Internet Engineering Task Force - MSEC WG
   Internet Draft                                            M. Euchner
   Intended Category: Proposed Standard
   Expires: October 2005                                     April 2005

                HMAC-authenticated Diffie-Hellman for MIKEY

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   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

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

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

Euchner                 Expires - October 2005                [Page 1]

             HMAC-authenticated Diffie-Hellman for MIKEY   April 2005


   This document describes a light-weight 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",
   this document are to be interpreted as described in RFC-2119 [2].

Table of Contents

   1.   Introduction................................................3
   1.1.   Definitions...............................................6
   1.2.   Abbreviations.............................................7
   2.   Scenario....................................................8
   2.1.   Applicability.............................................9
   2.2.   Relation to GKMARCH.......................................9
   3.   DHHMAC Security Protocol...................................10
   3.1.   TGK re-keying............................................12
   4.   DHHMAC payload formats.....................................13
   4.1.   Common header payload (HDR)..............................13
   4.2.   Key data transport payload (KEMAC).......................14
   4.3.   ID payload (ID)..........................................15
   4.4.   General Extension Payload................................15
   5.   Security Considerations....................................16
   5.1.   Security environment.....................................16
   5.2.   Threat model.............................................16
   5.3.   Security features and properties.........................19
   5.4.   Assumptions..............................................23

Euchner                 Expires - October 2005                [Page 2]

             HMAC-authenticated Diffie-Hellman for MIKEY   April 2005

   5.5.   Residual risk............................................24
   5.6.   Authorization and Trust Model............................26
   6.   Acknowledgments............................................26
   7.   IANA considerations........................................26
   8.   References.................................................27
   8.1  Normative References.......................................27
   8.2    Informative References...................................27
   Appendix A  Usage of MIKEY-DHHMAC in H.235......................30
   Full Copyright Statement........................................33
   Expiration Date.................................................34
   Revision History................................................34
   Author's Addresses..............................................37


  There is work done in IETF to develop key management schemes. For
  example, IKE [14] is a widely accepted unicast scheme for IPsec, and
  the MSEC WG is developing other schemes, addressed to group
  communication [24], [25]. For reasons discussed below, there is
  however a need for a scheme with low latency, suitable for demanding
  cases such as real-time data over heterogeneous networks, and small
  interactive groups.

  As pointed out in MIKEY (see [3]), secure real-time multimedia
  applications demand a particular adequate light-weight 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 (MIKEY-PS) based upon
         pre-shared master keys;

     -   a public-key encryption-based key distribution protocol

Euchner                 Expires - October 2005                [Page 3]

             HMAC-authenticated Diffie-Hellman for MIKEY   April 2005

         (MIKEY-PK) assuming a public-key infrastructure with RSA-based
         (Rivest, Shamir and Adleman) private/public keys and digital

     -   and a Diffie-Hellman key agreement protocol (MIKEY-DHSIGN)
         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 [7] that each of the three key management
  schemes has its subtle constraints and limitations:

      -  The symmetric key distribution protocol (MIKEY-PS) is simple
         to implement, however, 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 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 (MIKEY-PK) 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

Euchner                 Expires - October 2005                [Page 4]

             HMAC-authenticated Diffie-Hellman for MIKEY   April 2005

         still not widely available and in general, implementations are
         significantly more complex.

         Further, additional round trips 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
         infrastructure such as validating digital certificates (RFC
         3029, [31]), ascertaining the revocation status of digital
         certificates (RFC 2560, [30]) and asserting certificate
         policies, construction of certification path(s) ([33]),
         requesting and obtaining necessary certificates (RFC 2511,
         [32]) 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.  Such steps and tasks all result in further delay
         of the key agreement or key establishment phase among the end
         systems, negatively impacting setup time.  Any extra PKI
         handshakes and processing are not in scope of MIKEY and since
         this document deploys symmetric security mechanisms only,
         aspects of PKI, digital certificates and related processing
         are not further covered in this document.

         Finally, as in the symmetric case, the responder depends
         completely upon the initiator choosing good and secure session

      -  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
         both parties actively involved in session key generation.
         This special security property - despite the somewhat higher

Euchner                 Expires - October 2005                [Page 5]

             HMAC-authenticated Diffie-Hellman for MIKEY   April 2005

         computational 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 describes such a fourth light-weight 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 than deploying a digital signature
  for authenticity of the exchanged keying material, instead uses a
  keyed-hash upon using symmetrically pre-assigned shared secrets.
  This combination of security mechanisms is called the HMAC-
  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 with
  MIKEY, see [3], 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; see

