HMAC-Authenticated Diffie-Hellman for Multimedia Internet KEYing (MIKEY)
Extracted elements (31)
DH key agreement provides fair mutual key contribution: both parties contribute to TGK = g^(xi*xr), unlike MIKEY-PS and MIKEY-PK where the initiator alone generates the session key. This reduces risk from weak key generation by a single untrusted party.
DHHMAC targets the gap between MIKEY-PS (simple but no PFS, no mutual key contribution) and MIKEY-DHSIGN (PFS but requires PKI). It is a 'synergetic optimization' delivering PFS and mutual key contribution with only pre-shared key infrastructure, at the cost of not providing non-repudiation or identity protection.
DHHMAC uses HMAC (symmetric) instead of digital signatures (asymmetric) for DH half-key authentication to eliminate PKI dependency. This trades non-repudiation for lower implementation complexity, faster computation (HMAC-SHA1 is more efficient than RSA), and applicability where only pre-shared keys are provisioned.
Off-line pre-computation of the initial DH half-key (g^xi) is permitted to reduce real-time roundtrip delay and mitigate DoS risk, since the expensive DH exponentiation is decoupled from the latency-sensitive call setup phase.
DHHMAC does not define new payload formats; it reuses existing MIKEY payloads from RFC 3830 (HDR, KEMAC, DH data, Timestamp, ID, SP, RAND, Error, General Extension) with specific restrictions defined in section 4. Only next payload types from Table 4.1.b are permitted; other RFC 3830 next payload values SHALL NOT be applied.
MIKEY-DHHMAC integrates with SIP/SDP by encapsulating MIKEY messages in SDP containers within the SDP offer/answer handshake (RFC 4567), and with H.323 by transport in H.225.0 fast start call signaling (SETUP and CallProceeding-to-CONNECT messages). For full-duplex H.323, two parallel DHHMAC runs are encapsulated in a single SETUP.
MIKEY-DHHMAC is applicable only for peer-to-peer configurations (maximum two entities). Like MIKEY-DHSIGN, it cannot scale to group key management for groups larger than two due to the pairwise nature of DH and the one-roundtrip constraint. In GKMARCH it can function only as a registration protocol.
Each party SHALL generate xi or xr using a strong, unpredictable PRNG and SHALL keep these values private. It is RECOMMENDED that the secret DH exponent values be destroyed once the common TGK has been established.
For DHHMAC, the ID payload SHALL hold only a non-certificate-based identity, excluding PKI/X.509 certificate-based identities.
For TGK re-keying with fresh keys, the initiator SHALL provide a new, fresh DHi and the responder SHALL respond with a new, fresh DHr plus the received DHi. For non-key information updates, [DHi] and [DHr, DHi] SHALL be left out.
HMAC-SHA-1 MUST be implemented as the mandatory default MAC algorithm (value 0); its result is 160 bits. The KEMAC payload SHALL be the last payload in any DHHMAC message (Next payload field SHALL be set to Last payload). The AES key wrap method SHALL NOT be applied.
In case of a decoding error or failed HMAC authentication verification, the responder SHALL apply the Error payload data type. Other defined next payload values from RFC 3830 SHALL NOT be applied to DHHMAC.
TGK processing SHALL be accomplished as described in MIKEY (RFC 3830) section 4. Off-line pre-computation of the initial DH half-key MAY be performed to reduce roundtrip delay and DoS risk.
The computed HMAC result SHALL be conveyed in the KEMAC payload MAC field. The HMAC SHALL be computed over the entire MIKEY message excluding the MAC field, using auth_key derived from the pre-shared secret s via the MIKEY PRF.
The DHHMAC key exchange SHALL be performed per Figure 1: initiator sends I_message with g^(xi) and HMAC, responder replies with R_message containing g^(xr) and HMAC. Both parties then independently compute TGK = g^(xi*xr).
The General Extension Payload for DHHMAC SHALL list all key management protocol identifiers of the surrounding encapsulation protocol (e.g., SDP) to prevent bidding-down attacks, and SHALL be integrity protected with the HMAC using the shared secret.
The initiator SHALL always include the recipient's identity IDr in I_message. IDi SHOULD be included but MAY be omitted if the receiver can identify the initiator by other means.
The responder SHALL always include the initiator's identity IDi in R_message regardless of whether IDi was present in I_message. IDr SHOULD be included but MAY be omitted if the initiator can identify the responder by other means.
The system running DHHMAC SHALL provide the capability to generate (pseudo) random numbers for DH operations and SHALL be capable of storing secret data, keys, and security parameters securely against unauthorized access and tampering.
MIKEY-DHHMAC is a fourth MIKEY key management variant (data types 7 and 8) combining Diffie-Hellman key agreement with HMAC authentication over a pre-shared key. It establishes a TEK Generation Key (TGK = g^(xi*xr)) within one roundtrip for peer-to-peer multimedia sessions without requiring a PKI.
The HDR (Common Header Payload) for DHHMAC uses data type 7 for initiator messages (DHHMAC init) and data type 8 for responder messages (DHHMAC resp). A responder identifies MIKEY-DHHMAC by evaluating the data type field as 7 or 8. Allowed next payload values are: Last (0), KEMAC (1), DH (3), T (5), ID (6), SP (10), RAND (11), ERR (12), General Ext. (21).
IANA is requested to add two entries to the MIKEY Payload Name Space: 'DHHMAC init' with value 7 and 'DHHMAC resp' with value 8, both referencing RFC 4650. No new IANA name spaces are defined beyond these additions to RFC 3830's registries.
Bidding-down attacks when multiple key management protocols are offered via SDP are addressed by listing all KMP identifiers within the HMAC-protected General Extension Payload. Omitting this protection could allow an attacker to force negotiation of a weaker protocol.
DHHMAC provides perfect forward secrecy (PFS) via Diffie-Hellman key agreement: even if the long-term pre-shared key s is compromised at some point, past and future TGKs are not exposed. Neither MIKEY-PS nor MIKEY-PK can provide PFS.
HMAC authentication of the exchanged Diffie-Hellman half-keys is essential to prevent man-in-the-middle attacks. Without HMAC, an attacker could substitute its own DH half-keys and establish separate sessions with each endpoint, compromising the TGK. Rapid HMAC checking before DH operations also provides limited DoS protection against message spam.
MIKEY-DHHMAC does not provide identity protection; identities are transmitted in cleartext. This is an explicit design trade-off: no known protocol can achieve PFS, one-roundtrip completion, and no-PKI while also providing identity protection. Identity protection may be inherited from a security layer below MIKEY.
Non-repudiation is explicitly not provided by DHHMAC, as it is not a requirement in the target environment. Authorization is also not explicitly provided by the protocol but is facilitated locally by the fact that possession of the pre-shared key implies a pre-established trust relationship.
Replay protection is achieved via embedded timestamps requiring loosely synchronized clocks. If clock synchronization is lost, replayed messages cannot be detected, secure key establishment fails, and a denial-of-service results. Operators should consult RFC 3830 sections 5.4 and 9.3 for guidance.
Residual cryptographic risk remains: DHHMAC security depends on the DH discrete logarithm assumption, SHA1 collision resistance, and HMAC security, none of which have been mathematically proven. SHA1 collision attacks have been reported (RFC 4270), though no attacks against HMAC-SHA1 were known at publication. Elliptic Curve DH variants (RFC referenced as work in progress) offer better future-proofing.
The initiator message (I_message) carries: HDR (data type 7), T (timestamp), RAND, [IDi], IDr, {SP}, DHi (g^xi public DH half-key), KEMAC (HMAC result). The responder message (R_message) carries: HDR (data type 8), T, [IDr], IDi, DHr (g^xr), DHi (echoed back), KEMAC.
The KEMAC payload in DHHMAC context carries: MAC alg = 0 (HMAC-SHA-1, mandatory), Encr alg = 2 (NULL), Encr data len = 0, empty Encr data field, and a 160-bit HMAC-SHA-1 MAC field. No encrypted key data is carried; KEMAC is used solely to convey the HMAC result.