Network Working Group R. Blom Internet-Draft Y. Cheng Intended status: Standards Track F. Lindholm Expires: January 8, 2009 J. Mattsson M. Naslund K. Norrman Ericsson Research July 7, 2008 SRTP Store and Forward draft-mattsson-srtp-store-and-forward-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 January 8, 2009. Abstract The Secure Real-time Transport Protocol (SRTP) transforms were designed to allow simple and efficient protection of RTP. To provide this, encryption and authenticity of media and control signaling are tightly coupled to the RTP session, and to the information in the RTP header. Hence, it is not possible to perform store and forward of protected media. This document gives, based on a use case analysis, requirements that Blom, et al. Expires January 8, 2009 [Page 1] Internet-Draft SRTP Store and Forward July 2008 new SRTP transforms need to satisfy in order to allow independent media and transport protection. A first proposal on how to implement such transforms in SRTP is also presented. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Trust Model and Assumptions . . . . . . . . . . . . . . . 4 3.2. Use Case: Answering Machine . . . . . . . . . . . . . . . 4 3.2.1. Storing/Caching Encrypted Media . . . . . . . . . . . 4 3.2.2. Transport Protection . . . . . . . . . . . . . . . . . 5 3.2.3. Playback of Media Stream . . . . . . . . . . . . . . . 5 3.2.4. Multiple Callers . . . . . . . . . . . . . . . . . . . 5 3.3. Use Case: Centralized Conferencing . . . . . . . . . . . . 6 4. Analysis and Requirements . . . . . . . . . . . . . . . . . . 6 4.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 5. Solution Proposal . . . . . . . . . . . . . . . . . . . . . . 8 5.1. SRTP Cryptographic Contexts . . . . . . . . . . . . . . . 8 5.2. New Transforms . . . . . . . . . . . . . . . . . . . . . . 10 5.2.1. Encryption Part . . . . . . . . . . . . . . . . . . . 10 5.2.2. Authentication Part . . . . . . . . . . . . . . . . . 11 5.2.3. Replay Protection . . . . . . . . . . . . . . . . . . 12 5.3. Key Derivation . . . . . . . . . . . . . . . . . . . . . . 12 6. Example Usage . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Implications on SRTP . . . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8.1. Encryption Transform . . . . . . . . . . . . . . . . . . . 13 8.2. Replay Protection . . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 11.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 17 Blom, et al. Expires January 8, 2009 [Page 2] Internet-Draft SRTP Store and Forward July 2008 1. Introduction The Secure Real-time Transport Protocol (SRTP) [RFC3711] is a profile of the Real-time Transport Protocol (RTP) [RFC3550], which provides confidentiality, message authentication, and replay protection to both RTP and RTCP (Real-time Transport Control Protocol). SRTP is designed with the assumption that each participant in the SRTP session is equally trusted. This implies that all participants in the SRTP session have access to all keying material needed to encrypt/decrypt and authenticate the media. It is well known that this model does not apply to all real-world use cases. In particular the presence of middle boxes that are not trusted with access to cleartext media, but need to manipulate e.g. the RTP headers, poses a problem. This document describes a couple of use cases focused on streaming media where at least one of the participants does not have access to all the keying material. The main use case used to derive requirements is an answering machine that is storing encrypted media and later forwarding it to clients. This use case is selected as it seems to require the most from a functional point of view even though other media store and forward applications might be of greater practical importance. One important use case is a non-trusted server streaming pre-encrypted media. As the SRTP was not designed with such a use case in mind, SRTP cannot readily be used. Other methods like the Packet-switched Streaming Service (PSS) [3GPP.26.234] exist, but are part of larger frameworks tailored for very specific situations. It would however be desirable to be able to use SRTP as a general lightweight mechanism in many of these cases. To achieve this, SRTP needs enhancements that support the use cases in an efficient and coherent way. This draft lists a number of requirements for these use cases, and based on these requirements, a brief solution outline is given. 2. Terminology 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]. Definitions of terms and notation will, unless otherwise indicated, be as defined in [RFC3711]. The term authentication will be used to denote message authentication and message integrity protection. Blom, et al. Expires January 8, 2009 [Page 3] Internet-Draft SRTP Store and Forward July 2008 By RTP transport protection or simply transport protection, we mean protection (confidentiality, authentication, etc.) of streamed RTP packets. This is provided by SRTP according to [RFC3711]. By media protection, we similarly mean protection of the application payloads carried in RTP. SRTP provides media protection, but only during transport (see above). 3. Use Cases The following use cases were chosen to illustrate media streaming scenarios where the current SRTP specification [RFC3711] does not provide sufficient functionality. These use cases provide context and general rationale for the requirements presented in Section 4. 3.1. Trust Model and Assumptions The trust model that is addressed in this document includes two parties who wish to communicate securely via one or more honest but curious middle-boxes. This means that the communicating parties trust the middle-box to deliver the media as expected, but they do not trust it with cleartext data. As can be seen from the use cases below there is no example of multiple middle-boxes, but it is a natural generalization and it seems warranted to cover this case as well. 3.2. Use Case: Answering Machine 3.2.1. Storing/Caching Encrypted Media Operators commonly provide an answering machine service to their customers. In this case the communicating parties (the caller and the callee) may not wish to disclose the media to any other party, and hence want to apply encryption between each other. This requires that they are able to establish a shared key; how that is accomplished is out of scope for this document. The answering machine acts as a store and forward middle-box, which has to store encrypted data and re-transmit it to the callee. The answering machine, acting as a streaming server when sending the data to the callee, will not use the exact same RTP headers on the outgoing SRTP traffic as was used on the incoming SRTP traffic. SRTP as specified in [RFC3711] will not work in this case, since parts of the RTP header is input to the encryption/authentication transforms. Blom, et al. Expires January 8, 2009 [Page 4] Internet-Draft SRTP Store and Forward July 2008 3.2.2. Transport Protection To avoid that the answering machine is filled up with bogus data, it is still necessary for the answering machine to authenticate the sender of the traffic, and further, to verify the authenticity of the incoming traffic. This poses a problem for SRTP as of [RFC3711] in that the message authentication requires a session key shared with the answering machine, but the encryption key shall as discussed above not be available to it. When the callee retrieves the media from the answering machine, message authentication is also beneficial. There are two possibilities. Since the answering machine is trusted not to actively behave maliciously, it may be sufficient to provide message authentication between the answering machine and the callee. Also here it would be necessary to have a separation between the encryption key and authentication key. The second option is that authentication is applied from the caller to the callee. But if the authentication is applied in that way, the answering machine will not be able to verify the integrity of the incoming traffic from the caller. It is of course also possible that message authentication is desired for any combination of endpoints, i.e. between the caller and the callee, between the caller and the answering machine, and between the answering machine and the callee. Again, how the key management is handled is out of scope for this document. 3.2.3. Playback of Media Stream When a user listens to the messages stored on the answering machine, it is useful to be able to rewind and/or fast forward in the media stream. For SRTP as of [RFC3711] this is not possible. The reason for that is that even if the same payloads can be re-inserted in the stream by the answering machine, the RTP sequence number is steadily increasing on a per packet basis. Since the synchronization of the encryption transforms is based on the RTP sequence number, the decryption will fail. In addition, message authentication (no matter which option described in Section 3.2.2 is used), will fail since the authentication according to [RFC3711] shall cover the header of the RTP packet. 3.2.4. Multiple Callers Several messages may be left on the answering machine, received in different sessions and possibly from different callers. The result of this is that different keys were used to encrypt the media. Depending on how the callee retrieves the messages from the answering Blom, et al. Expires January 8, 2009 [Page 5] Internet-Draft SRTP Store and Forward July 2008 machine, different options are possible. One option is to retrieve each message as a separate stream, and in this case a separate session is required per message. Another option is to somehow switch security contexts midstream. 3.3. Use Case: Centralized Conferencing Another use case is a conference bridge that is not to be trusted with the cleartext media. In this case the conference bridge cannot act as a mixer, but in some cases this may be a reasonable assumption. An example is Push-To-Talk solutions, where only one user at a time is allowed to talk. In this setting, the media may be re-packaged by the conferencing server into RTP packets with different headers compared to the incoming traffic. As described in Section 3.2, this causes authentication and decryption to fail in SRTP. 4. Analysis and Requirements There are thus a number of issues with the current SRTP when it comes to its use in store and forward applications: o All current SRTP transforms use the RTP header as input. AES-CTR uses the SSRC and the packet index to calculate the IV (Initialization Vector), AES-f8 uses even more header parameters, and HMAC-SHA1 authenticates the full RTP header. The SSRC is typically determined by the key management protocol and the packet index includes the RTP sequence number, which is randomly chosen by RTP [RFC3550]. This means that it is impossible to retransmit protected packets in a standard compliant way. o Even if SSRC and the SRTP index could be determined beforehand, allowing a client to randomly seek in a stream without renegotiation would lead to misalignment between the packet index used when streaming and the one used during pre-encryption. If the user jumps to a different part of the stream, it is impossible to continue increasing the RTP sequence number stepwise while at the same time keeping it equal to the sequence number needed for decryption. Jumping backward (e.g. media rewind) would cause even more problems as the retransmitted packets would be discarded by the SRTP replay protection. o Both the encryption key and the authentication key are derived from the same master key in SRTP, see Figure 1. A client able to derive the authentication keys must have access to the master key, and can therefore also derive the decryption keys. Blom, et al. Expires January 8, 2009 [Page 6] Internet-Draft SRTP Store and Forward July 2008 Packet index -------+ | v +------------+ +------------+ Session encr_key | | Master key | +------------------> | External +---------------->| Key | Session auth_key | Key | | Derivation +------------------> | Management +---------------->| | Session salt_key | | Master salt | +------------------> +------------+ +------------+ Figure 1: SRTP key derivation 4.1. Requirements Based on the use cases and the analysis above, the required enhancements needed to support the use cases in an efficient way are: o Transport independent media protection To allow retransmission of received protected media, a transform that is independent of RTP transport parameters is needed. The media protection MUST cover both message authentication and confidentiality protection. o Support of playback of protected media streams A client SHALL be able to rewind, fast forward or jump to any point in a protected media stream. Note that as playback functions like retransmission and random seek capability is features in the described use cases; replay protection can not be required for transport independent media protection. The option to simply disable authentication all together is not an attractive solution. It SHOULD be possible provide (source) authentication of the media stream. o Transport protection It SHALL be possible to provide transport protection which is independent of the media protection. The transport protection MUST be able to provide confidentiality, authentication, and replay protection for RTP and at least authentication and replay protection for RTCP. This requirement maps well against the SRTP as of [RFC3711]. Transport protection is also a means to provide replay protection of the media. Blom, et al. Expires January 8, 2009 [Page 7] Internet-Draft SRTP Store and Forward July 2008 o Separation of security contexts It MUST be possible to have independent security contexts for the transport independent media protection and the transport protection. o Change of transport independent media protection security context To allow multiplexing of protected media "clips" using different transport independent media protection security contexts into a single media stream, it MUST be possible to signal to the receiver the security context to use. 5. Solution Proposal The stated requirements above seem possible to meet with two proposed additions to SRTP. Both address the issue of the current SRTP transforms' dependence on the RTP packet header. As mentioned, in SRTP [RFC3711] the RTP header is used in IV formation for encryption/decryption and the authentication transform protects the entire packet from modification, creating a cryptographic "binding" between payload and RTP header; without the original RTP header, the payload itself cannot be authenticated. When SRTP transport protection is applied hop-by-hop (hbh), this implies problems to simultaneously protect the payload end-to-end (e2e), e.g. in the scenarios above, and to provide protection (e.g. authentication) for each hop. The first proposed addition is therefore a new encryption and authentication transform similar to the current AES-CTR/HMAC transforms, but with different IV formation and coverage. As a side effect of this new transform, a new key derivation transform is also needed. We also discuss how other components such as replay protection would work. Before discussing these transforms, however, we discuss how to implement the trust model above, which is very much about access to keys, i.e. a key management issue. 5.1. SRTP Cryptographic Contexts SRTP maintains a cryptographic context, containing master key(s), cryptographic transforms, etc., for the associated SRTP session. Exactly how the parameters in the cryptographic context are agreed is out of scope of SRTP and is a key management issue. SRTP assumes that a cryptographic context or rather the master key therein is Blom, et al. Expires January 8, 2009 [Page 8] Internet-Draft SRTP Store and Forward July 2008 shared only between mutually trusted parties. The SRTP cryptographic context concept is reusable for the use cases above. Conceptually, two mutually trusted parties can share an "e2e context". Between an endpoint and an intermediary (or between two intermediaries) a "hbh context" is similarly assumed. The requirement to implement the trust model of the use cases above is that the master key(s) in any e2e context MUST be independent and MUST NOT be possible to deduce from the master key of any hbh context. The key management protocol used MUST therefore be able to negotiate keys satisfying these requirements. This means that the sender will use two cryptographic contexts: an e2e context used for payload protection to the end-receiver, and, a hbh context used to secure the SRTP transport to the (first) intermediary. Similarly, the end-receiver will use two contexts. An intermediary node however, will only use one standard SRTP context. In other words, an e2e context is used to achieve media protection as required in Section 4, and a hbh context similarly is used to achieve transport protection. For both e2e and hbh contexts, it is assumed that SRTP cryptographic context parameters, such as master key and salt are included. From these, SRTP session keys/salts are derived similarly to [RFC3711] (see also below). Note that it would be possible to avoid dual SRTP contexts by instead using distinct master keys for encryption and authentication; this would allow encryption e2e and authentication hbh in the above trust model. However, since it may also be desirable to be able to encrypt hbh, it appears more flexible to use distinct contexts. Other aspects such as replay protection (see below) also speak in favor of using "standard", but dual SRTP contexts, rather than extending the SRTP context definition itself. e2e_context (payload protection) <-----------------------------------> +---+ +---+ +---+ | S | | M | | R | +---+ +---+ +---+ <---------------> <-----------------> hbh_context1 hbh_context2 ^ ^ | | +- transport protection -+ Figure 2: Context sharing (Sender, Middlebox, Receiver) Blom, et al. Expires January 8, 2009 [Page 9] Internet-Draft SRTP Store and Forward July 2008 If several senders' payloads are multiplexed within the same SRTP stream from a server to a receiver (as discussed in Section 3.2.4) there may be need for the receiver to switch between e2e contexts in "midstream". This seems possible to implement using the SRTP MKI field which signals which key(s) to use. The hbh context would, however, not be affected by the change in the MKI field. 5.2. New Transforms We present the new transform as an authenticated encryption mode for transport independent media protection. That is, both confidentiality and authenticity are provided by the same transform. If for some reason these security services are needed independently, it is easy to see how to separate the encryption part from the authentication part and handle them as separate transforms. 5.2.1. Encryption Part The new encryption transform may for instance use AES in counter mode. (This would enable reuse of parts of already existing SRTP implementations.) However, the new transform derives the IV in a different way than the current AES-CTR transform [RFC3711]. The 128-bit IV is proposed to be constructed from the session salt, a nonce (signaled out of band before the streaming begins), and an IV sequence number (IVSN), included in each SRTP packet. The nonce is added to replace the SSRC that guaranteed stream-uniqueness of the IV, and the IVSN replace the packet index that guaranteed packet- uniqueness. Session encr_key Session salt_key | | | | V V +----------------+ +-----------+ +-----------+ | RTP |-------\| AES-CTR |<--------+ f |<----+ | Payload |-------/| | IV | | | +----------------+ +-----------+ +-----------+ | || ^ | \/ | Nonce +----------------+------+ | | Encrypted | IV |<-----+ | Payload | SN | \ +----------------+------+ IVSN ^ ^ Encrypted portion ---+-----------------------+ of SRTP packet Blom, et al. Expires January 8, 2009 [Page 10] Internet-Draft SRTP Store and Forward July 2008 Figure 3: New encryption transform The IVSN increases by one for each encrypted packet and is concatenated to the encrypted payload and the SRTP payload would therefore be larger than the RTP payload. See Figure 3. The choice of the function f should be decided by futher study. Note that although the IVSN is not encrypted, it is conceptually considered part of the output of the new transform, i.e. part of the "Encrypted portion". On the receiver side, the IVSN is extracted from the received packet and is used to retrieve the original RTP Payload in the obvious way. 5.2.2. Authentication Part The new authentication transform may for instance be based on HMAC- SHA1 just as the default authentication transform of [RFC3711] is. The main difference is that it only covers the "Encrypted portion" including the IVSN, see Figure 3, but not the RTP header. Another difference is that no explicit replay protection is provided by this transform. Figure 4 shows the format. Session auth_key | | V +-----------------------+ +-----------+ | Encrypted |----------\| HMAC | | Portion (Fig 3) |----------/| SHA1 | +-----------------------+ +-----------+ || || || \/ || +-----------------------+------+ |+--\ | Encrypted | TAG | +---/ | Portion | | +-----------------------+------+ ^ ^ Authenticated ------+-----------------------+ portion of SRTP packet Figure 4: New authentication transform The RTP header and optionally a MKI is then added before the packet is further processed and transmitted. The order (applying authentication after encryption) is proposed to agree with current SRTP and best common practice (limit of DoS Blom, et al. Expires January 8, 2009 [Page 11] Internet-Draft SRTP Store and Forward July 2008 effects etc). The processing on the receiving side is not discussed, but is straight forward. A new identifier for the above authenticated encryption transform is needed. In the sequel we simply denote it T_e2e (end-to-end transform). 5.2.3. Replay Protection When the RTP data is also hbh transport protected by SRTP between server and receiver, replay protection on the transport level is provided. As mentioned, it is assumed that the server is trusted not to attempt replay of data on media level, unless the user requests it and thus, this is in line with the trust model. 5.3. Key Derivation Session key derivation (and optional key refresh) for the hbh context is performed as in [RFC3711] and is based on SRTP 48-bit index. When deriving keys for the T_e2e transform, the IVSN SHALL be used instead of the SRTP index. In practice, this means that we have defined a new key derivation transform to be used for the e2e context. 6. Example Usage Suppose that a sender, S, wants to send information to a receiver, R, via an intermediary, M. 1. S agrees with R on an e2e context. The context has a master key, k_e2e, and is configured to use the new transforms described in Section 5. How this is done/signaled (which key management protocol to use etc.) is out of scope. It could be done using e.g. MIKEY [RFC3830]. 2. S sets up an SRTP session with M to have data forwarded to R. A hbh context containing a key, k_hbh, is (somehow) agreed between S and M. The context is assumed configured to use HMAC (standard HMAC-SHA1 as in [RFC3711]) for transport authentication and, say, NULL encryption. 3. S starts to transmit SRTP towards M, in effect using T_e2e and k_e2e for encryption and k_hbh for authentication. (The result of this is that the payload will be SRTP e2e protected both for Blom, et al. Expires January 8, 2009 [Page 12] Internet-Draft SRTP Store and Forward July 2008 authenticity and confidentiality, whereas the entire SRTP-packet will hbh transport protected for authenticity between S and M.) 4. M, recognizing that it is an intermediary for S<->R (i.e. due to out-of-band signaling or from the fact that it does not have access to the e2e context/key) verifies authenticity of each SRTP packet, but does not decrypt the payloads, and just stores them for later use. 5. At some later time, R sets up an session with M, using SRTP with NULL encryption and standard HMAC for transport protection. A second context/key, k_hbh', is agreed/used. 6. M uses SRTP with HMAC and k_hbh' to transmit authenticated data to R. 7. When receiving SRTP packets, R verifies transport authenticity using HMAC and k_hbh'. R then uses T_e2e with k_e2e to process the payload part. 7. Implications on SRTP As the SRTP specification allows new transforms, the new transforms can be added without any implications. The handling of dual security contexts (in the end-points) is however a new feature. 8. Security Considerations 8.1. Encryption Transform Any fixed keystream output, generated from the same inputs (i.e. key and IV) MUST only be used to encrypt once. Reusing such a keystream (commonly called a "two-time pad") would almost certainly compromise security. The new encryption transforms accomplish packet-uniqueness by including the IVSN and stream-uniqueness by inclusion of a nonce. Thus, the nonce MUST be unique between all the RTP streams within the same RTP session that share the same master key. Master keys MAY be shared between streams belonging to the same RTP session, but it is RECOMMENDED that each stream have its own master key. With these conditions fulfilled the security level should be equal to that of [RFC3711]. Blom, et al. Expires January 8, 2009 [Page 13] Internet-Draft SRTP Store and Forward July 2008 8.2. Replay Protection Replay protection is only provided on hbh basis, which means that a malicious server could "initiate" rewind without the user having requested it. However, this threat falls outside the assumed trust model. Another case when retransmission on e2e level seems needed is for the "answering machine" type of applications where users often go back and listen to the same message several times, without re-initiating the connection. 9. Acknowledgements The authors would like to thank Daniel Catrein, Frank Hartung, and Magnus Westerlund for their support and valuable comments. 10. 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. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. 11.2. Informative References [3GPP.26.234] 3GPP, "Transparent end-to-end Packet-switched Streaming Service (PSS); Protocols and codecs", 3GPP TS 26.234 7.5.0, March 2008. Blom, et al. Expires January 8, 2009 [Page 14] Internet-Draft SRTP Store and Forward July 2008 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004. Authors' Addresses Rolf Blom Ericsson Research SE-164 80 Stockholm Sweden Phone: +46 8 585 317 07 Email: rolf.j.blom@ericsson.com Yi Cheng Ericsson Research SE-164 80 Stockholm Sweden Phone: +46 8 568 674 22 Email: yi.cheng@ericsson.com Fredrik Lindholm Ericsson SE-126 37 Hagersten Sweden Phone: +46 8 585 317 05 Email: fredrik.lindholm@ericsson.com John Mattsson Ericsson Research SE-164 80 Stockholm Sweden Phone: +46 8 404 35 01 Email: john.mattsson@ericsson.com Blom, et al. Expires January 8, 2009 [Page 15] Internet-Draft SRTP Store and Forward July 2008 Mats Naslund Ericsson Research SE-164 80 Stockholm Sweden Phone: +46 8 585 337 39 Email: mats.naslund@ericsson.com Karl Norrman Ericsson Research SE-164 80 Stockholm Sweden Phone: +46 8 404 45 02 Email: karl.norrman@ericsson.com Blom, et al. Expires January 8, 2009 [Page 16] Internet-Draft SRTP Store and Forward July 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Blom, et al. Expires January 8, 2009 [Page 17]