RFC 4650

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

📅 published September 2006, from ietf

RFC 4650 🎀 HMAC-Authenticated Diffie-Hellman for Multimedia Internet KEYing (MIKEY) 💖

Author: M. Euchner 🧚 Series: Network Working Group Category: Standards Track 🌸 Date: September 2006 ✨ Obsoletes / Updates: the header doesn't list any, so this one doesn't obsolete or update anything 🫶

Status of This Memo 📜

okay so this doc is an Internet standards track protocol spec for the Internet community 🌈 and it's literally asking everyone to chat about it and send improvement ideas. For the official standardization state and status, check the current edition of the "Internet Official Protocol Standards" (STD 1) 💅. Distribution is unlimited, so share it with everyone 🦋

Copyright (C) The Internet Society (2006). ✨

Abstract 💜

this is giving a lightweight point-to-point key management protocol variant for the multimedia Internet keying (MIKEY) protocol, which is defined in RFC 3830 🫶 The main move here is using the classic Diffie-Hellman key agreement to set up keys with perfect forward secrecy 🔐 and pairing it with a keyed hash message authentication code, so both sides can authenticate each other and check that the key management messages weren't tampered with 🛡️ The whole point is solving the security and performance problems of multimedia key management in MIKEY, and honestly it's iconic 👑

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 🌸

okay so, IETF folks have been cooking up key management schemes for a while 🍳 IKE [12] is the widely loved unicast option for IPsec, and the MSEC WG is working on group communication schemes [17], [18]. But there's still a gap 🥺 we need a scheme with low latency that works for demanding stuff like real-time data over heterogeneous networks and small interactive groups, and I'll explain why below 💅

As pointed out in MIKEY (see [2]), secure real-time multimedia apps really need a lightweight key management scheme that sets up dynamic session keys securely and efficiently in a conversational multimedia setting 🎧 bestie, that's the whole vibe ✨

MIKEY scenarios cover peer-to-peer, simple one-to-many, and small groups 🧚 For peer-to-peer, MIKEY describes three key management schemes that each finish in 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]) that assumes 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) that uses digital signatures and certificates ✍️

All three of these are built to finish in just one roundtrip 🏃‍♀️ The catch is they depend on loosely synchronized clocks and use timestamps inside the key management protocols ⏰

But it's known [6] that each of the three has its own subtle constraints and limitations, so let's spill 🫣

  • MIKEY-PS is simple to implement 🫶 but it wasn't meant to scale beyond peer-to-peer, simple one-to-many, and small (interactive) groups, because it needs mutually pre-assigned shared master secrets 🙈

It also doesn't have perfect forward secrecy. Basically, if the shared master secret gets compromised, past and future session keys can be compromised too 💀

And the session key is only generated by the initiator 😬 so the responder has to fully trust the initiator to pick a good, secure session secret. The responder can't take part in key generation or influence it at all. That's a specific limitation in less trusted environments 🚩

  • MIKEY-PK and MIKEY-RSA-R [33] rely on a public-key infrastructure that certifies the private-public keys by issuing and maintaining digital certificates 📜 These schemes scale really well in large networks, but PKIs still aren't widely available, and implementations are way more complex 🤯

Plus, each end system might need extra roundtrips and computation to verify digital certificates 🐌 Typical PKI operations can involve extra network handshakes with the PKI and with certification authorities, and extra processing steps on the end systems. These include validating digital certificates (RFC 3029, [24]), checking the revocation status of digital certificates (RFC 2560, [23]), asserting certificate policies, constructing certification path(s) ([26]), requesting and obtaining necessary certificates (RFC 2511, [25]), and managing certificates for those purposes ([22]). All of that adds delay to the key agreement or key establishment phase among the end systems, which hurts setup time 😩 Any extra PKI handshakes and processing are outside MIKEY's scope, and since this document only uses symmetric security mechanisms, PKI, digital certificates, and related processing aren't covered further here 🙅‍♀️

