idnits 2.17.1 draft-wing-mmusic-sdes-early-media-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 384. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 361. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 368. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 374. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 16, 2005) is 6766 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2234 (ref. '2') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2327 (ref. '3') (Obsoleted by RFC 4566) == Outdated reference: A later version (-04) exists of draft-ietf-mmusic-securityprecondition-00 == Outdated reference: A later version (-12) exists of draft-ietf-mmusic-sdescriptions-11 Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC R. Raymond 3 Internet-Draft CounterPath Solutions, Inc. 4 Expires: April 19, 2006 D. Wing 5 Cisco Systems 6 October 16, 2005 8 Security Descriptions Extension for Early Media 9 draft-wing-mmusic-sdes-early-media-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 19, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document extends security descriptions to allow early media to 43 be received and decrypted. This extension is useful when security 44 preconditionss isn't used. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 50 3. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3.1. Usage with MKI . . . . . . . . . . . . . . . . . . . . . . 4 52 4. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 5.1. Offer and Accepted Answer . . . . . . . . . . . . . . . . 5 55 5.2. Answerer Doesn't Understand "req:" . . . . . . . . . . . . 5 56 5.3. Offer With Multiple Crypto Suites . . . . . . . . . . . . 6 57 5.4. Offer With Multiple Keys . . . . . . . . . . . . . . . . . 7 58 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 59 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 60 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 62 8.2. Informational References . . . . . . . . . . . . . . . . . 8 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 64 Intellectual Property and Copyright Statements . . . . . . . . . . 10 66 1. Introduction 68 Security Descriptions [5] provides a mechanism to indicate SRTP keys 69 in SDP[3]. In Security Descriptions, the transmitter indicates the 70 key used to transmit their RTP or RTCP packets. 72 In the SDP offer/answer model [6], without security preconditions 73 [4], an answerer might begin transmitting SRTP media towards an 74 offerer before the offerer has received the answer containing the 75 SRTP keys necessary to decrypt the SRTP stream. This is called 76 'early media' [7]. 78 This document provides an extension to security descriptions which 79 allows the offerer to decrypt this early media without requiring the 80 offerer or answerer to implement security preconditions. 82 2. Requirements Language 84 The key words "MUST", "MUST NOT" "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in RFC 2119 [1]. 88 3. Mechanism 90 A new security descriptions session parameter "req", indicates the 91 offerer is requesting that the answerer use a specific key and salt 92 for encrypting RTP and RTCP traffic the answerer transmits. An offer 93 MAY contain the session parameter "req". 95 If the answerer is willing to use this requested key parameter (key, 96 salt, MKI, lifetime) and SRTP session parameters (KDR, FEC_ORDER, 97 etc.) as indicated the offer, the answerer can establish its SRTP 98 crypto context using that infomation, begin sending SRTP packets 99 immediately, and generate an answer indicating it accepted these SRTP 100 key parameters and SRTP session parameters. An answer MUST NOT 101 contain the session parameter "req". 103 If the offerer receives SRTP packets before receiving the answer, the 104 offerer SHOULD assume the answerer supports the extension described 105 in this document and attempt to authenticate the incoming SRTP 106 packet. If the packet is authenticated the early media can be played 107 to the user. If the packet doesn't authenticate, the answer will 108 need to be received before the packet can be processed. This will be 109 the situation if the answerer doesn't support the extension described 110 in this document, the answerer rejected the offered key parameters or 111 session parameters. Typically, in a case where early media is 112 received and can't be authenticated, the SRTP packet will simply be 113 discarded. 115 The technique described in this document is valuable if the answerer 116 sends early media and if the offerer and answerer both use SRTP 117 authentication. 119 3.1. Usage with MKI 121 Some implementations may find MKI to be useful when offering multiple 122 crypto-suites to identify which crypto-suite was chosen by the 123 answerer before the answer arrives. For example, an offer might 124 contain several a=crypto lines for one media line, and each a=cryto 125 line might offer a different crypto suite and a different MKI. When 126 the offerer receives an SRTP packet before receiving the answer, the 127 offerer can determine which a=crypto line was selected by the MKI 128 value of the arriving packets. To provide this functionality, the 129 answerer MUST use the same MKI value of the first key of the selected 130 a=crypto line in the offer; if no MKI is present in the offer, the 131 answerer MUST NOT use use an MKI for its early media. If the offer 132 contained MKI and the answerer chooses to generate its own key (that 133 is, it doesn't use the requested key), the answerer SHOULD use a 134 different MKI value than any of the a=crypto lines for that media 135 stream; by doing this the offerer avoids attempting to authenticate 136 early media until the answer arrives. 138 As MKI incurs some per-packet overhead it is often desirable, after a 139 successful offer/answer exchange, to send packets without MKI. To 140 accomplish this, another offer should be generated with the same 141 a=crypto parameters but without an MKI. When this new offer is 142 accepted, the offerer and answerer can send SRTP packets without MKI, 143 thus conserving bandwidth. 145 In order for early media to be decrypted, an offer MUST have the same 146 MKI length for all a=crypto lines of a media stream. 148 4. ABNF 150 Security Descriptions [5] is extended to allow the offerer to suggest 151 a key for the answerer to use. Following the ABNF [2] in Security 152 Descriptions, the following new session parameter is defined: 154 srtp-session-extension = "req:" key-salt 156 5. Examples 158 In all of the examples below, long a=crypto lines are shown split 159 into separate lines with indentation due to formatting restrictions 160 of this document. 162 5.1. Offer and Accepted Answer 164 This is an offer with the extension described in this document. 166 v=0 167 ... 168 m=video 51372 RTP/SAVP 31 169 a=crypto:1 AES_CM_128_HMAC_SHA1_80 170 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 171 req:s0GbsbrbKRhetTr3FVOxCLeKAUYwFM1ruWPlYHdy 172 ... 174 After receiving the above offer, the answerer may immediately begin 175 sending SRTP media using the key and salt indicated by "req:", and 176 lifetime and MKI indicated by "inline:". 178 This is the answer generated from the above offer, which shows the 179 acceptance of the "req" key and salt and the same lifetime and MKI 180 values. 182 v=0 183 ... 184 m=video 42511 RTP/SAVP 31 185 a=crypto:1 AES_CM_128_HMAC_SHA1_80 186 inline:s0GbsbrbKRhetTr3FVOxCLeKAUYwFM1ruWPlYHdy|2^20|1:32 187 ... 189 5.2. Answerer Doesn't Understand "req:" 191 Using the same offer as the previous example, the following answer 192 was generated by an answerer that doesn't support the extension 193 defined in this document, or by an answerer that rejected the key, 194 salt, or session parameters in the offer and wanted to set its own 195 negotiated parameters. Note the answerer's MKI value (231) is 196 different from the offerer's MKI value (1) because the answerer 197 didn't use the requested key. If the answerer had chosen the same 198 MKI value, the offerer might waste CPU cycles attempting to 199 autehnticate early media which won't authenticate. 201 v=0 202 ... 203 m=video 51372 RTP/SAVP 31 204 a=crypto:1 AES_CM_128_HMAC_SHA1_80 205 inline:F0CxoxnxGNdapPn3BRKtYHaGWQUsBI1nqSLhUDzu|2^20|231:32 206 ... 208 As can be seen, the answer uses a different key and MKI than the 209 original offer. Of course, if the answerer starts sending SRTP media 210 to the offerer before the offerer receives this answer, the offerer 211 won't be able to decrypt that SRTP media until the offerer receives 212 the answer. 214 5.3. Offer With Multiple Crypto Suites 216 This is an offer with the extension described in this document, with 217 multiple crypto suites each with its own MKI. The MKI is used to 218 identify the crypto-suite that the answerer selected when early media 219 is received. 221 v=0 222 ... 223 m=video 51372 RTP/SAVP 31 224 a=crypto:1 AES_CM_128_HMAC_SHA1_80 225 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|101:32 226 req:s0GbsbrbKRhetTr3FVOxCLeKAUYwFM1ruWPlYHdy 227 a=crypto:2 AES_CM_128_HMAC_SHA1_32 228 inline:FAGbsbrbKRhetTr3FVOxCLeKAUYwFM1ruWPl07Fc|2^20|102:32 229 req:4gZGUgYXBveW8gbXV0dW88QlI+PEEgaHJlZj0izE 230 ... 232 The answerer would select one of the a=crypto lines, as described in 233 security descriptions. In this example, the answerer selected the 234 a=crypto line with the tag "1". So that the offerer can decrypt 235 early media, the answerer would also use the same MKI, 101, as in the 236 original offer for the a=crypto line it selected. Thus, the answerer 237 can begin immediately sending SRTP encrypted media and be confident 238 that the offerer can successfully authenticate and decrypt that 239 media. The answer would look like this: 241 v=0 242 ... 243 m=video 42511 RTP/SAVP 31 244 a=crypto:1 AES_CM_128_HMAC_SHA1_80 245 inline:s0GbsbrbKRhetTr3FVOxCLeKAUYwFM1ruWPlYHdy|2^20|101:32 246 ... 248 5.4. Offer With Multiple Keys 250 This is an offer with the extension described in this document, with 251 multiple keys in the first a=crypto line and in the second a=crypto 252 line. 254 v=0 255 ... 256 m=video 51372 RTP/SAVP 31 257 a=crypto:1 AES_CM_128_HMAC_SHA1_80 258 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|101:32; 259 inline:3MgVW5pZG9zLCBlcyB1biBwYXF1ZXRlIHF1ZSBzZ|2^20|102:32 260 req:s0GbsbrbKRhetTr3FV3xCLeKAUYwFM1ruWPlYHdy 261 a=crypto:2 AES_CM_128_HMAC_SHA1_32 262 inline:WdyYWNp824geSBBc3VudG9zIFJlbGlnaW9zb3Mje|2^20|103:32; 263 inline:0ZXJpYSBtaWdyYXRvcmlhLCBwYXJhIGxvIGN1YWw|2^20|104:32 264 req:JJKbsbrbKRhetTr3FVOuCLeKAUYwFM1ruWPlY8jQ 265 ... 267 In this example, the answerer selected the first a=crypto line (with 268 tag "1"). To allow the offerer to decrypt early media, the answerer 269 would also use the same MKI, 101, as the first key in the original 270 offer for the a=crypto line it selected. Thus, the answerer can 271 begin immediately sending SRTP encrypted media and be confident that 272 the offerer can successfully authenticate and decrypt that media. In 273 the example below, the answer shows the requested key (s0Gb...) was 274 selected with an MKI of 101, and additional keys with other MKIs are 275 also indicated in the answer. These other keys can overlap MKIs with 276 the offer. 278 v=0 279 ... 280 m=video 42511 RTP/SAVP 31 281 a=crypto:1 AES_CM_128_HMAC_SHA1_80 282 inline:s0GbsbrbKRhetTr3FVOxCLeKAUYwFM1ruWPlYHdy|2^20|102:32; 283 inline:LFTCBVTklWRVJTQUw8QlI+PC9CPkVsIHN1YnNlY3|2^20|105:32; 284 inline:3MgbWlncmFudGVzIG1leGljYW5vcywgeWEgc2VhI|2^20|106:32 285 ... 287 6. Security Considerations 289 The answerer may find it objectionable to trust the randomness of an 290 encryption key for its own traffic that is provided by a remote peer. 291 In such cases, the requested key described in this document would be 292 ignored and the answerer would generate its own key. 294 7. IANA Considerations 296 This document does not add new IANA registrations. 298 8. References 300 8.1. Normative References 302 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 303 Levels", BCP 14, RFC 2119, March 1997. 305 [2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 306 Specifications: ABNF", RFC 2234, November 1997. 308 [3] Handley, M. and V. Jacobson, "SDP: Session Description 309 Protocol", RFC 2327, April 1998. 311 [4] Andreasen, F. and D. Wing, "Security Preconditions for Session 312 Description Protocol Media Streams", 313 draft-ietf-mmusic-securityprecondition-00 (work in progress), 314 February 2005. 316 [5] Andreasen, F., Baugher, M., and D. Wing, "Session Description 317 Protocol Security Descriptions for Media Streams", 318 draft-ietf-mmusic-sdescriptions-11 (work in progress), 319 June 2005. 321 8.2. Informational References 323 [6] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 324 Session Description Protocol (SDP)", RFC 3264, June 2002. 326 [7] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone 327 Generation in the Session Initiation Protocol (SIP)", RFC 3960, 328 December 2004. 330 Authors' Addresses 332 Rob Raymond 333 CounterPath Solutions, Inc. 334 8th Floor 335 100 West Pender Street 336 Vancouver, British Columbia V6B 1R8 337 Canada 339 Phone: +1.604.878.0440 340 Fax: 341 Email: rob@counterpath.com 342 URI: 344 Dan Wing 345 Cisco Systems 346 170 West Tasman Drive 347 San Jose, CA 95134 348 USA 350 Email: dwing@cisco.com 352 Intellectual Property Statement 354 The IETF takes no position regarding the validity or scope of any 355 Intellectual Property Rights or other rights that might be claimed to 356 pertain to the implementation or use of the technology described in 357 this document or the extent to which any license under such rights 358 might or might not be available; nor does it represent that it has 359 made any independent effort to identify any such rights. Information 360 on the procedures with respect to rights in RFC documents can be 361 found in BCP 78 and BCP 79. 363 Copies of IPR disclosures made to the IETF Secretariat and any 364 assurances of licenses to be made available, or the result of an 365 attempt made to obtain a general license or permission for the use of 366 such proprietary rights by implementers or users of this 367 specification can be obtained from the IETF on-line IPR repository at 368 http://www.ietf.org/ipr. 370 The IETF invites any interested party to bring to its attention any 371 copyrights, patents or patent applications, or other proprietary 372 rights that may cover technology that may be required to implement 373 this standard. Please address the information to the IETF at 374 ietf-ipr@ietf.org. 376 Disclaimer of Validity 378 This document and the information contained herein are provided on an 379 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 380 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 381 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 382 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 383 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 384 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 386 Copyright Statement 388 Copyright (C) The Internet Society (2005). This document is subject 389 to the rights, licenses and restrictions contained in BCP 78, and 390 except as set forth therein, the authors retain all their rights. 392 Acknowledgment 394 Funding for the RFC Editor function is currently provided by the 395 Internet Society.