Internet Engineering Task Force - MSEC WG Internet DraftNetwork Working Group M. EuchnerIntendedRequest for Comments: 4650 September 2006 Category:Proposed Standard Expires: October 2005 April 2005 HMAC-authenticatedStandards Track HMAC-Authenticated Diffie-Hellman forMIKEY <draft-ietf-msec-mikey-dhhmac-11.txt>Multimedia Internet KEYing (MIKEY) Status ofthisThis MemoBy 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 ofThis document specifies an Internet standards track protocol for the InternetEngineering Task Force (IETF), its areas,community, andits 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 monthsrequests discussion andmay be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material orsuggestions for improvements. Please refer tocite them other than as "work in progress". The list ofthe currentInternet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The listedition ofInternet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Comments should be sent to the MSEC WG mailing list at msec@securemulticast.org and totheauthor. HMAC-authenticated Diffie-Hellman"Internet Official Protocol Standards" (STD 1) forMIKEY April 2005the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes alight-weightlightweight point-to-point key management protocol variant for the multimedia Internet keying (MIKEY) protocol MIKEY, as defined in RFC 3830. In particular, this variant deploys the classic Diffie-Hellman key agreement protocol for key establishment featuring perfect forward secrecy in conjunction with a keyed hash message authentication code for achieving mutual authentication and message integrity of the key management messages exchanged. This protocol addresses the security and performance constraints of multimedia key management in MIKEY.Conventions used in this document 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 [2].Table of Contents 1.Introduction................................................3Introduction ....................................................2 1.1.Definitions...............................................6Definitions ................................................5 1.2.Abbreviations.............................................7Abbreviations ..............................................6 1.3. Conventions Used in This Document ..........................7 2.Scenario....................................................8Scenario ........................................................7 2.1.Applicability.............................................9Applicability ..............................................7 2.2. Relation toGKMARCH.......................................9GKMARCH ........................................8 3. DHHMAC SecurityProtocol...................................10Protocol ........................................8 3.1. TGKre-keying............................................12Re-keying .............................................10 4. DHHMACpayload formats.....................................13 4.1. Common header payload (HDR)..............................13Payload Formats .........................................10 4.2. Keydata transport payload (KEMAC).......................14Data Transport Payload (KEMAC) ........................12 4.3. IDpayload (ID)..........................................15Payload (ID) ...........................................12 4.4. General ExtensionPayload................................15Payload .................................12 5. SecurityConsiderations....................................16Considerations ........................................13 5.1. Securityenvironment.....................................16Environment ......................................13 5.2. Threatmodel.............................................16Model ..............................................13 5.3. SecurityfeaturesFeatures andproperties.........................19Properties ..........................16 5.4.Assumptions..............................................23 HMAC-authenticated Diffie-Hellman for MIKEY April 2005Assumptions ...............................................19 5.5. Residualrisk............................................24Risk .............................................20 5.6. Authorization and TrustModel............................26Model .............................21 6.Acknowledgments............................................26Acknowledgments ................................................21 7. IANAconsiderations........................................26Considerations ............................................22 8.References.................................................27 8.1References .....................................................22 8.1. NormativeReferences.......................................27 8.2References ......................................22 8.2. InformativeReferences...................................27References ....................................22 AppendixAA. Usage of MIKEY-DHHMAC inH.235......................30 Full Copyright Statement........................................33 Expiration Date.................................................34 Revision History................................................34 Author's Addresses..............................................37H.235 ........................25 1. Introduction There is work done in IETF to develop key management schemes. For example, IKE[14][12] is a widely accepted unicast scheme for IPsec, and the MSEC WG is developing other schemes, addressed to group communication[24], [25].[17], [18]. For reasons discussed below, thereis howeveris, however, a need for a scheme with low latency, suitable for demanding cases such as real-time data over heterogeneousnetworks,networks and small interactive groups. As pointed out in MIKEY (see[3]),[2]), secure real-time multimedia applications demand a particular adequatelight-weightlightweight key management scheme thatcares for howtakes care tosecurely and efficientlyestablish dynamic session keys securely and efficiently in a conversational multimedia scenario. In general, MIKEY scenarios cover peer-to-peer,simple-one-to-manysimple one-to-many, and small-sized groups. MIKEY inparticular,particular describes three key management schemes for the peer-to-peer case that all finish their task within oneround trip:roundtrip: - a symmetric key distribution protocol (MIKEY-PS) basedupon pre-sharedon pre- shared masterkeys;keys - a public-key encryption-based key distribution protocolHMAC-authenticated Diffie-Hellman for MIKEY April 2005 (MIKEY-PK)(MIKEY-PK and reverse-mode MIKEY-RSA-R [33]) assuming a public-key infrastructure with RSA-based (Rivest, Shamir and Adleman) private/public keys and digitalcertificates;certificates -anda Diffie-Hellman key agreement protocol (MIKEY-DHSIGN) deploying digital signatures and certificates. All of these three key management protocols are designedsuchso that they complete their work within just oneround trip.roundtrip. This requires depending on loosely synchronized clocks and deploying timestamps within the key management protocols. However, it is known[7][6] that each of the three key management schemes has its subtle constraints and limitations: - The symmetric key distribution protocol (MIKEY-PS) is simple toimplement,implement; however, it was not intended to scale to support any configurations beyond peer-to-peer, simple one-to-many, and small-size (interactive) groups, due to the needoffor mutually pre-assigned shared master secrets. Moreover, the security provided does not achieve the property of perfect forward secrecy;i.e.i.e., compromise of the shared master secret would render past and even future session keys susceptible to compromise. Further, the generation of the session key happens just at the initiator. Thus, the responder has to fully trust the initiatoron choosingto choose a good and secure session secret; the responderneitheris able neither to participate in the key generation nor to influence that process. This is consideredasa specific limitation in less trusted environments. - The public-key encryption scheme(MIKEY-PK)(MIKEY-PK and MIKEY-RSA-R [33]) depends upon a public-key infrastructure that certifies the private-public keys by issuing and maintaining digital certificates. While suchakey managementscheme providesschemes provide full scalability in large networked configurations, public-key infrastructures areHMAC-authenticated Diffie-Hellman for MIKEY April 2005still not widelyavailable andavailable, and, in general, implementations are significantly more complex. Further, additionalround tripsroundtrips and computational processing might be necessary for each end system in order to ascertain verification of the digital certificates. For example, typical operations in the context of a public-key infrastructuresuch asmay involve extra network communication handshakes with the public-key infrastructure and with certification authorities and may typically involve additional processing steps in the end systems. These operations would include validating digital certificates (RFC 3029,[31]),[24]), ascertaining the revocation status of digital certificates (RFC 2560,[30]) and[23]), asserting certificate policies, construction of certification path(s)([33]),([26]), requesting and obtaining necessary certificates (RFC 2511,[32])[25]), and management of certificates for such purposes([29]) may involve extra network communication handshakes with the public-key infrastructure and with certification authorities and may typically involve additional processing steps in the end systems.([22]). Such steps and tasks all result in further delay of the key agreement or key establishment phase among the end systems, which negativelyimpactingaffects setup time. Any extra PKI handshakes and processing are not in the scope ofMIKEYMIKEY, and since this document only deploys symmetric securitymechanisms only,mechanisms, aspects of PKI, digitalcertificatescertificates, and related processing are not further covered in this document. Finally, as in the symmetric case, the responder depends completely upon theinitiatorinitiator's choosing good and secure session keys. - The third MIKEY-DHSIGN key management protocol deploys the Diffie-Hellman key agreement scheme and authenticates the exchange of the Diffie-Hellman half-keys in each direction by using a digital signature. This approach has the same advantages and deficiencies as described in the previous section in terms of a public-key infrastructure. However, the Diffie-Hellman key agreement protocol is known for its subtle security strengths in that it is able to provide full perfect forward secrecy (PFS) and further have to both parties actively involved in session key generation. This special security property- despite(despite the somewhat higherHMAC-authenticated Diffie-Hellman for MIKEY April 2005computationalcosts -costs) makes Diffie-Hellman techniques attractive in practice. In order to overcome some of the limitations as outlined above, a special need has been recognized for another efficient key agreement protocol variant in MIKEY. This protocol variant aims to provide the capability of perfect forward secrecy as part of a key agreement with low latency without dependency on a public-key infrastructure. This document describessucha fourthlight-weightlightweight key management scheme for MIKEY that could somehow be seen as a synergetic optimization between the pre-shared key distribution scheme and the Diffie-Hellman key agreement. The idea of the protocol in this document is to apply the Diffie- Hellman key agreement, but rather thandeployingdeploy a digital signature for authenticity of the exchanged keying material, it instead uses a keyed-hashupon usingfor symmetrically pre-assigned shared secrets. This combination of security mechanisms is called theHMAC- authenticatedHMAC-authenticated Diffie-Hellman (DH) key agreement for MIKEY (DHHMAC). The DHHMAC variant closely follows the design and philosophy of MIKEY and reuses MIKEY protocol payload components and MIKEY mechanisms to its maximum benefit and for best compatibility. Like the MIKEY Diffie-Hellman protocol, DHHMAC does not scale beyond a point-to-point constellation; thus, both MIKEY Diffie-Hellman protocols do not support group-based keying for any group size larger than two entities. 1.1. Definitions The definitions and notations in this document are aligned withMIKEY,MIKEY; see[3],[2] sections 1.3 - 1.4. All large integer computations in this document should be understood as being mod p within some fixed group G for some large prime p; seeHMAC-authenticated Diffie-Hellman for MIKEY April 2005 [3][2] section3.3; however,3.3. However, the DHHMAC protocol is also applicablein generalgenerally to other appropriate finite, cyclical groups as well. It is assumed that a pre-shared key s is known by both entities (initiator and responder). The authentication key auth_key is derived from the pre-shared secret s using the pseudo-random function PRF; see[3][2] sections 4.1.3 and 4.1.5. In this text, [X] represents an optional piece of information. Generally throughout the text, X SHOULD be present unless certaincircumstancecircumstances MAY allow Xbeingto be optional and not to bepresentpresent, thereby potentially resulting in weakersecurity potentially. Likewisesecurity. Likewise, [X, Y] represents an optional compound piece of information where the pieces X and YSHOULD beeither SHOULD both be present or MAY optionallybeboth be absent. {X} denotes zero or more occurrences of X. 1.2. Abbreviations auth_keypre-sharedPre-shared authentication key, PRF-derived from pre-shared key s. DH Diffie-Hellman DHipublicPublic Diffie-Hellman half key g^(xi) of the Initiator DHrpublicPublic Diffie-Hellman half key g^(xr) of the Responder DHHMAC HMAC-authenticated Diffie-Hellman DoS Denial-of-service G Diffie-Hellman group HDR MIKEY common header payload HMACkeyedKeyed Hash Message Authentication Code HMAC-SHA1 HMAC using SHA1 as hash function (160-bit result) IDi Identity of initiator IDr Identity of receiver IKE Internet Key Exchange IPsec Internet Protocol Security MIKEY Multimedia Internet KEYing MIKEY-DHHMAC MIKEY Diffie-Hellman key management protocol using HMAC MIKEY-DHSIGN MIKEY Diffie-Hellman key agreement protocolHMAC-authenticated Diffie-Hellman for MIKEY April 2005MIKEY-PK MIKEY public-key encryption-based key distribution protocol MIKEY-PS MIKEY pre-shared key distribution protocol p Diffie-Hellman prime modulus PKI Public-key Infrastructure PRF MIKEY pseudo-random function (see[3][2] section4.1.3.)4.1.3) RSA Rivest,ShamirShamir, and Adleman spre-sharedPre-shared key SDP Session Description Protocol SOI Son-of-IKE, IKEv2 SP MIKEY Security Policy (Parameter) Payload TtimestampTimestamp TEK Traffic Encryption Key TGK MIKEY TEK GenerationKeyKey, as the common Diffie- Hellman shared secret TLS Transport Layer Security xisecret,Secret, (pseudo) random Diffie-Hellman key of the Initiator xrsecret,Secret, (pseudo) random Diffie-Hellman key of the Responder 1.3. Conventions Used in This Document 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 [1]. 2. Scenario The HMAC-authenticated Diffie-Hellman key agreement protocol (DHHMAC) for MIKEY addresses the same scenarios and scope as the other three key management schemes in MIKEY address. DHHMAC is applicable in a peer-to-peer group where no access to a public-key infrastructure can be assumed to be available. Rather, pre- shared master secrets are assumed to be available among the entities in such an environment. In a pair-wise group, it is assumed that each client will be setting up a session key for its outgoing links with its peer using the DH- MAC key agreement protocol.HMAC-authenticated Diffie-Hellman for MIKEY April 2005As is the case for the other three MIKEY key management protocols, DHHMAC assumes, at least, loosely synchronized clocks among the entities in the small group. To synchronize the clocks in a secure manner, some operational or procedural means are recommended. MIKEY-DHHMAC does not define any secure time synchronizationmeasures,measures; however, sections 5.4 and 9.3 of[3][2] provide implementation guidance on clock synchronization and timestamps. 2.1. ApplicabilityMIKEY-DHHMAC, as well asMIKEY-DHHMAC and the other MIKEY key managementprotocols, isprotocols are intended for application-level key management andisare optimized for multimedia applications with real-time session setup and session management constraints. As the MIKEY-DHHMAC key management protocol terminates in one roundtrip, DHHMAC is applicable for integration into two-way handshakesession-session or call signaling protocols such as a)SIP/SDPSIP [13] and SDP, where the encoded MIKEY messages are encapsulated and transported in SDP containers of the SDP offer/answer[RFC 3264] handshakesee RFC 3264 [27]) handshake, as described in[5],[4]; and b) H.323 (see[22])[15]), where the encoded MIKEY messages are transported in the H.225.0 fast start call signaling handshake. Appendix A outlines the usage of MIKEY-DHHMAC within H.235. MIKEY-DHHMAC is offered as an option to the other MIKEY key management variants (MIKEY-pre-shared, MIKEY-public-key andMIKEY-DH-SIGN)MIKEY- DH-SIGN) for all those cases where DHHMAC has its particular strengths (see section 5). 2.2. Relation to GKMARCH The Group key management architecture (GKMARCH)[26][19] describes a generic architecture for multicast security group key management protocols. In the context of this architecture, MIKEY-DHHMAC mayHMAC-authenticated Diffie-Hellman for MIKEY April 2005operate as a registrationprotocol,protocol; see also[3][2] section 2.4. The main entities involved in the architecture are a group controller/key server (GCKS), the receiver(s), and the sender(s). Due to thepair-wisepair- wise nature of the Diffie-Hellman operation and the 1-roundtrip constraint, usage of MIKEY-DHHMAC rules out any deployment as a group key management protocol with more than two group entities. Only the degenerate case with two peers is possiblewherewhere, forexampleexample, the responder acts as the group controller. Note that MIKEY does not provide re-keying in the GKMARCH sense, only updating of the keys by normal unicast messages. 3. DHHMAC Security Protocol The following figure defines the security protocol for DHHMAC: Initiator Responder I_message = HDR, T, RAND, [IDi], IDr, {SP}, DHi, KEMAC -----------------------> R_message = HDR, T, [IDr], IDi, DHr, DHi, KEMAC <---------------------- Figure 1: HMAC-authenticated Diffie-Hellmankey basedkey-based exchange, where xi and xr are (pseudo) randomlychosen respectivelychosen, respectively, by the initiator and the responder. The DHHMAC key exchange SHALL be done according to Figure 1. The initiator chooses a (pseudo) randomvaluevalue, xi, and sends an HMACed message including g^(xi) and a timestamp to the responder. It is recommended that the initiator SHOULD always include the identity payloads IDi and IDr within the I_message; unless the receiver can defer the initiator's identity by some other means,thenIDi MAYHMAC-authenticated Diffie-Hellman for MIKEY April 2005optionally be omitted. The initiator SHALL always include the recipient's identity. The group parameters (e.g., the group G) are a set of parameters chosen by the initiator.Note,Note that like in the MIKEY protocol, both sender and receiver explicitly transmit the Diffie-Hellman group G within the Diffie-Hellman payload DHi or DHr through an encoding (e.g., OAKLEY groupnumbering,numbering; see[3][2] section6.4); the6.4). The actual group parameters g andp howeverp, however, are not explicitly transmitted but can be deduced from the Diffie-Hellman group G. The responder chooses a (pseudo) random positiveintegerinteger, xr, and sends an HMACed message including g^(xr) and the timestamp to the initiator. The responder SHALL always include the initiator's identity IDi regardless of whether the I_message conveyed any IDi. It is RECOMMENDED that the responder SHOULD always include the identity payload IDr within the R_message; unless the initiator can defer the responder's identity by some other means,thenIDr MAY optionally be left out. Both parties then calculate the TGK as g^(xi * xr). The HMAC authentication provides authentication of the DHhalf- keys,half-keys and is necessary to avoid man-in-the-middle attacks. This approach is less expensive than digitally signedDiffie- HellmanDiffie-Hellman in that both sides computefirstone exponentiation and oneHMAC,HMAC first, then one HMACverificationverification, and finally anotherDiffie- HellmanDiffie-Hellman exponentiation. With off-line pre-computation, the initial Diffie-Hellman half-key MAY be computed before the key management transaction and thereby MAY further reduce the overallround trip delayroundtrip delay, as well asreducethe risk of denial-of-service attacks. Processing of the TGK SHALL be accomplished as described in MIKEY[3] chapter[2] section 4. The computed HMAC result SHALL be conveyed in the KEMAC payload field where the MAC fields holds the HMAC result. The HMAC SHALLHMAC-authenticated Diffie-Hellman for MIKEY April 2005be computed over the entiremessagemessage, excluding the MAC field usingauth_key,auth_key; see also section 4.2. 3.1. TGKre-keyingRe-keying TGK re-keying for DHHMAC generally proceeds as described in[3][2] section 4.5. Specifically,figureFigure 2 provides the message exchange for the DHHMAC update message. Initiator Responder I_message = HDR, T, [IDi], IDr, {SP}, [DHi], KEMAC -----------------------> R_message = HDR, T, [IDr], IDi, [DHr, DHi], KEMAC <---------------------- Figure 2: DHHMAC update message TGK re-keying supports two procedures: a) True re-keying by exchanging new and fresh Diffie-Hellman half- keys. For this, the initiator SHALL provide a new, freshDHiDHi, and the responder SHALL respond with a new, fresh DHr and the received DHi. b) Non-key related information update without including anyDiffie-HellmanDiffie- Hellman half-keysincludedin the exchange. Such a transaction does not change the actual TGK but updates other informationlikesuch as security policyparameters for example.parameters. Toonlyupdate the non-key relatedinformation,information only, [DHi] and [DHr, DHi] SHALL be left out.HMAC-authenticated Diffie-Hellman for MIKEY April 20054. DHHMACpayload formatsPayload Formats This section specifies the payload formats and data type values forDHHMAC,DHHMAC; see also[3] chapter 6[2] section 6, for a definition of the MIKEY payloads. This document does not define new payload formats but re-uses MIKEY payloads for DHHMAC as referenced: * Common header payload(HDR),(HDR); see section 4.1 and[3][2] section6.16.1. * SRTP IDsub-payload,sub-payload; see[3][2] section6.1.1,6.1.1. * Key data transport payload(KEMAC),(KEMAC); see section 4.2 and[3][2] section6.26.2. * DH datapayload,payload; see[3][2] section6.46.4. * Timestamppayload, [3]payload; see [2] section6.66.6. * IDpayload, [3]payload; [2] section6.76.7. * Security Policy payload(SP), [3](SP); see [2] section6.106.10. * RAND payload(RAND), [3](RAND); see [2] section6.116.11. * Error payload(ERR), [3](ERR); see [2] section6.126.12. * General ExtensionPayload, [3]Payload; see [2] section6.156.15. 4.1. Commonheader payloadHeader Payload (HDR) Referring to[3][2] section 6.1,for DHHMACthe following data types SHALL beused:used for DHHMAC: Data type | Value | Comment -------------------------------------------------------------HMAC-authenticated Diffie-Hellman for MIKEY April 2005DHHMAC init | 7 | Initiator's DHHMAC exchange message DHHMAC resp | 8 | Responder's DHHMAC exchange message Error | 6 | Errormessage,message; see[3][2] section 6.12 Table 4.1.a Note: A responder is able to recognize the MIKEY DHHMAC protocol by evaluating the data type field as 7 or 8. This is how the responder can differentiate between MIKEY and MIKEY DHHMAC. The next payload field SHALL be one of the following values: Next payload| Value | Section ---------------------------------------------------------------- Last payload| 0 | - KEMAC | 1 | section 4.2 and[3][2] section 6.2 DH | 3 |[3][2] section 6.4 T | 5 |[3][2] section 6.6 ID | 6 |[3][2] section 6.7 SP | 10 |[3][2] section 6.10 RAND | 11 |[3][2] section 6.11 ERR | 12 |[3][2] section 6.12 General Ext.| 21 |[3][2] section 6.15 Table 4.1.b Other defined next payload values defined in[3][2] SHALL not be applied to DHHMAC.The responder inIn case of a decoding error or of a failed HMAC authenticationverificationverification, the responder SHALL apply the Error payload data type. 4.2. Keydata transport payloadData Transport Payload (KEMAC) DHHMAC SHALL apply this payload for conveying the HMAC result along with the indicated authentication algorithm.KEMAC whenWhen used in conjunction withDHHMACDHHMAC, KEMAC SHALL not convey any encrypted data;thusthus, Encr alg SHALL be set to 2 (NULL), Encr data len SHALL be setHMAC-authenticated Diffie-Hellman for MIKEY April 2005to00, and Encr data SHALL be left empty. The AES key wrap method (see[23])[16]) SHALL not be applied for DHHMAC. For DHHMAC, this key data transport payload SHALL be the last payload in the message. Note that the Next payload field SHALL be set to Last payload. The HMAC is then calculated over the entire MIKEYmessagemessage, excluding the MAC field using auth_key as described in[3][2] section5.25.2, and then stored within the MAC field. MAC alg | Value | Comments ------------------------------------------------------------------ HMAC-SHA-1 | 0 | Mandatory, Default (see[4])[3]) NULL | 1 | Very restricteduse,use; see |[3][2] section 4.2.4 Table 4.2.a HMAC-SHA-1 is the default hash function that MUST be implemented as part of the DHHMAC. The length of the HMAC-SHA-1 result is 160 bits. 4.3. IDpayloadPayload (ID) For DHHMAC, this payload SHALL only hold anon-certificate basednon-certificate-based identity. 4.4. General Extension Payload ForDHHMAC andDHHMAC, to avoid bidding-down attacks, this payload SHALL list all key management protocol identifiers of a surrounding encapsulationprotocolprotocol, such asfor example,SDP[5].[4]. The General Extension Payload SHALL beintegrity-protectedintegrity protected with the HMAC using the shared secret. Type | Value | Comments SDP IDs | 1 | List of SDP key management IDs (allocated for use in[5]);[4]); see also[3][2] section 6.15.HMAC-authenticated Diffie-Hellman for MIKEY April 2005Table 4.4.a 5. Security Considerations This document addresses key management security issues throughout. For a comprehensive explanation of MIKEY security considerations, please refer to MIKEY[3][2] section 9. Inaddition to that,addition, this document addresses security issues according to[8][7], where the following security considerations apply in particular to this document: 5.1. Securityenvironment Generally, theEnvironment The DHHMAC security protocol described in this document focuses primarily on communication security;i.e.i.e., the security issues concerned with the MIKEY DHHMAC protocol. Nevertheless, some system security issues are also of interestas wellthat are not explicitly defined by the DHHMAC protocol, but that should be provided locally in practice. The system that runs the DHHMAC protocol entity SHALL provide the capability to generate (pseudo) random numbers as input to the Diffie-Hellman operation (see[9], [15]).[8]). Furthermore, the system SHALL be capable of storing the generated (pseudo) random data, secret data,keyskeys, and other secret security parameters securely(i.e.(i.e., confidential and safe from unauthorized tampering). 5.2. ThreatmodelModel The threat model, to which this document adheres, covers the issues of end-to-end security in the Internet generally, without ruling out the possibility that MIKEY DHHMAC can be deployed in a corporate, closed IP environment. This also includes the possibility that MIKEY DHHMAC can be deployed on a hop-by-hop basis with some intermediate trusted "MIKEY DHHMAC proxies" involved. Since DHHMAC is a key management protocol, the following security threats are of concern:HMAC-authenticated Diffie-Hellman for MIKEY April 2005* Unauthorized interception of plain TGKs: ForDHHMACDHHMAC, this threat does not occur since the TGK is not actually transmitted on the wire (not even in encrypted fashion). * Eavesdropping of other, transmitted keying information: DHHMAC protocol does not explicitly transmit the TGK at all. Instead, by using the Diffie-Hellman "encryption" operation, which conceals the secret (pseudo) random values, only partial information(i.e.(i.e., theDH- half key)DH half-key) for construction of the TGK is transmitted. It is fundamentally assumed that availability of such Diffie-Hellman half-keys to an eavesdropper does not result in any substantial security risk; see 5.4. Furthermore, the DHHMAC carries other data such as timestamps, (pseudo) random values, identification information or security policy parameters; eavesdropping of any such data isconsiderednot considered to yield any significant security risk. * Masquerade of either entity: This security threat must beavoidedavoided, and if a masquerade attack would be attempted, appropriate detection means must be in place. DHHMAC addresses this threat by providing mutual peer entity authentication. * Man-in-the-middle attacks: Such attacks threaten the security of exchanged, non-authenticated messages. Man-in-the-middle attacks usually come with masquerade and or loss of message integrity (see below). Man-in-the-middle attacks must beavoided, andavoided and, if present orattemptedattempted, must be detected appropriately. DHHMAC addresses this threat by providing mutual peer entity authentication and message integrity. * Loss of integrity: This security threat relates to unauthorized replay, deletion,insertioninsertion, and manipulation of messages.WhileAlthough any such attacks cannot beavoidedavoided, they mustbe detectedatleast.least be detected. DHHMAC addresses this threat by providing message integrity. * Bidding-down attacks:HMAC-authenticated Diffie-Hellman for MIKEY April 2005When multiple key managementprotocolsprotocols, each of a distinct securitylevellevel, are offered(e.g., such(such asisthose made possible by SDP[5]),[4]), avoiding bidding-down attacks is of concern. DHHMAC addresses this threat by reusing the MIKEY General Extension Payload mechanism, where all key management protocol identifiers are to be listed within the MIKEY General Extension Payload. Some potential threats are not within the scope of this threat model: * Passive and off-line cryptanalysis of the Diffie-Hellman algorithm: Under certain reasonable assumptions (see5.4 below)5.4, below), it is widely believed that DHHMAC is sufficiently secure and that such attacks are infeasible, although the possibility of a successful attack cannot be ruled out. * Non-repudiation of the receipt or of the origin of the message: These are not requirements within the context of DHHMAC in thisenvironmentenvironment, and thus related countermeasures are not provided at all. * Denial-of-service or distributed denial-of-service attacks: Some considerations are given on some of those attacks, but DHHMAC does not claim to provide full countermeasure against any of those attacks. For example, stressing the availability of the entitiesareis not thwarted by means of the key management protocol; some other local countermeasures should be applied. Further, some DoS attacks are notcounteredcountered, such as interception of a valid DH- request and its massive instant duplication. Such attacks might at least be countered partially by some local means that are outside the scope of this document. * Identity protection: Like MIKEY, identity protection is not a major design requirement forMIKEY-DHHMAC either,MIKEY-DHHMAC, either; see[3].[2]. No security protocol is known sofar,far that is able to provide the objectives of DHHMAC as stated in section5.35.3, including identity protection within just a single roundtrip. MIKEY-DHHMAC trades identity protection for better security for the keying material and shorter roundtrip time. Thus, MIKEY-DHHMAC does not provide identity protection on its own butHMAC-authenticated Diffie-Hellman for MIKEY April 2005may inherit such property from a security protocol underneath that actually features identity protection. The DHHMAC security protocol (see section 3) and the TGK re-keying security protocol (see section 3.1) provide the option not to supply identity information. This option is only applicable if some other means are availableof supplyingto supply trustworthy identity information; e.g., by relying on secured links underneathofMIKEY that supply trustworthy identity informationotherwise.some other way. However, it is understood that without identityinformation present,information, the MIKEY key management security protocols might be subject to security weaknesses such as masquerade,impersonationimpersonation, and reflectionattacksattacks, particularly in end-to-end scenarios where no other secure means of assured identity informationisare provided. Leaving identity fields optionalif possible(if doing so is possible) thus should not be seen as a privacymethodmethod, either, but rather as a protocol optimization feature. 5.3. SecurityfeaturesFeatures andpropertiesProperties With the security threats in mind, thisdraftdocument provides the following security features and yields the following properties: * Secure key agreement with the establishment of a TGK at both peers: This is achieved using an authenticated Diffie-Hellman key management protocol. * Peer-entity authentication (mutual): This authentication corroborates that the host/user is authentic in that possession of a pre-assigned secret key is proven using keyed HMAC. Authentication occurs on the request and on the responsemessage,message; thus authentication is mutual. The HMAC computation corroborates for authentication and message integrity of the exchanged Diffie-Hellman half-keys and associated messages. The authentication is absolutely necessary in order toHMAC-authenticated Diffie-Hellman for MIKEY April 2005avoid man-in-the-middle attacks on the exchanged messages in transitandand, in particular, on the otherwise non-authenticated exchanged Diffie-Hellmanhalf keys.half-keys. Note: This document does not address issues regarding authorization; this feature is not provided explicitly. However, DHHMAC authentication means support and facilitate realization of authorization means (local issue). * Cryptographic integrity check: The cryptographic integrity check is achieved using a message digest (keyed HMAC). It includes the exchanged Diffie-Hellman half-keys but covers the other parts of the exchanged message as well. Both mutual peer entity authentication and message integrity provide effective countermeasures against man-in-the-middle attacks. The initiator may deploy a local timer that fires when the awaited response message did not arrive in a timely manner. This is intended to detect deletion of entire messages. * Replay protection of the messages is achieved using embeddedtimestamps.timestamps: In order to detect replayedmessagesmessages, it is essential that the clocks among initiator and sender be roughly synchronized. The reader is referred to[3][2] section5.45.4, and[3][2] section9.3 that9.3, which provide further considerations and give guidance on clock synchronization and timestamp usage. Should the clock synchronization be lost,thenend systems cannot detect replayed messagesanymore resulting thatanymore, and the end systems cannot securely establish keying material. This may result in adenial-of-service,denial-of-service; see[3][2] section 9.5. * Limited DoS protection: Rapid checking of the message digest allows verifying the authenticity and integrity of a message before launching CPU intensive Diffie-Hellman operations or starting other resource consuming tasks. This protects against somedenial-of-servicedenial-of- service attacks: malicious modification of messages and spam attacks with (replayed or masqueraded) messages. DHHMAC probably does not explicitly counter sophisticated distributed, large-scaledenial- HMAC-authenticated Diffie-Hellman for MIKEY April 2005 of-servicedenial-of-service attacks that compromise systemavailabilityavailability, for example. Some DoS protection is provided by inclusion of the initiator's identity payload in the I_message. This allows the recipient to filter out those (replayed) I_messages that are not targeted for him andavoids the recipient fromto avoid creating unnecessary MIKEY sessions. * Perfect-forward secrecy (PFS): Other than the MIKEY pre-shared andpublic-key basedpublic-key-based key distribution protocols, the Diffie-Hellman key agreement protocol features a security property called perfect forward secrecy. That is,thateven if the long-term pre-shared keywould beis compromised at some point in time, thiswoulddoes notrendercompromise past or future sessionkeys compromised.keys. Neither the MIKEY pre-shared nor the MIKEY public-key protocol variants are able to provide the security property of perfect- forward secrecy. Thus, none of the other MIKEY protocols is able to substitute the Diffie-Hellman PFS property. As such,DHHMAC, as well asDHHMAC and digitally signedDH, providesDH provide a far superior security leveloverto that of the pre-shared orpublic-key basedpublic-key-based key distribution protocol in that respect. * Fair, mutual key contribution: The Diffie-Hellman key management protocol is not a strict key distribution protocol perse withse, in which the initiatordistributingdistributes a key to its peers. Actually, both parties involved in the protocol exchange are able toequallycontribute to the commonDiffie- HellmanDiffie-Hellman TEK traffic generatingkey.key equally. This reduces the risk of either party cheating or unintentionally generating a weak session key. This makes the DHHMAC a fair key agreement protocol. One may view this property as an additional distributed security measure thatis increasingincreases security robustness over that of the case where all the security depends just on the proper implementation of a single entity.In order forFor Diffie-Hellman key agreement to be secure, each party SHALL generate its xi or xr values using a strong, unpredictablepseudo-randompseudo- random generator if a source of true randomness is notHMAC-authenticated Diffie-Hellman for MIKEY April 2005available. Further, these values xi or xr SHALL be kept private. It is RECOMMENDED that these secret values be destroyed once the common Diffie-Hellman shared secret key has been established. * Efficiency and performance: Like the MIKEY-public key protocol, the MIKEY DHHMAC key agreement protocol securely establishes a TGK within just one roundtrip. Other existing key managementtechniques liketechniques, such as IPsec-IKE[14],[12], IPsec-IKEv2[21] and[14], TLS[13][11], and otherschemesschemes, are not deemed adequate in addressingsufficientlythosereal-timereal- time and securityrequirements;requirements sufficiently; they all use more than a single roundtrip. All the MIKEY key management protocols are able to complete their task of security policy parameternegotiationnegotiation, including key-agreement or keydistributiondistribution, in one roundtrip. However, the MIKEY pre-shared andtheMIKEY public-key protocolbothare both able to complete their task even in ahalf-round triphalf- roundtrip when the confirmation messages are omitted. Using HMAC in conjunction with a strong one-way hash functionsuch(such asSHA1SHA1) may be achieved more efficiently in software than expensive public-key operations. This yields a particular performance benefit of DHHMAC over signed DH or the public-key encryption protocol. If a very high security level is desired for long-term secrecy of the negotiated Diffie-Hellman shared secret, longer hash values may bedeployeddeployed, such as SHA256,SHA384SHA384, or SHA512 provide, possibly in conjunction with stronger Diffie-Hellman groups. This is left as for further study. For the sake of improved performance and reducedround trip delayroundtrip delay, either party mayoff-linepre-compute its public Diffie-Hellmanhalf-key.half-key off-line. On the other side and under reasonable conditions, DHHMAC consumes more CPU cycles than the MIKEY pre-shared key distribution protocol. The same might hold true quite likely for the MIKEY public-key distribution protocol (depending on choice of the private and public key lengths).HMAC-authenticated Diffie-Hellman for MIKEY April 2005As such, it can be said that DHHMAC provides sound performance when compared with the other MIKEY protocol variants. The use of optional identity information (with the constraints stated in section 5.2) and optional Diffie-Hellman half-key fields provides a means to increase performance and shorten the consumed network bandwidth. * Security infrastructure: This document describes theHMAC-authenticatedHMAC- authenticated Diffie-Hellman key agreementprotocol thatprotocol, which completely avoids digital signatures and the associated public-keyinfrastructureinfrastructure, as would be necessary for the X.509 RSApublic-key basedpublic- key-based key distribution protocol or the digitally signed Diffie-Hellman key agreement protocol as described in MIKEY. Public-key infrastructures may not always be available in certainenvironmentsenvironments, nor may they be deemed adequate forreal- timereal-time multimedia applications whentakingadditional steps are taken for certificate validation and certificate revocation methods with additionalround-tripsroundtrips into account. DHHMAC does not depend onPKIPKI, nor do implementations require PKIstandards and thusstandards. Thus, it is believed to be much simpler than the more complex PKI facilities. DHHMAC is particularly attractive in those environments where provisioning of a pre-shared key has already been accomplished. * NAT-friendliness: DHHMAC is able to operate smoothly through firewall/NAT devices as long as the protected identity information of the end entity is not anIP /transportIP/transport address. * Scalability: Like the MIKEY signed Diffie-Hellman protocol, DHHMAC does not scale to any larger configurations beyond peer-to-peer groups. 5.4. AssumptionsHMAC-authenticated Diffie-Hellman for MIKEY April 2005This document states a couple of assumptions upon which the security of DHHMAC significantly depends.It is assumed, thatThe following conditions are assumed: *theThe parameters xi, xr,ss, and auth_key are to be kept secret. *theThe pre-shared key s has sufficient entropy and cannot be effectively guessed. *theThe pseudo-random function (PRF) is secure, yieldsindeedthepseudo-random propertypseudo- random property, and maintains the entropy. *aA sufficiently large and secure Diffie-Hellman group is applied. *theThe Diffie-Hellman assumption holds saying basically that even with knowledge of the exchanged Diffie-Hellman half-keys and knowledge of the Diffie-Hellman group, it is infeasible to compute the TGK or to derive the secret parameters xi or xr. The latter is also called the discrete logarithm assumption. Please see[7], [11][6], [9], or[12][10] for more background information regarding the Diffie-Hellman problem and its computational complexity assumptions. *theThe hash function (SHA1) is secure;i.e. thati.e., it is computationally infeasible to find a messagewhichthat corresponds to a given message digest, or to find two different messages that produce the same message digest. *theThe HMAC algorithm is secure and does not leak the auth_key. In particular, the security depends on the message authentication property of the compression function of the hash function H when it is applied to single blocks (see[6]).[5]). *aA source capable of producing sufficiently many bits of (pseudo) randomness is available. *theThe system upon which DHHMAC runs is sufficiently secure. 5.5. Residualrisk HMAC-authenticated Diffie-Hellman for MIKEY April 2005Risk Although these detailed assumptions are non-negligible, security experts generally believe that all these assumptions are reasonable and that the assumptions made can be fulfilled in practice with little or no expenses. The mathematical and cryptographic assumptions of the properties of the PRF, the Diffie-Hellman algorithm (discrete log-assumption), the HMACalgorithmalgorithm, and the SHA1 algorithms have been neither provenornor disproven at this time. Thus, a certain residual risk remains, which might threaten the overall security at some unforeseeable time in the future. The DHHMAC would be compromised as soon as any of the listed assumptionsdo not hold anymore.no longer hold. The Diffie-Hellman mechanism is a generic security technique that is not only applicable to groups of prime order or of characteristic two. This is because of the fundamental mathematical assumption that the discrete logarithm problem is also a very hard one in general groups. This enables Diffie-Hellman to be deployed also for GF(p)*, for sub-groups of sufficientsizesize, and for groups upon elliptic curves. RSA does not allow such generalization, as the core mathematical problem is a different one (large integer factorization). RSA asymmetric keys tend to become increasingly lengthy (1536 bits and more) and thus very computationally intensive. Nevertheless,elliptic curveElliptic Curve Diffie-Hellman (ECDH) allowsto cut-downkey lengths to be cut down substantially (say 170 bits or more) while maintaining at least the security level and providing even more significant performance benefits in practice. Moreover, it is believed thatelliptic curveelliptic-curve techniques provide much better protection against side channel attacks due to the inherent redundancy in the projective coordinates. For all these reasons, one may view elliptic-curve-based Diffie- Hellman as being more "future-proof" and robust against potential threats thanRSA. Note,RSA is. Note thatan elliptic-curveElliptic Curve Diffie-Hellmanvariantvariants of MIKEYremains for further study. HMAC-authenticated Diffie-Hellman for MIKEY April 2005 It is not recommendedare defined in [31]. HMAC-SHA1 is a key security mechanism within DHHMAC on which the overall security of MIKEY DHHMAC depends. MIKEY DHHMAC uses HMAC- SHA1 in combination with the classic Diffie-Hellman key agreement scheme. HMAC-SHA1 is a keyed one-way hash function that involves a secret in its computation. DHHMAC applies HMAC-SHA1 for protection of the MIKEY payload. Likewise, the pseudo-random function PRF within MIKEY [2] uses the HMAC-SHA1 mechanism as a key derivation function. While certain attacks have been reported against SHA1 and MD5 (see [29]), with current knowledge (see [29], [30]), no attacks have been reported against the HMAC-SHA1 security mechanism. In fact, [32] proves that HMAC possesses the property of a pseudo-random function PRF assuming solely that the (SHA1) hash function is a pseudo-random function. [32] also provides evidence that HMAC is robust against collision attacks on the underlying hash function. It is believed that MIKEY DHHMAC should be considered secure enough for the time being. Thus, there is no need to change the underlying security mechanism within the MIKEY DHHMAC protocol. It is not recommended to deploy DHHMAC for any otherusageuse than that depicted in section 2.Otherwise any suchAny misapplication might lead to unknown, undefined properties. 5.6. Authorization and Trust Model Basically, similar remarks on authorization as those stated in[3][2] section4.3.2.4.3.2 hold also for DHHMAC. However, as noted before, this key management protocol does not serve full groups. One may view the pre-established shared secretto yieldas yielding some pre- established trust relationship between the initiator and the responder. This results in a much simpler trust model for DHHMAC than would be the case for some generic group key management protocol and potential group entities without any pre-defined trust relationship.The common group controller inIn conjunction with the assumption of a sharedkeykey, the common group controller simplifies the communication setup of the entities. One may view the pre-established trust relationship through the pre- shared secret as some means for pre-granted, implied authorization. This document does not define any particular authorization means but leaves this subject to the application. 6. Acknowledgments This document incorporateskindlykindly, valuable review feedback from Steffen Fries, Hannes Tschofenig, Fredrick Lindholm, MaryBarnesBarnes, and Russell Housley and general feedback by the MSEC WG. 7. IANAconsiderationsConsiderations This document does not define its own new name spaces for DHHMAC, beyond the IANA name spaces that have been assigned forMIKEY,MIKEY; see[3] section[2] sections 10 andsection 10.1, see also10.1 and IANA MIKEY payload name spaces [37].HMAC-authenticated Diffie-Hellman for MIKEY April 2005In order to align Table 4.1.a with[3] table 6.1.a,Table 6.1.a in [2], IANA is requested to add the following entries to their MIKEY Payload Name Space: Data Type Value Reference --------------- ----- --------- DHHMAC init 7[RFCxxxx]RFC 4650 DHHMAC resp 8[RFCxxxx] [Note to the RFC editor: Please replace RFCxxxx with theRFCnumber of this document prior to publication.]4650 8. References8.18.1. Normative References [1] Bradner, S.,"The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Bradner, S.,"Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[3] J.[2] Arkko,E.J., Carrara,F.E., Lindholm,M.F., Naslund, M., and K.Norrman;Norrman, "MIKEY: Multimedia Internet KEYing", RFC3830 IETF,3830, August 2004.[4][3] NIST, FIBS-PUB180-1,180-2, "Secure Hash Standard", April 1995,http://csrc.nist.gov/fips/fip180-1.ps. [5] J.http://csrc.nist.gov/publications/fips/fips180-2/ fips180-2withchangenotice.pdf. [4] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E.Carrara et al:Carrara, "Key Management Extensions forSDPSession Description Protocol (SDP) andRTSP", Internet Draft <draft-ietf-mmusic-kmgmt-ext-14.txt>, Work in Progress (MMUSIC WG), IETF, March 2005. [6] H.Real Time Streaming Protocol (RTSP)", RFC 4567, July 2006. [5] Krawczyk,M.H., Bellare, M., and R.Canetti:Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.8.28.2. Informative References[7][6] A.J. Menezes, P. van Oorschot, S. A. Vanstone: "Handbook of Applied Cryptography", CRC Press 1996.HMAC-authenticated Diffie-Hellman for MIKEY April 2005 [8] E.[7] Rescorla, E. and B.Korver: " GuidelinesKorver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552,IETF,July 2003.[9] D. Eastlake, S. Crocker:[8] Eastlake 3rd, D., Crocker, S., and J. Schiller, "Randomness Recommendations for Security", RFC 1750,IETF,December 1994.[10] S.M. Bellovin, C. Kaufman, J. I. Schiller: "Security Mechanisms for the Internet", RFC 3631, IETF, December 2003. [11][9] Ueli M. Maurer, S. Wolf: "The Diffie-Hellman Protocol", Designs, Codes, and Cryptography, Special Issue Public Key Cryptography, Kluwer Academic Publishers, vol. 19, pp. 147-171, 2000.ftp://ftp.inf.ethz.ch/pub/crypto/publications/MauWol00c.ps [12]ftp://ftp.inf.ethz.ch/pub/crypto/publications/MauWol00c.ps. [10] Discrete Logarithms and the Diffie-HellmanProtocol; http://www.crypto.ethz.ch/research/ntc/dldh/ [13] T.Protocol, http://www.crypto.ethz.ch/research/ntc/dldh/. [11] Dierks,C. Allen:T. and E. Rescorla, "TheTLSTransport Layer Security (TLS) Protocol Version1.0.",1.1", RFC2246, IETF, January 1999. [14] D.4346, April 2006. [12] Harkins, D.Carrel:and D. Carrel, "The Internet Key Exchange(IKE).",(IKE)", RFC 2409,IETF,November 1998.[15] Donald[13] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E.Eastlake, Jeffrey I. Schiller, Steve Crocker: "Randomness Requirements for Security"; <draft-eastlake- randomness2-10.txt>; Work in Progress, IETF, January 2005. [16] J. Schiller: "Strong Security Requirements for Internet Engineering Task Force Standard Protocols", RFC 3365, IETF, 2002. [17] C. Meadows: "Advice on Writing an Internet Draft Amenable to Security Analysis", Work in Progress, <draft-irtf-cfrg-advice- 00.txt>, IRTF, October 2002. [18] T. Narten: "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, IETF, October 1998. [19] J. Reynolds: "Instructions to Request for Comments (RFC) HMAC-authenticated Diffie-Hellman for MIKEY April 2005 Authors", Work in Progress, <draft-rfc-editor-rfc2223bis- 08.txt>, IETF, August 2004. [20] J. Rosenberg et all:Schooler, "SIP: Session Initiation Protocol", RFC 3261,IETF,June 2002.[21] Ch. Kaufman:[14] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",Work in Progress (IPSEC WG), <draft-ietf-ipsec-ikev2-17.txt>, Internet Draft, Work in Progress (IPSEC WG). [22]RFC 4306, December 2005. [15] ITU-T RecommendationH.235 Annex G: "UsageH.235.7: " H.323 Security framework: Usage of the MIKEY Key Management Protocol for the Secure Real Time Transport Protocol (SRTP) within H.235";1/2005. [23]9/2005. [16] Schaad,J., Housley R.:J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394,IETF,September 2002.[24][17] Baugher, M., Weis, B., Hardjono, T., and H. Harney,H.:"The Group Domain of Interpretation", RFC 3547,IETF,July 2003.[25][18] Harney, H.,Colegrove, A., Harder, E.,Meth, U.,Fleischer, R.: "GroupColegrove, A., and G. Gross, "GSAKMP: Group Secure Association Key Management Protocol",<draft-ietf- msec-gsakmp-sec-08.txt>, Internet Draft, Work in Progress (MSEC WG). [26]RFC 4535, June 2006. [19] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm,F.: "Group"Multicast Security (MSEC) Group Key Management Architecture",<draft-ietf-msec-gkmarch-08.txt>, Internet Draft, Work in Progress (MSEC WG). [27]RFC 4046, April 2005. [20] Baugher, M., McGrew,Oran, Blom,D., Naslund, M., Carrara,Naslund:E., and K. Norrman, "The Secure Real-time TransportProtocol",Protocol (SRTP)", RFC 3711,IETF,March 2004.[28][21] ITU-T RecommendationH.235V3Amd1 Corr1, "Security and encryptionH.235.0, " H.323 Security framework: Security framework for H-series (H.323 and otherH.245-based)H.245 based) multimediaterminals", (01/2005). [29] C. Adams et al:systems", (09/2005). [22] Adams, C., Farrell, S., Kause, T., and T. Mononen, "Internet X.509 Public Key Infrastructure Certificate ManagementProtocols"; draft-ietf-pkix-rfc2510bis- 09.txt, Internet Draft, Work in Progress (PKIX WG). HMAC-authenticated Diffie-Hellman for MIKEY April 2005 [30] M. Myers et al:Protocol (CMP)", RFC 4210, September 2005. [23] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560,IETF,June 1999.[31] C. Adams et al:[24] Adams, C., Sylvester, P., Zolotarev, M., and R. Zuccherato, "Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols", RFC 3029,IETF,February 2001.[32] M. Myers:[25] Schaad, J., "Internet X.509 Public Key Infrastructure Certificate Request MessageFormat",Format (CRMF)", RFC2511, IETF, March 1999. [33] M. Cooper et al:4211, September 2005. [26] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R. Nicholas, "Internet X.509 Public Key Infrastructure: Certification Path Building",<draft-ietf-pkix-certpathbuild- 05.txt>, Internet Draft, Work in Progress (PKIX WG). [34] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3978, March 2005. [35] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP 79,RFC3979, March4158, September 2005.[36] J.[27] Rosenberg, J. and H.Schulzrinne:Schulzrinne, "An Offer/Answer Model withtheSession Description Protocol (SDP)", RFC 3264,IETF,June 2002. [37] IANA MIKEY Payload Name Spaces per[RFC3830],RFC 3830, seehttp://www.iana.org/assignments/mikey-payloadshttp://www.iana.org/assignments/mikey-payloads. [29] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, November 2005. [30] Bellovin, S.M. and E.K. Rescorla: "Deploying a New Hash Algorithm", October 2005, http://www.cs.columbia.edu/~smb/papers/new-hash.pdf. [31] Milne, A., Blaser, M., Brown, D., and L. Dondetti, "ECC Algorithms For MIKEY", Work in Progress, June 2005. [32] Bellare, M.: "New Proofs for NMAC and HMAC: Security Without Collision-Resistance", http://eprint.iacr.org/2006/043.pdf, November 2005. [33] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "An additional mode of key Distribution in MIKEY: MIKEY-RSA-R", Work in Progress, August 2006. AppendixAA. Usage of MIKEY-DHHMAC in H.235 This appendix provides informative overview how MIKEY-DHHMAC can be applied in some H.323-based multimedia environments. Generally, MIKEY is applicable for multimedia applications including IP telephony.[22][15] describes various use cases of the MIKEY key management protocols (MIKEY-PS, MIKEY-PK, MIKEY-DHSIGN and MIKEY- DHHMAC) with the purpose to establish TGK keying material among H.323 endpoints. The TGKs are then used for media encryption by applying SRTP[27].[20]. Addressed scenarios include point-to-point with one or more intermediate gatekeepers (trusted or partially trusted)in-between. HMAC-authenticated Diffie-Hellman for MIKEY April 2005in between. One particular use case addresses MIKEY-DHHMAC to establish a media connection from an endpoint B calling (through a gatekeeper) to another endpoint A that is located within that same gatekeeper zone. While EP-A and EP-B typically do not share any auth_key a priori, some separate protocol exchange means are achieved outside the actual call setup procedure to establish an auth_key for the time while endpoints are being registered with the gatekeeper; such protocols exist[22][15] but are not shown in this document. The auth_key between the endpoints is being used to authenticate and integrity protect the MIKEY-DHHMAC messages. To establish a call, it is assumed that endpoint B has obtained permission from the gatekeeper (not shown). Endpoint B as the caller builds the MIKEY-DHHMACI_message(seeI_message (see section 3) and sends the I_message encapsulated within the H.323-SETUP to endpoint A. A routing gatekeeper (GK) would forward this message to endpoint B; in case of a non-routing gatekeeper, endpoint B sends the SETUP directly to endpoint A. In either case, H.323 inherent security mechanisms[28][21] are applied to protect the (encapsulation) message during transfer. This is not depicted here. The receiving endpoint A is able to verify the conveyed I_message and can compute a TGK. Assuming that endpoint A would accept the call, EP-A then builds the MIKEY-DHHMAC R_message and sends the response as part of the CallProceeding-to-Connect message back to the calling endpoint B (possibly through a routing gatekeeper). Endpoint B processes the conveyed R_message to compute the same TGK as the called endpoint A. 1.) EP-B -> (GK) -> EP-A: SETUP(I_fwd_message [, I_rev_message]) 2.) EP-A -> (GK) -> EP-B: CallProceeding-to-CONNECT(R_fwd_message [, R_rev_message]) Notes: If it is necessary to establish directional TGKs for full- duplex links in both directions B->A and A->B, then the calling endpoint B instantiates the DHHMAC protocol twice: once in the direction B->A using I_fwd_message and another run in parallel in the direction A->B using I_rev_message. In that case, two MIKEY-DHHMAC I_messages are encapsulated within SETUP (I_fwd_message and I_rev_message) and twoHMAC-authenticated Diffie-Hellman for MIKEY April 2005MIKEY-DHHMAC R_messages (R_fwd_message and R_rev_message) areencapsultedencapsulated within CallProceeding-to-CONNECT. The I_rev_message corresponds with the I_fwd_message. Alternatively, the called endpoint A may instantiate the DHHMAC protocol in a separate run with endpoint B (not shown); however, this requires a third handshake to complete. For more details on how the MIKEY protocols may be deployed with H.235, please refer to[22]. HMAC-authenticated Diffie-Hellman for MIKEY April 2005[15]. Author's Address Martin Euchner Hofmannstr. 51 81359 Munich, Germany Phone: +49 89 722 55790 Fax: +49 89 722 62366 EMail: martin_euchner@hotmail.com Full Copyright Statement Copyright (C) The Internet Society(2004).(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. 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. Intellectual PropertyRightsThe 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.HMAC-authenticated Diffie-HellmanAcknowledgement Funding forMIKEY April 2005 Expiration Date This Internet Draft expires on 30 October 2005. [Note tothe RFCeditor: Please remove the entire following section prior to publication.] Revision History Changes against draft-ietf-msec-mikey-dhhmac-10.txt: * A few editorial bugs removed. * References updated. Changes against draft-ietf-msec-mikey-dhhmac-09.txt: *IESG review feedback incorporated; generally, only editorial corrections. * Section 2.1.1 moved into new Appendix A. * IANA considerations section reworked and clarified. Changes against draft-ietf-msec-mikey-dhhmac-08.txt: * PKIX removed; some minor editorials. Changes against draft-ietf-msec-mikey-dhhmac-07.txt: * Feedback addressed from AD review. * added considerations on the possible impact of PKIX protocols and operations to end systems with real-time constraints (section 1). * added note that DH groupEditor function istransmitted explicitly but not the parameters g and p; see section 3. * added considerations on clock synchronization and timestamps in section 2 and in section 5.3 in the view of consequences on replay protection. * references updated. * editorial corrections and cleanup. Changes against draft-ietf-msec-mikey-dhhmac-06.txt: * Abstract reworded. HMAC-authenticated Diffie-Hellman for MIKEY April 2005 * used new RFC boilerplate: changed/moved IPR statement (now atprovided by thebeginning), status of Memo, and Intellectual Property Rights section in accordance with RFC 3667, RFC 3668. * ID nits removal. * References updated. * Note added to section 4.1 explaining how to differentiate between MIKEY and DHHMAC. * New section 4.4 added that describes the use of the general extension payload to avoid bidding-down attacks. * Description of the bidding-down avoidance mechanism removed from the threat model in section 5.2. * IANA considerations section re-written and aligned with MIKEY. * Open issue on KMID pointed in IANA considerations section. * editorial clean-up. Changes against draft-ietf-msec-mikey-dhhmac-05.txt: * HMAC-SHA1-96 option removed (see section 1.2, 4.2, 5.3,). This option does not really provide much gain; removal reduces number of options. * IDr added to I_message for DoS protection of the recipient; see section 3, 3.1, 5.3. * References updated. Changes against draft-ietf-msec-mikey-dhhmac-04.txt: * Introduction section modified: PFS property of DH, requirement for 4th MIKEY key management variant motivated. * MIKEY-DHSIGN, MIKEY-PK and MIKEY-PS added to section 1.2 Abbreviations. * Note on secure time synchronization added to section 2.0. * New section 2.2 "Relation to GMKARCH" added. * New section 2.1.1 "Usage in H.235" added: this section outlines a use case of DHHMAC in the context of H.235. * Trade-off between identity-protection and security & performance added to section 5.1. * New section 5.6 "Authorization and Trust Model" added. * Some further informative references added. HMAC-authenticated Diffie-Hellman for MIKEY April 2005 Changes against draft-ietf-msec-mikey-dhhmac-03.txt: * RFC 3552 available; some references updated. Changes against draft-ietf-msec-mikey-dhhmac-02.txt: * text allows both random and pseudo-random values. * exponentiation ** changed to ^. * Notation aligned with MIKEY-07. * Clarified that the HMAC is calculated over the entire MIKEY message excluding the MAC field. * Section 4.2: The AES key wrap method SHALL not be applied. * Section 1: Relationship with other, existing work mentioned. Changes against draft-ietf-msec-mikey-dhhmac-01.txt: * bidding-down attacks addressed (see section 5.2). * optional [X], [X, Y] defined and clarified (see section 1.1, 5.3). * combination of options defined in key update procedure (see section 3.1). * ID payloads clarified (see section 3 and 5.2). * relationship with MIKEY explained (roundtrip, performance). * new section 2.1 on applicability of DHHMAC for SIP/SDP and H.323 added. * more text due to DH resolution incorporated in section 5.3 regarding PFS, security robustness of DH, generalization capability of DH to general groups in particular EC and "future-proofness". * a few editorials and nits. * references adjusted and cleaned-up. Changes against draft-ietf-msec-mikey-dhhmac-00.txt: * category set to proposed standard. * identity protection clarified. * aligned with MIKEY-05 DH protocol, notation and with payload * some editorials and nits. HMAC-authenticated Diffie-Hellman for MIKEY April 2005 Changes against draft-euchner-mikey-dhhmac-00.txt: * made a MSEC WG draft * aligned with MIKEY-03 DH protocol, notation and with payload formats * clarified that truncated HMAC actually truncates the HMAC result rather than the SHA1 intermediate value. * improved security considerations section completely rewritten in the spirit of [8]. * IANA consideration section added * a few editorial improvements and corrections * IPR clarified and IPR section changed. Author's Addresses Martin Euchner Email: martin_euchner@hotmail.com Phone: +49 89 722 55790 Hofmannstr. 51 Fax: +49 89 722 62366 81359 Munich, GermanyIETF Administrative Support Activity (IASA).