And just like the symmetric case, the responder completely depends on the initiator choosing good, secure session keys 🥲

  • MIKEY-DHSIGN uses Diffie-Hellman key agreement and authenticates the exchange of the Diffie-Hellman half-keys in each direction with a digital signature ✍️ It has the same advantages and drawbacks as described above for the PKI situation 🫠

BUT. Diffie-Hellman is famous for its security strengths: it can provide full perfect forward secrecy (PFS), and both parties are actively involved in generating the session key 💅 That special security property, even with the somewhat higher computational costs, is why Diffie-Hellman techniques are so attractive in practice 🔥

To get past some of those limitations, there's a clear need for another efficient key agreement protocol variant in MIKEY 🧠 This one aims to provide perfect forward secrecy as part of a low-latency key agreement, with no dependency on a public-key infrastructure ✨

This document describes a fourth lightweight key management scheme for MIKEY 🦋 You could kind of see it as a synergetic optimization between the pre-shared key distribution scheme and the Diffie-Hellman key agreement 💜

The core idea is to use Diffie-Hellman key agreement, but instead of a digital signature to authenticate the exchanged keying material, it uses a keyed hash with symmetrically pre-assigned shared secrets 🔐 This combo of security mechanisms is called the HMAC-authenticated Diffie-Hellman (DH) key agreement for MIKEY (DHHMAC) 🎀

DHHMAC follows MIKEY's design and philosophy closely, and it reuses MIKEY protocol payload components and MIKEY mechanisms as much as possible for the best compatibility 🫶

Just like MIKEY's Diffie-Hellman protocol, DHHMAC doesn't scale beyond a point-to-point setup 🙃 So both MIKEY Diffie-Hellman protocols don't support group keying for any group bigger than two entities 🚫

1.1. Definitions 📖

The definitions and notations in this document line up 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 🔢 But DHHMAC also works generally with other appropriate finite, cyclical groups, so it's not picky 💖

It's 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] means an optional piece of information. Generally, X SHOULD be present, unless certain circumstances MAY allow X to be optional and not present, which could potentially mean weaker security 🫣 Likewise, [X, Y] is an optional compound piece of information where X and Y either SHOULD both be present or MAY optionally both be absent 🌈 And {X} means zero or more occurrences of X 🍓

Heads up, bestie: when the optional bits get skipped, the security can get weaker. Keep that in mind as you read the rest of the spec 👀

Part 2 is next, so stay tuned 🦋💖

1.2. Abbreviations ✨

Okay so here's the abbreviation list, bestie. Lowkey the ultimate cheat sheet 🧚

   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

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 is giving the same scenarios and scope as the other three key management schemes in MIKEY. It's a whole vibe 🌸

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

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

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

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

Okay bestie, DHHMAC SHALL use this payload to carry the HMAC result along with the authentication algorithm it's indicating 💅. When DHHMAC is in the mix, KEMAC SHALL not carry any encrypted data 🙈. So 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, no exceptions 🫶.

For DHHMAC, this key data transport payload SHALL be the last payload in the message 👑. Heads up: the Next payload field SHALL be set to Last payload. Then the HMAC gets calculated over the entire MIKEY message, excluding the MAC field, using auth_key as described in [2] section 5.2, and the result gets stored in 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, and it MUST be implemented as part of the DHHMAC. Its result is 160 bits long 🌈.

4.3. ID Payload (ID) 🪪

For DHHMAC, this payload SHALL only hold a non-certificate-based identity ✨. That's it, that's the tea 🍓.

4.4. General Extension Payload 🧩

For DHHMAC, this payload is how we dodge bidding-down attacks 🙅‍♀️. It 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

5. Security Considerations 🛡️

Okay, this part is serious but also iconic. This document handles key management security issues throughout 💖. For the full MIKEY security story, go check MIKEY [2] section 9 📚.

On top of that, this document covers security issues according to [7], and these security considerations apply to this document in particular 🦋:

5.1. Security Environment 🌸

The DHHMAC security protocol focuses mainly on communication security, meaning the security issues that come with the MIKEY DHHMAC protocol 💜. But there are some system security issues that DHHMAC doesn't explicitly define, and they should be provided locally in practice. Very important, don't skip these ✨.

