Internet Engineering Task Force                               M. Euchner
Internet Draft                                                Siemens AG
Intended Category: Informational Proposed Standard
Expires: February June 2003                                          January 2003                                       August 2002

              HMAC-authenticated Diffie-Hellman for MIKEY
                 (draft-ietf-msec-mikey-dhhmac-00.txt)
                 (draft-ietf-msec-mikey-dhhmac-01.txt)

Status of this memo

     This document is an Internet-Draft and is in full conformance with
     all provisions of Section 10 of RFC2026.

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

     Internet-Drafts are draft documents valid for a maximum of six
     months and may be updated, replaced, or obsoleted by other
     documents at any time.  It is inappropriate to use Internet-Drafts
     as reference material or to cite them other than as "work in
     progress."

     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt

     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.

     The distribution of this memo is unlimited.

     Comments should be sent to the MSEC WG mailing list at
     msec@securemulticast.org and to the author.

Abstract

     This document describes a point-to-point key management protocol
     variant for the multimedia Internet keying (MIKEY).  In
     particular, the classic Diffie-Hellman key agreement protocol is
     used for key establishment in conjunction with a keyed hash (HMAC-SHA1) (HMAC-
     SHA1) for achieving mutual authentication and message integrity of
     the key management messages exchanged.  This MIKEY variant is
     called the HMAC-authenticated Diffie-Hellmann (DH-HMAC). (DHHMAC).  It
     addresses the security and performance constraints of multimedia
     key management in MIKEY.

             HMAC-authenticated Diffie-Hellman for MIKEY  August 2002 January 2003

Table of Contents

1.  Introduction.....................................................3   Introduction..................................................2
1.1. Notational Conventions.........................................4 Conventions........................................4
1.2.  Definitions....................................................5 Definitions...................................................4
1.3.  Abbreviations..................................................5 Abbreviations.................................................4
2.  Scenario.........................................................6   Scenario......................................................5
3.  DH-HMAC   DHHMAC Security Protocol........................................6 Protocol......................................5
3.1. TGK re-keying..................................................7 re-keying.................................................7
4.  DH-HMAC   DHHMAC payload formats..........................................8 formats........................................7
4.1. Common header payload (HDR)....................................8 (HDR) ..................................8
4.2. Key data transport payload (KEMAC).............................9 (KEMAC) ...........................8
4.3. ID payload (ID)................................................9 (ID) ..............................................9
5.   Security Considerations.........................................10 Considerations.......................................9
5.1. Security environment..........................................10 environment..........................................9
5.2. Threat model..................................................10 model..................................................9
5.3. Security features and properties..............................11 properties.............................11
5.4.  Assumptions...................................................14 Assumptions..................................................14
5.5. Residual risk.................................................15 risk................................................15
6.   IANA considerations.............................................16 considerations..........................................15
7.   Intellectual Property Rights....................................16 Rights.................................15
8.  Acknowledgements................................................16   Acknowledgements.............................................16
9.  Conclusions.....................................................16   Conclusions..................................................16
10.  Normative References...........................................17 References.........................................17
11.  Informative References.........................................17 References.......................................17
12.  Author's Address...............................................18 Address.............................................18
13.  Expiration Date................................................18  Full Copyright Statement.....................................18
14.  Expiration Date..............................................19
15.  Revision History...............................................18
             HMAC-authenticated Diffie-Hellman for MIKEY  August 2002 History.............................................19

