doc: Add RFC documents

1 files changed, 1515 insertions, 0 deletions

diff --git a/doc/rfc/rfc4650.txt b/doc/rfc/rfc4650.txt
new file mode 100644
index 0000000..d03147d
--- /dev/null
+++ b/doc/rfc/rfc4650.txt
@@ -0,0 +1,1515 @@
+
+
+
+
+
+
+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:
+
+   -  a symmetric key distribution protocol (MIKEY-PS) based on pre-
+      shared master keys
+
+   -  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
+
+   -  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:
+
+   -  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.
+
+   -  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.
+
+   -  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]
+