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.
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
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.
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.
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.
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
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
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)
DHHMAC SHALL apply this payload for conveying the HMAC result along