1. Introduction

  As pointed out in MIKEY (see [1]), secure real-time multimedia
  applications demand a particular adequate key management scheme that
  cares for how to securely and efficiently establish dynamic session
  keys in a conversational multimedia scenario.
  In general, MIKEY scenarios cover peer-to-peer, simple-one-to-many
  and small-sized groups.  MIKEY in particular, describes three key
  management schemes for the peer-to-peer case that all finish their
  task within one round trip:
     -    a symmetric key distribution protocol based upon pre-shared
          master keys;

     -    a public-key encryption-based key distribution protocol
          assuming a public-key infrastructure with RSA-based (Rivest,
          Shamir and Adleman) private/public keys and digital
          certificates;

     -    and a Diffie-Hellman key agreement protocol deploying digital
          signatures and certificates.

  All these three key management protocols are designed such that they
  complete their work within just one round trip.  This requires
             HMAC-authenticated Diffie-Hellman for MIKEY January 2003

  depending on loosely synchronized clocks and deploying timestamps
  within the key management protocols.

  However, it is known [4] [5] that each of the three key management
  schemes has its subtle constraints and limitations:
     -    The symmetric key distribution protocol is simple to
          implement but does not nicely scale in any larger
          configuration of potential peer entities due to the need of
          mutually pre-assigned shared master secrets.

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

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

     -    The public-key encryption scheme depends upon a public-key
          infrastructure that certifies the private-public keys by
          issuing and maintaining digital certificates.  While such a
          key management scheme provides full scalability in large
          networked configurations, public-key infrastructures are
          still not widely available and in general, implementations
          are significantly more complex.

             HMAC-authenticated Diffie-Hellman for MIKEY  August 2002

          Further additional round trips might be necessary for each
          side in order to ascertain verification of the digital
          certificates.

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

     -    The third MIKEY key management protocol deploys the Diffie-
          Hellman key agreement scheme and authenticates the exchange
          of the Diffie-Hellman half-keys in each direction by using a
          digital signature upon.  As in the previous method, this
          introduces the dependency upon a public-key infrastructure
          with its strength on scalability but also the limitations on
          computational costs in performing the asymmetric long-integer
          operations and the potential need for additional
          communication for verification of the digital certificates.

          However, the Diffie-Hellman key agreement protocol is known
          for its subtle security strengths in that it is able to
          provide full perfect secrecy and further have both parties
          actively involved in session key generation.

             HMAC-authenticated Diffie-Hellman for MIKEY January 2003

  This document describes a fourth key management scheme for MIKEY that
  could somehow be seen as a synergetic optimization between the pre-
  shared key distribution scheme and the Diffie-Hellman key agreement.

  The idea of that protocol is to apply the Diffie-Hellman key
  agreement but instead of deploying a digital signature for
  authenticity of the exchanged keying material rather uses a keyed-
  hash upon using symmetrically pre-assigned shared secrets.  This
  combination of security mechanisms is called the HMAC-authenticated
  Diffie-Hellman (DH) key agreement for MIKEY (DH-HMAC). (DHHMAC).

  Like the MIKEY Diffie-Hellman protocol, DH-HMAC 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.   Notational Conventions

     The key word "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
     this document are to be interpreted as described in RFC-2119.

             HMAC-authenticated Diffie-Hellman for MIKEY  August 2002

  1.2.   Definitions

  The definitions and notations in this document are aligned with
  MIKEY, see [1] and [1] sections 1.2 - 1.3.

  All large integer computations in this document should be understood
  as being mod p within some fixed group G for some large prime p; see
  [1] section 3.3; however, the DH-HMAC DHHMAC protocol is applicable in
  general to other appropriate groups as well.

  It is assumed that a pre-shared key s is known by both entities
  (initiator and responder).  The authentication key auth_key is
  derived from the pre-shared secret s using the pseudo-random function
  PRF; see [1] sections 4.1.3 and 4.1.5.

  1.3.   Abbreviations

     auth_key       pre-shared authentication key, PRF-derived from
                    pre-shared key s.
     DH             Diffie-Hellman
     DHi            public Diffie-Hellman half key g**(xi) of
                    Initiatior
     DHr            public Diffie-Hellman half key g**(xr) of Responder
     DH-HMAC
     DHHMAC         HMAC-authenticated Diffie-Hellman
             HMAC-authenticated Diffie-Hellman for MIKEY January 2003

     DoS            Denial-of-service
     G              Diffie-Hellman group
     HDR            MIKEY common header payload
     HMAC           keyed Hash Message Authentication Code
     HMAC-SHA1      HMAC using SHA1 as hash function (160-bit result)
     HMAC-SHA-1-96  HMAC-SHA1 truncated to 96 bits
     IDi            Identity of initiator
     IDr            Identity of receiver
     IKE            Internet Key Exchange
     IPSEC          Internet Protocol Security
     MIKEY          Multimedia Internet KEYing
     p              Diffie-Hellman prime modulus
     PRF            MIKEY pseudo-random function
                    (see [1] section 4.1.3.)
     RSA            Rivest, Shamir and Adleman
     s              pre-shared key
     SOI            Son-of-IKE
     SP             MIKEY Security Policy (Parameter) Payload
     T              timestamp
     TEK            Traffic Encryption Key
     TGK            MIKEY TEK Generation Key as the common Diffie-
                    Hellman shared secret
     TLS            Transport Layer Security
     xi             secret, random Diffie-Hellman key of Initiator
     xr             secret, random Diffie-Hellman key of Responder
             HMAC-authenticated Diffie-Hellman for MIKEY  August 2002