The system running the DHHMAC protocol entity SHALL provide the ability to generate (pseudo) random numbers as input to the Diffie-Hellman operation (see [8]). The system SHALL also be able to store the generated (pseudo) random data, secret data, keys, and other secret security parameters securely 🔐. That means confidential and safe from unauthorized tampering, obviously 🙈.

5.2. Threat Model 🕵️‍♀️

The threat model here covers end-to-end security on the Internet in general 🌍. It doesn't rule out DHHMAC being deployed in a corporate, closed IP environment either 🏢. It also includes the possibility that MIKEY DHHMAC gets deployed on a hop-by-hop basis, with some intermediate trusted "MIKEY DHHMAC proxies" involved 🧚.

Since DHHMAC is a key management protocol, these are the security threats we're worried about 😭:

  • 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 does not explicitly transmit the TGK at all 🫣. Instead, it uses the Diffie-Hellman "encryption" operation, which hides the secret (pseudo) random values, so only partial information (the DH half-key) for building the TGK gets sent. It's fundamentally assumed that an eavesdropper having those DH half-keys doesn't cause any substantial security risk; see 5.4. Also, DHHMAC carries other data like timestamps, (pseudo) random values, identification information, or security policy parameters, and eavesdropping on any of that isn't 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 is about 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 with a distinct security level, are offered (such as those made possible by SDP [4]), avoiding bidding-down attacks is a real concern 👀. DHHMAC addresses this by reusing the MIKEY General Extension Payload mechanism, where all key management protocol identifiers are listed within the MIKEY General Extension Payload 👑.

Some potential threats are NOT in scope for 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 in the context of DHHMAC in this environment, so related countermeasures are not provided at all 🤷‍♀️.
  • Denial-of-service or distributed denial-of-service attacks: Some considerations are given on some of those attacks, but DHHMAC does not claim to provide full countermeasures against any of them 😩. For example, stressing the availability of the entities is not thwarted by the key management protocol, so some other local countermeasures should be applied. Also, some DoS attacks aren't countered, such as intercepting a valid DH request and duplicating it massively and instantly. Such attacks might at least be countered partially by some local means 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 can 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 a shorter roundtrip time. So MIKEY-DHHMAC doesn't provide identity protection on its own, but it may inherit that 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) give you the option not to supply identity information 🫥. This option only makes sense 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's understood that without identity information, the MIKEY key management security protocols might be subject to security weaknesses such as masquerade, impersonation, and reflection attacks, especially in end-to-end scenarios where no other secure means of assured identity information are provided. Yikes 💀.

Leaving identity fields optional (if doing so is possible) thus should not be seen as a privacy method, either. It's more of a protocol optimization feature 🎀.

5.3. Security Features and Properties

With those threats in mind, DHHMAC brings a bunch of security features to the table, and here's what you get out of them 🛡️💖

  • Secure key agreement ✨: Both peers end up with a TGK, and this is achieved using an authenticated Diffie-Hellman key management protocol. Bestie, this is the core of the whole thing 🔑
  • Peer-entity authentication (mutual) 🫶: This corroborates that the host/user is authentic, because they prove they have a pre-assigned secret key by using keyed HMAC. Authentication happens on both the request and the response message, so it's mutual, no cap 🤝

The HMAC computation covers authentication and message integrity of the exchanged Diffie-Hellman half-keys and the associated messages. This is absolutely necessary to avoid man-in-the-middle attacks on the messages in transit and, especially, on the Diffie-Hellman half-keys, since those aren't authenticated on their own 🙈

Note: This document does not address issues regarding authorization, so this feature is not provided explicitly. Still, DHHMAC authentication means it supports and facilitates realization of authorization means (local issue) 📝
  • Cryptographic integrity check 🔒: This is achieved using a message digest (keyed HMAC). It includes the exchanged Diffie-Hellman half-keys and covers the other parts of the message too. Mutual peer entity authentication and message integrity together are super effective countermeasures against man-in-the-middle attacks 🙅‍♀️

