GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4650

Network Working Group M. Euchner Request for Comments: 4650 September 2006 Category: Standards Track

                 HMAC-Authenticated Diffie-Hellman
               for Multimedia Internet KEYing (MIKEY)

Status of This Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2006).

Abstract

 This document describes a lightweight point-to-point key management
 protocol variant for the multimedia Internet keying (MIKEY) protocol
 MIKEY, as defined in RFC 3830.  In particular, this variant deploys
 the classic Diffie-Hellman key agreement protocol for key
 establishment featuring perfect forward secrecy in conjunction with a
 keyed hash message authentication code for achieving mutual
 authentication and message integrity of the key management messages
 exchanged.  This protocol addresses the security and performance
 constraints of multimedia key management in MIKEY.

Euchner Standards Track [Page 1] RFC 4650 HMAC-Authenticated Diffie-Hellman for MIKEY September 2006

Table of Contents

 1. Introduction ....................................................2
    1.1. Definitions ................................................5
    1.2. Abbreviations ..............................................6
    1.3. Conventions Used in This Document ..........................7
 2. Scenario ........................................................7
    2.1. Applicability ..............................................7
    2.2. Relation to GKMARCH ........................................8
 3. DHHMAC Security Protocol ........................................8
    3.1. TGK Re-keying .............................................10
 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
    4.4. General Extension Payload .................................12
 5. Security Considerations ........................................13
    5.1. Security Environment ......................................13
    5.2. Threat Model ..............................................13
    5.3. Security Features and Properties ..........................15
    5.4. Assumptions ...............................................19
    5.5. Residual Risk .............................................20
    5.6. Authorization and Trust Model .............................21
 6. Acknowledgments ................................................21
 7. IANA Considerations ............................................22
 8. References .....................................................22
    8.1. Normative References ......................................22
    8.2. Informative References ....................................22
 Appendix A. Usage of MIKEY-DHHMAC in H.235 ........................25

1. Introduction

 There is work done in IETF to develop key management schemes.  For
 example, IKE [12] is a widely accepted unicast scheme for IPsec, and
 the MSEC WG is developing other schemes, addressed to group
 communication [17], [18].  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 [2]), secure real-time multimedia
 applications demand a particular adequate lightweight key management
 scheme that takes care to establish dynamic session keys securely and
 efficiently 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

Euchner Standards Track [Page 2] RFC 4650 HMAC-Authenticated Diffie-Hellman for MIKEY September 2006

 management schemes for the peer-to-peer case that all finish their
 task within one roundtrip:
  1. a symmetric key distribution protocol (MIKEY-PS) based on pre-

shared master keys

  1. a public-key encryption-based key distribution protocol (MIKEY-PK

and reverse-mode MIKEY-RSA-R [33]) assuming a public-key

    infrastructure with RSA-based (Rivest, Shamir and Adleman)
    private/public keys and digital certificates
  1. a Diffie-Hellman key agreement protocol (MIKEY-DHSIGN) deploying

digital signatures and certificates.

 All of these three key management protocols are designed so that they
 complete their work within just one roundtrip.  This requires
 depending on loosely synchronized clocks and deploying timestamps
 within the key management protocols.
 However, it is known [6] that each of the three key management
 schemes has its subtle constraints and limitations:
  1. The symmetric key distribution protocol (MIKEY-PS) is simple to

implement; however, it was not intended to scale to support any

    configurations beyond peer-to-peer, simple one-to-many, and
    small-size (interactive) groups, due to the need for 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
    to choose a good and secure session secret; the responder is able
    neither to participate in the key generation nor to influence that
    process.  This is considered a specific limitation in less trusted
    environments.
  1. The public-key encryption scheme (MIKEY-PK and MIKEY-RSA-R [33])

depends upon a public-key infrastructure that certifies the

    private-public keys by issuing and maintaining digital
    certificates.  While such key management schemes provide full
    scalability in large networked configurations, public-key
    infrastructures are still not widely available, and, in general,
    implementations are significantly more complex.

Euchner Standards Track [Page 3] RFC 4650 HMAC-Authenticated Diffie-Hellman for MIKEY September 2006

    Further, additional roundtrips and computational processing might
    be necessary for each end system in order to ascertain
    verification of the digital certificates.  For example, typical
    operations in the context of a public-key infrastructure may
    involve extra network communication handshakes with the public-key
    infrastructure and with certification authorities and may
    typically involve additional processing steps in the end systems.
    These operations would include validating digital certificates
    (RFC 3029, [24]), ascertaining the revocation status of digital
    certificates (RFC 2560, [23]), asserting certificate policies,
    construction of certification path(s) ([26]), requesting and
    obtaining necessary certificates (RFC 2511, [25]), and management
    of certificates for such purposes ([22]).  Such steps and tasks
    all result in further delay of the key agreement or key
    establishment phase among the end systems, which negatively
    affects setup time.  Any extra PKI handshakes and processing are
    not in the scope of MIKEY, and since this document only deploys
    symmetric security mechanisms, aspects of PKI, digital
    certificates, and related processing are not further covered in
    this document.
    Finally, as in the symmetric case, the responder depends
    completely upon the initiator's choosing good and secure session
    keys.
  1. The third MIKEY-DHSIGN key management protocol deploys the

