Internet Engineering Task Force - MSEC WG
   Internet Draft                                            M. Euchner
   Intended Category: Proposed Standard
   Expires: July 2005                                      January                                     February 2005

                HMAC-authenticated Diffie-Hellman for MIKEY

IPR Statement

   By submitting this Internet-Draft, I certify that any applicable patent
   or other IPR claims of which I am aware have been disclosed, or will be
   disclosed, and any of which I become aware will be disclosed, in accordance
   with RFC 3668.

Status of this Memo

   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 a "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.

             HMAC-authenticated Diffie-Hellman for MIKEY  January 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",
   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 Applicability...............................................8
   2.2. Relation to GKMARCH........................................11 GKMARCH........................................10
   3. DHHMAC Security Protocol.....................................11
   3.1. TGK re-keying..............................................13
   4. DHHMAC payload formats.......................................14
   4.1. Common header payload (HDR)................................15 (HDR)................................14
   4.2. Key data transport payload (KEMAC).........................16 (KEMAC).........................15
   4.3. ID payload (ID)............................................16
   4.4. General Extension Payload..................................16
   5. Security Considerations......................................17 Considerations......................................16
   5.1. Security environment.......................................17
   5.2. Threat model...............................................17
   5.3. Security features and properties...........................20
   5.4. Assumptions................................................24
             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005

   5.4. Assumptions................................................25

   5.5. Residual risk..............................................25
   5.6. Authorization and Trust Model..............................27 Model..............................26
   6.   Acknowledgments............................................27
   Conclusions.....................................................27   Acknowledgments............................................26
   7. IANA considerations..........................................28 considerations..........................................27
   8. References...................................................28 References...................................................27
   8.1  Normative References.......................................28 References.......................................27
   8.2  Informative References.....................................29 References.....................................28
   Full Copyright Statement........................................31 Statement........................................30
   Expiration Date.................................................32 Date.................................................31
   Revision History................................................33 History................................................32
   Author's Addresses..............................................35 Addresses..............................................34

1. Introduction

  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
         (MIKEY-PK) assuming a public-key infrastructure with RSA-based
         (Rivest, Shamir and Adleman) private/public keys and digital
             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005

     -   and a Diffie-Hellman key agreement protocol (MIKEY-DHSIGN)
             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005

         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 but does not nicely scale in any larger configuration
         of potential peer entities due to the need of mutually pre-assigned
         shared master secrets.

         Moreover, the security provided does not achieve the property of
         perfect forward secrecy; i.e. compromise of the shared master
         secret would render past and even future session keys susceptible
         to compromise.

         Further, the generation of the session key happens just at the
         initiator.  Thus, the responder has to fully trust the initiator
         on choosing a good and secure session secret; the responder neither
         is able to participate in the key generation nor to influence that
         process.  This is considered as a specific limitation in less
         trusted environments.

      -  The public-key encryption scheme (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 still not widely
         available and in general, implementations are significantly more

         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
         PKIX operations in
         the context of a public-key infrastructure such as validating of
         digital certificates (RFC
             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005 3029, [31]), ascertaining the revocation
         status of digital certificates (RFC 2560, [30]) and asserting
             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005

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

      -  The third MIKEY-DHSIGN key management protocol deploys the
         Diffie-Hellman key agreement scheme and authenticates the exchange
         of the Diffie-Hellman half-keys in each direction by using a digital
         signature.  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
         forward secrecy (PFS) and further have both parties actively
         involved in session key generation.  This special security property
         - despite the somewhat higher 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
             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005 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.

             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005

  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

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

  1.1.   Definitions

  The definitions and notations in this document are aligned with MIKEY,
  see [3] and [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 [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.

             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005

  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
             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005

  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
     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
     PKIX            Public-key Infrastructure Operation
     PRF             MIKEY pseudo-random function (see [3] section
             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005
     RSA             Rivest, Shamir and Adleman
     s               pre-shared key
     SDP             Session Description Protocol
     SOI             Son-of-IKE, IKEv2
     SP              MIKEY Security Policy (Parameter) Payload
             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005

     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

2. Scenario

  The HMAC-authenticated Diffie-Hellman key agreement protocol (DHHMAC) for
  MIKEY addresses the same scenarios and scope as the other three key
  management schemes in MIKEY address.

  DHHMAC is applicable in a peer-to-peer group where no access to a
  public-key infrastructure can be assumed available.  Rather, pre-
  shared pre-shared
  master secrets are assumed available among the entities in such an

  In a pair-wise group, it is assumed that each client will be setting up
  a session key for its outgoing links with it's peer using the DH-
  MAC DH-MAC key
  agreement protocol.

  As is the case for the other three MIKEY key management protocol, DHHMAC
  assumes loosely synchronized clocks among the entities in the small group.

  Note: To synchronize the clocks in a secure manner, some operational or
  procedural means are recommended.  However, MIKEY-DHHMAC does not describe
  any secure time synchronization measures and leaves such tasks to the
  discretion of the implementation.  The reader is
             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005 referred to [3] section
  5.4 and [3] section 9.3 that give guidance on clock synchronization and

  2.1.   Applicability
             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005

  MIKEY-DHHMAC as well as the other MIKEY key management protocols are
  optimized and targeted for the purpose of multimedia applications with
  application-level key management needs under 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 (see [5]) where the encoded MIKEY messages are encapsulated
     and transported in SDP containers of the SDP offer/answer handshake,
  b) H.323 (see [22]) where the encoded MIKEY messages are transported in
     the H.225.0 fast start call signaling handshake.

  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 peculiar strengths (see section 5).

  2.1.1. Usage in H.235

   This section 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
   DHHMAC) 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) in-
   between. in-between.
   One particular use case addresses MIKEY-DHHMAC to establish a media
   connection from an endpoint B calling (through a gatekeeper) to
             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005 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.

             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005

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

             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005
            Alternatively, the called endpoint A may instantiate the DHHMAC
            protocol in a separate run with endpoint B (not shown); however,
            this requires a third handshake to complete.

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

  2.2.   Relation to GKMARCH
             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005

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

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

3. DHHMAC Security Protocol

     The following figure defines the security protocol for DHHMAC:

                  Initiator                        Responder

      I_message = HDR, T, RAND, [IDi], IDr,
                  {SP}, DHi, KEMAC
                       ----------------------->   R_message = HDR, T,
                                                   [IDr], IDi, DHr,
                                                   DHi, KEMAC
             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005

      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
             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005

     the initiator's identity by some other means, then IDi MAY optionally
     be omitted.  The initiator SHALL always include the recipient's

     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., OAKELEY
     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 reponder'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, half-keys,
     and is necessary to avoid man-in-the-middle attacks.

     This approach is less expensive than digitally signed Diffie-
     Hellman. Diffie-Hellman.
     It requires first of all, that both sides compute one
             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005 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 be computed
             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005

     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:

             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005
     a) True re-keying by exchanging new and fresh Diffie-Hellman half-
         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 out.

             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005