2. Scenario

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

  DH-HMAC

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

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

3. DH-HMAC DHHMAC Security Protocol

     The following figure defines the security protocol for DH-HMAC: DHHMAC:

             HMAC-authenticated Diffie-Hellman for MIKEY January 2003

               Initiator                        Responder

   I_message = HDR, T, RAND, [IDi],
               {SP}, DHi, KEMAC
                           I_message
                    ----------------------->   R_message = HDR, T,
                                                [Idr],
                                                [IDr], IDi, DHr, DHi,
                                                 KEMAC
                             R_message
                    <----------------------

   TGK = g**(xi * yi)                        TGK = g**(xi * yi)

     Figure 1: HMAC-authenticated Diffie-Hellman key based exchange,
            where xi and xr are randomly chosen respectively
                  by the initiator and the responder.

     The DH-HMAC DHHMAC key exchange SHALL be done according to Figure 1. The
     initiator chooses a random value xi, and sends an HMACed message
     including g**xi and a timestamp to the responder (optionally also
     including its identity).

     The group parameters (e.g., the group G) are a set of parameters
     chosen by the initiator.  The responder chooses a random positive
     integer xr, and sends an HMACed message including g**xr and the
             HMAC-authenticated Diffie-Hellman for MIKEY  August 2002
     timestamp to the initiator (optionally also providing its
     identity).

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

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

     This approach is the less expensive than digitally signed Diffie-
     Hellman.  It requires first of all, that both sides compute one
     exponentiation and one HMAC, then one HMAC verification and
     finally another Diffie-Hellman exponentiation.

     With off-line pre-computation, the initial Diffie-Hellman half-key
     MAY be computed before the key management transaction and thereby
     MAY further reduce the overall round trip delay as well as reduce
     the risk of denial-of-service attacks.

     Processing of the TGK SHALL be accomplished as described in MIKEY
     [1] chapter 4.

     The computed HMAC result SHALL be conveyed in the KEMAC payload
     field where the MAC fields holds the HMAC result.  The HMAC shall
     be computed over the entire message using auth_key, see also
     section 4.2.

             HMAC-authenticated Diffie-Hellman for MIKEY January 2003

  3.1.   TGK re-keying

     TGK re-keying for DH-HMAC DHHMAC generally proceeds as described in [1]
     section 4.5.  Specifically, figure 2 provides the message fields
     for DH-HMAC DHHMAC update message.

               Initiator                        Responder

   I_message = HDR, T, [IDi],
               {SP}, [Dhi], [DHi], KEMAC
                           I_message
                    ----------------------->   R_message = HDR, T,
                                                [Idr],
                                                [IDr], IDi, [DHr, Dhi], DHi],
                                                 KEMAC
                             R_message
                    <----------------------

   [TGK = g**(xi * yi)]                      [TGK = g**(xi * yi)]

                    Figure 2: DH-HMAC DHHMAC update message
             HMAC-authenticated Diffie-Hellman for MIKEY  August 2002