Diffie-Hellman key agreement scheme and authenticates the exchange

    of the Diffie-Hellman half-keys in each direction by using a
    digital signature.  This approach has the same advantages and
    deficiencies as described in the previous section in terms of a
    public-key infrastructure.
    However, the Diffie-Hellman key agreement protocol is known for
    its subtle security strengths in that it is able to provide full
    perfect forward secrecy (PFS) and further have to both parties
    actively involved in session key generation.  This special
    security property (despite the somewhat higher computational
    costs) makes Diffie-Hellman techniques attractive in practice.
 In order to overcome some of the limitations as outlined above, a
 special need has been recognized for another efficient key agreement
 protocol variant in MIKEY.  This protocol variant aims to provide the
 capability of perfect forward secrecy as part of a key agreement with
 low latency without dependency on a public-key infrastructure.

Euchner Standards Track [Page 4] RFC 4650 HMAC-Authenticated Diffie-Hellman for MIKEY September 2006

 This document describes a fourth lightweight key management scheme
 for MIKEY that could somehow be seen as a synergetic optimization
 between the pre-shared key distribution scheme and the Diffie-Hellman
 key agreement.
 The idea of the protocol in this document is to apply the Diffie-
 Hellman key agreement, but rather than deploy a digital signature for
 authenticity of the exchanged keying material, it instead uses a
 keyed-hash for 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 [2] 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
 [2] section 3.3.  However, the DHHMAC protocol is also applicable
 generally 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 [2] sections 4.1.3 and 4.1.5.
 In this text, [X] represents an optional piece of information.
 Generally throughout the text, X SHOULD be present unless certain
 circumstances MAY allow X to be optional and not to be present,
 thereby potentially resulting in weaker security.  Likewise, [X, Y]
 represents an optional compound piece of information where the pieces
 X and Y either SHOULD both be present or MAY optionally both be
 absent.  {X} denotes zero or more occurrences of X.

Euchner Standards Track [Page 5] RFC 4650 HMAC-Authenticated Diffie-Hellman for MIKEY September 2006

1.2. Abbreviations

 auth_key        Pre-shared authentication key, PRF-derived from
                 pre-shared key s.
 DH              Diffie-Hellman
 DHi             Public Diffie-Hellman half key g^(xi) of the
                 Initiator
 DHr             Public Diffie-Hellman half key g^(xr) of the
                 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)
 IDi             Identity of initiator
 IDr             Identity of receiver
 IKE             Internet Key Exchange
 IPsec           Internet Protocol Security
 MIKEY           Multimedia Internet KEYing
 MIKEY-DHHMAC    MIKEY Diffie-Hellman key management protocol using
                 HMAC
 MIKEY-DHSIGN    MIKEY Diffie-Hellman key agreement protocol
 MIKEY-PK        MIKEY public-key encryption-based key distribution
                 protocol
 MIKEY-PS        MIKEY pre-shared key distribution protocol
 p               Diffie-Hellman prime modulus
 PKI             Public-key Infrastructure
 PRF             MIKEY pseudo-random function (see [2] 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 the
                 Initiator
 xr              Secret, (pseudo) random Diffie-Hellman key of the
                 Responder

Euchner Standards Track [Page 6] RFC 4650 HMAC-Authenticated Diffie-Hellman for MIKEY September 2006

1.3. 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 [1].

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 to be available.  Rather,
 pre- shared master secrets are assumed to be available among the
 entities in such an environment.
 In a pair-wise group, it is assumed that each client will be setting
 up a session key for its outgoing links with its peer using the DH-
 MAC key agreement protocol.
 As is the case for the other three MIKEY key management protocols,
 DHHMAC assumes, at least, loosely synchronized clocks among the
 entities in the small group.
 To synchronize the clocks in a secure manner, some operational or
 procedural means are recommended.  MIKEY-DHHMAC does not define any
 secure time synchronization measures; however, sections 5.4 and 9.3
 of [2] provide implementation guidance on clock synchronization and
 timestamps.

2.1. Applicability

 MIKEY-DHHMAC and the other MIKEY key management protocols are
 intended for application-level key management and are optimized for
 multimedia applications with real-time session setup and session
 management constraints.
 As the MIKEY-DHHMAC key management protocol terminates in one
 roundtrip, DHHMAC is applicable for integration into two-way
 handshake session or call signaling protocols such as
 a) SIP [13] and SDP, where the encoded MIKEY messages are
    encapsulated and transported in SDP containers of the SDP
    offer/answer see RFC 3264 [27]) handshake, as described in [4];
    and

Euchner Standards Track [Page 7] RFC 4650 HMAC-Authenticated Diffie-Hellman for MIKEY September 2006

 b) H.323 (see [15]), where the encoded MIKEY messages are transported
    in the H.225.0 fast start call signaling handshake.  Appendix A
    outlines the usage of MIKEY-DHHMAC within H.235.
 MIKEY-DHHMAC is offered as an option to the other MIKEY key
 management variants (MIKEY-pre-shared, MIKEY-public-key and MIKEY-
 DH-SIGN) for all those cases where DHHMAC has its particular
 strengths (see section 5).