The initiator can run a local timer that fires if the awaited response message never shows up on time. This is meant to detect deletion of entire messages ⏰

  • Replay protection 🔁: This is achieved using embedded timestamps. To detect replayed messages, the clocks of the initiator and sender need to be roughly synchronized, so it's essential 🕰️ For more on clock synchronization and timestamp usage, check [2] section 5.4 and [2] section 9.3. If clock synchronization is lost, end systems can't detect replayed messages anymore, and they can't securely establish keying material either. This may result in a denial-of-service, so see [2] section 9.5 💀
  • Limited DoS protection 🛑: Rapid checking of the message digest lets you verify authenticity and integrity before launching CPU-intensive Diffie-Hellman operations or starting other resource-consuming tasks. This protects against some denial-of-service attacks, like malicious modification of messages and spam with (replayed or masqueraded) messages. DHHMAC probably does not explicitly counter sophisticated distributed, large-scale denial-of-service attacks that compromise system availability, for example 😤

Some DoS protection also comes from including the initiator's identity payload in the I_message. That lets the recipient filter out (replayed) I_messages that aren't targeted at them, so they don't waste time creating unnecessary MIKEY sessions 🧚

  • Perfect-forward secrecy (PFS) 🌸: Unlike the MIKEY pre-shared and public-key-based key distribution protocols, the Diffie-Hellman key agreement protocol has a security property called perfect forward secrecy. Even if the long-term pre-shared key gets compromised at some point, that doesn't compromise past or future session keys 🥹

Neither the MIKEY pre-shared nor the MIKEY public-key protocol variants can provide perfect-forward secrecy. So none of the other MIKEY protocols can substitute for the Diffie-Hellman PFS property 🙅‍♀️

Honestly, DHHMAC and digitally signed DH are way superior to the pre-shared or public-key-based key distribution protocols in this respect 👑

  • Fair, mutual key contribution ⚖️: The Diffie-Hellman key management protocol isn't a strict key distribution protocol, where the initiator hands a key out to its peers. Both parties in the exchange contribute equally to the common Diffie-Hellman TEK traffic generating key. This reduces the risk of either party cheating or accidentally generating a weak session key, which makes DHHMAC a fair key agreement protocol 🤝✨ You can also see it as an extra distributed security measure that boosts robustness compared to a setup where all the security depends on a single entity being implemented properly 💅

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. These xi or xr values SHALL be kept private. It is RECOMMENDED that these secret values be destroyed once the common Diffie-Hellman shared secret key has been established 🔐

  • Efficiency and performance 🚀: Like the MIKEY public-key protocol, the MIKEY DHHMAC key agreement protocol securely establishes a TGK within just one roundtrip. Other existing key management techniques, like IPsec-IKE [12], IPsec-IKEv2 [14], TLS [11], and other schemes, aren't considered adequate for those real-time and security requirements, because they all use more than a single roundtrip 🏎️ All the MIKEY key management protocols can complete their task of security policy parameter negotiation, including key agreement or key distribution, in one roundtrip. However, the MIKEY pre-shared and MIKEY public-key protocols can even complete their task in a half-roundtrip when the confirmation messages are omitted 🍓

Using HMAC together with a strong one-way hash function (such as SHA1) can be done more efficiently in software than expensive public-key operations. That gives DHHMAC a real performance edge over signed DH or the public-key encryption protocol 💜

If a very high security level is wanted for long-term secrecy of the negotiated Diffie-Hellman shared secret, longer hash values may be deployed, like what SHA256, SHA384, or SHA512 provide, possibly paired with stronger Diffie-Hellman groups. This is left 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 flip side, and under reasonable conditions, DHHMAC consumes more CPU cycles than the MIKEY pre-shared key distribution protocol. The same might quite likely hold for the MIKEY public-key distribution protocol, depending on the choice of private and public key lengths. So it's fair to say DHHMAC provides sound performance compared with the other MIKEY protocol variants 🙂