Euchner                 Expires - October 2005                [Page 6]

             HMAC-authenticated Diffie-Hellman for MIKEY   April 2005

  [3] section 3.3; however, the DHHMAC protocol is applicable in
  general 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] 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 certain
  circumstance MAY allow X being optional and not be present thereby
  resulting in weaker security potentially.  Likewise [X, Y] represents
  an optional compound piece of information where the pieces X and Y
  SHOULD be either both present or MAY optionally be both absent.  {X}
  denotes zero or more occurrences of X.

  1.2.   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 the
     DHr             public Diffie-Hellman half key g^(xr) of the
     DHHMAC          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)
     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
     MIKEY-DHSIGN    MIKEY Diffie-Hellman key agreement protocol

Euchner                 Expires - October 2005                [Page 7]

             HMAC-authenticated Diffie-Hellman for MIKEY   April 2005

     MIKEY-PK        MIKEY public-key encryption-based key distribution
     MIKEY-PS        MIKEY pre-shared key distribution protocol
     p               Diffie-Hellman prime modulus
     PKI             Public-key Infrastructure
     PRF             MIKEY pseudo-random function (see [3] section
     RSA             Rivest, Shamir and Adleman
     s               pre-shared key
     SDP             Session Description Protocol
     SOI             Son-of-IKE, IKEv2
     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, (pseudo) random Diffie-Hellman key of the
     xr              secret, (pseudo) random Diffie-Hellman key of the


  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 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 its peer using the DH-
  MAC key agreement protocol.

Euchner                 Expires - October 2005                [Page 8]

             HMAC-authenticated Diffie-Hellman for MIKEY   April 2005

  As 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 synchronization measures, however, sections 5.4 and 9.3
  of [3] provide implementation guidance on clock synchronization and

  2.1.   Applicability

  MIKEY-DHHMAC, as well as the other MIKEY key management protocols, is
  intended for application-level key management and is 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
  handshake session- or call signaling protocols such as

  a) SIP/SDP where the encoded MIKEY messages are encapsulated and
     transported in SDP containers of the SDP offer/answer [RFC 3264]
     handshake as described in [5],
  b) H.323 (see [22]) 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 option to the other MIKEY key management
  variants (MIKEY-pre-shared, MIKEY-public-key and 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] describes a
     generic architecture for multicast security group key management
     protocols.  In the context of this architecture, MIKEY-DHHMAC may

Euchner                 Expires - October 2005                [Page 9]

             HMAC-authenticated Diffie-Hellman for MIKEY   April 2005

     operate as a registration protocol, see also [3] 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 the pair-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
     possible where for example the responder acts as the group

     Note that MIKEY does not provide re-keying in the GKMARCH sense,
     only updating of the keys by normal unicast messages.

  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-Hellman key based exchange,
         where xi and xr are (pseudo) randomly chosen respectively
                    by the initiator and the responder.

     The DHHMAC key exchange SHALL be done according to Figure 1. The
     initiator chooses a (pseudo) random value 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, then IDi MAY

Euchner                 Expires - October 2005               [Page 10]

             HMAC-authenticated Diffie-Hellman for MIKEY   April 2005

     optionally 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, 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 group numbering, see [3] section 6.4); the
     actual group parameters g and p however are not explicitly
     transmitted but can be deduced from the Diffie-Hellman group G.
     The responder chooses a (pseudo) random positive integer 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, then IDr
     MAY optionally be left out.

     Both parties then calculate the TGK as g^(xi * xr).

     The HMAC authentication provides authentication of the DH half-
     keys, and is necessary to avoid man-in-the-middle attacks.

     This approach is less expensive than digitally signed Diffie-
     Hellman in that both sides compute first 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
     [3] 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

Euchner                 Expires - October 2005               [Page 11]

             HMAC-authenticated Diffie-Hellman for MIKEY   April 2005

     be computed over the entire message excluding the MAC field using
     auth_key, see also section 4.2.

  3.1.   TGK re-keying

     TGK re-keying for DHHMAC generally proceeds as described in [3]
     section 4.5.  Specifically, figure 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, fresh DHi
         and the responder SHALL respond with a new, fresh DHr and the
         received DHi.

     b) Non-key related information update without any Diffie-Hellman
         half-keys included in the exchange.  Such transaction does not
         change the actual TGK but updates other information like
         security policy parameters for example.  To only update the
         non-key related information, [DHi] and [DHr, DHi] SHALL be left

