Network Working Group R. Blom Internet-Draft Y. Cheng Intended status: Standards Track F. Lindholm Expires: December 24, 2009 J. Mattsson M. Naslund K. Norrman Ericsson Research June 22, 2009 The Use of the Secure Real-time Transport Protocol (SRTP) in Store-and-Forward Applications draft-naslund-srtp-saf-01 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 December 24, 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 December 24, 2009 [Page 1] Internet-Draft SRTP in Store-and-Forward Applications June 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 enable identification of the cryptographic context (keys etc.). 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 Cases . . . . . . . . . . . . . . . 6 3.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 6 3.2. Trust Model and Security Requirements . . . . . . . . . . 7 3.3. Problems with SRTP in SaF Scenarios . . . . . . . . . . . 9 3.4. Design Rationale . . . . . . . . . . . . . . . . . . . . . 9 4. Usage of SaF Security within SRTP . . . . . . . . . . . . . . 10 4.1. The SaF Extension . . . . . . . . . . . . . . . . . . . . 10 4.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 11 4.3. SRTP SaF Packet Format . . . . . . . . . . . . . . . . . . 11 4.4. Extension of the SRTP Cryptographic Context . . . . . . . 13 4.4.1. E2e Context Definition . . . . . . . . . . . . . . . . 14 4.4.2. Identification of e2e Context . . . . . . . . . . . . 15 4.5. SRTP SaF Processing . . . . . . . . . . . . . . . . . . . 18 4.5.1. Sender . . . . . . . . . . . . . . . . . . . . . . . . 18 4.5.2. SaF Middlebox . . . . . . . . . . . . . . . . . . . . 18 4.5.3. Receiver . . . . . . . . . . . . . . . . . . . . . . . 20 4.6. Use of SRTCP with SRTP SaF . . . . . . . . . . . . . . . . 20 4.7. Cryptographic Transforms . . . . . . . . . . . . . . . . . 21 4.7.1. Default hbh Transforms . . . . . . . . . . . . . . . . 21 4.7.2. Default e2e Transforms . . . . . . . . . . . . . . . . 21 4.7.3. Session Key Derivation . . . . . . . . . . . . . . . . 22 5. SRTP SaF Default Parameters . . . . . . . . . . . . . . . . . 22 5.1. Adding Future e2e Transforms . . . . . . . . . . . . . . . 23 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 23 6.2. Keystream Reuse . . . . . . . . . . . . . . . . . . . . . 24 Blom, et al. Expires December 24, 2009 [Page 2] Internet-Draft SRTP in Store-and-Forward Applications June 2009 6.3. Attacks on CCIs . . . . . . . . . . . . . . . . . . . . . 24 6.4. Authentication and Authorization . . . . . . . . . . . . . 25 6.5. Replay Protection . . . . . . . . . . . . . . . . . . . . 25 6.6. Key Management Considerations . . . . . . . . . . . . . . 26 6.7. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 26 6.8. RTCP Considerations . . . . . . . . . . . . . . . . . . . 27 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 9.1. Normative References . . . . . . . . . . . . . . . . . . . 27 9.2. Informative References . . . . . . . . . . . . . . . . . . 28 Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . . 28 A.1. Streaming Pre-encrypted Media . . . . . . . . . . . . . . 28 A.2. Recording Encrypted Media at Home . . . . . . . . . . . . 28 A.3. Answering Machine . . . . . . . . . . . . . . . . . . . . 28 A.4. Media Rewind . . . . . . . . . . . . . . . . . . . . . . . 28 Appendix B. Test Vector . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Blom, et al. Expires December 24, 2009 [Page 3] Internet-Draft SRTP in Store-and-Forward Applications June 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 extended, as the parameters used in [RFC3711] are available 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. 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, as far as the cryptographic processing is concerned, the SaF middleboxes may use Blom, et al. Expires December 24, 2009 [Page 4] Internet-Draft SRTP in Store-and-Forward Applications June 2009 [RFC3711] compliant processing and changes in cryptographic processing 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 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 "honest-but-curious" in the following sense. A trust B to maintain information I provided by A, and (later) redistribute it to the Blom, et al. Expires December 24, 2009 [Page 5] Internet-Draft SRTP in Store-and-Forward Applications June 2009 intended recipients as specified by A (parties that A trust with I). However, A does not trust that B will not also 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 with I. A is similarly said to have receiver-semi-trust in B, if A trusts B to maintain information intended for A and to (later) distribute this information to A if and only if A so requests. However, A does not trust that B will not also attempt to distribute the information to other parties 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 SRTP cryptographic context concept. 3. The Store-and-Forward Use Cases 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. For each use case, we comment on aspects of the semi-trusted model defined above. Blom, et al. Expires December 24, 2009 [Page 6] Internet-Draft SRTP in Store-and-Forward Applications June 2009 Streaming Pre-encrypted Media: A content creator (S) distributes high value, encrypted content to clients (R). Distribution is made via a streaming server (M). From the content creator's point of view it is important that decrypted (plaintext) content is only made available to authorized clients. This means that S should be able to use a streaming server M, to which it assigns a bare minimum of sender- semi-trust. The clients may typically have some basic privacy requirement related to what type of content they access, but may otherwise be less concerned with whom else that also gets access to the content. 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, awaiting a license for rendering. Here, the trust in the HDD (M) by S and R is probably very asymmetric since the end-user most likely has a very strong trust in his personal home equipment. An additional requirement is the possibility for M to authenticate the data source S in order not to exhaust storage capacity with garbage. 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. In this use case, sender and receiver-semi-trust in M is likely to be fairly symmetric. 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/or 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 Blom, et al. Expires December 24, 2009 [Page 7] Internet-Draft SRTP in Store-and-Forward Applications June 2009 o S trusts R, o S semi-trusts M to deliver information to R, and, o R semi-trusts M to forward any information intended for R. Trust --------------------------------------------> +---+ +---+ +---+ | S | | M | | R | +---+ +---+ +---+ ---------------------> <--------------------- Sender-semi-trust Receiver-semi-trust Figure 1: Trust Model (Sender, SaF Middlebox, Receiver) As noted in the use cases above, S may be more concerned with who gets access to the information than R is. Still, this trust model, assuming a bare minimum of sender- and receiver-semi-trust as defined above, has been chosen since it is a simple trust model and seems to apply (qualitatively) as a common denominator for all the SaF use cases. Note also that the trust between S and R may often be mutual, but we do not require this. 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 the information S provides. 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. Similarly, a more robust implementation of M should have means to authenticate also R in order to avoid wasting resources, responding to spoofed requests. 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 there are several SaF middleboxes in the path between S and R, it is necessary to assume that the 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. Blom, et al. Expires December 24, 2009 [Page 8] Internet-Draft SRTP in Store-and-Forward Applications June 2009 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. As mentioned, hbh cryptographic processing is compatible with SRTP [RFC3711] and therefore also RTCP SHOULD be protected using SRTCP on hbh basis according to [RFC3711]. However, the SRTP SaF extension defined herein makes no provision to provide e2e protection of RTCP also on e2e basis. Relevant considerations (rationale and caveats) relating to RTCP are provided in Section 4.6. 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. 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 constant end-to-end in the SaF scenario, namely SSRC and receiver's IP address and port. The SRTP SaF extension defined in this document addresses these problems. 3.4. Design Rationale As noted above, different SaF scenarios may have slightly different security requirements and trust models and there may be many different possibilities to extend SRTP in different directions to handle a specific SaF use case (or some subset of use cases). For Blom, et al. Expires December 24, 2009 [Page 9] Internet-Draft SRTP in Store-and-Forward Applications June 2009 example, the problems related to the most basic trust model extension (need to provide confidentiality e2e and integrity hbh) are due to the fact that in SRTP, parties always know both the encryption key and the authentication key. This could be addressed (mainly) by just separating encryption and authentication keys (i.e. modifying SRTP key derivation and cryptographic context). However, the solution would then become severely limited, e.g. it would not support pre- encryption of data or re-transmission of stored data. Similarly, as will be seen below, SRTP SaF adds some additional in-band data fields, though some use cases above could probably be handled without them. Again, the solution would be limited to these use-cases and would then not allow e.g. the secure fast-forward/rewind use cases, which requires in-band synchronization data. By making the added fields optional, it is possible to support these features as needed, yet keeping bandwidth low when such features are not needed. This specification is rather based on - identifying the common denominator(s) to the SaF use case problems, captured in the trust model and requirements of Section 3.2 - proposing a single extension of the SRTP framework (see Section 4.1) powerful enough to handle all foreseen SaF use cases, which, by - simple configuration of the extended framework (Section 4.3) can be adopted to support the requirements of the specific SaF use case at hand. Considering that the impacts of the present specification on SRTP are very similar to those of [RFC4383], there does not appear to be any disadvantage in having a single SaF extension compared to having per- SaF-use-case extensions. 4. Usage of SaF Security within SRTP 4.1. The SaF Extension The SaF extension consists of a new packet format (Section 4.3), an extended cryptographic context concept (Section 4.4), and new SRTP processing at sender/receiver (Section 4.5). Considering only the cryptographic processing, SaF middleboxes are compatible with [RFC3711], and the necessary additional processing is defined in Section 4.5.2. Senders/receivers need to support new cryptographic transforms (see Section 4.7). Blom, et al. Expires December 24, 2009 [Page 10] Internet-Draft SRTP in Store-and-Forward Applications June 2009 4.2. Terminology A SaF e2e session is defined as the set of SaF e2e protected data produced under a single e2e context (a security association between sender and the ultimate receiver, see Section 4.3 for the exact 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 produced under a single hbh context (a security association between two entities where at least one entity is a middlebox, see Section 4.3 for the exact definition of e2e context). The cryptographic transforms, keys, etc., used for the e2e and hbh protection, respectively, are denoted e2e transform, hbh transform, e2e key, hbh key, etc. 4.3. 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 e2e encryption of the payload, RTP padding, RTP pad count. The e2e protected portion also defines two new fields (PUV and SSS) for cryptographic synchronization, and an e2e MAC tag field. The e2e MAC tag covers the e2e protected portion, except the e2e MAC tag itself. 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 PUV and SSS as well. Blom, et al. Expires December 24, 2009 [Page 11] Internet-Draft SRTP in Store-and-Forward Applications June 2009 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 (MANDATORY) ~ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | ~ e2e SSS (OPTIONAL) ~ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | ~ e2e MAC (RECOMMENDED) ~ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ | | ~ hbh CCI (OPTIONAL) ~ | | +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-|-+ | ~ hbh MKI (OPTIONAL) ~ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | ~ hbh MAC (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.7.2. The e2e protected portion is opaque from SaF middlebox point-of-view. Thus, by treating the inner e2e protected portion and the Crypto Context Identifier (CCI, see below) as the (hbh) "encrypted portion" of [RFC3711], the overall SRTP SaF packet format 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 Blom, et al. Expires December 24, 2009 [Page 12] Internet-Draft SRTP in Store-and-Forward Applications June 2009 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.7 and 6.2. The implementation of the necessary anti-collision mechanism is outside the scope of this specification. o PUV: Packet Unique Value for the e2e transform. PUV is transform dependent, of configurable length, and MANDATORY. The format is transform dependent and security aspects need to be considered when defining the format, see Sections 6.2 and 6.4. For a given SaF e2e session and SaF source, the PUV SHALL be unique for each generated e2e protected portion. The PUV is used as input to the IV formation for the e2e encryption transform. o e2e MAC: This field is used to carry payload authentication data e2e. It is transform dependent, of configurable length and is RECOMMENDED to be used. Observe that the e2e MAC SHALL cover the RTP payload, the PUV and SSS but SHALL NOT cover the RTP header, nor the CCI. o CCI: Crypto Context Identifier: used to signal hbh, which e2e cryptographic context (keys and other parameters, see Section 4.4.1) to use. The field is OPTIONAL and of configurable length. Parameters which are configurable have default values (see Section 5), and are otherwise negotiated during SaF e2e/hbh session establishment, agreed upon out of band, or hard coded for a specific application. 4.4. Extension of the SRTP Cryptographic Context A SRTP SaF cryptographic context SHALL consist of two main parts. 1. A hbh context. 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 Blom, et al. Expires December 24, 2009 [Page 13] Internet-Draft SRTP in Store-and-Forward Applications June 2009 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. If the context contains more than one e2e context, each e2e context SHALL be associated with a CCI value. Since the length of the CCI field is variable, the length of the CCIs SHALL be determined by a length parameter, n_CCI. 4.4.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, see Section 4.7.2 for the default e2e encryption transform specification, o an identifier for the e2e message authentication algorithm, see Section 4.7.2 for the default e2e message authentication transform specification, o an identifier for the e2e pseudo-random function, 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, n_s, and n_tag determining the length of the e2e session keys for encryption and message authentication, the e2e session salt, and the e2e authentication tag, o non-negative integers n_PUV, and n_SSS determining the length of the PUV, and SSS fields. There may also be need to include e2e transform dependent parameters, see Section 4.7.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.5.3.1. Also note that unlike [RFC3711] cryptographic contexts, the e2e context SHALL only contain parameters for RTP Blom, et al. Expires December 24, 2009 [Page 14] Internet-Draft SRTP in Store-and-Forward Applications June 2009 protection, and SHALL NOT contain parameters for RTCP protection, see Section 4.6. 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.4.2. Identification of e2e Context A SaF context MAY contain several e2e contexts. 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 e2e context MAY be identified by simply transferring the entire context out-of-band. The e2e context MUST be e2e protected so that middleboxes or other unauthorized entities cannot access or modify it. Alternatively, out-of-band context identification may use indirection and SHALL then be defined as follows. Each sender, for each e2e context, defines a Content ID, CID. When used, 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. If the SaF context contains a single e2e context, the in-band context identification SHALL be done as defined in [RFC3711]. Both the hbh context and the e2e context are uniquely identified by the triplet context identifier: The e2e context (either the context itself or its CID) is here implicit from the triplet. Note that different triplets identify the Blom, et al. Expires December 24, 2009 [Page 15] Internet-Draft SRTP in Store-and-Forward Applications June 2009 e2e context on each "hop". If the SaF context contains more than one e2e context, the triplet context identifier cannot uniquely identify the e2e context and the in-band context identifier needs to be extended with the CCI field in the SRTP SaF packet (see Figure 2). The e2e context is uniquely identified by the quadruplet context identifier: The CCI may thus be thought of as a mutant, short, in-band alias for the e2e context (possibly via additional indirection through CID) and is only used on hbh basis. 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. 4.4.2.1. CCI Mapping For each distinct e2e context (provided by the sender or a previous SaF middlebox through direct transfer of the protected context itself or a CID) the SaF middlebox SHALL ensure that when CCIs are used, 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 December 24, 2009 [Page 16] Internet-Draft SRTP in Store-and-Forward Applications June 2009 o-o-b: CID1 +------------------------------------------------------------------+ | o-o-b: CID1 | | +-------------------------+ | | | | o-o-b: (CID1, CCI1), (CID2, CCI2) | +----+ | +---------------------------------+ | | | SRTP SaF | | | | | S1 |------------------+ v | v v | | | +---+ +---+ +----+ +--->| | SRTP SaF: CCI1, CCI2 | | | M |------------------------------>| R | +----+ +--->| | | | | | | +---+ +---+ | S2 |------------------+ ^ ^ | | SRTP SaF | | +----+ | | | | | | | +--------------------------+ | | o-o-b: CID2 | +-----------------------------------------------------------------+ o-o-b: CID2 Figure 3: CCI Mapping The sender S1 wishes to store a message for R on a SaF middlebox M. S1 uses out-of-band (o-o-b) signaling to communicate the Content ID CID1 to R and 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 to transfer the content to M. Later, also S2 stores a message for R on the SaF middlebox M. S2 uses out-of-band signaling to communicate the Content ID CID2 to R and M. S2 then uses SRTP SaF to transfer the content. When R later retrieves the content from M it is multiplexed inside the same hbh 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. It is similarly assumed that sender-middlebox and middlebox-receiver, respectively, agree on the hbh cryptographic context. Blom, et al. Expires December 24, 2009 [Page 17] Internet-Draft SRTP in Store-and-Forward Applications June 2009 4.5. SRTP SaF Processing 4.5.1. Sender The sender SHALL first, out-of-band, establish the necessary CIDs, CCIs and hbh context parameters with the SaF middlebox as discussed above. The rest of sender's processing is identical to [RFC3711] with the following exceptions and extensions. S1 In analogy with step 1 of [RFC3711], the sender SHALL determine both the hbh context and the e2e context as discussed in Sections 4.4.1 and 4.4.2. Next, and prior to performing step 2 of [RFC3711], the sender SHALL perform step S2-S6 as defined below. S2 The sender SHALL from the e2e master key and master salt determine the e2e session key(s)/salt as discussed in Section 4.7.3. S3 The sender SHALL next apply the e2e encryption transform as described in Section 4.7.2. S4 The sender SHALL next apply the e2e authentication transform as described in Section 4.7.2 applying the e2e session key(s)/salt of step S2 to the result of S3 concatenated by the PUV, and the SSS. S5 The sender SHALL then form the e2e protected portion of the SRTP SaF packet by concatenating the result of S3, the PUV, the SSS and the tag from S4. S6 The sender adds the CCI (if used), 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.5.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. Generally, the SaF middlebox SHALL first, out-of-band, establish the necessary CIDs, CCIs, and hbh context parameters with the source or destination as discussed above. Blom, et al. Expires December 24, 2009 [Page 18] Internet-Draft SRTP in Store-and-Forward Applications June 2009 4.5.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 be able to map the correct content to the intended receiver, e.g. e2e context, the CID, or 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 portion of the packets (corresponding to Figure 2) and to allow the receiver to uniquely identify the correct e2e context, e.g. by storing the CID or the e2e context. 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.5.2.2. Acting as Sender ("Forward") MS1 When forwarding media to the receiver, the SaF middlebox SHALL retrieve the correct hbh context as specified in [RFC3711]. MS2 A payload SHALL be formed consisting of the e2e protected portion and, if used, 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.5.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 to 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.5.2.2. M2 SHALL act as a SaF middlebox receiver (Section 4.5.2.1). Blom, et al. Expires December 24, 2009 [Page 19] Internet-Draft SRTP in Store-and-Forward Applications June 2009 4.5.3. Receiver R1 The receiver SHALL first, out-of-band, establish the necessary CIDs, CCIs and hbh context parameters with the SaF middlebox as discussed above. R2 Step 1 to 8 of [RFC3711] SHALL then applied, using the hbh context to perform hbh processing. 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 portion 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.4.2. (In case the CCI was NOT used or 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.7.3 using the e2e master key and salt. R5 The receiver SHALL verify authentication and decrypt the e2e protected portion as specified by the e2e transform(s), see Section 4.7.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 PUV, SSS, e2e MAC, and CCI as appropriate. 4.5.3.1. Replay Protection For reasons discussed in Appendix A, it is in general not meaningful or desirable to provide application independent replay protection for the e2e part. Some of the identified use cases make this clear by having a requirement that the receiver should be able to jump back/ forward in the e2e media stream. See Section 6.5 for security considerations. 4.6. Use of SRTCP with SRTP SaF SRTCP protection SHALL be provided hbh, conforming to [RFC3711], and SHALL NOT be provided e2e, as this covers most/all use cases currently identified. Further RFCs may specify additional e2e Blom, et al. Expires December 24, 2009 [Page 20] Internet-Draft SRTP in Store-and-Forward Applications June 2009 functionality for SRTCP SaF. As noted, it may still be beneficial to forward information from some of the inbound RTCP messages (from S to M) in the outbound RTCP (from M to R). Also note that 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.7. 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.7.1. Default hbh Transforms The hbh protection may reuse any of the existing SRTP transforms such as those defined in the original specification [RFC3711], or, transforms that have been added later. By default the NULL encryption algorithm, the HMAC-SHA1 authentication algorithm and the AES-CM pseudo-random function SHALL be used. 4.7.2. Default e2e Transforms The sender SHALL first apply the e2e encryption transform and then the e2e authentication transform. The default e2e encryption transform SHALL be 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 key and salt, see Section 4.7.3) and where SSS and 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 24 bits and the maximum allowed size for AES counter mode SHALL be 48 bits. 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 be 64 bits. The key used SHALL be the session encryption key k_e (derived from Blom, et al. Expires December 24, 2009 [Page 21] Internet-Draft SRTP in Store-and-Forward Applications June 2009 the e2e master key and salt, see Section 4.7.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 field. The resulting MAC tag SHALL be inserted in the e2e MAC field. The key used SHALL be the session authentication key k_a (derived from the e2e master key and salt, see Section 4.7.3). The default e2e pseudo-random function SHALL be AES-CM as defined in [RFC3711], Section 4.3.3. 4.7.3. Session Key Derivation 4.7.3.1. Session Keys for hbh Processing For the hbh security processing, session key derivation SHALL be done exactly as in [RFC3711] using the hbh master key and hbh salt. 4.7.3.2. Session Keys for e2e Processing For the e2e security processing the key derivation is also identical to [RFC3711] with the following exceptions o The e2e master key and e2e salt, SHALL be used together with the defined labels of [RFC3711] for derivation of the different keys. 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 for master and session key lengths are 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 parameters: o n_PUV: 24 bits. Blom, et al. Expires December 24, 2009 [Page 22] Internet-Draft SRTP in Store-and-Forward Applications June 2009 o n_SSS: 0 bits (not used) o n_CCI: 0 bits (not used) 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 PUV field and, if used, for the SSS field. An authentication transform MUST define how the e2e MAC 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. 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 three new in-band parameters, PUV, CCI, and SSS, are specified. Note that CCI and SSS 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. Blom, et al. Expires December 24, 2009 [Page 23] Internet-Draft SRTP in Store-and-Forward Applications June 2009 6.2. Keystream Reuse A main concern of [RFC3711] is to avoid keystream reuse. This concern is present also here. The currently defined encryption transforms are additive stream ciphers which are sensitive to keystream reuse. It is therefore RECOMMENDED that each session utilizes random, cryptographically independent e2e and 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 encryption transform such reuse will only be secure if the sender and receiver keep state to prohibit reuse of IVs. Another situation when key reuse may be beneficial is if sender and receiver use the SaF middlebox in a "chat-like" fashion (with 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 ensure that unique SSS values are used each time the same e2e master key is reused. For the bidirectional case (as well as for the more general case where a group key is used as e2e 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 values 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 sessions is, just as in [RFC3711], therefore NOT RECOMMENDED. 6.3. Attacks on CCIs The CCI values are not e2e integrity protected as they only exist hbh. SaF middleboxes are semi-trusted which implies that they are assumed to (at least) forward data as requested by the sender/receiver. A Blom, et al. Expires December 24, 2009 [Page 24] Internet-Draft SRTP in Store-and-Forward Applications June 2009 middlebox providing incorrect CCI mappings therefore falls outside the trust model. Nevertheless, even if a SaF middlebox is malicious beyond our assumptions, there seems to be only two attacks that can be launched by such a middlebox, and where said attacks are either detectable, or, will have only DoS effects. First, using incorrect CCI mappings, the middlebox may attempt to claim to the receiver that data comes from another sender. This will be detected by the (RECOMMENDED) use of the e2e authentication. Second, the middlebox could simply make data unintelligible for the receiver by providing "random" incorrect CCI mappings, causing the receiver either be unable to process the e2e protected media, or, doing so using incorrect context/keys, thereby producing "garbage" after decryption of the e2e part. An outsider (non-middlebox) may attempt to modify CCIs. This would be a DoS attack which would be mitigated 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 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 Blom, et al. Expires December 24, 2009 [Page 25] Internet-Draft SRTP in Store-and-Forward Applications June 2009 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 replay or reorder 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 PUV (as the default e2e transform does). It then becomes infeasible even 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 Key management is outside the scope of this specification which is an intentional design choice in order not to introduce any dependency on using a specific key management scheme. Nevertheless, 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 keys 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 fresh, 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 a SaF middlebox to deliver the correct media (produced with the correct e2e context) to the receiver, some SaF applications may choose to store information regarding the identity of the sender and will be able to deduce the communication taking part between the two. Blom, et al. Expires December 24, 2009 [Page 26] Internet-Draft SRTP in Store-and-Forward Applications June 2009 To enhance privacy, senders/receivers may use agreed pseudonyms or other similar Privacy Enhancing Techniques (PET)s. One such technique is to use (random) CIDs to identify media and to follow the recommendation and assign random CCIs on each hop where CCIs are used. Complete anonymity may be in conflict with the requirement that the SaF middlebox needs protection from flooding by garbage or other forms of unwanted traffic. When hbh encryption is configured additional protection against 3rd party traffic analysis is provided since the CCIs are 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. As noted though, it may still be useful to forward e.g. sender reports to the receiver using hbh RTCP protection. 7. Acknowledgements The authors would like to thank Magnus Westerlund for his support and valuable comments. We are also grateful to Eric Rescorla for his feedback when reviewing version 00 of this draft. 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. Blom, et al. Expires December 24, 2009 [Page 27] Internet-Draft SRTP in Store-and-Forward Applications June 2009 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 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 leave messages protected by different e2e keys. As discussed in the SRTP SaF specification, 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 Blom, et al. Expires December 24, 2009 [Page 28] Internet-Draft SRTP in Store-and-Forward Applications June 2009 wish to listen once again to a message left in a voice mail without terminating and reinitiating the session with the SaF middlebox. Appendix B. Test Vector The parameters are chosen to be typical for a voice call. A frame size of 32 bytes is used by AMR 12.2 (Adaptive Multi-Rate) and with 20 ms speech frames, a PUV length of 24 bits equals 93.2 h. A 32-bit MAC offers good integrity protection for a voice call. The 16 bit SSS is not typical but is included to make the test vector more general. Encryption algorithm: AES-CM Authentication algorithm: HMAC-SHA-1 Pseudo Random Function: AES-CM n_e (encr session key length): 128 n_a (auth session key length): 160 n_s (session salt key length): 112 n_PUV (Packet Unique Value length): 24 n_SSS (SRTP SaF Source length): 16 n_tag (Authentication tag length): 32 The values below are in hexadecimal. e2e Master key (128 bits) 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f e2e Master salt (112 bits) 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d e2e Session encryption key (128 bits) 12 ed 05 3a f7 8c 9a f2 96 5c 64 26 f4 d1 56 23 e2e Session authentication key (160 bits) 73 0c 3c ac 1d 75 27 36 91 97 d4 ab c2 b4 6b 46 cd e0 19 83 e2e Session salting key (112 bits) eb 31 d1 cb af 09 68 cd 14 f2 2b be 35 18 Packet Unique Value (24 bits) 80 81 82 SRTP SaF Source (16 bits) c0 c1 Blom, et al. Expires December 24, 2009 [Page 29] Internet-Draft SRTP in Store-and-Forward Applications June 2009 Payload (256 bits) 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e2e Protected Portion (328 bits) 82 37 69 bd f8 9c f3 61 57 e4 3d 74 b7 e6 07 4b 05 80 52 ec 7d 68 72 63 b2 e1 10 ae b9 7b 7c a0 80 81 82 c0 c1 bd ab 1e f6 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 Blom, et al. Expires December 24, 2009 [Page 30] Internet-Draft SRTP in Store-and-Forward Applications June 2009 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 December 24, 2009 [Page 31]