4. DH-HMAC DHHMAC payload formats

  This section specifies the payload formats and data type values for
  DH-HMAC,
  DHHMAC, see also [1] chapter 6 for a definition of the MIKEY
  payloads.

  The following referenced MIKEY payloads are used for DH-MAC:

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

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

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

  * DH data payload, see [1] section 6.4

  * Timestamp payload, [1] section 6.6

  * ID payload, [1] section 6.7

  * Security Policy payload (SP), [1] section 6.10
             HMAC-authenticated Diffie-Hellman for MIKEY January 2003

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

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

  * General Extension Payload, [1] section 6.15

  4.1.   Common header payload (HDR)

     Referring to [1] section 6.1, for DH-HMAC DHHMAC the following data type
     SHALL be used:

        Data type     | Value | Comment
        --------------------------------------
        DHHMAC init   |     7 | Initiator's DH-HMAC DHHMAC exchange message
        DHHMAC resp   |     8 | Responder's DH-HMAC DHHMAC exchange message
        Error         |     6 | Error message, see [1] section 6.12

     The next payload field shall be one of the following values:

     Next payload| Value |       Section
     ------------------------------------------------------
     Last payload|     0 | -
     KEMAC       |     1 | section 4.2 and [1] section 6.2
     DH          |     3 | [1] section 6.4
     T           |     5 | [1] section 6.6
     ID          |     6 | [1] section 6.7
     SP          |    10 | [1] section 6.10
     RAND        |    11 | [1] section 6.11
             HMAC-authenticated Diffie-Hellman for MIKEY  August 2002
     ERR         |    12 | [1] section 6.12
     General Ext.|    21 | [1] section 6.15

     Other defined next payload values defined in [1] shall SHALL not be
     applied to DH-HMAC. DHHMAC.

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

  4.2.   Key data transport payload (KEMAC)

     DH-HMAC shall

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

     For DH-HMAC, DHHMAC, this key data transport payload shall SHALL be the last
     payload in the message.  Note that the Next payload field is SHALL be
     set to Last payload.  The HMAC is then calculated over the entire
     MIKEY message using auth_key as described in [1] section 5.2 and
     then stored within MAC field.

             HMAC-authenticated Diffie-Hellman for MIKEY January 2003

        MAC alg       | Value |           Comments
        --------------------------------------------------------
        HMAC-SHA-1    |     0 | Mandatory, Default (see [SHA1])
        NULL          |     1 | Very restricted use, see
                              | [1] section 4.2.4
        HMAC-SHA-1-96 |     5 | Optional, HMAC-SHA1 truncated to the 96
                              | leftmost bits of the HMAC-SHA-1 result
                              | when represented in network byte order.

     HMAC-SHA-1 is the default hash function that MUST be implemented
     as part of the DH-HMAC. DHHMAC.  The length of the HMAC-SHA-1 result is 160
     bits.

     HMAC-SHA-1-96 produces a slightly shorter HMAC result where the
     HMAC-SHA-1 result SHALL be truncated to the 96 leftmost bits when
     represented in network byte order.  This saves some bandwidth.

  4.3.   ID payload (ID)

     For DH-HMAC, DHHMAC, this payload shall SHALL only hold a non-certificate based
     identify.

             HMAC-authenticated Diffie-Hellman for MIKEY  August 2002

