MSEC S. Fries Internet-Draft Siemens Expires: November 17, 2006 D. Ignjatic Polycom May 16, 2006 On the applicability of various MIKEY modes and extensions draft-ietf-msec-mikey-applicability-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 17, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Multimedia Internet Keying - MIKEY - is a key management scheme that can be used for real-time applications. In particular, it has been defined focusing on the support of the Secure Real-time Transport Protocol. MIKEY itself defines four key distribution schemes. Moreover, it is defined to allow extensions of the protocol. As MIKEY becomes more and more accepted, extensions to the base protocol arose, especially in terms of additional key distribution schemes, Fries & Ignjatic Expires November 17, 2006 [Page 1] Internet-Draft MIKEY modes applicability May 2006 but also in terms of payload enhancements. This document provides an overview about MIKEY in general as well as the existing extensions in MIKEY, which have been defined or are in the process of definition. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 4 3. MIKEY Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Symmetric key distribution . . . . . . . . . . . . . . . . 6 3.2. Asymmetric key distribution . . . . . . . . . . . . . . . 6 3.3. Diffie-Hellman key agreement protected with digital signatures . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4. Unprotected key distribution . . . . . . . . . . . . . . . 8 4. MIKEY Extensions . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Diffie-Hellman key agreement protected with pre-shared secrets . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. SAML assisted DH-key agreement . . . . . . . . . . . . . . 9 4.3. Asymmetric key distribution with in-band certificate exchange . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.4. ECC algorithms support . . . . . . . . . . . . . . . . . . 11 4.4.1. Elliptic Curve Integrated Encryption Scheme application in MIKEY . . . . . . . . . . . . . . . . . 12 4.4.2. Elliptic Curve Menezes-Qu-Vanstone Scheme application in MIKEY . . . . . . . . . . . . . . . . . 12 4.5. New Payload for bootstrapping TESLA . . . . . . . . . . . 12 4.6. New Key ID information type . . . . . . . . . . . . . . . 13 4.7. Supporting Integrity Transform carrying the Rollover Counter . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.8. OMA BCAST MIKEY General Extension Payload Specification . 14 5. Selection and interworking of MIKEY modes . . . . . . . . . . 14 5.1. MIKEY and Early Media . . . . . . . . . . . . . . . . . . 15 5.2. MIKEY and Forking . . . . . . . . . . . . . . . . . . . . 16 5.3. MIKEY and Call Transfer . . . . . . . . . . . . . . . . . 16 6. Transport of MIKEY messages . . . . . . . . . . . . . . . . . 16 7. Summary of MIKEY related IANA Registrations . . . . . . . . . 17 8. MIKEY alternatives for SRTP security parameter negotiation . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 12.1. Normative References . . . . . . . . . . . . . . . . . . . 19 12.2. Informative References . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . . . 23 Fries & Ignjatic Expires November 17, 2006 [Page 2] Internet-Draft MIKEY modes applicability May 2006 1. Introduction Key distribution describes the process of delivering cryptographic keys to the required parties. MIKEY [RFC3830], the Multimedia Internet Keying, has been defined focusing on support for the establishment of security context for the Secure Real-time Transport Protocol [RFC3711]. Note that MIKEY is not restricted to be used for SRTP only, as it features a generic approach and allows for extensions to the key distribution schemes, but also for the payload associated with the protocol using the distributed security context. MIKEY defines four key distribution schemes as there are: o Symmetric key distribution o Asymmetric key distribution o Diffie-Hellman key agreement protected by digital signatures o Unprotected key distribution There have been scenarios where none of the above schemes fits perfectly, so extensions have been defined. These extensions comprise new key distribution schemes, algorithm enhancements, new payload definitions supporting other protocols than SRTP. The key distribution scheme extensions are defined in the following documents: o Diffie-Hellman key agreement protected by symmetric pre-shared keys as defined in [I-D.ietf-msec-mikey-dhhmac] o SAML assisted Diffie-Hellman key agreement as defined [Reference to draft-moskowitz-MIKEY-SAML-DH] o Asymmetric key distribution (based on asymmetric encryption) with in-band certificate provision as defined in [I-D.ietf-msec-mikey- rsa-r] Algorithm extensions are defined in the following document: o ECC algorithms for MIKEY as defined in [I-D.ietf-msec-mikey-ecc] Payload extensions are defined in the following documents: o Bootstrapping TESLA, defining a new payload for the Timed Efficient Stream Loss-tolerant Authentication protocol [RFC4082] as defined in [RFC4442] o The Key ID information type for the general extension payload as defined in [I-D.ietf-msec-newtype-keyid] o Integrity Transform Carrying Roll-over Counter for SRTP, as defined in [I-D.lehtovirta-srtp-rcc] Fries & Ignjatic Expires November 17, 2006 [Page 3] Internet-Draft MIKEY modes applicability May 2006 o OMA BCAST MIKEY General Extension Payload Specification, as defined in [I-D.dondeti-msec-mikey-genext-oma] This document provides an overview about MIKEY and the relations to the different extensions to provide a framework when using MIKEY. It is intended as additional source of information for developers or architects to provide more insight in use case scenarios and motivations as well as advantages and disadvantages for the different key distribution schemes. This document may be enhanced as soon as new extensions to MIKEY appear. It has been seen that enhancing the overview document requires much less effort than enhancing an established standard. 2. Terminology and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. The following definitions have mostly been taken from [RFC3830]: (Data) Security Protocol: the security protocol used to protect the actual data traffic. Examples of security protocols are IPsec and SRTP. Data Security Association (Data SA): information for the security protocol, including a TEK and a set of parameters/policies. Crypto Session (CS): uni- or bi-directional data stream(s), protected by a single instance of a security protocol. Crypto Session Bundle (CSB): collection of one or more Crypto Sessions, which can have common TGKs (see below) and security parameters. Crypto Session ID: unique identifier for the CS within a CSB. Crypto Session Bundle ID (CSB ID): unique identifier for the CSB. TEK Generation Key (TGK): a bit-string agreed upon by two or more parties, associated with CSB. From the TGK, Traffic-encrypting Keys can then be generated without needing further communication. Traffic-Encrypting Key (TEK): the key used by the security protocol to protect the CS (this key may be used directly by the security protocol or may be used to derive further keys depending on the security protocol). The TEKs are derived from the CSB's TGK. Fries & Ignjatic Expires November 17, 2006 [Page 4] Internet-Draft MIKEY modes applicability May 2006 TGK re-keying: the process of re-negotiating/updating the TGK (and consequently future TEK(s)). Initiator: the initiator of the key management protocol, not necessarily the initiator of the communication. Responder: the responder in the key management protocol. Salting key: a random or pseudo-random (see [RAND, HAC]) string used to protect against some off-line pre-computation attacks on the underlying security protocol. HDR: denotes the protocol header PRF(k,x): a keyed pseudo-random function E(k,m): encryption of m with the key k RAND: Random value T: Timestamp CERTx: the certificate of x SIGNx: the signature from x using the private key of x PKx: the public key of x IDx: the identity of x [] an optional piece of information {} denotes zero or more occurrences || concatenation | OR (selection operator) ^ exponentiation XOR exclusive or 3. MIKEY Overview This section will provide an overview about the MIKEY base document. The focus lies here on the key distribution schemes as well as the discussion about advantages and disadvantages of the different Fries & Ignjatic Expires November 17, 2006 [Page 5] Internet-Draft MIKEY modes applicability May 2006 schemes. Note that the MIKEY key distribution schemes rely on loosely synchronized clocks. Thus should be realized by a secure network clock synchronization protocol. MIKEY recommends for this the ISO time synchronization protocol [ISO_sec_time]. The format applied to the timestamps submitted in the MIKEY have to match the NTP format described in [RFC1305]. In other cases, such as of a SIP endpoint clock synchronization by deriving time from a trusted outbound proxy may be appropriate. 3.1. Symmetric key distribution This option of the key management uses a pre-shared secret key to derive key material for integrity protection and encryption to protect the actual exchange of key material. Note that the pre- shared secret is agreed upon before the session, e.g., by out-of-band means. The response message is optional and may be used for mutual authentication or error signaling. Initiator Responder I_MESSAGE = HDR, T, RAND, [IDi],[IDr], {SP}, KEMAC ---> R_MESSAGE = [<---] HDR, T, [IDr], V The advantages of this approach lay in the fact that there is no dependency on a PKI (Public Key Infrastructure), the solution consumes low bandwidth and enables high performance, and is all in all a simple straightforward master key provisioning. The disadvantages are that no perfect forward secrecy is provided and key generation is just performed by the initiator. Furthermore, the approach is not scaleable to larger configurations but acceptable in small-sized groups. Note, according to [RFC3830] this option is mandatory to implement. 3.2. Asymmetric key distribution Using the asymmetric option of the key management, the initiator generates the key material to be transmitted and sends it encrypted with the responder's public key. Additionally a so-called envelope key is transmitted, encrypted with the receiver's public key. The envelope key env-key, which is a random number, is used to derive the auth-key and the enc-key. Moreover, the envelope key is used to protect the signaling message and may be used as a pre-shared key to establish further crypto sessions. The response message is optional and may be used for mutual authentication or error signaling. Fries & Ignjatic Expires November 17, 2006 [Page 6] Internet-Draft MIKEY modes applicability May 2006 Initiator Responder I_MESSAGE = HDR, T, RAND, [IDi|CERTi], [IDr], {SP}, KEMAC, [CHASH], PKE, SIGNi ---> R_MESSAGE = [<---] HDR, T, [IDr], V An advantage of this approach are that the usage of self-signed certificates can avoid PKI. Note that using self-signed certificates may result in limited scalability and complex provisioning. The disadvantages comprise the necessity of a PKI for fully scalability, the performance of the key generation just by the initiator, and no provision of perfect forward secrecy. Furthermore, the verification of certificates may not be done in real-time. This could be the case in scenarios where the revocation status of certificates is checked through a further component. Note, according to [RFC3830] this option is mandatory to implement. 3.3. Diffie-Hellman key agreement protected with digital signatures The Diffie-Hellman option of the key management enables a shared secret establishment between initiator and responder in a way where both parties contribute to the shared secret. The Diffie-Hellman key agreement is authenticated (and integrity protected) using digital signatures. Initiator Responder I_MESSAGE = HDR, T, RAND, [IDi|CERTi], [IDr], {SP}, DHi, SIGNi ---> R_MESSAGE = <--- HDR, T, [IDr|CERTr], IDi, DHr, DHi, SIGNr [RFC3830] does not mandate any specific asymmetric algorithm for the signature calculation. The algorithm used for signature or public key encryption is rather defined by, and dependent on the certificate used. Besides the use of X.509v3 certificates it is mandatory to support the Diffie-Hellmann group "OAKLEY5" [RFC2412]. The advantages of this approach are a fair, mutual key agreement, perfect forward secrecy, and the option to use self-signed certificates to avoid PKI (would result in limited scalability and more complex provisioning). Negatively to remark is that this approach just scales to point-to-point groups and depends on PKI for full Fries & Ignjatic Expires November 17, 2006 [Page 7] Internet-Draft MIKEY modes applicability May 2006 scalability. Moreover, it has a limited performance since expensive, non-real time certificate validation has to be done. 3.4. Unprotected key distribution MIKEY also supports a mode to provide a key in an unprotected manner. This is based on the pre-shared key option depicted in Section 3.1 and may be compared with the plain approach in sdescriptions [I-D.ietf-mmusic-sdescriptions]. This MIKEY scheme is based on the symmetric key distribution approach described in Section 3.1, but is used with the NULL encryption and the NULL authentication algorithm. It completely relies on the security of the underlying layer, e.g., provided by TLS This option should be used with caution as it does not protect the key management. 4. MIKEY Extensions This section will provide an overview about the MIKEY extensions for key distribution schemes, crypto algorithms and payloads which have been defined in several documents. 4.1. Diffie-Hellman key agreement protected with pre-shared secrets This is an additional option which has been defined in [I-D.ietf- msec-mikey-dhhmac]. In contrast to the method described in Section 3.3 here the Diffie-Hellmann key agreement is authenticated (and integrity protected) using a pre-shared secret and keyed hash function. Initiator Responder I_MESSAGE = 3D HDR, T, RAND, [IDi], IDr, {SP}, DHi, KEMAC ---> R_MESSAGE = <--- 3D HDR, T,[IDr], IDi, DHr, DHi, KEMAC TGK =3D g^(xi * yi) TGK =3D g^(xi * yi) For the integrity protection of the Diffie-Hellman key agreement [I-D.ietf-msec-mikey-dhhmac] mandates the use of HMAC SHA-1. Regarding Diffie-Hellman groups [RFC3830] is referenced. Thus, it is mandatory to support the Diffie-Hellman group "OAKLEY5" [RFC2412]. This option has also several advantages, as there are the fair mutual key agreement, the perfect forward secrecy, and no dependency on a Fries & Ignjatic Expires November 17, 2006 [Page 8] Internet-Draft MIKEY modes applicability May 2006 PKI and PKI standards. Moreover, this scheme has a sound performance and reduced bandwidth requirements and provides a simple and straightforward master key provisioning. The scalability of this approach just to point-to-point groups is a disadvantage. This mode of operation provides an efficient scheme in deployments where there is a central trusted server that is provisioned with shared secrets for many clients. Such setups could for example be enterprise PBXs, service provider proxies, etc. 4.2. SAML assisted DH-key agreement This document [Reference to draft-moskowitz-MIKEY-SAML-DH] is targeted to fulfill the general requirements on key management approaches repeated here: 1. Mutual authentication of involved parties 2. Both parties involved contribute to the session key generation 3. Provide perfect forward secrecy 4. Support distribution of group session keys 5. Provide liveliness tests when involved parties do not have a reliable clock 6. Support of limited parties involved To fullfill all of the requirements, the document proposes the use of a classic Diffie-Hellman key agreement protocol for key establishment in conjunction with UA's SIP server signed element authenticating the Diffie-Hellman key and the ID using the SAML (Security Association Markup Language, [SAML_overview]) approach. Here the client's public Diffie-Hellman-credentials are signed by the server to form a SAML assertion [CRED], which may be used for later sessions with other clients. This assertion needs at least to convey the ID, public DH key, expiry, and the signature from the server. This provides the involved clients with mutual authentication and message integrity of the key management messages exchanged. Initiator Responder I_MESSAGE = HDR, T, RAND1, [CREDi], IDr, {SP} ---> R_MESSAGE = <--- HDR, T, [CREDr], IDi, DHr, RAND2, (SP) TGK = HMACx(RAND1|RAND2), where x = g^(xi * xr). Additionally the document proposes a second roundtrip to avoid the Fries & Ignjatic Expires November 17, 2006 [Page 9] Internet-Draft MIKEY modes applicability May 2006 dependence on synchronized clocks and provide liveliness checks. This is achieved by exchanging nonces, protected with the session key. This second roundtrip can also be used for distribution of group keys or for the leverage of a weak DH key for a stronger session key. The trigger for the second round trip would be handled via SP, the Security Policy communicated via MIKEY. Initiator Responder I_MESSAGE = HDR, SIGN(ENC(RAND3)) ---> R_MESSAGE = <--- SIGN(ENC(RAND4)) Note if group keys are to be provided RAND would be substituted by that group key. With the second roundtrip, this approach also provides an option for all of the other key distribution methods, when liveliness checks are needed. The drawback of the second roundtrip is that these messages need to be integrated into the call flow of the signaling protocol. In straight forward call one roundtrip may be enough to setup a session. Thus this second roundtrip would require additional messages to be exchanged. 4.3. Asymmetric key distribution with in-band certificate exchange This is an additional option which has been defined in [I-D.ietf- msec-mikey-rsa-r]. It describes the asymmetric key distribution with optional in-band certificate exchange. Initiator Responder I_MESSAGE = HDR, T, [IDi|CERTi], [IDr], {SP}, [RAND], SIGNi ---> R_MESSAGE = <--- HDR, [GenExt(CSB-ID)], T, RAND, [IDr|CERTr], [SP], KEMAC, SIGNr This option has some advantages compared to the asymmetric key distribution stated in Section 3.2. Here, the sender and receiver do not need to know the certificate of the other peer in advance as it may be sent in the MIKEY initiator message. Thus, the receiver of this message can utilize the received key material to encrypt the Fries & Ignjatic Expires November 17, 2006 [Page 10] Internet-Draft MIKEY modes applicability May 2006 session parameter and send them back as part of the MIKEY response message. The certificate check may be done depending on the signing authority. If the certificate is signed by an publicly accepted authority the certificate validation is done on the common base. In the other case additional steps may be necessary. The disadvantage is that no perfect forward secrecy is provided. This mode is meant to provide a low cost solution when PKI is present and/or required. Specifically in SIP, session invitations can be retargeted or forked. MIKEY modes that require the Initiator to target a single well known Responder may be impractical here as they may require multiple roundtrips to do key negotiation. By allowing the Responder to generate secret material used for key derivation this mode allows for an efficient key delivery scheme. Note that the Initiator can contribute to the material the key is derived from through CSB-ID and RAND payloads in unicast use cases. This mode is also useful in multicast scenarios where multiple clients are contacting a known server and are downloading the key. Server workload is significantly reduced in these scenarios compared to MIKEY in public key mode. Examples of deployments where this mode can be used are enterprises with PKI, service provider setups where the service provider decides to provision certificates to its users, etc. 4.4. ECC algorithms support [I-D.ietf-msec-mikey-ecc] proposes extensions to the authentication, encryption and digital signature methods described for use in MIKEY, employing elliptic-curve cryptography (ECC). These extensions are defined to align MIKEY with other ECC implementations and standards. The motivation for supporting ECC within the MIKEY stems from the following advantages: o ECC support is generally added to security protocols o ECC support requires considerably smaller keys by keeping the same security level compared to other asymmetric techniques (like RSA). Elliptic curve algorithms are capable of providing security consistent with AES keys of 128, 192, and 256 bits without extensive growth in asymmetric key sizes. o As stated in [I-D.ietf-msec-mikey-ecc] implementations have shown that elliptic curve algorithms can significantly improve performance and security-per-bit over other recommended algorithms. These advantages make the usage of ECC especially interesting for embedded devices, which may have only limited performance and storage capabilities. Fries & Ignjatic Expires November 17, 2006 [Page 11] Internet-Draft MIKEY modes applicability May 2006 [I-D.ietf-msec-mikey-ecc] proposes several ECC based mechanisms to enhance the MIKEY key distribution schemes, as there are: o Use of ECC methods with public-key encryption (MIKEY-RSA); ECDSA o Use of Elliptic Curve Integrated Encryption Scheme (MIKEY-ECIES) o Use of ECC methods with Diffie-Hellman key exchange (MIKEY-DHSIGN) o Use of Elliptic Curve Menezes-Qu-Vanstone (MIKEY-MQV) The following subsections will provide more detailed information about the message exchanges for MIKEY-ECIES and MIKEY-MQV. 4.4.1. Elliptic Curve Integrated Encryption Scheme application in MIKEY The following figure shows the message exchange for the MIKEY-ECIES scheme: Initiator Responder I_MESSAGE = HDR, T, RAND, [IDi|CERTi], [IDr], {SP}, ECCPT, KEMAC, [CHASH], SIGNi ---> R_MESSAGE = [<---] HDR, T, [IDr], V 4.4.2. Elliptic Curve Menezes-Qu-Vanstone Scheme application in MIKEY The following figure shows the message exchange for the MIKEY-MQV scheme: Initiator Responder I_MESSAGE = HDR, T, RAND, [IDi|CERTi], [IDr], {SP}, ECCPT, KEMAC, [CHASH], SIGNi ---> R_MESSAGE = [<---] HDR, T, [IDr], V 4.5. New Payload for bootstrapping TESLA TESLA [RFC4082] is a protocol for providing source authentication in multicast scenarios. TESLA is an efficient protocol with low communication and computation overhead, which scales to large numbers of receivers, and also tolerates packet loss. TESLA is based on loose time synchronization between the sender and the receivers. Fries & Ignjatic Expires November 17, 2006 [Page 12] Internet-Draft MIKEY modes applicability May 2006 Source authentication is realized in TESLA by using Message Authentication Code (MAC) chaining. The use of TESLA within the Secure Real-time Transport Protocol (SRTP) has been published in [RFC4383] targeting multicast authentication in scenarios, where SRTP is applied to protect the multimedia data. This solution assumes that TESLA parameters are made available by out-of-band mechanisms. [RFC4442] specifies payloads for MIKEY to bootstrap TESLA for source authentication of secure group communications using SRTP. TESLA may be bootstrapped using one of the MIKEY key management approaches described above sent via unicast, multicast or broadcast. This approach provides the necessary parameter payload extensions for the usage of TESLA in SRTP but is not limited to this. 4.6. New Key ID information type This extension specifies a new Type (the Key ID Information Type) for the General Extension Payload. This is used in, e.g., the Multimedia Broadcast/Multicast Service (MBMS) specified in the 3rd Generation Partnership Project (3GPP). MBMS requires the use of MIKEY to convey the keys and related security parameters needed to secure the multimedia that is multicast or broadcast. One of the requirements that MBMS puts on security is the possibility to perform frequent updates of the keys. The rationale behind this is that it should be inconvenient for subscribers to publish the decryption keys enabling non-subscribers to view the content. To implement this, MBMS uses a three level key management, to distribute group keys to the clients, and be able to re-key by pushing down a new group key. MBMS has the need to identify, which types of key are involved in the MIKEY message, and their identity. [I-D.ietf-msec-newtype-keyid] specifies a new Type for the General Extension Payload in MIKEY, to identify the type and identity of involved keys. 4.7. Supporting Integrity Transform carrying the Rollover Counter The document [I-D.lehtovirta-srtp-rcc] defines a new integrity transform for SRTP [RFC3711] providing the option to also transmit the Roll Over Counter (ROC) as part of dedicated SRTP packets. This extension has been defined for the use in the 3GPP multicast/ broadcast service. While the communicating parties did agree on a starting ROC, in some cases the receiver will not be able to synchronize his ROC with the one used by the sender even if it is signaled to him out of band. Here the new extension provides the possibility for the receiver to re-synchronize to the sender's ROC. To signal the use of the new integrity transform new definitions for Fries & Ignjatic Expires November 17, 2006 [Page 13] Internet-Draft MIKEY modes applicability May 2006 certain MIKEY payloads need to be made. These MIKEY new definition comprise the integrity transform s and new integrity transform parameter. Moreover, the document specifies integrity parameter, to enable the usage of different integrity transforms for SRTP and SRTCP. 4.8. OMA BCAST MIKEY General Extension Payload Specification The document [I-D.dondeti-msec-mikey-genext-oma] specifies a new general extension payload type for use in the Open Mobile Alliance's (OMA) Browser and Content Broadcast (BCAST) group. OMA BCAST's service and content protection specification uses short term key message and long term key message payloads that in certain broadcast distribution systems are carried in MIKEY. The document defines the payloads for both, short term and long term key messages as part of the general extension payload. Note, that only a parameter description is included, but no key information. 5. Selection and interworking of MIKEY modes While MIKEY and its extensions provide plenty of choice in terms of modes of operation an implementation may choose to simplify its behavior. This can be achieved by operating in a single mode of operation when in Initiator's role. Where PKI is available and/or required an implementation may choose for example to start all sessions in RSA-R mode but it would be trivial for it to act as a Responder in public key mode. If envelope keys are cached it can then also choose to do re-keying in shared key mode. In general, modes of operation where the Initiator generates keying material are useful when two peers are aware of each other before the MIKEY communication takes place. If an implementation chooses not to operate in shared key mode its behavior may be identical to a peer that does but lacks the shared key. Similarly, if a peer chooses not to operate in the public key mode it may reject the certificate of the Initiator. The same applies to peers that choose to operate in one of the DH modes exclusively. Forward MIKEY modes like public key or shared key mode when used in SIP/SDP may lead to complications in some calls scenarios, for example forking scenarios key derivation material gets distributed to multiple parties. As mentioned earlier this may be impractical as some of the destinations may not have the resources to validate the message and may cause the initiator to drop the session invitation. Even in the case all parties involved have all the prerequisites for interpreting the MIKEY message received there is a possible problem with multiple responders starting media sessions using the same key. While the SSRCs will be different in most of the cases they are only Fries & Ignjatic Expires November 17, 2006 [Page 14] Internet-Draft MIKEY modes applicability May 2006 sixteen bits long and there is a high probability of a two time pad problem. As suggested earlier forward modes are most useful when the two peers are aware of each other before the communication takes place (as is the case in key renewal scenarios when costly public key operations can be avoided by using the envelope key). Choosing between the different modes of MIKEY depends strongly on the use case. This document may discuss further scenarios to argue for preferred modes. The following call scenarios provide a list of potential call scenarios and are matter of discussion: o Early Media o Forking o Call Transfer 5.1. MIKEY and Early Media In early media scenarios, SRTP data may be received before the answer over the SIP signaling arrives. The two MIKEY modes, which only require one message to be transported (Section 3.1 and Section 3.2), work nicely in early media situations, as both, sender and receiver have all the necessary parameters in place before actually sending/ receiving encrypted data. The other modes, featuring either Diffie- Hellman key agreement (Section 3.3, Section 4.1, and Section 4.2) or the enhanced asymmetric variant (Section 4.3) suffer from the requirements that the initiator has to wait for the response before being able to decrypt the incoming SRTP media. In fact, even if early media is not used, in other words if media is not sent before the SDP answer a similar problem may arise from the fact that SIP/SDP signaling has to traverse multiple proxies on its way back and media may arrive before the SDP answer. It is expected that this delay would be significantly shorter than in the case of early media though. It is worth mentioning here that security descriptions ([I-D.ietf- mmusic-sdescriptions]) have the same problem as the initiating end needs the SDP answer before it can start decrypting SRTP media. To cope with the early media problem there are further approaches to describe security preconditions [I-D.ietf-mmusic- securityprecondition], i.e., certain preconditions need to be met to enable voice data encryption. One example is for instance that a scenario where a provisional response, containing the required MIKEY parameter, is sent before encrypted media is processed. Fries & Ignjatic Expires November 17, 2006 [Page 15] Internet-Draft MIKEY modes applicability May 2006 5.2. MIKEY and Forking In SIP forking scenarios a SIP proxy server sends an INVITE request to more than one location. This means that also the MIKEY payload, which is part of the SDP is sent to several (different) locations. MIKEY modes supporting signatures may be used in forking scenarios (Section 3.3 and Section 4.3) as here the receiver can validate the signature. There are limitations with the symmetric key encryption as well as the asymmetric key encryption modes (Section 3.1 and Section 3.2). This is due to the fact that in symmetric encryption the recipient needs to possess the symmetric key before handling the MIKEY data. For asymmetric MIKEY modes, if the sender is aware of the forking he may not know in advance to which location the INVITE is forked and thus may not use the right receiver certificate to encrypt the MIKEY envelope key. Note, the sender may include several MIKEY containers into the same INVITE message to cope with forking, but this requires the knowledge of all forking targets in advance and also requires the possession of the target certificates. It is out of the scope of MIKEY to specify behavior in such a case. DH modes or the Section 4.3 do not have this problem. In scenarios, where the sender is not aware of forking, only the intended receiver is able to decrypt the MIKEY container. If forking is combined with early media the situation gets aggravated. If MIKEY modes requiring full roundtrip are used, like the signed Diffie-Hellman, multiple responses may overload the end device. An example is forking to 30 destinations (group pickup), while MIKEY is used with the signed Diffie-Hellman mode together with security preconditions. Here, every target would answer with a provisional response, leading to 30 signature validations and Diffie- Hellman calculations at the senders site. This may lead to a prolonged media setup delay. 5.3. MIKEY and Call Transfer In a SIP environment MIKEY exchange is tied to SDP offer/answer and irrespective of the implementation model used for call transfer the same properties and limitations of MIKEY modes apply as in a normal call setup scenarios. 6. Transport of MIKEY messages MIKEY defines message formats to transport key information and security policies between communicating entities. It does not define the embedding of these messages into the used signaling protocol. This definition is provided in separate documents, depending on the used signaling protocol. Fries & Ignjatic Expires November 17, 2006 [Page 16] Internet-Draft MIKEY modes applicability May 2006 Several IETF defined protocols utilize the Session Description Protocol (SDP, [RFC2327]) to transport the session parameters. Examples are the Session Initiation Protocol (SIP, [RFC3261] or the Gateway Control Protocol (GCP, [RFC3525]). The transport of MIKEY messages as part of SDP is described in [I-D.ietf-mmusic-kmgmt-ext]. Here, the complete MIKEY message is base64 encoded and transmitted as part of the SDP part of the signaling protocol message. Note, as several key distribution messages may be transported within one SDP container, [I-D.ietf-mmusic-kmgmt-ext] also comprises an integrity protection regarding all supplied key distribution attempts. Thus, bidding down attacks will be recognized. MIKEY is also applied in ITU-T protocols like H.323, which is used to establish communication sessions similar to SIP. For H.323 a security framework exists, which is defined in H.235. Within this framework H.235.7 [H.235.7] describes the usage of MIKEY and SRTP in the context of H.323. In contrast to SIP H.323 uses ASN.1 (Abstract Syntax Notation). Thus there is no need to encode the MIKEY container as base64. Within H.323 the MIKEY container is binary encoded. 7. Summary of MIKEY related IANA Registrations For MIKEY and the extensions to MIKEY IANA registrations have been made. Here only a link to the appropriate IANA registration is provided to avoid inconsistencies. The IANA registrations for MIKEY payloads can be found under http://www.iana.org/assignments/mikey-payloads These registrations comprise the MIKEY base registrations as well as registrations made by MIKEY extensions regarding the payload. The IANA registrations for MIKEY port numbers can be found under http://www.iana.org/assignments/port-numbers (search for MIKEY). 8. MIKEY alternatives for SRTP security parameter negotiation Besides MIKEY there exists several approaches to handle the security parameter establishment. This is due to the fact, that some limitations in certain scenarios have been seen. Examples are early media and forking situations as described in Section 5. The following list provides a short summary about currently discussed alternatives: o sdescription - [I-D.ietf-mmusic-sdescriptions] describes a key management scheme, which uses SDP for transport and completly relies on underlying protocol security. For transport the Fries & Ignjatic Expires November 17, 2006 [Page 17] Internet-Draft MIKEY modes applicability May 2006 documents defines a SDP attribute transmitting all necessary SRTP parameter in clear. For security it references TLS and S/MIME.In contrast to MIKEY in the message from the initiator to the responder the SRTP parameter for the direction initiator to responder is sent rather than vice versa. This may lead to problems in early media scenarios. o sdescription with early media support - [I-D.wing-mmusic-sdes- early-media] enhances the above scheme with the possibility to also be usable in early media scenarios, when security preconditions is not used. o Encrypted Key Transport for Secure RTP - [Reference to draft-mcgrew-srtp-ekt] is an extension to SRTP that provides for the secure transport of SRTP master keys, Rollover Counters, and other information, within SRTCP. This facility enables SRTP to work for decentralized conferences with minimal control, and to handle situations caused by SIP forking and early media. o Diffie Hellman support in SDP - [I-D.baugher-mmusic-sdp-dh] defines a new SDP attribute for exchanging Diffie-Hellman public keys. The attribute is an SDP session-level attribute for describing DH keys, and there is a new media-level parameter for describing public keying material for SRTP key generation. o DTLS/SRTP compatibility mode - is described as part of [I-D.tschofenig-avt-rtp-dtls] and provides for using DTLS as key management approach in conjunction with partial encryption targeted for low bandwidth connections. o SRTP extensions for DTLS - [Reference to draft-mcgrew-dtls-srtp] describes a method of using DTLS key management for SRTP by using a new extension that indicates that SRTP is to be used for data protection, and which establishes SRTP keys. o ZRTP - [I-D.zimmermann-avt-zrtp] This document defines ZRTP as RTP header extensions for a Diffie-Hellman exchange to agree on a session key and parameters for establishing SRTP sessions. The ZRTP protocol is completely self-contained in RTP and does not require support in the signaling protocol or assume a PKI. 9. Security Considerations This document does not define extensions to existing protocols. It rather provides an overview about the set of MIKEY and available extensions. Thus, the reader is referred to the original documents defining the base protocol and the extensions for the security considerations. 10. IANA Considerations This document does not require any IANA registration. Fries & Ignjatic Expires November 17, 2006 [Page 18] Internet-Draft MIKEY modes applicability May 2006 11. Acknowledgments The authors would like to thank Lakshminath Dondeti for his document reviews and for his guidance. 12. References 12.1. Normative References [I-D.baugher-mmusic-sdp-dh] Baugher, M. and D. McGrew, "Diffie-Hellman Exchanges for Multimedia Sessions", draft-baugher-mmusic-sdp-dh-00 (work in progress), February 2006. [I-D.dondeti-msec-mikey-genext-oma] Dondeti, L. and D. Castleford, "OMA BCAST MIKEY General Extension Payload Specification", draft-dondeti-msec-mikey-genext-oma-00 (work in progress), April 2006. [I-D.ietf-mmusic-kmgmt-ext] Arkko, J., "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)", draft-ietf-mmusic-kmgmt-ext-15 (work in progress), June 2005. [I-D.ietf-mmusic-securityprecondition] Andreasen, F. and D. Wing, "Security Preconditions for Session Description Protocol Media Streams", draft-ietf-mmusic-securityprecondition-01 (work in progress), October 2005. [I-D.ietf-msec-mikey-dhhmac] Euchner, M., "HMAC-authenticated Diffie-Hellman for MIKEY", draft-ietf-msec-mikey-dhhmac-11 (work in progress), April 2005. [I-D.ietf-msec-mikey-ecc] Milne, A., "ECC Algorithms For MIKEY", draft-ietf-msec-mikey-ecc-00 (work in progress), February 2006. [I-D.ietf-msec-mikey-rsa-r] Ignjatic, D., "An additional mode of key distribution in MIKEY: MIKEY-RSA-R", draft-ietf-msec-mikey-rsa-r-04 (work in progress), April 2006. Fries & Ignjatic Expires November 17, 2006 [Page 19] Internet-Draft MIKEY modes applicability May 2006 [I-D.ietf-msec-newtype-keyid] Carrara, E., "The Key ID Information Type for the General Extension Payload in MIKEY", draft-ietf-msec-newtype-keyid-05 (work in progress), March 2006. [I-D.lehtovirta-srtp-rcc] Lehtovirta, V., "Integrity Transform Carrying Roll-over Counter", draft-lehtovirta-srtp-rcc-01 (work in progress), February 2006. [I-D.tschofenig-avt-rtp-dtls] Tschofenig, H. and E. Rescorla, "Real-Time Transport Protocol (RTP) over Datagram Transport Layer Security (DTLS)", draft-tschofenig-avt-rtp-dtls-00 (work in progress), March 2006. [I-D.wing-mmusic-sdes-early-media] Raymond, R. and D. Wing, "Security Descriptions Extension for Early Media", draft-wing-mmusic-sdes-early-media-00 (work in progress), October 2005. [I-D.zimmermann-avt-zrtp] Zimmermann, P., "ZRTP: Extensions to RTP for Diffie- Hellman Key Agreement for SRTP", draft-zimmermann-avt-zrtp-01 (work in progress), March 2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004. [RFC4442] Fries, S. and H. Tschofenig, "Bootstrapping Timed Efficient Stream Loss-Tolerant Authentication (TESLA)", RFC 4442, March 2006. 12.2. Informative References [H.235.7] ""ITU-T Recommendation H.235.7: Usage of the MIKEY Key Management Protocol for the Secure Real Time Transport Protocol (SRTP) within H.235"", 2005. Fries & Ignjatic Expires November 17, 2006 [Page 20] Internet-Draft MIKEY modes applicability May 2006 [I-D.ietf-mmusic-sdescriptions] Andreasen, F., "Session Description Protocol Security Descriptions for Media Streams", draft-ietf-mmusic-sdescriptions-12 (work in progress), September 2005. [ISO_sec_time] ""ISO/IEC 18014 Information technology - Security techniques - Time-stamping services, Part 1-3."", 2002. [RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992. [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3525] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, "Gateway Control Protocol Version 1", RFC 3525, June 2003. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. Briscoe, "Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction", RFC 4082, June 2005. [RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP)", RFC 4383, February 2006. [SAML_overview] Huges, J. and E. Maler, ""Security Assertion Markup Language (SAML) 2.0 Technical Overview, Working Draft"", 2005. Fries & Ignjatic Expires November 17, 2006 [Page 21] Internet-Draft MIKEY modes applicability May 2006 Authors' Addresses Steffen Fries Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany Email: steffen.fries@siemens.com Dragan Ignjatic Polycom 1000 W. 14th Street North Vancouver, BC V7P 3P3 Canada Email: dignjatic@polycom.com Fries & Ignjatic Expires November 17, 2006 [Page 22] Internet-Draft MIKEY modes applicability May 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Fries & Ignjatic Expires November 17, 2006 [Page 23]