idnits 2.17.1 draft-ietf-msec-mikey-applicability-09.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, updated by RFC 4748 on line 1431. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1442. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1449. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1455. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 17 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 224 has weird spacing: '...-keying the p...' == Line 232 has weird spacing: '...ing key a r...' == 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 (March 31, 2008) is 5842 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RAND' is mentioned on line 668, but not defined == Missing Reference: 'HAC' is mentioned on line 232, but not defined == Missing Reference: 'IDi' is mentioned on line 529, but not defined == Missing Reference: 'IDr' is mentioned on line 786, but not defined == Missing Reference: 'CHASH' is mentioned on line 770, but not defined == Missing Reference: 'CREDi' is mentioned on line 596, but not defined == Missing Reference: 'CREDr' is mentioned on line 599, but not defined == Missing Reference: 'SP' is mentioned on line 671, but not defined == Outdated reference: A later version (-07) exists of draft-ietf-avt-dtls-srtp-02 == Outdated reference: A later version (-09) exists of draft-ietf-sip-media-security-requirements-04 == Outdated reference: A later version (-06) exists of draft-mcgrew-srtp-ekt-03 == Outdated reference: A later version (-22) exists of draft-zimmermann-avt-zrtp-06 -- Obsolete informational reference (is this intentional?): RFC 1305 (Obsoleted by RFC 5905) -- Obsolete informational reference (is this intentional?): RFC 3525 (Obsoleted by RFC 5125) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 4909 (Obsoleted by RFC 5410, RFC 6309) Summary: 2 errors (**), 0 flaws (~~), 16 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MSEC S. Fries 3 Internet-Draft Siemens 4 Intended status: Informational D. Ignjatic 5 Expires: October 2, 2008 Polycom 6 March 31, 2008 8 On the applicability of various MIKEY modes and extensions 9 draft-ietf-msec-mikey-applicability-09.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 October 2, 2008. 36 Abstract 38 Multimedia Internet Keying - MIKEY - is a key management protocol 39 that can be used for real-time applications. In particular, it has 40 been defined focusing on the support of the Secure Real-time 41 Transport Protocol. MIKEY itself is standardized within RFC3830 and 42 defines four key distribution methods. Moreover, it is defined to 43 allow extensions of the protocol. As MIKEY becomes more and more 44 accepted, extensions to the base protocol arose, especially in terms 45 of additional key distribution methods, but also in terms of payload 46 enhancements. 48 This document provides an overview about the MIKEY base document in 49 general as well as the existing extensions for MIKEY, which have been 50 defined or are in the process of definition. It is intended as 51 additional source of information for developers or architects to 52 provide more insight in use case scenarios and motivations as well as 53 advantages and disadvantages for the different key distribution 54 schemes. The use cases discussed in this document are strongly 55 related to dedicated SIP call scenarios providing challenges for key 56 management in general among them media before SDP answer, forking, 57 and shared key conferencing. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 6 63 3. MIKEY Overview . . . . . . . . . . . . . . . . . . . . . . . . 9 64 3.1. Pre-shared key protected distribution . . . . . . . . . . 11 65 3.2. Public Key encrypted key distribution . . . . . . . . . . 11 66 3.3. Diffie-Hellman key agreement protected with digital 67 signatures . . . . . . . . . . . . . . . . . . . . . . . . 12 68 3.4. Unprotected key distribution . . . . . . . . . . . . . . . 13 69 3.5. Diffie-Hellman key agreement protected with pre-shared 70 secrets . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 3.6. SAML assisted DH-key agreement . . . . . . . . . . . . . . 14 72 3.7. Asymmetric key distribution with in-band certificate 73 exchange . . . . . . . . . . . . . . . . . . . . . . . . . 16 74 4. Further MIKEY Extensions . . . . . . . . . . . . . . . . . . . 18 75 4.1. ECC algorithms support . . . . . . . . . . . . . . . . . . 18 76 4.1.1. Elliptic Curve Integrated Encryption Scheme 77 application in MIKEY . . . . . . . . . . . . . . . . . 19 78 4.1.2. Elliptic Curve Menezes-Qu-Vanstone Scheme 79 application in MIKEY . . . . . . . . . . . . . . . . . 19 80 4.2. New MIKEY Payload for bootstrapping TESLA . . . . . . . . 19 81 4.3. MBMS extensions to the Key ID information type . . . . . . 20 82 4.4. OMA BCAST MIKEY General Extension Payload Specification . 20 83 4.5. Supporting Integrity Transform carrying the Rollover 84 Counter . . . . . . . . . . . . . . . . . . . . . . . . . 21 85 5. Selection and interworking of MIKEY modes . . . . . . . . . . 22 86 5.1. MIKEY and Early Media . . . . . . . . . . . . . . . . . . 24 87 5.2. MIKEY and Forking . . . . . . . . . . . . . . . . . . . . 24 88 5.3. MIKEY and Call Transfer/Redirect/Retarget . . . . . . . . 25 89 5.4. MIKEY and Shared Key Conferencing . . . . . . . . . . . . 26 90 5.5. MIKEY Mode Summary . . . . . . . . . . . . . . . . . . . . 26 91 6. Transport of MIKEY messages . . . . . . . . . . . . . . . . . 28 92 7. MIKEY alternatives for SRTP security parameter negotiation . . 29 93 8. Summary of MIKEY related IANA Registrations . . . . . . . . . 31 94 9. Security Considerations . . . . . . . . . . . . . . . . . . . 32 95 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 96 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 97 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 98 12.1. Normative References . . . . . . . . . . . . . . . . . . . 35 99 12.2. Informative References . . . . . . . . . . . . . . . . . . 35 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 101 Intellectual Property and Copyright Statements . . . . . . . . . . 39 103 1. Introduction 105 Key distribution describes the process of delivering cryptographic 106 keys to the required parties. MIKEY [RFC3830], the Multimedia 107 Internet Keying, has been defined focusing on support for the 108 establishment of security context for the Secure Real-time Transport 109 Protocol [RFC3711]. Note that RFC3830 is not restricted to be used 110 for SRTP only, as it features a generic approach and allows for 111 extensions to the key distribution schemes. Thus, it may also be 112 used for security parameter negotiation for other protocols. 114 For MIKEY, meanwhile seven key distribution methods are described as 115 there are: 117 o Symmetric key distribution as defined in [RFC3830] (MIKEY-PSK) 119 o Asymmetric key distribution as defined in [RFC3830] (MIKEY-RSA) 121 o Diffie-Hellman key agreement protected by digital signatures as 122 defined in [RFC3830] (MIKEY-DHSIGN) 124 o Unprotected key distribution (MIKEY-NULL) 126 o Diffie-Hellman key agreement protected by symmetric pre-shared 127 keys as defined in [RFC4650] (MIKEY-DHHMAC) 129 o SAML assisted Diffie-Hellman key agreement as defined (not 130 available as seperate document, but discussions are reflected 131 within this document (MIKEY-DHSAML)) 133 o Asymmetric key distribution (based on asymmetric encryption) with 134 in-band certificate provision as defined in [RFC4738] 135 (MIKEY-RSA-R) 137 Note that the latter three modes are extensions to MIKEY as there 138 have been scenarios where none of the first four modes defined in 139 [RFC3830] fits perfectly. There are further extensions to MIKEY 140 comprising algorithm enhancements and a new payload definition 141 supporting other protocols than SRTP. 143 Algorithm extensions are defined in the following document: 145 o ECC algorithms for MIKEY as defined in [I-D.ietf-msec-mikey-ecc] 147 Payload extensions are defined in the following documents: 149 o Bootstrapping TESLA, defining a new payload for the Timed 150 Efficient Stream Loss-tolerant Authentication (TESLA) protocol 152 [RFC4082] as defined in [RFC4442] 154 o The Key ID information type for the general extension payload as 155 defined in [RFC4563] 157 o OMA BCAST MIKEY General Extension Payload Specification, as 158 defined in [RFC4909] 160 o Integrity Transform Carrying Roll-over Counter for SRTP, as 161 defined in [RFC4771]. Note that this is rather an extension to 162 SRTP and requires MIKEY to carry a new parameter, but is stated 163 here for completeness. 165 This document provides an overview about RFC3830 and the relations to 166 the different extensions to provide a framework when using MIKEY. It 167 is intended as additional source of information for developers or 168 architects to provide more insight in use case scenarios and 169 motivations as well as advantages and disadvantages for the different 170 key distribution schemes. The use cases discussed in this document 171 are inspired by specific protocol workings of SIP that have proved to 172 be problematic for a general key distribution mechanisms in general. 173 These protocol workings are described in detail in Wing et al. 174 [I-D.ietf-sip-media-security-requirements] to include the following: 176 o Early Media respectively Media before SDP answer 178 o Forking 180 o Call Transfer/Redirect/Retarget 182 o Shared Key Conferencing 184 2. Terminology and Definitions 186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 188 document are to be interpreted as described in RFC 2119 [RFC2119]. 190 The following definitions have been taken from [RFC3830]: 192 (Data) Security Protocol: the security protocol used to protect the 193 actual data traffic. Examples of security protocols 194 are IPsec and SRTP. 196 Data SA Data Security Association information for the security 197 protocol, including a TEK and a set of parameters/ 198 policies. 200 CS Crypto Session, uni- or bi-directional data stream(s), 201 protected by a single instance of a security protocol. 203 CSB Crypto Session Bundle, collection of one or more 204 Crypto Sessions, which can have common TGKs (see 205 below) and security parameters. 207 CS ID Crypto Session ID, unique identifier for the CS within 208 a CSB. 210 CSB ID Crypto Session Bundle ID, unique identifier for the 211 CSB. 213 TGK TEK Generation Key, a bit-string agreed upon by two or 214 more parties, associated with CSB. From the TGK, 215 Traffic-encrypting Keys can then be generated without 216 needing further communication. 218 TEK Traffic-Encrypting Key, the key used by the security 219 protocol to protect the CS (this key may be used 220 directly by the security protocol or may be used to 221 derive further keys depending on the security 222 protocol). The TEKs are derived from the CSB's TGK. 224 TGK re-keying the process of re-negotiating/updating the TGK (and 225 consequently future TEK(s)). 227 Initiator the initiator of the key management protocol, not 228 necessarily the initiator of the communication. 230 Responder the responder in the key management protocol. 232 Salting key a random or pseudo-random (see [RAND, HAC]) string 233 used to protect against some off-line pre-computation 234 attacks on the underlying security protocol. 236 HDR denotes the protocol header 238 PRF(k,x) a keyed pseudo-random function 240 E(k,m) encryption of m with the key k 242 RAND Random value 244 T Timestamp 246 CERTx the certificate of x 248 SIGNx the signature from x using the private key of x 250 PKx the public key of x 252 IDx the identity of x 254 [] an optional piece of information 256 {} denotes zero or more occurrences 258 || concatenation 260 | OR (selection operator) 262 ^ exponentiation 264 XOR exclusive or 266 The following definition has been added to the ones from [RFC3830]: 268 SSRC Synchronization Source Identifier 270 KEMAC MIKEY Key Data Transport Payload, containing a set of 271 encrypted sub-payloads and a MAC. 273 V MIKEY Verification Message 274 SP Security Parameter 276 Forking The ability of a SIP proxy to replicate an incoming 277 request to multiple outgoing requests in order to 278 efficiently find the called party for rendezvous. SIP 279 forking can be done in serial (depth-first search), or 280 in parallel (breadth-first search). 282 Redirect The ability of a SIP proxy to send a final response 283 that redirects the caller to send a request to an 284 alternate location. 286 Re-target The ability of a SIP proxy to re-write the Request-URI 287 thereby altering the destination of the request 288 without explicitly notifying the user agent client. 290 3. MIKEY Overview 292 This section will provide an overview about MIKEY. MIKEY focuses on 293 the setup of cryptographic context to secure multimedia sessions in a 294 heterogeneous environment. MIKEY is mainly intended to be used for 295 peer-to-peer, simple one-to-many, and small-size (interactive) 296 groups. One objective of MIKEY is to produce a Data security 297 association (SA) for the security protocol, including a traffic- 298 encrypting key (TEK), which is derived from a TEK Generation Key 299 (TGK), and used as input for the security protocol. 301 MIKEY supports the possibility of establishing keys and parameters 302 for more than one security protocol (or for several instances of the 303 same security protocol) at the same time. The concept of Crypto 304 Session Bundle (CSB) is used to denote a collection of one or more 305 Crypto Sessions that can have common TGK and security parameters, but 306 which obtain distinct TEKs from MIKEY. 308 MIKEY as defined in RFC3830 may proceed with one roundtrip at most, 309 using a so-called Initiator message for the forward direction and a 310 Responder message for the backward direction. Note that there exist 311 MIKEY schemes, which may proceed within a half roundtrip (e.g., based 312 on a pre-shared key), while other schemes require a full roundtrip 313 (e.g., Diffie Hellman based schemes). The main objective of the 314 Initiator's message (I_MESSAGE) is to transport one or more TGKs 315 (carried in the KEMAC field) and a set of security parameters (SPs) 316 to the Responder in a secure manner. As the verification message 317 from the Responder is optional for some schemes, the Initiator 318 indicates whether it requires a verification message or not from the 319 Responder. 321 The focus of the following subsections lies on the key distribution 322 methods as well as the discussion about advantages and disadvantages 323 of the different schemes. Note that the MIKEY key distribution 324 schemes rely on loosely synchronized clocks. If clock 325 synchronization is not available, the replay handling of MIKEY 326 (cf.[RFC3830]) may not work. This is due to the fact that MIKEY does 327 not use a challenge-response mechanism for replay handling; instead, 328 timestamps are used together with message caching. Thus the required 329 synchronization depends on the number of messages that can be cached 330 on either side. Therefore, MIKEY recommendeds to adjust the cache 331 size depending on the clock skew in the deployment environment. 332 Moreover, RFC3830 recommends the ISO time synchronization protocol 333 [ISO_sec_time]. The format applied to the timestamps submitted in 334 the MIKEY have to match the NTP format described in [RFC1305]. In 335 other cases, such as of a SIP endpoint, clock synchronization by 336 deriving time from a trusted outbound proxy may be appropriate. 338 The different MIKEY related schemes are compared regarding following 339 criteria: 341 o Mandatory for implementation: provides information, if RFC3830 342 requires the implementation of this scheme. 344 o Scalability: describes the technical feasibility to easily deploy 345 a solution based on the considered scheme 347 o Dependency on PKI: states if the support of a PKI is required to 348 support this scheme. Note, that PKI here relates to PKI services 349 like key generation, distribution and revocation. 351 o Provision of Perfect Forward Secrecy (PFS): Describes the support 352 of PFS, which is, according to RFC4949 [RFC4949] the property that 353 compromising the long-term keying material does not compromise 354 session keys that were previously derived from the long-term 355 material. 357 o Key generation involvement: Describes if both or just one of the 358 participants are actively involved in key generation. The option 359 to involve both parties in the key generation is considered here 360 as it addresses several points: 362 * If both sides contribute public entropy, it is ensured that 363 each side can guarantee that keys are fresh to avoid replay 364 attacks. 366 * Involvement of both sides avoids that one side generates 367 (intentionally or unintentionally) weak (predictable) nonces, 368 which in turn may result in weak keys. 370 o Support of group keying: Feasibility of the MIKEY option to be 371 used also for group keying, e.g., in conferencing scenarios. 373 If MIKEY is used for SRTP [RFC3711] bootstrapping, it also uses the 374 SSRC to associate security policies with actual sessions. The SSRC 375 identifies the synchronization source. The value is chosen randomly, 376 with the intent that no two synchronization sources within the same 377 SRTP session will have the same SSRC. Although the probability of 378 multiple sources choosing the same identifier is low, all (S)RTP 379 implementations must be prepared to detect and resolve collisions. 380 Nevertheless in multimedia communication scenarios supporting forking 381 (see Section 5.2) or retargeting, (see Section 5.3) collisions may 382 occur leading to so-called two-time pads, i.e., the same key is used 383 for media streams to different destinations. This occurs, if two 384 branches have the same TEK (based on the MIKEY key establishment) and 385 choose the same 32-bit SSRC for the SRTP streams. The SRTP key 386 derivation will then produce the same session keys (as the input 387 values are the same) and also derive the same initialization vector 388 per packet, as the SSRC are the same. Note that two time pads may 389 also occur for media streams to the same destination. This is 390 outlined in [RFC3711]. 392 3.1. Pre-shared key protected distribution 394 This option of the key management uses a pre-shared secret key to 395 derive key material for integrity protection and encryption to 396 protect the actual exchange of key material. Note that the pre- 397 shared secret is agreed upon before the session, e.g., by out-of-band 398 means. The response message is optional and may be used for mutual 399 authentication (proof of possession of the pre-shared secret) or 400 error signaling. 402 Initiator Responder 404 I_MESSAGE = 405 HDR, T, RAND, [IDi],[IDr], 406 {SP}, KEMAC ---> 407 R_MESSAGE = 408 [<---] HDR, T, [IDr], V 410 The advantages of this approach lay in the fact that there is no 411 dependency on a PKI (Public Key Infrastructure), the solution 412 consumes low bandwidth and enables high performance, and is all in 413 all a simple straightforward master key provisioning. The 414 disadvantages are that perfect forward secrecy is not provided and 415 key generation is just performed by the initiator. Furthermore, the 416 approach is not scalable to larger configurations but is acceptable 417 in small-sized groups. Note that according to [RFC3830] this option 418 is mandatory to implement. 420 3.2. Public Key encrypted key distribution 422 Using the asymmetric option of the key management, the initiator 423 generates the key material (TGK's) to be transmitted and sends it 424 encrypted with a so-called envelope key, which in turn is encrypted 425 with the receiver's public key. The envelope key, env-key, which is 426 a random number, is used to derive the auth-key and the enc-key. 427 Moreover, the envelope key may be used as a pre-shared key to 428 establish further crypto sessions. The response message is optional 429 and may be used for mutual authentication or error signaling. 431 Initiator Responder 433 I_MESSAGE = 434 HDR, T, RAND, [IDi|CERTi], 435 [IDr], {SP}, KEMAC, [CHASH], 436 PKE, SIGNi ---> 437 R_MESSAGE = 438 [<---] HDR, T, [IDr], V 440 An advantage of this approach is that it allows the usage of self- 441 signed certificates, which in turn can avoid a full blown PKI. Note 442 that using self-signed certificates may result in limited scalability 443 and also require additional means for authentication such as exchange 444 of fingerprints of the certificates or similar techniques. The 445 disadvantages comprise the necessity of a PKI for fully scalability, 446 the performance of the key generation just by the initiator, and no 447 provision of perfect forward secrecy. Additionally, the responder 448 certificate needs to be available in advance at the sender's side. 449 Furthermore, the verification of certificates may not be done in 450 real-time. This could be the case in scenarios where the revocation 451 status of certificates is checked through a further component. 452 Depending on the initiator role this scheme may can also be applied 453 in group based communication, where a central server distributes the 454 group key protected with the public keys of the associated clients. 455 Note, according to [RFC3830] this option is mandatory to implement. 457 3.3. Diffie-Hellman key agreement protected with digital signatures 459 The Diffie-Hellman option of the key management enables a shared 460 secret establishment between initiator and responder in a way where 461 both parties contribute to the shared secret. The Diffie-Hellman key 462 agreement is authenticated (and integrity protected) using digital 463 signatures. 465 Initiator Responder 467 I_MESSAGE = 468 HDR, T, RAND, [IDi|CERTi], 469 [IDr], {SP}, DHi, SIGNi ---> 470 R_MESSAGE = 471 <--- HDR, T, [IDr|CERTr], 472 IDi, DHr, DHi, SIGNr 474 [RFC3830] does mandate the support of RSA as specific asymmetric 475 algorithm for the signature generation. Additionally the algorithm 476 used for signature or public key encryption is defined by, and 477 dependent on the certificate used. Besides the use of X.509v3 478 certificates it is mandatory to support the Diffie-Hellmann group 479 "OAKLEY5" [RFC2412]. It is also possible to use other Diffie-Hellman 480 groups within MIKEY. This can be done by defining a new mapping sub- 481 payload and the associated policy payload according to [RFC3830]. 482 The advantages of this approach are a fair, mutual key agreement 483 (both parties provide to the key), and perfect forward secrecy, and 484 the absence of the need to fetch a certificate in advance as needed 485 for the MIKEY-RSA method depicted above. Moreover, it also provides 486 the option to use self-signed certificates to avoid a PKI deployment. 487 Note that, depending on the security policy, self-signed certificates 488 may not be suitable for every use case. 490 Negatively to remark is that this approach scales mainly to point-to- 491 point and depends on PKI for full scalability. Multiparty 492 conferencing is not supported using just MIKEY-DHSIGN. Nevertheless, 493 the established Diffie-Hellman-Secret may serve as a pre-shared key 494 to bootstrap group-related security parameter. Furthermore, as for 495 the MIKEY-RSA mode described above, the verification of certificates 496 may not be necessarily done in real-time. This could be the case in 497 scenarios where the revocation status of certificates is checked 498 through a further component. Note, according to [RFC3830] it is 499 optional to implement this scheme. 501 3.4. Unprotected key distribution 503 RFC3830 also supports a mode to provide a key in an unprotected 504 manner (MIKEY-NULL). This is based on the symmetric key encryption 505 option depicted in Section 3.1 but is used with the NULL encryption 506 and the NULL authentication algorithm. It may be compared with the 507 plain approach in sdescriptions [RFC4568]. MIKEY-NULL completely 508 relies on the security of the underlying layer, e.g., provided by 509 TLS. This option should be used with caution as it does not protect 510 the key management. 512 Based on the missing cryptographic protection of this method, it is 513 obvious that perfect forward secrecy is not provided. As it is based 514 on the pre-shared secret mode only the initiator provides to the key 515 management. The method itself is highly scalable but again, without 516 proper protection through an underlying security layers it is not 517 advisable for use. 519 3.5. Diffie-Hellman key agreement protected with pre-shared secrets 521 This is an additional option which has been defined in [RFC4650]. In 522 contrast to the method described in Section 3.3 here the Diffie- 523 Hellmann key agreement is authenticated (and integrity protected) 524 using a pre-shared secret and keyed hash function. 526 Initiator Responder 528 I_MESSAGE = 529 HDR, T, RAND, [IDi], 530 IDr, {SP}, DHi, KEMAC ---> 531 R_MESSAGE = 532 <--- HDR, T,[IDr], IDi, 533 DHr, DHi, KEMAC 535 TGK = g^(xi * yi) TGK = g^(xi * yi) 537 For the integrity protection of the Diffie-Hellman key agreement 538 [RFC4650] mandates the use of HMAC SHA-1. Regarding Diffie-Hellman 539 groups [RFC3830] is referenced. Thus, it is mandatory to support the 540 Diffie-Hellman group "OAKLEY5" [RFC2412]. It is also possible to use 541 other Diffie-Hellman groups within MIKEY. This can be done by 542 defining a new mapping sub-payload and the associated policy payload 543 according to RFC3830. This option has also several advantages, as 544 there are the fair mutual key agreement, the perfect forward secrecy, 545 and no dependency on a PKI and PKI standards. Moreover, this scheme 546 has a sound performance and reduced bandwidth requirements compared 547 to MIKEY-DH-SIGN and provides a simple and straightforward master key 548 provisioning. The establishment of shared secrets and the lack of 549 support for group keying is a disadvantage. 551 This mode of operation provides an efficient scheme in deployments 552 where there is a central trusted server that is provisioned with 553 shared secrets for many clients. Such setups could for example be 554 enterprise PBXs, service provider proxies, etc. In contrast to the 555 plain pre-shared key encryption based mode, described in Section 3.1, 556 this mode offers perfect forward secrecy as well as active 557 involvement in the key generation of both parties involved. 559 3.6. SAML assisted DH-key agreement 561 There has been a longer discussion during IETF meetings and also on 562 the IETF MSEC mailing about a SAML assisted DH approach. This idea 563 has not been submitted as a separate draft. Nevertheless, the 564 discussion is reflected here as it is targeted to fulfill general 565 requirements on key management approaches. Those requirements can be 566 summarized as: 568 1. Mutual authentication of involved parties 570 2. Both parties involved contribute to the session key generation 572 3. Provide perfect forward secrecy 573 4. Support distribution of group session keys 575 5. Provide liveliness tests when involved parties do not have a 576 reliable clock 578 6. Support of limited parties involved 580 To fulfill all of the requirements, it was proposed to use a classic 581 Diffie-Hellman key agreement protocol for key establishment in 582 conjunction with a User Agents (UA's) SIP server signed element, 583 authenticating the Diffie-Hellman key and the ID using the SAML 584 (Security Association Markup Language, [SAML_overview]) approach. 585 Here the client's public Diffie-Hellman-credentials are signed by the 586 server to form a SAML assertion (referred to as CRED below), which 587 may be used for later sessions with other clients. This assertion 588 needs at least to convey the ID, public DH key, expiry, and the 589 signature from the server. It provides the involved clients with 590 mutual authentication and message integrity of the key management 591 messages exchanged. 593 Initiator Responder 595 I_MESSAGE = 596 HDR, T, RAND1, [CREDi], 597 IDr, {SP} ---> 598 R_MESSAGE = 599 <--- HDR, T, [CREDr], IDi, DHr, 600 RAND2, (SP) 601 TGK = HMACx(RAND1|RAND2), where x = g^(xi * xr). 603 Additionally the scheme proposes a second roundtrip to avoid the 604 dependence on synchronized clocks and provide liveliness checks. 605 This is achieved by exchanging nonces, protected with the session 606 key. The second roundtrip can also be used for distribution of group 607 keys or to leverage a weak DH key for a stronger session key. The 608 trigger for the second round trip would be handled via SP, the 609 Security Policy communicated via MIKEY. 611 Initiator Responder 613 I_MESSAGE = 614 HDR, SIGN(ENC(RAND3)) ---> 615 R_MESSAGE = 616 <--- SIGN(ENC(RAND4)) 618 Note if group keys are to be provided RAND would be substituted by 619 that group key. 621 With the second roundtrip, this approach also provides an option for 622 all of the other key distribution methods, when liveliness checks are 623 needed. The drawback of the second roundtrip is that these messages 624 need to be integrated into the call flow of the signaling protocol. 625 In straight forward call one roundtrip may be enough to setup a 626 session. Thus this second roundtrip would require additional 627 messages to be exchanged. 629 Regarding the different criteria discussed in the introduction of 630 this section, the advantages of this approach are a fair, mutual key 631 agreement (both parties provide to the key), perfect forward secrecy. 632 Through the second roundtrip, the dependency on synchronized clocks 633 can be avoided. Moreover, this second roundtrip enables the 634 distribution of a group key and thus enhances the scalability from 635 mainly point-to-point to also multiparty conferencing. The usage of 636 SAML assisted DH may decrease the hidden latency cost through the 637 credential validation necessary to be done for the signed DH scheme 638 described in Section 3.3. If the UA received its SAML assertion from 639 its domain's SIP server, it is trusting the server implicitly thus it 640 may extend that trust to relying on it to validate the other party's 641 SAML assertion. This not only eliminates the hidden validation 642 latency, but also its computational cost to the UA. 644 Negatively to remark is that this proposal does have one significant 645 security risk. The UA's SIP server can cheat and create an extra 646 authentication object for the UA where it has the Diffie-Hellman 647 private key. With this, the (SIP) server issuing the SAML assertion 648 can successfully launch a MITM attack against two of its UAs. Also 649 two SIP servers can collude so that either can successfully launch a 650 MITM attack against their UAs. A UA can block this attack if its 651 Diffie-Hellman key is authenticated by a trustworthy third party and 652 this whole object is signed by the SIP server. Moreover, this 653 approach uses two roundtrips, increasing the necessary bandwidth and 654 also the setup time, which may be crucial for many scenarios. For 655 the credential generation usually a seperate component (server) is 656 necessary, so server less call setup is not supported. 658 3.7. Asymmetric key distribution with in-band certificate exchange 660 This is an additional option which has been defined in [RFC4738]. It 661 describes the asymmetric key distribution with optional in-band 662 certificate exchange. 664 Initiator Responder 666 I_MESSAGE = 667 HDR, T, [IDi|CERTi], [IDr], 668 {SP}, [RAND], SIGNi ---> 669 R_MESSAGE = 670 <--- HDR, [GenExt(CSB-ID)], T, 671 RAND, [IDr|CERTr], [SP], 672 KEMAC, SIGNr 674 This option has some advantages compared to the asymmetric key 675 distribution stated in Section 3.2. Here, the sender and receiver do 676 not need to know the certificate of the other peer in advance as it 677 may be sent in the MIKEY initiator message (if the receiver knows the 678 certificate in advance, RFC3830's MIKEY-RSA mode may be used 679 instead). Thus, the receiver of this message can utilize the 680 received key material to encrypt the session parameter and send them 681 back as part of the MIKEY response message. The certificate check 682 may be done depending on the signing authority. If the certificate 683 is signed by a publicly accepted authority the certificate validation 684 can be done in a straightforward manner, by using the commonly known 685 certificate authority's public key. In the other case additional 686 steps may be necessary. The disadvantage is that no perfect forward 687 secrecy is provided. 689 This mode is meant to provide an easy option for certificate 690 provisioning when PKI is present and/or required. Specifically in 691 SIP, session invitations can be retargeted or forked. MIKEY modes 692 that require the Initiator to target a single well known Responder 693 may be impractical here as they may require multiple roundtrips to do 694 key negotiation. By allowing the Responder to generate secret 695 material used for key derivation this mode allows for an efficient 696 key delivery scheme. Note that the Initiator can contribute to the 697 key material since the key is derived from CSB-ID and RAND payloads 698 in unicast use cases. This mode is also useful in multicast 699 scenarios where multiple clients are contacting a known server and 700 are downloading the key. Responder workload is significantly reduced 701 in these scenarios compared to MIKEY in public key mode. This is due 702 to the fact that the RSA asymmetric encryption requires less effort 703 compared to the decryption using the private key (The public key is 704 usually shorter than the private key, hence less performance for 705 encryption compared to decryption). Examples of deployments where 706 this mode can be used are enterprises with PKI, service provider 707 setups where the service provider decides to provision certificates 708 to its users, etc. 710 4. Further MIKEY Extensions 712 This section will provide an overview about further MIKEY [RFC3830] 713 extensions for crypto algorithms, generic payload enhancements, as 714 well as enhancements to support the negotiation of security 715 parameters for other security protocols than SRTP. These extensions 716 have been defined in several additional documents. 718 4.1. ECC algorithms support 720 [I-D.ietf-msec-mikey-ecc] proposes extensions to the authentication, 721 encryption and digital signature methods described for use in MIKEY, 722 employing elliptic-curve cryptography (ECC). These extensions are 723 defined to align MIKEY with other ECC implementations and standards. 725 The motivation for supporting ECC within the MIKEY stems from the 726 following advantages: 728 o ECC modes are more and more added to security protocols 730 o ECC support requires considerably smaller keys by keeping the same 731 security level compared to other asymmetric techniques (like RSA). 732 Elliptic curve algorithms are capable of providing security 733 consistent with AES keys of 128, 192, and 256 bits without 734 extensive growth in asymmetric key sizes. 736 o As stated in [I-D.ietf-msec-mikey-ecc] implementations have shown 737 that elliptic curve algorithms can significantly improve 738 performance and security-per-bit over other recommended 739 algorithms. 741 These advantages make the usage of ECC especially interesting for 742 embedded devices, which may have only limited performance and storage 743 capabilities. 745 [I-D.ietf-msec-mikey-ecc] proposes several ECC based mechanisms to 746 enhance the MIKEY key distribution schemes, as there are: 748 o Use of ECC methods extending the Diffie-Hellman key exchange: 749 MIKEY-DHSIGN with ECDSA or ECGDSA 751 o Use of ECC methods extending the Diffie-Hellman key exchange: 752 MIKEY-DHSIGN with ECDH 754 o Use of Elliptic Curve Integrated Encryption Scheme (MIKEY-ECIES) 756 o Use of Elliptic Curve Scheme Menezes-Qu-Vanstone (MIKEY-ECMQV) 757 The following subsections will provide more detailed information 758 about the message exchanges for MIKEY-ECIES and MIKEY-ECMQV. 760 4.1.1. Elliptic Curve Integrated Encryption Scheme application in MIKEY 762 The following figure shows the message exchange for the MIKEY-ECIES 763 scheme: 765 Initiator Responder 767 I_MESSAGE = 768 HDR, T, RAND, [IDi|CERTi], 769 [IDr], {SP}, KEMAC, 770 [CHASH], PKE, SIGNi ---> 771 R_MESSAGE = 772 [<---] HDR, T, [IDr], V 774 4.1.2. Elliptic Curve Menezes-Qu-Vanstone Scheme application in MIKEY 776 The following figure shows the message exchange for the MIKEY-ECMQV 777 scheme: 779 Initiator Responder 781 I_MESSAGE = 782 HDR, T, RAND, [IDi|CERTi], 783 [IDr], {SP}, 784 ECCPTi, SIGNi ---> 785 R_MESSAGE = 786 [<---] HDR, T, [IDr], V 788 4.2. New MIKEY Payload for bootstrapping TESLA 790 TESLA [RFC4082] is a protocol for providing source authentication in 791 multicast scenarios. TESLA is an efficient protocol with low 792 communication and computation overhead, which scales to large numbers 793 of receivers, and also tolerates packet loss. TESLA is based on 794 loose time synchronization between the sender and the receivers. 795 Source authentication is realized in TESLA by using Message 796 Authentication Code (MAC) chaining. The use of TESLA within the 797 Secure Real-time Transport Protocol (SRTP) has been published in 798 [RFC4383] targeting multicast authentication in scenarios, where SRTP 799 is applied to protect the multimedia data. This solution assumes 800 that TESLA parameters are made available by out-of-band mechanisms. 802 [RFC4442] specifies payloads for MIKEY to bootstrap TESLA for source 803 authentication of secure group communications using SRTP. TESLA may 804 be bootstrapped using one of the MIKEY key management approaches 805 described above by sending the MIKEY message via unicast, multicast 806 or broadcast. This approach provides the necessary parameter payload 807 extensions for the usage of TESLA in SRTP. Nevertheless, if the 808 parameter set is also sufficient for other TESLA use cases, it can be 809 applied as well. 811 4.3. MBMS extensions to the Key ID information type 813 This extension specifies a new Type (the Key ID Information Type) for 814 the General Extension Payload. This is used in, e.g., the Multimedia 815 Broadcast/Multicast Service (MBMS) specified in the 3rd Generation 816 Partnership Project (3GPP). MBMS requires the use of MIKEY to convey 817 the keys and related security parameters needed to secure the 818 multimedia that is multicast or broadcast. 820 One of the requirements that MBMS puts on security is the ability to 821 perform frequent updates of the keys. The rationale behind this is 822 that it will be costly for subscribers to re-distribute the 823 decryption keys to non-subscribers. The cost for re-distributing the 824 keys using the unicast channel should be higher than the cost of 825 purchasing the keys for this scheme to have an effect. To achieve 826 this, MBMS uses a three-level key management, to distribute group 827 keys to the clients, and be able to re-key by pushing down a new 828 group key. MBMS has the need to identify, which types of keys are 829 involved in the MIKEY message and their identity. 831 [RFC4563] specifies a new Type for the General Extension Payload in 832 MIKEY, to identify the type and identity of involved keys. Moreover, 833 as MBMS uses MIKEY both as a registration protocol and a re-key 834 protocol, this RFC specifies the necessary additions that allow MIKEY 835 to function both as a unicast and multicast re-key protocol in the 836 MBMS setting. 838 4.4. OMA BCAST MIKEY General Extension Payload Specification 840 The document [RFC4909] specifies a new general extension payload type 841 for use in the Open Mobile Alliance's (OMA) Browser and Content 842 Broadcast (BCAST) group. OMA BCAST's service and content protection 843 specification uses short term key message and long term key message 844 payloads that in certain broadcast distribution systems are carried 845 in MIKEY. The document defines a general extensions payload to allow 846 possible extensions to MIKEY without defining a new payload. The 847 general extension payload can be used in any MIKEY message and is 848 part of the authenticated or signed data part. Note, that only a 849 parameter description is included, but no key information. 851 4.5. Supporting Integrity Transform carrying the Rollover Counter 853 The document [RFC4771] defines a new integrity transform for SRTP 854 [RFC3711] providing the option to also transmit the Roll Over Counter 855 (ROC) as part of dedicated SRTP packets. This extension has been 856 defined for the use in the 3GPP multicast/broadcast service. While 857 the communicating parties did agree on a starting ROC, in some cases 858 the receiver may not be able to synchronize his ROC with the one used 859 by the sender even if it is signaled to him out of band. Here the 860 new extension provides the possibility for the receiver to re- 861 synchronize to the sender's ROC. To signal the use of the new 862 integrity transform new definitions for certain MIKEY payloads need 863 to be done. These new definition comprise the integrity transforms 864 itself as well as new integrity transform parameter. Moreover, the 865 document specifies additional parameter, to enable the usage of 866 different integrity transforms for SRTP and SRTCP. 868 5. Selection and interworking of MIKEY modes 870 While MIKEY and its extensions provide a variety of choice in terms 871 of modes of operation an implementation may choose to simplify its 872 behavior. This can be achieved by operating in a single mode of 873 operation when in Initiator's role. Where PKI is available and/or 874 required an implementation may choose for example to start all 875 sessions in RSA-R mode and it would be trivial for it to act as a 876 Responder in public key mode. If envelope keys are cached it can 877 then also choose to do re-keying in shared key mode. It is outside 878 the scope of MIKEY or MIKEY extensions if the caching of envelope 879 keys is allowed. This is a matter of the configuration of the 880 involved components. This local configuration is also outside the 881 scope of MIKEY. In general, modes of operation where the Initiator 882 generates keying material are useful when two peers are aware of each 883 other before the MIKEY communication takes place. If a peer chooses 884 not to operate in the public key mode it may reject the certificate 885 of the Initiator. The same applies to peers that choose to operate 886 in one of the DH modes exclusively. 888 Forward MIKEY modes, where the initiator provides the key material, 889 like public key or shared key mode when used in SIP/SDP may lead to 890 complications in some calls scenarios, for example forking scenarios 891 where key derivation material gets distributed to multiple parties. 892 As mentioned earlier this may be impractical as some of the 893 destinations may not have the resources to validate the message and 894 may cause the initiator to drop the session invitation. Even in the 895 case all parties involved have all the prerequisites for interpreting 896 the MIKEY message received there is a possible problem with multiple 897 responders starting media sessions using the same key. While the 898 SSRCs will be different in most of the cases they are only 32 bits 899 long and there is a high probability of a two-time pad problem. This 900 is due to the support of scenarios like forking (see also 901 Section 5.2) or retargeting (see also Section 5.3), where a two-time 902 pad occurs if two branches have the same TEK (based on the MIKEY key 903 establishment) and choose the same 32-bit SSRC for the SRTP streams 904 and transmit SRTP packets. As suggested earlier forward modes are 905 most useful when the two peers are aware of each other before the 906 communication takes place (as is the case in key renewal scenarios 907 when costly public key operations can be avoided by using the 908 envelope key). 910 The following list gives an idea how the different MIKEY modes may be 911 used or combined, depending on available key material at the 912 initiator side. 914 1. If the Initiator has a PSK with the Responder, it uses the PSK 915 mode. 917 2. If the Initiator has a PSK with the Responder, but needs PFS or 918 knows that the responder has a policy that both parties should 919 provide entropy to the key, then it uses the DH-HMAC mode. 921 3. If the Initiator has the RSA key of the Responder, it uses the 922 RSA mode to establish the TGK. Note that the TGK may be used as 923 PSK together with Option 1 for further key management operations. 925 4. If the Initiator does not expect the receiver to have his 926 certificate he may use RSA-R. Using RSA-R he can provide the 927 initiators certificate information in-band to the receiver. 928 Moreover, the initiator may also provide a random number which 929 can be used by the receiver for key generation. Thus both 930 parties can be involved in the key management. But as the 931 inclusion of the random number cannot be forced by the initiator, 932 true PFS cannot be provided. Note that in this mode, after 933 establishing the TGK, it may be used as PSK with other MIKEY 934 modes. 936 5. The Initiator uses DH-SIGN when PFS is required by his policy and 937 he knows that the responder has a policy that both parties should 938 provide entropy. Note that also in this mode, after establishing 939 the TGK, it may be used as PSK with other MIKEY modes. 941 6. If no PSK or certificate is available at the initiators side (and 942 likewise at the receivers side) but lower level security (like 943 TLS or IPsec) is in place the user may use the unprotected mode 944 of MIKEY.It has to obeyed, that this enables intermediate nodes 945 like proxies to actually get the exchanged master key in plain. 946 This may not be intended, especially in cases, where the 947 intermediate node is not trusted. 949 Besides the available key material choosing between the different 950 modes of MIKEY depends strongly on the use case. This section will 951 depict dedicated scenarios to discuss the feasibility of the 952 different modes in these scenarios. A comparison of the different 953 modes of operation regarding the influences and requirements to the 954 deploying infrastructure as well as the cryptographic strength can be 955 found in [I-D.ietf-sip-media-security-requirements] The following 956 list provides the most prominent call scenarios and are matter of 957 further discussion: 959 o Early Media 961 o Forking 963 o Call Transfer/Redirect/Retarget 964 o Shared key conferencing 966 5.1. MIKEY and Early Media 968 The term early media describes two different scenarios. The first 969 one relates to the case where media data are received before the 970 actual SDP signaling answer has been received. This may arise 971 through the different latency on the signaling and media path. This 972 case is often referred to as media before signaling answer. The 973 second scenario describes the case were media data are send from the 974 callee before sending the final SIP 200 OK nessage. This situation 975 appears usually in call center scenarios, when queueing a waiting 976 loop or when providing personal ring tones. 978 In early media scenarios, SRTP data may be received before the answer 979 over the SIP signaling arrives. The two MIKEY modes, which only 980 require one message to be transported (Section 3.1 and Section 3.2), 981 work nicely in early media situations, as both, sender and receiver 982 have all the necessary parameters in place before actually sending/ 983 receiving encrypted data. The other modes, featuring either Diffie- 984 Hellman key agreement (Section 3.3, Section 3.5, and Section 3.6) or 985 the enhanced asymmetric variant (Section 3.7) suffer from the 986 requirements that the initiator has to wait for the response before 987 being able to decrypt the incoming SRTP media. In fact, even if 988 early media is not used, in other words if media is not sent before 989 the SDP answer a similar problem may arise from the fact that SIP/SDP 990 signaling has to traverse multiple proxies on its way back and media 991 may arrive before the SDP answer. It is expected that this delay 992 would be significantly shorter than in the case of early media 993 though. 995 It is worth mentioning here that security descriptions [RFC4568] has 996 basically the same problem as the initiating end needs the SDP answer 997 before it can start decrypting SRTP media. 999 To cope with the early media problem there are further approaches to 1000 describe security preconditions [RFC5027], i.e., certain 1001 preconditions need to be met to enable voice data encryption. One 1002 example is for instance that a scenario where a provisional response, 1003 containing the required MIKEY parameter, is sent before encrypted 1004 media is processed. 1006 5.2. MIKEY and Forking 1008 In SIP forking scenarios a SIP proxy server sends an INVITE request 1009 to more than one location. This means that also the MIKEY payload, 1010 which is part of the SDP is sent to several (different) locations. 1011 MIKEY modes supporting signatures may be used in forking scenarios 1012 (Section 3.3 and Section 3.7) as here the receiver can validate the 1013 signature. There are limitations with the symmetric key encryption 1014 as well as the asymmetric key encryption modes (Section 3.1 and 1015 Section 3.2). This is due to the fact that in symmetric encryption 1016 the recipient needs to possess the symmetric key before handling the 1017 MIKEY data. For asymmetric MIKEY modes, if the sender is aware of 1018 the forking he may not know in advance to which location the INVITE 1019 is forked and thus may not use the right receiver certificate to 1020 encrypt the MIKEY envelope key. Note, the sender may include several 1021 MIKEY containers into the same INVITE message to cope with forking, 1022 but this requires the knowledge of all forking targets in advance and 1023 also requires the possession of the target certificates. It is out 1024 of the scope of MIKEY to specify behavior in such a case. DH modes 1025 or the Section 3.7 do not have this problem. In scenarios, where the 1026 sender is not aware of forking, only the intended receiver is able to 1027 decrypt the MIKEY container. 1029 If forking is combined with early media the situation gets 1030 aggravated. If MIKEY modes requiring a full roundtrip are used, like 1031 the signed Diffie-Hellman, multiple responses may overload the end 1032 device. An example is forking to 30 destinations (group pickup), 1033 while MIKEY is used with the signed Diffie-Hellman mode together with 1034 security preconditions. Here, every target would answer with a 1035 provisional response, leading to 30 signature validations and Diffie- 1036 Hellman calculations at the senders site. This may lead to a 1037 prolonged media setup delay. 1039 Moreover, depending on the MIKEY mode chosen, a two-time pad may 1040 occur in dependence of the negotiated key material and the SSRC. For 1041 the non Diffie-Hellman modes other than RSA-R, a two-time pad may 1042 occur when multiple receivers pick the same SSRC. 1044 5.3. MIKEY and Call Transfer/Redirect/Retarget 1046 In a SIP environment MIKEY exchange is tied to SDP offer/answer and 1047 irrespective of the implementation model used for call transfer the 1048 same properties and limitations of MIKEY modes apply as in a normal 1049 call setup scenarios. 1051 In certain SIP scenarios the functionality of redirect is supported. 1052 In redirect scenarios the call initiator gets a response that the 1053 called party for instance has temporarily moved and may be reached at 1054 a different destination. The caller can now perform a call 1055 establishment with the new destination. Depending on the originally 1056 chosen MIKEY mode, the caller may not be able to perform this mode 1057 with the new destination. To be more precise MIKEY-PSK, and MIKEY- 1058 DHHMAC require a pre-shared secret in advance. MIKEY-RSA requires 1059 the knowledge about the target's certificate. Thus, these modes may 1060 influence the ability of the caller to initiate a session. 1062 Another functionality, which may be supported in SIP is retargeting. 1063 In contrast to redirect, the call initiator does not get a response 1064 about the different target. The SIP proxy sends the request to a 1065 different target about receiving a redirect response from the 1066 originally called target. This most likely will lead to problems 1067 when using MIKEY modes requiring a pre-shared key (MIKEY-PSK, MIKEY- 1068 DHHMAC) or were the caller used asymmetric key encryption (MIKEY-RSA) 1069 because the key management was originally targeted to a different 1070 destination. 1072 5.4. MIKEY and Shared Key Conferencing 1074 First of all, not all modes of MIKEY support shared key conferencing. 1075 Mainly the Diffie Hellman modes cannot be used straight forward for 1076 conferencing as this mechanism results in a pair wise shared secret 1077 key. All other modes can be applied in conferencing scenarios by 1078 obeying the initiator and responder role, i.e., the half roundtrip 1079 modes need to be initiated by the conferencing unit, to be able to 1080 distribute the conferencing key. The remaining full roundtrip mode, 1081 MIKEY RSA-R will be initiated by the client, while the conferencing 1082 unit provides the conferencing key based on the received certificate. 1084 An example conferencing architecture is defined in the IETF's XCON 1085 WG. The scope of this working group relates to mechanism for 1086 membership and authorization control, a mechanism to manipulate and 1087 describe media "mixing" or "topology" for multiple media types 1088 (audio, video, text), a mechanism for notification of conference 1089 related events/changes (for example a floor change), and a basic 1090 floor control protocol. A document describing possible use case 1091 scenarios is available in [RFC4597]. 1093 5.5. MIKEY Mode Summary 1095 The following two tables summarize the discussion from the 1096 subsections before. The first table matches the scenarios discussed 1097 in this section to the different MIKEY modes. 1099 MIKEY Early Secure Retarget Redirect Shared 1100 mode Media Forking Key Conf 1101 --------------------------------------------------------------------- 1102 PSK (3.1) Yes Yes * 1103 RSA (3.2) Yes Yes * 1104 DH-SIGN (3.3) Yes* Yes Yes 1105 Unprotected (3.4) Yes 1106 DH-HMAC (3.5) 1107 RSA-R (3.7) Yes Yes Yes Yes 1109 * = In centralized conferencing the media mixer needs to sent the MIKEY Initiator message 1111 The following table maps the MIKEY modes to key management related 1112 properties. 1114 MIKEY Manual Needs PFS Key Generation 1115 mode Keys PKI Involvement 1116 -------------------------------------------------------------- 1117 PSK (3.1) Yes No No Initiator 1118 RSA (3.2) No Yes No Initiator 1119 DH-SIGN (3.3) No Yes Yes Both 1120 Unprotected (3.4) No No No Initiator 1121 DH-HMAC (3.5) Yes No Yes Both 1122 RSA-R (3.7) No Yes No Both* 1124 * = assumed the Initiator provides the (optional) RAND value 1126 6. Transport of MIKEY messages 1128 MIKEY defines message formats to transport key information and 1129 security policies between communicating entities. It does not define 1130 the embedding of these messages into the used signaling protocol. 1131 This definition is provided in separate documents, depending on the 1132 used signaling protocol. Nevertheless, MIKEY can also be transported 1133 over plain UDP or TCP to port 2269. 1135 Several IETF defined protocols utilize the Session Description 1136 Protocol (SDP, [RFC4566]) to transport the session parameters. 1137 Examples are the Session Initiation Protocol (SIP, [RFC3261] or the 1138 Gateway Control Protocol (GCP, [RFC3525]). The transport of MIKEY 1139 messages as part of SDP is described in [RFC4567]. Here, the 1140 complete MIKEY message is base64 encoded and transmitted as part of 1141 the SDP part of the signaling protocol message. Note, as several key 1142 distribution messages may be transported within one SDP container, 1143 [RFC4567] also comprises an integrity protection regarding all 1144 supplied key distribution attempts. Thus, bidding down attacks will 1145 be recognized. Regarding RTSP, [RFC4567] defines header extensions 1146 allowing the transport of of MIKEY messages. Here, the initial 1147 messages uses SDP, while the remaining part of the key management is 1148 performed using the header extensions 1150 MIKEY is also applied in ITU-T protocols like H.323, which is used to 1151 establish communication sessions similar to SIP. For H.323 a 1152 security framework exists, which is defined in H.235. Within this 1153 framework H.235.7 [H.235.7] describes the usage of MIKEY and SRTP in 1154 the context of H.323. In contrast to SIP H.323 uses ASN.1 (Abstract 1155 Syntax Notation). Thus there is no need to encode the MIKEY 1156 container as base64. Within H.323 the MIKEY container is binary 1157 encoded. 1159 7. MIKEY alternatives for SRTP security parameter negotiation 1161 Besides MIKEY there exists several approaches to handle the security 1162 parameter establishment. This is due to the fact, that some 1163 limitations in certain scenarios have been seen. Examples are early 1164 media and forking situations as described in Section 5. The 1165 following list provides a short summary about possible alternatives: 1167 o sdescription - [RFC4568] describes a key management scheme, which 1168 uses SDP for transport and completely relies on underlying 1169 protocol security. For transport the documents defines a SDP 1170 attribute transmitting all necessary SRTP parameter in clear. For 1171 security it references TLS and S/MIME. In contrast to MIKEY the 1172 SRTP parameter in the initiator to responder direction is actually 1173 sent in the message from the initiator to the responder rather 1174 than vice versa. This may lead to problems in early media 1175 scenarios. 1177 o sdescription with early media support - 1178 [I-D.wing-mmusic-sdes-early-media] enhances the above scheme with 1179 the possibility to also be usable in early media scenarios, when 1180 security preconditions is not used. 1182 o Encrypted Key Transport for Secure RTP - [I-D.mcgrew-srtp-ekt] is 1183 an extension to SRTP that provides for the secure transport of 1184 SRTP master keys, Rollover Counters, and other information, within 1185 SRTCP. This facility enables SRTP to work for decentralized 1186 conferences with minimal control, and to handle situations caused 1187 by SIP forking and early media. It may also be used in 1188 conjunction with MIKEY. 1190 o Diffie Hellman support in SDP - [I-D.baugher-mmusic-sdp-dh] 1191 defines a new SDP attribute for exchanging Diffie-Hellman public 1192 keys. The attribute is an SDP session-level attribute for 1193 describing DH keys, and there is a new media-level parameter for 1194 describing public keying material for SRTP key generation. 1196 o DTLS-SRTP describing SRTP extensions for DTLS - 1197 [I-D.ietf-avt-dtls-srtp] describes a method of using DTLS key 1198 management for SRTP by using a new extension that indicates that 1199 SRTP is to be used for data protection, and which establishes SRTP 1200 keys. 1202 o ZRTP - [I-D.zimmermann-avt-zrtp] This document defines ZRTP as RTP 1203 header extensions for a Diffie-Hellman exchange to agree on a 1204 session key and parameters for establishing SRTP sessions. The 1205 ZRTP protocol is completely self-contained in RTP and does not 1206 require support in the signaling protocol or assume a PKI. 1208 There has been a longer discussion regarding a preferred key 1209 management approach in the IETF coping with the different scenarios 1210 and requirements continuously sorting out key management approaches. 1211 During IETF 68 three options were considered: MIKEY in an updated 1212 version (referred to as MIKEYv2); ZRTP; and DTLS-SRTP. The potential 1213 key management protocol for the standards track for media security 1214 was voted in favor of DTLS-SRTP. Thus, the reader is pointed to the 1215 appropriate resources for further information on DTLS-SRTP 1216 [I-D.ietf-avt-dtls-srtp]. Note that MIKEY has already been deployed 1217 for setting up SRTP security context and is also targeted for use in 1218 MBMS applications. 1220 8. Summary of MIKEY related IANA Registrations 1222 For MIKEY and the extensions to MIKEY IANA registrations have been 1223 made. Here only a link to the appropriate IANA registration is 1224 provided to avoid inconsistencies. The IANA registrations for MIKEY 1225 payloads can be found under 1226 http://www.iana.org/assignments/mikey-payloads These registrations 1227 comprise the MIKEY base registrations as well as registrations made 1228 by MIKEY extensions regarding the payload. 1230 The IANA registrations for MIKEY port numbers can be found under 1231 http://www.iana.org/assignments/port-numbers (search for MIKEY). 1233 9. Security Considerations 1235 This document does not define extensions to existing protocols. It 1236 rather provides an overview about the set of MIKEY modes and 1237 available extensions and provides information about the applicability 1238 of the different modes in different scenarios to support the decision 1239 making for network architects regarding the appropriate MIKEY scheme 1240 or extension to be used in a dedicated target scenario. Choosing 1241 between the different schemes described in this document strongly 1242 influences the security of the target system as the different schemes 1243 provide different level of security and also require different 1244 infrastructure support. 1246 As this document bases on the MIKEY base specification as well as the 1247 different specifications of the extensions the reader is referred to 1248 the original documents for the specific security considerations. 1250 10. IANA Considerations 1252 This document does not require any IANA registration. 1254 11. Acknowledgments 1256 The authors would like to thank Lakshminath Dondeti for his document 1257 reviews and for his guidance. 1259 12. References 1261 12.1. Normative References 1263 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 1264 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 1265 August 2004. 1267 12.2. Informative References 1269 [H.235.7] ""ITU-T Recommendation H.235.7: Usage of the MIKEY Key 1270 Management Protocol for the Secure Real Time Transport 1271 Protocol (SRTP) within H.235"", 2005. 1273 [I-D.baugher-mmusic-sdp-dh] 1274 Baugher, M. and D. McGrew, "Diffie-Hellman Exchanges for 1275 Multimedia Sessions", draft-baugher-mmusic-sdp-dh-00 (work 1276 in progress), February 2006. 1278 [I-D.ietf-avt-dtls-srtp] 1279 McGrew, D. and E. Rescorla, "Datagram Transport Layer 1280 Security (DTLS) Extension to Establish Keys for Secure 1281 Real-time Transport Protocol (SRTP)", 1282 draft-ietf-avt-dtls-srtp-02 (work in progress), 1283 February 2008. 1285 [I-D.ietf-msec-mikey-ecc] 1286 Milne, A., "ECC Algorithms for MIKEY", 1287 draft-ietf-msec-mikey-ecc-03 (work in progress), 1288 June 2007. 1290 [I-D.ietf-sip-media-security-requirements] 1291 Wing, D., Fries, S., Tschofenig, H., and F. Audet, 1292 "Requirements and Analysis of Media Security Management 1293 Protocols", draft-ietf-sip-media-security-requirements-04 1294 (work in progress), March 2008. 1296 [I-D.mcgrew-srtp-ekt] 1297 McGrew, D., "Encrypted Key Transport for Secure RTP", 1298 draft-mcgrew-srtp-ekt-03 (work in progress), July 2007. 1300 [I-D.wing-mmusic-sdes-early-media] 1301 Raymond, R. and D. Wing, "Security Descriptions Extension 1302 for Early Media", draft-wing-mmusic-sdes-early-media-00 1303 (work in progress), October 2005. 1305 [I-D.zimmermann-avt-zrtp] 1306 Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media 1307 Path Key Agreement for Secure RTP", 1308 draft-zimmermann-avt-zrtp-06 (work in progress), 1309 March 2008. 1311 [ISO_sec_time] 1312 ""ISO/IEC 18014 Information technology - Security 1313 techniques - Time-stamping services, Part 1-3."", 2002. 1315 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 1316 Specification, Implementation", RFC 1305, March 1992. 1318 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1319 Requirement Levels", BCP 14, RFC 2119, March 1997. 1321 [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", 1322 RFC 2412, November 1998. 1324 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1325 A., Peterson, J., Sparks, R., Handley, M., and E. 1326 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1327 June 2002. 1329 [RFC3525] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, 1330 "Gateway Control Protocol Version 1", RFC 3525, June 2003. 1332 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1333 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1334 RFC 3711, March 2004. 1336 [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. 1337 Briscoe, "Timed Efficient Stream Loss-Tolerant 1338 Authentication (TESLA): Multicast Source Authentication 1339 Transform Introduction", RFC 4082, June 2005. 1341 [RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient 1342 Stream Loss-Tolerant Authentication (TESLA) in the Secure 1343 Real-time Transport Protocol (SRTP)", RFC 4383, 1344 February 2006. 1346 [RFC4442] Fries, S. and H. Tschofenig, "Bootstrapping Timed 1347 Efficient Stream Loss-Tolerant Authentication (TESLA)", 1348 RFC 4442, March 2006. 1350 [RFC4563] Carrara, E., Lehtovirta, V., and K. Norrman, "The Key ID 1351 Information Type for the General Extension Payload in 1352 Multimedia Internet KEYing (MIKEY)", RFC 4563, June 2006. 1354 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1355 Description Protocol", RFC 4566, July 2006. 1357 [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 1358 Carrara, "Key Management Extensions for Session 1359 Description Protocol (SDP) and Real Time Streaming 1360 Protocol (RTSP)", RFC 4567, July 2006. 1362 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 1363 Description Protocol (SDP) Security Descriptions for Media 1364 Streams", RFC 4568, July 2006. 1366 [RFC4597] Even, R. and N. Ismail, "Conferencing Scenarios", 1367 RFC 4597, August 2006. 1369 [RFC4650] Euchner, M., "HMAC-Authenticated Diffie-Hellman for 1370 Multimedia Internet KEYing (MIKEY)", RFC 4650, 1371 September 2006. 1373 [RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY- 1374 RSA-R: An Additional Mode of Key Distribution in 1375 Multimedia Internet KEYing (MIKEY)", RFC 4738, 1376 November 2006. 1378 [RFC4771] Lehtovirta, V., Naslund, M., and K. Norrman, "Integrity 1379 Transform Carrying Roll-Over Counter for the Secure Real- 1380 time Transport Protocol (SRTP)", RFC 4771, January 2007. 1382 [RFC4909] Dondeti, L., Castleford, D., and F. Hartung, "Multimedia 1383 Internet KEYing (MIKEY) General Extension Payload for Open 1384 Mobile Alliance BCAST LTKM/STKM Transport", RFC 4909, 1385 June 2007. 1387 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1388 RFC 4949, August 2007. 1390 [RFC5027] Andreasen, F. and D. Wing, "Security Preconditions for 1391 Session Description Protocol (SDP) Media Streams", 1392 RFC 5027, October 2007. 1394 [SAML_overview] 1395 Huges, J. and E. Maler, ""Security Assertion Markup 1396 Language (SAML) 2.0 Technical Overview, Working Draft"", 1397 2005. 1399 Authors' Addresses 1401 Steffen Fries 1402 Siemens 1403 Otto-Hahn-Ring 6 1404 Munich, Bavaria 81739 1405 Germany 1407 Email: steffen.fries@siemens.com 1409 Dragan Ignjatic 1410 Polycom 1411 1000 W. 14th Street 1412 North Vancouver, BC V7P 3P3 1413 Canada 1415 Email: dignjatic@polycom.com 1417 Full Copyright Statement 1419 Copyright (C) The IETF Trust (2008). 1421 This document is subject to the rights, licenses and restrictions 1422 contained in BCP 78, and except as set forth therein, the authors 1423 retain all their rights. 1425 This document and the information contained herein are provided on an 1426 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1427 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1428 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1429 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1430 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1431 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1433 Intellectual Property 1435 The IETF takes no position regarding the validity or scope of any 1436 Intellectual Property Rights or other rights that might be claimed to 1437 pertain to the implementation or use of the technology described in 1438 this document or the extent to which any license under such rights 1439 might or might not be available; nor does it represent that it has 1440 made any independent effort to identify any such rights. Information 1441 on the procedures with respect to rights in RFC documents can be 1442 found in BCP 78 and BCP 79. 1444 Copies of IPR disclosures made to the IETF Secretariat and any 1445 assurances of licenses to be made available, or the result of an 1446 attempt made to obtain a general license or permission for the use of 1447 such proprietary rights by implementers or users of this 1448 specification can be obtained from the IETF on-line IPR repository at 1449 http://www.ietf.org/ipr. 1451 The IETF invites any interested party to bring to its attention any 1452 copyrights, patents or patent applications, or other proprietary 1453 rights that may cover technology that may be required to implement 1454 this standard. Please address the information to the IETF at 1455 ietf-ipr@ietf.org.