[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-euchner-mikey-dhhmac) 00 01 02 03 04 05 06 07 08 09 10 11 RFC 4650

             HMAC-authenticated Diffie-Hellman for MIKEY    July 2003


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


                HMAC-authenticated Diffie-Hellman for MIKEY
                   <draft-ietf-msec-mikey-dhhmac-03.txt>


Status of this Memo

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

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


Euchner                 Expires û January 2004                [Page 1]


             HMAC-authenticated Diffie-Hellman for MIKEY    July 2003


   achieving mutual authentication and message integrity of the key
   management messages exchanged.  This MIKEY variant is called the
   HMAC-authenticated Diffie-Hellmann (DHHMAC).  It 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",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [2].

Table of Contents

   1.   Introduction................................................3
   1.1. Definitions.................................................5
   1.2. Abbreviations...............................................6
   2.   Scenario....................................................7
   2.1. Applicability...............................................7
   3.   DHHMAC Security Protocol....................................8
   3.1. TGK re-keying...............................................9
   4.   DHHMAC payload formats.....................................10
   4.1. Common header payload (HDR)................................11
   4.2. Key data transport payload (KEMAC).........................12
   4.3. ID payload (ID)............................................12
   5.   Security Considerations....................................13
   5.1. Security environment.......................................13
   5.2. Threat model...............................................13
   5.3. Security features and properties...........................16
   5.4. Assumptions................................................20
   5.5. Residual risk..............................................21
   IANA considerations.............................................22
   Intellectual Property Rights....................................22
   References......................................................23
   Normative References............................................23
   Informative References..........................................24
   Acknowledgments.................................................25
   Conclusions.....................................................25
   Full Copyright Statement........................................26
   Expiration Date.................................................27
   Revision History................................................27


Euchner                 Expires û January 2004                [Page 2]


             HMAC-authenticated Diffie-Hellman for MIKEY    July 2003


   Author's Addresses..............................................28



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 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
  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 is simple to



Euchner                 Expires û January 2004                [Page 3]


             HMAC-authenticated Diffie-Hellman for MIKEY    July 2003


         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.

         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.




Euchner                 Expires û January 2004                [Page 4]


             HMAC-authenticated Diffie-Hellman for MIKEY    July 2003


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


  This document describes a fourth key management scheme for MIKEY that
  could somehow be seen as a synergetic optimization 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 (DHHMAC).

  The DHHMAC variant closely follows the design and philosophy of MIKEY
  and reuses MIKEY protocol payload components and MIKEY mechanisms to
  its maximum benefit and for best compatibility.

  Like the MIKEY Diffie-Hellman protocol, DHHMAC does not scale beyond
  a point-to-point constellation; thus, both MIKEY Diffie-Hellman
  protocols do not support group-based keying for any group size larger
  than two entities.



  1.1.   Definitions

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



Euchner                 Expires û January 2004                [Page 5]


             HMAC-authenticated Diffie-Hellman for MIKEY    July 2003


  In this text, [X] represents an optional piece of information.
  Generally throughout the text, X SHOULD be present unless certain
  circumstance MAY allow X being optional and not be present thereby
  resulting in weaker security potentially.  Likewise [X, Y] represents
  an optional compound piece of information where the pieces X and Y
  SHOULD be either both present or MAY optionally be both absent.


  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 Initiatior
     DHr       public Diffie-Hellman half key g^(xr) of Responder
     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)
     HMAC-SHA1-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 [3] section 4.1.3.)
     RSA       Rivest, Shamir and Adleman
     s         pre-shared key
     SDP       Session Description Protocol
     SOI       Son-of-IKE, IKEv2
     SP        MIKEY Security Policy (Parameter) Payload
     T         timestamp
     TEK       Traffic Encryption Key
     TGK       MIKEY TEK Generation Key as the common Diffie-
               Hellman shared secret
     TLS       Transport Layer Security
     xi        secret, (pseudo) random Diffie-Hellman key of Initiator
     xr        secret, (pseudo) random Diffie-Hellman key of Responder