Using optional identity information (with the constraints stated in section 5.2) and optional Diffie-Hellman half-key fields gives you a way to boost 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. Those would otherwise be needed for the X.509 RSA public-key-based key distribution protocol or the digitally signed Diffie-Hellman key agreement protocol described in MIKEY. Public-key infrastructures may not always be available in certain environments, and they may not be adequate for real-time multimedia applications when extra steps for certificate validation and certificate revocation, with additional roundtrips, are taken into account 😩

DHHMAC doesn't depend on PKI, and implementations don't need PKI standards either. So it's believed to be much simpler than the more complex PKI facilities 🧸

DHHMAC is especially attractive in environments where provisioning of a pre-shared key has already been done 🎀

  • NAT-friendliness 🦋: DHHMAC can 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

Okay, so this document makes a couple of assumptions that DHHMAC's security really depends on 🥺 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. Basically, that means 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. Check out [6], [9], or [10] for more background on 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]) 🔐
  • 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 💅

Okay so, these detailed assumptions are kinda non-negligible, but security experts generally think they're all reasonable 🧠 and that they can be met in practice with little or no expense. Totally doable, bestie ✨

The math and crypto assumptions behind the PRF, Diffie-Hellman (the discrete log assumption), the HMAC algorithm, and the SHA1 algorithms have been neither proven nor disproven at this time 🤔

So a certain residual risk is still lingering 👀, and it might threaten the overall security at some unforeseeable time in the future. Not me getting nervous 🙈

DHHMAC would be compromised as soon as any of the listed assumptions stop holding 💀

Diffie-Hellman is a generic security technique, not only for groups of prime order or of characteristic two 🦋. That's because the fundamental mathematical assumption is that the discrete logarithm problem is also very hard in general groups. So Diffie-Hellman can be deployed for GF(p)*, for sub-groups of sufficient size, and for groups upon elliptic curves too. RSA doesn't generalize like this, since its core mathematical problem is a different one (large integer factorization) 🔢

RSA asymmetric keys tend to get increasingly lengthy (1536 bits and more), which makes them super computationally intensive 😩. Elliptic Curve Diffie-Hellman (ECDH) lets key lengths get cut down substantially (say 170 bits or more) while still maintaining at least the security level, and it gives even more significant performance benefits in practice ⚡. It's also believed that elliptic-curve techniques protect much better against side channel attacks, thanks to the inherent redundancy in the projective coordinates. For all these reasons, elliptic-curve-based Diffie-Hellman can be seen as more "future-proof" and robust against potential threats than RSA is 👑. Note that Elliptic Curve Diffie-Hellman variants of MIKEY are defined in [31].

HMAC-SHA1 is a key security mechanism within DHHMAC, and the overall security of MIKEY DHHMAC depends on it 🔐. 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 to protect the MIKEY payload. Likewise, the pseudo-random function PRF within MIKEY [2] uses the HMAC-SHA1 mechanism as a key derivation function 🗝️. Certain attacks have been reported against SHA1 and MD5 (see [29]), but 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 the one depicted in section 2. Any misapplication might lead to unknown, undefined properties 🚫.

Please don't go using DHHMAC for anything outside section 2, bestie. Misapplying it might lead to unknown, undefined properties, and nobody wants that 😭.

5.6. Authorization and Trust Model 🎀

Basically, similar remarks on authorization as those stated in [2] section 4.3.2 hold for DHHMAC too. However, as noted before, this key management protocol does not serve full groups 🤏.

You can view the pre-established shared secret as yielding some pre-established trust relationship between the initiator and the responder 🤝. This makes the trust model for DHHMAC way simpler than it would be for a generic group key management protocol with potential group entities that have no pre-defined trust relationship. Combined with the assumption of a shared key, the common group controller simplifies the communication setup of the entities 🧚.

You can also view the pre-established trust relationship through the pre-shared secret as some means of pre-granted, implied authorization ✨. This document doesn't define any particular authorization means, though. It leaves that 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, plus general feedback from the MSEC WG 🌸.

7. IANA Considerations 🌈

This document doesn't define its own new name spaces for DHHMAC, beyond the IANA name spaces that have already been assigned for MIKEY. See [2] sections 10 and 10.1, and the IANA MIKEY payload name spaces [37] 📋.

