Internet Engineering Task Force M. Euchner Internet Draft Siemens AG Expires: August 2002 February 2002 HMAC-authenticated Diffie-Hellman for MIKEY (draft-euchner-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 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. It addresses the real-time aspects of multimedia key management in MIKEY. Martin Euchner [Page 1] HMAC-authenticated Diffie-Hellman for MIKEY February 2002 Table of Contents 1. Introduction....................................2 1.1. Notational Conventions..........................3 1.2. Definitions.....................................4 1.3. Abbreviations...................................4 2. Scenario........................................4 2.1. DH-HMAC Security Protocol.......................5 3. DH-HMAC payload formats.........................6 3.1. Common header payload...........................6 3.2. DH-HMAC data payload............................6 3.3. HMAC payload....................................6 4. Security Considerations.........................8 5. Acknowledgements................................9 6. Intellectual Property Rights....................9 7. Normative References............................9 8. Informative References.........................10 9. Author's Address...............................10 10. Expiration Date................................10 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. Euchner Expiration: 7/2002 [Page 2] HMAC-authenticated Diffie-Hellman for MIKEY February 2002 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. 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 among 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). 1.1. Notational Conventions Euchner Expiration: 7/2002 [Page 3] HMAC-authenticated Diffie-Hellman for MIKEY February 2002 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. 1.2. Definitions auth-key pre-shared authentication key IDa, IDb Identity of sender and receiver k_p common Diffie-Hellman shared secret T timestamp x, y secret, random value 1.3. Abbreviations DH Diffie-Hellman DH-HMAC HMAC-authenticated Diffie-Hellman HMAC keyed Hash Message Authentication HMAC-SHA1 HMAC using SHA1 as hash function MIKEY Multimedia Internet KEYing PMK Pre-Master Key RSA Rivest, Shamir and Adleman TEK Traffic Encryption Key 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 small-sized, peer-to-peer group where no access to a public-key infrastructure can be assumed available. Rather, pre-shared master secrets are available among the entities in such a small-sized group. In a small-sized 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. 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. Euchner Expiration: 7/2002 [Page 4] HMAC-authenticated Diffie-Hellman for MIKEY February 2002 2.1. DH-HMAC Security Protocol A B I = (IDa) K = g**x || T [|| I] A = HMAC (auth-key,K) K,A I' = (IDb) ----------------------> K' = g**y || T [|| I'] B' = HMAC (auth-key,K') K',B' <---------------------- k_p= g**(xy) k_p=g**(xy) Figure 1: HMAC-authenticated Diffie-Hellman key based exchange, where x and y are randomly chosen respectively by A and B. The key exchange is done according to Figure 1. The initiator chooses a random value x, and sends an HMACed message including g**x 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 y, and sends an HMACed message including g**y and the timestamp to the initiator (optionally also providing its identity). Both parties then calculate the PMK, g**(xy). 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 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 TEK SHALL be accomplished as described in MIKEY chapter 4. The computed HMAC result A or B' SHALL be conveyed in the DH-HMAC payload field of the MIKEY payload as specified in chapter 5 of MIKEY. Euchner Expiration: 7/2002 [Page 5] HMAC-authenticated Diffie-Hellman for MIKEY February 2002 3. DH-HMAC payload formats This section specifies the payload formats and data type values for DH-HMAC. 3.1. Common header payload For DH-HMAC the following data type SHALL be used: Data type | Value | Comment -------------------------------------- DHHMAC init | 7 | Initiator's DH-HMAC exchange message DHMHAC resp | 8 | Responder's DH-HMAC exchange message The Error payload data type SHALL be applied by the responder in case of a decoding error or of a failed HMAC authentication verification. Hash func | Value | Comments -------------------------------------------------------- SHA-1 | 0 | Mandatory, Default (see [SHA1]) SHA-1-96 | 5 | Optional, SHA1 truncated to the 96 leftmost bits of SHA-1 result when represented in network byte order. SHA-1 is the default hash function that MUST be implemented as part of the DH-HMAC. The length of the HMAC result is 160 bits. SHA-1-96 produces a slightly shorter HMAC result where the SHA-1 result SHALL be truncated to the 96 leftmost bits when represented in network byte order. This will save some bandwidth. 3.2. DH-HMAC data payload There is no separate payload defined for DH-HMAC. Rather, the DH payload data as defined in MIKEY Appendix A.4 SHALL be used. 3.3. HMAC payload The HMAC payload carries the computed HMAC value upon the DH-MAC message and corresponding payload data. The HMAC MUST always be the last payload in the DH-HMAC exchange messages. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ HMAC ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Euchner Expiration: 7/2002 [Page 6] HMAC-authenticated Diffie-Hellman for MIKEY February 2002 * HMAC: The computed HMAC upon the entire message. The hashing function within HMAC shall be used as indicated by the hash func value (0 or 5). Appendix B. - Payload usage summary This section describes the relationship of DH-HMAC messages and the MIKEY payload types. Depending on the type of message, different payloads MUST and MAY be included. There are six distinct types of messages: * Pre-shared key transport message * Public key transport message * Verification message (for either pre-shared key or public key) * DH exchange message (bi-directional) * DH-HMAC exchange message (bi-directional) * Error message | Message Type Payload type | PS | PK | DH | DH-HMAC | Ver | Error ----------------------------------------------------------- PS data | M - - - - - PK data | - M* - - - - DH data | - - M M - - Ver msg | - - - - M - Error | - - - - - M Timestamp | M M M O - O ID | O O O O O O Signature | - O M - - - HMAC | - - - M - - Certificate | - O O - - - Cert hash | - O O - - - n_start | O O O O - - n_end | O O O O - - SPI | O O O O - - SP | O O O O - O When a payload is not included, the default values for the information carried by it SHALL be used (when applicable). The following table summarizes what messages may be included in a specific message. Euchner Expiration: 7/2002 [Page 7] HMAC-authenticated Diffie-Hellman for MIKEY February 2002 4. Security Considerations This document addresses key management security issues throughout. For a comprehensive explanation of security considerations, please refer to MIKEY section 10. In addition to that, the following security considerations apply in particular to this document: 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 master would be compromised at some point in time, this would not render past session keys compromised. Further, Diffie-Hellman key management protocol is not a strict key distribution protocol per se. Actually, both parties involved in the protocol exchange are able to equally contribute to the common Diffie-Hellman master session key. This reduces the risk of either party cheating or unintentionally generating a weak session key. In order for Diffie-Hellman key agreement to be secure, each party shall generate its x or y values using a strong, unpredictable pseudo- random generator. Further these values x or y shall be kept private. It is recommended that these secret values be destroyed once the common Diffie-Hellman shared secret key has been established. For the sake of improved performance and reduced round trip delay either party may off-line pre-compute its public Diffie-Hellman half- key. 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. 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. The HMAC computation corroborates for authentication and message integrity of the exchanged Diffie-Hellman half-keys and associated messages. The authentication is absolute necessary in order to avoid man-in-the-middle attacks on the exchanged messages in transit. Euchner Expiration: 7/2002 [Page 8] HMAC-authenticated Diffie-Hellman for MIKEY February 2002 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 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. 5. Acknowledgements 6. Intellectual Property Rights This proposal is in full conformity with [RFC-2026]. Siemens may have patent rights on technology described in this document which employees of Siemens contribute for use in IETF standards discussions. In relation to any IETF standard incorporating any such technology, Siemens hereby agrees to license on fair, reasonable and non-discriminatory terms, based on reciprocity, any patent claims it owns covering such technology, to the extent such technology is essential to comply with such standard. 7. 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 Euchner Expiration: 7/2002 [Page 9] HMAC-authenticated Diffie-Hellman for MIKEY February 2002 8. Informative References [4] A.J. Menezes, P v. Oorschot, S. Vanstone: "Applied Cryptography", CRC Press, 1996 9. 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 10. Expiration Date This Internet Draft expires on 30 August 2002. Euchner Expiration: 7/2002 [Page 10]