MMUSIC R. Raymond Internet-Draft CounterPath Solutions, Inc. Expires: April 19, 2006 D. Wing Cisco Systems October 16, 2005 Security Descriptions Extension for Early Media draft-wing-mmusic-sdes-early-media-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 April 19, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document extends security descriptions to allow early media to be received and decrypted. This extension is useful when security preconditionss isn't used. Raymond & Wing Expires April 19, 2006 [Page 1] Internet-Draft Security Descriptions Early Media October 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Usage with MKI . . . . . . . . . . . . . . . . . . . . . . 4 4. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Offer and Accepted Answer . . . . . . . . . . . . . . . . 5 5.2. Answerer Doesn't Understand "req:" . . . . . . . . . . . . 5 5.3. Offer With Multiple Crypto Suites . . . . . . . . . . . . 6 5.4. Offer With Multiple Keys . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 8.2. Informational References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Raymond & Wing Expires April 19, 2006 [Page 2] Internet-Draft Security Descriptions Early Media October 2005 1. Introduction Security Descriptions [5] provides a mechanism to indicate SRTP keys in SDP[3]. In Security Descriptions, the transmitter indicates the key used to transmit their RTP or RTCP packets. In the SDP offer/answer model [6], without security preconditions [4], an answerer might begin transmitting SRTP media towards an offerer before the offerer has received the answer containing the SRTP keys necessary to decrypt the SRTP stream. This is called 'early media' [7]. This document provides an extension to security descriptions which allows the offerer to decrypt this early media without requiring the offerer or answerer to implement security preconditions. 2. Requirements Language 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 RFC 2119 [1]. 3. Mechanism A new security descriptions session parameter "req", indicates the offerer is requesting that the answerer use a specific key and salt for encrypting RTP and RTCP traffic the answerer transmits. An offer MAY contain the session parameter "req". If the answerer is willing to use this requested key parameter (key, salt, MKI, lifetime) and SRTP session parameters (KDR, FEC_ORDER, etc.) as indicated the offer, the answerer can establish its SRTP crypto context using that infomation, begin sending SRTP packets immediately, and generate an answer indicating it accepted these SRTP key parameters and SRTP session parameters. An answer MUST NOT contain the session parameter "req". If the offerer receives SRTP packets before receiving the answer, the offerer SHOULD assume the answerer supports the extension described in this document and attempt to authenticate the incoming SRTP packet. If the packet is authenticated the early media can be played to the user. If the packet doesn't authenticate, the answer will need to be received before the packet can be processed. This will be the situation if the answerer doesn't support the extension described in this document, the answerer rejected the offered key parameters or session parameters. Typically, in a case where early media is Raymond & Wing Expires April 19, 2006 [Page 3] Internet-Draft Security Descriptions Early Media October 2005 received and can't be authenticated, the SRTP packet will simply be discarded. The technique described in this document is valuable if the answerer sends early media and if the offerer and answerer both use SRTP authentication. 3.1. Usage with MKI Some implementations may find MKI to be useful when offering multiple crypto-suites to identify which crypto-suite was chosen by the answerer before the answer arrives. For example, an offer might contain several a=crypto lines for one media line, and each a=cryto line might offer a different crypto suite and a different MKI. When the offerer receives an SRTP packet before receiving the answer, the offerer can determine which a=crypto line was selected by the MKI value of the arriving packets. To provide this functionality, the answerer MUST use the same MKI value of the first key of the selected a=crypto line in the offer; if no MKI is present in the offer, the answerer MUST NOT use use an MKI for its early media. If the offer contained MKI and the answerer chooses to generate its own key (that is, it doesn't use the requested key), the answerer SHOULD use a different MKI value than any of the a=crypto lines for that media stream; by doing this the offerer avoids attempting to authenticate early media until the answer arrives. As MKI incurs some per-packet overhead it is often desirable, after a successful offer/answer exchange, to send packets without MKI. To accomplish this, another offer should be generated with the same a=crypto parameters but without an MKI. When this new offer is accepted, the offerer and answerer can send SRTP packets without MKI, thus conserving bandwidth. In order for early media to be decrypted, an offer MUST have the same MKI length for all a=crypto lines of a media stream. 4. ABNF Security Descriptions [5] is extended to allow the offerer to suggest a key for the answerer to use. Following the ABNF [2] in Security Descriptions, the following new session parameter is defined: srtp-session-extension = "req:" key-salt Raymond & Wing Expires April 19, 2006 [Page 4] Internet-Draft Security Descriptions Early Media October 2005 5. Examples In all of the examples below, long a=crypto lines are shown split into separate lines with indentation due to formatting restrictions of this document. 5.1. Offer and Accepted Answer This is an offer with the extension described in this document. v=0 ... m=video 51372 RTP/SAVP 31 a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 req:s0GbsbrbKRhetTr3FVOxCLeKAUYwFM1ruWPlYHdy ... After receiving the above offer, the answerer may immediately begin sending SRTP media using the key and salt indicated by "req:", and lifetime and MKI indicated by "inline:". This is the answer generated from the above offer, which shows the acceptance of the "req" key and salt and the same lifetime and MKI values. v=0 ... m=video 42511 RTP/SAVP 31 a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:s0GbsbrbKRhetTr3FVOxCLeKAUYwFM1ruWPlYHdy|2^20|1:32 ... 5.2. Answerer Doesn't Understand "req:" Using the same offer as the previous example, the following answer was generated by an answerer that doesn't support the extension defined in this document, or by an answerer that rejected the key, salt, or session parameters in the offer and wanted to set its own negotiated parameters. Note the answerer's MKI value (231) is different from the offerer's MKI value (1) because the answerer didn't use the requested key. If the answerer had chosen the same MKI value, the offerer might waste CPU cycles attempting to autehnticate early media which won't authenticate. Raymond & Wing Expires April 19, 2006 [Page 5] Internet-Draft Security Descriptions Early Media October 2005 v=0 ... m=video 51372 RTP/SAVP 31 a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:F0CxoxnxGNdapPn3BRKtYHaGWQUsBI1nqSLhUDzu|2^20|231:32 ... As can be seen, the answer uses a different key and MKI than the original offer. Of course, if the answerer starts sending SRTP media to the offerer before the offerer receives this answer, the offerer won't be able to decrypt that SRTP media until the offerer receives the answer. 5.3. Offer With Multiple Crypto Suites This is an offer with the extension described in this document, with multiple crypto suites each with its own MKI. The MKI is used to identify the crypto-suite that the answerer selected when early media is received. v=0 ... m=video 51372 RTP/SAVP 31 a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|101:32 req:s0GbsbrbKRhetTr3FVOxCLeKAUYwFM1ruWPlYHdy a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:FAGbsbrbKRhetTr3FVOxCLeKAUYwFM1ruWPl07Fc|2^20|102:32 req:4gZGUgYXBveW8gbXV0dW88QlI+PEEgaHJlZj0izE ... The answerer would select one of the a=crypto lines, as described in security descriptions. In this example, the answerer selected the a=crypto line with the tag "1". So that the offerer can decrypt early media, the answerer would also use the same MKI, 101, as in the original offer for the a=crypto line it selected. Thus, the answerer can begin immediately sending SRTP encrypted media and be confident that the offerer can successfully authenticate and decrypt that media. The answer would look like this: v=0 ... m=video 42511 RTP/SAVP 31 a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:s0GbsbrbKRhetTr3FVOxCLeKAUYwFM1ruWPlYHdy|2^20|101:32 ... Raymond & Wing Expires April 19, 2006 [Page 6] Internet-Draft Security Descriptions Early Media October 2005 5.4. Offer With Multiple Keys This is an offer with the extension described in this document, with multiple keys in the first a=crypto line and in the second a=crypto line. v=0 ... m=video 51372 RTP/SAVP 31 a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|101:32; inline:3MgVW5pZG9zLCBlcyB1biBwYXF1ZXRlIHF1ZSBzZ|2^20|102:32 req:s0GbsbrbKRhetTr3FV3xCLeKAUYwFM1ruWPlYHdy a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:WdyYWNp824geSBBc3VudG9zIFJlbGlnaW9zb3Mje|2^20|103:32; inline:0ZXJpYSBtaWdyYXRvcmlhLCBwYXJhIGxvIGN1YWw|2^20|104:32 req:JJKbsbrbKRhetTr3FVOuCLeKAUYwFM1ruWPlY8jQ ... In this example, the answerer selected the first a=crypto line (with tag "1"). To allow the offerer to decrypt early media, the answerer would also use the same MKI, 101, as the first key in the original offer for the a=crypto line it selected. Thus, the answerer can begin immediately sending SRTP encrypted media and be confident that the offerer can successfully authenticate and decrypt that media. In the example below, the answer shows the requested key (s0Gb...) was selected with an MKI of 101, and additional keys with other MKIs are also indicated in the answer. These other keys can overlap MKIs with the offer. v=0 ... m=video 42511 RTP/SAVP 31 a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:s0GbsbrbKRhetTr3FVOxCLeKAUYwFM1ruWPlYHdy|2^20|102:32; inline:LFTCBVTklWRVJTQUw8QlI+PC9CPkVsIHN1YnNlY3|2^20|105:32; inline:3MgbWlncmFudGVzIG1leGljYW5vcywgeWEgc2VhI|2^20|106:32 ... 6. Security Considerations The answerer may find it objectionable to trust the randomness of an encryption key for its own traffic that is provided by a remote peer. In such cases, the requested key described in this document would be ignored and the answerer would generate its own key. Raymond & Wing Expires April 19, 2006 [Page 7] Internet-Draft Security Descriptions Early Media October 2005 7. IANA Considerations This document does not add new IANA registrations. 8. References 8.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [3] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [4] Andreasen, F. and D. Wing, "Security Preconditions for Session Description Protocol Media Streams", draft-ietf-mmusic-securityprecondition-00 (work in progress), February 2005. [5] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol Security Descriptions for Media Streams", draft-ietf-mmusic-sdescriptions-11 (work in progress), June 2005. 8.2. Informational References [6] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [7] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)", RFC 3960, December 2004. Raymond & Wing Expires April 19, 2006 [Page 8] Internet-Draft Security Descriptions Early Media October 2005 Authors' Addresses Rob Raymond CounterPath Solutions, Inc. 8th Floor 100 West Pender Street Vancouver, British Columbia V6B 1R8 Canada Phone: +1.604.878.0440 Fax: Email: rob@counterpath.com URI: Dan Wing Cisco Systems 170 West Tasman Drive San Jose, CA 95134 USA Email: dwing@cisco.com Raymond & Wing Expires April 19, 2006 [Page 9] Internet-Draft Security Descriptions Early Media October 2005 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Raymond & Wing Expires April 19, 2006 [Page 10]