Internet Engineering Task Force M. Euchner Internet Draft Siemens AG Intended Category: Informational Expires: February 2003 August 2002 HMAC-authenticated Diffie-Hellman for MIKEY (draft-ietf-msec-mikey-dhhmac-00.txt) Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. The distribution of this memo is unlimited. Comments should be sent to the MSEC WG mailing list at msec@securemulticast.org and to the author. Abstract This document describes a point-to-point key management protocol variant for the multimedia Internet keying (MIKEY). In particular, the classic Diffie-Hellman key agreement protocol is used for key establishment in conjunction with a keyed hash (HMAC-SHA1) for achieving mutual authentication and message integrity of the key management messages exchanged. This MIKEY variant is called the HMAC-authenticated Diffie-Hellmann (DH-HMAC). It addresses the security and performance constraints of multimedia key management in MIKEY. Martin Euchner [Page 1] HMAC-authenticated Diffie-Hellman for MIKEY August 2002 Table of Contents 1. Introduction.....................................................3 1.1. Notational Conventions.........................................4 1.2. Definitions....................................................5 1.3. Abbreviations..................................................5 2. Scenario.........................................................6 3. DH-HMAC Security Protocol........................................6 3.1. TGK re-keying..................................................7 4. DH-HMAC payload formats..........................................8 4.1. Common header payload (HDR)....................................8 4.2. Key data transport payload (KEMAC).............................9 4.3. ID payload (ID)................................................9 5. Security Considerations.........................................10 5.1. Security environment..........................................10 5.2. Threat model..................................................10 5.3. Security features and properties..............................11 5.4. Assumptions...................................................14 5.5. Residual risk.................................................15 6. IANA considerations.............................................16 7. Intellectual Property Rights....................................16 8. Acknowledgements................................................16 9. Conclusions.....................................................16 10. Normative References...........................................17 11. Informative References.........................................17 12. Author's Address...............................................18 13. Expiration Date................................................18 14. Revision History...............................................18 Euchner Expiration: 2/2003 [Page 2] HMAC-authenticated Diffie-Hellman for MIKEY August 2002 1. Introduction As pointed out in MIKEY (see [1]), secure real-time multimedia applications demand a particular adequate key management scheme that cares for how to securely and efficiently establish dynamic session keys in a conversational multimedia scenario. In general, MIKEY scenarios cover peer-to-peer, simple-one-to-many and small-sized groups. MIKEY in particular, describes three key management schemes for the peer-to-peer case that all finish their task within one round trip: - a symmetric key distribution protocol based upon pre-shared master keys; - a public-key encryption-based key distribution protocol assuming a public-key infrastructure with RSA-based private/public keys and digital certificates; - and a Diffie-Hellman key agreement protocol deploying digital signatures and certificates. All these three key management protocols are designed such that they complete their work within just one round trip. This requires depending on loosely synchronized clocks and deploying timestamps within the key management protocols. However, it is known [4] that each of the three key management schemes has its subtle constraints and limitations: - The symmetric key distribution protocol is simple to implement but does not nicely scale in any larger configuration of potential peer entities due to the need of mutually pre-assigned shared master secrets. Moreover, the security provided does not achieve the property of perfect forward secrecy; 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 initiator on choosing a good and secure session secret; the responder neither is able to participate in the key generation nor to influence that process. This is considered as a specific limitation in less trusted environments. - The public-key encryption scheme depends upon a public-key infrastructure that certifies the private-public keys by issuing and maintaining digital certificates. While such a key management scheme provides full scalability in large networked configurations, public-key infrastructures are still not widely available and in general, implementations are significantly more complex. Euchner Expiration: 2/2003 [Page 3] HMAC-authenticated Diffie-Hellman for MIKEY August 2002 Further additional round trips might be necessary for each side in order to ascertain verification of the digital certificates. Finally, as in the symmetric case, the responder depends completely upon the initiator choosing good and secure session keys. - The third MIKEY 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 upon. As in the previous method, this introduces the dependency upon a public-key infrastructure with its strength on scalability but also the limitations on computational costs in performing the asymmetric long-integer operations and the potential need for additional communication for verification of the digital certificates. However, the Diffie-Hellman key agreement protocol is known for its subtle security strengths in that it is able to provide full perfect secrecy and further have both parties actively involved in session key generation. This document describes a fourth 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 that protocol is to apply the Diffie-Hellman key agreement but instead of deploying a digital signature for authenticity of the exchanged keying material rather uses a keyed- hash upon using symmetrically pre-assigned shared secrets. This combination of security mechanisms is called the HMAC-authenticated Diffie-Hellman key agreement for MIKEY (DH-HMAC). Like the MIKEY Diffie-Hellman protocol, DH-HMAC 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. Notational Conventions The key word "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. Euchner Expiration: 2/2003 [Page 4] HMAC-authenticated Diffie-Hellman for MIKEY August 2002 1.2. Definitions The definitions and notations in this document are aligned with MIKEY, see [1] and [1] sections 1.2 - 1.3. All large integer computations in this document should be understood as being mod p within some fixed group G for some large prime p; see [1] section 3.3; however, the DH-HMAC protocol is applicable in general to other appropriate 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 [1] sections 4.1.3 and 4.1.5. 1.3. Abbreviations auth_key pre-shared authentication key, PRF-derived from pre-shared key s. DH Diffie-Hellman DHi public Diffie-Hellman half key g**(xi) of Initiatior DHr public Diffie-Hellman half key g**(xr) of Responder DH-HMAC HMAC-authenticated Diffie-Hellman DoS Denial-of-service G Diffie-Hellman group HDR MIKEY common header payload HMAC keyed Hash Message Authentication Code HMAC-SHA1 HMAC using SHA1 as hash function (160-bit result) HMAC-SHA-1-96 HMAC-SHA1 truncated to 96 bits IDi Identity of initiator IDr Identity of receiver IKE Internet Key Exchange IPSEC Internet Protocol Security MIKEY Multimedia Internet KEYing p Diffie-Hellman prime modulus PRF MIKEY pseudo-random function (see [1] section 4.1.3.) RSA Rivest, Shamir and Adleman s pre-shared key SOI Son-of-IKE SP MIKEY Security Policy (Parameter) Payload T timestamp TEK Traffic Encryption Key TGK MIKEY TEK Generation Key as the common Diffie- Hellman shared secret TLS Transport Layer Security xi secret, random Diffie-Hellman key of Initiator xr secret, random Diffie-Hellman key of Responder Euchner Expiration: 2/2003 [Page 5] HMAC-authenticated Diffie-Hellman for MIKEY August 2002 2. Scenario The HMAC-authenticated Diffie-Hellman key agreement protocol (DH-HMAC) for MIKEY addresses the same scenarios and scope as the other three key management schemes in MIKEY address. DH-HMAC is applicable in a peer-to-peer group where no access to a public-key infrastructure can be assumed available. Rather, pre- shared master secrets are assumed 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 it's peer using the DH- MAC key agreement protocol. As is the case for the other three MIKEY key management protocol, DH-HMAC assumes loosely synchronized clocks among the entities in the small group. 3. DH-HMAC Security Protocol The following figure defines the security protocol for DH-HMAC: Initiator Responder I_message = HDR, T, RAND, [IDi], {SP}, DHi, KEMAC I_message -----------------------> R_message = HDR, T, [Idr], IDi, DHr, DHi, KEMAC R_message <---------------------- TGK = g**(xi * yi) TGK = g**(xi * yi) Figure 1: HMAC-authenticated Diffie-Hellman key based exchange, where xi and xr are randomly chosen respectively by the initiator and the responder. The DH-HMAC key exchange SHALL be done according to Figure 1. The initiator chooses a random value xi, and sends an HMACed message including g**xi and a timestamp to the responder (optionally also including its identity). The group parameters (e.g., the group G) are a set of parameters chosen by the initiator. The responder chooses a random positive integer xr, and sends an HMACed message including g**xr and the Euchner Expiration: 2/2003 [Page 6] HMAC-authenticated Diffie-Hellman for MIKEY August 2002 timestamp to the initiator (optionally also providing its identity). Both parties then calculate the TGK, g**(xi * xr). The HMAC authentication is due to provide authentication of the DH half-keys, and is necessary to avoid man-in-the-middle attacks. This approach is the less expensive than digitally signed Diffie- Hellman. It requires first of all, that both sides compute one exponentiation and one HMAC, then one HMAC verification and finally another Diffie-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 overall round trip delay as well as reduce the risk of denial-of-service attacks. Processing of the TGK SHALL be accomplished as described in MIKEY [1] chapter 4. The computed HMAC result SHALL be conveyed in the KEMAC payload field where the MAC fields holds the HMAC result. The HMAC shall be computed over the entire message using auth_key, see also section 4.2. 3.1. TGK re-keying TGK re-keying for DH-HMAC generally proceeds as described in [1] section 4.5. Specifically, figure 2 provides the message fields for DH-HMAC update message. Initiator Responder I_message = HDR, T, [IDi], {SP}, [Dhi], KEMAC I_message -----------------------> R_message = HDR, T, [Idr], IDi, [DHr, Dhi], KEMAC R_message <---------------------- [TGK = g**(xi * yi)] [TGK = g**(xi * yi)] Figure 2: DH-HMAC update message Euchner Expiration: 2/2003 [Page 7] HMAC-authenticated Diffie-Hellman for MIKEY August 2002 4. DH-HMAC payload formats This section specifies the payload formats and data type values for DH-HMAC, see also [1] chapter 6 for a definition of the MIKEY payloads. The following referenced MIKEY payloads are used for DH-MAC: * Common header payload (HDR), see section 4.1 and [1] section 6.1 * SRTP ID sub-payload, see [1] section 6.1.1, * Key data transport payload (KEMAC), see section 4.2 and [1] section 6.2 * DH data payload, see [1] section 6.4 * Timestamp payload, [1] section 6.6 * ID payload, [1] section 6.7 * Security Policy payload (SP), [1] section 6.10 * RAND payload (RAND), [1] section 6.11 * Error payload (ERR), [1] section 6.12 * General Extension Payload, [1] section 6.15 4.1. Common header payload (HDR) Referring to [1] section 6.1, for DH-HMAC the following data type SHALL be used: Data type | Value | Comment -------------------------------------- DHHMAC init | 7 | Initiator's DH-HMAC exchange message DHHMAC resp | 8 | Responder's DH-HMAC exchange message Error | 6 | Error message, see [1] section 6.12 The next payload field shall be one of the following values: Next payload| Value | Section ------------------------------------------------------ Last payload| 0 | - KEMAC | 1 | section 4.2 and [1] section 6.2 DH | 3 | [1] section 6.4 T | 5 | [1] section 6.6 ID | 6 | [1] section 6.7 SP | 10 | [1] section 6.10 RAND | 11 | [1] section 6.11 Euchner Expiration: 2/2003 [Page 8] HMAC-authenticated Diffie-Hellman for MIKEY August 2002 ERR | 12 | [1] section 6.12 General Ext.| 21 | [1] section 6.15 Other defined next payload values defined in [1] shall not be applied to DH-HMAC. The responder in case of a decoding error or of a failed HMAC authentication verification SHALL apply the Error payload data type. 4.2. Key data transport payload (KEMAC) DH-HMAC shall apply this payload for conveying the HMAC result along with the indicated authentication algorithm. KEMAC when used in conjunction with DH-HMAC shall not convey any encrypted data; thus Encr alg shall be set to 2 (NULL), Encr data len shall be set to 0 and Encr data shall be left empty. For DH-HMAC, this key data transport payload shall be the last payload in the message. Note that the Next payload field is set to Last payload. The HMAC is then calculated over the entire MIKEY message using auth_key as described in [1] section 5.2 and then stored within MAC field. MAC alg | Value | Comments -------------------------------------------------------- HMAC-SHA-1 | 0 | Mandatory, Default (see [SHA1]) NULL | 1 | Very restricted use, see | [1] section 4.2.4 HMAC-SHA-1-96 | 5 | Optional, HMAC-SHA1 truncated to the 96 | leftmost bits of the HMAC-SHA-1 result | when represented in network byte order. HMAC-SHA-1 is the default hash function that MUST be implemented as part of the DH-HMAC. The length of the HMAC-SHA-1 result is 160 bits. HMAC-SHA-1-96 produces a slightly shorter HMAC result where the HMAC-SHA-1 result SHALL be truncated to the 96 leftmost bits when represented in network byte order. This saves some bandwidth. 4.3. ID payload (ID) For DH-HMAC, this payload shall only hold a non-certificate based identify. Euchner Expiration: 2/2003 [Page 9] HMAC-authenticated Diffie-Hellman for MIKEY August 2002 5. Security Considerations This document addresses key management security issues throughout. For a comprehensive explanation of MIKEY security considerations, please refer to MIKEY [1] section 9. In addition to that, this document addresses security issues according to [5] where the following security considerations apply in particular to this document: 5.1. Security environment Generally, the DH-HMAC security protocol described in this document focuses primarily on communication security; i.e. the security issues concerned with the MIKEY DH-HMAC protocol. Nevertheless, some system security issues are of interest as well that are not explicitly defined by the DH-HMAC protocol, but should be provided locally in practice. The system where the DH-HMAC protocol entity runs upon shall provide the capability to generate random numbers as input to the Diffie-Hellman operation (see [6], [14]). Further, the system shall be capable of storing the generated random data, secret data, keys and other secret security parameters securely (i.e. confidential and safe from unauthorized tampering). 5.2. Threat model The threat model that this documents adheres to covers the issues of end-to-end security in the Internet generally; without ruling out the possibility that MIKEY DH-HMAC be deployed in a corporate, closed IP environment. This also includes the possibility that MIKEY DH-HMAC be deployed on a hop-by-hop basis with some intermediate trusted "MIKEY DH-HMAC proxies" involved. Since DH-HMAC is a key management protocol, the following security threats are of concern: * Unauthorized interception of plain TGKs. This threat shall not occur. Nevertheless, for DH-HMAC 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: DH-HMAC protocol does not explicitly transmit the TGK at all. Rather, by the Diffie-Hellman "encryption" operation, that conceals the secret, random values, only partial information (i.e. the DH- half key) for construction of the TGK is transmitted. It is assumed that availability of such Diffie-Hellman half-keys to an eavesdropper does not result in any risk; see 5.4. Further, the DH-HMAC carries other data such as timestamps, random values, identification information or security policy parameters; eavesdropping of any such data is considered not to yield any significant security risk. * Masquerade of either entity: Euchner Expiration: 2/2003 [Page 10] HMAC-authenticated Diffie-Hellman for MIKEY August 2002 This security threat must be avoided and if a masquerade attack would be attempted, appropriate detection means must be in place. DH-HMAC 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 be avoided, and if present or attempted must be detected appropriately. DH-HMAC addresses this threat by providing mutual peer entity authentication and message integrity. * Loss of integrity: This security threats relates to unauthorized replay, deletion, insertion and manipulation of messages. While any such attacks cannot be avoided they must be detected at least. DH-HMAC addresses this threat by providing message integrity. 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 (see 5.4 below) it is widely believed that DH-HMAC is sufficiently secure and that such attacks be infeasible although the possibility of a successful attack cannot be ruled out completely. * Non-repudiation of the receipt or of the origin of the message: These are not requirements of this environment and thus related countermeasures not provided at all. * Denial-of-service or distributed denial-of-service attacks: Some considerations are given on some of those attacks, but DH-HMAC does not claim to provide full countermeasure against any of those attacks. For example, stressing the availability of the entities are not thwarted by means of the key management protocol; some other local countermeasures should be applied. Further, some DoS attacks are not countered such as interception of a valid DH- requests 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. 5.3. Security features and properties With the security threats in mind, this draft 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. Euchner Expiration: 2/2003 [Page 11] HMAC-authenticated Diffie-Hellman for MIKEY August 2002 * 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. The authentication occurs on the request and on the response 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 to avoid man-in-the-middle attacks on the exchanged messages in transit and in particular, on the otherwise non-authenticated exchanged Diffie-Hellman half keys. Note: This document does not address issues regarding authorization; this feature is not provided explicitly. However, DH-HMAC 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 countermeasure against man-in-the-middle attacks. The initiator may deploy a local timer that fires when the awaited response message did not arrive timely. This is to detect deletion of entire messages. * Replay protection of the messages is achieved using embedded timestamps. * 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 some denial-of-service attacks: malicious modification of messages and spam attacks with (replayed or masqueraded) messages. DH-HMAC probably does not explicitly counter sophisticated distributed denial-of-service attacks that compromise system availability for example. * Perfect-forward secrecy (PFS): Other than the MIKEY pre-shared and public-key based key distribution protocols, the Diffie-Hellman key agreement protocol features a security property called perfect forward secrecy. That is, that even if the long-term pre-shared key would be compromised at some point in time, this would not render past or future session keys compromised. Euchner Expiration: 2/2003 [Page 12] HMAC-authenticated Diffie-Hellman for MIKEY August 2002 As such, DH-HMAC but also digitally signed DH provides a far superior security level over the pre-shared or public-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 per se with the initiator distributing a key to its peers. Actually, both parties involved in the protocol exchange are able to equally contribute to the common Diffie- Hellman TEK traffic generating key. This reduces the risk of either party cheating or unintentionally generating a weak session key. This makes the DH-HMAC a fair key agreement protocol. In order for Diffie-Hellman key agreement to be secure, each party shall generate its xi or xr values using a strong, unpredictable pseudo-random generator. 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: The DH-HMAC key agreement protocol securely establishes a TGK within just one roundtrip. Other existing key management techniques like IPSEC-IKE [13], IPSEC-SOI and TLS [12] and other schemes are not deemed adequate in addressing sufficiently those real-time and security requirements. Using HMAC in conjunction with a strong one-way hash function such as SHA1 may be achieved more efficiently in software than expensive public-key operations. This yields a particular performance benefit of DH-HMAC over signed DH or the public-key encryption protocol. DH-HMAC optionally features a variant where the HMAC-SHA-1 result is truncated to 96-bit instead of 160 bits. It is believed that although the truncated HMAC appears significantly shorter, the security provided would not suffer; it appears even reasonable that the shorter HMAC could provide increased security against known-plaintext crypt-analysis, see RFC 2104 for more details. In any way, truncated DH-HMAC is able to reduce the bandwidth during Diffie-Hellman key agreement and yield better round trip delay on low-bandwidth links. If a very high security level is desired for long-term secrecy of the negotiated Diffie-Hellman shared secret, longer hash values may be deployed such as SHA256, SHA384 or SHA512 provide, possibly in conjunction with stronger Diffie- Hellman groups. For the sake of improved performance and reduced round trip delay either party may off-line pre-compute its public Diffie-Hellman half-key. On the other side and under reasonable conditions, DH-HMAC consumes more CPU cycles than the MIKEY pre-shared key distribution protocol. The same might hold true quite likely for Euchner Expiration: 2/2003 [Page 13] HMAC-authenticated Diffie-Hellman for MIKEY August 2002 the MIKEY public-key distribution protocol (depending on choice of the private and public key lengths). As such, it can be said that DH-HMAC provides sound performance when compared with the other MIKEY protocol variants. * Security infrastructure: This document describes the HMAC-authenticated Diffie-Hellman key agreement protocol that completely avoids digital signatures and the associated public-key infrastructure as would be necessary for the X.509 RSA public-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 certain environments nor may they be deemed adequate for real-time multimedia applications when taking additional steps for certificate validation and certificate revocation methods with additional round-trips into account. DH-HMAC does not depend on PKI nor do implementations require PKI standards and thus is believed to be much simpler than the more complex PKI facilities. DH-HMAC is particularly attractive in those environments where provisioning of a pre-shared key has already been accomplished. * Firewall-friendliness: DH-HMAC is able to operate smoothly through firewall/NAT devices as long as the protected identity information of the end entity is not an IP /transport address. Of course, DH-HMAC does not necessarily require a firewall/NAT to operate. * Scalability: Like the MIKEY signed Diffie-Hellman protocol, DH-HMAC does not scale to any larger configurations beyond peer-to-peer groups. 5.4. Assumptions This document states a couple of assumptions upon which the security of DH-HMAC significantly depends. It is assumed, that * the parameters xi, xr, s and auth_key are to be kept secret. * the pre-shared key s has sufficient entropy and cannot be effectively guessed. * the pseudo-random function (PRF) is secure, yields indeed the pseudo-random property and maintains the entropy. * a sufficiently large and secure Diffie-Hellman group is applied. * the 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 Euchner Expiration: 2/2003 [Page 14] HMAC-authenticated Diffie-Hellman for MIKEY August 2002 called the discrete logarithm assumption. Please see [9], [10] or [11] for more background information regarding the Diffie-Hellman problem and its computational complexity assumptions. * the hash function (SHA1) is secure; i.e. that it is computationally infeasible to find a message which corresponds to a given message digest, or to find two different messages that produce the same message digest. * the 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 applied to single blocks (see [2]). * A source capable of producing sufficiently many bits of randomness is available. * The systems upon which DH-HMAC runs are sufficiently secure. The assumptions must be met as far as they can be enforced. 5.5. Residual risk 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 upon the properties of the PRF, the Diffie-Hellman algorithm (discrete log-assumption), the HMAC and SHA1 algorithms have not been proved yet nor have they been disproved by the time of this writing. Thus, a certain residual risk remains, which might threaten the overall security at some unforeseeable time in the future. The DH-HMAC would be compromised as soon as * the discrete logarithm problem could be solved efficiently, * the hash function could be subverted (efficient collisions become feasible), * the HMAC method be broken (leaking the auth_key), * systematic brute force attacks are effective by which an attacker attempts to discover the shared secret. It is assumed that the shared secret yields sufficient entropy to make such attacks infeasible, * or some other yet unknown attacking technique will be discovered. Euchner Expiration: 2/2003 [Page 15] HMAC-authenticated Diffie-Hellman for MIKEY August 2002 It is not recommended to deploy DH-HMAC for any other usage than depicted in section 2. Otherwise any such misapplication might lead to unknown, undefined properties. 6. IANA considerations This document does not define its own new name spaces for DH-HMAC, rather additional values for DH-HMAC are defined as part of the MIKEY fields. Thus, close alignment between DH-HMAC values and MIKEY values shall be maintained; see also [1] section 10. 7. Intellectual Property Rights This proposal is in full conformity with [RFC-2026]. The author is aware of related intellectual property rights currently being held by Infineon. Pursuant to the provisions of [RFC-2026], the author represents that he has disclosed the existence of any proprietary or intellectual property rights in the contribution that are reasonably and personally known to the author. The author does not represent that he personally knows of all potentially pertinent proprietary and intellectual property rights owned or claimed by the organizations he represents or third parties. The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. 8. Acknowledgements This document incorporates kindly review feedback by Steffen Fries and Fredrick Lindholm. 9. Conclusions Key management for environments and applications with real-time and performance constraints are becoming of interest. Existing key management techniques like IPSEC-IKE [13] and IPSEC-SOI, TLS [12] and Euchner Expiration: 2/2003 [Page 16] HMAC-authenticated Diffie-Hellman for MIKEY August 2002 other schemes are not deemed adequate in addressing sufficiently those real-time and security requirements. MIKEY defines three key management security protocols addressing real-time constraints. DH-HMAC described in this document defines a fourth MIKEY variant aiming at the same target. While each of the four key management protocols has its own merits there are also certain limitations of each approach. As such there is no single ideal solution and none of the variants is able to subsume the other remaining variants. It is concluded that DH-HMAC features useful security and performance properties that none of the other three MIKEY variants is able to provide. 10. Normative References [1] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman; "MIKEY:Multimedia Internet KEYing", Internet Draft , Work in Progress (MSEC WG) [2] H. Krawczyk, M. Bellare, R. Canetti; "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [3] NIST, FIBS-PUB 180-1, "Secure Hash Standard", April 1995, http://csrc.nist.gov/fips/fip180-1.ps 11. Informative References [4] A.J. Menezes, P v. Oorschot, S. Vanstone: "Applied Cryptography", CRC Press, 1996 [5] E. Rescorla, B. Korver: " Guidelines for Writing RFC Text on Security Considerations", Work in Progress , August 2002. [6] D. Eastlake, S. Crocker: "Randomness Recommendations for Security", 1750, IETF, December 1994. [7] S.M. Bellovin, J. I. Schiller: "Security Mechanisms for the Internet", Work in Progress , June 2002. [8] S. Bradner: "The Internet Standards Process -- Revision 3", RFC 2026, IETF, October 1996 [9] A.J. Menezes, P. van Oorschot, S. A. Vanstone: "Handbook of Applied Cryptography", CRC Press 1996. [10] Ueli M. Maurer, S. Wolf: "The Diffie-Hellman Protocol", Designs, Codes, and Cryptography, Special Issue Public Key Cryptography, Kluwer Euchner Expiration: 2/2003 [Page 17] HMAC-authenticated Diffie-Hellman for MIKEY August 2002 Academic Publishers, vol. 19, pp. 147-171, 2000. ftp://ftp.inf.ethz.ch/pub/crypto/publications/MauWol00c.ps [11] Discrete Logarithms and the Diffie-Hellman Protocol; http://www.crypto.ethz.ch/research/ntc/dldh/ [12] T. Dierks, C. Allen: "The TLS Protocol Version 1.0.", RFC 2246, IETF, January 1999. [13] D. Harkins, D. Carrel: "The Internet Key Exchange (IKE).", RFC 2409, IETF, November 1998. [14] Donald E. Eastlake, Jeffrey I. Schiller, Steve Crocker: "Randomness Requirements for Security"; ; Work in Progress, IETF, 7/2002. [15] J. Schiller: "Strong Security Requirements for Internet Engineering Task Force Standard Protocols", RFC 3365, IETF; 2002. 12. Author's Address Please address all comments to: Martin Euchner Siemens AG Email: martin.euchner@icn.siemens.de ICN M SR 3 Phone: +49 89 722 55790 Hofmannstr. 51 Fax: +49 89 722 47713 81359 Munich, Germany 13. Expiration Date This Internet Draft expires on 30 February 2003. 14. Revision History 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 [5]. * IANA consideration section added * a few editorial improvements and corrections * IPR clarified and IPR section changed Euchner Expiration: 2/2003 [Page 18]