diff options
Diffstat (limited to 'doc/rfc/rfc4650.txt')
| -rw-r--r-- | doc/rfc/rfc4650.txt | 1515 |
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] + |