2.2. Relation to GKMARCH

 The Group key management architecture (GKMARCH) [19] describes a
 generic architecture for multicast security group key management
 protocols.  In the context of this architecture, MIKEY-DHHMAC may
 operate as a registration protocol; see also [2] section 2.4.  The
 main entities involved in the architecture are a group controller/key
 server (GCKS), the receiver(s), and the sender(s).  Due to the pair-
 wise nature of the Diffie-Hellman operation and the 1-roundtrip
 constraint, usage of MIKEY-DHHMAC rules out any deployment as a group
 key management protocol with more than two group entities.  Only the
 degenerate case with two peers is possible where, for example, the
 responder acts as the group controller.
 Note that MIKEY does not provide re-keying in the GKMARCH sense, only
 updating of the keys by normal unicast messages.

3. DHHMAC Security Protocol

 The following figure defines the security protocol for DHHMAC:
             Initiator                        Responder
 I_message = HDR, T, RAND, [IDi], IDr,
             {SP}, DHi, KEMAC
                  ----------------------->   R_message = HDR, T,
                                              [IDr], IDi, DHr,
                                              DHi, KEMAC
                  <----------------------
    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

Euchner Standards Track [Page 8] RFC 4650 HMAC-Authenticated Diffie-Hellman for MIKEY September 2006

 payloads IDi and IDr within the I_message; unless the receiver can
 defer the initiator's identity by some other means, IDi MAY
 optionally be omitted.  The initiator SHALL always include the
 recipient's identity.
 The group parameters (e.g., the group G) are a set of parameters
 chosen by the initiator.  Note that like in the MIKEY protocol, both
 sender and receiver explicitly transmit the Diffie-Hellman group G
 within the Diffie-Hellman payload DHi or DHr through an encoding
 (e.g., OAKLEY group numbering; see [2] section 6.4).  The actual
 group parameters g and p, however, are not explicitly transmitted but
 can be deduced from the Diffie-Hellman group G.  The responder
 chooses a (pseudo) random positive integer, xr, and sends an HMACed
 message including g^(xr) and the timestamp to the initiator.  The
 responder SHALL always include the initiator's identity IDi
 regardless of whether the I_message conveyed any IDi.  It is
 RECOMMENDED that the responder SHOULD always include the identity
 payload IDr within the R_message; unless the initiator can defer the
 responder's identity by some other means, IDr MAY optionally be left
 out.
 Both parties then calculate the TGK as g^(xi * xr).
 The HMAC authentication provides authentication of the DH half-keys
 and is necessary to avoid man-in-the-middle attacks.
 This approach is less expensive than digitally signed Diffie-Hellman
 in that both sides compute one exponentiation and one HMAC first,
 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 roundtrip delay, as well as the risk of
 denial-of-service attacks.
 Processing of the TGK SHALL be accomplished as described in MIKEY [2]
 section 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.

Euchner Standards Track [Page 9] RFC 4650 HMAC-Authenticated Diffie-Hellman for MIKEY September 2006

3.1. TGK Re-keying

 TGK re-keying for DHHMAC generally proceeds as described in [2]
 section 4.5.  Specifically, Figure 2 provides the message exchange
 for the DHHMAC update message.
             Initiator                        Responder
 I_message = HDR, T, [IDi], IDr,
             {SP}, [DHi], KEMAC
                  ----------------------->   R_message = HDR, T,
                                              [IDr], IDi,
                                              [DHr, DHi], KEMAC
                  <----------------------
                    Figure 2: DHHMAC update message
 TGK re-keying supports two procedures:
 a) True re-keying by exchanging new and fresh Diffie-Hellman half-
    keys.  For this, the initiator SHALL provide a new, fresh DHi, and
    the responder SHALL respond with a new, fresh DHr and the received
    DHi.
 b) Non-key related information update without including any Diffie-
    Hellman half-keys in the exchange.  Such a transaction does not
    change the actual TGK but updates other information such as
    security policy parameters.  To update the non-key related
    information only, [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 [2] section 6, for a definition of the MIKEY
 payloads.
 This document does not define new payload formats but re-uses MIKEY
 payloads for DHHMAC as referenced:
  • Common header payload (HDR); see section 4.1 and [2] section 6.1.
  • SRTP ID sub-payload; see [2] section 6.1.1.
  • Key data transport payload (KEMAC); see section 4.2 and [2] section

6.2.

  • DH data payload; see [2] section 6.4.

Euchner Standards Track [Page 10] RFC 4650 HMAC-Authenticated Diffie-Hellman for MIKEY September 2006

  • Timestamp payload; see [2] section 6.6.
  • ID payload; [2] section 6.7.
  • Security Policy payload (SP); see [2] section 6.10.
  • RAND payload (RAND); see [2] section 6.11.
  • Error payload (ERR); see [2] section 6.12.
  • General Extension Payload; see [2] section 6.15.

4.1. Common Header Payload (HDR)

 Referring to [2] section 6.1, the following data types SHALL be used
 for DHHMAC:
    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 [2] section 6.12
                              Table 4.1.a
 Note: A responder is able to recognize the MIKEY DHHMAC protocol by
 evaluating the data type field as 7 or 8.  This is how the responder
 can differentiate between MIKEY and MIKEY DHHMAC.
 The next payload field SHALL be one of the following values:
 Next payload| Value |       Section
 ----------------------------------------------------------------
 Last payload|     0 | -
 KEMAC       |     1 | section 4.2 and [2] section 6.2
 DH          |     3 | [2] section 6.4
 T           |     5 | [2] section 6.6
 ID          |     6 | [2] section 6.7
 SP          |    10 | [2] section 6.10
 RAND        |    11 | [2] section 6.11
 ERR         |    12 | [2] section 6.12
 General Ext.|    21 | [2] section 6.15
                              Table 4.1.b
 Other defined next payload values defined in [2] SHALL not be applied
 to DHHMAC.

Euchner Standards Track [Page 11] RFC 4650 HMAC-Authenticated Diffie-Hellman for MIKEY September 2006

 In case of a decoding error or of a failed HMAC authentication
 verification, the responder 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.  When used in
 conjunction with DHHMAC, KEMAC 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 [16]) 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 [2]
 section 5.2, and then stored within the MAC field.
    MAC alg       | Value |           Comments
 ------------------------------------------------------------------
    HMAC-SHA-1    |     0 | Mandatory, Default (see [3])
    NULL          |     1 | Very restricted use; see
                          | [2] section 4.2.4
                              Table 4.2.a
 HMAC-SHA-1 is the default hash function that MUST be implemented as
 part of the DHHMAC.  The length of the HMAC-SHA-1 result is 160 bits.