5. Security Considerations

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

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

  5.1.   Security environment

  Generally, the DH-HMAC DHHMAC security protocol described in this document
  focuses primarily on communication security; i.e. the security issues
  concerned with the MIKEY DH-HMAC DHHMAC protocol.  Nevertheless, some system
  security issues are of interest as well that are not explicitly
  defined by the DH-HMAC DHHMAC protocol, but should be provided locally in
  practice.  The system where the DH-HMAC DHHMAC protocol entity runs upon
  shall provide the capability to generate random numbers as input to
  the Diffie-Hellman operation (see [6], [14]). [7], [15]).  Further, the system
  shall be capable of storing the generated random data, secret data,
  keys and other secret security parameters securely (i.e. confidential
  and safe from unauthorized tampering).

  5.2.   Threat model

  The threat model that this documents adheres to covers the issues of
  end-to-end security in the Internet generally; without ruling out the
             HMAC-authenticated Diffie-Hellman for MIKEY January 2003

  possibility that MIKEY DH-HMAC DHHMAC be deployed in a corporate, closed IP
  environment.  This also includes the possibility that MIKEY DH-HMAC DHHMAC be
  deployed on a hop-by-hop basis with some intermediate trusted "MIKEY
  DH-HMAC
  DHHMAC proxies" involved.

  Since DH-HMAC DHHMAC is a key management protocol, the following security
  threats are of concern:

  * Unauthorized interception of plain TGKs.
     This threat shall not occur. Nevertheless, for DH-HMAC 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:
     DH-HMAC
     DHHMAC protocol does not explicitly transmit the TGK at all.
     Rather, by the Diffie-Hellman "encryption" operation, that
     conceals the secret, random values, only partial information (i.e.
     the DH- half key) for construction of the TGK is transmitted.  It
     is assumed that availability of such Diffie-Hellman half-keys to
     an eavesdropper does not result in any risk; see 5.4.  Further,
     the
     DH-HMAC DHHMAC carries other data such as timestamps, random values,
     identification information or security policy parameters;
     eavesdropping of any such data is considered not to yield any
     significant security risk.

  * Masquerade of either entity:

             HMAC-authenticated Diffie-Hellman for MIKEY  August 2002
     This security threat must be avoided and if a masquerade attack
     would be attempted, appropriate detection means must be in place.
     DH-HMAC
     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. DH-HMAC  DHHMAC addresses this threat by providing
     mutual peer entity authentication and message integrity.

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

  Some potential threats are not within the scope of this threat model:

  * Passive and off-line cryptanalysis of the Diffie-Hellman algorithm:
     Under certain reasonable assumptions (see 5.4 below) it is widely
     believed that DH-HMAC DHHMAC is sufficiently secure and that such attacks
     be infeasible although the possibility of a successful attack
     cannot be ruled out completely.

             HMAC-authenticated Diffie-Hellman for MIKEY January 2003

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

  * Denial-of-service or distributed denial-of-service attacks:
     Some considerations are given on some of those attacks, but
     DH-HMAC 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-
     requests and its massive instant duplication.  Such attacks might
     at least be countered partially by some local means that are
     outside the scope of this document.

  * Identity protection:
     Like MIKEY, identity protection is not a major design requirement
     for MIKEY-DHHMAC either, see [1].  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.  As such, 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 ([21], [22]); both
     those protocols do not provide end-to-end identity protection.

  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.

             HMAC-authenticated Diffie-Hellman for MIKEY  August 2002

  * Peer-entity authentication (mutual):
     This authentication corroborates that the host/user is authentic
     in that possession of a pre-assigned secret key is proven using
     keyed HMAC.  The authentication occurs on the request and on the
     response message, thus authentication is mutual.

     The HMAC computation corroborates for authentication and message
     integrity of the exchanged Diffie-Hellman half-keys and associated
     messages.  The authentication is absolutely necessary in order to
     avoid man-in-the-middle attacks on the exchanged messages in
     transit and in particular, on the otherwise non-authenticated
     exchanged Diffie-Hellman half keys.

     Note: This document does not address issues regarding
     authorization; this feature is not provided explicitly.  However,
     DH-HMAC
             HMAC-authenticated Diffie-Hellman for MIKEY January 2003

     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 countermeasure against man-in-the-middle man-in-the-
     middle attacks.

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

     * Replay protection of the messages is achieved using embedded
     timestamps.
     embeddedtimestamps.

  * Limited DoS protection:
     Rapid checking of the message digest allows verifying the
     authenticity and integrity of a message before launching CPU
     intensive Diffie-Hellman operations or starting other resource
     consuming tasks.  This protects against some denial-of-service
     attacks: malicious modification of messages and spam attacks with
     (replayed or masqueraded) messages. DH-HMAC  DHHMAC probably does not
     explicitly counter sophisticated distributed denial-of-service
     attacks that compromise system availability for example.

  * Perfect-forward secrecy (PFS):
     Other than the MIKEY pre-shared and public-key based key
     distribution protocols, the Diffie-Hellman key agreement protocol
     features a security property called perfect forward secrecy.  That
     is, that even if the long-term pre-shared key would be compromised
     at some point in time, this would not render past or future
     session keys compromised.

             HMAC-authenticated Diffie-Hellman for MIKEY  August 2002

     As such, DH-HMAC 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 TEK traffic generating key.  This reduces the risk of
     either party cheating or unintentionally generating a weak session
     key.  This makes the DH-HMAC DHHMAC a fair key agreement protocol.

     In order for Diffie-Hellman key agreement to be secure, each party
     shall generate its xi or xr values using a strong, unpredictable
     pseudo-random generator.  Further these values xi or xr shall be
     kept private.  It is recommended that these secret values be
             HMAC-authenticated Diffie-Hellman for MIKEY January 2003

     destroyed once the common Diffie-Hellman shared secret key has
     been established.

  * Efficiency and performance:
     The DH-HMAC DHHMAC key agreement protocol securely establishes a TGK
     within just one roundtrip. Other existing key management
     techniques like IPSEC-IKE [13], [14], IPSEC-SOI and TLS [12] [13] and other
     schemes are not deemed adequate in addressing sufficiently those
     real-time and security requirements. requirements; they all use more than a
     single roundtrip.

     Using HMAC in conjunction with a strong one-way hash function such
     as SHA1 may be achieved more efficiently in software than
     expensive public-key operations.  This yields a particular
     performance benefit of DH-HMAC DHHMAC over signed DH or the public-key
     encryption protocol.

     DH-HMAC

     DHHMAC optionally features a variant where the HMAC-SHA-1 result
     is truncated to 96-bit instead of 160 bits.  It is believed that
     although the truncated HMAC appears significantly shorter, the
     security provided would not suffer; it appears even reasonable
     that the shorter HMAC could provide increased security against
     known-plaintext crypt-analysis, see RFC 2104 for more details.  In
     any way, truncated DH-HMAC DHHMAC is able to reduce the bandwidth during
     Diffie-Hellman key agreement and yield better round trip delay on
     low-bandwidth links.  If a very high security level is desired for
     long-term secrecy of the negotiated Diffie-Hellman shared secret,
     longer hash values may be deployed such as SHA256, SHA384 or
     SHA512 provide, possibly in conjunction with stronger Diffie-
     Hellman groups.  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, DH-HMAC DHHMAC consumes
     more CPU cycles than the MIKEY pre-shared key distribution
     protocol.  The same might hold true quite likely for
             HMAC-authenticated Diffie-Hellman for MIKEY  August 2002 the MIKEY
     public-key distribution protocol (depending on choice of the
     private and public key lengths).

     As such, it can be said that DH-HMAC DHHMAC provides sound performance
     when compared with the other MIKEY protocol variants.

  * Security infrastructure:
     This document describes the HMAC-authenticated Diffie-Hellman key
     agreement protocol that completely avoids digital signatures and
     the associated public-key infrastructure as would be necessary for
     the X.509 RSA public-key based key distribution protocol or the
     digitally signed Diffie-Hellman key agreement protocol as
     described in MIKEY.  Public-key infrastructures may not always be
     available in certain environments nor may they be deemed adequate
     for real-time multimedia applications when taking additional steps
             HMAC-authenticated Diffie-Hellman for MIKEY January 2003

     for certificate validation and certificate revocation methods with
     additional round-trips into account.

     DH-HMAC

     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.

     DH-HMAC

     DHHMAC is particularly attractive in those environments where
     provisioning of a pre-shared key has already been accomplished.

  * Firewall-friendliness:
     DH-HMAC NAT/Firewall-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.  Of course, DH-HMAC DHHMAC does not
     necessarily require a firewall/NAT to operate.

  * Scalability:
     Like the MIKEY signed Diffie-Hellman protocol, DH-HMAC DHHMAC does not
     scale to any larger configurations beyond peer-to-peer groups.

  5.4.   Assumptions

  This document states a couple of assumptions upon which the security
  of DH-HMAC 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
     beeffectively guessed.

     * the pseudo-random function (PRF) is secure, yields indeed the
     pseudo-random
     thepseudo-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
             HMAC-authenticated Diffie-Hellman for MIKEY  August 2002
     called the discrete logarithm assumption.  Please see [9], [10] or [10], [11]
     or [12] for more background information regarding the Diffie-Hellman Diffie-
     Hellman problem and its computational complexity assumptions.

  * the hash function (SHA1) is secure; i.e. that it is computationally
     infeasible to find a message which corresponds to a given message
     digest, or to find two different messages that produce the same
     message digest.

  * the HMAC algorithm is secure and does not leak the auth_key.  In
     particular, the security depends on the message authentication
     property of the compression function of the hash function H when
     applied to single blocks (see [2]).

             HMAC-authenticated Diffie-Hellman for MIKEY January 2003

     * A source capable of producing sufficiently many bits of randomness
     is
     randomnessis available.

  * The systems upon which DH-HMAC DHHMAC runs are sufficiently secure.

  The assumptions must MUST be met as far as they can be enforced.

  5.5.   Residual risk

  Although these detailed assumptions are non-negligible, security
  experts generally believe that all these assumptions are reasonable
  and that the assumptions made can be fulfilled in practice with
  little or no expenses.

  The mathematical and cryptographic assumptions upon the properties of
  the PRF, the Diffie-Hellman algorithm (discrete log-assumption), the
  HMAC and SHA1 algorithms have not been proved yet nor have they been
  disproved by the time of this writing.

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

  The DH-HMAC DHHMAC would be compromised as soon as

  * the discrete logarithm problem could be solved efficiently,

     * the hash function could be subverted (efficient collisions
     become feasible),

  * the HMAC method be broken (leaking the auth_key),

  * systematic brute force attacks are effective by which an attacker
  attempts to discover the shared secret.  It is assumed that the
  shared secret yields sufficient entropy to make such attacks
  infeasible,

  * or some other yet unknown attacking technique will be discovered.

             HMAC-authenticated Diffie-Hellman for MIKEY  August 2002

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

