idnits 2.17.1 draft-ietf-mmusic-sdescriptions-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1790. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1801. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1808. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1814. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1782), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 131: '...ignaling. Implementations MUST employ...' RFC 2119 keyword, line 134: '... of SIP [RFC3261], the application SHOULD employ either the SIPS URI...' RFC 2119 keyword, line 137: '... security is NOT RECOMMENDED since the...' RFC 2119 keyword, line 235: '...ine. The "crypto" attribute MUST only...' RFC 2119 keyword, line 256: '...ion 9.1 for details). The tag MUST be...' (128 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 129 has weird spacing: '...aterial withi...' == Line 570 has weird spacing: '...applied to a ...' == Line 1373 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 147, but not defined == Missing Reference: 'TLS' is mentioned on line 198, but not defined == Missing Reference: 'RFC 3550' is mentioned on line 1042, but not defined == Missing Reference: 'SIP' is mentioned on line 1267, but not defined == Missing Reference: 'RFC 3313' is mentioned on line 1287, but not defined == Missing Reference: 'RFC3711' is mentioned on line 1356, but not defined == Unused Reference: 'RFC3550' is defined on line 1668, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 1696, but no explicit reference was found in the text == Unused Reference: 'Bellovin' is defined on line 1709, but no explicit reference was found in the text == Unused Reference: 'RFC2733' is defined on line 1732, but no explicit reference was found in the text == Unused Reference: 'RFC2045' is defined on line 1751, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 1755, but no explicit reference was found in the text == Unused Reference: 'RFC3312' is defined on line 1763, but no explicit reference was found in the text == Unused Reference: 'RFC2974' is defined on line 1767, 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: 13 errors (**), 0 flaws (~~), 21 warnings (==), 9 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: December 2005 Cisco Systems 6 June, 2005 8 Session Description Protocol Security Descriptions 9 for Media Streams 10 12 Status of this memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or cite them other than as "work in progress". 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/lid-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). All Rights Reserved. 38 Abstract 40 This document defines a Session Description Protocol (SDP) 41 cryptographic attribute for unicast media streams. The attribute 42 describes a cryptographic key and other parameters, which serve to 43 configure security for a unicast media stream in either a single 44 message or a roundtrip exchange. The attribute can be used with a 45 variety of SDP media transports and this document defines how to use 46 it for the Secure Real-time Transport Protocol (SRTP) unicast media 47 streams. The SDP crypto attribute requires the services of a data 48 security protocol to secure the SDP message. 50 Table of Contents 52 1 Applicability.....................................................3 53 2 Notational Conventions............................................3 54 3 Introduction......................................................4 55 4 SDP "Crypto" Attribute and Parameters.............................5 56 4.1 Tag............................................................5 57 4.2 Crypto-suite...................................................6 58 4.3 Key Parameters.................................................6 59 4.4 Session Parameters.............................................7 60 4.5 Example........................................................7 61 5 General Use of the crypto Attribute...............................8 62 5.1 Use With Offer/Answer..........................................8 63 5.1.1 Generating the Initial Offer - Unicast Streams............8 64 5.1.2 Generating the Initial Answer - Unicast Streams...........9 65 5.1.3 Processing of the Initial Answer - Unicast Streams.......10 66 5.1.4 Modifying the Session....................................10 67 5.2 Use Outside Offer/Answer......................................11 68 5.3 General Backwards Compatibility Considerations................11 69 6 SRTP Security Descriptions.......................................11 70 6.1 SRTP Key Parameter............................................12 71 6.2 Crypto-suites.................................................15 72 6.2.1 AES_CM_128_HMAC_SHA1_80..................................15 73 6.2.2 AES_CM_128_HMAC_SHA1_32..................................16 74 6.2.3 F8_128_HMAC_SHA1_80......................................16 75 6.2.4 Adding new Crypto-suite Definitions......................16 76 6.3 Session Parameters............................................16 77 6.3.1 KDR=n....................................................16 78 6.3.2 UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP...................17 79 6.3.3 UNAUTHENTICATED_SRTP.....................................17 80 6.3.4 FEC_ORDER=order..........................................17 81 6.3.5 FEC_KEY=key-params.......................................17 82 6.3.6 Window Size Hint (WSH)...................................18 83 6.3.7 Defining New SRTP Session Parameters.....................18 84 6.4 SRTP Crypto Context Initialization............................18 85 6.4.1 Late Binding of one or more SSRCs to a crypto context....20 86 6.4.2 Sharing cryptographic contexts among Sessions or SSRCs...21 87 6.5 Removal of Crypto Contexts....................................21 88 7 SRTP-Specific Use of the crypto Attribute........................21 89 7.1 Use with Offer/Answer.........................................21 90 7.1.1 Generating the Initial Offer - Unicast Streams...........22 91 7.1.2 Generating the Initial Answer - Unicast Streams..........22 92 7.1.3 Processing of the Initial Answer - Unicast Streams.......23 93 7.1.4 Modifying the Session....................................23 94 7.1.5 Offer/Answer Example.....................................24 95 7.2 SRTP-Specific Use Outside Offer/Answer........................25 96 7.3 Support for SIP Forking.......................................26 97 7.4 SRTP-Specific Backwards Compatibility Considerations..........26 98 7.5 Operation with KEYMGT= and k= lines...........................27 99 8 Security Considerations..........................................27 100 8.1 Authentication of packets.....................................28 101 8.2 Keystream Reuse...............................................28 102 8.3 Signaling Authentication and Signaling Encryption.............28 103 9 Grammar..........................................................29 104 9.1 Generic "Crypto" Attribute Grammar............................29 105 9.2 SRTP "Crypto" Attribute Grammar...............................30 107 10 IANA Considerations.............................................31 108 10.1 Registration of the "crypto" attribute......................31 109 10.2 New IANA Registries and Registration Procedures.............31 110 10.2.1 Key Method Registry and Registration.....................31 111 10.2.2 Media Stream Transport Registry and Registration.........32 112 10.3 Initial Registrations.......................................32 113 10.3.1 Key Method...............................................32 114 10.3.2 SRTP Media Stream Transport..............................32 115 11 Acknowledgements................................................33 116 12 Authors' Addresses..............................................33 117 13 Normative References............................................34 118 14 Informative References..........................................34 119 15 Full Copyright Statement........................................36 121 1 Applicability 123 RFC YYYY {Note to RFC Editor: replace "YYYY" with RFC number for 124 [keymgt]} provides similar cryptographic key distribution 125 capabilities, and is intended for use when the signaling is to be 126 confidential and/or integrity-protected separately from the keying 127 material. 129 In contrast, this specification carries the keying material within 130 the SDP message, and it is intended for use when the keying material 131 is protected along with the signaling. Implementations MUST employ 132 security mechanisms that provide confidentiality and integrity for 133 the keying material. When this specification is used in the context 134 of SIP [RFC3261], the application SHOULD employ either the SIPS URI 135 or S/MIME to provide protection for the SDP message and the keying 136 material that it contains. The use of transport layer or IP layer 137 security is NOT RECOMMENDED since the protection of the SDP message 138 and the keying material that it contains cannot be ensured through 139 all intermediate entities such as SIP proxies. 141 2 Notational Conventions 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD 144 NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 145 be interpreted as described in [RFC2119]. The terminology in this 146 document conforms to [RFC2828], "Internet Security Glossary". 148 n^r is exponentiation where n is multiplied by itself r times; n and 149 r are integers. 0..k is an integer range of all integers from 0 150 through k inclusive. 152 The terms 'transport' and 'media transport' are used to mean 153 'transport protocol' as defined in RFC2327, page 20. 155 Explanatory notes are provided in several places throughout the 156 document; these notes are indented two spaces from the surrounding 157 text. 159 3 Introduction 161 The Session Description Protocol (SDP) [SDP] describes multimedia 162 sessions, which can be audio, video, whiteboard, fax, modem, and 163 other media streams. Security services such as data origin 164 authentication, integrity and confidentiality are often needed for 165 those streams. The Secure Real-time Transport Protocol (SRTP) [srtp] 166 provides security services for RTP media and is signaled by use of 167 secure RTP transport (e.g., "RTP/SAVP" or "RTP/SAVPF") in an SDP 168 media (m=) line. However, there are no means within SDP itself to 169 configure SRTP beyond using default values. This document specifies 170 a new SDP attribute called "crypto", which is used to signal and 171 negotiate cryptographic parameters for media streams in general, and 172 SRTP in particular. The definition of the crypto attribute in this 173 document is limited to two-party unicast media streams where each 174 source has a unique cryptographic key; support for multicast media 175 streams or multipoint unicast streams is for further study. 177 The crypto attribute is defined in a generic way to enable its use 178 with SRTP and any other secure transports that can establish 179 cryptographic parameters with only a single message or in a single 180 round-trip exchange using the offer/answer model [RFC3264]. 181 Extension to transports other than SRTP, however, is beyond the scope 182 of this document. Each type of secure media transport needs its own 183 specification for the crypto-attribute parameter. These definitions 184 are frequently unique to the particular type of transport and must be 185 specified in a Standards Track RFC and registered with IANA according 186 to the procedures defined in Section 10. This document defines the 187 security parameters and keying material for SRTP only. 189 It would be self-defeating not to secure cryptographic keys and other 190 parameters at least as well as the data is secured. Data security 191 protocols such as SRTP rely upon a separate key management system to 192 securely establish encryption and/or authentication keys. Key 193 management protocols provide authenticated key establishment (AKE) 194 procedures to authenticate the identity of each endpoint and protect 195 against man-in-the-middle, reflection/replay, connection hijacking 196 and some denial of service attacks [skeme]. Along with the key, an 197 AKE protocol such as MIKEY [mikey], GDOI [GDOI], KINK [kink], IKE 198 [ike], Secure Multiparts [s/mime, pgp/mime] or TLS [TLS] securely 199 disseminates information describing both the key and the data- 200 security session. AKE is needed because it is pointless to provide a 201 key over a medium where an attacker can snoop the key, alter the 202 definition of the key to render it useless, or change the parameters 203 of the security session to gain unauthorized access to session- 204 related information. 206 SDP, however, was not designed to provide AKE services, and the media 207 security descriptions defined in this document do not add AKE 208 services to SDP. This specification is no replacement for a key 209 management protocol or for the conveyance of key management messages 210 in SDP [keymgt]. The SDP security descriptions defined here are 211 suitable for restricted cases only where IPsec, TLS, or some other 212 encapsulating data-security protocol (e.g., SIP S/MIME) protects the 213 SDP message. This document adds security descriptions to those 214 encrypted and/or authenticated SDP messages through the new SDP 215 "crypto" attribute, which provides the cryptographic parameters of a 216 media stream. 218 The "crypto" attribute can be adapted to any media transport, but its 219 precise definition is unique to a particular transport. 221 In Section 4, we introduce the general SDP crypto attribute, and in 222 Section 5 we define how it is used with and without the offer/answer 223 model. In Section 6, we define the crypto attribute details needed 224 for SRTP, and in Section 7 we define SRTP-specific use of the 225 attribute with and without the offer/answer model. Section 8 recites 226 security considerations, and Section 9 gives an Augmented-BNF grammar 227 for the general crypto attribute as well as the SRTP-specific use of 228 the crypto attribute. IANA considerations are provided in Section 229 10. 231 4 SDP "Crypto" Attribute and Parameters 233 A new media-level SDP attribute called "crypto" describes the 234 cryptographic suite, key parameters, and session parameters for the 235 preceding unicast media line. The "crypto" attribute MUST only 236 appear at the SDP media level (not at the session level). The 237 "crypto" attribute follows the format (see Section 9.1 for the formal 238 ABNF grammar): 240 a=crypto: [] 242 The fields tag, crypto-suite, key-params, and session-params are 243 described in the following sub-sections. Below we show an example of 244 the crypto attribute for the "RTP/SAVP" transport, i.e., the secure 245 RTP extension to the Audio/Video Profile [srtp]. In the following, 246 newlines are included for formatting reasons only: 248 a=crypto:1 AES_CM_128_HMAC_SHA1_80 249 inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:32 251 The crypto-suite is AES_CM_128_HMAC_SHA1_80, key-params is defined 252 by the text starting with "inline:", and session-params is omitted. 254 4.1 Tag 255 The tag is a decimal number used as an identifier for a particular 256 crypto attribute (see Section 9.1 for details). The tag MUST be 257 unique among all crypto attributes for a given media line. It is 258 used with the offer/answer model to determine which of several 259 offered crypto attributes were chosen by the answerer (see Section 260 5.1). 262 In the offer/answer model, the tag is a negotiated parameter. 264 4.2 Crypto-suite 266 The crypto-suite field is an identifier that describes the encryption 267 and authentication algorithms (e.g., AES_CM_128_HMAC_SHA1_80) for 268 the transport in question (see Section 9.1 for details). The 269 possible values for the crypto-suite parameter are defined within the 270 context of the transport, i.e., each transport defines a separate 271 namespace for the set of crypto-suites. For example, the crypto- 272 suite "AES_CM_128_HMAC_SHA1_80" defined within the context 273 "RTP/SAVP" transport applies to Secure RTP only; the string may be 274 reused for another transport (e.g., "RTP/SAVPF" [srtpf]), but a 275 separate definition would be needed. 277 In the offer/answer model, the crypto-suite is a negotiated 278 parameter. 280 4.3 Key Parameters 282 The key-params field provides one or more sets of keying material for 283 the crypto-suite in question. The field consists of a method 284 indicator followed by a colon, and the actual keying information as 285 shown below (the formal grammar is provided in Section 9.1): 287 key-params = ":" 289 Keying material might be provided by different means than key-params, 290 however this is out of scope. Only one method is defined in this 291 document, namely "inline", which indicates that the actual keying 292 material is provided in the key-info field itself. There is a single 293 name space for the key-method, i.e., the key-method is transport 294 independent. New key-methods (e.g., use of a URL) may be defined in 295 a Standards Track RFC in the future. Although the key-method itself 296 may be generic, the accompanying key-info definition is specific not 297 only to the key-method, but also to the transport in question. Key- 298 info encodes keying material for a crypto suite, which defines that 299 keying material. New key methods MUST be registered with the IANA 300 according to the procedures defined in Section 10.2.1. 302 Key-info is defined as a general character string (see Section 9.1 303 for details); further transport and key-method specific syntax and 304 semantics MUST be provided in a Standards Track RFC for each 305 combination of transport and key-method that use it; definitions for 306 SRTP are provided in Section 6. Note that such definitions are 307 provided within the context of both a particular transport (e.g., 308 "RTP/SAVP") and a specific key-method (e.g., "inline"). IANA will 309 register the list of supported key methods for each transport. 311 When multiple keys are included in the key parameters, it MUST be 312 possible to determine which of the keys is being used in a given 313 media packet by a simple inspection of the media packet received; a 314 trial-and-error approach between the possible keys MUST NOT be 315 performed. 317 For SRTP, this could be achieved by use of Master Key Identifiers 318 (MKI) [srtp]. Use of <"From, "To"> values are not supported in 319 SRTP security descriptions for reasons explained in Section 6.1, 320 below. 322 In the offer/answer model, the key parameter is a declarative 323 parameter. 325 4.4 Session Parameters 327 Session parameters are specific to a given transport and use of them 328 is OPTIONAL in the security descriptions framework, where they are 329 just defined as general character strings. If session parameters are 330 to be used for a given transport, then transport-specific syntax and 331 semantics MUST be provided in a Standards Track RFC; definitions for 332 SRTP are provided in Section 6. 334 In the offer/answer model, session parameters may be either 335 negotiated or declarative; the definition of specific session 336 parameters MUST indicate whether they are negotiated or declarative. 337 Negotiated parameters apply to data sent in both directions, whereas 338 declarative parameters apply only to media sent by the entity that 339 generated the SDP. Thus, a declarative parameter in an offer applies 340 to media sent by the offerer, whereas a declarative parameter in an 341 answer applies to media sent by the answerer. 343 4.5 Example 345 This example shows use of the crypto attribute for the "RTP/SAVP" 346 media transport type (as defined in Section 5). The "a=crypto" line 347 is actually one long line; it is shown as two lines due to page 348 formatting: 350 v=0 351 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 352 s=SDP Seminar 353 i=A Seminar on the session description protocol 354 u=http://www.example.com/seminars/sdp.pdf 355 e=j.doe@example.com (Jane Doe) 356 c=IN IP4 161.44.17.12/127 357 t=2873397496 2873404696 358 m=video 51372 RTP/SAVP 31 359 a=crypto:1 AES_CM_128_HMAC_SHA1_80 360 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 361 m=audio 49170 RTP/SAVP 0 362 a=crypto:1 AES_CM_128_HMAC_SHA1_32 363 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 364 m=application 32416 udp wb 365 a=orient:portrait 367 This SDP message describes three media streams, two of which use the 368 "RTP/SAVP" transport. Each has a crypto attribute for the 369 "RTP/SAVP" transport. These secure-RTP specific descriptions are 370 defined in Section 6. 372 5 General Use of the crypto Attribute 374 In this section, we describe the general use of the crypto attribute 375 outside of any transport or key-method specific rules. 377 5.1 Use With Offer/Answer 379 The general offer/answer rules for the crypto attribute are in 380 addition to the rules specified in RFC 3264, which MUST be followed, 381 unless otherwise noted. RFC 3264 defines operation for both unicast 382 and multicast streams; the sections below describe operation for two- 383 party unicast streams only, since support for multicast streams (and 384 multipoint unicast streams) is for further study. 386 5.1.1 Generating the Initial Offer - Unicast Streams 388 When generating an initial offer for a unicast stream, there MUST be 389 one or more crypto attributes present for each media stream for which 390 security is desired. Each crypto attribute for a given media stream 391 MUST contain a unique tag. 393 The ordering of multiple "a=crypto" lines is significant: The most 394 preferred crypto line is listed first. Each crypto attribute 395 describes the crypto-suite, key(s) and possibly session parameters 396 offered for the media stream. In general, a "more preferred" crypto- 397 suite SHOULD be cryptographically stronger than a "less preferred" 398 crypto-suite. 400 The crypto-suite always applies to media in the directions supported 401 by the media stream (e.g., send and receive). The key(s), however, 402 apply to media in the direction from the offerer to the answerer; if 403 the media stream is marked as "recvonly", a key MUST still be 404 provided. 406 This is done for consistency. Also, in the case of SRTP, for 407 example, secure RTCP will still be flowing in both the send and 408 receive direction for a unidirectional stream. 410 The offer may include session parameters. There are no general offer 411 rules for the session parameters; instead, specific rules may be 412 provided as part of the transport-specific definitions of any session 413 parameters. 415 When issuing an offer, the offerer MUST be prepared to support media 416 security in accordance with any of the crypto attributes included in 417 the offer. There are however two problems associated with this. 418 First of all, the offerer does not know which key the answerer will 419 be using for media sent to the offerer. Second, the offerer may not 420 be able to deduce which of the offered crypto attributes were 421 accepted. Since media may arrive prior to the answer, delay or 422 clipping can occur. If this is unacceptable to the offerer, the 423 offerer SHOULD use a mechanism outside the scope of this document to 424 prevent the above problem. 426 For example, in SIP [RFC3261], a "security" precondition as defined 427 in [sprecon] could solve the above problem. 429 5.1.2 Generating the Initial Answer - Unicast Streams 431 When the answerer receives the initial offer with one or more crypto 432 attributes for a given unicast media stream, the answerer MUST either 433 accept exactly one of the offered crypto attributes, or the offered 434 stream MUST be rejected. 436 If the answerer wishes to indicate support for other crypto 437 attributes, those can be listed by use of the SDP Simple Capability 438 Declaration [RFC3407] extensions. 440 Only crypto attributes that are valid can be accepted; valid 441 attributes do not violate any of the general rules defined for 442 security descriptions as well as any specific rules defined for the 443 transport and key-method in question. When selecting one of the 444 valid crypto attributes, the answerer SHOULD select the most 445 preferred crypto attribute it can support, i.e., the first valid 446 supported crypto attribute in the list, considering the answerer's 447 capabilities and security policies. 449 If there are one or more crypto attributes in the offer, but none of 450 them are valid, or none of the valid ones are supported, the offered 451 media stream MUST be rejected. 453 When an offered crypto attribute is accepted, the crypto attribute in 454 the answer MUST contain the following: 456 * The tag and crypto-suite from the accepted crypto attribute in the 457 offer (the same crypto-suite MUST be used in the send and receive 458 direction). 459 * The key(s) the answerer will be using for media sent to the 460 offerer. Note that a key MUST be provided, irrespective of any 461 direction attributes in the offer or answer. 463 Furthermore, any session parameters that are negotiated MUST be 464 included in the answer. Declarative session parameters provided by 465 the offerer are not included in the answer, however the answerer may 466 provide its own set of declarative session parameters. 468 Once the answerer has accepted one of the offered crypto attributes, 469 the answerer MAY begin sending media to the offerer in accordance 470 with the selected crypto attribute. Note however, that the offerer 471 may not be able to process such media packets correctly until the 472 answer has been received. 474 5.1.3 Processing of the Initial Answer - Unicast Streams 476 When the offerer receives the answer, the offerer MUST verify, that 477 one of the initially offered crypto suites and its accompanying tag 478 was accepted and echoed in the answer. Also, the answer MUST include 479 one or more keys, which will be used for media sent from the answerer 480 to the offerer. 482 If the offer contained any mandatory negotiated session parameters 483 (see section 6.3.7), the offerer MUST verify that said parameters are 484 included in the answer and support them. If the answer contains any 485 mandatory declarative session parameters, the offerer MUST be able to 486 support those. 488 If any of the above fails, the negotiation MUST fail. 490 5.1.4 Modifying the Session 492 Once a media stream has been established, it MAY be modified at any 493 time, as described in RFC 3264, Section 8. Such a modification MAY 494 be triggered by the security service, e.g., in order to perform a re- 495 keying or change the crypto-suite. If media stream security using 496 the general security descriptions defined here is still desired, the 497 crypto attribute MUST be included in these new offer/answer 498 exchanges. The procedures are similar to those defined in Section 499 5.1.1, 5.1.2, 5.1.3 of this document, subject to the considerations 500 provided in RFC 3264 Section 8. 502 5.2 Use Outside Offer/Answer 504 The crypto attribute can also be used outside the context of 505 offer/answer where there is no negotiation of the crypto suite, 506 cryptographic key or session parameters. In this case, the sender 507 determines security parameters for the stream. Since there is no 508 negotiation mechanisms, the sender MUST include exactly one crypto 509 attribute and the receiver MUST either accept it or else SHOULD NOT 510 receive the associated stream. The sender SHOULD select the security 511 description that it deems most secure for its purposes. 513 5.3 General Backwards Compatibility Considerations 515 In the offer/answer model, it is possible that the answerer supports 516 a given secure transport (e.g., "RTP/SAVP") and accepts the offered 517 media stream, yet the answerer does not support the crypto attribute 518 defined in this document and hence ignores it. The offerer can 519 recognize this situation by seeing an accepted media stream in the 520 answer that does not include a crypto line. In that case, the 521 security negotiation defined here MUST fail. 523 Similar issues exist when security descriptions are used outside of 524 the offer/answer model. But the source of a non-negotiated security 525 description has no indication that the receiver has ignored the 526 crypto attribute. 528 6 SRTP Security Descriptions 530 In this section, we provide definitions for security descriptions for 531 SRTP media streams. In the next section, we define how to use SRTP 532 security descriptions with and without the offer/answer model. 534 SRTP security descriptions MUST only be used with the SRTP transport 535 (e.g., "RTP/SAVP" or "RTP/SAVPF"). The following specifies security 536 descriptions for the "RTP/SAVP" profile defined in [srtp], however it 537 is expected that other secure RTP profiles (e.g., "RTP/SAVPF") can 538 use the same descriptions, which are in accordance with the SRTP 539 protocol specification [srtp]. 541 There is no assurance that an endpoint is capable of configuring its 542 SRTP service with a particular crypto attribute parameter, but SRTP 543 guarantees minimal interoperability among SRTP endpoints through the 544 default SRTP parameters [srtp]. More capable SRTP endpoints support 545 a variety of parameter values beyond the SRTP defaults and these 546 values can be configured by the SRTP security descriptions defined 547 here. An endpoint that does not support the crypto attribute will 548 ignore it according to the SDP. Such an endpoint will not correctly 549 process the particular media stream. By using the Offer/Answer 550 model, the offerer and answerer can negotiate the crypto parameters 551 to be used before commencement of the multimedia session (see Section 552 7.1). 554 There are over twenty cryptographic parameters listed in the SRTP 555 specification. Many of these parameters have fixed values for 556 particular cryptographic transforms. At the time of session 557 establishment, however, there is usually no need to provide unique 558 settings for many of the SRTP parameters, such as salt length and 559 pseudo-random function (PRF). Thus, it is possible to simplify the 560 list of parameters by defining "cryptographic suites" that fix a set 561 of SRTP parameter values for the security session. This approach is 562 followed by the SRTP security descriptions, which uses the general 563 security description parameters as follows: 565 * crypto-suite: Identifies the encryption and authentication 566 transforms 567 * key parameter: SRTP keying material and parameters 568 * session parameters: The following parameters are defined: 569 - KDR: The SRTP Key Derivation Rate is the rate that a 570 pseudo-random function is applied to a master key 571 - UNENCRYPTED_SRTP: SRTP messages are not encrypted 572 - UNENCRYPTED_SRTCP: SRTCP messages are not encrypted 573 - UNAUTHENTICATED_SRTP: SRTP messages are not authenticated 574 - FEC_ORDER: Order of forward error correction (FEC) 575 relative to SRTP services 576 - FEC_KEY: Master Key for FEC when the FEC stream is sent 577 to a separate address and/or port. 578 - WSH: Window Size Hint 579 - Extensions: Extension parameters can be defined 581 Please refer to the SRTP specification for a complete list of 582 parameters and their descriptions [Section 8.2, srtp]. Regarding the 583 UNENCRYPTED_SRTCP parameter, offerers and answerers of SDP security 584 descriptions MUST NOT use the SRTCP E-bit to override 585 UNENCRYPTED_SRTCP or the default, which is to encrypt all SRTCP 586 messages (see Section 6.3.2). The key parameter, the crypto-suite, 587 and the session parameters shown above are described in detail in the 588 following subsections. 590 6.1 SRTP Key Parameter 592 SRTP security descriptions define use of the "inline" key method as 593 described in the following. Use of any other keying method, e.g., 594 URL, for SRTP security descriptions is for further study. 596 The "inline" type of key contains the keying material (master key 597 and salt) and all policy related to that master key, including how 598 long it can be used (lifetime) and whether or not it uses a master 599 key identifier (MKI) to associate an incoming SRTP packet with a 600 particular master key. Compliant implementations obey the policies 601 associated with a master key, and MUST NOT accept incoming packets 602 that violate the policy (e.g., after the master key lifetime has 603 expired). 605 The key parameter contains one or more cryptographic master keys, 606 each of which MUST be a unique cryptographically random [RFC1750] 607 value with respect to other master keys in the entire SDP message 608 (i.e., including master keys for other streams). Each key follows 609 the format (the formal definition is provided in Section 9.2): 611 "inline:" ["|" lifetime] ["|" MKI ":" length] 613 key||salt concatenated master key and salt, base64 encoded 614 (see [RFC3548], Section 3) 615 lifetime master key lifetime (max number of SRTP or SRTCP 616 packets using this master key) 617 MKI:length MKI and length of the MKI field in SRTP packets 619 The following definition provides an example for 620 AES_CM_128_HMAC_SHA1_80: 622 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:4 624 The first field ("d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj") of the 625 parameter is the cryptographic master key appended with the master 626 salt; the two are first concatenated and then base64 encoded. The 627 length of the concatenated key and salt is determined by the crypto- 628 suite for which the key applies. If the length (after being decoded 629 from base64) does not match that specified for the crypto-suite, the 630 crypto attribute in question MUST be considered invalid. Each master 631 key and salt MUST be a cryptographically random number and MUST be 632 unique to the entire SDP message. When base64 decoding the key and 633 salt, padding characters (i.e., one or two "=" at the end of the 634 base64 encoded data) are discarded (see [RFC3548] for details). 635 Base64 encoding assumes that the base64 encoding input is an integral 636 number of octets. If a given crypto-suite requires the use of a 637 concatenated key and salt with a length that is not an integral 638 number of octets, said crypto-suite MUST define a padding scheme that 639 results in the base64 input being an integral number of octets. For 640 example, if the length defined was 250 bits, then 6 padding bits 641 would be needed, which could be defined to be the last 6 bits in a 642 256 bit input. 644 The second field, is the OPTIONAL lifetime of the master key as 645 measured in maximum number of SRTP or SRTCP packets using that master 646 key (i.e., the number of SRTP packets and the number of SRTCP packets 647 each have to be less than the lifetime). The lifetime value MAY be 648 written as a non-zero, positive integer or as a power of 2 (see the 649 grammar in Section 9.2 for details). The "lifetime" value MUST NOT 650 exceed the maximum packet lifetime for the crypto-suite. If the 651 lifetime is too large or otherwise invalid then the entire crypto 652 attribute MUST be considered invalid. The default MAY be implicitly 653 signaled by omitting the lifetime (note that the lifetime field never 654 includes a colon, whereas the third field always does). This is 655 convenient when the SRTP cryptographic key lifetime is the default 656 value. As a shortcut to avoid long decimal values, the syntax of the 657 lifetime allows using the literal "2^", which indicates "two to the 658 power of". The example above, shows a case where the lifetime is 659 specified as 2^20. The following example, which is for the 660 AES_CM_128_HMAC_SHA1_80 crypto-suite, has a default for the lifetime 661 field, which means that SRTP's and SRTCP's default values will be 662 used (see [srtp]): 664 inline:YUJDZGVmZ2hpSktMbW9QUXJzVHVWd3l6MTIzNDU2|1066:4 666 The example shows a 30-character key and concatenated salt that is 667 base64 encoded: The 30-character key/salt concatenation is expanded 668 to 40 characters by the three-in-four encoding of base64. 670 The third field, which is also OPTIONAL, is the Master Key Identifier 671 (MKI) and its byte length. 673 "MKI" is the master key identifier associated with the SRTP master 674 key. The MKI is here defined as a positive integer which is encoded 675 as a big-endian integer in the actual SRTP packets. If the MKI is 676 given, then the length of the MKI MUST also be given and separated 677 from the MKI by a colon (":"). The MKI length is the size of the MKI 678 field in the SRTP packet, specified in bytes. If the MKI length is 679 not given or its value exceeds 128 (bytes), then the entire crypto 680 attribute MUST be considered invalid. The substring "1:4" in the 681 first example assigns to the key a master key identifier of 1 that is 682 4 bytes long, and the second example assigns a 4-byte master key 683 identifier of 1066 to the key. One or more master keys with their 684 associated MKI can be initially defined, and then later updated, or 685 deleted and new ones defined. 687 SRTP offers a second feature for specifying the lifetime of a master 688 key in terms of two values, called "From" and "To," which are defined 689 on the SRTP sequence number space [srtp]. This SRTP Security 690 Descriptions specification, however, does not support the 691 <"From","To"> feature since the lifetime of an AES master key is 2^48 692 SRTP packets, which means that there is no cryptographic reason to 693 replace a master key for practical point-to-point applications. For 694 this reason, there is no need to support two means for signaling key 695 update. The MKI is chosen over <"From","To"> by this specification 696 for the very few applications that need it since the MKI feature is 697 simpler (though the MKI adds additional bytes to each packet whereas 698 <"From", "To"> does not). 700 As mentioned above, the key parameter can contain one or more master 701 keys. When the key parameter contains more than one master key, all 702 of the master keys in that key parameter MUST include an MKI value. 704 When using the MKI, the MKI length MUST be the same for all keys in a 705 given crypto attribute. 707 6.2 Crypto-suites 709 The SRTP crypto-suites define the encryption and authentication 710 transforms to be used for the SRTP media stream. The SRTP 711 specification has defined three crypto-suites, which are described 712 further in the following subsections in the context of the SRTP 713 security descriptions. The table below provides an overview of the 714 crypto-suites and their parameters: 716 +---------------------+-------------+--------------+---------------+ 717 | |AES_CM_128_ | AES_CM_128_ | F8_128_ | 718 | |HMAC_SHA1_80 | HMAC_SHA1_32 | HMAC_SHA1_80 | 719 +---------------------+-------------+--------------+---------------+ 720 | Master key length | 128 bits | 128 bits | 128 bits | 721 | Salt value | 112 bits | 112 bits | 112 bits | 722 | Default lifetime | 2^31 packets| 2^31 packets | 2^31 packets | 723 | Cipher | AES Counter | AES Counter | F8 | 724 | | Mode | Mode | | 725 | Encryption key | 128 bits | 128 bits | 128 bits | 726 | MAC | HMAC-SHA1 | HMAC-SHA1 | HMAC-SHA1 | 727 | Authentication tag | 80 bits | 32 bits | 80 bits | 728 | SRTP auth. key | 160 bits | 160 bits | 160 bits | 729 | SRTCP auth. key | 160 bits | 160 bits | 160 bits | 730 +---------------------+-------------+--------------+---------------+ 732 6.2.1 AES_CM_128_HMAC_SHA1_80 734 AES_CM_128_HMAC_SHA1_80 is the SRTP default AES Counter Mode cipher 735 and HMAC-SHA1 message authentication having an 80-bit authentication 736 tag. The master-key length is 128 bits and has a default lifetime 737 of a maximum of 2^31 SRTP packets or SRTCP packets, whichever comes 738 first [Page 39, srtp]. 740 Technically, SRTP allows 2^48 SRTP packets or 2^31 SRTCP packets, 741 whichever comes first. SRTP security descriptions, however, 742 simplify the parameters to share a single upper bound of 2^31 743 packets. It is RECOMMENDED that automated key management allow 744 easy and efficient rekeying at intervals far smaller than 2^31 745 packets given today's media rates or even HDTV media rates. 747 The SRTP and SRTCP encryption key lengths are 128 bits. The SRTP 748 and SRTCP authentication key lengths are 160 bits (see Security 749 Considerations in Section 8). The master salt value is 112 bits in 750 length and the session salt value is 112 bits in length. The 751 pseudo-random function (PRF) is the default SRTP pseudo-random 752 function that uses AES Counter Mode with a 128-bit key length. 754 The length of the base64 decoded key and salt value for this crypto- 755 suite MUST be 30 characters, i.e., 240 bits; otherwise the crypto 756 attribute is considered invalid. 758 6.2.2 AES_CM_128_HMAC_SHA1_32 760 This crypto-suite is identical to AES_CM_128_HMAC_SHA1_80 except 761 that the authentication tag is 32 bits. 763 The length of the base64-decoded key and salt value for this crypto- 764 suite MUST be 30 characters, i.e., 240 bits; otherwise the crypto 765 attribute is considered invalid. 767 6.2.3 F8_128_HMAC_SHA1_80 769 This crypto-suite is identical to AES_CM_128_HMAC_SHA1_80 except the 770 cipher is F8 [srtp]. 772 The length of the base64 decoded key and salt value for this crypto- 773 suite MUST be 30 characters, i.e. 240 bits; otherwise the crypto 774 attribute is considered invalid. 776 6.2.4 Adding new Crypto-suite Definitions 778 If new transforms are added to SRTP, new definitions for those 779 transforms SHOULD be given for the SRTP security descriptions and 780 published in a Standards Track RFC. Sections 6.2.1 through 6.2.3 781 illustrate how to define crypto-suite values for particular 782 cryptographic transforms. Any new crypto-suites MUST be registered 783 with IANA following the procedures in section 10. 785 6.3 Session Parameters 787 SRTP security descriptions define a set of "session" parameters, 788 which OPTIONALLY may be used to override SRTP session defaults for 789 the SRTP and SRTCP streams. These parameters configure an RTP 790 session for SRTP services. The session parameters provide session- 791 specific information to establish the SRTP cryptographic context. 793 6.3.1 KDR=n 795 KDR specifies the Key Derivation Rate, as described in section 4.3.1 796 of [srtp]. 798 The value n MUST be an integer in the set {1,2,...,24}, which 799 denotes a power of 2 from 2^1 to 2^24, inclusive. The SRTP key 800 derivation rate controls how frequently a new session key is derived 801 from an SRTP master key(s) [srtp] given in the declaration. When 802 the key derivation rate is not specified (i.e., the KDR parameter is 803 omitted), a single initial key derivation is performed [srtp]. 805 In the offer/answer model, KDR is a declarative parameter. 807 6.3.2 UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP 809 SRTP and SRTCP packet payloads are encrypted by default. The 810 UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP session parameters modify the 811 default behavior of the crypto-suites with which they are used: 813 * UNENCRYPTED_SRTCP signals that the SRTCP packet payloads are not 814 encrypted. 816 * UNENCRYPTED_SRTP signals that the SRTP packet payloads are not 817 encrypted. 819 In the offer/answer model, these parameters are negotiated. If 820 UNENCRYPTED_SRTCP is signaled for the session, then the SRTCP E bit 821 MUST be clear (0) in all SRTCP messages. If the default is used, 822 all SRTCP messages are encrypted and the E bit MUST be set (1) on 823 all SRTCP messages. 825 6.3.3 UNAUTHENTICATED_SRTP 827 SRTP and SRTCP packet payloads are authenticated by default. The 828 UNAUTHENTICATED_SRTP session parameter signals that SRTP messages 829 are not authenticated. Use of UNAUTHENTICATED_SRTP is NOT 830 RECOMMENDED (see Security Considerations). 832 The SRTP specification requires use of message authentication for 833 SRTCP, but not for SRTP [srtp]. 835 In the offer/answer model, this parameter is negotiated. 837 6.3.4 FEC_ORDER=order 839 FEC_ORDER signals the use of forward error correction for the RTP 840 packets [rfc2733]. The forward error correction values for "order" 841 are FEC_SRTP or SRTP_FEC. FEC_SRTP signals that FEC is applied 842 before SRTP processing by the sender of the SRTP media and after SRTP 843 processing by the receiver of the SRTP media; FEC_SRTP is the 844 default. SRTP_FEC is the reverse processing. 846 In the offer/answer model, FEC_ORDER is a declarative parameter. 848 6.3.5 FEC_KEY=key-params 850 FEC_KEY signals the use of separate master key(s) for a Forward 851 Error Correction (FEC) stream. The master key(s) are specified with 852 the exact same format as the SRTP Key Parameter defined in Section 853 6.1, and the semantic rules are the same - in particular, the master 854 key(s) MUST be different from all other master key(s) in the SDP. A 855 FEC_KEY MUST be specified when the FEC stream is sent to a different 856 IP-address and/or port than the media stream to which it applies 857 (i.e., the "m=" line), e.g., as described in RFC 2733 Section 11.1. 858 When a FEC stream is sent to the same IP-address and port as the 859 media stream to which it applies, a FEC_KEY MUST NOT be specified. 860 If a FEC_KEY is specified in this latter case, the crypto attribute 861 in question MUST be considered invalid. 863 In the offer/answer model, FEC_KEY is a declarative parameter. 865 6.3.6 Window Size Hint (WSH) 867 SRTP defines the SRTP-WINDOW-SIZE [srtp, section 3.3.2] parameter to 868 protect against replay attacks. The minimum value is 64 [srtp], 869 however this value may be considered too low for some applications 870 (e.g., video). 872 The Window Size Hint (WSH) session parameter provides a hint for how 873 big this window should be to work satisfactorily (e.g., based on 874 sender knowledge of number of packets per second). However, there 875 might be enough information given in SDP attributes like 876 "a=maxprate" [maxprate] and the bandwidth modifiers to allow a 877 receiver to derive the parameter satisfactorily. Consequently, this 878 value is only considered a hint to the receiver of the SDP which MAY 879 choose to ignore the value provided. 881 In the offer/answer model, WSH is a declarative parameter. 883 6.3.7 Defining New SRTP Session Parameters 885 New SRTP session parameters for the SRTP security descriptions can 886 be defined in a Standards Track RFC and registered with IANA 887 according to the registration procedures defined in Section 10. 889 New SRTP session parameters are by default mandatory. A newly- 890 defined SRTP session parameter that is prefixed with the dash 891 character ("-") however is considered optional and MAY be ignored. 892 If an SDP crypto attribute is received with an unknown session 893 parameter that is not prefixed with a "-" character, that crypto 894 attribute MUST be considered invalid. 896 6.4 SRTP Crypto Context Initialization 898 In addition to the various SRTP parameters defined above, there are 899 three pieces of information that are critical to the operation of the 900 default SRTP ciphers: 902 * SSRC: Synchronization source 903 * ROC: Roll-over counter for a given SSRC 904 * SEQ: Sequence number for a given SSRC 905 In a unicast session, as defined here, there are three constraints on 906 these values. 908 The first constraint is on the SSRC, which makes an SRTP keystream be 909 unique from other participants. As explained in SRTP, the keystream 910 MUST NOT be reused on two or more different pieces of plaintext. 911 Keystream reuse makes the ciphertext vulnerable to cryptanalysis. 912 One vulnerability is that known-plaintext fields in one stream can 913 expose portions of the reused keystream and this could further expose 914 more plaintext in other streams. Since all current SRTP encryption 915 transforms use keystreams, key sharing is a general problem [srtp]. 916 SRTP mitigates this problem by including the SSRC of the sender in 917 the keystream. But SRTP does not solve this problem in its entirety 918 because Real-time Transport Protocol has SSRC collisions, which are 919 very rare [rtp] but quite possible. During a collision, two or more 920 SSRCs that share a master key will have identical keystreams for 921 overlapping portions of the RTP sequence-number space. SRTP Security 922 Descriptions avoids keystream reuse by making unique master keys 923 REQUIRED for the sender and receiver of the security description. 924 Thus, the first constraint is satisfied. 926 Also note, that there is a second problem with SSRC collisions: The 927 SSRC is used to identify the crypto context and thereby the cipher, 928 key, ROC, etc. to process incoming packets. In case of SSRC 929 collisions, crypto context identification becomes ambiguous and 930 correct packet processing may not occur. Furthermore, if an RTCP 931 BYE packet is to be sent for a colliding SSRC, that packet may also 932 have to be secured. In a (unicast) point-to-multipoint scenario, 933 this can be problematic for the same reasons, i.e., it is not known 934 which of the possible crypto contexts to use. Note that these 935 problems are not unique to the SDP security descriptions; any use 936 of SRTP needs to consider them. 938 The second constraint is that the ROC MUST be zero at the time that 939 each SSRC commences sending packets. Thus, there is no concept of a 940 "late joiner" in SRTP security descriptions, which are constrained to 941 be unicast and pairwise. The ROC and SEQ form a "packet index" in 942 the default SRTP transforms and the ROC is consistently set to zero 943 at session commencement, according to this document. 945 The third constraint is that the initial value of SEQ SHOULD be 946 chosen to be within the range of 0..2^15-1; this avoids an ambiguity 947 when packets are lost at the start of the session. If at the start 948 of a session, an SSRC source might randomly select a high sequence- 949 number value and put the receiver in an ambiguous situation: If 950 initial packets are lost in transit up to the point that the sequence 951 number wraps (i.e., exceeds 2^16-1), then the receiver might not 952 recognize that its ROC needs to be incremented. By restricting the 953 initial SEQ to the range of 0..2^15-1, SRTP packet-index 954 determination will find the correct ROC value, unless all of the 955 first 2^15 packets are lost (which seems, if not impossible, then 956 rather unlikely). See Section 3.3.1 of the SRTP specification 957 regarding packet-index determination [srtp]. 959 6.4.1 Late Binding of one or more SSRCs to a crypto context 961 The packet index, therefore, depends on the SSRC, the SEQ of an 962 incoming packet and the ROC, which is an SRTP crypto context 963 variable. Thus, SRTP has a big security dependency on SSRC 964 uniqueness. 966 Given the above constraints, unicast SRTP crypto contexts can be 967 established without the need to negotiate SSRC values in the SRTP 968 security descriptions. Instead, an approach called "late binding" is 969 RECOMMENDED by this specification. When a packet arrives, the SSRC 970 that is contained in it can be bound to the crypto context at the 971 time of session commencement (i.e., SRTP packet arrival) rather than 972 at the time of session signaling (i.e., receipt of an SDP). With the 973 arrival of the packet containing the SSRC, all the data items needed 974 for the SRTP crypto context are held by the receiver (note that the 975 ROC value by definition is zero; if non-zero values were to be 976 supported, additional signaling would be required). In other words, 977 the crypto context for a secure RTP session using late binding is 978 initially identified by the SDP as: 980 <*, address, port> 982 where '*' is a wildcard SSRC, "address" is the local receive address 983 from the "c=" line, and "port" is the local receive port from the 984 "m=" line. When the first packet arrives with ssrcX in its SSRC 985 field, the crypto context 987 989 is instantiated subject to the following constraints: 991 * Media packets are authenticated: Authentication MUST succeed; 992 otherwise, the crypto context is not instantiated. 994 * Media packets are not authenticated: Crypto context is 995 automatically instantiated. 997 It should be noted, that use of late binding when there is no 998 authentication of the SRTP media packets is subject to numerous 999 security attacks and consequently it is NOT RECOMMENDED (of course, 1000 this can be said for unauthenticated SRTP in general). 1002 Note that use of late binding without authentication will result in 1003 local state being created as a result of receiving a packet from 1004 any unknown SSRC. UNAUTHENTICATED_SRTP, therefore is NOT 1005 RECOMMENDED because it invites easy denial-of-service attack. In 1006 contrast, late binding with authentication does not suffer from 1007 this weakness. 1009 6.4.2 Sharing cryptographic contexts among Sessions or SSRCs 1011 With the constraints and procedures described above, it is not 1012 necessary to explicitly signal the SSRC, ROC and SEQ for a unicast 1013 RTP session. So there are no a=crypto parameters for signaling SSRC, 1014 ROC or SEQ. Thus, multiple SSRCs from the same entity will share 1015 a=crypto parameters when late binding is used. Multiple SSRCs from 1016 the same entity arises due to either multiple sources (microphones, 1017 cameras, etc.), or RTP payloads requiring SSRC multiplexing within 1018 that same session. SDP also allows multiple RTP sessions to be 1019 defined in the same media description ("m="), these RTP sessions will 1020 also share the a=crypto parameters. An application that uses 1021 a=crypto in this way serially shares a master key among RTP sessions 1022 or SSRCs and MUST replace the master key when the aggregate number of 1023 packets among all SSRCs approaches 2^31 packets. SSRCs that share a 1024 master key MUST be unique from one another. 1026 6.5 Removal of Crypto Contexts 1028 The mechanism defined above addresses the issue of creating crypto 1029 contexts, however in practice, session participants may want to 1030 remove crypto contexts prior to session termination. Since a crypto 1031 context contains information that can not automatically be recovered 1032 (e.g., ROC), it is important that the sender and receiver agree on 1033 when a crypto context can be removed, and perhaps more importantly 1034 when it cannot. 1036 Even when late binding is used for a unicast stream, the ROC is 1037 lost and cannot be recovered automatically (unless it is zero) once 1038 the crypto context is removed. 1040 We resolve this problem as follows. When SRTP security descriptions 1041 are being used, crypto-context removal MUST follow the same rules as 1042 SSRC removal from the member table [RFC 3550]; note that this can 1043 happen as the result of an SRTCP BYE packet or a simple time-out due 1044 to inactivity. Inactive session participants that wish to ensure 1045 their crypto contexts are not timed out MUST thus send SRTCP packets 1046 at regular intervals. 1048 7 SRTP-Specific Use of the crypto Attribute 1050 Section 5 describes general use of the crypto attribute, and this 1051 section completes it by describing SRTP-specific use. 1053 7.1 Use with Offer/Answer 1055 In this section, we describe how the SRTP security descriptions are 1056 used with the offer/answer model to negotiate cryptographic 1057 capabilities and communicate SRTP master keys. The rules defined 1058 below complement the general offer/answer rules defined in Section 1059 5.1, which MUST be followed, unless otherwise specified. Note that 1060 the rules below define unicast operation only; support for multicast 1061 and multipoint unicast streams is for further study. 1063 7.1.1 Generating the Initial Offer - Unicast Streams 1065 When the initial offer is generated, the offerer MUST follow the 1066 steps in Section 5.1.1 as well as the following steps. 1068 For each unicast media line (m=) using the secure RTP transport 1069 where the offerer wants to specify cryptographic parameters, the 1070 offerer MUST provide at least one valid SRTP security description 1071 ("a=crypto" line), as defined in Section 6. If the media stream 1072 includes Forward Error Correction with a different IP-address and/or 1073 port than the media stream itself, a FEC_KEY parameter MUST be 1074 included, as described in Section 6.3.5. 1076 The offerer MAY include one or more other SRTP session parameters as 1077 defined in Section 6.3. Note however, that if any SRTP session 1078 parameters are included that are not known to the answerer, but are 1079 nonetheless mandatory (see Section 6.3.6), the negotiation will fail 1080 if the answerer does not support them. 1082 7.1.2 Generating the Initial Answer - Unicast Streams 1084 When the initial answer is generated, the answerer MUST follow the 1085 steps in Section 5.1.2 as well as the following steps. 1087 For each unicast media line which uses the secure RTP transport and 1088 contains one or more "a=crypto" lines in the offer, the answerer 1089 MUST either accept one (and only one) of the crypto lines for that 1090 media stream, or it MUST reject the media stream. Only "a=crypto" 1091 lines that are considered valid SRTP security descriptions as 1092 defined in Section 6 can be accepted. Furthermore, all parameters 1093 (crypto-suite, key parameter, and mandatory session parameters) MUST 1094 be acceptable to the answerer in order for the offered media stream 1095 to be accepted. Note that if the media stream includes Forward 1096 Error Correction with a different IP-address and/or port than the 1097 media stream itself, a FEC_KEY parameter MUST be included, as 1098 described in Section 6.3.5. 1100 When the answerer accepts an SRTP unicast media stream with a crypto 1101 line, the answerer MUST include one or more master keys appropriate 1102 for the selected crypto algorithm; the master key(s) included in the 1103 answer MUST be different from those in the offer. 1105 When the master key(s) are not shared between the offerer and 1106 answerer, SSRC collisions between the offerer and answerer will not 1107 lead to keystream reuse, and hence SSRC collisions do not 1108 necessarily have to be prevented. 1110 If Forward Error Correction to a separate IP-address and/or port is 1111 included, the answer MUST include a FEC_KEY parameter, as described 1112 in Section 6.3.5. 1114 Declarative session parameters may be added to the answer as usual, 1115 however the answerer SHOULD NOT add any mandatory session parameter 1116 (see Section 6.3.6) that might be unknown to the offerer. 1118 If the answerer cannot find any valid crypto line that it supports, 1119 or if its configured policy prohibits any cryptographic key 1120 parameter (e.g., key length) or cryptographic session parameter 1121 (e.g., KDR, FEC_ORDER), it MUST reject the media stream, unless it 1122 is able to successfully negotiate use of SRTP by other means outside 1123 the scope of this document (e.g., by use of MIKEY [mikey]). 1125 7.1.3 Processing of the Initial Answer - Unicast Streams 1127 When the offerer receives the answer, it MUST perform the steps in 1128 Section 5.1.3 as well as the following steps for each SRTP media 1129 stream it offered with one or more crypto lines in it. 1131 If the media stream was accepted and it contains a crypto line, it 1132 MUST be checked that the crypto line is valid according to the 1133 constraints specified in Section 6 (including any FEC constraints). 1135 If the offerer either does not support or is not willing to honor 1136 one or more of the SRTP parameters in the answer, the offerer MUST 1137 consider the crypto line invalid. 1139 If the crypto line is not valid, or the offerer's configured policy 1140 prohibits any cryptographic key parameter (e.g. key length) or 1141 cryptographic session parameter, the SRTP security negotiation MUST 1142 be deemed to have failed. 1144 7.1.4 Modifying the Session 1146 When a media stream using the SRTP security descriptions has been 1147 established, and a new offer/answer exchange is performed, the 1148 offerer and answerer MUST follow the steps in Section 5.1.4 as well 1149 as the following steps. 1151 When modifying the session, all negotiated aspects of the SRTP media 1152 stream can be modified. For example, a new crypto suite can be used 1153 or a new master key can be established. As described in RFC 3264, 1154 when doing a new offer/answer exchange there will be a window of 1155 time, where the offerer and the answerer must be prepared to receive 1156 media according to both the old and the new offer/answer exchange. 1158 This requirement applies here as well, however the following should 1159 be noted: 1161 * When authentication is not being used, it may not be possible for 1162 either the offerer or the answerer to determine if a given packet 1163 is encrypted according to the old or new offer/answer exchange. 1164 RFC 3264 defines a couple of techniques to address this problem, 1165 e.g., changing the payload types used and/or the transport 1166 addresses. Note however that a change in transport addresses may 1167 have an impact on Quality of Service as well as firewall and NAT 1168 traversal. The SRTP security descriptions use the MKI to deal with 1169 this (which adds a few bytes to each SRTP packet) as described in 1170 Section 6.1. For further details on the MKI, please refer to 1171 [srtp]. 1173 * If the answerer changes its master key, the offerer will not 1174 be able to process packets secured via this master key until the 1175 answer is received. This could be addressed by using a security 1176 "precondition" [sprecon]. 1178 If the offerer includes an IP address and/or port that differs from 1179 that used previously for a media stream (or FEC stream), the offerer 1180 MUST include a new master key with the offer (and in so doing, it 1181 will be creating a new crypto context with the ROC set to zero). 1182 Similarly, if the answerer includes an IP address and/or port that 1183 differs from that used previously for a media stream (or FEC 1184 stream), the answerer MUST include a new master key with the offer 1185 (and hence create a new crypto context with the ROC set to zero). 1186 The reason for this is, that when the answerer receives an offer, or 1187 the offerer receives an answer, with an updated IP address and/or 1188 port, it is not possible to determine if the other side has access 1189 to the old crypto context parameters (and in particular the ROC) or 1190 not. For example, if one side is a decomposed gateway, or a back- 1191 to-back user agent is involved, it is possible that the media 1192 endpoint changed and no longer has access to the old crypto context. 1193 By always requiring a new master key in this case, the 1194 answerer/offerer will know that the ROC is zero for this 1195 offer/answer, and any key lifetime constraints will trivially be 1196 satisfied too. Another consideration here applies to media relays; 1197 if the relay changes the media endpoint on one side transparently to 1198 the other side, the relay cannot operate as a simple packet 1199 reflector but will have to actively engage in SRTP packet processing 1200 and transformation (i.e., decryption and re-encryption, etc.). 1202 Finally note, that if the new offer is rejected, the old crypto 1203 parameters remain in place. 1205 7.1.5 Offer/Answer Example 1207 In this example, the offerer supports two crypto suites (f8 and AES). 1208 The a=crypto line is actually one long line, although it is shown as 1209 two lines in this document due to page formatting. The f8 example 1210 shows two inline parameters; as explained in Section 6.1, there may 1211 be one or more key (i.e. inline) parameters in a crypto attribute. 1212 In this way, multiple keys are offered to support key rotation using 1213 a master key index (MKI). 1215 Offerer sends: 1216 v=0 1217 o=sam 2890844526 2890842807 IN IP4 10.47.16.5 1218 s=SRTP Discussion 1219 i=A discussion of Secure RTP 1220 u=http://www.example.com/seminars/srtp.pdf 1221 e=marge@example.com (Marge Simpson) 1222 c=IN IP4 168.2.17.12 1223 t=2873397496 2873404696 1224 m=audio 49170 RTP/SAVP 0 1225 a=crypto:1 AES_CM_128_HMAC_SHA1_80 1226 inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4 1227 FEC_ORDER=FEC_SRTP 1228 a=crypto:2 F8_128_HMAC_SHA1_80 1229 inline:MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm|2^20|1:4; 1230 inline:QUJjZGVmMTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5|2^20|2:4 1231 FEC_ORDER=FEC_SRTP 1233 Answerer replies: 1234 v=0 1235 o=jill 25690844 8070842634 IN IP4 10.47.16.5 1236 s=SRTP Discussion 1237 i=A discussion of Secure RTP 1238 u=http://www.example.com/seminars/srtp.pdf 1239 e=homer@example.com (Homer Simpson) 1240 c=IN IP4 168.2.17.11 1241 t=2873397526 2873405696 1242 m=audio 32640 RTP/SAVP 0 1243 a=crypto:1 AES_CM_128_HMAC_SHA1_80 1244 inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4 1246 In this case, the session would use the AES_CM_128_HMAC_SHA1_80 1247 crypto suite for the RTP and RTCP traffic. If F8_128_HMAC_SHA1_80 1248 were selected by the answerer, there would be two inline keys 1249 associated with the SRTP cryptographic context. One key has an MKI 1250 value of 1 and the second has an MKI of 2. 1252 7.2 SRTP-Specific Use Outside Offer/Answer 1254 Use of SRTP security descriptions outside the offer/answer model is 1255 not defined. 1257 Use of SRTP security descriptions outside offer/answer could have 1258 been defined for sendonly media streams, however, there would not 1259 be a way to indicate the key to use for SRTCP by the receiver of 1260 said media stream. 1262 7.3 Support for SIP Forking 1264 As mentioned earlier, the security descriptions defined here do not 1265 support multicast media streams or multipoint unicast streams. 1266 However, in the SIP protocol, it is possible to receive several 1267 answers to a single offer due to the use of forking (see [SIP]). 1268 Receiving multiple answers leads to a couple of problems for the 1269 SRTP security descriptions: 1271 * Different answerers may choose different ciphers, keys, etc., 1272 however there is no way for the offerer to associate a particular 1273 incoming media packet with a particular answer. 1275 * Two or more answerers may pick the same SSRC and hence the SSRC 1276 collision problems mentioned earlier may arise. 1278 As stated earlier, the above point-to-multipoint cases are outside 1279 the scope of the SDP security descriptions. However, there is a way 1280 of supporting SIP forking: Change the multipoint scenario resulting 1281 from SIP forking into multiple two-party unicast cases. This is 1282 done as follows: 1284 For each answer received beyond the initial answer, issue a new 1285 offer to that particular answerer using a new receive transport 1286 address (IP address and port); note that this requires support for 1287 the SIP UPDATE method [RFC 3313]. Also, to ensure that two media 1288 sessions are not inadvertently established prior to the UPDATE being 1289 processed by one of them, use security preconditions [sprecon]. 1291 Finally, note that all SIP User Agents that received the offer will 1292 know the key(s) being proposed by the initial offer. If the offerer 1293 wants to ensure security with respect to all other User Agents that 1294 may have received the offer, a new offer/answer exchange with a new 1295 key needs to be performed with the answerer as well. It should be 1296 noted, that the offerer cannot determine whether a single or 1297 multiple SIP User Agents received the offer, since intermediate 1298 forking proxies may only forward a single answer to the offerer. 1300 7.4 SRTP-Specific Backwards Compatibility Considerations 1302 It is possible that the answerer supports the SRTP transport and 1303 accepts the offered media stream, yet it does not support the crypto 1304 attribute defined here. The offerer can recognize this situation by 1305 seeing an accepted SRTP media stream in the answer that does not 1306 include a crypto line. In that case, the security negotiation 1307 defined here MUST be deemed to have failed. 1309 Also, if a media stream with a given SRTP transport (e.g., 1310 "RTP/SAVP") is sent to a device that does not support SRTP, that 1311 media stream will be rejected. 1313 7.5 Operation with KEYMGT= and k= lines 1315 An offer MAY include both "a=crypto" and "a=keymgt" lines [keymgt]. 1316 Per SDP rules, the answerer will ignore attribute lines that it does 1317 not understand. If the answerer supports both "a=crypto" and 1318 "a=keymgt", the answer MUST include either "a=crypto" or "a=keymgt" 1319 but not both, as including both is undefined. 1321 An offer MAY include both "a=crypto" and "k=" lines [SDP]. Per SDP 1322 rules, the answerer will ignore attribute lines it does not 1323 understand. If the answerer supports both "a=crypto" and "k=", the 1324 answer MUST include either "a=crypto" or "k=" but not both, as 1325 including both is undefined. 1327 8 Security Considerations 1329 Like all SDP messages, SDP messages containing security 1330 descriptions, are conveyed in an encapsulating application protocol 1331 (e.g., SIP, MGCP, etc.). It is the responsibility of the 1332 encapsulating protocol to ensure the protection of the SDP security 1333 descriptions. Therefore, IT IS REQUIRED that the application invoke 1334 its own security mechanisms (e.g., secure multiparts such as S/MIME 1335 [smime]) or alternatively utilize a lower-layer security service 1336 (e.g., TLS, or IPsec). IT IS REQUIRED that this security service 1337 provide strong message authentication and packet-payload encryption 1338 as well as effective replay protection. 1340 The discussion which follows uses "message authentication" and 1341 "message confidentiality" in a consistent manner with SRTP 1342 [RFC3711]. "Message confidentiality" means that only the holder of 1343 the secret decryption key can access the plain-text content of the 1344 message. The decryption key is the same key as the encryption key 1345 using SRTP counter mode and f8 encryption transforms, which are 1346 vulnerable to message tampering and need SRTP message authentication 1347 to detect such tampering. "Message authentication" and "message 1348 integrity validation" generally mean the same thing in IETF security 1349 standards: An SRTP message is authenticated following a successful 1350 HMAC integrity check [RFC3711], which proves that the message 1351 originated from the holder of an SRTP master key and was not altered 1352 en route. Such an "authentic" message, however, can be captured by 1353 an attacker and "replayed" when the attacker re-inserts the packet 1354 into the channel. A replayed packet can have a variety of bad 1355 effects on the session, and SRTP uses the extended sequence number 1356 to detect replayed SRTP packets [RFC3711]. 1358 The SRTP specification identifies which services and features are 1359 default values that are normative-to-implement (such as 1360 AES_CM_128_80) versus normative-to-use (such as AES_CM_128_32). 1362 8.1 Authentication of packets 1364 Security descriptions as defined herein signal security services for 1365 RTP packets. RTP messages are vulnerable to a variety of attacks 1366 such as replay and forging. To limit these attacks, SRTP message 1367 integrity mechanisms SHOULD be used (SRTP replay protection is 1368 always enabled). 1370 8.2 Keystream Reuse 1372 SRTP security descriptions signal configuration parameters for SRTP 1373 sessions. Misconfigured SRTP sessions are vulnerable to attacks on 1374 their encryption services when running the crypto suites defined in 1375 Sections 6.2.1, 6.2.2, and 6.2.3. An SRTP encryption service is 1376 "misconfigured" when two or more media streams are encrypted using 1377 the same keystream of AES blocks. When senders and receivers share 1378 derived session keys, SRTP requires that the SSRCs of session 1379 participants serve to make their corresponding keystreams unique, 1380 which is violated in the case of SSRC collision: SRTP SSRC collision 1381 drastically weakens SRTP or SRTCP payload encryption during the time 1382 that identical keystreams were used [srtp]. An attacker, for 1383 example, might collect SRTP and SRTCP messages and await a 1384 collision. This attack on the AES-CM and AES-f8 encryption is 1385 avoided entirely when each media stream has its own unique master 1386 key in both the send and receive direction. This specification 1387 restricts use of SDP security description to unicast point-to-point 1388 streams so that keys are not shared between SRTP hosts, and the 1389 master keys used in the send and receive direction for a given media 1390 stream are unique. 1392 8.3 Signaling Authentication and Signaling Encryption 1394 There is no reason to incur the complexity and computational expense 1395 of SRTP, however, when its key establishment is exposed to 1396 unauthorized parties. In most cases, the SRTP crypto attribute and 1397 its parameters are vulnerable to denial of service attacks when they 1398 are carried in an unauthenticated SDP message. In some cases, the 1399 integrity or confidentiality of the RTP stream can be compromised. 1400 For example, if an attacker sets UNENCRYPTED for the SRTP stream in 1401 an offer, this could result in the answerer not decrypting the 1402 encrypted SRTP messages. In the worst case, the answerer might 1403 itself send unencrypted SRTP and leave its data exposed to snooping. 1405 Thus, IT IS REQUIRED that MIME secure multiparts, IPsec, TLS, or 1406 some other data security service be used to provide message 1407 authentication for the encapsulating protocol that carries the SDP 1408 messages having a crypto attribute (a=crypto). Furthermore, IT IS 1409 REQUIRED that encryption of the encapsulating payload be used 1410 whenever a master key parameter (inline) appears in the message. 1411 Failure to encrypt the SDP message containing an inline SRTP master 1412 key renders the SRTP authentication or encryption service useless in 1413 practically all circumstances. Failure to authenticate an SDP 1414 message that carries SRTP parameters renders the SRTP authentication 1415 or encryption service useless in most practical applications. 1417 When the communication path of the SDP message is routed through 1418 intermediate systems that inspect parts of the SDP message, security 1419 protocols such as IPsec or TLS SHOULD NOT be used for encrypting 1420 and/or authenticating the security description. In the case of 1421 intermediate-system processing of a message containing SDP security 1422 descriptions, the "a=crypto" attributes SHOULD be protected end-to- 1423 end so that the intermediate system can neither modify the security 1424 description nor access the keying material. Network or transport 1425 security protocols that terminate at each intermediate system, 1426 therefore, SHOULD NOT be used for protecting SDP security 1427 descriptions. A security protocol SHOULD allow the security 1428 descriptions to be encrypted and authenticated end-to-end 1429 independently of the portions of the SDP message that any 1430 intermediate system modifies or inspects: MIME secure multiparts 1431 are RECOMMENDED for the protection of SDP messages that are 1432 processed by intermediate systems. 1434 9 Grammar 1436 In this section we first provide the ABNF grammar for the generic 1437 crypto attribute, and then we provide the ABNF grammar for the SRTP 1438 specific use of the crypto attribute. 1440 9.1 Generic "Crypto" Attribute Grammar 1442 The ABNF grammar for the crypto attribute is defined below: 1444 "a=crypto:" tag 1*WSP crypto-suite 1*WSP key-params 1445 *(1*WSP session-param) 1447 tag = 1*9DIGIT 1448 crypto-suite = 1*(ALPHA / DIGIT / "_") 1450 key-params = key-param *(";" key-param) 1451 key-param = key-method ":" key-info 1452 key-method = "inline" / key-method-ext 1453 key-method-ext = 1*(ALPHA / DIGIT / "_") 1454 key-info = %x21-3A / %x3C-7E ; visible (printing) characters 1455 ; except semi-colon 1456 session-param = 1*(VCHAR) ; visible (printing) characters 1458 where WSP, ALPHA, DIGIT, and VCHAR are defined in [RFC2234]. 1460 9.2 SRTP "Crypto" Attribute Grammar 1462 This section provides an Augmented BNF [RFC2234] grammar for the 1463 SRTP-specific use of the SDP crypto attribute: 1465 crypto-suite = srtp-crypto-suite 1466 key-method = srtp-key-method 1467 key-info = srtp-key-info 1468 session-param = srtp-session-param 1470 srtp-crypto-suite = "AES_CM_128_HMAC_SHA1_32" / 1471 "F8_128_HMAC_SHA1_32" / 1472 "AES_CM_128_HMAC_SHA1_80" / 1473 srtp-crypto-suite-ext 1475 srtp-key-method = "inline" 1476 srtp-key-info = key-salt ["|" lifetime] ["|" mki] 1478 key-salt = 1*(base64) ; binary key and salt values 1479 ; concatenated together, and then 1480 ; base64 encoded [section 6.8 of 1481 ; RFC2046] 1483 lifetime = ["2^"] 1*(DIGIT) ; see section 6.1 for "2^" 1484 mki = mki-value ":" mki-length 1485 mki-value = 1*DIGIT 1486 mki-length = 1*3DIGIT ; range 1..128. 1488 srtp-session-param = kdr / 1489 "UNENCRYPTED_SRTP" / 1490 "UNENCRYPTED_SRTCP" / 1491 "UNAUTHENTICATED_SRTP" / 1492 fec-order / 1493 fec-key / 1494 wsh / 1495 srtp-session-extension 1497 kdr = "KDR=" 1*2(DIGIT) ; range 0..24, 1498 ; power of two 1500 fec-order = "FEC_ORDER=" fec-type 1501 fec-type = "FEC_SRTP" / "SRTP_FEC" 1502 fec-key = "FEC_KEY=" key-params 1504 wsh = "WSH=" 2*DIGIT ; minimum value is 64 1505 base64 = ALPHA / DIGIT / "+" / "/" / "=" 1507 srtp-crypto-suite-ext = 1*(ALPHA / DIGIT / "_") 1508 srtp-session-extension = ["-"] 1*(VCHAR) ;visible chars [RFC2234] 1509 ; first character must not be dash ("-") 1511 10 IANA Considerations 1513 10.1 Registration of the "crypto" attribute 1515 The IANA is hereby requested to register a new SDP attribute as 1516 follows: 1518 Attribute name: crypto 1519 Long form name: Security description cryptographic attribute 1520 for media streams 1521 Type of attribute: Media-level 1522 Subject to charset: No 1523 Purpose: Security descriptions 1524 Appropriate values: See Section 4 1526 10.2 New IANA Registries and Registration Procedures 1528 The following sub-sections define a new IANA registry with associated 1529 sub-registries to be used for the SDP security descriptions. The 1530 IANA is hereby requested to create an SDP Security Description 1531 registry as shown below and further described in the following 1532 sections: 1534 SDP Security Descriptions 1535 | 1536 +- Key Methods (described in 10.2.1) 1537 | 1538 +- Media Stream Transports (described in 10.2.2) 1539 | 1540 +- Transport1 (e.g. SRTP) 1541 | | 1542 | +- Supported Key Methods (e.g. inline) 1543 | | 1544 | +- crypto suites 1545 | | 1546 | +- session parameters 1547 | 1548 +- Transport2 1549 : : 1551 10.2.1 Key Method Registry and Registration 1553 The IANA is hereby requested to create a new subregistry for SDP 1554 security description key methods. An IANA key method registration 1555 MUST be documented in an RFC in accordance with the RFC 2434 1556 Standards Action and it MUST provide the name of the key method in 1557 accordance with the grammar for key-method-ext defined in Section 1558 9.1. 1560 10.2.2 Media Stream Transport Registry and Registration 1562 The IANA is hereby requested to create a new subregistry for SDP 1563 security description Media Stream Transports. An IANA media stream 1564 transport registration MUST be documented in an RFC in accordance 1565 with the RFC 2434 Standards Action and the procedures defined in 1566 Section 4 and 5 of this document. The registration MUST provide the 1567 name of the transport and a list of supported key methods. 1569 In addition, each new media stream transport registry must contain a 1570 crypto-suite registry and a session parameter registry as well as 1571 IANA instructions for how to populate these registries. 1573 10.3 Initial Registrations 1575 10.3.1 Key Method 1577 The following security descriptions key methods are hereby 1578 registered: 1580 inline 1582 10.3.2 SRTP Media Stream Transport 1584 The IANA is hereby requested to create an SDP Security Description 1585 Media Stream Transport subregistry for "SRTP". The key methods 1586 supported is "inline". The reference for the SDP security 1587 description for SRTP is this document. 1589 10.3.2.1 SRTP Crypto Suite Registry and Registration 1591 The IANA is hereby requested to create a new subregistry for SRTP 1592 crypto suites under the SRTP transport of the SDP Security 1593 Descriptions. An IANA SRTP crypto suite registration MUST indicate 1594 the crypto suite name in accordance with the grammar for srtp- 1595 crypto-suite-ext defined in Section 9.2. 1597 The semantics of the SRTP crypto suite MUST be described in an RFC 1598 in accordance with the RFC 2434 Standards Action, including the 1599 semantics of the "inline" key-method and any special semantics of 1600 parameters. 1602 The following SRTP crypto suites are hereby registered: 1604 AES_CM_128_HMAC_SHA1_80 1605 AES_CM_128_HMAC_SHA1_32 1606 F8_128_HMAC_SHA1_80 1608 The reference for these crypto-suites is provided in this document. 1610 10.3.2.2 SRTP Session Parameter Registration 1612 The IANA is hereby requested to create a new subregistry for SRTP 1613 session parameters under the SRTP transport of the SDP Security 1614 Descriptions. An IANA SRTP session parameter registration MUST 1615 indicate the session parameter name (srtp-session-extension as 1616 defined in Section 9.2); the name MUST NOT begin with the dash 1617 character ("-"). 1619 The semantics of the parameter MUST be described in an RFC in 1620 accordance with the RFC 2434 Standards Action. If values can be 1621 assigned to the parameter, then the format and possible values that 1622 can be assigned MUST be described in the RFC in accordance with the 1623 RFC 2434 Standards Action as well. Also, it MUST be specified 1624 whether the parameter is declarative or negotiated in the 1625 offer/answer model. 1627 The following SRTP session parameters are hereby registered: 1629 KDR 1630 UNENCRYPTED_SRTP 1631 UNENCRYPTED_SRTCP 1632 UNAUTHENTICATED_SRTP 1633 FEC_ORDER 1634 FEC_KEY 1635 WSH 1637 The reference for these parameters is this document. 1639 11 Acknowledgements 1641 This document is a product of the IETF MMUSIC working group and has 1642 benefited from comments from its participants. This document also 1643 benefited from discussions with Elisabetta Cararra, Earl Carter, 1644 Bill Foster, Matt Hammer, Cullen Jennings, Paul Kyzivat, David 1645 McGrew, Mats Naslund, Dave Oran, Jonathan Rosenberg, Dave Singer, 1646 Mike Thomas, Brian Weis, and Magnus Westerlund. 1648 12 Authors' Addresses 1650 Flemming Andreasen 1651 Cisco Systems, Inc. 1652 499 Thornall Street, 8th Floor 1653 Edison, New Jersey 08837 USA 1654 fandreas@cisco.com 1656 Mark Baugher 1657 5510 SW Orchid Street 1658 Portland, Oregon 97219 USA 1659 mbaugher@cisco.com 1660 Dan Wing 1661 Cisco Systems, Inc. 1662 170 West Tasman Drive 1663 San Jose, CA 95134 USA 1664 dwing@cisco.com 1666 13 Normative References 1668 [RFC3550] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, 1669 "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, 1670 STD 64, July 2003, http://www.ietf.org/rfc/rfc3550.txt. 1672 [RFC2234] D. Crocker, P. Overell, "Augmented BNF for Syntax 1673 Specifications: ABNF," RFC 2234, November 1997, 1674 http://www.ietf.org/rfc/rfc2234.txt. 1676 [SDP] M. Handley, V. Jacobson, "SDP: Session Description Protocol", 1677 RFC 2327, April 1998. 1679 [RFC2828] R. Shirey, "Internet Security Glossary", RFC 2828, May 1680 2000, http://www.ietf.org/rfc/rfc2828.txt. 1682 [RFC3264] J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with 1683 the Session Description Protocol (SDP)", RFC 3264, June 2202, 1684 http://www.ietf.org/rfc/rfc3264.txt. 1686 [srtp] M. Baugher, D. McGrew, M. Naslund, E. Carrara, K. Norrman, 1687 "The Secure Real-time Transport Protocol", RFC 3711, March 2004. 1689 [RFC1750] D. Eastlake 3rd, S. Crocker, J. Schiller, "Randomness 1690 Recommendations for Security", RFC 1750, December 1994, 1691 http://www.ietf.org/rfc/rfc1750.txt. 1693 [RFC3548] S. Josefsson, "The Base16, Base32, and Base64 Data 1694 Encodings", RFC 3548, July 2003. 1696 [RFC2434] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA 1697 Considerations Section in RFCs", RFC 2434, October 1998. 1699 [sprecon] Andreasen, F., Baugher, M., and D. Wing, "Security 1700 Preconditions for Session Description Protocol Media Streams", work 1701 in progress, February 2004. 1703 14 Informative References 1705 [RFC3407] F. Andreasen, "Session Description Protocol (SDP) Simple 1706 Capability Declaration", RFC 3407, October 2002, 1707 http://www.ietf.org/rfc/rfc3407.txt. 1709 [Bellovin] Steven M. Bellovin, "Problem Areas for the IP Security 1710 Protocols," in Proceedings of the Sixth Usenix Unix Security 1711 Symposium, pp. 1-16, San Jose, CA, July 1996. 1713 [GDOI] M. Baugher, B. Weis, T. Hardjono, H. Harney, "The Group 1714 Domain of Interpretation", RFC 3547, July 2003, 1715 http://www.ietf.org/rfc/rfc3547.txt. 1717 [kink] M. Thomas, J. Vilhuber, "Kerberized Internet Negotiation of 1718 Keys (KINK)", Work in Progress. 1720 [ike] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", RFC 1721 2409, November 1998, http://www.ietf.org/rfc/rfc2409.txt. 1723 [ipsec] Kent, S. and R. Atkinson, "Security Architecture for the 1724 Internet Protocol", RFC 2401, November 1998, 1725 http://www.ietf.org/rfc/rfc2401.txt. 1727 [maxprate] Westerlund, M., "A Transport-independent Bandwidth 1728 Modifier for the Session Description Protocol (SDP)," April 2004, 1729 http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-bwparam- 1730 06.txt 1732 [RFC2733] J. Rosenberg, H. Schulzrinne, "An RTP Payload Format for 1733 Generic Forward Error Correction", RFC 2733, December 1999, 1734 http://www.ietf.org/rfc/rfc2733.txt. 1736 [s/mime] Ramsdell B., "S/MIME Version 3 Message Specification", RFC 1737 2633, June 1999, http://www.ietf.org/rfc/rfc2633.txt. 1739 [pgp/mime] M. Elkins, "MIME Security with Pretty Good Privacy 1740 (PGP)", RFC 2015, October 1996, http://www.ietf.org/rfc/rfc2015.txt. 1742 [tls] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 1743 2246, January 1999, http://www.ietf.org/rfc/rfc2246.txt. 1745 [keymgt] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman, 1746 "Key Management Extensions for SDP and RTSP", Work in Progress. 1748 [mikey] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman, 1749 "MIKEY: Multimedia Internet KEYing", Work in Progress. 1751 [RFC2045] N. Freed, N. Borenstein, "Multipurpose Internet Mail 1752 Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 1753 2045, November 1996, http://www.ietf.org/rfc/rfc2045.txt. 1755 [RFC2104] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing 1756 for Message Authentication", RFC 2014, November 1997, 1757 http://www.ietf.org/rfc/rfc2104.txt. 1759 [skeme] H. Krawczyk, "SKEME: A Versatile Secure Key Exchange 1760 Mechanism for the Internet", ISOC Secure Networks and Distributed 1761 Systems Symposium, San Diego, 1996. 1763 [RFC3312] G. Camarillo, W. Marshall, J. Rosenberg, "Integration of 1764 Resource Management and Session Initiation Protocol (SIP)", RFC 1765 3312, October 2002, http://www.ietf.org/rfc/rfc3312.txt. 1767 [RFC2974] M. Handley, C. Perkins, E. Whelan, "Session Announcement 1768 Protocol", RFC 2974, October 2000, 1769 http://www.ietf.org/rfc/rfc2974.txt. 1771 [srtpf] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 1772 RTCP-based Feedback (RTP/SAVPF)", work in progress, October 2003. 1774 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1775 A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1776 Session Initiation Protocol", RFC 3261, June 2002. 1778 15 Full Copyright Statement 1780 Copyright (C) The Internet Society (2005). This document is subject 1781 to the rights, licenses and restrictions contained in BCP 78, and 1782 except as set forth therein, the authors retain all their rights. 1784 This document and the information contained herein are provided on 1785 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1786 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1787 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1788 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1789 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1790 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1792 Intellectual Property 1794 The IETF takes no position regarding the validity or scope of any 1795 Intellectual Property Rights or other rights that might be claimed 1796 to pertain to the implementation or use of the technology 1797 described in this document or the extent to which any license 1798 under such rights might or might not be available; nor does it 1799 represent that it has made any independent effort to identify any 1800 such rights. Information on the procedures with respect to 1801 rights in RFC documents can be found in BCP 78 and BCP 79. 1803 Copies of IPR disclosures made to the IETF Secretariat and any 1804 assurances of licenses to be made available, or the result of an 1805 attempt made to obtain a general license or permission for the use 1806 of such proprietary rights by implementers or users of this 1807 specification can be obtained from the IETF on-line IPR repository 1808 at http://www.ietf.org/ipr. 1810 The IETF invites any interested party to bring to its attention 1811 any copyrights, patents or patent applications, or other 1812 proprietary rights that may cover technology that may be required 1813 to implement this standard. Please address the information to the 1814 IETF at ietf-ipr@ietf.org. 1816 Acknowledgement 1818 Funding for the RFC Editor function is currently provided by the 1819 Internet Society.