Internet Engineering Task Force                               M. Euchner
Internet Draft                                                Siemens AG
Expires: August 2002
                                                           February 2002

              HMAC-authenticated Diffie-Hellman for MIKEY

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

     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

     The list of current Internet-Drafts can be accessed at

     The list of Internet-Draft Shadow Directories can be accessed at

     The distribution of this memo is unlimited.

     Comments should be sent to the MSEC WG mailing list at and to the author.


     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
     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

     -    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",
     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_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

     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

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

  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

        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

     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

          * 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-

  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

  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

7. Normative References

[1]  J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman;
"MIKEY:Multimedia Internet KEYing", Internet Draft, Work in Progress

[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,

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:            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]