Euchner                 Expires - October 2005               [Page 12]

             HMAC-authenticated Diffie-Hellman for MIKEY   April 2005

  DHHMAC payload formats

  This section specifies the payload formats and data type values for
  DHHMAC, see also [3] chapter 6 for a definition of the MIKEY

  This document does not define new payload formats but re-uses MIKEY
  payloads for DHHMAC as referenced:

  * Common header payload (HDR), see section 4.1 and [3] section 6.1

  * SRTP ID sub-payload, see [3] section 6.1.1,

  * Key data transport payload (KEMAC), see section 4.2 and [3] section

  * DH data payload, see [3] section 6.4

  * Timestamp payload, [3] section 6.6

  * ID payload, [3] section 6.7

  * Security Policy payload (SP), [3] section 6.10

  * RAND payload (RAND), [3] section 6.11

  * Error payload (ERR), [3] section 6.12

  * General Extension Payload, [3] section 6.15

  4.1.   Common header payload (HDR)

     Referring to [3] section 6.1, for DHHMAC the following data types
     SHALL be used:

        Data type     | Value | Comment

Euchner                 Expires - October 2005               [Page 13]

             HMAC-authenticated Diffie-Hellman for MIKEY   April 2005

        DHHMAC init   |     7 | Initiator's DHHMAC exchange message
        DHHMAC resp   |     8 | Responder's DHHMAC exchange message
        Error         |     6 | Error message, see [3] 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] section 6.2
     DH          |     3 | [3] section 6.4
     T           |     5 | [3] section 6.6
     ID          |     6 | [3] section 6.7
     SP          |    10 | [3] section 6.10
     RAND        |    11 | [3] section 6.11
     ERR         |    12 | [3] section 6.12
     General Ext.|    21 | [3] section 6.15

     Table 4.1.b

     Other defined next payload values defined in [3] SHALL not be
     applied to DHHMAC.

     The responder in case of a decoding error or of a failed HMAC
     authentication verification SHALL apply the Error payload data

  4.2.   Key data transport payload (KEMAC)

     DHHMAC SHALL apply this payload for conveying the HMAC result
     along with the indicated authentication algorithm. KEMAC when used
     in conjunction with DHHMAC SHALL not convey any encrypted data;
     thus Encr alg SHALL be set to 2 (NULL), Encr data len SHALL be set

Euchner                 Expires - October 2005               [Page 14]

             HMAC-authenticated Diffie-Hellman for MIKEY   April 2005

     to 0 and Encr data SHALL be left empty. The AES key wrap method
     (see [23]) 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
     MIKEY message excluding the MAC field using auth_key as described
     in [3] section 5.2 and then stored within the MAC field.

        MAC alg       | Value |           Comments
        HMAC-SHA-1    |     0 | Mandatory, Default (see [4])
        NULL          |     1 | Very restricted use, see
                              | [3] 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

  4.3.   ID payload (ID)

     For DHHMAC, this payload SHALL only hold a non-certificate based

  4.4.   General Extension Payload

     For DHHMAC and to avoid bidding-down attacks, this payload SHALL
     list all key management protocol identifiers of a surrounding
     encapsulation protocol such as for example, SDP [5].  The General
     Extension Payload SHALL be integrity-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]); see also [3] section 6.15.

Euchner                 Expires - October 2005               [Page 15]

             HMAC-authenticated Diffie-Hellman for MIKEY   April 2005

     Table 4.4.a

  Security Considerations

  This document addresses key management security issues throughout.
  For a comprehensive explanation of MIKEY security considerations,
  please refer to MIKEY [3] section 9.

  In addition to that, this document addresses security issues
  according to [8] where the following security considerations apply in
  particular to this document:

  5.1.   Security environment

  Generally, the DHHMAC security protocol described in this document
  focuses primarily on communication security; i.e. the security issues
  concerned with the MIKEY DHHMAC protocol.  Nevertheless, some system
  security issues are of interest as well that are not explicitly
  defined by the DHHMAC protocol, but should be provided locally in

  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]).  Furthermore, the system
  SHALL be capable of storing the generated (pseudo) 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, 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:

Euchner                 Expires - October 2005               [Page 16]

             HMAC-authenticated Diffie-Hellman for MIKEY   April 2005

  * Unauthorized interception of plain TGKs:
    For DHHMAC 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. the 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 is considered not to yield any
    significant security risk.

  * Masquerade of either entity:
    This security threat must be avoided and if a masquerade attack
    would be attempted, appropriate detection means must be in place.
    DHHMAC addresses this threat by providing mutual peer entity

  * 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.  DHHMAC addresses this threat by providing
    mutual peer entity authentication and message integrity.

  * Loss of integrity:
    This security threat relates to unauthorized replay, deletion,
    insertion and manipulation of messages.  While any such attacks
    cannot be avoided they must be detected at least.  DHHMAC addresses
    this threat by providing message integrity.

  * Bidding-down attacks:

Euchner                 Expires - October 2005               [Page 17]

             HMAC-authenticated Diffie-Hellman for MIKEY   April 2005

     When multiple key management protocols each of a distinct security
     level are offered (e.g., such as is possible by SDP [5]), 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 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 (see 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 this
    environment and thus related countermeasures are not provided at

  * 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 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-
    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
    for MIKEY-DHHMAC either, see [3].  No security protocol is known so
    far, that is able to provide the objectives of DHHMAC as stated in
    section 5.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 but

Euchner                 Expires - October 2005               [Page 18]

             HMAC-authenticated Diffie-Hellman for MIKEY   April 2005

    may 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 available of supplying trustworthy identity
    information; e.g., by relying on secured links underneath of MIKEY
    that supply trustworthy identity information otherwise.  However,
    it is understood that without identity information present, the
    MIKEY key management security protocols might be subject to
    security weaknesses such as masquerade, impersonation and
    reflection attacks particularly in end-to-end scenarios where no
    other secure means of assured identity information is provided.

    Leaving identity fields optional if possible thus should not be
    seen as a privacy method either, but rather as a protocol
    optimization feature.

  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.

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

Euchner                 Expires - October 2005               [Page 19]

             HMAC-authenticated Diffie-Hellman for MIKEY   April 2005

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

    The initiator may deploy a local timer that fires when the awaited
    response message did not arrive in a timely manner.  This is to
    detect deletion of entire messages.

  * Replay protection of the messages is achieved using embedded
    timestamps.  In order to detect replayed messages it is essential
    that the clocks among initiator and sender be roughly synchronized.
    The reader is referred to [3] section 5.4 and [3] section 9.3 that
    provide further considerations and give guidance on clock
    synchronization and timestamp usage.  Should the clock
    synchronization be lost, then end systems cannot detect replayed
    messages anymore resulting that the end systems cannot securely
    establish keying material.  This may result in a denial-of-service,
    see [3] 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 some denial-of-service
    attacks: malicious modification of messages and spam attacks with
    (replayed or masqueraded) messages.  DHHMAC probably does not
    explicitly counter sophisticated distributed, large-scale denial-

Euchner                 Expires - October 2005               [Page 20]

             HMAC-authenticated Diffie-Hellman for MIKEY   April 2005

    of-service attacks that compromise system availability 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 and avoids the recipient from creating unnecessary MIKEY

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

    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 as 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 DHHMAC a fair key agreement protocol. One may
    view this property as an additional distributed security measure
    that is increasing security robustness over the case where all the
    security depends just on the proper implementation of a single

    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 if a source of true randomness is not

Euchner                 Expires - October 2005               [Page 21]

             HMAC-authenticated Diffie-Hellman for MIKEY   April 2005

    available.  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 management techniques like IPsec-IKE [14],
    IPsec-IKEv2 [21] and TLS [13] and other schemes are not deemed
    adequate in addressing sufficiently those real-time and security
    requirements; they all use more than a single roundtrip.  All the
    MIKEY key management protocols are able to complete their task of
    security policy parameter negotiation including key-agreement or
    key distribution in one roundtrip.  However, the MIKEY pre-shared
    and the MIKEY public-key protocol both are able to complete their
    task even in a half-round trip when the confirmation messages are

    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 DHHMAC over signed DH or the public-key encryption

    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.  This is left as
    for further study.

    For the sake of improved performance and reduced round trip delay
    either party may off-line pre-compute its public Diffie-Hellman

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

Euchner                 Expires - October 2005               [Page 22]

             HMAC-authenticated Diffie-Hellman for MIKEY   April 2005

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

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

    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
    an IP /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.   Assumptions

Euchner                 Expires - October 2005               [Page 23]

             HMAC-authenticated Diffie-Hellman for MIKEY   April 2005

  This document states a couple of assumptions upon which the security
  of DHHMAC 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
    called the discrete logarithm assumption.  Please see [7], [11] or
    [12] 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 [6]).

  * a source capable of producing sufficiently many bits of (pseudo)
    randomness is available.

  * the system upon which DHHMAC runs is sufficiently secure.

  5.5.   Residual risk