6. IANA considerations

     This document does not define its own new name spaces for DH-HMAC, DHHMAC,
     rather additional values for DH-HMAC DHHMAC and EC are defined as part of
     the MIKEY fields.  Thus, close alignment between DH-HMAC DHHMAC values and
     MIKEY values shall be maintained; see also [1] section 10.

7. Intellectual Property Rights
             HMAC-authenticated Diffie-Hellman for MIKEY January 2003

     This proposal is in full conformity with [RFC-2026].

     The author is aware of related intellectual property rights
     currently being held by Infineon.  Pursuant to the provisions of
     [RFC-2026], the author represents that he has disclosed the
     existence of any proprietary or intellectual property rights in
     the contribution that are reasonably and personally known to the
     author.  The author does not represent that he personally knows of
     all potentially pertinent proprietary and intellectual property
     rights owned or claimed by the organizations he represents or
     third parties.

     The IETF takes no position regarding the validity or scope of any
     intellectual property or other rights that might be claimed to
     pertain to the implementation or use of the technology described
     in this document or the extent to which any license under such
     rights might or might not be available; neither does it represent
     that it has made any effort to identify any such rights.
     Information on the IETF's procedures with respect to rights in
     standards-track and standards-related documentation can be found
     in BCP-11.  Copies of claims of rights made available for
     publication and any assurances of licenses to be made available,
     or the result of an attempt made to obtain a general license or
     permission for the use of such proprietary rights by implementors
     or users of this specification can be obtained from the IETF
     Secretariat.