4.3. ID Payload (ID)

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

4.4. General Extension Payload

 For DHHMAC, to avoid bidding-down attacks, this payload SHALL list
 all key management protocol identifiers of a surrounding
 encapsulation protocol, such as SDP [4].  The General Extension
 Payload SHALL be integrity protected with the HMAC using the shared
 secret.
 Type      | Value | Comments
 SDP IDs   |     1 | List of SDP key management IDs (allocated for
                     use in [4]); see also [2] section 6.15.
                              Table 4.4.a

Euchner Standards Track [Page 12] RFC 4650 HMAC-Authenticated Diffie-Hellman for MIKEY September 2006

5. Security Considerations

 This document addresses key management security issues throughout.
 For a comprehensive explanation of MIKEY security considerations,
 please refer to MIKEY [2] section 9.
 In addition, this document addresses security issues according to
 [7], where the following security considerations apply in particular
 to this document:

5.1. Security Environment

 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 also of interest that are not explicitly defined
 by the DHHMAC protocol, but that should be provided locally in
 practice.
 The system that runs the DHHMAC protocol entity SHALL provide the
 capability to generate (pseudo) random numbers as input to the
 Diffie-Hellman operation (see [8]).  Furthermore, the system SHALL be
 capable of storing the generated (pseudo) random data, secret data,
 keys, and other secret security parameters securely (i.e.,
 confidential and safe from unauthorized tampering).

5.2. Threat Model

 The threat model, to which this document adheres, covers the issues
 of end-to-end security in the Internet generally, without ruling out
 the possibility that MIKEY DHHMAC can be deployed in a corporate,
 closed IP environment.  This also includes the possibility that MIKEY
 DHHMAC can be deployed on a hop-by-hop basis with some intermediate
 trusted "MIKEY DHHMAC proxies" involved.
 Since DHHMAC is a key management protocol, the following security
 threats are of concern:
  • Unauthorized interception of plain TGKs: For DHHMAC, this threat

does not occur since the TGK is not actually transmitted on the

   wire (not even in encrypted fashion).
  • Eavesdropping of other, transmitted keying information: DHHMAC

protocol does not explicitly transmit the TGK at all. Instead, by

   using the Diffie-Hellman "encryption" operation, which conceals the
   secret (pseudo) random values, only partial information (i.e., the
   DH half-key) for construction of the TGK is transmitted.  It is
   fundamentally assumed that availability of such Diffie-Hellman

Euchner Standards Track [Page 13] RFC 4650 HMAC-Authenticated Diffie-Hellman for MIKEY September 2006

   half-keys to an eavesdropper does not result in any substantial
   security risk; see 5.4.  Furthermore, the DHHMAC carries other data
   such as timestamps, (pseudo) random values, identification
   information or security policy parameters; eavesdropping of any
   such data is not considered 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.

   Although any such attacks cannot be avoided, they must at least be
   detected.  DHHMAC addresses this threat by providing message
   integrity.
  • Bidding-down attacks: When multiple key management protocols, each

of a distinct security level, are offered (such as those made

   possible by SDP [4]), avoiding bidding-down attacks is of concern.
   DHHMAC addresses this threat by reusing the MIKEY General Extension
   Payload mechanism, where all key management protocol identifiers
   are to be listed within the MIKEY General Extension Payload.
 Some potential threats are not within the scope of this threat model:
  • Passive and off-line cryptanalysis of the Diffie-Hellman algorithm:

Under certain reasonable assumptions (see 5.4, below), it is widely

   believed that DHHMAC is sufficiently secure and that such attacks
   are infeasible, although the possibility of a successful attack
   cannot be ruled out.
  • Non-repudiation of the receipt or of the origin of the message:

These are not requirements within the context of DHHMAC in this

   environment, and thus related countermeasures are not provided at
   all.

Euchner Standards Track [Page 14] RFC 4650 HMAC-Authenticated Diffie-Hellman for MIKEY September 2006

  • 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
   is 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 [2]. No security

   protocol is known so far that is able to provide the objectives of
   DHHMAC as stated in section 5.3, including identity protection
   within just a single roundtrip.  MIKEY-DHHMAC trades identity
   protection for better security for the keying material and shorter
   roundtrip time.  Thus, MIKEY-DHHMAC does not provide identity
   protection on its own but may inherit such property from a security
   protocol underneath that actually features identity protection.
   The DHHMAC security protocol (see section 3) and the TGK re-keying
   security protocol (see section 3.1) provide the option not to
   supply identity information.  This option is only applicable if
   some other means are available to supply trustworthy identity
   information; e.g., by relying on secured links underneath MIKEY
   that supply trustworthy identity information some other way.
   However, it is understood that without identity information, 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 are provided.
   Leaving identity fields optional (if doing so is 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 document 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.

Euchner Standards Track [Page 15] RFC 4650 HMAC-Authenticated Diffie-Hellman for MIKEY September 2006

  • Peer-entity authentication (mutual): This authentication

corroborates that the host/user is authentic in that possession of

   a pre-assigned secret key is proven using keyed HMAC.
   Authentication occurs on the request and on the response message;
   thus authentication is mutual.
   The HMAC computation corroborates for authentication and message
   integrity of the exchanged Diffie-Hellman half-keys and associated
   messages.  The authentication is absolutely necessary in order to
   avoid man-in-the-middle attacks on the exchanged messages in
   transit and, in particular, on the otherwise non-authenticated
   exchanged Diffie-Hellman half-keys.
   Note: This document does not address issues regarding
   authorization; this feature is not provided explicitly.  However,
   DHHMAC authentication means support and facilitate realization of
   authorization means (local issue).
  • Cryptographic integrity check: The cryptographic integrity check is

achieved using a message digest (keyed HMAC). It includes the

   exchanged Diffie-Hellman half-keys but covers the other parts of
   the exchanged message as well.  Both mutual peer entity
   authentication and message integrity provide effective
   countermeasures against man-in-the-middle attacks.
   The initiator may deploy a local timer that fires when the awaited
   response message did not arrive in a timely manner.  This is
   intended to detect deletion of entire messages.
  • Replay protection of the messages is achieved using embedded

timestamps: In order to detect replayed messages, it is essential

   that the clocks among initiator and sender be roughly synchronized.
   The reader is referred to [2] section 5.4, and [2] section 9.3,
   which provide further considerations and give guidance on clock
   synchronization and timestamp usage.  Should the clock
   synchronization be lost, end systems cannot detect replayed
   messages anymore, and the end systems cannot securely establish
   keying material.  This may result in a denial-of-service; see [2]
   section 9.5.
  • Limited DoS protection: Rapid checking of the message digest allows

verifying the authenticity and integrity of a message before

   launching CPU intensive Diffie-Hellman operations or starting other
   resource consuming tasks.  This protects against some denial-of-
   service attacks: malicious modification of messages and spam
   attacks with (replayed or masqueraded) messages.  DHHMAC probably
   does not explicitly counter sophisticated distributed, large-scale
   denial-of-service attacks that compromise system availability, for

Euchner Standards Track [Page 16] RFC 4650 HMAC-Authenticated Diffie-Hellman for MIKEY September 2006

   example.  Some DoS protection is provided by inclusion of the
   initiator's identity payload in the I_message.  This allows the
   recipient to filter out those (replayed) I_messages that are not
   targeted for him and to avoid creating unnecessary MIKEY sessions.
  • Perfect-forward secrecy (PFS): Other than the MIKEY pre-shared and

public-key-based key distribution protocols, the Diffie-Hellman key

   agreement protocol features a security property called perfect
   forward secrecy.  That is, even if the long-term pre-shared key is
   compromised at some point in time, this does not compromise past or
   future session keys.
   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 and digitally signed DH provide a far superior
   security level to that of 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, in which

   the initiator distributes a key to its peers.  Actually, both
   parties involved in the protocol exchange are able to contribute to
   the common Diffie-Hellman TEK traffic generating key equally.  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 increases security robustness
   over that of the case where all the security depends just on the
   proper implementation of a single entity.
   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, such as IPsec-IKE [12], IPsec-IKEv2 [14], TLS [11], and
   other schemes, are not deemed adequate in addressing those real-
   time and security requirements sufficiently; they all use more than
   a single roundtrip.  All the MIKEY key management protocols are
   able to complete their task of security policy parameter

Euchner Standards Track [Page 17] RFC 4650 HMAC-Authenticated Diffie-Hellman for MIKEY September 2006

   negotiation, including key-agreement or key distribution, in one
   roundtrip.  However, the MIKEY pre-shared and MIKEY public-key
   protocol are both able to complete their task even in a half-
   roundtrip 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.
   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 roundtrip delay,
   either party may  pre-compute its public Diffie-Hellman half-key
   off-line.
   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, which

   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 additional steps are taken for
   certificate validation and certificate revocation methods with
   additional roundtrips into account.

Euchner Standards Track [Page 18] RFC 4650 HMAC-Authenticated Diffie-Hellman for MIKEY September 2006

   DHHMAC does not depend on PKI, nor do implementations require PKI
   standards.  Thus, it is believed to be much simpler than the more
   complex PKI facilities.
   DHHMAC is particularly attractive in those environments where
   provisioning of a pre-shared key has already been accomplished.
  • NAT-friendliness: DHHMAC is able to operate smoothly through

firewall/NAT devices as long as the protected identity information

   of the end entity is not an IP/transport address.
  • Scalability: Like the MIKEY signed Diffie-Hellman protocol, DHHMAC

does not scale to any larger configurations beyond peer-to-peer

   groups.

5.4. Assumptions

 This document states a couple of assumptions upon which the security
 of DHHMAC significantly depends.  The following conditions are
 assumed:
  • 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 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 [6], [9], or
   [10] for more background information regarding the Diffie-Hellman
   problem and its computational complexity assumptions.
  • The hash function (SHA1) is secure; i.e., it is computationally

infeasible to find a message that 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 it
   is applied to single blocks (see [5]).

Euchner Standards Track [Page 19] RFC 4650 HMAC-Authenticated Diffie-Hellman for MIKEY September 2006

  • A source capable of producing sufficiently many bits of (pseudo)

randomness is available.

  • The system upon which DHHMAC runs is sufficiently secure.

5.5. Residual Risk

 Although these detailed assumptions are non-negligible, security
 experts generally believe that all these assumptions are reasonable
 and that the assumptions made can be fulfilled in practice with
 little or no expenses.
 The mathematical and cryptographic assumptions of the properties of
 the PRF, the Diffie-Hellman algorithm (discrete log-assumption), the
 HMAC algorithm, and the SHA1 algorithms have been neither proven nor
 disproven at this time.
 Thus, a certain residual risk remains, which might threaten the
 overall security at some unforeseeable time in the future.
 The DHHMAC would be compromised as soon as any of the listed
 assumptions no longer hold.
 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 computationally intensive.  Nevertheless,
 Elliptic Curve Diffie-Hellman (ECDH) allows key lengths to be cut
 down substantially (say 170 bits or more) while maintaining at least
 the security level and providing even more significant performance
 benefits in practice.  Moreover, it is believed that elliptic-curve
 techniques provide much better protection against side channel
 attacks due to the inherent redundancy in the projective coordinates.
 For all these reasons, one may view elliptic-curve-based Diffie-
 Hellman as being more "future-proof" and robust against potential
 threats than RSA is.  Note that Elliptic Curve Diffie-Hellman
 variants of MIKEY are defined in [31].

Euchner Standards Track [Page 20] RFC 4650 HMAC-Authenticated Diffie-Hellman for MIKEY September 2006

 HMAC-SHA1 is a key security mechanism within DHHMAC on which the
 overall security of MIKEY DHHMAC depends.  MIKEY DHHMAC uses HMAC-
 SHA1 in combination with the classic Diffie-Hellman key agreement
 scheme.  HMAC-SHA1 is a keyed one-way hash function that involves a
 secret in its computation.  DHHMAC applies HMAC-SHA1 for protection
 of the MIKEY payload.  Likewise, the pseudo-random function PRF
 within MIKEY [2] uses the HMAC-SHA1 mechanism as a key derivation
 function.  While certain attacks have been reported against SHA1 and
 MD5 (see [29]), with current knowledge (see [29], [30]), no attacks
 have been reported against the HMAC-SHA1 security mechanism.  In
 fact, [32] proves that HMAC possesses the property of a pseudo-random
 function PRF assuming solely that the (SHA1) hash function is a
 pseudo-random function. [32] also provides evidence that HMAC is
 robust against collision attacks on the underlying hash function.  It
 is believed that MIKEY DHHMAC should be considered secure enough for
 the time being.  Thus, there is no need to change the underlying
 security mechanism within the MIKEY DHHMAC protocol.
 It is not recommended to deploy DHHMAC for any other use than that
 depicted in section 2.  Any misapplication might lead to unknown,
 undefined properties.

5.6. Authorization and Trust Model

 Basically, similar remarks on authorization as those stated in [2]
 section 4.3.2 hold also for DHHMAC.  However, as noted before, this
 key management protocol does not serve full groups.
 One may view the pre-established shared secret as yielding some pre-
 established trust relationship between the initiator and the
 responder.  This results in a much simpler trust model for DHHMAC
 than would be the case for some generic group key management protocol
 and potential group entities without any pre-defined trust
 relationship.  In conjunction with the assumption of a shared key,
 the common group controller simplifies the communication setup of the
 entities.
 One may view the pre-established trust relationship through the pre-
 shared secret as some means for pre-granted, implied authorization.
 This document does not define any particular authorization means but
 leaves this subject to the application.

6. Acknowledgments

 This document incorporates kindly, valuable review feedback from
 Steffen Fries, Hannes Tschofenig, Fredrick Lindholm, Mary Barnes, and
 Russell Housley and general feedback by the MSEC WG.

Euchner Standards Track [Page 21] RFC 4650 HMAC-Authenticated Diffie-Hellman for MIKEY September 2006

7. IANA Considerations

 This document does not define its own new name spaces for DHHMAC,
 beyond the IANA name spaces that have been assigned for MIKEY; see
 [2] sections 10 and 10.1 and IANA MIKEY payload name spaces [37].
 In order to align Table 4.1.a with Table 6.1.a in [2], IANA is
 requested to add the following entries to their MIKEY Payload Name
 Space:
 Data Type        Value  Reference
 ---------------  -----  ---------
 DHHMAC init          7  RFC 4650
 DHHMAC resp          8  RFC 4650

8. References

8.1. Normative References

 [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
       Levels", BCP 14, RFC 2119, March 1997.
 [2]   Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
       Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August
       2004.
 [3]   NIST, FIBS-PUB 180-2, "Secure Hash Standard", April 1995,
       http://csrc.nist.gov/publications/fips/fips180-2/
       fips180-2withchangenotice.pdf.
 [4]   Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E.
       Carrara, "Key Management Extensions for Session Description
       Protocol (SDP) and Real Time Streaming Protocol (RTSP)", RFC
       4567, July 2006.
 [5]   Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
       for Message Authentication", RFC 2104, February 1997.

8.2. Informative References

 [6]   A.J. Menezes, P. van Oorschot, S. A. Vanstone: "Handbook of
       Applied Cryptography", CRC Press 1996.
 [7]   Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on
       Security Considerations", BCP 72, RFC 3552, July 2003.
 [8]   Eastlake 3rd, D., Crocker, S., and J. Schiller, "Randomness
       Recommendations for Security", RFC 1750, December 1994.

Euchner Standards Track [Page 22] RFC 4650 HMAC-Authenticated Diffie-Hellman for MIKEY September 2006

 [9]   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.
 [10]  Discrete Logarithms and the Diffie-Hellman Protocol,
       http://www.crypto.ethz.ch/research/ntc/dldh/.
 [11]  Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
       Protocol Version 1.1", RFC 4346, April 2006.
 [12]  Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
       RFC 2409, November 1998.
 [13]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
       Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
       Session Initiation Protocol", RFC 3261, June 2002.
 [14]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
       4306, December 2005.
 [15]  ITU-T Recommendation H.235.7: " H.323 Security framework: Usage
       of the MIKEY Key Management Protocol for the Secure Real Time
       Transport Protocol (SRTP) within H.235"; 9/2005.
 [16]  Schaad, J. and R. Housley, "Advanced Encryption Standard (AES)
       Key Wrap Algorithm", RFC 3394, September 2002.
 [17]  Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group
       Domain of Interpretation", RFC 3547, July 2003.
 [18]  Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP:
       Group Secure Association Key Management Protocol", RFC 4535,
       June 2006.
 [19]  Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm,
       "Multicast Security (MSEC) Group Key Management Architecture",
       RFC 4046, April 2005.
 [20]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
       Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC
       3711, March 2004.
 [21]  ITU-T Recommendation H.235.0, " H.323 Security framework:
       Security framework for H-series (H.323 and other H.245 based)
       multimedia systems", (09/2005).

Euchner Standards Track [Page 23] RFC 4650 HMAC-Authenticated Diffie-Hellman for MIKEY September 2006

 [22]  Adams, C., Farrell, S., Kause, T., and T. Mononen, "Internet
       X.509 Public Key Infrastructure Certificate Management Protocol
       (CMP)", RFC 4210, September 2005.
 [23]  Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams,
       "X.509 Internet Public Key Infrastructure Online Certificate
       Status Protocol - OCSP", RFC 2560, June 1999.
 [24]  Adams, C., Sylvester, P., Zolotarev, M., and R. Zuccherato,
       "Internet X.509 Public Key Infrastructure Data Validation and
       Certification Server Protocols", RFC 3029, February 2001.
 [25]  Schaad, J., "Internet X.509 Public Key Infrastructure
       Certificate Request Message Format (CRMF)", RFC 4211, September
       2005.
 [26]  Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R.
       Nicholas, "Internet X.509 Public Key Infrastructure:
       Certification Path Building", RFC 4158, September 2005.
 [27]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
       Session Description Protocol (SDP)", RFC 3264, June 2002.
 [37]  IANA MIKEY Payload Name Spaces per RFC 3830, see
       http://www.iana.org/assignments/mikey-payloads.
 [29]  Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes
       in Internet Protocols", RFC 4270, November 2005.
 [30]  Bellovin, S.M. and E.K. Rescorla: "Deploying a New Hash
       Algorithm", October 2005,
       http://www.cs.columbia.edu/~smb/papers/new-hash.pdf.
 [31]  Milne, A., Blaser, M., Brown, D., and L. Dondetti, "ECC
       Algorithms For MIKEY", Work in Progress, June 2005.
 [32]  Bellare, M.: "New Proofs for NMAC and HMAC: Security Without
       Collision-Resistance", http://eprint.iacr.org/2006/043.pdf,
       November 2005.
 [33]  Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "An
       additional mode of key Distribution in MIKEY: MIKEY-RSA-R",
       Work in Progress, August 2006.

Euchner Standards Track [Page 24] RFC 4650 HMAC-Authenticated Diffie-Hellman for MIKEY September 2006

Appendix A. Usage of MIKEY-DHHMAC in H.235

 This appendix provides informative overview how MIKEY-DHHMAC can be
 applied in some H.323-based multimedia environments.  Generally,
 MIKEY is applicable for multimedia applications including IP
 telephony.  [15] describes various use cases of the MIKEY key
 management protocols (MIKEY-PS, MIKEY-PK, MIKEY-DHSIGN and MIKEY-
 DHHMAC) with the purpose to establish TGK keying material among H.323
 endpoints.  The TGKs are then used for media encryption by applying
 SRTP [20].  Addressed scenarios include point-to-point with one or
 more intermediate gatekeepers (trusted or partially trusted) in
 between.
 One particular use case addresses MIKEY-DHHMAC to establish a media
 connection from an endpoint B calling (through a gatekeeper) to
 another endpoint A that is located within that same gatekeeper zone.
 While EP-A and EP-B typically do not share any auth_key a priori,
 some separate protocol exchange means are achieved outside the actual
 call setup procedure to establish an auth_key for the time while
 endpoints are being registered with the gatekeeper; such protocols
 exist [15] but are not shown in this document.  The auth_key between
 the endpoints is being used to authenticate and integrity protect the
 MIKEY-DHHMAC messages.
 To establish a call, it is assumed that endpoint B has obtained
 permission from the gatekeeper (not shown).  Endpoint B as the caller
 builds the MIKEY-DHHMAC I_message (see section 3) and sends the
 I_message encapsulated within the H.323-SETUP to endpoint A.  A
 routing gatekeeper (GK) would forward this message to endpoint B; in
 case of a non-routing gatekeeper, endpoint B sends the SETUP directly
 to endpoint A.  In either case, H.323 inherent security mechanisms
 [21] are applied to protect the (encapsulation) message during
 transfer.  This is not depicted here.  The receiving endpoint A is
 able to verify the conveyed I_message and can compute a TGK.
 Assuming that endpoint A would accept the call, EP-A then builds the
 MIKEY-DHHMAC R_message and sends the response as part of the
 CallProceeding-to-Connect message back to the calling endpoint B
 (possibly through a routing gatekeeper).  Endpoint B processes the
 conveyed R_message to compute the same TGK as the called endpoint A.
 1.) EP-B -> (GK) -> EP-A: SETUP(I_fwd_message [, I_rev_message])
 2.) EP-A -> (GK) -> EP-B: CallProceeding-to-CONNECT(R_fwd_message
     [, R_rev_message])
 Notes: If it is necessary to establish directional TGKs for full-
        duplex links in both directions B->A and A->B, then the
        calling endpoint B instantiates the DHHMAC protocol twice:
        once in the direction B->A using I_fwd_message and another run