Euchner                 Expires - October 2005               [Page 24]

             HMAC-authenticated Diffie-Hellman for MIKEY   April 2005

  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
  HMAC algorithm and SHA1 algorithms have been neither proven or
  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
  assumptions do not hold anymore.

  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 sufficient size and for groups upon elliptic
  curves.  RSA does not allow such generalization, as the core
  mathematical problem is a different one (large integer

  RSA asymmetric keys tend to become increasingly lengthy (1536 bits
  and more) and thus very computationally intensive.  Nevertheless,
  elliptic curve Diffie-Hellman (ECDH) allows to cut-down key lengths
  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 that elliptic 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 than RSA.  Note, that an elliptic-curve Diffie-Hellman
  variant of MIKEY remains for further study.

Euchner                 Expires - October 2005               [Page 25]

             HMAC-authenticated Diffie-Hellman for MIKEY   April 2005

  It is not recommended to deploy DHHMAC for any other usage than
  depicted in section 2.  Otherwise any such misapplication might lead
  to unknown, undefined properties.

  5.6.   Authorization and Trust Model

  Basically, similar remarks on authorization as stated in [3] section
  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 secret to yield 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 in conjunction with the
  assumption of a shared key simplifies the communication setup of the

  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 incorporates kindly valuable review feedback from
   Steffen Fries, Hannes Tschofenig, Fredrick Lindholm, Mary Barnes and
   Russell Housley and general feedback by the MSEC WG.

7.   IANA considerations

   This document does not define its own new name spaces for DHHMAC,
   beyond the IANA name spaces that have been assigned for MIKEY, see
   [3] section 10 and section 10.1, see also IANA MIKEY payload name
   spaces [37].

Euchner                 Expires - October 2005               [Page 26]

             HMAC-authenticated Diffie-Hellman for MIKEY   April 2005

   In order to align Table 4.1.a with [3] table 6.1.a, IANA is
   requested to add the following entries to their MIKEY Payload Name

   Data Type        Value  Reference

   ---------------  -----  ---------

   DHHMAC init          7  [RFCxxxx]
   DHHMAC resp          8  [RFCxxxx]

[Note to the RFC editor: Please replace RFCxxxx with the RFC number of
this document prior to publication.]

8.   References
   8.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. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman;
       "MIKEY: Multimedia Internet KEYing", RFC 3830 IETF, August 2004.

   [4] NIST, FIBS-PUB 180-1, "Secure Hash Standard", April 1995,

   [5] J. Arkko, E. Carrara et al: "Key Management Extensions for SDP
       and RTSP", Internet Draft <draft-ietf-mmusic-kmgmt-ext-14.txt>,
       Work in Progress (MMUSIC WG), IETF, March 2005.

   [6] H. Krawczyk, M. Bellare, R. Canetti: "HMAC: Keyed-Hashing for
       Message Authentication", RFC 2104, February 1997.

   8.2    Informative References

   [7] A.J. Menezes, P. van Oorschot, S. A. Vanstone: "Handbook of
       Applied Cryptography", CRC Press 1996.

Euchner                 Expires - October 2005               [Page 27]

             HMAC-authenticated Diffie-Hellman for MIKEY   April 2005

   [8] E. Rescorla, B. Korver: " Guidelines for Writing RFC Text on
       Security Considerations", RFC 3552, IETF, July 2003.

   [9] D. Eastlake, S. Crocker: "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] 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,

   [12] Discrete Logarithms and the Diffie-Hellman Protocol;

   [13] T. Dierks, C. Allen: "The TLS Protocol Version 1.0.", RFC 2246,
       IETF, January 1999.

   [14] D. Harkins, D. Carrel: "The Internet Key Exchange (IKE).", RFC
       2409, IETF, November 1998.

   [15] Donald 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,

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

Euchner                 Expires - October 2005               [Page 28]

             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: "SIP: Session Initiation Protocol", RFC
       3261, IETF, June 2002.

   [21] Ch. Kaufman: "Internet Key Exchange (IKEv2) Protocol", Work in
       Progress (IPSEC WG), <draft-ietf-ipsec-ikev2-17.txt>, Internet
       Draft, Work in Progress (IPSEC WG).

   [22] ITU-T Recommendation H.235 Annex G: "Usage of the MIKEY
       Key Management Protocol for the Secure Real Time Transport
       Protocol (SRTP) within H.235"; 1/2005.

   [23] Schaad, J., Housley R.: "Advanced Encryption Standard (AES)
       Key Wrap Algorithm", RFC 3394, IETF, September 2002.

   [24] Baugher, M., Weis, B., Hardjono, T., Harney, H.: "The Group
       Domain of Interpretation", RFC 3547, IETF, July 2003.

   [25] Harney, H., Colegrove, A., Harder, E., Meth, U., Fleischer, R.:
       "Group Secure Association Key Management Protocol", <draft-ietf-
       msec-gsakmp-sec-08.txt>, Internet Draft, Work in Progress (MSEC

   [26] Baugher, M., Canetti, R., Dondeti, L., and Lindholm, F.: "Group
       Key Management Architecture", <draft-ietf-msec-gkmarch-08.txt>,
       Internet Draft, Work in Progress (MSEC WG).

   [27] Baugher, McGrew, Oran, Blom, Carrara, Naslund: "The Secure
        Real-time Transport Protocol", RFC 3711, IETF, March 2004.

   [28] ITU-T Recommendation H.235V3Amd1 Corr1, "Security and
        encryption for H-series (H.323 and other H.245-based) multimedia
        terminals", (01/2005).

   [29] C. Adams et al: "Internet X.509 Public Key Infrastructure
        Certificate Management Protocols"; draft-ietf-pkix-rfc2510bis-
        09.txt, Internet Draft, Work in Progress (PKIX WG).

Euchner                 Expires - October 2005               [Page 29]

             HMAC-authenticated Diffie-Hellman for MIKEY   April 2005

   [30] M. Myers et al: "X.509 Internet Public Key Infrastructure
        Online Certificate Status Protocol - OCSP", RFC 2560, IETF, June

   [31] C. Adams et al: "Internet X.509 Public Key Infrastructure Data
        Validation and Certification Server Protocols", RFC 3029, IETF,
        February 2001.

   [32] M. Myers: "Internet X.509 Certificate Request Message Format",
        RFC 2511, IETF, March 1999.

   [33] M. Cooper et al: "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, RFC 3979, March 2005.

   [36] J. Rosenberg, H. Schulzrinne: "An Offer/Answer Model with the
        Session Description Protocol (SDP)", RFC 3264, IETF, June 2002.

   [37] IANA MIKEY Payload Name Spaces per [RFC3830], see

Appendix A  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] 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].  Addressed scenarios include point-to-point with
   one or more intermediate gatekeepers (trusted or partially trusted)

