idnits 2.17.1 draft-fries-msec-mikey-applicability-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 835. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 812. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 819. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 825. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 26, 2006) is 6633 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: 'RAND' is mentioned on line 188, but not defined == Missing Reference: 'HAC' is mentioned on line 188, but not defined == Missing Reference: 'IDi' is mentioned on line 348, but not defined == Missing Reference: 'IDr' is mentioned on line 539, but not defined == Missing Reference: 'CHASH' is mentioned on line 537, but not defined == Missing Reference: 'CRED' is mentioned on line 392, but not defined == Missing Reference: 'CREDi' is mentioned on line 401, but not defined == Missing Reference: 'CREDr' is mentioned on line 404, but not defined == Missing Reference: 'SP' is mentioned on line 447, but not defined == Unused Reference: 'I-D.ietf-msec-mikey-rsa-r' is defined on line 711, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 725, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-ietf-msec-mikey-ecc-00 == Outdated reference: A later version (-07) exists of draft-ietf-msec-mikey-rsa-r-02 == Outdated reference: A later version (-05) exists of draft-ietf-msec-newtype-keyid-03 ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 1305 (Obsoleted by RFC 5905) -- Obsolete informational reference (is this intentional?): RFC 2327 (Obsoleted by RFC 4566) -- Obsolete informational reference (is this intentional?): RFC 3525 (Obsoleted by RFC 5125) Summary: 4 errors (**), 0 flaws (~~), 17 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MSEC S. Fries 3 Internet-Draft Siemens 4 Expires: August 30, 2006 D. Ignjatic 5 Polycom 6 February 26, 2006 8 On the applicability of various MIKEY modes and extensions 9 draft-fries-msec-mikey-applicability-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 30, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 Multimedia Internet Keying - MIKEY - is a key management scheme that 43 can be used for real-time applications. In particular, it has been 44 defined focusing on the support of the Secure Real-time Transport 45 Protocol. MIKEY itself defines four key distribution schemes. 46 Moreover, it is defined to allow extensions of the protocol. As 47 MIKEY becomes more and more accepted, extensions to the base protocol 48 arose, especially in terms of additional key distribution schemes, 49 but also in terms of payload enhancements. 51 This document provides an overview about MIKEY in general as well as 52 the existing extensions in MIKEY, which have been defined or are in 53 the process of definition. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 4 59 3. MIKEY Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3.1. Symmetric key distribution . . . . . . . . . . . . . . . . 6 61 3.2. Asymmetric key distribution . . . . . . . . . . . . . . . 6 62 3.3. Diffie-Hellman key agreement protected with digital 63 signatures . . . . . . . . . . . . . . . . . . . . . . . . 7 64 3.4. Unprotected key distribution . . . . . . . . . . . . . . . 7 65 4. MIKEY Extensions . . . . . . . . . . . . . . . . . . . . . . . 8 66 4.1. Diffie-Hellman key agreement protected with pre-shared 67 secrets . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 4.2. SAML assisted DH-key agreement . . . . . . . . . . . . . . 9 69 4.3. Asymmetric key distribution with in-band certificate 70 exchange . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 4.4. ECC algorithms support . . . . . . . . . . . . . . . . . . 11 72 4.4.1. Elliptic Curve Integrated Encryption Scheme 73 application in MIKEY . . . . . . . . . . . . . . . . . 12 74 4.4.2. Elliptic Curve Menezes-Qu-Vanstone Scheme 75 application in MIKEY . . . . . . . . . . . . . . . . . 12 76 4.5. New Payload for bootstrapping TESLA . . . . . . . . . . . 12 77 4.6. New Key ID information type . . . . . . . . . . . . . . . 13 78 5. Selection and interworking of MIKEY modes . . . . . . . . . . 13 79 6. Transport of MIKEY messages . . . . . . . . . . . . . . . . . 14 80 7. Summary of MIKEY related IANA Registrations . . . . . . . . . 15 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 83 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 85 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 86 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 88 Intellectual Property and Copyright Statements . . . . . . . . . . 20 90 1. Introduction 92 Key distribution describes the process of delivering cryptographic 93 keys to the required parties. MIKEY [RFC3830], the Multimedia 94 Internet Keying, has been defined focusing on support for the 95 establishment of security context for the Secure Real-time Transport 96 Protocol [RFC3711]. Note that MIKEY is not restricted to be used for 97 SRTP only, as it features a generic approach and allows for 98 extensions to the key distribution schemes, but also for the payload 99 associated with the protocol using the distributed security context. 101 MIKEY defines four key distribution schemes as there are: 103 o Symmetric key distribution 104 o Asymmetric key distribution 105 o Diffie-Hellman key agreement protected by digital signatures 106 o Unprotected key distribution 108 There have been scenarios where none of the above schemes fits 109 perfectly, so extensions have been defined. These extensions 110 comprise new key distribution schemes, algorithm enhancements, new 111 payload definitions supporting other protocols than SRTP. The key 112 distribution scheme extensions are defined in the following 113 documents: 115 o Diffie-Hellman key agreement protected by symmetric pre-shared 116 keys as defined in [I-D.ietf-msec-mikey-dhhmac] 117 o SAML assisted Diffie-Hellman key agreement as defined [Reference 118 to draft-moskowitz-MIKEY-SAML-DH] 119 o Asymmetric key distribution (based on asymmetric encryption) with 120 in-band certificate provision as defined in [I-D.ietf-msec-mikey- 121 rsa-r] 123 Algorithm extensions are defined in the following document: 125 o ECC algorithms for MIKEY as defined in [I-D.ietf-msec-mikey-ecc] 127 Payload extensions are defined in the following documents: 129 o Bootstrapping TESLA, defining a new payload for the Timed 130 Efficient Stream Loss-tolerant Authentication protocol [RFC4082] 131 as defined in [I-D.ietf-msec-bootstrapping-tesla] 132 o The Key ID information type for the general extension payload as 133 defined in [I-D.ietf-msec-newtype-keyid] 135 This document provides an overview about MIKEY and the relations to 136 the different extensions to provide a framework when using MIKEY. It 137 is intended as additional source of information for developers or 138 architects to provide more insight in use case scenarios and 139 motivations as well as advantages and disadvantages for the different 140 key distribution schemes. This document may be enhanced as soon as 141 new extensions to MIKEY appear. It has been seen that enhancing the 142 overview document requires much less effort than enhancing an 143 established standard. 145 2. Terminology and Definitions 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in RFC 2119 [RFC2119]. 151 The following definitions have mostly been taken from [RFC3830]: 153 (Data) Security Protocol: the security protocol used to protect the 154 actual data traffic. Examples of security protocols are IPsec and 155 SRTP. 157 Data Security Association (Data SA): information for the security 158 protocol, including a TEK and a set of parameters/policies. 160 Crypto Session (CS): uni- or bi-directional data stream(s), protected 161 by a single instance of a security protocol. 163 Crypto Session Bundle (CSB): collection of one or more Crypto 164 Sessions, which can have common TGKs (see below) and security 165 parameters. 167 Crypto Session ID: unique identifier for the CS within a CSB. 169 Crypto Session Bundle ID (CSB ID): unique identifier for the CSB. 171 TEK Generation Key (TGK): a bit-string agreed upon by two or more 172 parties, associated with CSB. From the TGK, Traffic-encrypting Keys 173 can then be generated without needing further communication. 175 Traffic-Encrypting Key (TEK): the key used by the security protocol 176 to protect the CS (this key may be used directly by the security 177 protocol or may be used to derive further keys depending on the 178 security protocol). The TEKs are derived from the CSB's TGK. 180 TGK re-keying: the process of re-negotiating/updating the TGK (and 181 consequently future TEK(s)). 183 Initiator: the initiator of the key management protocol, not 184 necessarily the initiator of the communication. 186 Responder: the responder in the key management protocol. 188 Salting key: a random or pseudo-random (see [RAND, HAC]) string used 189 to protect against some off-line pre-computation attacks on the 190 underlying security protocol. 192 HDR: denotes the protocol header 194 PRF(k,x): a keyed pseudo-random function 196 E(k,m): encryption of m with the key k 198 RAND: Random value 200 T: Timestamp 202 CERTx: the certificate of x 204 SIGNx: the signature from x using the private key of x 206 PKx: the public key of x 208 IDx: the identity of x 210 [] an optional piece of information 212 {} denotes zero or more occurrences 214 || concatenation 216 | OR (selection operator) 218 ^ exponentiation 220 XOR exclusive or 222 3. MIKEY Overview 224 This section will provide an overview about the MIKEY base document. 225 The focus lies here on the key distribution schemes as well as the 226 discussion about advantages and disadvantages of the different 227 schemes. Note that the MIKEY key distribution schemes rely on 228 loosely synchronized clocks. Thus should be realized by a secure 229 network clock synchronization protocol. MIKEY recommends for this 230 the ISO time synchronization protocol [ISO_sec_time]. The format 231 applied to the timestamps submitted in the MIKEY have to match the 232 NTP format described in [RFC1305]. In other cases, such as of a SIP 233 endpoint clock synchronization by deriving time from a trusted 234 outbound proxy may be appropriate. 236 3.1. Symmetric key distribution 238 This option of the key management uses a pre-shared secret key to 239 derive key material for integrity protection and encryption to 240 protect the actual exchange of key material. The response message is 241 optional and may be used for mutual authentication. 243 Initiator Responder 245 I_MESSAGE = 246 HDR, T, RAND, [IDi],[IDr], 247 {SP}, KEMAC ---> 248 R_MESSAGE = 249 [<---] HDR, T, [IDr], V 251 The advantages of this approach lay in the fact that there is no 252 dependency on a PKI (Public Key Infrastructure), the solution 253 consumes low bandwidth and enables high performance, and is all in 254 all a simple straightforward master key provisioning. The 255 disadvantages are that no perfect forward secrecy is provided and key 256 generation is just performed by the initiator. Furthermore, the 257 approach is not scaleable to larger configurations but acceptable in 258 small-sized groups. Note, according to [RFC3830] this option is 259 mandatory to implement. 261 3.2. Asymmetric key distribution 263 Using the asymmetric option of the key management, the initiator 264 generates the key material to be transmitted and sends it encrypted 265 with the responder's public key. Additionally a so-called envelope 266 key is transmitted, encrypted with the receiver's public key. The 267 envelope key env-key is used to derive the auth-key and the enc-key. 268 Moreover, the envelope key may be used as a pre-shared key to 269 establish further crypto sessions. The response message is optional 270 and may be used for mutual authentication. 272 Initiator Responder 274 I_MESSAGE = 275 HDR, T, RAND, [IDi|CERTi], [IDr], {SP}, 276 KEMAC, [CHASH], PKE, SIGNi ---> 277 R_MESSAGE = 278 [<---] HDR, T, [IDr], V 280 An advantage of this approach are that the usage of self-signed 281 certificates can avoid PKI. Note that using self-signed certificates 282 may result in limited scalability and complex provisioning. The 283 disadvantages comprise the necessity of a PKI for fully scalability, 284 the performance of the key generation just by the initiator, and no 285 provision of perfect forward secrecy. Furthermore, the verification 286 of certificates may not be done in real-time. This could be the case 287 in scenarios where the revocation status of certificates is checked 288 through a further component. Note, according to [RFC3830] this 289 option is mandatory to implement. 291 3.3. Diffie-Hellman key agreement protected with digital signatures 293 The Diffie-Hellman option of the key management enables a shared 294 secret establishment between initiator and responder in a way where 295 both parties contribute to the shared secret. The Diffie-Hellman key 296 agreement is authenticated (and integrity protected) using digital 297 signatures. 299 Initiator Responder 301 I_MESSAGE = 302 HDR, T, RAND, [IDi|CERTi],[IDr] 303 {SP}, DHi, SIGNi ---> 304 R_MESSAGE = 305 <--- HDR, T, [IDr|CERTr], 306 IDi, DHr, DHi, SIGNr 308 [RFC3830] does not mandate any specific asymmetric algorithm for the 309 signature calculation. The algorithm used for signature or public 310 key encryption is rather defined by, and dependent on the certificate 311 used. Besides the use of X.509v3 certificates it is mandatory to 312 support the Diffie-Hellmann group "OAKLEY5" [RFC2412]. The 313 advantages of this approach are a fair, mutual key agreement, perfect 314 forward secrecy, and the option to use self-signed certificates to 315 avoid PKI (would result in limited scalability and more complex 316 provisioning). Negatively to remark is that this approach just 317 scales to point-to-point groups and depends on PKI for full 318 scalability. Moreover, it has a limited performance since expensive, 319 non-real time certificate validation has to be done. 321 3.4. Unprotected key distribution 323 MIKEY also supports a mode to provide a key in an unprotected manner. 324 This is based on the pre-shared key option depicted in Section 3.1 325 and may be compared with the plain approach in sdescriptions 326 [I-D.ietf-mmusic-sdescriptions]. Here, MIKEY completely relies on 327 the underlying security and may be used with the NULL encryption and 328 the NULL authentication algorithm. This option should be used with 329 caution as it does not protect the key management. 331 4. MIKEY Extensions 333 This section will provide an overview about the MIKEY extensions for 334 key distribution schemes, crypto algorithms and payloads which have 335 been defined in several documents. 337 4.1. Diffie-Hellman key agreement protected with pre-shared secrets 339 This is an additional option which has been defined in [I-D.ietf- 340 msec-mikey-dhhmac]. In contrast to the method described in 341 Section 3.3 here the Diffie-Hellmann key agreement is authenticated 342 (and integrity protected) using a pre-shared secret and keyed hash 343 function. 345 Initiator Responder 347 I_MESSAGE = 348 3D HDR, T, RAND, [IDi], IDr, 349 {SP}, DHi, KEMAC ---> 350 R_MESSAGE = 351 <--- 3D HDR, T,[IDr], IDi, 352 DHr, DHi, KEMAC 354 TGK =3D g^(xi * yi) TGK =3D g^(xi * yi) 356 For the integrity protection of the Diffie-Hellman key agreement 357 [I-D.ietf-msec-mikey-dhhmac] mandates the use of HMAC SHA-1. 358 Regarding Diffie-Hellman groups [RFC3830] is referenced. Thus, it is 359 mandatory to support the Diffie-Hellman group "OAKLEY5" [RFC2412]. 360 This option has also several advantages, as there are the fair mutual 361 key agreement, the perfect forward secrecy, and no dependency on a 362 PKI and PKI standards. Moreover, this scheme has a sound performance 363 and reduced bandwidth requirements and provides a simple and 364 straightforward master key provisioning. The scalability of this 365 approach just to point-to-point groups is a disadvantage. 367 This mode of operation provides an efficient scheme in deployments 368 where there is a central trusted server that is provisioned with 369 shared secrets for many clients. Such setups could for example be 370 enterprise PBXs, service provider proxies, etc. 372 4.2. SAML assisted DH-key agreement 374 This document [Reference to draft-moskowitz-MIKEY-SAML-DH] is 375 targeted to fulfill the general requirements on key management 376 approaches repeated here: 378 1. Mutual authentication of involved parties 379 2. Both parties involved contribute to the session key generation 380 3. Provide perfect forward secrecy 381 4. Support distribution of group session keys 382 5. Provide liveliness tests when involved parties do not have a 383 reliable clock 384 6. Support of limited parties involved 386 To fullfill all of the requirements, the document proposes the use of 387 a classic Diffie-Hellman key agreement protocol for key establishment 388 in conjunction with UA's SIP server signed element authenticating the 389 Diffie-Hellman key and the ID using the SAML (Security Association 390 Markup Language, [SAML_overview]) approach. Here the client's public 391 Diffie-Hellman-credentials are signed by the server to form a SAML 392 assertion [CRED], which may be used for later sessions with other 393 clients. This assertion needs at least to convey the ID, public DH 394 key, Expiry, and the signature from the server. This provides the 395 involved clients with mutual authentication and message integrity of 396 the key management messages exchanged. 398 Initiator Responder 400 I_MESSAGE = 401 HDR, T, RAND1, [CREDi], 402 IDr, {SP} ---> 403 R_MESSAGE = 404 <--- HDR, T, [CREDr], IDi, DHr, 405 RAND2, (SP) 406 TGK = HMACx(RAND1|RAND2), where x = g^(xi * xr). 408 Additionally the document proposes a second roundtrip to avoid the 409 dependence on synchronized clocks and provide liveliness checks. 410 This is achieved by exchanging nonces, protected with the session 411 key. This second roundtrip can also be used for distribution of 412 group keys or for the leverage of a weak DH key for a stronger 413 session key. The trigger for the second round trip would be handled 414 via SP, the Security Policy communicated via MIKEY. 416 Initiator Responder 418 I_MESSAGE = 419 HDR, SIGN(ENC(RAND3)) ---> 420 R_MESSAGE = 421 <--- SIGN(ENC(RAND4)) 423 Note if group keys are to be provided RAND would be substituted by 424 that group key. 426 With the second roundtrip, this approach also provides an option for 427 all of the other key distribution methods, when liveliness checks are 428 needed. The drawback of the second roundtrip is that these messages 429 need to be integrated into the call flow of the signaling protocol. 430 In straight forward call one roundtrip may be enough to setup a 431 session. Thus this second roundtrip would require additional 432 messages to be exchanged. 434 4.3. Asymmetric key distribution with in-band certificate exchange 436 This is an additional option which has been defined in [I-D.ietf- 437 msec-mikey-rsa-r]. It describes the asymmetric key distribution with 438 optional in-band certificate exchange. 440 Initiator Responder 442 I_MESSAGE = 443 HDR, T, [IDi|CERTi], [IDr], 444 {SP}, SIGNi ---> 445 R_MESSAGE = 446 <--- HDR, [GenExt(CSB-ID)], T, 447 RAND, [IDr|CERTr], [SP], 448 KEMAC, PKE, SIGNr 450 This option has some advantages compared to the asymmetric key 451 distribution stated in Section 3.2. Here, the sender and receiver do 452 not need to know the certificate of the other peer in advance as it 453 may be sent in the MIKEY initiator message. Thus, the receiver of 454 this message can utilize the received key material to encrypt the 455 session parameter and send them back as part of the MIKEY response 456 message. The certificate check may be done depending on the signing 457 authority. If the certificate is signed by an publicly accepted 458 authority the certificate validation is done on the common base. In 459 the other case additional steps may be necessary. The disadvantage 460 is that no perfect forward secrecy is provided. 462 This mode is meant to provide a low cost solution when PKI is present 463 and/or required. Specifically in SIP, session invitations can be 464 retargeted or forked. MIKEY modes that require the Initiator to 465 target a single well known Responder may be impractical here as they 466 may require multiple roundtrips to do key negotiation. By allowing 467 the Responder to generate secret material used for key derivation 468 this mode allows for an efficient key delivery scheme. Note that the 469 Initiator can contribute to the material the key is derived from 470 through CSB-ID and RAND payloads in unicast use cases. This mode is 471 also useful in multicast scenarios where multiple clients are 472 contacting a known server and are downloading the key. Server 473 workload is significantly reduced in these scenarios compared to 474 MIKEY in public key mode. Examples of deployments where this mode 475 can be used are enterprises with PKI, service provider setups where 476 the service provider decides to provision certificates to its users, 477 etc. 479 4.4. ECC algorithms support 481 [I-D.ietf-msec-mikey-ecc] proposes extensions to the authentication, 482 encryption and digital signature methods described for use in MIKEY, 483 employing elliptic-curve cryptography (ECC). These extensions are 484 defined to align MIKEY with other ECC implementations and standards. 486 The motivation for supporting ECC within the MIKEY stems from the 487 following advantages: 489 o ECC support is generally added to security protocols 490 o ECC support requires considerably smaller keys by keeping the same 491 security level compared to other asymmetric techniques (like RSA). 492 Elliptic curve algorithms are capable of providing security 493 consistent with AES keys of 128, 192, and 256 bits without 494 extensive growth in asymmetric key sizes. 495 o As stated in [I-D.ietf-msec-mikey-ecc] implementations have shown 496 that elliptic curve algorithms can significantly improve 497 performance and security-per-bit over other recommended 498 algorithms. 500 These advantages make the usage of ECC especially interesting for 501 embedded devices, which may have only limited performance and storage 502 capabilities. 504 [I-D.ietf-msec-mikey-ecc] proposes several ECC based mechanisms to 505 enhance the MIKEY key distribution schemes, as there are: 507 o Use of ECC methods with public-key encryption (MIKEY-RSA); ECDSA 508 o Use of Elliptic Curve Integrated Encryption Scheme (MIKEY-ECIES) 509 o Use of ECC methods with Diffie-Hellman key exchange (MIKEY-DHSIGN) 510 o Use of Elliptic Curve Menezes-Qu-Vanstone (MIKEY-MQV) 512 The following subsections will provide more detailed information 513 about the message exchanges for MIKEY-ECIES and MIKEY-MQV. 515 4.4.1. Elliptic Curve Integrated Encryption Scheme application in MIKEY 517 The following figure shows the message exchange for the MIKEY-ECIES 518 scheme: 520 Initiator Responder 522 I_MESSAGE = 523 HDR, T, RAND, [IDi|CERTi], [IDr], {SP}, 524 ECCPT, KEMAC, [CHASH], SIGNi ---> 525 R_MESSAGE = 526 [<---] HDR, T, [IDr], V 528 4.4.2. Elliptic Curve Menezes-Qu-Vanstone Scheme application in MIKEY 530 The following figure shows the message exchange for the MIKEY-MQV 531 scheme: 533 Initiator Responder 535 I_MESSAGE = 536 HDR, T, RAND, [IDi|CERTi], [IDr], {SP}, 537 ECCPT, KEMAC, [CHASH], SIGNi ---> 538 R_MESSAGE = 539 [<---] HDR, T, [IDr], V 541 4.5. New Payload for bootstrapping TESLA 543 TESLA [RFC4082] is a protocol for providing source authentication in 544 multicast scenarios. TESLA is an efficient protocol with low 545 communication and computation overhead, which scales to large numbers 546 of receivers, and also tolerates packet loss. TESLA is based on 547 loose time synchronization between the sender and the receivers. 548 Source authentication is realized in TESLA by using Message 549 Authentication Code (MAC) chaining. The use of TESLA within the 550 Secure Real-time Transport Protocol (SRTP) has been published in 551 [RFC4383] targeting multicast authentication in scenarios, where SRTP 552 is applied to protect the multimedia data. This solution assumes 553 that TESLA parameters are made available by out-of-band mechanisms. 555 [I-D.ietf-msec-bootstrapping-tesla] specifies payloads for MIKEY to 556 bootstrap TESLA for source authentication of secure group 557 communications using SRTP. TESLA may be bootstrapped using one of 558 the MIKEY key management approaches described above sent via unicast, 559 multicast or broadcast. This approach provides the necessary 560 parameter payload extensions for the usage of TESLA in SRTP but is 561 not limited to this. 563 4.6. New Key ID information type 565 This extension specifies a new Type (the Key ID Information Type) for 566 the General Extension Payload. This is used in, e.g., the Multimedia 567 Broadcast/Multicast Service (MBMS) specified in the 3rd Generation 568 Partnership Project (3GPP). MBMS requires the use of MIKEY to convey 569 the keys and related security parameters needed to secure the 570 multimedia that is multicast or broadcast. 572 One of the requirements that MBMS puts on security is the possibility 573 to perform frequent updates of the keys. The rationale behind this 574 is that it should be inconvenient for subscribers to publish the 575 decryption keys enabling non-subscribers to view the content. To 576 implement this, MBMS uses a three level key management, to distribute 577 group keys to the clients, and be able to re-key by pushing down a 578 new group key. MBMS has the need to identify, which types of key are 579 involved in the MIKEY message, and their identity. 581 [I-D.ietf-msec-newtype-keyid] specifies a new Type for the General 582 Extension Payload in MIKEY, to identify the type and identity of 583 involved keys. 585 5. Selection and interworking of MIKEY modes 587 While MIKEY and its extensions provide plenty of choice in terms of 588 modes of operation an implementation may choose to simplify its 589 behavior. This can be achieved by operating in a single mode of 590 operation when in Initiator's role. Where PKI is available and/or 591 required an implementation may choose for example to start all 592 sessions in RSA-R mode but it would be trivial for it to act as a 593 Responder in public key mode. If envelope keys are cached it can 594 then also choose to do re-keying in shared key mode. In general, 595 modes of operation where the Initiator generates keying material are 596 useful when two peers are aware of each other before the MIKEY 597 communication takes place. If an implementation chooses not to 598 operate in shared key mode its behavior may be identical to a peer 599 that does but lacks the shared key. Similarly, if a peer chooses not 600 to operate in the public key mode it may reject the certificate of 601 the Initiator. The same applies to peers that choose to operate in 602 one of the DH modes exclusively. 604 Choosing between the different modes of MIKEY depends strongly on the 605 use case. This document may discuss further scenarios to argue for 606 preferred modes. The following call scenarios provide a list of 607 potential call scenarios and are matter of discussion: 609 o Call Transfer 610 o Forking 612 Forward MIKEY modes like public key or shared key mode when used in 613 SIP/SDP may lead to complications in some calls scenarios, for 614 example forking scenarios key derivation material gets distributed to 615 multiple parties. As mentioned earlier this may be impractical as 616 some of the destinations may not have the resources to validate the 617 message and may cause the initiator to drop the session invitation. 618 Even in the case all parties involved have all the prerequisites for 619 interpreting the MIKEY message received there is a possible problem 620 with multiple responders starting media sessions using the same key. 621 While the SSRCs will be different in most of the cases they are only 622 sixteen bits long and there is a high probability of a two time pad 623 problem. As suggested earlier forward modes are most useful when the 624 two peers are aware of each other before the communication takes 625 place (as is the case in key renewal scenarios when costly public key 626 operations can be avoided by using the envelope key). 628 6. Transport of MIKEY messages 630 MIKEY defines message formats to transport key information and 631 security policies between communicating entities. It does not define 632 the embedding of these messages into the used signaling protocol. 633 This definition is provided in separate documents, depending on the 634 used signaling protocol. 636 Several IETF defined protocols utilize the Session Description 637 Protocol (SDP, [RFC2327]) to transport the session parameters. 638 Examples are the Session Initiation Protocol (SIP, [RFC3261] or the 639 Gateway Control Protocol (GCP, [RFC3525]). The transport of MIKEY 640 messages as part of SDP is described in [I-D.ietf-mmusic-kmgmt-ext]. 641 Here, the complete MIKEY message is base64 encoded and transmitted as 642 part of the SDP part of the signaling protocol message. Note, as 643 several key distribution messages may be transported within one SDP 644 container, [I-D.ietf-mmusic-kmgmt-ext] also comprises an integrity 645 protection regarding all supplied key distribution attempts. Thus, 646 bidding down attacks will be recognized. 648 MIKEY is also applied in ITU-T protocols like H.323, which is used to 649 establish communication sessions similar to SIP. For H.323 a 650 security framework exists, which is defined in H.235. Within this 651 framework H.235.7 [H.235.7] describes the usage of MIKEY and SRTP in 652 the context of H.323. In contrast to SIP H.323 uses ASN.1 (Abstract 653 Syntax Notation). Thus there is no need to encode the MIKEY 654 container as base64. Within H.323 the MIKEY container is binary 655 encoded. 657 7. Summary of MIKEY related IANA Registrations 659 For MIKEY and the extensions to MIKEY IANA registrations have been 660 made. Here only a link to the appropriate IANA registration is 661 provided to avoid inconsistencies. The IANA registrations for MIKEY 662 payloads can be found under 663 http://www.iana.org/assignments/mikey-payloads These registrations 664 comprise the MIKEY base registrations as well as registrations made 665 by MIKEY extensions regarding the payload. 667 The IANA registrations for MIKEY port numbers can be found under 668 http://www.iana.org/assignments/port-numbers (search for MIKEY). 670 8. Security Considerations 672 This document does not define extensions to existing protocols. It 673 rather provides an overview about the set of MIKEY and available 674 extensions. Thus, the reader is referred to the original documents 675 defining the base protocol and the extensions for the security 676 considerations. 678 9. IANA Considerations 680 This document does not require any IANA registration. 682 10. Acknowledgments 684 The authors would like to thank Lakshminath Dondeti for his document 685 reviews and for his guidance. 687 11. References 688 11.1. Normative References 690 [I-D.ietf-mmusic-kmgmt-ext] 691 Arkko, J., "Key Management Extensions for Session 692 Description Protocol (SDP) and Real Time Streaming 693 Protocol (RTSP)", draft-ietf-mmusic-kmgmt-ext-15 (work in 694 progress), June 2005. 696 [I-D.ietf-msec-bootstrapping-tesla] 697 Fries, S. and H. Tschofenig, "Bootstrapping TESLA", 698 draft-ietf-msec-bootstrapping-tesla-03 (work in progress), 699 January 2006. 701 [I-D.ietf-msec-mikey-dhhmac] 702 Euchner, M., "HMAC-authenticated Diffie-Hellman for 703 MIKEY", draft-ietf-msec-mikey-dhhmac-11 (work in 704 progress), April 2005. 706 [I-D.ietf-msec-mikey-ecc] 707 Milne, A., "ECC Algorithms For MIKEY", 708 draft-ietf-msec-mikey-ecc-00 (work in progress), 709 February 2006. 711 [I-D.ietf-msec-mikey-rsa-r] 712 Ignjatic, D., "An additional mode of key distribution in 713 MIKEY: MIKEY-RSA-R", draft-ietf-msec-mikey-rsa-r-02 (work 714 in progress), February 2006. 716 [I-D.ietf-msec-newtype-keyid] 717 Carrara, E., "The Key ID Information Type for the General 718 Extension Payload in MIKEY", 719 draft-ietf-msec-newtype-keyid-03 (work in progress), 720 December 2005. 722 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 723 Requirement Levels", BCP 14, RFC 2119, March 1997. 725 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 726 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 727 October 1998. 729 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 730 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 731 August 2004. 733 11.2. Informative References 735 [H.235.7] ""ITU-T Recommendation H.235.7: Usage of the MIKEY Key 736 Management Protocol for the Secure Real Time Transport 737 Protocol (SRTP) within H.235"", 2005. 739 [I-D.ietf-mmusic-sdescriptions] 740 Andreasen, F., "Session Description Protocol Security 741 Descriptions for Media Streams", 742 draft-ietf-mmusic-sdescriptions-12 (work in progress), 743 September 2005. 745 [ISO_sec_time] 746 ""ISO/IEC 18014 Information technology - Security 747 techniques - Time-stamping services, Part 1-3."", 2002. 749 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 750 Specification, Implementation", RFC 1305, March 1992. 752 [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description 753 Protocol", RFC 2327, April 1998. 755 [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", 756 RFC 2412, November 1998. 758 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 759 A., Peterson, J., Sparks, R., Handley, M., and E. 760 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 761 June 2002. 763 [RFC3525] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, 764 "Gateway Control Protocol Version 1", RFC 3525, June 2003. 766 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 767 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 768 RFC 3711, March 2004. 770 [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. 771 Briscoe, "Timed Efficient Stream Loss-Tolerant 772 Authentication (TESLA): Multicast Source Authentication 773 Transform Introduction", RFC 4082, June 2005. 775 [RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient 776 Stream Loss-Tolerant Authentication (TESLA) in the Secure 777 Real-time Transport Protocol (SRTP)", RFC 4383, 778 February 2006. 780 [SAML_overview] 781 Huges, J. and E. Maler, ""Security Assertion Markup 782 Language (SAML) 2.0 Technical Overview, Working Draft"", 783 2005. 785 Authors' Addresses 787 Steffen Fries 788 Siemens 789 Otto-Hahn-Ring 6 790 Munich, Bavaria 81739 791 Germany 793 Email: steffen.fries@siemens.com 795 Dragan Ignjatic 796 Polycom 797 1000 W. 14th Street 798 North Vancouver, BC V7P 3P3 799 Canada 801 Email: dignjatic@polycom.com 803 Intellectual Property Statement 805 The IETF takes no position regarding the validity or scope of any 806 Intellectual Property Rights or other rights that might be claimed to 807 pertain to the implementation or use of the technology described in 808 this document or the extent to which any license under such rights 809 might or might not be available; nor does it represent that it has 810 made any independent effort to identify any such rights. Information 811 on the procedures with respect to rights in RFC documents can be 812 found in BCP 78 and BCP 79. 814 Copies of IPR disclosures made to the IETF Secretariat and any 815 assurances of licenses to be made available, or the result of an 816 attempt made to obtain a general license or permission for the use of 817 such proprietary rights by implementers or users of this 818 specification can be obtained from the IETF on-line IPR repository at 819 http://www.ietf.org/ipr. 821 The IETF invites any interested party to bring to its attention any 822 copyrights, patents or patent applications, or other proprietary 823 rights that may cover technology that may be required to implement 824 this standard. Please address the information to the IETF at 825 ietf-ipr@ietf.org. 827 Disclaimer of Validity 829 This document and the information contained herein are provided on an 830 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 831 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 832 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 833 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 834 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 835 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 837 Copyright Statement 839 Copyright (C) The Internet Society (2006). This document is subject 840 to the rights, licenses and restrictions contained in BCP 78, and 841 except as set forth therein, the authors retain all their rights. 843 Acknowledgment 845 Funding for the RFC Editor function is currently provided by the 846 Internet Society.