Network Working Group R. Blom
Internet-Draft Y. Cheng
Intended status: Standards Track F. Lindholm
Expires: September 5, 2009 J. Mattsson
M. Naslund
K. Norrman
Ericsson Research
March 4, 2009
The Use of the Secure Real-time Transport Protocol (SRTP)
in Store-and-Forward Applications
draft-naslund-srtp-saf-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 5, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Blom, et al. Expires September 5, 2009 [Page 1]
Internet-Draft SRTP in Store-and-Forward Applications March 2009
Abstract
This memo describes the use of so called store-and-forward
cryptographic transforms within the Secure Real-time Transport
Protocol (SRTP). The motivation is to support use cases when two
end-points communicate via one (or more) store-and-forward
middleboxes that are not fully trusted to access the media content.
One of the main aspects of the transform is to make the
confidentiality and message authentication independent of the RTP
header. Another central aspect is to make identification of the
cryptographic context (keys etc.) independent of RTP transport
parameters. Besides the security of the end-points, also trust
assumptions regarding the store-and-forward middleboxes are
addressed.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Scope of this Document . . . . . . . . . . . . . . . . . . 5
1.2. Conventions used in this Document . . . . . . . . . . . . 5
1.2.1. Notation and Definitions . . . . . . . . . . . . . . . 5
2. SRTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. The Store-and-Forward Use Case . . . . . . . . . . . . . . . . 6
3.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 7
3.2. Trust Model and Security Requirements . . . . . . . . . . 7
3.3. Problems with SRTP in SaF Scenarios . . . . . . . . . . . 8
4. Usage of SaF Security within SRTP . . . . . . . . . . . . . . 9
4.1. The SaF Extension . . . . . . . . . . . . . . . . . . . . 9
4.2. SRTP SaF Packet Format . . . . . . . . . . . . . . . . . . 9
4.3. Extension of the SRTP Cryptographic Context . . . . . . . 12
4.3.1. E2e Context Definition . . . . . . . . . . . . . . . . 12
4.3.2. Identification of e2e Context . . . . . . . . . . . . 13
4.4. SRTP SaF Processing . . . . . . . . . . . . . . . . . . . 16
4.4.1. Sender . . . . . . . . . . . . . . . . . . . . . . . . 16
4.4.2. SaF Middlebox . . . . . . . . . . . . . . . . . . . . 16
4.4.3. Receiver . . . . . . . . . . . . . . . . . . . . . . . 18
4.5. SRTCP SaF . . . . . . . . . . . . . . . . . . . . . . . . 19
4.6. Cryptographic Transforms . . . . . . . . . . . . . . . . . 19
4.6.1. Hbh Transforms . . . . . . . . . . . . . . . . . . . . 19
4.6.2. E2e Transforms . . . . . . . . . . . . . . . . . . . . 19
4.6.3. Session Key Derivation . . . . . . . . . . . . . . . . 20
5. SRTP SaF Default Parameters . . . . . . . . . . . . . . . . . 20
5.1. Adding Future e2e Transforms . . . . . . . . . . . . . . . 21
6. Security Considerations . . . . . . . . . . . . . . . . . . . 21
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.2. Keystream Reuse . . . . . . . . . . . . . . . . . . . . . 22
6.3. Attacks on CCIs . . . . . . . . . . . . . . . . . . . . . 22
Blom, et al. Expires September 5, 2009 [Page 2]
Internet-Draft SRTP in Store-and-Forward Applications March 2009
6.4. Authentication and Authorization . . . . . . . . . . . . . 23
6.5. Replay Protection . . . . . . . . . . . . . . . . . . . . 23
6.6. Key Management Considerations . . . . . . . . . . . . . . 24
6.7. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.8. RTCP Considerations . . . . . . . . . . . . . . . . . . . 25
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.1. Normative References . . . . . . . . . . . . . . . . . . . 25
9.2. Informative References . . . . . . . . . . . . . . . . . . 25
Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . . 25
A.1. Streaming Pre-encrypted Media . . . . . . . . . . . . . . 26
A.2. Recording Encrypted Media at Home . . . . . . . . . . . . 26
A.3. Answering Machine . . . . . . . . . . . . . . . . . . . . 26
A.4. Media Rewind . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Blom, et al. Expires September 5, 2009 [Page 3]
Internet-Draft SRTP in Store-and-Forward Applications March 2009
1. Introduction
The Secure Real-time Transport Protocol (SRTP) [RFC3711] is a profile
of RTP, which can provide confidentiality, message authentication,
and replay protection to the RTP traffic and to the RTP control
protocol, the Real-time Transport Control Protocol (RTCP). The basic
SRTP profile in [RFC3711] solves real-time end-to-end use cases, and
does not consider use cases requiring store-and-forward (SaF)
middleboxes. Such use cases are characterized by the need for a
sender to deliver media to a receiver via a SaF middlebox. A SaF
middlebox temporarily stores media and retransmits it to the intended
receiver. Retransmission can be almost immediate (e.g. a push-to-
talk group server), or be done at a much later time (e.g. a VoIP
answering machine). The SaF middlebox is typically considered as
semi-trusted, meaning that a SaF middlebox will store and deliver
media as requested, but it cannot be excluded that a SaF middlebox
will also try to extract the information for its own purposes
(whatever they might be). The trust model will be made more formal
later in this document. What causes problems for standard end-to-end
SRTP in these settings is its dependence on the actual RTP transport
parameters which will differ when RTP is used on different hops,
i.e., sender-middlebox and middlebox-receiver.
SRTP is a framework that allows new security functions and new
transforms to be added and this document defines a so called Store-
and-Forward extension to SRTP to meet the additional use cases
considered. One of the main aspects of the transform is to make the
confidentiality and message authentication independent of the RTP
header. This allows for end-to-end protection to be achieved also in
the cases SaF middleboxes need to manipulate the RTP headers.
Another aspect is that identification of the cryptographic context
(keys etc.) between the end-points must be independent on parameters
that are well-defined only during transport of RTP packets over a
"hop". For instance, [RFC3711] specifies that the receiver's IP
address shall be part of the context identifier, but this value may
of course not be known to the sender when communicating messages via
a SaF middlebox. Indeed, the receiver may not even be on-line at the
time when the source initiates the communication. Another part of
the cryptographic context identifier is the SSRC, which may be
modified by SaF middleboxes and is hence seldom useful on an end-to-
end basis.
While there certainly are differences between this document and
[RFC3711] on mechanism level, it is worth noticing that the kind of
extensions defined herein are conceptually almost identical to the
SRTP extensions previously defined in [RFC4383], which adds source
origin authentication support to SRTP. Moreover, the SaF middleboxes
may use [RFC3711] compliant implementations for the cryptographic
Blom, et al. Expires September 5, 2009 [Page 4]
Internet-Draft SRTP in Store-and-Forward Applications March 2009
processing and changes are thus only needed in the end-points.
1.1. Scope of this Document
The scope of this document is to specify extensions to SRTP
(parameters, processing, and cryptographic transforms) to support the
store-and-forward use case and its associated trust model. The SaF
use case and trust models is defined in Section 3. No claims are
made about supporting also other use cases, though of course, all the
original uses cases from [RFC3711] can also be supported.
The SaF use case implies a different trust model than that originally
considered when designing SRTP. This manifests itself in terms of
the need to ensure authorized access to the different cryptographic
keys involved, i.e. the extensions defined herein MUST have support
from some key management scheme. Similar to the original SRTP
specification, the actual definition of the key management solution
is out of scope of this document. Necessary (and sufficient)
requirements on the key management can be found in Section 6.6.
1.2. Conventions used in this Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Throughout the specification all protocol data fields are assumed to
be byte aligned, i.e. all defined bit-sizes SHALL be multiples of 8.
1.2.1. Notation and Definitions
DoS: Denial of service
e2e: end-to-end
hbh: hop-by-hop
SaF: Store-and-Forward
For the purpose of this document we use the following definitions:
A SaF e2e session is defined as the set of SaF e2e protected data
produced under a single e2e context (see Section 4.3 for definition
of e2e context). A SaF e2e session may comprise several so-called
SaF sources, i.e. several distinct logical e2e media streams to be
protected by the same e2e context.
A SaF hbh session is defined as the set of SaF hbh protected data
Blom, et al. Expires September 5, 2009 [Page 5]
Internet-Draft SRTP in Store-and-Forward Applications March 2009
produced under a single hbh master key.
A is said to trust B with information I, if A is willing to share I
with B. In the sequel we will simply say that A trusts B.
A is said to have sender-semi-trust in B if A considers B to be what
is often called "honest-but-curious". That is, A trusts that B will
maintain information, I, provided by A, and redistribute it at least
to a specified subset of the entities which A trusts with I. However,
A does not trust that B will not try to extract the information I for
him/herself and/or to attempt to distribute I also to other parties,
e.g. parties that A does not trust.
A is similarly said to have receiver-semi-trust in B, if A trusts B
to maintain information intended for A and, on request, distribute
this information to A. However, A does not trust that B will not also
distribute the information to others and/or try to extract it him/
herself.
When it is obvious from the context (or irrelevant) we shall omit the
directivity (sender/receiver) and simply say that A semi-trusts B.
2. SRTP
The Secure Real-time Transport Protocol (SRTP) [RFC3711] is a profile
of RTP, which can provide confidentiality, message authentication,
and replay protection to the RTP traffic and to the RTP control
protocol, the Real-time Transport Control Protocol (RTCP). Note that
the term "SRTP" may often be used to indicate SRTCP as well. SRTP is
a framework that allows new security functions and new transforms to
be added. In the sequel, we assume that the reader is familiar with
the SRTP specification [RFC3711], its packet structure, and its
processing rules.
This specification defines a so called Store-and-Forward extension to
SRTP to permit communication via semi-trusted SaF middleboxes. As
mentioned, the SRTP extensions defined herein are very similar in
nature to the SRTP extensions previously defined in [RFC4383] to add
source origin authentication support to SRTP. In both cases, the
extensions needed are: definition of new cryptographic transforms, a
new packet format including additional in-band context signaling, and
extensions to the cryptographic contexts
3. The Store-and-Forward Use Case
Blom, et al. Expires September 5, 2009 [Page 6]
Internet-Draft SRTP in Store-and-Forward Applications March 2009
3.1. Problem Statement
We consider RTP communication solutions that include semi-trusted SaF
middleboxes, i.e. middleboxes that should not have access to
cleartext media, but still should be able to have access to other
data in order to retransmit media according to RTP standard
procedures. Below, we provide some use cases where S, M, and R refer
to Sender, SaF Middlebox, and Receiver.
Streaming Pre-encrypted Media: A content creator (S) distributes high
value, encrypted content to clients (R). Distribution is made via a
streaming server (M).
Recording Encrypted Media: Encrypted IPTV is broadcasted in a
network. Only clients trusted by the content creator (S) should have
access. Before having acquired a license to view the content, a user
(R) records media on a Hard Disk Drive (M), where the media is stored
in encrypted format on M, awaiting a license for rendering.
Answering Machine: Operators commonly provide an answering machine
service to their customers. Communicating parties (S and R) may not
wish to disclose the media to any other party. Thus, the answering
machine (M) acts as a SaF middlebox, which has to store encrypted
data and retransmit it to the callee.
Further examples and more details can be found in Appendix A
The typical use case is thus to require that media is (at least)
confidentiality protected end-to-end (e2e) between the sender and the
receiver. At the same time the communication should be protected
hop-by-hop (hbh) to prevent malicious users from performing denial of
service attacks by sending bogus data to SaF middleboxes, which the
SaF middleboxes then would store, eventually exhausting their storage
space and corrupting the data stored.
3.2. Trust Model and Security Requirements
The following figure shows the assumed trust model in terms of
previous definitions.
In practice, the model means that
o S trusts R,
o S semi-trusts M to deliver information to R, and,
o R semi-trusts that M will forward any information intended for R.
Blom, et al. Expires September 5, 2009 [Page 7]
Internet-Draft SRTP in Store-and-Forward Applications March 2009
Trust
-------------------------------------------->
+---+ +---+ +---+
| S | | M | | R |
+---+ +---+ +---+
---------------------> <---------------------
Sender-semi-trust Receiver-semi-trust
Figure 1: Trust Model (Sender, SaF Middlebox, Receiver)
Typically the trust between S and R is mutual, but we do not require
it to be. M does not need to trust either of S or R. However, in
order to fulfill its (assumed) duty as a semi-trusted SaF middlebox,
M must at least be able to authenticate S and R and the information
they provide. If this was not the case, some malicious party might
exhaust the storage resources of M, implying that it could not even
be semi-trusted by S and R. That is, the trust model also assumes the
existence of other parties (not shown) that are not trusted by any of
S, M or R, and which may attempt to intervene with the communication
between them and the SaF services provided by M.
When several SaF middleboxes lie on the path between S and R, it is
necessary to assume that SaF middleboxes semi-trust each other, at
least in a transitive sense. Also, we may then have a situation
where S and R does not (directly) semi-trust a common M.
The security requirements for SRTP SaF hence are:
1. It SHALL be possible to provide e2e confidentiality and message
authentication between S and R.
2. It SHALL be possible to provide hbh message authentication
between S and M, respectively between M and R.
To provide a basis for enhanced privacy protection against other
parties (e.g. traffic analysis), hbh confidentiality SHOULD also be
provided. Some practical use cases when this trust model is likely
to apply are given in Appendix A.
The cryptographic transforms, keys, etc., used for the e2e and hbh
protection, respectively, are denoted e2e transform, hbh transform,
e2e key, hbh key, etc.
3.3. Problems with SRTP in SaF Scenarios
It would be desirable to be able to offer use of SRTP as a general,
lightweight mechanism to achieve the above type of protection, but
trying to do so reveals two main problems.
Blom, et al. Expires September 5, 2009 [Page 8]
Internet-Draft SRTP in Store-and-Forward Applications March 2009
The first problem is due to the fact that RTP streams recorded and
later resent by an entity in general are independent; received SRTP-
encrypted payloads cannot just be stored and later retransmitted as
they are. For instance, a new SSRC is most likely used when
retransmitting. This in particular implies that SRTP with currently
defined transforms cannot be applied end-to-end as they depend on the
SSRC.
The second problem is that in order to provide both e2e and hbh
protection, two independent security contexts with associated
protection mechanisms have to coexist; a feature unavailable in SRTP
as currently specified. While it is not too difficult to imagine how
two contexts in place of one might be used, a problem arises when
specifying how the e2e part of the context should be identified and
signaled, as current SRTP context definition rests on parameters
which are not valid end-to-end in the SaF scenario, namely SSRC and
receiver IP address and port.
The SRTP SaF extension defined in this document addresses these
problems.
4. Usage of SaF Security within SRTP
4.1. The SaF Extension
The SaF extension consists of a new packet format (Section 4.2), an
extended cryptographic context concept (Section 4.3), and new SRTP
processing at sender/receiver (Section 4.4). SaF middlebox
operations are, from cryptographic point of view, compatible with
[RFC3711] and otherwise explained in Section 4.4.2. Senders/
receivers need to support new SRTP transforms (Section 4.6).
4.2. SRTP SaF Packet Format
Figure 2 illustrates the format of the SRTP packet when SaF is
applied.
The packet format is composed of an "inner" e2e (sender-receiver)
part embedded in an "outer" hbh (sender-middlebox or middlebox-
receiver) part. Between these parts, a new CCI field (explained
below) is introduced.
The e2e protected portion provides confidentiality protection of the
payload, RTP padding and RTP PAD count. This confidentiality
protected part is called the e2e encrypted portion. The e2e
encrypted portion together with the two fields for cryptographic
synchronization, the e2e PUV and the SSS, and the corresponding e2e
Blom, et al. Expires September 5, 2009 [Page 9]
Internet-Draft SRTP in Store-and-Forward Applications March 2009
MAC tag constitute the e2e authenticated portion. Whether
authentication implies source origin authentication or only message
integrity depends on the transform used. Thus, e2e encryption is
provided over the Payload, RTP padding, and RTP pad count fields,
while authentication is provided for the e2e PUV and SSS as well.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<---+
|V=2|P|X| CC |M| PT | sequence number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| timestamp | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| synchronization source (SSRC) identifier | |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
| contributing source (CSRC) identifiers | |
| .... | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| RTP extension (OPTIONAL) | |
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ |
| | payload ... | | |
| | +-------------------------------+ | |
| | | RTP padding | RTP pad count | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| ~ e2e PUV (OPTIONAL) ~ | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| ~ SSS (OPTIONAL) ~ | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| ~ e2e MAC (RECOMMENDED) ~ | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ |
| ~ CCI (MANDATORY) ~ | |
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-|-+
| ~ hbh SRTP MKI (OPTIONAL) ~ | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| ~ hbh authentication tag (RECOMMENDED) ~ | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | |
+-- hbh Encrypted Portion e2e Protected Portion ---+ |
|
hbh Authenticated Portion -----+
Figure 2: The format of the SRTP packet when SaF is applied.
Default e2e transforms, which provide both encryption and
authentication, and which SHALL be supported are defined in
Section 4.6.2.
The e2e protected part is opaque from SaF middlebox point-of-view.
Blom, et al. Expires September 5, 2009 [Page 10]
Internet-Draft SRTP in Store-and-Forward Applications March 2009
Thus, by treating the inner e2e protected part and Crypto Context
Identifier (CCI, see below) as the (hbh) "encrypted portion" of
[RFC3711], the overall SRTP packet conforms to standard [RFC3711]
compliant SRTP. (Note that the additional fields added in the inner
e2e part could just as well have been added by a new transform
defined for SRTP, e.g. padding and/or crypto synch fields.) Hence,
the hbh MAC and hbh MKI are in one-to-one correspondence with the MAC
and MKI of [RFC3711] and will not be discussed further.
The additional fields added by the inner e2e security processing are:
o SSS: SRTP SaF Source is a value used by the SRTP SaF transform as
an identifier for the SaF source within a SaF e2e session. Thus,
SSS MUST be unique for all SaF sources within the SaF e2e session.
Since there may be only one such SaF source, the SSS field is
OPTIONAL and of configurable length. SSS resembles the SSRC usage
in RTP/SRTP in the sense that it ensures that two-time pads do not
occur under the same e2e master key, see Sections 4.6 and 6.2.
The implementation of the necessary anti-collision mechanism is
outside the scope of this specification.
o e2e PUV: Packet Unique Value for the e2e transform, transform
dependent and configurable length, OPTIONAL. While the format is
transform dependent, some security aspects needs consideration
when defining the format, see Section 6.2 and 6.4. When used, for
a given SaF source, the e2e PUV shall be unique for each e2e
protected portion being generated by that SaF source within the
SaF e2e session (with the use of the same SSS). The e2e PUV is
used as input ti the IV formation for the e2e transform.
o e2e MAC: This field is used to carry payload authentication data
e2e. It is of transform dependent, configurable length and is
RECOMMENDED to be used. Observe that the e2e MAC SHALL cover the
RTP payload, the e2e PUV and SSS but SHALL NOT cover the RTP
header, nor the CCI.
o CCI: Crypto Context Identifier: used to signal from sender to
receiver, via a SaF middlebox, which e2e cryptographic context
(keys and other parameters, see Section 4.3.1) to use. The field
is MANDATORY, of configurable length and MAY be modified by a SaF
middlebox.
Parameters which are configurable are either defaults (see
Section 5), negotiated during SaF e2e/hbh session establishment,
agreed upon out of band, or hard coded for a specific application.
Blom, et al. Expires September 5, 2009 [Page 11]
Internet-Draft SRTP in Store-and-Forward Applications March 2009
4.3. Extension of the SRTP Cryptographic Context
A SRTP SaF cryptographic context SHALL consist of three main parts.
1. The hbh context SHALL be an SRTP cryptographic context conforming
to [RFC3711] and SHALL be used for the hbh protection between
sender and SaF middlebox, between SaF middlebox and receiver, or,
between two SaF middleboxes. The hbh context SHALL thus be
identified by the (destination IP address, destination port,
SSRC) triplet exactly as defined in [RFC3711].
2. One (or more) e2e contexts: this part of the context is defined
below and SHALL be used for the e2e protection between sender and
receiver.
3. With each e2e context, a CCI value SHALL be associated. Since
the length of CCI is variable, each CCI SHALL be associated with
a length parameter, n_CCI.
4.3.1. E2e Context Definition
The e2e context SHALL contain the following e2e transform independent
parameters.
o an identifier for the e2e encryption algorithm, i.e., the cipher
and its mode of operation,
o an identifier for the e2e message authentication algorithm,
o an e2e master key, which MUST be random and secret to all except
sender and receiver. The e2e master key MUST be cryptographically
independent of any hbh key,
o an e2e master salt, which MUST be random,
o non-negative integers n_e, n_a, and n_s determining the length of
the session keys for encryption, message authentication, and
session salt,
o non-negative integers n_PUV, and n_SSS determining the length of
the per-packet initialization vector, and SSS fields.
There may also be need to include e2e transform dependent parameters,
see Section 4.6.2 for the parameters associated with the default e2e
transforms.
Observe that there is no replay protection data in the e2e context,
see Section 4.4.3.1. Also note that the e2e context SHALL only
Blom, et al. Expires September 5, 2009 [Page 12]
Internet-Draft SRTP in Store-and-Forward Applications March 2009
contain parameters for SRTP, and SHALL NOT contain parameters for
SRTCP, see Section 4.5.
E2e contexts need only to be supported by end-points, i.e. senders
and receivers. SaF middleboxes need, however, to understand the
usage of the e2e context identifiers (CCI) as discussed next.
4.3.2. Identification of e2e Context
More than one e2e context MAY be used in the case of SaF middlebox to
receiver communication. The motivation for allowing more than one
e2e context is to support scenarios where the SaF middlebox and
receiver use a single (S)RTP session into which they multiplex
several e2e protected sessions, see Appendix A for use cases.
The e2e context SHALL be identified by a combination of out-of-band
and in-band signaling.
The out-of-band part of the context identifier is defined as follows.
Each sender SHALL for each e2e context define a Content ID, CID. The
CID MUST uniquely determine the context between a sender and a
receiver but the exact format of the CID is outside the scope of this
specification. For example, a statistically unique (e.g. 256-bit)
value may be used. The CID is communicated by out-of-band means:
o e2e, between sender and receiver
o hbh, between sender and SaF middlebox, between two SaF middleboxes
(as applicable), and between SaF middlebox and receiver.
How this is done (which protocol etc.) is outside the scope of this
specification but will typically be part of session setup.
The in-band part of the context identification uses the CCI field in
the SRTP SaF packet (see Figure 2).
The CCI may be thought of as a mutant, short, in-band alias for the
CID and is only used on hbh basis. When a CID is transferred (hbh)
out-of-band from a source to a destination, the source SHALL also
indicate which in-band CCI it will associate with that CID. If
multiple pieces of content corresponding to multiple CIDs are
transferred within the same SaF hbh session, the source SHALL ensure
the use of distinct CCIs for all CIDs. It is RECOMMENDED for privacy
reasons to assign CCIs randomly, with the above uniqueness
requirement. During transfer of e2e protected content associated
with a certain CID, the source (initial sender or SaF middlebox)
SHALL add the associated CCI to each packet being part of that
content.
Blom, et al. Expires September 5, 2009 [Page 13]
Internet-Draft SRTP in Store-and-Forward Applications March 2009
4.3.2.1. CCI Mapping
In a SaF use case it may be difficult for senders to ensure that the
CCI uniquely determines the e2e context on the receiver side. For
instance, a sender S may send and store several messages intended for
a certain receiver, R, on the SaF middlebox M at different points in
time. The messages may be protected by different keys, yet S may
accidentally reuse the same CCI twice since it cannot be required
that the sender maintains state. Similarly, if several distinct
senders leave messages for a certain R, two different senders may
accidentally use the same CCI. In both these cases, if multiple
pieces of content are then multiplexed within the same RTP session
between the SaF middlebox and the receiver, the original CCIs may
fail to uniquely determine the CID and the associated keys.
To avoid these issues, the SaF middlebox SHALL detect collisions in
CCI values used by sender(s) in communication directed to a certain
fixed receiver in the following sense: For each distinct CID
(provided by the sender or a previous SaF middlebox) the SaF
middlebox SHALL ensure that distinct CCIs are used when forwarding
messages to the receiver (or to another SaF middlebox) within any
given hbh session. The SaF middlebox SHALL, in conjunction to
informing the next hop destination about the CID values, also inform
if and how it has associated the CCIs to CIDs, e.g. as part of
session setup signaling. For instance, the SaF middlebox may provide
pairs of form
(CID1, CCI1), (CID2, CCI2), ...
The CCIs are then used in-band when forwarding the media to indicate
which e2e crypto context shall be used with each packet. As noted
above, the CCI SHALL NOT be e2e authenticated, in order to allow
changes by SaF middleboxes. Clearly, the CCIs SHOULD be hbh
authenticated to avoid e.g. DoS attacks, see Section 6.3 for
security considerations.
The figure below shows a simple example of signaling of CID/CCI and
their use.
Blom, et al. Expires September 5, 2009 [Page 14]
Internet-Draft SRTP in Store-and-Forward Applications March 2009
o-o-b: CID1
+------------------------------------------------------------------+
| o-o-b: (CID1, CCI1) |
| +-------------------------+ |
| | | o-o-b: (CID1, CCI1), (CID2, CCI3) |
+----+ | +---------------------------------+ |
| | SRTP SaF: CCI1 | | | |
| S1 |------------------+ v | v v
| | | +---+ +---+
+----+ +--->| | SRTP SaF: CCI1, CCI3 | |
| M |------------------------------>| R |
+----+ +--->| | | |
| | | +---+ +---+
| S2 |------------------+ ^ ^
| | SRTP SaF: CCI2 | |
+----+ | /* CCI2 == CCI1 */ |
| | | |
| +--------------------------+ |
| o-o-b: (CID2, CCI2) |
+-----------------------------------------------------------------+
o-o-b: CID2
Figure 3: Two senders, S1 and S2, accidentally choose the same CCI
for their content, and the SaF middlebox, M, changes the CCIs to
avoid collisions.
The sender S1 wishes to store a message for R on SaF middlebox M. S1
uses out-of-band (o-o-b) signaling to communicate the Content ID CID1
to R and CID1 and the crypto context id, CCI1, to M. (The
communication with R typically will not happen at the same time as
the communication with M; it may have already occurred, or it may
occur later.) S1 then uses SRTP SaF with in-band CCI1 to transfer
content to M.
Later, also S2 stores a message for R on SaF middlebox M. S2 uses
out-of-band signaling to communicate the Content ID CID2 to R and
CID2 and the crypto context id, CCI2 to M. S2 then uses SRTP SaF with
in-band CCI2 to transfer content.
By accident, CCI2 equals CCI1 which triggers an anti-collision
mechanism in M as the same recipient is specified. When R later
retrieves the content from M it is multiplexed inside the same SRTP
SaF session. Before starting the streaming, however, M first (using
out-of-band-signaling) informs R about the CIDs and their
corresponding CCIs.
In what follows, it is assumed that the sender and receiver agree
out-of-band on the e2e cryptographic context parameters to use, in
Blom, et al. Expires September 5, 2009 [Page 15]
Internet-Draft SRTP in Store-and-Forward Applications March 2009
particular the content and context identifiers, CID, CCI as discussed
above.
It is similarly assumed that sender-middlebox and middlebox-receiver,
respectively, agree on the hbh cryptographic context.
4.4. SRTP SaF Processing
4.4.1. Sender
The sender SHALL first, out-of-band, establish the necessary CIDs,
CCIs and SaF hbh context parameters with the SaF middlebox as
discussed above. The rest of sender's processing is similar to
[RFC3711] with the following exceptions.
S1 When in step 1 of [RFC3711], the sender determines the
cryptographic contexts, i.e. the sender SHALL here determine both
the hbh context and the e2e context as discussed in Section 4.3.1
and 4.3.2.
S2 The sender SHALL from the e2e master key and master salt
determine the e2e session key(s)/salt as discussed in
Section 4.6.3.
S3 The sender SHALL next apply the e2e encryption transform as
described in Section 4.6.2.
S4 The sender SHALL next apply the e2e authentication transform as
described in Section 4.6.2 applying the e2e session key(s)/salt
of step S2 to the result of S3 concatenated by the e2e PUV, and
the SSS.
S5 The sender SHALL then form the e2e protected part of the SRTP SaF
packet by concatenating the result of S3, the e2e PUV, the SSS
and the tag from S4.
S6 The sender adds the CCI (see also Figure 2).
The rest of the sender's processing conforms to [RFC3711], steps 2-8,
by treating the result of S6 as the part to be encrypted ("encrypted
portion" of [RFC3711]) and using the hbh context.
4.4.2. SaF Middlebox
SaF middleboxes do not have access to the e2e contexts and may even
be unaware of their definition. Hence, "context" in this section
refers to standard [RFC3711] cryptographic contexts, which in turn
agrees with the hbh contexts defined herein.
Blom, et al. Expires September 5, 2009 [Page 16]
Internet-Draft SRTP in Store-and-Forward Applications March 2009
Generally, the SaF middlebox SHALL first, out-of-band, establish the
necessary CIDs, CCIs, and SaF hbh context parameters with the source
or destination as discussed above.
4.4.2.1. Acting as Receiver ("Store")
MR1 When receiving media from a sender, the SaF middlebox SHALL
retrieve the correct context and process the packet exactly
according to the receiver behavior of [RFC3711].
MR2 The SaF middlebox SHALL store sufficient information to later
identify/authenticate the intended receiver, e.g. the intended
receiver's identity (ID). ID format and usage is otherwise out
of scope for this specification, but could, e.g., be retrieved
during the session establishment.
MR3 The SaF middlebox SHALL store information sufficient to later
reconstruct the e2e protected part of the packets (corresponding
to Figure 2) and to allow the receiver uniquely identify the
correct e2e context, by storing the CID. Note that information
from RTCP SR are used for synchronization between streams e.g.
in a multimedia video/audio session. Such information also has
to be stored by the SaF middlebox.
4.4.2.2. Acting as Sender ("Forward")
MS1 When forwarding media to the receiver, the SaF middlebox SHALL
retrieve the correct context as specified in [RFC3711].
MS2 A payload SHALL be formed consisting of the e2e protected part
and the CCI.
MS3 The SaF middlebox SHALL then add an RTP header and process the
packet exactly according to the sender behavior of [RFC3711]
using the retrieved context. As noted above, certain
information from RTCP messages, originating from the sender
(e.g. RTCP SRs), may also need to be forwarded. These (and
other RTCP messages) SHALL be processed according to the SRTCP
specification of [RFC3711].
4.4.2.3. Multiple SaF Middleboxes
When more than one SaF middlebox is present, we consider a pair of
adjacent SaF middleboxes M1 and M2, where M1 forwards media M2.
M1 SHALL act as if M2 was the (final) receiver for the media by
providing M2 CIDs, CCIS, and hbh protected packets, i.e. according to
Section 4.4.2.2.
Blom, et al. Expires September 5, 2009 [Page 17]
Internet-Draft SRTP in Store-and-Forward Applications March 2009
M2 SHALL act as a SaF middlebox receiver (Section 4.4.2.1).
4.4.3. Receiver
The receiver SHALL first, out-of-band, establish the necessary CIDs,
CCIs and SaF hbh context parameters with the SaF middlebox as
discussed above. The rest of the receiver's processing is similar to
[RFC3711] with the following exceptions.
R1 The receiver SHALL determine the hbh cryptographic context
according to [RFC3711].
R2 The receiver SHALL then proceed according to steps 2-8 of
[RFC3711] using the hbh context.
The remainder of the processing concerns the e2e protection. The
result after performing the hbh authentication check and decryption
as described above MAY be stored at the receiver for later
application of the e2e processing. If so, the receiver MUST store
the e2e protected part and the CCI in order to be able to perform the
further steps as described below.
R3 The receiver SHALL next determine the e2e context as discussed in
Section 4.3.2. (In case the CCI was NOT encrypted by the hbh
transform, the receiver MAY determine the e2e context already in
step R1.)
R4 The receiver SHALL determine the e2e session encryption/
authentication key(s) as describe in Section 4.6.3 using the e2e
master key and salt.
R5 The receiver SHALL verify authentication and decrypt the e2e
protected part as specified by the e2e transform(s), see
Section 4.6.2. If the result of authentication is "FAILURE", the
packet MUST be discarded from further processing and the event
SHOULD be logged. Note that there is no replay protection for
the e2e context (see Section 6.5).
R6 The receiver removes e2e PUV, SSS, e2e authentication tag, and
CCI as appropriate.
4.4.3.1. Replay Protection
For the reasons discussed in Appendix A, it is generally not
meaningful or desirable to provide application independent replay
protection for the e2e part. Some of the identified use cases have a
requirement for the receiver to be able to jump back/forward in the
e2e media stream. See Section 6.5 for security considerations.
Blom, et al. Expires September 5, 2009 [Page 18]
Internet-Draft SRTP in Store-and-Forward Applications March 2009
4.5. SRTCP SaF
SRTCP protection SHALL only be provided hbh, as this covers most/all
use cases currently identified. Further RFCs may specify additional
e2e functionality for SRTCP SaF.
As noted, information of some of the inbound RTCP messages (from S to
M) may be beneficial to forward in the outbound RTCP (from M to R).
However, it may in general not be possible for the SaF middlebox to
reproduce RTCP reports, accurately reflecting the ongoing SaF hbh
session. For instance, since the e2e encryption hides any possible
RTP padding, there may be a discrepancy between sender's byte counts
on the S-M and M-R links, respectively. After decryption at R,
however, the correct values will be possible to reconstruct.
4.6. Cryptographic Transforms
We define a set of SRTP SaF transforms. Note that SaF middleboxes do
not need to support any cryptographic transform outside what is
already defined in [RFC3711].
4.6.1. Hbh Transforms
The hbh protection may reuse any of the existing SRTP transforms such
as those of defined in the original specification [RFC3711], or,
transforms that have been added later. AES-128 Counter Mode and
HMAC-SHA1-80 SHALL be used as defaults.
4.6.2. E2e Transforms
The sender SHALL first apply the e2e encryption transform and then
the e2e authentication transform.
The default encryption transform for e2e protection is AES Counter
Mode as specified in [RFC3711], Section 4.1.1, with the following
modification. Instead of forming the initialization vector as
defined in [RFC3711], the IV SHALL be formed as:
IV = (k_s * 2^16) XOR (SSS * 2^64) XOR (PUV * 2^16)
where k_s is the session salting key (derived from the e2e master
salt, see Section 4.6.3) and where SSS and e2e PUV are the SSS/PUV
fields from the packet. The PUV is a counter, initially set to zero
and then increasing by one (1) for each packet. The default size of
the PUV SHALL be 48 bits which SHALL also be the maximum allowed size
for the AES counter mode transform. If the SSS field is not present,
the value 0 (zero) SHALL be used. The default size of the SSS SHALL
be zero (not present) and the maximum size for AES counter mode SHALL
Blom, et al. Expires September 5, 2009 [Page 19]
Internet-Draft SRTP in Store-and-Forward Applications March 2009
be 64 bits.
The key used SHALL be the session encryption key (derived from the
e2e master key, see also Section 4.6.3).
The default e2e authentication transform SHALL be HMAC-SHA1 as
defined in [RFC3711], Section 4.2.1, with the difference that it
SHALL be applied to the e2e protected portion, excluding the e2e MAC
field itself. Note also that the e2e MAC SHALL NOT be applied to the
CCI value. The resulting MAC tag SHALL be added in the e2e_MAC field
of the e2e protected portion.
The key used shall be the session authentication key k_a (derived
from the e2e master key, see Section 4.6.3).
4.6.3. Session Key Derivation
4.6.3.1. Hbh Session Keys
For the hbh security processing, session key derivation SHALL be done
exactly as in [RFC3711] using the master key/salt of the hbh context.
4.6.3.2. E2e Session Keys
For the e2e security processing the key derivation is also identical
to [RFC3711] with the following exceptions
o The e2e master key/salt, etc. SHALL be used.
o The key derivation rate SHALL be zero.
5. SRTP SaF Default Parameters
The default hbh parameters are identical to [RFC3711].
The default e2e parameters are also the same as in [RFC3711] with the
differences in transform definition as defined above and the
following additional exception.
o Replay window size: N/A (or 0).
We also add the following additional default parameter:
o n_PUV: 48 bits.
o n_SSS: 0 (not used)
Blom, et al. Expires September 5, 2009 [Page 20]
Internet-Draft SRTP in Store-and-Forward Applications March 2009
o n_CCI: 32 bits
5.1. Adding Future e2e Transforms
Adding transforms for the hbh protection SHALL follow the existing
guidelines of [RFC3711]. Indeed, any current (or future, as far as
we can see) transform specification for SRTP is applicable for usage
with the hbh protection.
To add an e2e transform, the accompanying specification MUST, besides
specifying the cryptographic operations, define the format and usage
of the e2e PUV field and, if used, for the SSS field. An
authentication transform MUST define how the e2e authentication tag
is computed and MUST NOT include the CCI field in the authentication
coverage.
It is STRONGLY RECOMMENDED that, when separate transforms are used
for encryption and authentication, the sender SHALL first apply the
e2e encryption transform and then the e2e authentication transform,
and conversely on the receiver side. When a combined (data
encapsulation) transform is used, the order of processing is
typically built in to the transform.
6. Security Considerations
6.1. General
Though it may seem that there are quite a few differences between the
cryptography and key management used in [RFC3711] and the
corresponding functions defined here, the differences are actually
smaller then one may think and the security considerations turn out
to be essentially equivalent.
As noted, a problem of SRTP in SaF applications is the transforms'
dependence of the SSRC. The SSRC is part of IV formation and crypto
context identification in [RFC3711].
In this specification two a new in-band parameters, CCI and SSS, are
specified. Note that they are used in exactly the same way the SSRC
is used in [RFC3711]: context identification (CCI) and IV formation
(SSS). Basically, one can think of the CCI as the e2e context
identifier and the SSS as a substitute for the SSRC. The SSS (when
used) is e2e protected.
It would have been possible to use CCI alone as a replacement for
SSRC and omit the SSS. This would however have had a drawback since
CCIs may be changed (and even added) by SaF middlebox(es) and an e2e
Blom, et al. Expires September 5, 2009 [Page 21]
Internet-Draft SRTP in Store-and-Forward Applications March 2009
mechanism for mapping CCIs back to the original value would then be
needed.
6.2. Keystream Reuse
A main concern of [RFC3711] is to avoid keystream reuse which is
present also here.
Both the default hbh and e2e transforms use additive stream ciphers
which are sensitive to keystream reuse. It is therefore RECOMMENDED
that each session/message is carried out with random,
cryptographically independent e2e/hbh keys.
When sender and receiver share an e2e key it may be convenient to
reuse the key for several e2e sessions/messages via the SaF
middlebox. For the predefined e2e transform this is only possible if
sender/receiver keeps state to avoid reusing IVs. The situation also
holds if sender and receiver use the SaF middlebox in a "chat" like
fashion (bi-directional communication using the same keys in both
directions). In this case there may be a risk that a message in one
direction (e.g. "A-to-B") reuses keystream of some message in the
other direction ("B-to-A"). Again, with the default transform this
REQUIRES that IVs in one direction are never reused in the opposite
direction.
Unique IVs MAY be assured by putting requirement on the
implementation of the sender to assure that unique SSS values are
used each time the same master key is reused. For the bidirectional
case (as well as for the more general case where a group key is used
as master key), some out-of-band signaling that assures that end-
points use distinct SSSs is, as mentioned REQUIRED.
The situation is essentially equivalent to that of SRTP. As noted in
the security considerations of [RFC3711], keys may be reused (with
the predefined transforms) if (and only if) unique SSRC values can be
guaranteed. As noted the SSS and CCI value defined here for SaF SRTP
basically takes the place of SSRC in that they serves exactly the
same two purposes: being part of the crypto context identifier and
providing unique IVs.
Due to the risks of misuse, reuse of master keys between SaF sessions
is, just as in [RFC3711], therefore NOT RECOMMENDED.
6.3. Attacks on CCIs
The CCI values are not e2e integrity protected as it would make it
impossible for SaF middleboxes to modify them, which in turn is
needed to enable unique identification of the e2e cryptographic
Blom, et al. Expires September 5, 2009 [Page 22]
Internet-Draft SRTP in Store-and-Forward Applications March 2009
context and still using only 32 bits per packet in-band signaling.
(A larger CCI, e.g. 128 or 256 bit would guarantee statistical
uniqueness on e2e basis but is excluded as being too bandwidth
consuming).
If a SaF middlebox is malicious it can, by modifying CCIs, at most
cause DoS as the receiver will either be unable to process the e2e
protected media, or, will do so using incorrect context/keys, thereby
producing authentication failure and/or "garbage" after decryption.
An outsider (non-middlebox) may also attempt to modify CCIs. This
would have the same DoS aspects, but can be avoided if hbh integrity
is used as the CCI is then integrity protected on each hop where it
might be exposed. Modifications of the hbh integrity protected
messages would still result in a DoS attack, since the messages would
be dropped by the receiver. However, the DoS effect is further
limited in that "garbage" does not even reach the e2e protection
stage.An attack where messages are simply blocked/dropped by the
attacker would cause more or less the same effect. Use of hbh
integrity is RECOMMENDED as it also protects the SaF middleboxes from
filling up storage space with junk.
6.4. Authentication and Authorization
For reasons already discussed, it is RECOMMENDED that middleboxes
using this SaF specification authorize senders (typically involving
authentication) before accepting messages to be stored/forwarded.
Similarly, it is RECOMMENDED that the middleboxes authorize/
authenticate the receiver before delivering data. While the content
is protected by keys supposedly only known to the receiver, this
provides extra protection if the e2e keys have fallen into the wrong
hands and it also avoids that the SaF middlebox wastes resources,
responding to spoofed requests. E2e authentication between sender
and receiver is achieved by applying authentication/integrity to the
e2e protected portion and is also RECOMMENDED.
6.5. Replay Protection
Replay protection is provided on an hbh basis by use of a hbh
transform including message authentication. It is RECOMMENDED to use
hbh message authentication as it protects from outsiders attempting
to change the order of packets.
Since some scenarios considered makes it reasonable to expect that
the receiver may wish to jump (fast-forward or rewind) in the e2e
protected media flow, it is not meaningful to strictly enforce replay
protection on an e2e basis. Note however that our trust model
assumes that the SaF middleboxes are trusted enough not to attempt to
Blom, et al. Expires September 5, 2009 [Page 23]
Internet-Draft SRTP in Store-and-Forward Applications March 2009
replay media unless the receiver so requests.
It is however still possible (and RECOMMENDED) to provide e2e
authentication of the packets in combination with inclusion of a
sequence number in the e2e PUV (as the default e2e transform does).
It then becomes infeasible for the SaF middlebox to fake the relative
association between a particular packet and its sequence number.
This means that the receiver will be able to detect a replay that
occurs without the receiver actually having requested it.
6.6. Key Management Considerations
While key management is outside the scope of this specification, some
considerations need to be highlighted and taken into account when
deploying this specification in practice.
To implement the targeted trust model, the main concern is that the
e2e key(s) MUST be independent from the hbh keys. In other words
knowledge of any hbh key MUST NOT reveal non-trivial information
about any e2e key.
This can be achieved by ensuring that key management for hbh and e2e
protection is carried out independently using completely new, random
and independent keys each time. This is the RECOMMENDED approach.
Another alternative which may be attractive in some cases is to use
the slightly weaker notion of cryptographic independence. Here, the
hbh keys MAY be derived from the e2e keys by applying a sufficiently
strong pseudo-random function.
Even if hbh keys are random and independent each time, it is still
RECOMMENDED that e2e keys are not cached/reused (see above discussion
on keystream reuse).
6.7. Privacy
In order for the receiver to identify the correct e2e context, the
SaF middlebox in general needs to convey this information to the
receiver and thus may need to store the identity of the sender and
will be able to deduce the communication taking part between the two.
To enhance privacy, senders/receivers may use agreed pseudonyms or
other similar Privacy Enhancing Techniques (PET)s. One such
technique is to follow the recommendation and assign random CCIs on
each hop. Complete anonymity appears difficult as it seems to
conflict with the requirement that the SaF middlebox needs protection
from flooding by garbage or other forms of unwanted traffic.
Blom, et al. Expires September 5, 2009 [Page 24]
Internet-Draft SRTP in Store-and-Forward Applications March 2009
When hbh encryption is configured some additional protection against
3rd party traffic analysis is provided since the CCIs are then even
encrypted.
6.8. RTCP Considerations
As specified, RTCP is only protected on hbh basis. This is motivated
by the assumption that a SaF middlebox indeed is a true store-and-
forward entity (as opposed to performing a more intelligent
function). The inbound/outbound RTP sessions are then different and
RTCP then reports only on the current RTP session.
7. Acknowledgements
The authors would like to thank Magnus Westerlund for his support and
valuable comments.
8. IANA Considerations
To signal that the new transforms are used, each relevant key
management protocol needs to register the new transforms including
numbering scheme and syntax with IANA.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
9.2. Informative References
[RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient
Stream Loss-Tolerant Authentication (TESLA) in the Secure
Real-time Transport Protocol (SRTP)", RFC 4383,
February 2006.
Appendix A. Use Cases
In the use cases below, we map the entities to the trust model of
Blom, et al. Expires September 5, 2009 [Page 25]
Internet-Draft SRTP in Store-and-Forward Applications March 2009
Section 3.2 by indicating which entity that corresponds to S, M, R.
A.1. Streaming Pre-encrypted Media
A content creator (S) wants to distribute high value content to
clients (R). The content provider distributes the media via a
streaming server (M) which should not have access to cleartext media,
typically because it is not trusted by the content creator.
A.2. Recording Encrypted Media at Home
High value encrypted media (e.g. IPTV, and radio) is broadcasted in
a network. Only clients trusted by the content creator (S) have
access to the encryption key. A user (R) is recording the media on a
Hard Disk Drive (M), but does not yet have a license or have a
license that does not allow cleartext copying. The media is
therefore stored in protected format on the HDD.
A.3. Answering Machine
Operators commonly provide an answering machine service to their
customers. In this case the communicating parties (S and R) may not
wish to disclose the media to any other party, and hence want to
apply encryption between each other. The answering machine (M) acts
as a SaF middlebox, which has to store encrypted data and retransmit
it to the callee.
In this use case it is also likely that several callers left messages
protected by different e2e keys. As discussed above, the receiver
and SaF middlebox may agree to use a single hbh context into which
the different e2e contexts are multiplexed using the CCI.
A.4. Media Rewind
Common to the use cases above is the possible desire to be able to
rewind or jump forward in the media stream. For instance, a user may
wish to listen once again to a message left in a voice mail without
terminating and reinitiating the session with the SaF middlebox.
Blom, et al. Expires September 5, 2009 [Page 26]
Internet-Draft SRTP in Store-and-Forward Applications March 2009
Authors' Addresses
Rolf Blom
Ericsson Research
SE-164 80 Stockholm
Sweden
Phone: +46 10 71 31 707
Email: rolf.j.blom@ericsson.com
Yi Cheng
Ericsson Research
SE-164 80 Stockholm
Sweden
Phone: +46 10 71 17 589
Email: yi.cheng@ericsson.com
Fredrik Lindholm
Ericsson AB
SE-164 80 Stockholm
Sweden
Phone: +46 10 71 31 705
Email: fredrik.lindholm@ericsson.com
John Mattsson
Ericsson Research
SE-164 80 Stockholm
Sweden
Phone: +46 10 71 43 501
Email: john.mattsson@ericsson.com
Mats Naslund
Ericsson Research
SE-164 80 Stockholm
Sweden
Phone: +46 10 71 33 739
Email: mats.naslund@ericsson.com
Karl Norrman
Ericsson Research
SE-164 80 Stockholm
Sweden
Phone: +46 10 71 44 502
Email: karl.norrman@ericsson.com
Blom, et al. Expires September 5, 2009 [Page 27]