Euchner                 Expires - October 2005               [Page 30]

             HMAC-authenticated Diffie-Hellman for MIKEY   April 2005

   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] 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-DHHMAC I_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] 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 [,

   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 two

Euchner                 Expires - October 2005               [Page 31]

             HMAC-authenticated Diffie-Hellman for MIKEY   April 2005

            MIKEY-DHHMAC R_messages (R_fwd_message and R_rev_message)
            are encapsulted 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

            For more details on how the MIKEY protocols may be deployed
            with H.235, please refer to [22].

Euchner                 Expires - October 2005               [Page 32]

             HMAC-authenticated Diffie-Hellman for MIKEY   April 2005

Full Copyright Statement

  Copyright (C) The Internet Society (2004).  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

Intellectual Property Rights

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed
   to pertain to the implementation or use of the technology described
   in this document or the extent to which any license under such
   rights might or might not be available; nor does it represent that
   it has made any independent effort to identify any such rights.
   Information on the procedures with respect to rights in RFC
   documents can be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use
   of such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository

   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

Euchner                 Expires - October 2005               [Page 33]

             HMAC-authenticated Diffie-Hellman for MIKEY   April 2005

Expiration Date

  This Internet Draft expires on 30 October 2005.

[Note to the RFC editor: 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
   * 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 group is transmitted 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
   * references updated.
   * editorial corrections and cleanup.

   Changes against draft-ietf-msec-mikey-dhhmac-06.txt:

     * Abstract reworded.

Euchner                 Expires - October 2005               [Page 34]

             HMAC-authenticated Diffie-Hellman for MIKEY   April 2005

     * used new RFC boilerplate: changed/moved IPR statement (now at
     the beginning), 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
       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
     * 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.

Euchner                 Expires - October 2005               [Page 35]

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

Euchner                 Expires - October 2005               [Page 36]

             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
     * 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
   Phone: +49 89 722 55790                       Hofmannstr. 51
   Fax:   +49 89 722 62366

   81359 Munich, Germany

Euchner                 Expires - October 2005               [Page 37]