8. Acknowledgements

  This document incorporates kindly review feedback by Steffen Fries
  and Fredrick Lindholm.

9. Conclusions

  Key management for environments and applications with real-time and
  performance constraints are becoming of interest.  Existing key
  management techniques like IPSEC-IKE [13] [14] and IPSEC-SOI, TLS [12] [13] and
             HMAC-authenticated Diffie-Hellman for MIKEY  August 2002
  other schemes are not deemed adequate in addressing sufficiently
  those real-time and security requirements.

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

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

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

             HMAC-authenticated Diffie-Hellman for MIKEY January 2003

10.  Normative References

[1]  J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman;
"MIKEY:Multimedia Internet KEYing", Internet Draft <draft-ietf-msec-
mikey-04.txt>,
mikey-05.txt>, Work in Progress (MSEC WG)

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

[3] NIST, FIBS-PUB 180-1, "Secure Hash Standard", April 1995,
http://csrc.nist.gov/fips/fip180-1.ps

[4] S. Bradner: "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.

11.  Informative References

[4]

[5] A.J. Menezes, P v. Oorschot, S. Vanstone: "Applied Cryptography",
CRC Press, 1996

[5]

[6] E. Rescorla, B. Korver: " Guidelines for Writing RFC Text on
Security Considerations", Work in Progress <draft-iab-sec-cons-00.txt>,
August <draft-iab-sec-cons-01.txt>,
October 2002.