To line up 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.

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

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

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

Okay so this appendix is informative, which means it's a helpful overview and not a set of rules 💅. It shows how MIKEY-DHHMAC can be used in some H.323-based multimedia environments. MIKEY works for multimedia apps in general, IP telephony included 📞. [15] covers the different use cases for the MIKEY key management protocols (MIKEY-PS, MIKEY-PK, MIKEY-DHSIGN and MIKEY-DHHMAC). Their whole goal is setting up TGK keying material among H.323 endpoints. The TGKs then get used for media encryption by applying SRTP [20]. The scenarios include point-to-point calls with one or more intermediate gatekeepers in between, which can be trusted or partially trusted 🔐.

One particular use case is MIKEY-DHHMAC setting up a media connection from an endpoint B that's calling (through a gatekeeper) to another endpoint A that lives in that same gatekeeper zone 🦋. EP-A and EP-B usually don't share any auth_key ahead of time, so some separate protocol exchange gets done outside the actual call setup to establish an auth_key while the endpoints are registering with the gatekeeper. Those protocols exist [15] but aren't shown in this document 🙈. The auth_key between the endpoints is what authenticates and integrity protects the MIKEY-DHHMAC messages.

To set up a call, it's assumed that endpoint B already got permission from the gatekeeper (not shown). Endpoint B, as the caller, builds the MIKEY-DHHMAC I_message (see section 3) and sends it inside the H.323-SETUP to endpoint A. A routing gatekeeper (GK) forwards this message to endpoint A. If it's a non-routing gatekeeper, endpoint B sends the SETUP straight to endpoint A 🌸. Either way, H.323 inherent security mechanisms [21] protect the encapsulated message during transfer. That part isn't depicted here. The receiving endpoint A can verify the I_message it got and compute a TGK ✨. If endpoint A accepts the call, EP-A builds the MIKEY-DHHMAC R_message and sends the response back to the calling endpoint B, as part of the CallProceeding-to-Connect message (possibly through a routing gatekeeper). Endpoint B processes the R_message and ends up computing the same TGK as the called endpoint A 👑.

The message flow looks like this:

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 you need directional TGKs for full-duplex links in both directions, B->A and A->B, then the calling endpoint B runs the DHHMAC protocol twice 🔥. First in the B->A direction using I_fwd_message, then a second run in parallel in the A->B direction using I_rev_message. In that case, two MIKEY-DHHMAC I_messages get encapsulated within SETUP (I_fwd_message and I_rev_message), and two MIKEY-DHHMAC R_messages (R_fwd_message and R_rev_message) get encapsulated within CallProceeding-to-CONNECT. The I_rev_message corresponds with the I_fwd_message. Alternatively, the called endpoint A can run the DHHMAC protocol in a separate run with endpoint B (not shown). The catch is that this requires a third handshake to complete 🥹.

For more details on how the MIKEY protocols may be deployed with H.235, please check out [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

Copyright (C) The Internet Society (2006). 🧚

This document is subject to the rights, licenses and restrictions in BCP 78. Except as set out there, the authors keep all their rights 💜.

This document and the information in it are provided on an "AS IS" basis, and the disclaimer below is written in full capitals on purpose, so it stays exactly as the original has it:

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 doesn't take a position on whether any Intellectual Property Rights or other rights that someone might claim for the technology in this document are valid or in scope. It also doesn't say whether licenses for those rights are available. It hasn't made any independent effort to find those rights either. Info on how rights work for RFC documents lives in BCP 78 and BCP 79 📚.

Copies of IPR disclosures sent to the IETF Secretariat, plus any assurances of licenses that will be made available, can be found in the IETF on-line IPR repository at http://www.ietf.org/ipr. The same goes for the result of any attempt to get a general license or permission for implementers or users of this spec to use those proprietary rights 🫶.

The IETF invites anyone interested to tell it about any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 💖.

Acknowledgement 🌸

Funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA). 🎀✨

📦 where this page comes from