Euchner                 Expires û January 2004                [Page 6]


             HMAC-authenticated Diffie-Hellman for MIKEY    July 2003




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 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,
  DHHMAC assumes loosely synchronized clocks among the entities in the
  small group.


  2.1.   Applicability

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


Euchner                 Expires û January 2004                [Page 7]


             HMAC-authenticated Diffie-Hellman for MIKEY    July 2003




3. DHHMAC Security Protocol

     The following figure defines the security protocol for DHHMAC:

                  Initiator                        Responder

      I_message = HDR, T, RAND, [IDi],
                  {SP}, DHi, KEMAC
                              I_message
                       ----------------------->   R_message = HDR, T,
                                                   [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 (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
     payload IDi within the I_message; unless the receiver can defer the
     initiator's identity by some other means, then IDi MAY optionally
     be left out.

     The group parameters (e.g., the group G) are a set of parameters
     chosen by the initiator.  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.



Euchner                 Expires û January 2004                [Page 8]


             HMAC-authenticated Diffie-Hellman for MIKEY    July 2003


     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 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
     [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 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 fields
     for DHHMAC update message.


                  Initiator                        Responder

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


Euchner                 Expires û January 2004                [Page 9]


             HMAC-authenticated Diffie-Hellman for MIKEY    July 2003


                                R_message
                       <----------------------

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


                      Figure 2: DHHMAC update message

     TGK re-keying supports two procedures:
     a) True re-keying by exchanging new and fresh Diffie-Hellman half-
         keys.  For this, the initiator SHALL provide a new, fresh DHi
         and the responder SHALL respond with a new, fresh DHr and the
         received DHi.

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


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.


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

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

  * DH data payload, see [3] section 6.4

  * Timestamp payload, [3] section 6.6

  * ID payload, [3] section 6.7


Euchner                 Expires û January 2004               [Page 10]


             HMAC-authenticated Diffie-Hellman for MIKEY    July 2003



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

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

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

  * General Extension Payload, [3] section 6.15


  4.1.   Common header payload (HDR)

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

        Data type     | Value | Comment
     -------------------------------------------------------------
        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





     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

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





Euchner                 Expires û January 2004               [Page 11]


             HMAC-authenticated Diffie-Hellman for MIKEY    July 2003


     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 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
        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 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 DHHMAC, this payload SHALL only hold a non-certificate based
     identity.




Euchner                 Expires û January 2004               [Page 12]


             HMAC-authenticated Diffie-Hellman for MIKEY    July 2003





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.

  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 where the DHHMAC protocol entity runs upon shall provide
  the capability to generate (pseudo) random numbers as input to the
  Diffie-Hellman operation (see [9], [15]).  Further, the system shall
  be capable of storing the generated (pseudo) random data, secret
  data, keys and other secret security parameters securely (i.e.
  confidential and safe from unauthorized tampering).

  5.2.   Threat model

  The threat model 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.



Euchner                 Expires û January 2004               [Page 13]


             HMAC-authenticated Diffie-Hellman for MIKEY    July 2003


    This threat shall not occur. Nevertheless, 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 that availability of such Diffie-Hellman
    half-keys to an eavesdropper does not result in any substantial
    security risk; see 5.4.  Further, 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:
    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 mechanism as described in [3] section 7.1,
     where all key management protocol identifiers must be listed within
     the MIKEY General Extension Payload.  The protocol identifier for


Euchner                 Expires û January 2004               [Page 14]


             HMAC-authenticated Diffie-Hellman for MIKEY    July 2003


     DHHMAC shall be "mikeydhhmac".  The General Extension Payload must
     be integrity-protected with the HMAC using the shared secret.


  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 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 and its massive instant duplication.  Such attacks might at
    least be countered partially by some local means that are outside
    the scope of this document.

  * Identity protection:
    Like MIKEY, identity protection is not a major design requirement
    for MIKEY-DHHMAC either, see [3].  No security protocol is known so
    far, that is able to provide the objectives of DHHMAC as stated in
    section 5.3 including identity protection within just a single
    roundtrip.  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 ([20], [5]); both those protocols do not
    provide end-to-end identity protection.

    The DHHMAC security protocol (see section 3) and the TGK re-keying
    security protocol (see section 3.1) provide the option not to
    supply identity information.  This option is only applicable if
    some other means are available of supplying trustworthy identity


Euchner                 Expires û January 2004               [Page 15]


             HMAC-authenticated Diffie-Hellman for MIKEY    July 2003


    information; e.g., by relying on secured links underneath of MIKEY
    that supply trustworthy identity information otherwise.  However,
    it is understood that without identity information present, the
    MIKEY key management security protocols might be subject to
    security weaknesses such as masquerade, impersonation and
    reflection attacks particularly in end-to-end scenarios where no
    other secure means of assured identity information is provided.
    Leaving identity fields optional if possible thus should not be
    seen as a privacy method either, but rather as a protocol
    optimization feature.




  5.3.   Security features and properties

  With the security threats in mind, this draft provides the following
  security features and yields the following properties:

  * Secure key agreement with the establishment of a TGK at both peers:
    This is achieved using an authenticated Diffie-Hellman key
    management protocol.

  * Peer-entity authentication (mutual):
    This authentication corroborates that the host/user is authentic in
    that possession of a pre-assigned secret key is proven using keyed
    HMAC.  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,
    DHHMAC authentication means support and facilitate realization of
    authorization means (local issue).

  * Cryptographic integrity check:



Euchner                 Expires û January 2004               [Page 16]


             HMAC-authenticated Diffie-Hellman for MIKEY    July 2003


    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.

    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.

  * Limited DoS protection:
    Rapid checking of the message digest allows verifying the
    authenticity and integrity of a message before launching CPU
    intensive Diffie-Hellman operations or starting other resource
    consuming tasks.  This protects against some denial-of-service
    attacks: malicious modification of messages and spam attacks with
    (replayed or masqueraded) messages.  DHHMAC probably does not
    explicitly counter sophisticated distributed, large-scale denial-
    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.

    Neither the MIKEY pre-shared nor the MIKEY public-key protocol
    variants are able to provide the security property of perfect-
    forward secrecy.  Thus, none of the other MIKEY protocols is able
    to substitute the Diffie-Hellman PFS property.

    As such, DHHMAC 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


Euchner                 Expires û January 2004               [Page 17]


             HMAC-authenticated Diffie-Hellman for MIKEY    July 2003


    to its peers.  Actually, both parties involved in the protocol
    exchange are able to equally contribute to the common Diffie-
    Hellman TEK traffic generating key.  This reduces the risk of
    either party cheating or unintentionally generating a weak session
    key.  This makes the DHHMAC a fair key agreement protocol. One may
    view this property as an additional distributed security measure
    that is increasing security robustness over the case where all the
    security depends just on the proper implementation of a single
    entity.

    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.

    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 [6] for more details.  In


Euchner                 Expires û January 2004               [Page 18]


             HMAC-authenticated Diffie-Hellman for MIKEY    July 2003


    any way, truncated 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, DHHMAC consumes
    more CPU cycles than the MIKEY pre-shared key distribution
    protocol.  The same might hold true quite likely for the MIKEY
    public-key distribution protocol (depending on choice of the
    private and public key lengths).

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

    The use of optional identity information (with the constraints
    stated in section 5.2) and optional Diffie-Hellman half-key fields
    provides a means to increase performance and shorten the consumed
    network bandwidth.

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

    DHHMAC does not depend on PKI nor do implementations require PKI
    standards and thus is believed to be much simpler than the more
    complex PKI facilities.




Euchner                 Expires û January 2004               [Page 19]


             HMAC-authenticated Diffie-Hellman for MIKEY    July 2003


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

  * 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, DHHMAC does not necessarily
    require a firewall/NAT to operate.

  * Scalability:
    Like the MIKEY signed Diffie-Hellman protocol, 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 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


Euchner                 Expires û January 2004               [Page 20]


             HMAC-authenticated Diffie-Hellman for MIKEY    July 2003


    particular, the security depends on the message authentication
    property of the compression function of the hash function H when
    applied to single blocks (see [6]).

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

  * The systems upon which DHHMAC runs are sufficiently secure.

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


Euchner                 Expires û January 2004               [Page 21]


             HMAC-authenticated Diffie-Hellman for MIKEY    July 2003



  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 robust against potential threats than RSA.
  Note, that an elliptic-curve Diffie-Hellman variant of MIKEY remains
  for further study.


  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.


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


Intellectual Property Rights
     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


Euchner                 Expires û January 2004               [Page 22]


             HMAC-authenticated Diffie-Hellman for MIKEY    July 2003


     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.


References
   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", Internet Draft <draft-ietf-
       msec-mikey-07.txt>, Work in Progress (MSEC WG), IETF, June 2003.

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

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

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


Euchner                 Expires û January 2004               [Page 23]


             HMAC-authenticated Diffie-Hellman for MIKEY    July 2003



   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", Work in Progress <draft-iab-sec-cons-
       03.txt>, IETF, January 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", Work in Progress <draft-iab-
       secmech-02.txt>, IETF, January 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,
       2000. ftp://ftp.inf.ethz.ch/pub/crypto/publications/MauWol00c.ps

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

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

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

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

   [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>, IRTF, October 2002.



Euchner                 Expires û January 2004               [Page 24]


             HMAC-authenticated Diffie-Hellman for MIKEY    July 2003


   [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-
       06.txt>, IETF, June 2003.

   [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-08.txt>, IETF, May
       2003.

   [22] Draft ITU-T Recommendation H.235 Annex G: "Usage of the Secure
       Real Time Transport Protocol (SRTP) in conjunction with the
       MIKEY Key Management Protocol within H.235"; 5/2003.

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

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

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


Acknowledgments

   This document incorporates kindly review feedback by Steffen Fries
   and Fredrick Lindholm and general feedback by the MSEC WG.


Conclusions

  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 schemes are not deemed adequate in addressing
  sufficiently those real-time and security requirements.


Euchner                 Expires û January 2004               [Page 25]


             HMAC-authenticated Diffie-Hellman for MIKEY    July 2003



  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.


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




Euchner                 Expires û January 2004               [Page 26]


             HMAC-authenticated Diffie-Hellman for MIKEY    July 2003


Expiration Date

  This Internet Draft expires on 30 January 2004.

Revision History

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

     * text allows both random and pseudo-random values.
     * exponentiation ** changed to ^.
     * Notation aligned with MIKEY-07.
     * Clarified that the HMAC is calculated over the entire MIKEY
       message excluding the MAC field.
     * Section 4.2: The AES key wrap method SHALL not be applied.
     * Section 1: Relationship with other, existing work mentioned.
     *


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

     * bidding-down attacks addressed (see section 5.2).
     * optional [X], [X, Y] defined and clarified (see section 1.1,
       5.3).
     * combination of options defined in key update procedure (see
       section 3.1).
     * ID payloads clarified (see section 3 and 5.2).
     * relationship with MIKEY explained (roundtrip, performance).
     * new section 2.1 on applicability of DHHMAC for SIP/SDP and
       H.323 added.
     * more text due to DH resolution incorporated in section 5.3
       regarding PFS, security robustness of DH, generalization
       capability of DH to general groups in particular EC and
       "future-proofness".
     * a few editorials and nits.
     * references adjusted and cleaned-up.

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

     * category set to proposed standard.
     * identity protection clarified.
     * aligned with MIKEY-05 DH protocol, notation and with payload
     * some editorials and nits.



Euchner                 Expires û January 2004               [Page 27]


             HMAC-authenticated Diffie-Hellman for MIKEY    July 2003


   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 [8].
     * IANA consideration section added
     * a few editorial improvements and corrections
     * IPR clarified and IPR section changed.




Author's Addresses

   Martin Euchner
   Email: martin_euchner@hotmail.com
   Phone: +49 89 722 55790                       Hofmannstr. 51
   Fax:   +49 89 722 62366

   81359 Munich, Germany





















Euchner                 Expires û January 2004               [Page 28]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/