[6]

[7] D. Eastlake, S. Crocker: "Randomness Recommendations for Security",
1750, IETF, December 1994.

[7]

[8] S.M. Bellovin, J. I. Schiller: "Security Mechanisms for the
Internet", Work in Progress <draft-iab-secmech-01.txt>, June 2002.

[8]

[9]  S. Bradner: "The Internet Standards Process -- Revision 3", RFC
2026, IETF, October 1996

[9]

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

[10]

[11] Ueli M. Maurer, S. Wolf: "The Diffie-Hellman Protocol", Designs,
Codes, and Cryptography, Special Issue Public Key Cryptography, Kluwer
             HMAC-authenticated Diffie-Hellman for MIKEY  August 2002
Academic Publishers, vol. 19, pp. 147-171, 2000.
ftp://ftp.inf.ethz.ch/pub/crypto/publications/MauWol00c.ps

[11]

[12] Discrete Logarithms and the Diffie-Hellman Protocol;
http://www.crypto.ethz.ch/research/ntc/dldh/

[12]

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

[13]

             HMAC-authenticated Diffie-Hellman for MIKEY January 2003

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

[14]

[15] Donald E. Eastlake, Jeffrey I. Schiller, Steve Crocker:
"Randomness Requirements for Security"; <draft-eastlake-randomness2-
03.txt>; Work in Progress, IETF, 7/2002.

[15]

[16] J. Schiller: "Strong Security Requirements for Internet
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-00.txt>,
October 2002.

[18] Steven M. Bellovin: "Security Mechanisms for the Internet", Work
in Progress <draft-iab-secmech-01.txt>, June 2002.

[19] T. Narten: "Guidelines for Writing an IANA Considerations Section
in RFCs", RFC 2434, October 1998.

[20] J. Reynolds: "Instructions to Request for Comments (RFC) Authors",
Work in Progress, <draft-rfc-editor-rfc2223bis-03.txt>, IETF, 12
October 2002.

[21] J. Rosenberg et all: "SIP: Session Initiation Protocol", RFC 3261,
June 2002.

[22] J. Arkko et al: "Key Management Extensions for SDP and RTSP", Work
in Progress, <draft-ietf-mmusic-kmgmt-ext-05.txt>, June, 2002.

12.  Author's Address

  Please address all comments to:

Martin Euchner                                  Siemens AG
Email: martin.euchner@icn.siemens.de martin.euchner@siemens.com               ICN M SR 3
Phone: +49 89 722 55790                         Hofmannstr. 51
Fax:   +49 89 722 47713 62366

 81359 Munich, Germany

13.  Full Copyright Statement

  Copyright (C) The Internet Society (2003).  All Rights Reserved.

  This document and translations of it may be copied and furnished to
  others, and derivative works that comment on or otherwise explain it
  or assist in its implementation may be prepared, copied, published
  and distributed, in whole or in part, without restriction of any
  kind, provided that the above copyright notice and this paragraph are
             HMAC-authenticated Diffie-Hellman for MIKEY January 2003

  included on all such copies and derivative works.  However, this
  document itself may not be modified in any way, such as by removing
  the copyright notice or references to the Internet Society or other
  Internet organizations, except as needed for the purpose of
  developing Internet standards in which case the procedures for
  copyrights defined in the Internet Standards process must be
  followed, or as required to translate it into languages other than
  English.

  The limited permissions granted above are perpetual and will not be
  revoked by the Internet Society or its successors or assigns.

  This document and the information contained herein is provided on an
  "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

14.  Expiration Date

  This Internet Draft expires on 30 February June 2003.

14.

15.  Revision History

Changes against draft-euchner-MIKEY-DHHMAC-00.txt: 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
     formats
     * clarified that truncated HMAC actually truncates the HMAC result
     rather than the SHA1 intermediate value.
     * improved security considerations section completely rewritten in
     the spirit of [5]. [6].
     * IANA consideration section added
     * a few editorial improvements and corrections
     * IPR clarified and IPR section changed changed.