4. 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 payloads.

  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
             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005

  * 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
        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
             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005

     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.

             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005

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

  4.2.   Key data transport payload (KEMAC)

     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 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
             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005

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

  4.3.   ID payload (ID)

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

  4.4.   General Extension Payload
             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005

     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.

     Table 4.4.a

5. Security Considerations

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

             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005

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

  The system that runs the DHHMAC protocol entity SHALL provide the
  capability to generate (pseudo) random numbers as input to the
  Diffie-Hellman operation (see [9], [15]).  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
             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005

  The threat model that this document adheres to cover the issues of
  end-to-end security in the Internet generally; without ruling out the
  possibility that MIKEY DHHMAC be deployed in a corporate, closed IP
  environment.  This also includes the possibility that MIKEY DHHMAC 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:

  * 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.  Rather,
    by the Diffie-Hellman "encryption" operation, that 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
             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005

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

  * Man-in-the-middle attacks:
    Such attacks threaten the security of exchanged, non-authenticated
    messages.  Man-in-the-middle attacks usually come with masquerade and
    or loss of message integrity (see below).  Man-in-the-middle attacks
    must be avoided, and if present or attempted must be detected
    appropriately.  DHHMAC addresses this threat by providing mutual peer
    entity authentication and message integrity.

  * Loss of integrity:

             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005
    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:
     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 be
             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005

    infeasible although the possibility of a successful attack cannot be
    ruled out completely.

  * Non-repudiation of the receipt or of the origin of the message:
    These are not requirements of this environment and thus related
    countermeasures are not provided at all.

  * Denial-of-service or distributed denial-of-service attacks:
    Some considerations are given on some of those attacks, but DHHMAC does
    not claim to provide full countermeasure against any of those attacks.
    For example, stressing the availability of the 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 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
             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005 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 may inherit such property
    from a security protocol underneath that actually features identity
    protection.  On the other hand, it is expected that MIKEY-DHHMAC is
    typically being deployed within SDP/SIP ([20], [5]); both those
    protocols do not provide end-to-end identity protection either.

    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.

             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005

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

  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

  * 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-authenticated Diffie-Hellman for MIKEY  January 2005 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 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

  * Cryptographic integrity check:
    The cryptographic integrity check is achieved using a message digest
    (keyed HMAC).  It includes the exchanged Diffie-Hellman half-keys but
    covers the other parts of the exchanged message as well.  Both mutual
    peer entity authentication and message integrity provide effective
    countermeasure against man-in-the-middle attacks.

             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005

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

  * Replay protection of the messages is achieved using embedded
    timestamps.  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
             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005 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-
    of-service denial-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 sessions.

  * 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 perfect-forward secrecy.
    Thus, none of the other MIKEY protocols is able to substitute the
    Diffie-Hellman PFS property.

             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005

    As such, DHHMAC but also digitally signed DH provides a far superior
    security level over the pre-shared or public-key based key distribution
    protocol in that respect.

  * Fair, mutual key contribution:
    The Diffie-Hellman key management protocol is not a strict key
    distribution protocol per se with the initiator distributing a key to
    its peers.  Actually, both parties involved in the protocol exchange
    are able to equally contribute to the common Diffie-
    Hellman 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 entity.

             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005

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

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

             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005

    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 half-key.

    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
             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005 public-key distribution
    protocol (depending on choice of the private and public key lengths).

    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

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

             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005

    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.

             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005

  5.4.   Assumptions

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

             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005

  * 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
             HMAC-authenticated Diffie-Hellman for MIKEY  January 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 upon the properties of the
  PRF, the Diffie-Hellman algorithm (discrete log-assumption), the HMAC and
  SHA1 algorithms have not been proved yet nor have they been disproved by
  the time of this writing.

  Thus, a certain residual risk remains, which might threaten the overall
  security at some unforeseeable time in the future.

  The 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 factorization).
  RSA asymmetric keys tend to become increasingly lengthy (1536 bits and
  more) and thus very computational intensive.  Neverthess, 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 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
             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005

  robust against potential threats than RSA.  Note, that an elliptic-curve
  Diffie-Hellman variant of MIKEY remains for further study.

             HMAC-authenticated Diffie-Hellman for MIKEY  January 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-
  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 entities.

  One may view the pre-established trust relationship through the pre-
  shared 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 and Russell
   Housely Housley and
   general feedback by the MSEC WG.


  Key management for environments and applications with real-time and
  performance constraints are becoming of interest.  Existing key management
  techniques like IPsec-IKE [14] and IPsec-IKEv2 [22], TLS [13] and other
             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005

  schemes are not deemed adequate in addressing sufficiently those real-time
  and security requirements.

             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005

  MIKEY defines three key management security protocols addressing
  real-time constraints.  DHHMAC as described in this document defines a
  fourth MIKEY variant aiming at the same target.

  While each of the four key management protocols has its own merits there
  are also certain limitations of each approach.  As such there is no single
  ideal solution and none of the variants is able to subsume the other
  remaining variants.

  It is concluded that DHHMAC features useful security and performance
  properties that none of the other three MIKEY variants is able to provide.

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.
   The name spaces for the following fields in the Common header payload (from
   Section 4.1) are requested to be managed by IANA (in bracket is the
   reference to the table with the initially registered values):

   *  data type (Table 4.1.a); to be aligned with [3] table 6.1.a.

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.

             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005

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

             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005

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

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

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

             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005

       "Randomness Requirements for Security"; <draft-eastlake-
       <draft-eastlake-randomness2-10.txt>; Work in Progress, IETF,
       January 2005.

   [16] J. Schiller: "Strong Security Requirements for Internet
             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005
       Engineering Task Force Standard Protocols", RFC 3365, IETF, 2002.

   [17] C. Meadows: "Advice on Writing an Internet Draft Amenable to
       Security Analysis", Work in Progress, <draft-irtf-cfrg-advice-
       <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)
       Authors", Work in Progress, <draft-rfc-editor-rfc2223bis-
       08.txt>, <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-
       <draft-ietf-msec-gsakmp-sec-07.txt>, Internet Draft, Work in
       Progress (MSEC WG).

   [26] Baugher, M., Canetti, R., Dondeti, L., and Lindholm, F.: "Group
             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005

       Key Management Architecture", <draft-ietf-msec-gkmarch-08.txt>,
       Internet Draft, Work in Progress (MSEC WG).

             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005

   [27] Baugher, McGrew, Oran, Blom, Carrara, Naslund: "The Secure Real-
        time 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",

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

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

   [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-
        <draft-ietf-pkix-certpathbuild-05.txt>, Internet Draft, Work in
        Progress (PKIX WG).

   [34] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667,
        February 2004.

   [35] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP
        79, RFC 3668, February 2004.

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.

             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005

  This document and the information contained herein are provided on an "AS
             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005 ENGINEERING

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 ISOC Documents can be found in BCP
   78 and BCP 79.

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

   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

Expiration Date

  This Internet Draft expires on 30 July 2005.

             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005

[Note to the RFC editor: Please remove the entire following section prior
to publication.]
             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005

Revision History

   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 protection.
   * references updated.
   * editorial corrections and cleanup.

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

     * Abstract reworded.
     * 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-authenticated Diffie-Hellman for MIKEY  January 2005

     * HMAC-SHA1-96 option removed (see section 1.2, 4.2, 5.3,).  This
       option does not really provide much gain;  removal reduces number
       of options.
     * IDr added to I_message for DoS protection of the recipient; see
       section 3, 3.1, 5.3.
     * References updated.

             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005

   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.

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

             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005

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

             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005
     * 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.

   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
             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005

   Phone: +49 89 722 55790                       Hofmannstr. 51
   Fax:   +49 89 722 62366

   81359 Munich, Germany
             HMAC-authenticated Diffie-Hellman for MIKEY  January 2005