idnits 2.17.1 draft-ietf-mmusic-sdescriptions-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 5 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 ** 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 114: '... transport and SHOULD be specified i...' RFC 2119 keyword, line 147: '...m. The crypto attribute MAY contain a...' RFC 2119 keyword, line 149: '... a=crypto MAY also contain "security...' RFC 2119 keyword, line 153: '... its value MAY be unique to a partic...' RFC 2119 keyword, line 164: '...ies. "a=crypto" MUST NOT appear at th...' (99 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 510 has weird spacing: '..., which is ze...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: key-length = 1*(DIGIT) ; length in bytes salt-length = 1*(DIGIT) ; length in bytes key = 1*(base64) salt = 1*(base64) key-salt = key salt ; key and salt concatenated and ; then base64 encoded [section ; 6.8 of RFC2045] lifetime = ["2^"] 1*(DIGIT) mki = "/" mki-length ":" mki-value mki-length = 1*3(DIGIT) ; MUST be multiple of 8 and ; MUST not exceed 128 mki-value = 1*(base64) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 24, 2003) is 7731 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2119' is mentioned on line 91, but not defined == Missing Reference: 'SRTP' is mentioned on line 532, but not defined == Unused Reference: 'Bellovin' is defined on line 964, but no explicit reference was found in the text == Unused Reference: 'RFC1889' is defined on line 978, but no explicit reference was found in the text == Unused Reference: 'RFC2045' is defined on line 982, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 986, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Bellovin' ** Obsolete normative reference: RFC 1889 (Obsoleted by RFC 3550) ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2327 (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 2828 (Obsoleted by RFC 4949) ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) Summary: 12 errors (**), 0 flaws (~~), 13 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Mark Baugher 3 MMUSIC Working Group Dan Wing 4 INTERNET-DRAFT Cisco Systems 5 EXPIRES: August 2003 February 24, 2003 7 SDP Security Descriptions for Media Streams 8 10 Status of this memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as reference 23 material or cite them other than as "work in progress". 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/lid-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 Abstract 33 This Internet Draft gives a cryptographic attribute to Session 34 Description Protocol (SDP) media streams. The attribute describes a 35 cryptographic key and other parameters, which serve to configure 36 security for a media stream. This draft also defines the SRTP 37 parameters for the attribute. The SDP crypto attribute requires the 38 services of a data security protocol to secure the SDP message. 40 TABLE OF CONTENTS 42 1.0 Notational Conventions...........................................2 43 2.0 Introduction.....................................................3 44 3.0 SDP "Crypto" Attribute and Parameters............................4 45 3.1 Crypto-suite....................................................4 46 3.2 Application Parameter...........................................4 47 3.3 Key Parameter...................................................4 48 3.4 Session Parameters..............................................5 49 3.5 Examples........................................................5 50 4.0 RTP/SAVP (SRTP) Security Descriptions............................6 51 4.1 Crypto-suites...................................................7 52 4.1.1 AES_CM_128_HMAC_SHA1_80.....................................7 53 4.1.2 AES_CM_128_HMAC_SHA1_32.....................................7 54 4.1.3 F8_128_HMAC_SHA1_80.........................................7 55 4.1.4 F8_128_HMAC_SHA1_32.........................................7 56 4.1.5 Adding new CRYPTO-SUITE definitions.........................8 57 4.2 Application Parameter...........................................8 58 4.3 Key Parameter...................................................8 59 4.3.1 INLINE Usage................................................8 60 4.3.2 INLINE Definition...........................................9 61 4.4 Session Parameters.............................................10 62 4.4.1 SSRC=n.....................................................10 63 4.4.2 ROC=n......................................................11 64 4.4.3 KEY_DERIVATION_RATE=n......................................11 65 4.4.4 UNENCRYPTED................................................11 66 4.4.5 FEC_ORDER=order............................................12 67 4.4.6 UNAUTHENTICATED............................................12 68 5.0 Use with Offer/Answer...........................................12 69 5.1 Offerer Processing.............................................12 70 5.2 Answerer Processing............................................13 71 5.3 Non-RTP/SAVP Answerers.........................................13 72 5.4 Offer/Answer Example: Receiver Supports SRTP...................14 73 5.5 Offer/Answer Example: Different SRTP and SRTCP keys............14 74 5.6 Use of a=crypto With Active Media Streams......................15 75 6.0 Security Considerations.........................................16 76 6.1 Authentication of packets......................................16 77 6.1 Reuse of Keying Material ("Two-Time Pad")......................16 78 6.2 Signaling Authentication and Signaling Encryption..............17 79 7.0 Grammar.........................................................18 80 8.0 Acknowledgements................................................19 81 9.0 Authors' Addresses..............................................20 82 10.0 References.....................................................20 83 11.0 Full Copyright Statement.......................................21 85 1.0 Notational Conventions 87 The key words "MUST", "MUST NOT", "REQUIRED", "MUST", "MUST NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in [RFC2119]. The 90 terminology conforms to [RFC2828]. 92 2.0 Introduction 94 Session Description Protocol (SDP) describes multimedia sessions, 95 such as Real-time Transport Protocol (RTP), white board, fax, modem 96 and other media sessions. Security services such as authentication 97 and confidentiality are often needed for these media streams. When 98 run under the RTP/SAVP profile, for example, an RTP stream uses the 99 Secure Real-time Transport Protocol (SRTP). The "RTP/SAVP" 100 descriptor in an SDP m=line signals the use of SRTP for a media 101 stream, but there are no means within SDP itself to configure SRTP 102 beyond using defaults values. This document specifies an SDP 103 attribute to signal a cryptographic parameters in addition to a key 104 for SRTP and other SDP media streams. 106 Thus, the SDP crypto attribute provides both generic and specific 107 security descriptions for SDP media streams that can be used for 108 various transports, including SRTP. In this way, the crypto 109 attribute can be extended to non-SRTP transports such as white 110 board, modem, fax, and other transports that could use various 111 security protocols such as IPsec or TLS. Each SDP media stream, 112 however, needs its own definitions that assign values to crypto- 113 attribute parameters. These definitions are unique to the SDP 114 transport and SHOULD be specified in an Internet RFC. This document 115 defines the parameter values for SRTP. With this document, an 116 application developer can describe an SRTP key and its configuration 117 according to application-specific needs. 119 It would be self-defeating, however, to not secure cryptographic 120 keys and other parameters at least as well as SRTP secures RTP 121 messages or IPsec secures IP packets. Data security protocols such 122 as SRTP rely upon a separate key management system to securely 123 establish encryption and/or authentication keys. Key management 124 protocols provide authenticated key establishment (AKE) procedures 125 to authenticate the identity of each endpoint and protect against 126 man-in-the-middle, reflection/replay, connection hijacking and some 127 denial of service attacks [skeme]. Along with the key, an AKE 128 protocol such as MIKEY, GDOI, KINK, IKE or TLS securely disseminates 129 information describing both the key and the data-security session 130 (for example, whether SRTCP is encrypted or unencrypted in an SRTP 131 session). AKE is needed because it is pointless to provide a key 132 over a medium where an attacker can snoop the key, alter the 133 definition of the key to render it useless, or change the parameters 134 of the security session to gain unauthorized access to session- 135 related information. 137 SDP was not designed to provide AKE services, and the media security 138 descriptions that follow do not add AKE services to SDP. This 139 specification is no replacement for a key management protocol or for 140 the conveyance of key management messages in SDP [keymgt]. SDP 141 media-stream security descriptions are suitable for restricted cases 142 where IPsec, TLS, or some other data-security protocol protects the 143 SDP message. 145 This draft adds security descriptions to SDP messages through a new 146 SDP attribute named "crypto", which provides the cryptographic 147 parameters of a media stream. The crypto attribute MAY contain a 148 cryptographic key and other parameters that describe the key. 149 a=crypto MAY also contain "security session parameters" that are 150 unique to a transport. 152 The a=crypto parameter is applicable to all media transports, but 153 its value MAY be unique to a particular transport. Section 3 154 specifies the SDP crypto attribute generically. Section 4 defines 155 the crypto attribute for SRTP. Section 5 discusses use of the 156 crypto attribute in Offer/Answer exchanges. Section 6 recites 157 security considerations, and Section 7 gives an Augmented-BNF 158 grammar for the security descriptions. 160 3.0 SDP "Crypto" Attribute and Parameters 162 A new media-level SDP attribute called "crypto" describes the 163 cryptographic and security-session parameters for one or more media 164 entries. "a=crypto" MUST NOT appear at the SDP session level. 166 a=crypto: [] 168 The ordering of multiple a=crypto lines is significant, and the 169 most-preferred is listed first; see section 5. The next sections 170 describes these fields in more detail. 172 3.1 Crypto-suite 174 "Crypto-suite" describes all needed information about the encryption 175 and authentication algorithms for the transport. The "crypto-suite" 176 parameter is unique to the transport. 178 3.2 Application Parameter 180 A particular transport can have multiple protocols that are secured 181 differently. For example, when using the RTP/SAVP transport, both 182 the SRTP and SRTCP protocols will be used, but the security for each 183 MAY be different: A longer authentication output tag might be 184 desired for the SRTCP control protocol than for the SRTP media 185 stream. The "application" parameter allows separate security 186 descriptions for separate protocols of a transport. 188 3.3 Key Parameter 190 The key parameter can contain an inline key descriptor, or can be a 191 pointer to a uri which contains the actual key: 193 inline:key-descriptor 194 uri:absolute-uri 196 If the key parameter starts with the string "uri:", the URI method 197 is used and the value that follows is a Uniform Resource Identifier. 198 The URI is a resource that SHOULD be queried to obtain the 199 cryptographic key for the session. The format or protocols used for 200 the uri are beyond the scope of this document. 202 The INLINE method is invoked when the key parameter starts with the 203 string "inline:" - and the cryptographic key is encoded according 204 to a transport-specific syntax. Thus, the URI method is transport 205 generic and the INLINE method is transport specific. Section 4 206 describes the INLINE key-parameter syntax for RTP/SAVP, the SRTP 207 media transport type. 209 If SDP descriptions for new media-stream transports are defined in 210 the future, new methods MAY be defined in an Internet RFC. 212 3.4 Session Parameters 214 "Session" parameters are specific to the SDP transport and optional. 215 Section 4 describes the session parameters for RTP/SAVP. 217 3.5 Examples 219 The first example shows a=crypto for the RTP/SAVP transport type (as 220 defined in Section 4). 222 v=0 223 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 224 s=SDP Seminar 225 i=A Seminar on the session description protocol 226 u=http://www.example.com/seminars/sdp.pdf 227 e=j.doe@example.com (Jane Doe) 228 c=IN IP4 224.2.17.12/127 229 t=2873397496 2873404696 230 a=recvonly 231 m=video 51372 RTP/SAVP 31 232 a=crypto:AES_CM_128_HMAC_SHA1_80 both 233 inline:16/14/d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj/2^20/1:32 234 m=audio 49170 RTP/SAVP 0 235 a=crypto:AES_CM_128_HMAC_SHA1_32 srtp 236 inline:16/14/NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj/2^20/1:32 237 a=crypto:AES_CM_128_HMAC_SHA1_80 srtcp 238 inline:16/14/ ZkBkQythOTg3NjU0MSEzMDMyMT01NDg5N2RlRkF/2^20/1:32 239 m=application 32416 udp wb 240 a=orient:portrait 242 This SDP message describes three "recvonly" media streams, two of 243 which use the RTP/SAVP transport. The first a=crypto line appears 244 in the m=video media entry; it is associated with the RTP/SAVP 245 transport of the m=video line and uses the SRTP default crypto- 246 suite, "AES_CM_128_HMAC_SHA1_80," and its key parameter carries the 247 SRTP master key data and descriptors inline. The m=video a=crypto 248 attribute applies to both SRTP and SRTCP. The m=audio media entry 249 uses the "crypto-suite=AES_CM_128_HMAC_SHA1_32," having a short 32- 250 bit tag for SRTP, and it uses AES_CM_128_HMAC_SHA1_80 for SRTCP. 251 The RTP/SAVP-specific descriptions are defined in the next section. 253 4.0 RTP/SAVP (SRTP) Security Descriptions 255 The generic security descriptions of the preceding section need 256 parameter values for specific media transports; this section defines 257 the crypto attribute values and parameters for the RTP/SAVP (SRTP) 258 transport. SRTP services for a media stream MUST be signaled 259 through the presence of an RTP/SAVP transport descriptor in the m= 260 line and SHALL apply only to that media entry. 262 There is no assurance that a receiver is capable of configuring its 263 SRTP service with a particular crypto attribute parameter, but SRTP 264 guarantees minimal interoperability among SRTP systems through the 265 default SRTP parameters [srtp]. More capable SRTP receivers support 266 a variety of parameter values beyond the SRTP defaults and can be 267 configured by the crypto attribute. A receiver that does not 268 recognize a=crypto and assumes default SRTP parameters might receive 269 a stream that uses non-default parameters, which will cause that 270 receiver to fail. An Offer/Answer capabilities exchange, however, 271 allows sender and receiver to agree on parameters before 272 commencement of the multimedia session (see Section 5.0). 274 There are over twenty cryptographic parameters listed in the SRTP 275 specification. Many of these parameters have fixed values for 276 particular cryptographic transforms. At the time of session 277 establishment, however, there is usually no need to provide unique 278 settings for many of the SRTP parameters. Thus, it is possible to 279 simplify the list of parameters in "cryptographic suites" that fix a 280 set of SRTP parameter values for the security session. The list of 281 SRTP parameters, including the crypto-suite parameter for SDP 282 a=crypto follows. 284 SDP SRTP Parameter Description 285 ------------------ ----------- 286 CRYPTO-SUITE Encryption and authentication transforms 287 SSRC SSRC of the sender of the SDP message 288 ROC Roll-over counter 289 KEY_DERIVATION_RATE Rate that the pseudo-random function 290 is applied to a key 291 UNENCRYPTED Protocol messages are not encrypted 292 UNAUTHENTICATED SRTP messages are not authenticated 293 FEC_ORDER Order of forward error correction (FEC) 294 relative to SRTP services 296 Please refer to the SRTP specification for a complete list of 297 parameters and their descriptions [Section 8.2, srtp]. The CRYPTO- 298 SUITE and the five session parameters shown in the table above are 299 described in the following sections. If a receiver cannot recognize 300 a parameter or value, then the receiver MUST NOT participate in the 301 media stream and SHOULD log an "invalid name" condition unless the 302 receiver is participating in an Offer/Answer exchange (Section 5). 304 4.1 Crypto-suites 306 A crypto-suite value appears as the first parameter in a=crypto. The 307 CRYPTO-SUITE value MAY be different for SRTP and SRTCP as described 308 in Section 4.2. If a receiver does not support the particular 309 crypto-suite, then the receiver MUST NOT participate in the media 310 stream and SHOULD log an "unrecognized crypto-suite" condition 311 unless the receiver is participating in an Offer/Answer exchange 312 (Section 5). RTP/SAVP has four crypto-suites as described below. 314 4.1.1 AES_CM_128_HMAC_SHA1_80 316 This is the SRTP default AES Counter Mode cipher and HMAC-SHA1 317 message authentication having a 80-bit authentication tag. The 318 encryption and authentication key lengths are 128 bits. The master 319 salt value is 112 bits and the session salt value is 112 bits. The 320 PRF is the default SRTP pseudo-random function that uses AES Counter 321 Mode with a 128-bit key length. 323 4.1.2 AES_CM_128_HMAC_SHA1_32 325 The SRTP AES Counter Mode cipher is used with HMAC-SHA1 message 326 authentication having an 32-bit authentication tag. The encryption 327 and authentication key lengths are 128 bits. The master salt value 328 is 112 bits and the session salt value is 112 bits. These values 329 apply to SRTP and to SRTCP. The PRF is the default SRTP pseudo- 330 random function that uses AES Counter Mode with a 128-bit key 331 length. 333 4.1.3 F8_128_HMAC_SHA1_80 335 The SRTP f8 cipher is used with HMAC-SHA1 message authentication 336 having a 80-bit authentication tag. The encryption and 337 authentication key lengths are 128 bits. The master salt value is 338 112 bits and the session salt value is 112 bits. The PRF is the 339 default SRTP pseudo-random function that uses AES Counter Mode with 340 a 128-bit key length. 342 4.1.4 F8_128_HMAC_SHA1_32 344 The SRTP f8 cipher is used with HMAC-SHA1 message authentication 345 having a 32-bit authentication tag. The encryption and 346 authentication key lengths are 128 bits. The master salt value is 347 112 bits and the session salt value is 112 bits. The PRF is the 348 default SRTP pseudo-random function that uses AES Counter Mode with 349 a 128-bit key length. 351 4.1.5 Adding new CRYPTO-SUITE definitions 353 If new transforms are added to SRTP, new definitions for those 354 transforms SHOULD be given for the SDP crypto attribute and 355 published in an Internet RFC. Sections 4.1.1 through 4.1.4 356 illustrate how to define CRYPTO-SUITE values for particular 357 cryptographic transforms. New definitions MAY be added to existing 358 transforms, moreover, to augment or modify definitions 4.1.1 through 359 4.1.4. 361 4.2 Application Parameter 363 The "application" parameter indicates if this a=crypto line applies 364 to only secure RTP, only secure RTCP, or to both secure RTP and 365 RTCP. The values for this are "srtp", "srtcp", or "both". If a 366 receiver finds an "srtp" a=crypto without a corresponding "srtcp" 367 a=crypto, or vice versa, it MUST NOT participate in the media stream 368 and SHOULD log an "missing crypto attribute" condition. 370 4.3 Key Parameter 372 If the "key" parameter has a "uri:" descriptor, the value is a 373 Uniform Resource Identifier value as described in Section 3. When 374 key-parameter has an "inline:" descriptor, the value contains a 375 cryptographic key that MUST be a unique random value with respect to 376 other "inline:" values in the SDP message. 378 4.3.1 INLINE Usage 380 The "inline:" descriptor is applicable to SDP media-entries having a 381 "recvonly," "sendonly" or "sendrecv" direction attribute. In 382 general, the source of data will generate the master key to protect 383 its data, but this is a matter of local policy and application 384 preference. Multicast applications, for example, often will use a 385 third-party provider of a master key. Thus, when the inline key is 386 used, it SHOULD be used for a recvonly media-entry or for the 387 received stream of sendrecv media-entry. The inline key MAY be used 388 for a sendonly media-entry or for streams that are sent and received 389 on a sendrecv media-entry. The following paragraphs add detail to 390 these inline-key recommendations for recvonly, sendonly, and 391 sendrecv media entries. 393 In the recvonly case, the inline SRTP master key SHOULD be used to 394 derive keys [SRTP] to decrypt/authenticate incoming SRTP messages. 395 When the a=crypto "application" parameter is set to "both," the 396 receiver also derives keys from the same master key to 397 decrypt/authenticate incoming SRTCP messages. When that receiver 398 sends RTP Receiver Reports for the incoming SRTP stream, it SHOULD 399 derive keys from the same master key to encrypt/authenticate 400 outgoing SRTCP messages for that SRTP stream. 402 In the sendonly case, the inline SRTP master key SHOULD be used to 403 derive keys [SRTP] to encrypt and authenticate outgoing SRTP 404 messages. When the a=crypto "application" parameter is set to 405 "both," the sender also derives keys from the same SRTP master key 406 to encrypt and authenticate outgoing SRTCP message. When that 407 sender sends RTP Sender Reports for the outgoing SRTP stream, it 408 SHOULD derive keys from the same master key to encrypt/authenticate 409 outgoing SRTCP messages for the outgoing SRTP stream. 411 In the sendrecv case, the inline SRTP master key SHOULD be used as 412 in the recvonly case described above but MAY also be used as in the 413 sendonly case. 415 4.3.2 INLINE Definition 417 If the identifier is "inline", the key-descriptor MUST have the 418 following format. 420 key_length/salt_length/BASE64(key||salt)/lifetime/MKI:MKI_length 422 The "key_length" is the integer length of the SRTP master key in 423 bytes, and "salt_length" is the integer length of the master salt in 424 bytes. If their sum is less than the sum of the lengths of the 425 master key and salt of the crypto suite, then the receiver MUST NOT 426 participate in the media stream and SHOULD log a "key length too 427 short" condition. If their sum is greater than the crypto-suite sum, 428 then bytes are truncated from the right (i.e. "little end"). The 429 key_length and salt_length MUST appear in the "inline" encoding. For 430 example, 432 inline:16/14/d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj/2^20/1:32 (1) 434 has a key_length of 16 and a salt_length of 14. 436 The third part of the "inline" encoding is the cryptographic master 437 key appended with the master salt ("||" denotes concatenation). 438 Each master key and salt MUST be a random number and MUST be unique 439 to the SDP message. Both are concatenated and then base-64 encoded. 440 If the length of the concatenated keys (after being decoded from 441 base 64) does not equal or exceed the sum of the key_length and 442 salt_length, the receiver MUST NOT participate in the media stream 443 and SHOULD log a "inline encoding too short" condition. For 444 example, 446 inline:16/8/YUJDZGVmZ2hpSktMbW9QUXJzVHVWd3l6//1066:32 (2) 447 has a key_length of 16, a salt_length of 8, and a 32-character key 448 and concatenated salt that is base-64 encoded: The 24-character 449 key/salt concatenation is expanded to 32 characters by the three-in- 450 four encoding of base 64. 452 The fourth part of the of the "inline" encoding is the OPTIONAL 453 lifetime of the master key as measured in number of packets 454 encrypted or authenticated with that key. The lifetime value MAY be 455 written as an non-zero, positive integer or as a power of 2, and is 456 indicated with "2^"; see the ABNF in Section 7 for details. The 457 default value is 2^48, which is 2^48 packets encrypted with a master 458 key according to the SRTP standard [srtp]. The "lifetime" value 459 MUST NOT exceed the maximum packets lifetime for the crypto-suite 460 (e.g. 2^48 for AES Counter Mode with a 128-bit key). If lifetime is 461 too large or otherwise invalid, then the receiver MUST NOT 462 participate in the media stream and SHOULD log an "invalid lifetime" 463 condition. The default MAY be implicitly signaled by having no 464 described value for lifetime (i.e. "//"). This is convenient when 465 the srtp crypto_key lifetime is allowed to default. Trailing 466 slashes ("/") MUST follow the master key and lifetime; otherwise, 467 the receiver MUST NOT participate in the media stream and SHOULD log 468 an "invalid inline encoding" condition. Example (1), above, shows a 469 case where the lifetime is specified as 2^20 while example (2) shows 470 an empty lifetime that implicitly uses the SRTP default value of 471 2^48. 473 The MKI value is OPTIONAL as is its specified bit length (see 474 Section 7). "MKI" is the master key index associated with the 475 srtp_master key. If the MKI is given, then the length of the MKI 476 MUST also be given and separated from the MKI by a colon (":"). The 477 MKI_length is the size of the MKI field in the SRTP packet, 478 specified in bits, and MUST be a positive multiple of 8. If the 479 MKI_length is not given or if the value exceeds 128, then the 480 receiver MUST NOT participate in the media stream and SHOULD log an 481 "invalid MKI_length" condition. If the value of the MKI is larger 482 than allowed by MKI_length, then the receiver MUST NOT participate 483 in the media stream and SHOULD log an "invalid MKI" condition. The 484 substring "1:32" in example (1) assigns to the key a key index of 1 485 that is 32 bits long, and example (2) assigns a 32-bit key index of 486 1066 to the key. 488 4.4 Session Parameters 490 The "session" parameters are OPTIONAL and MAY override SRTP session 491 defaults for the SRTP and SRTCP streams. These parameters configure 492 an RTP session for SRTP services. 494 4.4.1 SSRC=n 496 The value n is an integer in the range of 0..2^32-1 for the RTP SSRC 497 parameter, which is undefined by default. This is the RTP SSRC of 498 the sender of the SDP message. If n is invalid, the receiver MUST 499 NOT participate in the media stream but SHOULD log an "invalid SSRC" 500 condition. 502 SSRC MAY be specified when the setting of the "application" 503 parameter is "srtp" or "both." Otherwise the receiver MUST NOT 504 participate in the media stream and SHOULD log an "invalid session 505 parameter" condition. 507 4.4.2 ROC=n 509 The value "n" is an integer in the range of 0..2^32-1 for the SRTP 510 rollover counter (ROC), which is zero by default. The ROC MAY be 511 set to a non-zero value for an ongoing RTP/SAVP stream in which the 512 SRTP ROC has cycled one or more times [srtp]. The receiver of the 513 SDP message SHOULD refresh the ROC value before joining a session 514 "late." How "late" is defined depends on the rate of the particular 515 RTP stream and the time that has elapsed since its commencement. 516 Depending on the nature of the session control, the late-joining 517 receiver might need to refresh its ROC value through a unicast 518 exchange or through receipt of a multicast SDP message. If n is 519 invalid, then the receiver MUST NOT participate in the media stream 520 but SHOULD log an "invalid ROC" condition. 522 ROC MAY be specified when the setting of the "application" parameter 523 is "srtp" or "both." Otherwise the receiver MUST NOT participate in 524 the media stream and SHOULD log an "invalid session parameter" 525 condition. 527 4.4.3 KEY_DERIVATION_RATE=n 529 The value n may be an integer in the set {1,2,4,...,2^24}, i.e. a 530 power of 2 between 2^0 to 2^24, inclusive. The SRTP key derivation 531 rate controls how frequently a new session key is derived from an 532 SRTP master key [SRTP]. The default value is 0, which causes the 533 key derivation function to be invoked exactly once. 535 Key_Derivation_Rate MAY be specified when the "application" 536 parameter setting is "srtp" or "both". Otherwise the receiver MUST 537 NOT participate in the media stream and SHOULD log an "invalid 538 session parameter" condition. 540 4.4.4 UNENCRYPTED 542 This indicates that the SRTP or SRTCP stream is not encrypted. SRTP 543 and SRTCP messages are encrypted by default. 545 UNENCRYPTED MAY be specified for "srtp", "srtcp", or "both". If the 546 a=crypto "application" setting is "both," then both the SRTP and 547 SRTCP streams are unencrypted. 549 4.4.5 FEC_ORDER=order 551 The forward error correction values for "order" are FEC_SRTP, 552 SRTP_FEC, or SPLIT [mikey]. FEC_SRTP signals that FEC is applied 553 before SRTP processing on the sender and after SRTP processing on 554 the receiver; FEC_SRTP is the default. SRTP_FEC is the reverse 555 processing. SPLIT signals that SRTP encryption occurs on the 556 sender, followed by FEC processing, followed by SRTP authentication; 557 processing is reversed on the receiver. If the receiver cannot 558 recognize the order value, then the receiver MUST NOT participate in 559 the media stream but SHOULD log an "invalid FEC_ORDER" condition. 561 If specified, it MUST only be specified with "srtp" or "both." 562 Otherwise the receiver MUST NOT participate in the media stream and 563 SHOULD log an "invalid session parameter" condition. 565 4.4.6 UNAUTHENTICATED 567 This parameter signals that SRTP messages are not authenticated. 568 SRTP authenticates SRTP messages by default (see Security 569 Considerations). 571 If specified, it MUST only be specified with "srtp", or "both" since 572 it applies only to the SRTP stream: Authentication is mandatory for 573 secure RTCP. If UNAUTHENTICATED appears in an a=crypto with an 574 "srtcp" application parameter, the receiver MUST NOT participate in 575 the media stream and SHOULD log an "invalid session parameter" 576 condition. 578 5.0 Use with Offer/Answer 580 A receiver that does not recognize a=crypto and assumes default SRTP 581 parameters might receive a stream that uses non-default parameters, 582 which will cause that receiver to fail. An Offer/Answer 583 capabilities exchange, however, allows sender and receiver to agree 584 on parameters before commencement of the multimedia session. The 585 sender and receiver use an Offer/Answer exchange [RFC3264] to match 586 cryptographic capabilities. 588 This section discusses Offer/Answer exchanges only for the RTP/SAVP 589 (SRTP). A future revision of this document will consider 590 Offer/Answer exchanges for security descriptions in general. 592 5.1 Offerer Processing 594 On each SDP media line (m=) where the is "RTP/SAVP", the 595 offerer MAY follow that media line with at least one a=crypto line. 596 The lines are specified in preference order, with the most preferred 597 listed first. The offerer determines the crypto parameters based on 598 its capabilities and its security policies. 600 To specify a list of preferred crypto suites for RTP, RTCP, or both, 601 the offerer includes separate a=crypto lines, in preference order. 602 Each offer is grouped. If separate rtp and rtcp keys are wanted, 603 the srtp a=crypto line MUST be sent first, and both the RTP and RTCP 604 keys MUST always be sent, even if the endpoint is recvonly. 606 The offerer obtains keying material or the uri pointing to a 607 keyserver by means that are outside the scope of this specification 608 (e.g. the offerer could generate the material or request the 609 material from a third party). 611 5.2 Answerer Processing 613 For each SDP media line where the is RTP/SAVP and the 614 stream is bi-directional stream will be created, the answer MUST 615 include a media line with its set to RTP/SAVP in order 616 to accept the offer; otherwise, the offer is rejected for that media 617 entry. 619 The answerer examines the a=crypto lines, in order. If the a=crypto 620 line indicates the application is rtp, and the line immediately 621 following indicates the application is rtcp, the receiver groups 622 these two lines together; otherwise, this group is ignored as it is 623 syntactically invalid. If the a=crypto line indicates the 624 application is "both", it is grouped by itself. 626 After grouping, the answerer selects the first group of a=crypto 627 that it supports, considering the answerer's capabilities and its 628 security policies. 630 After selecting one group, the answerer obtains keys appropriate for 631 the selected crypto algorithm(s). The key MUST have the same key 632 length and salt length as the offer. 634 To set up the bi-directional media with set to RTP/SAVP, 635 the answerer includes one or two a=crypto lines after the media 636 line. If the offer indicated separate keys for RTP and RTCP, the 637 answer MUST do the same. 639 5.3 Non-RTP/SAVP Answerers 641 If a media line with set to RTP/SAVP is sent to a device 642 that doesn't suppport RTP/SAVP, that media line will not be 643 processed. 645 If an offerer wants to interoperate with such a device, albeit 646 without the benefits of SRTP or SRTCP, the offerer MUST include an 647 additional media line with set to RTP/AVP, and other 648 values in that line MUST match the values of the associated 649 "RTP/SAVP" media line. This second media line would be specified 650 after all of the attribute (a=) lines for the RTP/SAVP media 652 5.4 Offer/Answer Example: Receiver Supports SRTP 654 In this example, the offerer supports two crypto suites (F8 and 655 AES). When presented with multiple "a=crypto" lines for an "m=" 656 line, the answerer will chose the first crypto suite that it 657 supports, and the answerer MUST reply with only one "a=crypto" line 658 per "m=" line 660 Offerer transmits: 661 v=0 662 o=sam 2890844526 2890842807 IN IP4 10.47.16.5 663 s=SRTP Discussion 664 i=A discussion of Secure RTP 665 u=http://www.example.com/seminars/srtp.pdf 666 e=marge@example.com (Marge Simpson) 667 c=IN IP4 224.2.17.12/127 668 t=2873397496 2873404696 669 a=recvonly 670 m=audio 49170 RTP/SAVP 0 671 a=crypto:AES_CM_128_HMAC_SHA1_80 both 672 inline:16/14/WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz/20/1:32 673 a=crypto:F8_128_HMAC_SHA1_80 both 674 inline:16/14/MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm/20/1:32 676 Answerer transmits: 677 v=0 678 o=jill 25690844 8070842634 IN IP4 10.47.16.5 679 s=SRTP Discussion 680 i=A discussion of Secure RTP 681 u=http://www.example.com/seminars/srtp.pdf 682 e=homer@example.com (Homer Simpson) 683 c=IN IP4 224.2.17.11/128 684 t=2873397526 2873405696 685 a=sendonly 686 m=audio 32640 RTP/SAVP 0 687 a=crypto:F8_128_HMAC_SHA1_80 both 688 inline:16/14/MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm/20/1:32 690 In this case, the session would use the F8_128_HMAC_SHA1_80 crypto 691 suite for the RTP and RTCP traffic it generates. 693 5.5 Offer/Answer Example: Different SRTP and SRTCP keys 695 In this example, the offerer requests use of one crypto suite for 696 SRTP (AES) and a different crypto suite for RTCP. 698 Offerer transmits: 699 v=0 700 o=sam 2890844526 2890842807 IN IP4 10.47.16.5 701 s=SRTP Discussion 702 i=A discussion of Secure RTP 703 u=http://www.example.com/seminars/srtp.pdf 704 e=marge@example.com (Marge Simpson) 705 c=IN IP4 224.2.17.12/127 706 t=2873397496 2873404696 707 a=recvonly 708 m=audio 49170 RTP/SAVP 0 709 a=crypto:AES_CM_128_HMAC_SHA1_80 rtp 710 inline:16/14/WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz/20/1:32 711 a=crypto:F8_128_HMAC_SHA1_80 rtcp 712 inline:16/14/MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm/20/1:32 714 Answerer transmits: 715 v=0 716 o=jill 25690844 8070842634 IN IP4 10.47.16.5 717 s=SRTP Discussion 718 i=A discussion of Secure RTP 719 u=http://www.example.com/seminars/srtp.pdf 720 e=homer@example.com (Homer Simpson) 721 c=IN IP4 224.2.17.11/128 722 t=2873397526 2873405696 723 a=sendonly 724 m=audio 32640 RTP/SAVP 0 725 a=crypto:AES_CM_128_HMAC_SHA1_80 rtp 726 inline:16/14/8NxJiu9zZW1jdGwgKCkgewkyMjA7fQp9CnVubTnC/20/1:32 727 a=crypto:F8_128_HMAC_SHA1_80 rtcp 728 16/14/c2VtZ2V0KSkgewogICAgc3V/20/1:32 730 5.6 Use of a=crypto With Active Media Streams 732 When an active SRTP session is rekeyed, this is indicated by sending 733 a new SDP. Rekey MUST NOT be done with an Offer/Answer exchange, 734 but rather as a unidirectional SDP transmission. 736 When the Offerer needs to rekey, the Offerer MUST only send a=crypto 737 lines which match a=crypto lines it had received in the Answer. 739 When an SRTP or SRTCP transmitter needs to rekey, the only new 740 values permitted in the a=crypto line(s) are the new key and new 741 salt -- other cryptographic parameters MUST NOT be changed. 743 If the Answerer selected a=crypto lines using the "inline" method, 744 the exact same a=crypto line(s) as agreed to in the Answer MUST be 745 sent and a new new inline key MUST be sent. 747 If the Answer selected a=crypto lines using the "uri" method, the 748 sender MAY transmit the same uri, and the recipient MUST re-fetch 749 the uri. 751 6.0 Security Considerations 753 One needs to define SDP security descriptions for a specific SDP 754 media transport for a=crypto to be useful. The definitions SHOULD 755 be specified in an Internet RFC, which has security implications 756 that MUST be considered in the RFC. This section considers the SRTP 757 descriptions for the RTP/SAVP transport as specified in this 758 Internet Draft. 760 6.1 Authentication of packets 762 RTP messages are vulnerable to a variety of attacks such as replay 763 and forging. To limit these attacks, SRTP message integrity and 764 anti-replay mechanisms SHOULD be used. Source authentication of 765 unicast SRTP messages SHOULD be performed [srtp]. Note that SRTP 766 source-message authentication does not authenticate the IP-address 767 of the SRTP source, but ensures that the SRTP message that the SRTP 768 receiver had received is exactly what the SRTP sender had sent. 769 Source authentication of multicast SRTP messages is today non- 770 standard and hence for further study. Use of the UNAUTHENTICATED 771 parameter therefore, is NOT RECOMMENDED. SRTP supports this setting, 772 however, for voice applications where authentication is implicit in 773 the application [srtp]. In general, applications SHOULD NOT set 774 UNAUTHENTICATED. 776 6.1 Reuse of Keying Material ("Two-Time Pad") 778 Misconfigured SRTP sessions, moreover, are vulnerable to attacks on 779 their encryption services when running crypto suites of Sections 780 4.1.1, 4.1.2 and 4.1.3. An SRTP encryption service is "mis- 781 configured" when two or more media streams are encrypted using the 782 same AES keystream. When senders and receivers share derived 783 session keys, SRTP requires that the SSRCs of session participants 784 make them unique, which is violated in the case of SSRC collision: 785 RTP SSRC collision reveals SRTP or SRTCP plaintext during the time 786 that identical keystreams were used [srtp]. An attacker, for 787 example, might collect SRTP and SRTCP messages and await a 788 collision. This attack on the AES-CM and AES-f8 encryption is 789 avoided entirely when each media stream has its own unique master 790 key, as this document requires (Section 4.2). There is risk of 791 attack, however, when an SDP media stream has an "a=sendrecv" 792 direction attribute and a pair of senders are sharing a master key 793 for their encryption (i.e. a weaker condition than sharing a master 794 key). It is RECOMMENDED, therefore, that a sendrecv stream have two 795 SRTP master keys, one for each directional stream. By implication, 796 the SDP message that describes the sendrecv stream MUST NOT be a 797 multicast media stream that provides inline keys from multiple 798 receivers. For the same reason, the risk recurs when a media stream 799 has an "a=sendonly" direction attribute in an multicast SDP message. 801 SRTP multicast operation requires that each host-sender have a 802 unique SRTP master key. This can be accomplished by ensuring that 803 each receiver be allocated a unique key or by ensuring that the SSRC 804 of each receiver is unique. Since SSRC collision might occur, the 805 latter condition is not possible unless all SSRCs are assigned by a 806 central authority such as a 3rd-party key server [srtp]. This is 807 for further study. The RECOMMENDED approach of this document is to 808 allocate a different master key for each host-participant of an SRTP 809 session. 811 6.2 Signaling Authentication and Signaling Encryption 813 There is no reason to incur the complexity and computational expense 814 of SRTP, however, when its key establishment is exposed to 815 unauthorized parties. In most cases, the SRTP attribute and its 816 parameters are vulnerable to denial of service attacks when they are 817 carried in an unauthenticated SDP message. In some cases, the 818 integrity or confidentiality of the RTP stream can be compromised. 819 For example, if an attacker set UNENCRYPTED for the SRTP stream in 820 an Offer, this could result in the Answerer not decrypting the 821 encrypted SRTP messages. In the worst case, the Answerer might 822 itself send unencrypted SRTP and leave its data exposed to snooping. 824 IPsec, TLS, S/MIME or some other data security service SHOULD be 825 used to provide message authentication for SDP messages that carry 826 the SRTP attribute. Message encryption SHOULD be used when a master 827 key parameter appears in the message. Failure to encrypt the SDP 828 message containing an inline SRTP master key renders the SRTP 829 authentication or encryption service useless in practically all 830 circumstances. Failure to authenticate an SDP message that carries 831 SRTP parameters renders the SRTP authentication or encryption 832 service useless in most practical applications. 834 When the SDP parameters cannot be carried in an encrypted and 835 authenticated SDP message, it is RECOMMENDED that a key management 836 protocol be used. The proposed SDP key-mgmt statement [keymgt] 837 allows authentication and encryption of the key management protocol 838 data independently of the SDP message that carries it. The security 839 of the SDP SRTP attribute, however, is as good as the data security 840 protocol that protects the SDP message. For example, if an IPsec 841 security association exists between the source endpoint, its 842 signaling controller, and the destination endpoints, then this 843 solution is more secure than use of the key-mgmt statement in an 844 unauthenticated SDP message, which is vulnerable to tampering. 846 There are practical cases, however, where SDP security is not end- 847 to-end: If there is a third-party provider between the sender and 848 receiver, then the data-security session might not be end-to-end. 849 That is, one possible configuration might have an IPsec or TLS 850 connection between the sender of the SDP message and the provider, 851 such as a VoIP service provider, with a second secure connection 852 between the provider and the receiver: 854 signaling controller---(network-b)---signaling controller 855 | | 856 (network a) (network c) 857 | | 858 sender----------------(SRTP bearer)--------------receiver 860 where all of link a, b, and c are encrypted with TLS or IPsec. 862 In this case, the third-party provider is provided the contents of 863 the SRTP attribute descriptions in the SDP message. SDP key-mgmt 864 statement, however, allows true end-to-end security that is 865 independent of the service provider, who often needs access to some 866 parts of the SDP message to render its services. The SRTP attribute 867 MUST NOT be used when end-to-end authentication or confidentiality 868 is needed but the SDP message is not secured end to end (such as the 869 above example where a third-party provider maintains the security 870 associations with the endpoints for the SDP message). 872 7.0 Grammar 874 This section provides an Augmented BNF grammar for the SRTP profile 875 of the SDP crypto-attribute. ABNF is defined in [RFC2234]. The 876 rule names and are from SDP [RFC2327]. 878 att-field = "crypto" 879 att-value = cipher application 881 application = cipher-both / cipher-srtp / cipher-srtcp 883 cipher-both = key-parameter *[SP sess-par-both] 884 cipher-srtp = key-parameter *[SP sess-par-srtp] 885 cipher-srtcp = key-parameter *[SP sess-par-srtcp] 887 key-parameter = method-inline / method-uri 889 cipher = "AES_CM_128_HMAC_SHA1_32" / 890 "F8_128_HMAC_SHA1_32" / 891 "AES_CM_128_HMAC_SHA1_80" 893 sess-par-both = roc / ; Roll-Over Counter 894 kdr / ; Key Derivation Rate 895 "UNENCRYPTED" 897 sess-par-srtp = ssrc / fec-order 899 sess-par-srtcp = "UNAUTHENTICATED" 900 method-inline = "inline:" key-info 901 method-uri = "uri:<" absoluteURI ">" ; absoluteURI defined in 902 ; [RFC2396] 904 key-info = "/" key-length "/" salt-length "/" key-salt 905 "/" [lifetime] "/" [mki] 907 key-length = 1*(DIGIT) ; length in bytes 908 salt-length = 1*(DIGIT) ; length in bytes 909 key = 1*(base64) 910 salt = 1*(base64) 911 key-salt = key salt ; key and salt concatenated and 912 ; then base64 encoded [section 913 ; 6.8 of RFC2045] 914 lifetime = ["2^"] 1*(DIGIT) 915 mki = "/" mki-length ":" mki-value 916 mki-length = 1*3(DIGIT) ; MUST be multiple of 8 and 917 ; MUST not exceed 128 918 mki-value = 1*(base64) 920 roc = "ROC:" 1*(DIGIT) 921 kdr = "KDR:" 1*(DIGIT) 923 ssrc = "SSRC:" ssrc-value 924 ssrc-value = 1*(DIGIT) *["," ssrc-value] 926 fec-order = "FEC:" 1*(DIGIT) 928 base64 = ALPHA / DIGIT / "+" / "/" / "=" 930 8.0 Acknowledgements 932 This document benefited from discussions with Flemming Andreasen, 933 David McGrew, Mats Naslund, Mike Thomas, Elisabetta Cararra, Brian 934 Weis, Dave Oran, Bill Foster, Earl Carter, Matt Hammer and Dave 935 Singer. These people shared observations, identified errors and 936 made suggestions for improving the specification. Mats made several 937 valuable suggestions on parameters and syntax that are in the 938 current draft. Dave Oran recommended the generic approach to the 939 SDP media-stream security descriptions that is followed in this 940 draft. Flemming Andreasen suggested some changes to an earlier 941 draft that greatly simplify this document. David McGrew suggested 942 the conservative approach of using unique master keys for each SDP 943 media stream as followed in this document. Jonathan Rosenberg 944 suggested reducing the complexity by specifying only one security 945 parameter for each media stream. 947 9.0 Authors' Addresses 949 Mark Baugher 950 5510 SW Orchid Street 951 Portland, Oregon 952 mbaugher@rdrop.com 953 +1-408-853-4418 955 Dan Wing 956 Cisco Systems, Inc. 957 170 West Tasman Drive 958 San Jose, CA 95134 USA 959 dwing@cisco.com 960 +1 408 525 5314 962 10.0 References 964 [Bellovin] Steven M. Bellovin, "Problem Areas for the IP Security 965 Protocols," in Proceedings of the Sixth Usenix Unix Security 966 Symposium, pp. 1-16, San Jose, CA, July 1996. 968 [keymgt] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman, 969 "Key Management Extensions for SDP and RTSP", June 2002, 970 http://search.ietf.org/internet-drafts/draft-ietf-mmusic-kmgmt-ext- 971 06.txt, Work in Progress 973 [mikey] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman, 974 "MIKEY: Multimedia Internet KEYing", July 2002, 975 http://search.ietf.org/internet-drafts/draft-ietf-msec-mikey-06.txt, 976 Work in Progress 978 [RFC1889] H. Schulzrinne, S. Casner, R. Fredrick, V. Jacobson, "RTP: 979 A Transport Protocol for Real-Time Applications", January 1996, 980 http://www.ietf.org/rfc/rfc1889.txt 982 [RFC2045] N. Freed, N. Borenstein, "Multipurpose Internet Mail 983 Extensions (MIME) Part One: Format of Internet Message Bodies", 984 November 1996, http://www.ietf.org/rfc/rfc2045.txt 986 [RFC2104] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing 987 for Message Authentication", November 1997, 988 http://www.ietf.org/rfc/rfc2104.txt 990 [RFC2234] D. Crocker, P. Overell, "Augmented BNF for Syntax 991 Specifications: ABNF", November 1997, 992 http://www.ietf.org/rfc/rfc2234.txt 994 [RFC2327] M. Handley, V. Jacobson, "SDP: Session Description 995 Protocol", April 1998, http://www.ietf.org/rfc/rfc2327.txt 997 [RFC2828] R. Shirey, "Internet Security Glossary", May 2000, 998 http://www.ietf.org/rfc/rfc2828.txt 1000 [RFC2396] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform 1001 Resource Identifiers (URI): Generic Syntax", August 1998, 1002 http://www.ietf.org/rfc/rfc2396.txt 1004 [RFC3264] "J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with 1005 the Session Description Protocol (SDP)", June 2202, 1006 http://www.ietf.org/rfc/rfc3264.txt 1008 [skeme] H. Krawczyk, "SKEME: A Versatile Secure Key Exchange 1009 Mechanism for the Internet", ISOC Secure Networks and Distributed 1010 Systems Symposium, San Diego, 1996. 1012 [srtp] M. Baugher, R. Blom, E. Carrara, D. McGrew, M. Naslund, K. 1013 Norrman, D. Oran, "The Secure Real-time Transport Protocol", June 1014 2002, http://search.ietf.org/internet-drafts/draft-ietf-avt-srtp- 1015 05.txt, Work in Progress 1017 11.0 Full Copyright Statement 1019 "Copyright (C) The Internet Society 2003. All Rights Reserved. 1021 This document and translations of it may be copied and furnished to 1022 others, and derivative works that comment on or otherwise explain it 1023 or assist in its implementation may be prepared, copied, published 1024 and distributed, in whole or in part, without restriction of any 1025 kind, provided that the above copyright notice and this paragraph 1026 are included on all such copies and derivative works. However, this 1027 document itself may not be modified in any way, such as by removing 1028 the copyright notice or references to the Internet Society or other 1029 Internet organizations, except as needed for the purpose of 1030 developing Internet standards in which case the procedures for 1031 copyrights defined in the Internet Standards process must be 1032 followed, or as required to translate it into languages other than 1033 English. 1035 The limited permissions granted above are perpetual and will not be 1036 revoked by the Internet Society or its successors or assigns. 1038 This document and the information contained herein is provided on an 1039 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1040 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1041 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1042 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1043 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.