idnits 2.17.1 draft-ietf-mmusic-sdescriptions-07.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.5 on line 1748. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1759. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1766. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1772. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1740), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 39. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 6 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and 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? RFC 2119 keyword, line 215: '...ine. The "crypto" attribute MUST only...' RFC 2119 keyword, line 237: '...ion 8.1 for details). The tag MUST be...' RFC 2119 keyword, line 280: '... New key methods MUST be registered wi...' RFC 2119 keyword, line 285: '... semantics MUST be provided in a Sta...' RFC 2119 keyword, line 292: '...uded in the key parameters, it MUST be...' (123 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 551 has weird spacing: '...applied to a ...' == Line 1310 has weird spacing: '...essions are v...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2119' is mentioned on line 128, but not defined == Missing Reference: 'TLS' is mentioned on line 179, but not defined == Missing Reference: 'RFC 3550' is mentioned on line 1012, but not defined == Missing Reference: 'SIP' is mentioned on line 1229, but not defined == Missing Reference: 'RFC 3313' is mentioned on line 1249, but not defined == Unused Reference: 'RFC3550' is defined on line 1626, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 1654, but no explicit reference was found in the text == Unused Reference: 'Bellovin' is defined on line 1663, but no explicit reference was found in the text == Unused Reference: 'RFC2733' is defined on line 1686, but no explicit reference was found in the text == Unused Reference: 'RFC2045' is defined on line 1705, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 1709, but no explicit reference was found in the text == Unused Reference: 'RFC3312' is defined on line 1717, but no explicit reference was found in the text == Unused Reference: 'RFC2974' is defined on line 1721, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2327 (ref. 'SDP') (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 2828 (Obsoleted by RFC 4949) ** Obsolete normative reference: RFC 1750 (Obsoleted by RFC 4086) ** Obsolete normative reference: RFC 3548 (Obsoleted by RFC 4648) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 3547 (ref. 'GDOI') (Obsoleted by RFC 6407) -- Obsolete informational reference (is this intentional?): RFC 2733 (Obsoleted by RFC 5109) Summary: 15 errors (**), 0 flaws (~~), 19 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Flemming Andreasen 3 MMUSIC Working Group Mark Baugher 4 INTERNET-DRAFT Dan Wing 5 EXPIRES: January 2005 Cisco Systems 6 July, 2004 8 Session Description Protocol Security Descriptions 9 for Media Streams 10 12 Status of this memo 14 By submitting this Internet-Draft, the authors certify that any 15 applicable patent or other IPR claims of which we are aware have been 16 disclosed, and any of which we become aware will be disclosed, in 17 accordance with RFC 3668 (BCP 79). 19 By submitting this Internet-Draft, the authors accept the provisions 20 of Section 3 of RFC 3667 (BCP 78). 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or cite them other than as "work in progress". 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/lid-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). All Rights Reserved. 41 Abstract 43 This document defines a Session Description Protocol (SDP) 44 cryptographic attribute for unicast media streams. The attribute 45 describes a cryptographic key and other parameters, which serve to 46 configure security for a unicast media stream in either a single 47 message or a roundtrip exchange. The attribute can be used with a 48 variety of SDP media transports and this document defines how to use 49 it for the Secure Real-time Transport Protocol (SRTP) unicast media 50 streams. The SDP crypto attribute requires the services of a data 51 security protocol to secure the SDP message. 53 Table of Contents 55 1. Notational Conventions............................................3 56 2. Introduction......................................................3 57 3. SDP "Crypto" Attribute and Parameters.............................5 58 3.1 Tag.............................................................5 59 3.2 Crypto-suite....................................................5 60 3.3 Key Parameters..................................................6 61 3.4 Session Parameters..............................................7 62 3.5 Example.........................................................7 63 4. General Use of the crypto Attribute...............................8 64 4.1 Use With Offer/Answer...........................................8 65 4.1.1 Generating the Initial Offer - Unicast Streams.............8 66 4.1.2 Generating the Initial Answer - Unicast Streams............9 67 4.1.3 Processing of the Initial Answer - Unicast Streams........10 68 4.1.4 Modifying the Session.....................................10 69 4.2 Use Outside Offer/Answer.......................................10 70 4.3 General Backwards Compatibility Considerations.................10 71 5. SRTP Security Descriptions.......................................11 72 5.1 SRTP Key Parameter.............................................12 73 5.2 Crypto-suites..................................................14 74 5.2.1 AES_CM_128_HMAC_SHA1_80...................................15 75 5.2.2 AES_CM_128_HMAC_SHA1_32...................................15 76 5.2.3 F8_128_HMAC_SHA1_80.......................................16 77 5.2.4 Adding new Crypto-suite Definitions.......................16 78 5.3 Session Parameters.............................................16 79 5.3.1 KDR=n.....................................................16 80 5.3.2 UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP....................16 81 5.3.3 UNAUTHENTICATED_SRTP......................................17 82 5.3.4 FEC_ORDER=order...........................................17 83 5.3.5 FEC_KEY=key-params........................................17 84 5.3.6 Window Size Hint (WSH)....................................18 85 5.3.7 Defining New SRTP Session Parameters......................18 86 5.4 SRTP Crypto Context Initialization.............................18 87 5.4.1 Late Binding of one or more SSRCs to a crypto context.....19 88 5.4.2 Sharing cryptographic contexts among Sessions or SSRCs....20 89 5.5 Removal of Crypto Contexts.....................................21 90 6. SRTP-Specific Use of the crypto Attribute........................21 91 6.1 Use with Offer/Answer..........................................21 92 6.1.1 Generating the Initial Offer - Unicast Streams............22 93 6.1.2 Generating the Initial Answer - Unicast Streams...........22 94 6.1.3 Processing of the Initial Answer - Unicast Streams........23 95 6.1.4 Modifying the Session.....................................23 96 6.1.5 Offer/Answer Example......................................24 97 6.2 SRTP-Specific Use Outside Offer/Answer.........................25 98 6.3 Support for SIP Forking........................................26 99 6.4 SRTP-Specific Backwards Compatibility Considerations...........26 100 6.5 Operation with KEYMGT= and k= lines............................27 101 7. Security Considerations..........................................27 102 7.1 Authentication of packets......................................27 103 7.2 Keystream Reuse................................................27 104 7.3 Signaling Authentication and Signaling Encryption..............28 105 8. Grammar..........................................................29 106 8.1 Generic "Crypto" Attribute Grammar.............................29 107 8.2 SRTP "Crypto" Attribute Grammar................................29 108 9. IANA Considerations..............................................30 109 9.1 Registration of the "crypto" attribute.........................30 110 9.2 New IANA Registries and Registration Procedures................30 111 9.2.1 Key Method Registry and Registration......................31 112 9.2.2 Media Stream Transport Registry and Registration..........31 113 9.3 Initial Registrations..........................................31 114 9.3.1 Key Method................................................31 115 9.3.2 SRTP Media Stream Transport...............................32 116 10. Acknowledgements................................................33 117 11. Authors' Addresses..............................................33 118 12. Normative References............................................34 119 13. Informative References..........................................34 120 14. Full Copyright Statement........................................36 122 1. Notational Conventions 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD 125 NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 126 be interpreted as described in [RFC2119]. The terminology in this 127 document conforms to [RFC2828], "Internet Security Glossary". 129 n^r is exponentiation where n is multiplied by itself r times; n and 130 r are integers. 0..k is an integer range of all integers from 0 131 through k inclusive. 133 The terms 'transport' and 'media transport' are used to mean 134 'transport protocol' as defined in RFC2327, page 20. 136 Explanatory notes are provided in several places throughout the 137 document; these notes are indented two spaces from the surrounding 138 text. 140 2. Introduction 142 The Session Description Protocol (SDP) [SDP] describes multimedia 143 sessions, which can be audio, video, whiteboard, fax, modem, and 144 other media streams. Security services such as data origin 145 authentication, integrity and confidentiality are often needed for 146 those streams. The Secure Real-time Transport Protocol (SRTP) [srtp] 147 provides security services for RTP media and is signaled by use of 148 secure RTP transport (e.g., "RTP/SAVP" or "RTP/SAVPF") in an SDP 149 media (m=) line. However, there are no means within SDP itself to 150 configure SRTP beyond using default values. This document specifies 151 a new SDP attribute called "crypto", which is used to signal and 152 negotiate cryptographic parameters for media streams in general, and 153 SRTP in particular. The definition of the crypto attribute in this 154 document is limited to two-party unicast media streams where each 155 source has a unique cryptographic key; support for multicast media 156 streams or multipoint unicast streams is for further study. 158 The crypto attribute is defined in a generic way to enable its use 159 with SRTP and any other secure transports that can establish 160 cryptographic parameters with only a single message or in a single 161 round-trip exchange using the offer/answer model [RFC3264]. 162 Extension to transports other than SRTP, however, is beyond the scope 163 of this document. Each type of secure media transport needs its own 164 specification for the crypto-attribute parameter. These definitions 165 are frequently unique to the particular type of transport and must be 166 specified in a Standards Track RFC and registered with IANA according 167 to the procedures defined in Section 9. This document defines the 168 security parameters and keying material for SRTP only. 170 It would be self-defeating not to secure cryptographic keys and other 171 parameters at least as well as the data is secured. Data security 172 protocols such as SRTP rely upon a separate key management system to 173 securely establish encryption and/or authentication keys. Key 174 management protocols provide authenticated key establishment (AKE) 175 procedures to authenticate the identity of each endpoint and protect 176 against man-in-the-middle, reflection/replay, connection hijacking 177 and some denial of service attacks [skeme]. Along with the key, an 178 AKE protocol such as MIKEY [mikey], GDOI [GDOI], KINK [kink], IKE 179 [ike], Secure Multiparts [s/mime, pgp/mime] or TLS [TLS] securely 180 disseminates information describing both the key and the data- 181 security session. AKE is needed because it is pointless to provide a 182 key over a medium where an attacker can snoop the key, alter the 183 definition of the key to render it useless, or change the parameters 184 of the security session to gain unauthorized access to session- 185 related information. 187 SDP, however, was not designed to provide AKE services, and the media 188 security descriptions defined in this document do not add AKE 189 services to SDP. This specification is no replacement for a key 190 management protocol or for the conveyance of key management messages 191 in SDP [keymgt]. The SDP security descriptions defined here are 192 suitable for restricted cases only where IPsec, TLS, or some other 193 encapsulating data-security protocol (e.g., SIP secure multiparts) 194 protects the SDP message. This document adds security descriptions 195 to those encrypted and/or authenticated SDP messages through the new 196 SDP "crypto" attribute, which provides the cryptographic parameters 197 of a media stream. 199 The "crypto" attribute can be adapted to any media transport, but its 200 precise definition is unique to a particular transport. 202 In Section 3, we introduce the general SDP crypto attribute, and in 203 Section 4 we define how it is used with and without the offer/answer 204 model. In Section 5, we define the crypto attribute details needed 205 for SRTP, and in Section 6 we define SRTP-specific use of the 206 attribute with and without the offer/answer model. Section 7 recites 207 security considerations, and Section 8 gives an Augmented-BNF grammar 208 for the general crypto attribute as well as the SRTP-specific use of 209 the crypto attribute. IANA considerations are provided in Section 9. 211 3. SDP "Crypto" Attribute and Parameters 213 A new media-level SDP attribute called "crypto" describes the 214 cryptographic suite, key parameters, and session parameters for the 215 preceding unicast media line. The "crypto" attribute MUST only 216 appear at the SDP media level (not at the session level). The 217 "crypto" attribute follows the format (see Section 8.1 for the formal 218 ABNF grammar): 220 a=crypto: [] 222 The fields tag, crypto-suite, key-params, and session-params are 223 described in the following sub-sections. Below we show an example of 224 the crypto attribute for the "RTP/SAVP" transport, i.e., the secure 225 RTP extension to the Audio/Video Profile [srtp]. In the following, 226 newlines are included for formatting reasons only: 228 a=crypto:1 AES_CM_128_HMAC_SHA1_80 229 inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:32 231 The crypto-suite is AES_CM_128_HMAC_SHA1_80, key-params is defined 232 by the text starting with "inline:", and session-params is omitted. 234 3.1 Tag 236 The tag is a decimal number used as an identifier for a particular 237 crypto attribute (see Section 8.1 for details). The tag MUST be 238 unique among all crypto attributes for a given media line. It is 239 used with the offer/answer model to determine which of several 240 offered crypto attributes were chosen by the answerer (see Section 241 4.1). 243 In the offer/answer model, the tag is a negotiated parameter. 245 3.2 Crypto-suite 247 The crypto-suite field is an identifier that describes the encryption 248 and authentication algorithms (e.g., AES_CM_128_HMAC_SHA1_80) for 249 the transport in question (see Section 8.1 for details). The 250 possible values for the crypto-suite parameter are defined within the 251 context of the transport, i.e., each transport defines a separate 252 namespace for the set of crypto-suites. For example, the crypto- 253 suite "AES_CM_128_HMAC_SHA1_80" defined within the context 254 "RTP/SAVP" transport applies to Secure RTP only; the string may be 255 reused for another transport (e.g., "RTP/SAVPF" [srtpf]), but a 256 separate definition would be needed. 258 In the offer/answer model, the crypto-suite is a negotiated 259 parameter. 261 3.3 Key Parameters 263 The key-params field provides one or more sets of keying material for 264 the crypto-suite in question. The field consists of a method 265 indicator followed by a colon, and the actual keying information as 266 shown below (the formal grammar is provided in Section 8.1): 268 key-params = ":" 270 Keying material might be provided by different means than key-params, 271 however this is out of scope. Only one method is defined in this 272 document, namely "inline", which indicates that the actual keying 273 material is provided in the key-info field itself. There is a single 274 name space for the key-method, i.e., the key-method is transport 275 independent. New key-methods (e.g., use of a URL) may be defined in 276 a Standards Track RFC in the future. Although the key-method itself 277 may be generic, the accompanying key-info definition is specific not 278 only to the key-method, but also to the transport in question. Key- 279 info encodes keying material for a crypto suite, which defines that 280 keying material. New key methods MUST be registered with the IANA 281 according to the procedures defined in Section 9.2.1. 283 Key-info is defined as a general character string (see Section 8.1 284 for details); further transport and key-method specific syntax and 285 semantics MUST be provided in a Standards Track RFC for each 286 combination of transport and key-method that use it; definitions for 287 SRTP are provided in Section 5. Note that such definitions are 288 provided within the context of both a particular transport (e.g., 289 "RTP/SAVP") and a specific key-method (e.g., "inline"). IANA will 290 register the list of supported key methods for each transport. 292 When multiple keys are included in the key parameters, it MUST be 293 possible to determine which of the keys is being used in a given 294 media packet by a simple inspection of the media packet received; a 295 trial-and-error approach between the possible keys MUST NOT be 296 performed. 298 For SRTP, this could be achieved by use of Master Key Identifiers 299 (MKI) [srtp]. Use of <"From, "To"> values are not supported in 300 SRTP security descriptions for reasons explained in Section 5.1, 301 below. 303 In the offer/answer model, the key parameter is a declarative 304 parameter. 306 3.4 Session Parameters 308 Session parameters are specific to a given transport and use of them 309 is OPTIONAL in the security descriptions framework, where they are 310 just defined as general character strings. If session parameters are 311 to be used for a given transport, then transport-specific syntax and 312 semantics MUST be provided in a Standards Track RFC; definitions for 313 SRTP are provided in Section 5. 315 In the offer/answer model, session parameters may be either 316 negotiated or declarative; the definition of specific session 317 parameters MUST indicate whether they are negotiated or declarative. 318 Negotiated parameters apply to data sent in both directions, whereas 319 declarative parameters apply only to media sent by the entity that 320 generated the SDP. Thus, a declarative parameter in an offer applies 321 to media sent by the offerer, whereas a declarative parameter in an 322 answer applies to media sent by the answerer. 324 3.5 Example 326 This example shows use of the crypto attribute for the "RTP/SAVP" 327 media transport type (as defined in Section 4). The "a=crypto" line 328 is actually one long line; it is shown as two lines due to page 329 formatting: 331 v=0 332 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 333 s=SDP Seminar 334 i=A Seminar on the session description protocol 335 u=http://www.example.com/seminars/sdp.pdf 336 e=j.doe@example.com (Jane Doe) 337 c=IN IP4 161.44.17.12/127 338 t=2873397496 2873404696 339 m=video 51372 RTP/SAVP 31 340 a=crypto:1 AES_CM_128_HMAC_SHA1_80 341 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 342 m=audio 49170 RTP/SAVP 0 343 a=crypto:1 AES_CM_128_HMAC_SHA1_32 344 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 345 m=application 32416 udp wb 346 a=orient:portrait 348 This SDP message describes three media streams, two of which use the 349 "RTP/SAVP" transport. Each has a crypto attribute for the 350 "RTP/SAVP" transport. These secure-RTP specific descriptions are 351 defined in Section 5. 353 4. General Use of the crypto Attribute 355 In this section, we describe the general use of the crypto attribute 356 outside of any transport or key-method specific rules. 358 4.1 Use With Offer/Answer 360 The general offer/answer rules for the crypto attribute are in 361 addition to the rules specified in RFC 3264, which MUST be followed, 362 unless otherwise noted. RFC 3264 defines operation for both unicast 363 and multicast streams; the sections below describe operation for two- 364 party unicast streams only, since support for multicast streams (and 365 multipoint unicast streams) is for further study. 367 4.1.1 Generating the Initial Offer - Unicast Streams 369 When generating an initial offer for a unicast stream, there MUST be 370 one or more crypto attributes present for each media stream for which 371 security is desired. Each crypto attribute for a given media stream 372 MUST contain a unique tag. 374 The ordering of multiple "a=crypto" lines is significant: The most 375 preferred crypto line is listed first. Each crypto attribute 376 describes the crypto-suite, key(s) and possibly session parameters 377 offered for the media stream. In general, a "more preferred" crypto- 378 suite SHOULD be cryptographically stronger than a "less preferred" 379 crypto-suite. 381 The crypto-suite always applies to media in the directions supported 382 by the media stream (e.g., send and receive). The key(s), however, 383 apply to media in the direction from the offerer to the answerer; if 384 the media stream is marked as "recvonly", a key MUST still be 385 provided. 387 This is done for consistency. Also, in the case of SRTP, for 388 example, secure RTCP will still be flowing in both the send and 389 receive direction for a unidirectional stream. 391 The offer may include session parameters. There are no general offer 392 rules for the session parameters; instead, specific rules may be 393 provided as part of the transport-specific definitions of any session 394 parameters. 396 When issuing an offer, the offerer MUST be prepared to support media 397 security in accordance with any of the crypto attributes included in 398 the offer. There are however two problems associated with this. 399 First of all, the offerer does not know which key the answerer will 400 be using for media sent to the offerer. Second, the offerer may not 401 be able to deduce which of the offered crypto attributes were 402 accepted. Since media may arrive prior to the answer, delay or 403 clipping can occur. If this is unacceptable to the offerer, the 404 offerer SHOULD use a mechanism outside the scope of this document to 405 prevent the above problem. 407 For example, in SIP [RFC3261], a "security" precondition as defined 408 in [sprecon] could solve the above problem. 410 4.1.2 Generating the Initial Answer - Unicast Streams 412 When the answerer receives the initial offer with one or more crypto 413 attributes for a given unicast media stream, the answerer MUST either 414 accept exactly one of the offered crypto attributes, or the offered 415 stream MUST be rejected. 417 If the answerer wishes to indicate support for other crypto 418 attributes, those can be listed by use of the SDP Simple Capability 419 Declaration [RFC3407] extensions. 421 Only crypto attributes that are valid can be accepted; valid 422 attributes do not violate any of the general rules defined for 423 security descriptions as well as any specific rules defined for the 424 transport and key-method in question. When selecting one of the 425 valid crypto attributes, the answerer SHOULD select the most 426 preferred crypto attribute it can support, i.e., the first valid 427 supported crypto attribute in the list, considering the answerer's 428 capabilities and security policies. 430 If there are one or more crypto attributes in the offer, but none of 431 them are valid, or none of the valid ones are supported, the offered 432 media stream MUST be rejected. 434 When an offered crypto attribute is accepted, the crypto attribute in 435 the answer MUST contain the following: 437 * The tag and crypto-suite from the accepted crypto attribute in the 438 offer (the same crypto-suite MUST be used in the send and receive 439 direction). 440 * The key(s) the answerer will be using for media sent to the 441 offerer. Note that a key MUST be provided, irrespective of any 442 direction attributes in the offer or answer. 444 Furthermore, any session parameters that are negotiated MUST be 445 included in the answer. Declarative session parameters provided by 446 the offerer are not included in the answer, however the answerer may 447 provide its own set of declarative session parameters. 449 Once the answerer has accepted one of the offered crypto attributes, 450 the answerer MAY begin sending media to the offerer in accordance 451 with the selected crypto attribute. Note however, that the offerer 452 may not be able to process such media packets correctly until the 453 answer has been received. 455 4.1.3 Processing of the Initial Answer - Unicast Streams 457 When the offerer receives the answer, the offerer MUST verify, that 458 one of the initially offered crypto suites and its accompanying tag 459 was accepted and echoed in the answer. Also, the answer MUST include 460 one or more keys, which will be used for media sent from the answerer 461 to the offerer. 463 If the offer contained any mandatory negotiated session parameters 464 (see section 5.3.7), the offerer MUST verify that said parameters are 465 included in the answer and support them. If the answer contains any 466 mandatory declarative session parameters, the offerer MUST be able to 467 support those. 469 If any of the above fails, the negotiation MUST fail. 471 4.1.4 Modifying the Session 473 Once a media stream has been established, it MAY be modified at any 474 time, as described in RFC 3264, Section 8. Such a modification MAY 475 be triggered by the security service, e.g., in order to perform a re- 476 keying or change the crypto-suite. If media stream security using 477 the general security descriptions defined here is still desired, the 478 crypto attribute MUST be included in these new offer/answer 479 exchanges. The procedures are similar to those defined in Section 480 4.1.1, 4.1.2, 4.1.3 of this document, subject to the considerations 481 provided in RFC 3264 Section 8. 483 4.2 Use Outside Offer/Answer 485 The crypto attribute can also be used outside the context of 486 offer/answer where there is no negotiation of the crypto suite, 487 cryptographic key or session parameters. In this case, the sender 488 determines security parameters for the stream. Since there is no 489 negotiation mechanisms, the sender MUST include exactly one crypto 490 attribute and the receiver MUST either accept it or else SHOULD NOT 491 receive the associated stream. The sender SHOULD select the security 492 description that it deems most secure for its purposes. 494 4.3 General Backwards Compatibility Considerations 496 In the offer/answer model, it is possible that the answerer supports 497 a given secure transport (e.g., "RTP/SAVP") and accepts the offered 498 media stream, yet the answerer does not support the crypto attribute 499 defined in this document and hence ignores it. The offerer can 500 recognize this situation by seeing an accepted media stream in the 501 answer that does not include a crypto line. In that case, the 502 security negotiation defined here MUST fail. 504 Similar issues exist when security descriptions are used outside of 505 the offer/answer model. But the source of a non-negotiated security 506 description has no indication that the receiver has ignored the 507 crypto attribute. 509 5. SRTP Security Descriptions 511 In this section, we provide definitions for security descriptions for 512 SRTP media streams. In the next section, we define how to use SRTP 513 security descriptions with and without the offer/answer model. 515 SRTP security descriptions MUST only be used with the SRTP transport 516 (e.g., "RTP/SAVP" or "RTP/SAVPF"). The following specifies security 517 descriptions for the "RTP/SAVP" profile defined in [srtp], however it 518 is expected that other secure RTP profiles (e.g., "RTP/SAVPF") can 519 use the same descriptions, which are in accordance with the SRTP 520 protocol specification [srtp]. 522 There is no assurance that an endpoint is capable of configuring its 523 SRTP service with a particular crypto attribute parameter, but SRTP 524 guarantees minimal interoperability among SRTP endpoints through the 525 default SRTP parameters [srtp]. More capable SRTP endpoints support 526 a variety of parameter values beyond the SRTP defaults and these 527 values can be configured by the SRTP security descriptions defined 528 here. An endpoint that does not support the crypto attribute will 529 ignore it according to the SDP. Such an endpoint will not correctly 530 process the particular media stream. By using the Offer/Answer 531 model, the offerer and answerer can negotiate the crypto parameters 532 to be used before commencement of the multimedia session (see Section 533 6.1). 535 There are over twenty cryptographic parameters listed in the SRTP 536 specification. Many of these parameters have fixed values for 537 particular cryptographic transforms. At the time of session 538 establishment, however, there is usually no need to provide unique 539 settings for many of the SRTP parameters, such as salt length and 540 pseudo-random function (PRF). Thus, it is possible to simplify the 541 list of parameters by defining "cryptographic suites" that fix a set 542 of SRTP parameter values for the security session. This approach is 543 followed by the SRTP security descriptions, which uses the general 544 security description parameters as follows: 546 * crypto-suite: Identifies the encryption and authentication 547 transforms 548 * key parameter: SRTP keying material and parameters 549 * session parameters: The following parameters are defined: 550 - KDR: The SRTP Key Derivation Rate is the rate that a 551 pseudo-random function is applied to a master key 552 - UNENCRYPTED_SRTP: SRTP messages are not encrypted 553 - UNENCRYPTED_SRTCP: SRTCP messages are not encrypted 554 - UNAUTHENTICATED_SRTP: SRTP messages are not authenticated 555 - FEC_ORDER: Order of forward error correction (FEC) 556 relative to SRTP services 557 - FEC_KEY: Master Key for FEC when the FEC stream is sent 558 to a separate address and/or port. 559 - WSH: Window Size Hint 560 - Extensions: Extension parameters can be defined 562 Please refer to the SRTP specification for a complete list of 563 parameters and their descriptions [Section 8.2, srtp]. The key 564 parameter, the crypto-suite, and the session parameters shown above 565 are described in detail in the following subsections. 567 5.1 SRTP Key Parameter 569 SRTP security descriptions define use of the "inline" key method as 570 described in the following. Use of any other keying method, e.g., 571 URL, for SRTP security descriptions is for further study. 573 The "inline" type of key contains the keying material (master key 574 and salt) and all policy related to that master key, including how 575 long it can be used (lifetime) and whether or not it uses a master 576 key identifier (MKI) to associate an incoming SRTP packet with a 577 particular master key. Compliant implementations obey the policies 578 associated with a master key, and MUST NOT accept incoming packets 579 that violate the policy (e.g., after the master key lifetime has 580 expired). 582 The key parameter contains one or more cryptographic master keys, 583 each of which MUST be a unique cryptographically random [RFC1750] 584 value with respect to other master keys in the entire SDP message 585 (i.e., including master keys for other streams). Each key follows 586 the format (the formal definition is provided in Section 8.2): 588 "inline:" "|" [lifetime] "|" [MKI ":" length] 590 key||salt concatenated master key and salt, base64 encoded 591 (see [RFC3548], Section 3) 592 lifetime master key lifetime (max number of SRTP or SRTCP 593 packets using this master key) 594 MKI:length MKI and length of the MKI field in SRTP packets 596 The following definition provides an example for 597 AES_CM_128_HMAC_SHA1_80: 599 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:4 601 The first field ("d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj") of the 602 parameter is the cryptographic master key appended with the master 603 salt; the two are first concatenated and then base64 encoded. The 604 length of the concatenated key and salt is determined by the crypto- 605 suite for which the key applies. If the length (after being decoded 606 from base64) does not match that specified for the crypto-suite, the 607 crypto attribute in question MUST be considered invalid. Each master 608 key and salt MUST be a cryptographically random number and MUST be 609 unique to the entire SDP message. When base64 decoding the key and 610 salt, padding characters (i.e., one or two "=" at the end of the 611 base64 encoded data) are discarded (see [RFC3548] for details). 612 Base64 encoding assumes that the base64 encoding input is an integral 613 number of octets. If a given crypto-suite requires the use of a 614 concatenated key and salt with a length that is not an integral 615 number of octets, said crypto-suite MUST define a padding scheme that 616 results in the base64 input being an integral number of octets. For 617 example, if the length defined was 250 bits, then 6 padding bits 618 would be needed, which could be defined to be the last 6 bits in a 619 256 bit input. 621 The second field, is the OPTIONAL lifetime of the master key as 622 measured in maximum number of SRTP or SRTCP packets using that master 623 key (i.e., the number of SRTP packets and the number of SRTCP packets 624 each have to be less than the lifetime). The lifetime value MAY be 625 written as a non-zero, positive integer or as a power of 2 (see the 626 grammar in Section 8.2 for details). The "lifetime" value MUST NOT 627 exceed the maximum packet lifetime for the crypto-suite. If the 628 lifetime is too large or otherwise invalid then the entire crypto 629 attribute MUST be considered invalid. The default MAY be implicitly 630 signaled by omitting the lifetime value (i.e., "||"). This is 631 convenient when the SRTP cryptographic key lifetime is the default 632 value. As a shortcut to avoid long decimal values, the syntax of the 633 lifetime allows using the literal "2^", which indicates "two to the 634 power of". The example above, shows a case where the lifetime is 635 specified as 2^20. The following example, which is for the 636 AES_CM_128_HMAC_SHA1_80 crypto-suite, has a default for the lifetime 637 field, which means that SRTP's and SRTCP's default values will be 638 used (see [srtp]): 640 inline:YUJDZGVmZ2hpSktMbW9QUXJzVHVWd3l6MTIzNDU2||1066:4 642 The example shows a 30-character key and concatenated salt that is 643 base64 encoded: The 30-character key/salt concatenation is expanded 644 to 40 characters by the three-in-four encoding of base64. 646 The third field, which is also OPTIONAL, is the Master Key Identifier 647 (MKI) and its byte length. 649 "MKI" is the master key identifier associated with the SRTP master 650 key. If the MKI is given, then the length of the MKI MUST also be 651 given and separated from the MKI by a colon (":"). The MKI length is 652 the size of the MKI field in the SRTP packet, specified in bytes. If 653 the MKI length is not given or its value exceeds 128 (bytes), then 654 the entire crypto attribute MUST be considered invalid. The 655 substring "1:4" in the first example assigns to the key a master key 656 identifier of 1 that is 4 bytes long, and the second example assigns 657 a 4-byte master key identifier of 1066 to the key. One or more 658 master keys with their associated MKI can be initially defined, and 659 then later updated, or deleted and new ones defined. 661 SRTP offers a second feature for specifying the lifetime of a master 662 key in terms of two values, called "From" and "To," which are defined 663 on the SRTP sequence number space [srtp]. This SRTP Security 664 Descriptions specification, however, does not support the 665 <"From","To"> feature since the lifetime of an AES master key is 2^48 666 SRTP packets, which means that there is no cryptographic reason to 667 replace a master key for practical point-to-point applications. For 668 this reason, there is no need to support two means for signaling key 669 update. The MKI is chosen over <"From","To"> by this specification 670 for the very few applications that need it since the MKI feature is 671 simpler (though the MKI adds additional bytes to each packet whereas 672 <"From", "To"> does not). 674 As mentioned above, the key parameter can contain one or more master 675 keys. When the key parameter contains more than one master key, all 676 of the master keys in that key parameter MUST include an MKI value. 677 When using the MKI, the MKI length MUST be the same for all keys in a 678 given crypto attribute. 680 5.2 Crypto-suites 682 The SRTP crypto-suites define the encryption and authentication 683 transforms to be used for the SRTP media stream. The SRTP 684 specification has defined three crypto-suites, which are described 685 further in the following subsections in the context of the SRTP 686 security descriptions. The table below provides an overview of the 687 crypto-suites and their parameters: 689 +---------------------+-------------+--------------+---------------+ 690 | |AES_CM_128_ | AES_CM_128_ | F8_128_ | 691 | |HMAC_SHA1_80 | HMAC_SHA1_32 | HMAC_SHA1_80 | 692 +---------------------+-------------+--------------+---------------+ 693 | Master key length | 128 bits | 128 bits | 128 bits | 694 | Salt value | 112 bits | 112 bits | 112 bits | 695 | Default lifetime | 2^31 packets| 2^31 packets | 2^31 packets | 696 | Cipher | AES Counter | AES Counter | F8 | 697 | | Mode | Mode | | 698 | Encryption key | 128 bits | 128 bits | 128 bits | 699 | MAC | HMAC-SHA1 | HMAC-SHA1 | HMAC-SHA1 | 700 | Authentication tag | 80 bits | 32 bits | 80 bits | 701 | SRTP auth. key | 160 bits | 160 bits | 160 bits | 702 | SRTCP auth. key | 160 bits | 160 bits | 160 bits | 703 +---------------------+-------------+--------------+---------------+ 705 5.2.1 AES_CM_128_HMAC_SHA1_80 707 AES_CM_128_HMAC_SHA1_80 is the SRTP default AES Counter Mode cipher 708 and HMAC-SHA1 message authentication having an 80-bit authentication 709 tag. The master-key length is 128 bits and has a default lifetime 710 of a maximum of 2^31 SRTP packets or SRTCP packets, whichever comes 711 first [Page 39, srtp]. 713 Technically, SRTP allows 2^48 SRTP packets or 2^31 SRTCP packets, 714 whichever comes first. SRTP security descriptions, however, 715 simplify the parameters to share a single upper bound of 2^31 716 packets. It is RECOMMENDED that automated key management allow 717 easy and efficient rekeying at intervals far smaller than 2^31 718 packets given today's media rates or even HDTV media rates. 720 The SRTP and SRTCP encryption key lengths are 128 bits. The SRTP 721 and SRTCP authentication key lengths are 160 bits (see Security 722 Considerations in Section 7). The master salt value is 112 bits in 723 length and the session salt value is 112 bits in length. The 724 pseudo-random function (PRF) is the default SRTP pseudo-random 725 function that uses AES Counter Mode with a 128-bit key length. 727 The length of the base64 decoded key and salt value for this crypto- 728 suite MUST be 30 characters, i.e., 240 bits; otherwise the crypto 729 attribute is considered invalid. 731 5.2.2 AES_CM_128_HMAC_SHA1_32 733 This crypto-suite is identical to AES_CM_128_HMAC_SHA1_80 except 734 that the authentication tag is 32 bits. 736 The length of the base64-decoded key and salt value for this crypto- 737 suite MUST be 30 characters, i.e., 240 bits; otherwise the crypto 738 attribute is considered invalid. 740 5.2.3 F8_128_HMAC_SHA1_80 742 This crypto-suite is identical to AES_CM_128_HMAC_SHA1_80 except the 743 cipher is F8 [srtp]. 745 The length of the base64 decoded key and salt value for this crypto- 746 suite MUST be 30 characters, i.e. 240 bits; otherwise the crypto 747 attribute is considered invalid. 749 5.2.4 Adding new Crypto-suite Definitions 751 If new transforms are added to SRTP, new definitions for those 752 transforms SHOULD be given for the SRTP security descriptions and 753 published in a Standards Track RFC. Sections 5.2.1 through 5.2.3 754 illustrate how to define crypto-suite values for particular 755 cryptographic transforms. Any new crypto-suites MUST be registered 756 with IANA following the procedures in section 9. 758 5.3 Session Parameters 760 SRTP security descriptions define a set of "session" parameters, 761 which OPTIONALLY may be used to override SRTP session defaults for 762 the SRTP and SRTCP streams. These parameters configure an RTP 763 session for SRTP services. The session parameters provide session- 764 specific information to establish the SRTP cryptographic context. 766 5.3.1 KDR=n 768 KDR specifies the Key Derivation Rate, as described in section 4.3.1 769 of [srtp]. 771 The value n MUST be an integer in the set {1,2,...,24}, which 772 denotes a power of 2 from 2^1 to 2^24, inclusive. The SRTP key 773 derivation rate controls how frequently a new session key is derived 774 from an SRTP master key(s) [srtp] given in the declaration. When 775 the key derivation rate is not specified (i.e., the KDR parameter is 776 omitted), a single initial key derivation is performed [srtp]. 778 In the offer/answer model, KDR is a declarative parameter. 780 5.3.2 UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP 782 SRTP and SRTCP packet payloads are encrypted by default. The 783 UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP session parameters modify the 784 default behavior of the crypto-suites with which they are used: 786 * UNENCRYPTED_SRTCP signals that the SRTCP packet payloads are not 787 encrypted. 789 * UNENCRYPTED_SRTP signals that the SRTP packet payloads are not 790 encrypted. 792 In the offer/answer model, these parameters are negotiated. 794 5.3.3 UNAUTHENTICATED_SRTP 796 SRTP and SRTCP packet payloads are authenticated by default. The 797 UNAUTHENTICATED_SRTP session parameter signals that SRTP messages 798 are not authenticated. Use of UNAUTHENTICATED_SRTP is NOT 799 RECOMMENDED (see Security Considerations). 801 The SRTP specification requires use of message authentication for 802 SRTCP, but not for SRTP [srtp]. 804 In the offer/answer model, this parameter is negotiated. 806 5.3.4 FEC_ORDER=order 808 FEC_ORDER signals the use of forward error correction for the RTP 809 packets [rfc2733]. The forward error correction values for "order" 810 are FEC_SRTP or SRTP_FEC. FEC_SRTP signals that FEC is applied 811 before SRTP processing by the sender of the SRTP media and after SRTP 812 processing by the receiver of the SRTP media; FEC_SRTP is the 813 default. SRTP_FEC is the reverse processing. 815 In the offer/answer model, FEC_ORDER is a declarative parameter. 817 5.3.5 FEC_KEY=key-params 819 FEC_KEY signals the use of separate master key(s) for a Forward 820 Error Correction (FEC) stream. The master key(s) are specified with 821 the exact same format as the SRTP Key Parameter defined in Section 822 5.1, and the semantic rules are the same - in particular, the master 823 key(s) MUST be different from all other master key(s) in the SDP. A 824 FEC_KEY MUST be specified when the FEC stream is sent to a different 825 IP-address and/or port than the media stream to which it applies 826 (i.e., the "m=" line), e.g., as described in RFC 2733 Section 11.1. 827 When a FEC stream is sent to the same IP-address and port as the 828 media stream to which it applies, a FEC_KEY MUST NOT be specified. 829 If a FEC_KEY is specified in this latter case, the crypto attribute 830 in question MUST be considered invalid. 832 In the offer/answer model, FEC_KEY is a declarative parameter. 834 5.3.6 Window Size Hint (WSH) 836 SRTP defines the SRTP-WINDOW-SIZE [srtp, section 3.3.2] parameter to 837 protect against replay attacks. The minimum value is 64 [srtp], 838 however this value may be considered too low for some applications 839 (e.g., video). 841 The Window Size Hint (WSH) session parameter provides a hint for how 842 big this window should be to work satisfactorily (e.g., based on 843 sender knowledge of number of packets per second). However, there 844 might be enough information given in SDP attributes like 845 "a=maxprate" [maxprate] and the bandwidth modifiers to allow a 846 receiver to derive the parameter satisfactorily. Consequently, this 847 value is only considered a hint to the receiver of the SDP which MAY 848 choose to ignore the value provided. 850 In the offer/answer model, WSH is a declarative parameter. 852 5.3.7 Defining New SRTP Session Parameters 854 New SRTP session parameters for the SRTP security descriptions can 855 be defined in a Standards Track RFC and registered with IANA 856 according to the registration procedures defined in Section 9. 858 New SRTP session parameters are by default mandatory. A newly- 859 defined SRTP session parameter that is prefixed with the dash 860 character ("-") however is considered optional and MAY be ignored. 861 If an SDP crypto attribute is received with an unknown session 862 parameter that is not prefixed with a "-" character, that crypto 863 attribute MUST be considered invalid. 865 5.4 SRTP Crypto Context Initialization 867 In addition to the various SRTP parameters defined above, there are 868 three pieces of information that are critical to the operation of the 869 default SRTP ciphers: 871 * SSRC: Synchronization source 872 * ROC: Roll-over counter for a given SSRC 873 * SEQ: Sequence number for a given SSRC 875 In a unicast session, as defined here, there are three constraints on 876 these values. 878 The first constraint is on the SSRC, which makes an SRTP keystream be 879 unique from other participants. As explained in SRTP, the keystream 880 MUST NOT be reused on two or more different pieces of plaintext. 881 Keystream reuse makes the ciphertext vulnerable to cryptanalysis. 882 One vulnerability is that known-plaintext fields in one stream can 883 expose portions of the reused keystream and this could further expose 884 more plaintext in other streams. Since all current SRTP encryption 885 transforms use keystreams, key sharing is a general problem [srtp]. 886 SRTP mitigates this problem by including the SSRC of the sender in 887 the keystream. But SRTP does not solve this problem in its entirety 888 because Real-time Transport Protocol has SSRC collisions, which are 889 very rare [rtp] but quite possible. During a collision, two or more 890 SSRCs that share a master key will have identical keystreams for 891 overlapping portions of the RTP sequence-number space. SRTP Security 892 Descriptions avoids keystream reuse by making unique master keys 893 REQUIRED for the sender and receiver of the security description. 894 Thus, the first constraint is satisfied. 896 Also note, that there is a second problem with SSRC collisions: The 897 SSRC is used to identify the crypto context and thereby the cipher, 898 key, ROC, etc. to process incoming packets. In case of SSRC 899 collisions, crypto context identification becomes ambiguous and 900 correct packet processing may not occur. Furthermore, if an RTCP 901 BYE packet is to be sent for a colliding SSRC, that packet may also 902 have to be secured. In a (unicast) point-to-multipoint scenario, 903 this can be problematic for the same reasons, i.e., it is not known 904 which of the possible crypto contexts to use. Note that these 905 problems are not unique to the SDP security descriptions; any use 906 of SRTP needs to consider them. 908 The second constraint is that the ROC MUST be zero at the time that 909 each SSRC commences sending packets. Thus, there is no concept of a 910 "late joiner" in SRTP security descriptions, which are constrained to 911 be unicast and pairwise. The ROC and SEQ form a "packet index" in 912 the default SRTP transforms and the ROC is consistently set to zero 913 at session commencement, according to this document. 915 The third constraint is that the initial value of SEQ SHOULD be 916 chosen to be within the range of 0..2^15-1; this avoids an ambiguity 917 when packets are lost at the start of the session. If at the start 918 of a session, an SSRC source might randomly select a high sequence- 919 number value and put the receiver in an ambiguous situation: If 920 initial packets are lost in transit up to the point that the sequence 921 number wraps (i.e., exceeds 2^16-1), then the receiver might not 922 recognize that its ROC needs to be incremented. By restricting the 923 initial SEQ to the range of 0..2^15-1, SRTP packet-index 924 determination will find the correct ROC value, unless all of the 925 first 2^15 packets are lost (which seems, if not impossible, then 926 rather unlikely). See Section 3.3.1 of the SRTP specification 927 regarding packet-index determination [srtp]. 929 5.4.1 Late Binding of one or more SSRCs to a crypto context 931 The packet index, therefore, depends on the SSRC, the SEQ of an 932 incoming packet and the ROC, which is an SRTP crypto context 933 variable. Thus, SRTP has a big security dependency on SSRC 934 uniqueness. 936 Given the above constraints, unicast SRTP crypto contexts can be 937 established without the need to negotiate SSRC values in the SRTP 938 security descriptions. Instead, an approach called "late binding" is 939 RECOMMENDED by this specification. When a packet arrives, the SSRC 940 that is contained in it can be bound to the crypto context at the 941 time of session commencement (i.e., SRTP packet arrival) rather than 942 at the time of session signaling (i.e., receipt of an SDP). With the 943 arrival of the packet containing the SSRC, all the data items needed 944 for the SRTP crypto context are held by the receiver (note that the 945 ROC value by definition is zero; if non-zero values were to be 946 supported, additional signaling would be required). In other words, 947 the crypto context for a secure RTP session using late binding is 948 initially identified by the SDP as: 950 <*, address, port> 952 where '*' is a wildcard SSRC, "address" is the local receive address 953 from the "c=" line, and "port" is the local receive port from the 954 "m=" line. When the first packet arrives with ssrcX in its SSRC 955 field, the crypto context 957 959 is instantiated subject to the following constraints: 961 * Media packets are authenticated: Authentication MUST succeed; 962 otherwise, the crypto context is not instantiated. 964 * Media packets are not authenticated: Crypto context is 965 automatically instantiated. 967 It should be noted, that use of late binding when there is no 968 authentication of the SRTP media packets is subject to numerous 969 security attacks and consequently it is NOT RECOMMENDED (of course, 970 this can be said for unauthenticated SRTP in general). 972 Note that use of late binding without authentication will result in 973 local state being created as a result of receiving a packet from 974 any unknown SSRC. UNAUTHENTICATED_SRTP, therefore is NOT 975 RECOMMENDED because it invites easy denial-of-service attack. In 976 contrast, late binding with authentication does not suffer from 977 this weakness. 979 5.4.2 Sharing cryptographic contexts among Sessions or SSRCs 981 With the constraints and procedures described above, it is not 982 necessary to explicitly signal the SSRC, ROC and SEQ for a unicast 983 RTP session. So there are no a=crypto parameters for signaling SSRC, 984 ROC or SEQ. Thus, multiple SSRCs from the same entity will share 985 a=crypto parameters when late binding is used. Multiple SSRCs from 986 the same entity arises due to either multiple sources (microphones, 987 cameras, etc.), or RTP payloads requiring SSRC multiplexing within 988 that same session. SDP also allows multiple RTP sessions to be 989 defined in the same media description ("m="), these RTP sessions will 990 also share the a=crypto parameters. An application that uses 991 a=crypto in this way serially shares a master key among RTP sessions 992 or SSRCs and MUST replace the master key when the aggregate number of 993 packets among all SSRCs approaches 2^31 packets. SSRCs that share a 994 master key MUST be unique from one another. 996 5.5 Removal of Crypto Contexts 998 The mechanism defined above addresses the issue of creating crypto 999 contexts, however in practice, session participants may want to 1000 remove crypto contexts prior to session termination. Since a crypto 1001 context contains information that can not automatically be recovered 1002 (e.g., ROC), it is important that the sender and receiver agree on 1003 when a crypto context can be removed, and perhaps more importantly 1004 when it cannot. 1006 Even when late binding is used for a unicast stream, the ROC is 1007 lost and cannot be recovered automatically (unless it is zero) once 1008 the crypto context is removed. 1010 We resolve this problem as follows. When SRTP security descriptions 1011 are being used, crypto-context removal MUST follow the same rules as 1012 SSRC removal from the member table [RFC 3550]; note that this can 1013 happen as the result of an SRTCP BYE packet or a simple time-out due 1014 to inactivity. Inactive session participants that wish to ensure 1015 their crypto contexts are not timed out MUST thus send SRTCP packets 1016 at regular intervals. 1018 6. SRTP-Specific Use of the crypto Attribute 1020 Section 4 describes general use of the crypto attribute, and this 1021 section completes it by describing SRTP-specific use. 1023 6.1 Use with Offer/Answer 1025 In this section, we describe how the SRTP security descriptions are 1026 used with the offer/answer model to negotiate cryptographic 1027 capabilities and communicate SRTP master keys. The rules defined 1028 below complement the general offer/answer rules defined in Section 1029 4.1, which MUST be followed, unless otherwise specified. Note that 1030 the rules below define unicast operation only; support for multicast 1031 and multipoint unicast streams is for further study. 1033 6.1.1 Generating the Initial Offer - Unicast Streams 1035 When the initial offer is generated, the offerer MUST follow the 1036 steps in Section 4.1.1 as well as the following steps. 1038 For each unicast media line (m=) using the secure RTP transport 1039 where the offerer wants to specify cryptographic parameters, the 1040 offerer MUST provide at least one valid SRTP security description 1041 ("a=crypto" line), as defined in Section 5. If the media stream 1042 includes Forward Error Correction with a different IP-address and/or 1043 port than the media stream itself, a FEC_KEY parameter MUST be 1044 included, as described in Section 5.3.5. 1046 The offerer MAY include one or more other SRTP session parameters as 1047 defined in Section 5.3. Note however, that if any SRTP session 1048 parameters are included that are not known to the answerer, but are 1049 nonetheless mandatory (see Section 5.3.6), the negotiation will fail 1050 if the answerer does not support them. 1052 6.1.2 Generating the Initial Answer - Unicast Streams 1054 When the initial answer is generated, the answerer MUST follow the 1055 steps in Section 4.1.2 as well as the following steps. 1057 For each unicast media line which uses the secure RTP transport and 1058 contains one or more "a=crypto" lines in the offer, the answerer 1059 MUST either accept one (and only one) of the crypto lines for that 1060 media stream, or it MUST reject the media stream. Only "a=crypto" 1061 lines that are considered valid SRTP security descriptions as 1062 defined in Section 5 can be accepted. Furthermore, all parameters 1063 (crypto-suite, key parameter, and mandatory session parameters) MUST 1064 be acceptable to the answerer in order for the offered media stream 1065 to be accepted. Note that if the media stream includes Forward 1066 Error Correction with a different IP-address and/or port than the 1067 media stream itself, a FEC_KEY parameter MUST be included, as 1068 described in Section 5.3.5. 1070 When the answerer accepts an SRTP unicast media stream with a crypto 1071 line, the answerer MUST include one or more master keys appropriate 1072 for the selected crypto algorithm; the master key(s) included in the 1073 answer MUST be different from those in the offer. 1075 When the master key(s) are not shared between the offerer and 1076 answerer, SSRC collisions between the offerer and answerer will not 1077 lead to keystream reuse, and hence SSRC collisions do not 1078 necessarily have to be prevented. 1080 If Forward Error Correction to a separate IP-address and/or port is 1081 included, the answer MUST include a FEC_KEY parameter, as described 1082 in Section 5.3.5. 1084 Declarative session parameters may be added to the answer as usual, 1085 however the answerer SHOULD NOT add any mandatory session parameter 1086 (see Section 5.3.6) that might be unknown to the offerer. 1088 If the answerer cannot find any valid crypto line that it supports, 1089 or if its configured policy prohibits any cryptographic key 1090 parameter (e.g., key length) or cryptographic session parameter 1091 (e.g., KDR, FEC_ORDER), it MUST reject the media stream, unless it 1092 is able to successfully negotiate use of SRTP by other means outside 1093 the scope of this document (e.g., by use of MIKEY [mikey]). 1095 6.1.3 Processing of the Initial Answer - Unicast Streams 1097 When the offerer receives the answer, it MUST perform the steps in 1098 Section 4.1.3 as well as the following steps for each SRTP media 1099 stream it offered with one or more crypto lines in it. 1101 If the media stream was accepted and it contains a crypto line, it 1102 MUST be checked that the crypto line is valid according to the 1103 constraints specified in Section 5 (including any FEC constraints). 1105 If the offerer either does not support or is not willing to honor 1106 one or more of the SRTP parameters in the answer, the offerer MUST 1107 consider the crypto line invalid. 1109 If the crypto line is not valid, or the offerer's configured policy 1110 prohibits any cryptographic key parameter (e.g. key length) or 1111 cryptographic session parameter, the SRTP security negotiation MUST 1112 be deemed to have failed. 1114 6.1.4 Modifying the Session 1116 When a media stream using the SRTP security descriptions has been 1117 established, and a new offer/answer exchange is performed, the 1118 offerer and answerer MUST follow the steps in Section 4.1.4 as well 1119 as the following steps. 1121 When modifying the session, all negotiated aspects of the SRTP media 1122 stream can be modified. For example, a new crypto suite can be used 1123 or a new master key can be established. As described in RFC 3264, 1124 when doing a new offer/answer exchange there will be a window of 1125 time, where the offerer and the answerer must be prepared to receive 1126 media according to both the old and the new offer/answer exchange. 1127 This requirement applies here as well, however the following should 1128 be noted: 1130 * When authentication is not being used, it may not be possible for 1131 either the offerer or the answerer to determine if a given packet 1132 is encrypted according to the old or new offer/answer exchange. 1133 RFC 3264 defines a couple of techniques to address this problem, 1134 e.g., changing the payload types used and/or the transport 1135 addresses. Note however that a change in transport addresses may 1136 have an impact on Quality of Service as well as firewall and NAT 1137 traversal. The SRTP security descriptions use the MKI to deal with 1138 this (which adds a few bytes to each SRTP packet) as described in 1139 Section 5.1. For further details on the MKI, please refer to 1140 [srtp]. 1142 * If the answerer changes its master key, the offerer will not 1143 be able to process packets secured via this master key until the 1144 answer is received. This could be addressed by using a security 1145 "precondition" [sprecon]. 1147 If the offerer includes an IP address and/or port that differs from 1148 that used previously for a media stream (or FEC stream), the offerer 1149 MUST include a new master key with the offer (and in so doing, it 1150 will be creating a new crypto context with the ROC set to zero). 1151 Similarly, if the answerer includes an IP address and/or port that 1152 differs from that used previously for a media stream (or FEC 1153 stream), the answerer MUST include a new master key with the offer 1154 (and hence create a new crypto context with the ROC set to zero). 1155 The reason for this is, that when the answerer receives an offer, or 1156 the offerer receives an answer, with an updated IP address and/or 1157 port, it is not possible to determine if the other side has access 1158 to the old crypto context parameters (and in particular the ROC) or 1159 not. For example, if one side is a decomposed gateway, or a back- 1160 to-back user agent is involved, it is possible that the media 1161 endpoint changed and no longer has access to the old crypto context. 1162 By always requiring a new master key in this case, the 1163 answerer/offerer will know that the ROC is zero for this 1164 offer/answer, and any key lifetime constraints will trivially be 1165 satisfied too. Another consideration here applies to media relays; 1166 if the relay changes the media endpoint on one side transparently to 1167 the other side, the relay cannot operate as a simple packet 1168 reflector but will have to actively engage in SRTP packet processing 1169 and transformation (i.e., decryption and re-encryption, etc.). 1171 Finally note, that if the new offer is rejected, the old crypto 1172 parameters remain in place. 1174 6.1.5 Offer/Answer Example 1176 In this example, the offerer supports two crypto suites (F8 and AES). 1177 The a=crypto line is actually one long line, although it is shown as 1178 two lines in this document due to page formatting. 1180 Offerer sends: 1181 v=0 1182 o=sam 2890844526 2890842807 IN IP4 10.47.16.5 1183 s=SRTP Discussion 1184 i=A discussion of Secure RTP 1185 u=http://www.example.com/seminars/srtp.pdf 1186 e=marge@example.com (Marge Simpson) 1187 c=IN IP4 168.2.17.12 1188 t=2873397496 2873404696 1189 m=audio 49170 RTP/SAVP 0 1190 a=crypto:1 AES_CM_128_HMAC_SHA1_80 1191 inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4 1192 FEC_ORDER=FEC_SRTP 1193 a=crypto:2 F8_128_HMAC_SHA1_80 1194 inline:MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm|2^20|1:4; 1195 inline:QUJjZGVmMTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5|2^20|2:4 1196 FEC_ORDER=FEC_SRTP 1198 Answerer replies: 1199 v=0 1200 o=jill 25690844 8070842634 IN IP4 10.47.16.5 1201 s=SRTP Discussion 1202 i=A discussion of Secure RTP 1203 u=http://www.example.com/seminars/srtp.pdf 1204 e=homer@example.com (Homer Simpson) 1205 c=IN IP4 168.2.17.11 1206 t=2873397526 2873405696 1207 m=audio 32640 RTP/SAVP 0 1208 a=crypto:1 AES_CM_128_HMAC_SHA1_80 1209 inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4 1211 In this case, the session would use the AES_CM_128_HMAC_SHA1_80 1212 crypto suite for the RTP and RTCP traffic. 1214 6.2 SRTP-Specific Use Outside Offer/Answer 1216 Use of SRTP security descriptions outside the offer/answer model is 1217 not defined. 1219 Use of SRTP security descriptions outside offer/answer could have 1220 been defined for sendonly media streams, however, there would not 1221 be a way to indicate the key to use for SRTCP by the receiver of 1222 said media stream. 1224 6.3 Support for SIP Forking 1226 As mentioned earlier, the security descriptions defined here do not 1227 support multicast media streams or multipoint unicast streams. 1228 However, in the SIP protocol, it is possible to receive several 1229 answers to a single offer due to the use of forking (see [SIP]). 1230 Receiving multiple answers leads to a couple of problems for the 1231 SRTP security descriptions: 1233 * Different answerers may choose different ciphers, keys, etc., 1234 however there is no way for the offerer to associate a particular 1235 incoming media packet with a particular answer. 1237 * Two or more answerers may pick the same SSRC and hence the SSRC 1238 collision problems mentioned earlier may arise. 1240 As stated earlier, the above point-to-multipoint cases are outside 1241 the scope of the SDP security descriptions. However, there is a way 1242 of supporting SIP forking: Change the multipoint scenario resulting 1243 from SIP forking into multiple two-party unicast cases. This is 1244 done as follows: 1246 For each answer received beyond the initial answer, issue a new 1247 offer to that particular answerer using a new receive transport 1248 address (IP address and port); note that this requires support for 1249 the SIP UPDATE method [RFC 3313]. Also, to ensure that two media 1250 sessions are not inadvertently established prior to the UPDATE being 1251 processed by one of them, use security preconditions [sprecon]. 1253 Finally, note that all the answerers will know the key(s) being 1254 proposed by the initial offer. If the offerer wants to ensure 1255 security with respect to other answerers, a new offer/answer 1256 exchange with a new key needs to be performed with the first 1257 answerer as well. 1259 6.4 SRTP-Specific Backwards Compatibility Considerations 1261 It is possible that the answerer supports the SRTP transport and 1262 accepts the offered media stream, yet it does not support the crypto 1263 attribute defined here. The offerer can recognize this situation by 1264 seeing an accepted SRTP media stream in the answer that does not 1265 include a crypto line. In that case, the security negotiation 1266 defined here MUST be deemed to have failed. 1268 Also, if a media stream with a given SRTP transport (e.g., 1269 "RTP/SAVP") is sent to a device that does not support SRTP, that 1270 media stream will be rejected. 1272 6.5 Operation with KEYMGT= and k= lines 1274 An offer MAY include both "a=crypto" and "a=keymgt" lines [keymgt]. 1275 Per SDP rules, the answerer will ignore attribute lines that it does 1276 not understand. If the answerer supports both "a=crypto" and 1277 "a=keymgt", the answer MUST include either "a=crypto" or "a=keymgt" 1278 but not both, as including both is undefined. 1280 An offer MAY include both "a=crypto" and "k=" lines [SDP]. Per SDP 1281 rules, the answerer will ignore attribute lines it does not 1282 understand. If the answerer supports both "a=crypto" and "k=", the 1283 answer MUST include either "a=crypto" or "k=" but not both, as 1284 including both is undefined. 1286 7. Security Considerations 1288 Like all SDP messages, SDP messages containing security 1289 descriptions, are conveyed in an encapsulating application protocol 1290 (e.g., SIP, MGCP, etc.). It is the responsibility of the 1291 encapsulating protocol to ensure the protection of the SDP security 1292 descriptions. Therefore, the application protocol SHOULD either 1293 invoke its own security mechanisms (e.g., secure multiparts) or 1294 alternatively utilize a lower-layer security service (e.g., TLS, or 1295 IPSec). This security service SHOULD provide strong message 1296 authentication and packet-payload encryption as well as effective 1297 replay protection. 1299 7.1 Authentication of packets 1301 Security descriptions as defined herein signal security services for 1302 RTP packets. RTP messages are vulnerable to a variety of attacks 1303 such as replay and forging. To limit these attacks, SRTP message 1304 integrity mechanisms SHOULD be used (SRTP replay protection is 1305 always enabled). 1307 7.2 Keystream Reuse 1309 SRTP security descriptions signal configuration parameters for SRTP 1310 sessions. Misconfigured SRTP sessions are vulnerable to attacks on 1311 their encryption services when running the crypto suites defined in 1312 Sections 5.2.1, 5.2.2, and 5.2.3. An SRTP encryption service is 1313 "misconfigured" when two or more media streams are encrypted using 1314 the same AES keystream. When senders and receivers share derived 1315 session keys, SRTP requires that the SSRCs of session participants 1316 serve to make their corresponding keystreams unique, which is 1317 violated in the case of SSRC collision: SRTP SSRC collision 1318 drastically weakens SRTP or SRTCP payload encryption during the time 1319 that identical keystreams were used [srtp]. An attacker, for 1320 example, might collect SRTP and SRTCP messages and await a 1321 collision. This attack on the AES-CM and AES-f8 encryption is 1322 avoided entirely when each media stream has its own unique master 1323 key in both the send and receive direction. This specification 1324 restricts use of SDP security description to unicast point-to-point 1325 streams so that keys are not shared between SRTP hosts, and the 1326 master keys used in the send and receive direction for a given media 1327 stream are unique. 1329 7.3 Signaling Authentication and Signaling Encryption 1331 There is no reason to incur the complexity and computational expense 1332 of SRTP, however, when its key establishment is exposed to 1333 unauthorized parties. In most cases, the SRTP crypto attribute and 1334 its parameters are vulnerable to denial of service attacks when they 1335 are carried in an unauthenticated SDP message. In some cases, the 1336 integrity or confidentiality of the RTP stream can be compromised. 1337 For example, if an attacker sets UNENCRYPTED for the SRTP stream in 1338 an offer, this could result in the answerer not decrypting the 1339 encrypted SRTP messages. In the worst case, the answerer might 1340 itself send unencrypted SRTP and leave its data exposed to snooping. 1342 Thus, MIME secure multiparts, IPsec, TLS, or some other data 1343 security service SHOULD be used to provide message authentication 1344 for the encapsulating protocol that carries the SDP messages having 1345 a crypto attribute (a=crypto). Furthermore, encryption of the 1346 encapsulating payload SHOULD be used because a master key parameter 1347 (inline) appears in the message. Failure to encrypt the SDP message 1348 containing an inline SRTP master key renders the SRTP authentication 1349 or encryption service useless in practically all circumstances. 1350 Failure to authenticate an SDP message that carries SRTP parameters 1351 renders the SRTP authentication or encryption service useless in 1352 most practical applications. 1354 When the communication path of the SDP message is routed through 1355 intermediate systems that inspect parts of the SDP message, security 1356 protocols such as IPsec or TLS SHOULD NOT be used for encrypting 1357 and/or authenticating the security description. In the case of 1358 intermediate-system processing of a message containing SDP security 1359 descriptions, the "a=crypto" attributes SHOULD be protected end-to- 1360 end so that the intermediate system can neither modify the security 1361 description nor access the keying material. Network or transport 1362 security protocols that terminate at each intermediate system, 1363 therefore, SHOULD NOT be used for protecting SDP security 1364 descriptions. A security protocol SHOULD allow the security 1365 descriptions to be encrypted and authenticated end-to-end 1366 independently of the portions of the SDP message that any 1367 intermediate system modifies or inspects: MIME secure multiparts 1368 are RECOMMENDED for the protection of SDP messages that are 1369 processed by intermediate systems. 1371 When the SDP parameters cannot be carried in an encrypted and 1372 authenticated SDP message, it is RECOMMENDED that a key management 1373 protocol be used instead of the security descriptions defined here 1374 (a=crypto). The proposed SDP key-mgmt extension [keymgt] allows 1375 authentication and encryption of the key management protocol data 1376 independently of the SDP message that carries it. The security of 1377 the SDP SRTP attribute, however, is as good as the data security 1378 protocol that protects the SDP message. For example, if an IPSec 1379 security association exists between the SDP source and destination 1380 endpoints, then this solution is more secure than use of the key- 1381 mgmt statement in an unauthenticated SDP message, which is 1382 vulnerable to tampering. 1384 8. Grammar 1386 In this section we first provide the ABNF grammar for the generic 1387 crypto attribute, and then we provide the ABNF grammar for the SRTP 1388 specific use of the crypto attribute. 1390 8.1 Generic "Crypto" Attribute Grammar 1392 The ABNF grammar for the crypto attribute is defined below: 1394 "a=crypto:" tag 1*WSP crypto-suite 1*WSP key-params 1395 *(1*WSP session-param) 1397 tag = 1*9DIGIT 1398 crypto-suite = 1*(ALPHA / DIGIT / "_") 1400 key-params = key-param *(";" key-param) 1401 key-param = key-method ":" key-info 1402 key-method = "inline" / key-method-ext 1403 key-method-ext = 1*(ALPHA / DIGIT / "_") 1404 key-info = %x21-3A / %x3C-7E ; visible (printing) characters 1405 ; except semi-colon 1406 session-param = 1*(VCHAR) ; visible (printing) characters 1408 where WSP, ALPHA, DIGIT, and VCHAR are defined in [RFC2234]. 1410 8.2 SRTP "Crypto" Attribute Grammar 1412 This section provides an Augmented BNF [RFC2234] grammar for the 1413 SRTP-specific use of the SDP crypto attribute: 1415 crypto-suite = srtp-crypto-suite 1416 key-method = srtp-key-method 1417 key-info = srtp-key-info 1418 session-param = srtp-session-param 1420 srtp-crypto-suite = "AES_CM_128_HMAC_SHA1_32" / 1421 "F8_128_HMAC_SHA1_32" / 1422 "AES_CM_128_HMAC_SHA1_80" / 1423 srtp-crypto-suite-ext 1425 srtp-key-method = "inline" 1426 srtp-key-info = key-salt "|" [lifetime] "|" [mki] 1428 key-salt = 1*(base64) ; binary key and salt values 1429 ; concatenated together, and then 1430 ; base64 encoded [section 6.8 of 1431 ; RFC2046] 1433 lifetime = ["2^"] 1*(DIGIT) ; see section 5.1 for "2^" 1434 mki = mki-value ":" mki-length 1435 mki-value = 1*DIGIT 1436 mki-length = 1*3DIGIT ; range 1..128. 1438 srtp-session-param = kdr / 1439 "UNENCRYPTED_SRTP" / 1440 "UNENCRYPTED_SRTCP" / 1441 "UNAUTHENTICATED_SRTP" / 1442 fec-order / 1443 fec-key / 1444 wsh / 1445 srtp-session-extension 1447 kdr = "KDR=" 1*2(DIGIT) ; range 0..24, power of two 1449 fec-order = "FEC_ORDER=" fec-type 1450 fec-type = "FEC_SRTP" / "SRTP_FEC" 1451 fec-key = "FEC_KEY=" key-params 1453 wsh = "WSH=" 2*DIGIT ; minimum value is 64 1454 base64 = ALPHA / DIGIT / "+" / "/" / "=" 1456 srtp-crypto-suite-ext = 1*(ALPHA / DIGIT / "_") 1457 srtp-session-extension = ["-"] 1*(VCHAR) ;visible chars [RFC2234] 1458 ; first character must not be dash ("-") 1460 9. IANA Considerations 1462 9.1 Registration of the "crypto" attribute 1464 The IANA is hereby requested to register a new SDP attribute as 1465 follows: 1467 Attribute name: crypto 1468 Long form name: Security description cryptographic attribute 1469 for media streams 1470 Type of attribute: Media-level 1471 Subject to charset: No 1472 Purpose: Security descriptions 1473 Appropriate values: See Section 3 1475 9.2 New IANA Registries and Registration Procedures 1476 The following sub-sections define a new IANA registry with associated 1477 sub-registries to be used for the SDP security descriptions. The 1478 IANA is hereby requested to create an SDP Security Description 1479 registry as shown below and further described in the following 1480 sections: 1482 SDP Security Descriptions 1483 | 1484 +- Key Methods (described in 9.2.1) 1485 | 1486 +- Media Stream Transports (described in 9.2.2) 1487 | 1488 +- Transport1 (e.g. SRTP) 1489 | | 1490 | +- Supported Key Methods (e.g. inline) 1491 | | 1492 | +- crypto suites 1493 | | 1494 | +- session parameters 1495 | 1496 +- Transport2 1497 : : 1499 9.2.1 Key Method Registry and Registration 1501 The IANA is hereby requested to create a new subregistry for SDP 1502 security description key methods. An IANA key method registration 1503 MUST be documented in an RFC in accordance with the RFC 2434 1504 Standards Action and it MUST provide the name of the key method in 1505 accordance with the grammar for key-method-ext defined in Section 1506 8.1. 1508 9.2.2 Media Stream Transport Registry and Registration 1510 The IANA is hereby requested to create a new subregistry for SDP 1511 security description Media Stream Transports. An IANA media stream 1512 transport registration MUST be documented in an RFC in accordance 1513 with the RFC 2434 Standards Action and the procedures defined in 1514 Section 3 and 4 of this document. The registration MUST provide the 1515 name of the transport and a list of supported key methods. 1517 In addition, each new media stream transport registry must contain a 1518 crypto-suite registry and a session parameter registry as well as 1519 IANA instructions for how to populate these registries. 1521 9.3 Initial Registrations 1523 9.3.1 Key Method 1524 The following security descriptions key methods are hereby 1525 registered: 1527 inline 1529 9.3.2 SRTP Media Stream Transport 1531 The IANA is hereby requested to create an SDP Security Description 1532 Media Stream Transport subregistry for "SRTP". The key methods 1533 supported is "inline". The reference for the SDP security 1534 description for SRTP is this document. 1536 9.3.2.1 SRTP Crypto Suite Registry and Registration 1538 The IANA is hereby requested to create a new subregistry for SRTP 1539 crypto suites under the SRTP transport of the SDP Security 1540 Descriptions. An IANA SRTP crypto suite registration MUST indicate 1541 the crypto suite name in accordance with the grammar for srtp- 1542 crypto-suite-ext defined in Section 8.2. 1544 The semantics of the SRTP crypto suite MUST be described in an RFC 1545 in accordance with the RFC 2434 Standards Action, including the 1546 semantics of the "inline" key-method and any special semantics of 1547 parameters. 1549 The following SRTP crypto suites are hereby registered: 1551 AES_CM_128_HMAC_SHA1_80 1552 AES_CM_128_HMAC_SHA1_32 1553 F8_128_HMAC_SHA1_80 1555 The reference for these crypto-suites is provided in this document. 1557 9.3.2.2 SRTP Session Parameter Registration 1559 The IANA is hereby requested to create a new subregistry for SRTP 1560 session parameters under the SRTP transport of the SDP Security 1561 Descriptions. An IANA SRTP session parameter registration MUST 1562 indicate the session parameter name (srtp-session-extension as 1563 defined in Section 8.2); the name MUST NOT begin with the dash 1564 character ("-"). 1566 The semantics of the parameter MUST be described in an RFC in 1567 accordance with the RFC 2434 Standards Action. If values can be 1568 assigned to the parameter, then the format and possible values that 1569 can be assigned MUST be described in the RFC in accordance with the 1570 RFC 2434 Standards Action as well. Also, it MUST be specified 1571 whether the parameter is declarative or negotiated in the 1572 offer/answer model. 1574 The following SRTP session parameters are hereby registered: 1576 KDR 1577 UNENCRYPTED_SRTP 1578 UNENCRYPTED_SRTCP 1579 UNAUTHENTICATED_SRTP 1580 FEC_ORDER 1581 FEC_KEY 1582 WSH 1584 The reference for these parameters is this document. 1586 10. Acknowledgements 1588 This document is a product of the IETF MMUSIC working group and has 1589 benefited from comments from its participants. This document also 1590 benefited from discussions with Elisabetta Cararra, Earl Carter, 1591 Bill Foster, Matt Hammer, Cullen Jennings, Paul Kyzivat, David 1592 McGrew, Mats Naslund, Dave Oran, Jonathan Rosenberg, Dave Singer, 1593 Mike Thomas, Brian Weis, and Magnus Westerlund. These people shared 1594 observations, identified errors and made suggestions for improving 1595 the specification. Magnus provided many useful comments and Mats 1596 made several valuable suggestions on parameters and syntax that are 1597 in the current draft. Dave Oran and Mike Thomas encouraged us to 1598 bring this work to the IETF for standardization. David McGrew 1599 suggested the conservative approach of requiring unique master keys 1600 for each unicast SDP media stream as followed in this document. 1601 Paul Kyzivat suggested how to handle SIP forking. Jonathan 1602 Rosenberg suggested reducing the complexity by specifying only one 1603 security parameter for each media stream. 1605 11. Authors' Addresses 1607 Flemming Andreasen 1608 Cisco Systems, Inc. 1609 499 Thornall Street, 8th Floor 1610 Edison, New Jersey 08837 USA 1611 fandreas@cisco.com 1613 Mark Baugher 1614 5510 SW Orchid Street 1615 Portland, Oregon 97219 USA 1616 mbaugher@cisco.com 1618 Dan Wing 1619 Cisco Systems, Inc. 1620 170 West Tasman Drive 1621 San Jose, CA 95134 USA 1622 dwing@cisco.com 1624 12. Normative References 1626 [RFC3550] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, 1627 "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, 1628 STD 64, July 2003, http://www.ietf.org/rfc/rfc3550.txt. 1630 [RFC2234] D. Crocker, P. Overell, "Augmented BNF for Syntax 1631 Specifications: ABNF," RFC 2234, November 1997, 1632 http://www.ietf.org/rfc/rfc2234.txt. 1634 [SDP] M. Handley, V. Jacobson, "SDP: Session Description Protocol", 1635 RFC 2327, April 1998. 1637 [RFC2828] R. Shirey, "Internet Security Glossary", RFC 2828, May 1638 2000, http://www.ietf.org/rfc/rfc2828.txt. 1640 [RFC3264] J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with 1641 the Session Description Protocol (SDP)", RFC 3264, June 2202, 1642 http://www.ietf.org/rfc/rfc3264.txt. 1644 [srtp] M. Baugher, D. McGrew, M. Naslund, E. Carrara, K. Norrman, 1645 "The Secure Real-time Transport Protocol", RFC 3711, March 2004. 1647 [RFC1750] D. Eastlake 3rd, S. Crocker, J. Schiller, "Randomness 1648 Recommendations for Security", RFC 1750, December 1994, 1649 http://www.ietf.org/rfc/rfc1750.txt. 1651 [RFC3548] S. Josefsson, "The Base16, Base32, and Base64 Data 1652 Encodings", RFC 3548, July 2003. 1654 [RFC2434] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA 1655 Considerations Section in RFCs", RFC 2434, October 1998. 1657 13. Informative References 1659 [RFC3407] F. Andreasen, "Session Description Protocol (SDP) Simple 1660 Capability Declaration", RFC 3407, October 2002, 1661 http://www.ietf.org/rfc/rfc3407.txt. 1663 [Bellovin] Steven M. Bellovin, "Problem Areas for the IP Security 1664 Protocols," in Proceedings of the Sixth Usenix Unix Security 1665 Symposium, pp. 1-16, San Jose, CA, July 1996. 1667 [GDOI] M. Baugher, B. Weis, T. Hardjono, H. Harney, "The Group 1668 Domain of Interpretation", RFC 3547, July 2003, 1669 http://www.ietf.org/rfc/rfc3547.txt. 1671 [kink] M. Thomas, J. Vilhuber, "Kerberized Internet Negotiation of 1672 Keys (KINK)", Work in Progress. 1674 [ike] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", RFC 1675 2409, November 1998, http://www.ietf.org/rfc/rfc2409.txt. 1677 [ipsec] Kent, S. and R. Atkinson, "Security Architecture for the 1678 Internet Protocol", RFC 2401, November 1998, 1679 http://www.ietf.org/rfc/rfc2401.txt. 1681 [maxprate] Westerlund, M., "A Transport-independent Bandwidth 1682 Modifier for the Session Description Protocol (SDP)," April 2004, 1683 http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-bwparam- 1684 06.txt 1686 [RFC2733] J. Rosenberg, H. Schulzrinne, "An RTP Payload Format for 1687 Generic Forward Error Correction", RFC 2733, December 1999, 1688 http://www.ietf.org/rfc/rfc2733.txt. 1690 [s/mime] Ramsdell B., "S/MIME Version 3 Message Specification", RFC 1691 2633, June 1999, http://www.ietf.org/rfc/rfc2633.txt. 1693 [pgp/mime] M. Elkins, "MIME Security with Pretty Good Privacy 1694 (PGP)", RFC 2015, October 1996, http://www.ietf.org/rfc/rfc2015.txt. 1696 [tls] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 1697 2246, January 1999, http://www.ietf.org/rfc/rfc2246.txt. 1699 [keymgt] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman, 1700 "Key Management Extensions for SDP and RTSP", Work in Progress. 1702 [mikey] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman, 1703 "MIKEY: Multimedia Internet KEYing", Work in Progress. 1705 [RFC2045] N. Freed, N. Borenstein, "Multipurpose Internet Mail 1706 Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 1707 2045, November 1996, http://www.ietf.org/rfc/rfc2045.txt. 1709 [RFC2104] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing 1710 for Message Authentication", RFC 2014, November 1997, 1711 http://www.ietf.org/rfc/rfc2104.txt. 1713 [skeme] H. Krawczyk, "SKEME: A Versatile Secure Key Exchange 1714 Mechanism for the Internet", ISOC Secure Networks and Distributed 1715 Systems Symposium, San Diego, 1996. 1717 [RFC3312] G. Camarillo, W. Marshall, J. Rosenberg, "Integration of 1718 Resource Management and Session Initiation Protocol (SIP)", RFC 1719 3312, October 2002, http://www.ietf.org/rfc/rfc3312.txt. 1721 [RFC2974] M. Handley, C. Perkins, E. Whelan, "Session Announcement 1722 Protocol", RFC 2974, October 2000, 1723 http://www.ietf.org/rfc/rfc2974.txt. 1725 [srtpf] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 1726 RTCP-based Feedback (RTP/SAVPF)", work in progress, October 2003. 1728 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1729 A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1730 Session Initiation Protocol", RFC 3261, June 2002. 1732 [sprecon] Andreasen, F., Baugher, M., and D. Wing, "Security 1733 Preconditions for Session Description Protocol Media Streams", work 1734 in progress, February 2004. 1736 14. Full Copyright Statement 1738 Copyright (C) The Internet Society (2004). This document is subject 1739 to the rights, licenses and restrictions contained in BCP 78 and 1740 except as set forth therein, the authors retain all their rights. 1742 This document and the information contained herein are provided on 1743 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1744 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1745 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1746 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1747 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1748 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1750 Intellectual Property 1752 The IETF takes no position regarding the validity or scope of any 1753 Intellectual Property Rights or other rights that might be claimed 1754 to pertain to the implementation or use of the technology 1755 described in this document or the extent to which any license 1756 under such rights might or might not be available; nor does it 1757 represent that it has made any independent effort to identify any 1758 such rights. Information on the procedures with respect to 1759 rights in RFC documents can be found in BCP 78 and BCP 79. 1761 Copies of IPR disclosures made to the IETF Secretariat and any 1762 assurances of licenses to be made available, or the result of an 1763 attempt made to obtain a general license or permission for the use 1764 of such proprietary rights by implementers or users of this 1765 specification can be obtained from the IETF on-line IPR repository 1766 at http://www.ietf.org/ipr. 1768 The IETF invites any interested party to bring to its attention 1769 any copyrights, patents or patent applications, or other 1770 proprietary rights that may cover technology that may be required 1771 to implement this standard. Please address the information to the 1772 IETF at ietf-ipr@ietf.org. 1774 Acknowledgement 1776 Funding for the RFC Editor function is currently provided by the 1777 Internet Society.