Euchner Standards Track [Page 25] RFC 4650 HMAC-Authenticated Diffie-Hellman for MIKEY September 2006

        in parallel in the direction A->B using I_rev_message.  In
        that case, two MIKEY-DHHMAC I_messages are encapsulated within
        SETUP (I_fwd_message and I_rev_message) and two MIKEY-DHHMAC
        R_messages (R_fwd_message and R_rev_message) are encapsulated
        within CallProceeding-to-CONNECT.  The I_rev_message
        corresponds with the I_fwd_message.  Alternatively, the called
        endpoint A may instantiate the DHHMAC protocol in a separate
        run with endpoint B (not shown); however, this requires a
        third handshake to complete.
        For more details on how the MIKEY protocols may be deployed
        with H.235, please refer to [15].

Author's Address

 Martin Euchner
 Hofmannstr. 51
 81359 Munich, Germany
 Phone: +49 89 722 55790
 Fax:   +49 89 722 62366
 EMail: martin_euchner@hotmail.com

Euchner Standards Track [Page 26] RFC 4650 HMAC-Authenticated Diffie-Hellman for MIKEY September 2006

Full Copyright Statement

 Copyright (C) The Internet Society (2006).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at
 ietf-ipr@ietf.org.

Acknowledgement

 Funding for the RFC Editor function is provided by the IETF
 Administrative Support Activity (IASA).

Euchner Standards Track [Page 27]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4650.txt · Last modified: 2006/09/28 23:11 (external edit)