draft-ietf-msec-mikey-dhhmac-11.txt   rfc4650.txt 
Internet Engineering Task Force - MSEC WG Network Working Group M. Euchner
Internet Draft M. Euchner Request for Comments: 4650 September 2006
Intended Category: Proposed Standard Category: Standards Track
HMAC-authenticated Diffie-Hellman for MIKEY
<draft-ietf-msec-mikey-dhhmac-11.txt>
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering HMAC-Authenticated Diffie-Hellman
Task Force (IETF), its areas, and its working groups. Note that for Multimedia Internet KEYing (MIKEY)
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six Status of This Memo
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at This document specifies an Internet standards track protocol for the
http://www.ietf.org/1id-abstracts.html 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.
The list of Internet-Draft Shadow Directories can be accessed at Copyright Notice
http://www.ietf.org/shadow.html
Comments should be sent to the MSEC WG mailing list at Copyright (C) The Internet Society (2006).
msec@securemulticast.org and to the author.
Abstract Abstract
This document describes a light-weight point-to-point key management This document describes a lightweight point-to-point key management
protocol variant for the multimedia Internet keying (MIKEY) protocol protocol variant for the multimedia Internet keying (MIKEY) protocol
MIKEY, as defined in RFC 3830. In particular, this variant deploys MIKEY, as defined in RFC 3830. In particular, this variant deploys
the classic Diffie-Hellman key agreement protocol for key the classic Diffie-Hellman key agreement protocol for key
establishment featuring perfect forward secrecy in conjunction with establishment featuring perfect forward secrecy in conjunction with a
a keyed hash message authentication code for achieving mutual keyed hash message authentication code for achieving mutual
authentication and message integrity of the key management messages authentication and message integrity of the key management messages
exchanged. This protocol addresses the security and performance exchanged. This protocol addresses the security and performance
constraints of multimedia key management in MIKEY. constraints of multimedia key management in MIKEY.
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 [2].
Table of Contents Table of Contents
1. Introduction................................................3 1. Introduction ....................................................2
1.1. Definitions...............................................6 1.1. Definitions ................................................5
1.2. Abbreviations.............................................7 1.2. Abbreviations ..............................................6
2. Scenario....................................................8 1.3. Conventions Used in This Document ..........................7
2.1. Applicability.............................................9 2. Scenario ........................................................7
2.2. Relation to GKMARCH.......................................9 2.1. Applicability ..............................................7
3. DHHMAC Security Protocol...................................10 2.2. Relation to GKMARCH ........................................8
3.1. TGK re-keying............................................12 3. DHHMAC Security Protocol ........................................8
4. DHHMAC payload formats.....................................13 3.1. TGK Re-keying .............................................10
4.1. Common header payload (HDR)..............................13 4. DHHMAC Payload Formats .........................................10
4.2. Key data transport payload (KEMAC).......................14 4.1. Common Header Payload (HDR) ..............................11
4.3. ID payload (ID)..........................................15 4.2. Key Data Transport Payload (KEMAC) ........................12
4.4. General Extension Payload................................15 4.3. ID Payload (ID) ...........................................12
5. Security Considerations....................................16 4.4. General Extension Payload .................................12
5.1. Security environment.....................................16 5. Security Considerations ........................................13
5.2. Threat model.............................................16 5.1. Security Environment ......................................13
5.3. Security features and properties.........................19 5.2. Threat Model ..............................................13
5.4. Assumptions..............................................23 5.3. Security Features and Properties ..........................15
5.5. Residual risk............................................24 5.4. Assumptions ...............................................19
5.6. Authorization and Trust Model............................26 5.5. Residual Risk .............................................20
6. Acknowledgments............................................26 5.6. Authorization and Trust Model .............................21
7. IANA considerations........................................26 6. Acknowledgments ................................................21
8. References.................................................27 7. IANA Considerations ............................................22
8.1 Normative References.......................................27 8. References .....................................................22
8.2 Informative References...................................27 8.1. Normative References ......................................22
Appendix A Usage of MIKEY-DHHMAC in H.235......................30 8.2. Informative References ....................................22
Full Copyright Statement........................................33 Appendix A. Usage of MIKEY-DHHMAC in H.235 ........................25
Expiration Date.................................................34
Revision History................................................34
Author's Addresses..............................................37
1. 1. Introduction
Introduction
There is work done in IETF to develop key management schemes. For There is work done in IETF to develop key management schemes. For
example, IKE [14] is a widely accepted unicast scheme for IPsec, and example, IKE [12] is a widely accepted unicast scheme for IPsec, and
the MSEC WG is developing other schemes, addressed to group the MSEC WG is developing other schemes, addressed to group
communication [24], [25]. For reasons discussed below, there is communication [17], [18]. For reasons discussed below, there is,
however a need for a scheme with low latency, suitable for demanding however, a need for a scheme with low latency, suitable for demanding
cases such as real-time data over heterogeneous networks, and small cases such as real-time data over heterogeneous networks and small
interactive groups. interactive groups.
As pointed out in MIKEY (see [3]), secure real-time multimedia As pointed out in MIKEY (see [2]), secure real-time multimedia
applications demand a particular adequate light-weight key management applications demand a particular adequate lightweight key management
scheme that cares for how to securely and efficiently establish scheme that takes care to establish dynamic session keys securely and
dynamic session keys in a conversational multimedia scenario. efficiently in a conversational multimedia scenario.
In general, MIKEY scenarios cover peer-to-peer, simple-one-to-many In general, MIKEY scenarios cover peer-to-peer, simple one-to-many,
and small-sized groups. MIKEY in particular, describes three key and small-sized groups. MIKEY in particular describes three key
management schemes for the peer-to-peer case that all finish their management schemes for the peer-to-peer case that all finish their
task within one round trip: task within one round trip:
- a symmetric key distribution protocol (MIKEY-PS) based upon
pre-shared master keys;
- a public-key encryption-based key distribution protocol - a symmetric key distribution protocol (MIKEY-PS) based on pre-
(MIKEY-PK) assuming a public-key infrastructure with RSA-based shared master keys
(Rivest, Shamir and Adleman) private/public keys and digital
certificates;
- and a Diffie-Hellman key agreement protocol (MIKEY-DHSIGN) - a public-key encryption-based key distribution protocol (MIKEY-PK
deploying digital signatures and certificates. 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
All these three key management protocols are designed such that they - 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 round trip. This requires complete their work within just one round trip. This requires
depending on loosely synchronized clocks and deploying timestamps depending on loosely synchronized clocks and deploying timestamps
within the key management protocols. within the key management protocols.
However, it is known [7] that each of the three key management However, it is known [6] that each of the three key management
schemes has its subtle constraints and limitations: schemes has its subtle constraints and limitations:
- The symmetric key distribution protocol (MIKEY-PS) is simple - The symmetric key distribution protocol (MIKEY-PS) is simple to
to implement, however, was not intended to scale to support implement; however, it was not intended to scale to support any
any configurations beyond peer-to-peer, simple one-to-many, configurations beyond peer-to-peer, simple one-to-many, and
and small-size (interactive) groups, due to the need of small-size (interactive) groups, due to the need for mutually
mutually pre-assigned shared master secrets. pre-assigned shared master secrets.
Moreover, the security provided does not achieve the property Moreover, the security provided does not achieve the property of
of perfect forward secrecy; i.e. compromise of the shared perfect forward secrecy; i.e., compromise of the shared master
master secret would render past and even future session keys secret would render past and even future session keys susceptible
susceptible to compromise. to compromise.
Further, the generation of the session key happens just at the Further, the generation of the session key happens just at the
initiator. Thus, the responder has to fully trust the initiator. Thus, the responder has to fully trust the initiator
initiator on choosing a good and secure session secret; the to choose a good and secure session secret; the responder is able
responder neither is able to participate in the key generation neither to participate in the key generation nor to influence that
nor to influence that process. This is considered as a process. This is considered a specific limitation in less trusted
specific limitation in less trusted environments. environments.
- The public-key encryption scheme (MIKEY-PK) depends upon a - The public-key encryption scheme (MIKEY-PK and MIKEY-RSA-R [33])
public-key infrastructure that certifies the private-public depends upon a public-key infrastructure that certifies the
keys by issuing and maintaining digital certificates. While private-public keys by issuing and maintaining digital
such a key management scheme provides full scalability in certificates. While such key management schemes provide full
large networked configurations, public-key infrastructures are scalability in large networked configurations, public-key
still not widely available and in general, implementations are infrastructures are still not widely available, and, in general,
significantly more complex. implementations are significantly more complex.
Further, additional round trips and computational processing Further, additional roundtrips and computational processing might
might be necessary for each end system in order to ascertain be necessary for each end system in order to ascertain
verification of the digital certificates. For example, verification of the digital certificates. For example, typical
typical operations in the context of a public-key operations in the context of a public-key infrastructure may
infrastructure such as validating digital certificates (RFC involve extra network communication handshakes with the public-key
3029, [31]), ascertaining the revocation status of digital infrastructure and with certification authorities and may
certificates (RFC 2560, [30]) and asserting certificate typically involve additional processing steps in the end systems.
policies, construction of certification path(s) ([33]), These operations would include validating digital certificates
requesting and obtaining necessary certificates (RFC 2511, (RFC 3029, [24]), ascertaining the revocation status of digital
[32]) and management of certificates for such purposes ([29]) certificates (RFC 2560, [23]), asserting certificate policies,
may involve extra network communication handshakes with the construction of certification path(s) ([26]), requesting and
public-key infrastructure and with certification authorities obtaining necessary certificates (RFC 2511, [25]), and management
and may typically involve additional processing steps in the of certificates for such purposes ([22]). Such steps and tasks
end systems. Such steps and tasks all result in further delay all result in further delay of the key agreement or key
of the key agreement or key establishment phase among the end establishment phase among the end systems, which negatively
systems, negatively impacting setup time. Any extra PKI affects setup time. Any extra PKI handshakes and processing are
handshakes and processing are not in scope of MIKEY and since not in the scope of MIKEY, and since this document only deploys
this document deploys symmetric security mechanisms only, symmetric security mechanisms, aspects of PKI, digital
aspects of PKI, digital certificates and related processing certificates, and related processing are not further covered in
are not further covered in this document. this document.
Finally, as in the symmetric case, the responder depends Finally, as in the symmetric case, the responder depends
completely upon the initiator choosing good and secure session completely upon the initiator's choosing good and secure session
keys. keys.
- The third MIKEY-DHSIGN key management protocol deploys the - The third MIKEY-DHSIGN key management protocol deploys the
Diffie-Hellman key agreement scheme and authenticates the Diffie-Hellman key agreement scheme and authenticates the exchange
exchange of the Diffie-Hellman half-keys in each direction by of the Diffie-Hellman half-keys in each direction by using a
using a digital signature. This approach has the same digital signature. This approach has the same advantages and
advantages and deficiencies as described in the previous deficiencies as described in the previous section in terms of a
section in terms of a public-key infrastructure. public-key infrastructure.
However, the Diffie-Hellman key agreement protocol is known However, the Diffie-Hellman key agreement protocol is known for
for its subtle security strengths in that it is able to its subtle security strengths in that it is able to provide full
provide full perfect forward secrecy (PFS) and further have perfect forward secrecy (PFS) and further have to both parties
both parties actively involved in session key generation. actively involved in session key generation. This special
This special security property - despite the somewhat higher security property (despite the somewhat higher computational
computational costs - makes Diffie-Hellman techniques costs) makes Diffie-Hellman techniques attractive in practice.
attractive in practice.
In order to overcome some of the limitations as outlined above, a In order to overcome some of the limitations as outlined above, a
special need has been recognized for another efficient key agreement special need has been recognized for another efficient key agreement
protocol variant in MIKEY. This protocol variant aims to provide the protocol variant in MIKEY. This protocol variant aims to provide the
capability of perfect forward secrecy as part of a key agreement with capability of perfect forward secrecy as part of a key agreement with
low latency without dependency on a public-key infrastructure. low latency without dependency on a public-key infrastructure.
This document describes such a fourth light-weight key management This document describes a fourth lightweight key management scheme
scheme for MIKEY that could somehow be seen as a synergetic for MIKEY that could somehow be seen as a synergetic optimization
optimization between the pre-shared key distribution scheme and the between the pre-shared key distribution scheme and the Diffie-Hellman
Diffie-Hellman key agreement. key agreement.
The idea of the protocol in this document is to apply the Diffie- The idea of the protocol in this document is to apply the Diffie-
Hellman key agreement, but rather than deploying a digital signature Hellman key agreement, but rather than deploy a digital signature for
for authenticity of the exchanged keying material, instead uses a authenticity of the exchanged keying material, it instead uses a
keyed-hash upon using symmetrically pre-assigned shared secrets. keyed-hash for symmetrically pre-assigned shared secrets. This
This combination of security mechanisms is called the HMAC- combination of security mechanisms is called the HMAC-authenticated
authenticated Diffie-Hellman (DH) key agreement for MIKEY (DHHMAC). Diffie-Hellman (DH) key agreement for MIKEY (DHHMAC).
The DHHMAC variant closely follows the design and philosophy of MIKEY The DHHMAC variant closely follows the design and philosophy of MIKEY
and reuses MIKEY protocol payload components and MIKEY mechanisms to and reuses MIKEY protocol payload components and MIKEY mechanisms to
its maximum benefit and for best compatibility. its maximum benefit and for best compatibility.
Like the MIKEY Diffie-Hellman protocol, DHHMAC does not scale beyond Like the MIKEY Diffie-Hellman protocol, DHHMAC does not scale beyond
a point-to-point constellation; thus, both MIKEY Diffie-Hellman a point-to-point constellation; thus, both MIKEY Diffie-Hellman
protocols do not support group-based keying for any group size larger protocols do not support group-based keying for any group size larger
than two entities. than two entities.
1.1. Definitions 1.1. Definitions
The definitions and notations in this document are aligned with The definitions and notations in this document are aligned with
MIKEY, see [3], sections 1.3 - 1.4. MIKEY; see [2] sections 1.3 - 1.4.
All large integer computations in this document should be understood 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 as being mod p within some fixed group G for some large prime p; see
[3] section 3.3; however, the DHHMAC protocol is applicable in [2] section 3.3. However, the DHHMAC protocol is also applicable
general to other appropriate finite, cyclical groups as well. generally to other appropriate finite, cyclical groups as well.
It is assumed that a pre-shared key s is known by both entities It is assumed that a pre-shared key s is known by both entities
(initiator and responder). The authentication key auth_key is (initiator and responder). The authentication key auth_key is
derived from the pre-shared secret s using the pseudo-random function derived from the pre-shared secret s using the pseudo-random function
PRF; see [3] sections 4.1.3 and 4.1.5. PRF; see [2] sections 4.1.3 and 4.1.5.
In this text, [X] represents an optional piece of information. In this text, [X] represents an optional piece of information.
Generally throughout the text, X SHOULD be present unless certain Generally throughout the text, X SHOULD be present unless certain
circumstance MAY allow X being optional and not be present thereby circumstances MAY allow X to be optional and not to be present,
resulting in weaker security potentially. Likewise [X, Y] represents thereby potentially resulting in weaker security. Likewise, [X, Y]
an optional compound piece of information where the pieces X and Y represents an optional compound piece of information where the pieces
SHOULD be either both present or MAY optionally be both absent. {X} X and Y either SHOULD both be present or MAY optionally both be
denotes zero or more occurrences of X. absent. {X} denotes zero or more occurrences of X.
1.2. Abbreviations 1.2. Abbreviations
auth_key pre-shared authentication key, PRF-derived from auth_key Pre-shared authentication key, PRF-derived from
pre-shared key s. pre-shared key s.
DH Diffie-Hellman DH Diffie-Hellman
DHi public Diffie-Hellman half key g^(xi) of the DHi Public Diffie-Hellman half key g^(xi) of the
Initiator Initiator
DHr public Diffie-Hellman half key g^(xr) of the DHr Public Diffie-Hellman half key g^(xr) of the
Responder Responder
DHHMAC HMAC-authenticated Diffie-Hellman DHHMAC HMAC-authenticated Diffie-Hellman
DoS Denial-of-service DoS Denial-of-service
G Diffie-Hellman group G Diffie-Hellman group
HDR MIKEY common header payload HDR MIKEY common header payload
HMAC keyed Hash Message Authentication Code HMAC Keyed Hash Message Authentication Code
HMAC-SHA1 HMAC using SHA1 as hash function (160-bit result) HMAC-SHA1 HMAC using SHA1 as hash function (160-bit result)
IDi Identity of initiator IDi Identity of initiator
IDr Identity of receiver IDr Identity of receiver
IKE Internet Key Exchange IKE Internet Key Exchange
IPsec Internet Protocol Security IPsec Internet Protocol Security
MIKEY Multimedia Internet KEYing MIKEY Multimedia Internet KEYing
MIKEY-DHHMAC MIKEY Diffie-Hellman key management protocol using MIKEY-DHHMAC MIKEY Diffie-Hellman key management protocol using
HMAC HMAC
MIKEY-DHSIGN MIKEY Diffie-Hellman key agreement protocol MIKEY-DHSIGN MIKEY Diffie-Hellman key agreement protocol
MIKEY-PK MIKEY public-key encryption-based key distribution MIKEY-PK MIKEY public-key encryption-based key distribution
protocol protocol
MIKEY-PS MIKEY pre-shared key distribution protocol MIKEY-PS MIKEY pre-shared key distribution protocol
p Diffie-Hellman prime modulus p Diffie-Hellman prime modulus
PKI Public-key Infrastructure PKI Public-key Infrastructure
PRF MIKEY pseudo-random function (see [3] section PRF MIKEY pseudo-random function (see [2] section
4.1.3.) 4.1.3)
RSA Rivest, Shamir and Adleman RSA Rivest, Shamir, and Adleman
s pre-shared key s Pre-shared key
SDP Session Description Protocol SDP Session Description Protocol
SOI Son-of-IKE, IKEv2 SOI Son-of-IKE, IKEv2
SP MIKEY Security Policy (Parameter) Payload SP MIKEY Security Policy (Parameter) Payload
T timestamp T Timestamp
TEK Traffic Encryption Key TEK Traffic Encryption Key
TGK MIKEY TEK Generation Key as the common Diffie- TGK MIKEY TEK Generation Key, as the common Diffie-
Hellman shared secret Hellman shared secret
TLS Transport Layer Security TLS Transport Layer Security
xi secret, (pseudo) random Diffie-Hellman key of the xi Secret, (pseudo) random Diffie-Hellman key of the
Initiator Initiator
xr secret, (pseudo) random Diffie-Hellman key of the xr Secret, (pseudo) random Diffie-Hellman key of the
Responder Responder
2. 1.3. Conventions Used in This Document
Scenario
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) The HMAC-authenticated Diffie-Hellman key agreement protocol (DHHMAC)
for MIKEY addresses the same scenarios and scope as the other three for MIKEY addresses the same scenarios and scope as the other three
key management schemes in MIKEY address. key management schemes in MIKEY address.
DHHMAC is applicable in a peer-to-peer group where no access to a DHHMAC is applicable in a peer-to-peer group where no access to a
public-key infrastructure can be assumed available. Rather, pre- public-key infrastructure can be assumed to be available. Rather,
shared master secrets are assumed available among the entities in pre- shared master secrets are assumed to be available among the
such an environment. entities in such an environment.
In a pair-wise group, it is assumed that each client will be setting 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- up a session key for its outgoing links with its peer using the DH-
MAC key agreement protocol. MAC key agreement protocol.
As is the case for the other three MIKEY key management protocols, As is the case for the other three MIKEY key management protocols,
DHHMAC assumes, at least, loosely synchronized clocks among the DHHMAC assumes, at least, loosely synchronized clocks among the
entities in the small group. entities in the small group.
To synchronize the clocks in a secure manner, some operational or To synchronize the clocks in a secure manner, some operational or
procedural means are recommended. MIKEY-DHHMAC does not define any procedural means are recommended. MIKEY-DHHMAC does not define any
secure time synchronization measures, however, sections 5.4 and 9.3 secure time synchronization measures; however, sections 5.4 and 9.3
of [3] provide implementation guidance on clock synchronization and of [2] provide implementation guidance on clock synchronization and
timestamps. timestamps.
2.1. Applicability 2.1. Applicability
MIKEY-DHHMAC, as well as the other MIKEY key management protocols, is MIKEY-DHHMAC and the other MIKEY key management protocols are
intended for application-level key management and is optimized for intended for application-level key management and are optimized for
multimedia applications with real-time session setup and session multimedia applications with real-time session setup and session
management constraints. management constraints.
As the MIKEY-DHHMAC key management protocol terminates in one As the MIKEY-DHHMAC key management protocol terminates in one
roundtrip, DHHMAC is applicable for integration into two-way roundtrip, DHHMAC is applicable for integration into two-way
handshake session- or call signaling protocols such as handshake session or call signaling protocols such as
a) SIP/SDP where the encoded MIKEY messages are encapsulated and a) SIP [13] and SDP, where the encoded MIKEY messages are
transported in SDP containers of the SDP offer/answer [RFC 3264] encapsulated and transported in SDP containers of the SDP
handshake as described in [5], offer/answer see RFC 3264 [27]) handshake, as described in [4];
b) H.323 (see [22]) where the encoded MIKEY messages are transported 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 in the H.225.0 fast start call signaling handshake. Appendix A
outlines the usage of MIKEY-DHHMAC within H.235. outlines the usage of MIKEY-DHHMAC within H.235.
MIKEY-DHHMAC is offered as option to the other MIKEY key management MIKEY-DHHMAC is offered as an option to the other MIKEY key
variants (MIKEY-pre-shared, MIKEY-public-key and MIKEY-DH-SIGN) for management variants (MIKEY-pre-shared, MIKEY-public-key and MIKEY-
all those cases where DHHMAC has its particular strengths (see DH-SIGN) for all those cases where DHHMAC has its particular
section 5). strengths (see section 5).
2.2. Relation to GKMARCH 2.2. Relation to GKMARCH
The Group key management architecture (GKMARCH) [26] describes a The Group key management architecture (GKMARCH) [19] describes a
generic architecture for multicast security group key management generic architecture for multicast security group key management
protocols. In the context of this architecture, MIKEY-DHHMAC may protocols. In the context of this architecture, MIKEY-DHHMAC may
operate as a registration protocol, see also [3] section 2.4. The operate as a registration protocol; see also [2] section 2.4. The
main entities involved in the architecture are a group main entities involved in the architecture are a group controller/key
controller/key server (GCKS), the receiver(s), and the sender(s). server (GCKS), the receiver(s), and the sender(s). Due to the pair-
Due to the pair-wise nature of the Diffie-Hellman operation and wise nature of the Diffie-Hellman operation and the 1-roundtrip
the 1-roundtrip constraint, usage of MIKEY-DHHMAC rules out any constraint, usage of MIKEY-DHHMAC rules out any deployment as a group
deployment as a group key management protocol with more than two key management protocol with more than two group entities. Only the
group entities. Only the degenerate case with two peers is degenerate case with two peers is possible where, for example, the
possible where for example the responder acts as the group responder acts as the group controller.
controller.
Note that MIKEY does not provide re-keying in the GKMARCH sense, Note that MIKEY does not provide re-keying in the GKMARCH sense, only
only updating of the keys by normal unicast messages. updating of the keys by normal unicast messages.
3. 3. DHHMAC Security Protocol
DHHMAC Security Protocol
The following figure defines the security protocol for DHHMAC: The following figure defines the security protocol for DHHMAC:
Initiator Responder Initiator Responder
I_message = HDR, T, RAND, [IDi], IDr, I_message = HDR, T, RAND, [IDi], IDr,
{SP}, DHi, KEMAC {SP}, DHi, KEMAC
-----------------------> R_message = HDR, T, -----------------------> R_message = HDR, T,
[IDr], IDi, DHr, [IDr], IDi, DHr,
DHi, KEMAC DHi, KEMAC
<---------------------- <----------------------
Figure 1: HMAC-authenticated Diffie-Hellman key based exchange, Figure 1: HMAC-authenticated Diffie-Hellman key-based exchange,
where xi and xr are (pseudo) randomly chosen respectively where xi and xr are (pseudo) randomly chosen, respectively,
by the initiator and the responder. by the initiator and the responder.
The DHHMAC key exchange SHALL be done according to Figure 1. The The DHHMAC key exchange SHALL be done according to Figure 1. The
initiator chooses a (pseudo) random value xi, and sends an HMACed initiator chooses a (pseudo) random value, xi, and sends an HMACed
message including g^(xi) and a timestamp to the responder. It is message including g^(xi) and a timestamp to the responder. It is
recommended that the initiator SHOULD always include the identity recommended that the initiator SHOULD always include the identity
payloads IDi and IDr within the I_message; unless the receiver can payloads IDi and IDr within the I_message; unless the receiver can
defer the initiator's identity by some other means, then IDi MAY defer the initiator's identity by some other means, IDi MAY
optionally be omitted. The initiator SHALL always include the optionally be omitted. The initiator SHALL always include the
recipient's identity. recipient's identity.
The group parameters (e.g., the group G) are a set of parameters The group parameters (e.g., the group G) are a set of parameters
chosen by the initiator. Note, that like in the MIKEY protocol, chosen by the initiator. Note that like in the MIKEY protocol, both
both sender and receiver explicitly transmit the Diffie-Hellman sender and receiver explicitly transmit the Diffie-Hellman group G
group G within the Diffie-Hellman payload DHi or DHr through an within the Diffie-Hellman payload DHi or DHr through an encoding
encoding (e.g., OAKLEY group numbering, see [3] section 6.4); the (e.g., OAKLEY group numbering; see [2] section 6.4). The actual
actual group parameters g and p however are not explicitly group parameters g and p, however, are not explicitly transmitted but
transmitted but can be deduced from the Diffie-Hellman group G. can be deduced from the Diffie-Hellman group G. The responder
The responder chooses a (pseudo) random positive integer xr, and chooses a (pseudo) random positive integer, xr, and sends an HMACed
sends an HMACed message including g^(xr) and the timestamp to the message including g^(xr) and the timestamp to the initiator. The
initiator. The responder SHALL always include the initiator's responder SHALL always include the initiator's identity IDi
identity IDi regardless of whether the I_message conveyed any IDi. regardless of whether the I_message conveyed any IDi. It is
It is RECOMMENDED that the responder SHOULD always include the RECOMMENDED that the responder SHOULD always include the identity
identity payload IDr within the R_message; unless the initiator payload IDr within the R_message; unless the initiator can defer the
can defer the responder's identity by some other means, then IDr responder's identity by some other means, IDr MAY optionally be left
MAY optionally be left out. out.
Both parties then calculate the TGK as g^(xi * xr). Both parties then calculate the TGK as g^(xi * xr).
The HMAC authentication provides authentication of the DH half- The HMAC authentication provides authentication of the DH half-keys
keys, and is necessary to avoid man-in-the-middle attacks. and is necessary to avoid man-in-the-middle attacks.
This approach is less expensive than digitally signed Diffie- This approach is less expensive than digitally signed Diffie-Hellman
Hellman in that both sides compute first one exponentiation and in that both sides compute one exponentiation and one HMAC first,
one HMAC, then one HMAC verification and finally another Diffie- then one HMAC verification, and finally another Diffie-Hellman
Hellman exponentiation. exponentiation.
With off-line pre-computation, the initial Diffie-Hellman half-key With off-line pre-computation, the initial Diffie-Hellman half-key
MAY be computed before the key management transaction and thereby MAY be computed before the key management transaction and thereby MAY
MAY further reduce the overall round trip delay as well as reduce further reduce the overall roundtrip delay, as well as the risk of
the risk of denial-of-service attacks. denial-of-service attacks.
Processing of the TGK SHALL be accomplished as described in MIKEY Processing of the TGK SHALL be accomplished as described in MIKEY [2]
[3] chapter 4. section 4.
The computed HMAC result SHALL be conveyed in the KEMAC payload The computed HMAC result SHALL be conveyed in the KEMAC payload field
field where the MAC fields holds the HMAC result. The HMAC SHALL where the MAC fields holds the HMAC result. The HMAC SHALL be
be computed over the entire message excluding the MAC field using computed over the entire message, excluding the MAC field using
auth_key, see also section 4.2. auth_key; see also section 4.2.
3.1. TGK re-keying 3.1. TGK Re-keying
TGK re-keying for DHHMAC generally proceeds as described in [3] TGK re-keying for DHHMAC generally proceeds as described in [2]
section 4.5. Specifically, figure 2 provides the message exchange section 4.5. Specifically, Figure 2 provides the message exchange
for the DHHMAC update message. for the DHHMAC update message.
Initiator Responder Initiator Responder
I_message = HDR, T, [IDi], IDr, I_message = HDR, T, [IDi], IDr,
{SP}, [DHi], KEMAC {SP}, [DHi], KEMAC
-----------------------> R_message = HDR, T, -----------------------> R_message = HDR, T,
[IDr], IDi, [IDr], IDi,
[DHr, DHi], KEMAC [DHr, DHi], KEMAC
<---------------------- <----------------------
skipping to change at page 12, line 25 skipping to change at page 10, line 23
I_message = HDR, T, [IDi], IDr, I_message = HDR, T, [IDi], IDr,
{SP}, [DHi], KEMAC {SP}, [DHi], KEMAC
-----------------------> R_message = HDR, T, -----------------------> R_message = HDR, T,
[IDr], IDi, [IDr], IDi,
[DHr, DHi], KEMAC [DHr, DHi], KEMAC
<---------------------- <----------------------
Figure 2: DHHMAC update message Figure 2: DHHMAC update message
TGK re-keying supports two procedures: TGK re-keying supports two procedures:
a) True re-keying by exchanging new and fresh Diffie-Hellman half- a) True re-keying by exchanging new and fresh Diffie-Hellman half-
keys. For this, the initiator SHALL provide a new, fresh DHi keys. For this, the initiator SHALL provide a new, fresh DHi, and
and the responder SHALL respond with a new, fresh DHr and the the responder SHALL respond with a new, fresh DHr and the received
received DHi. DHi.
b) Non-key related information update without any Diffie-Hellman b) Non-key related information update without including any Diffie-
half-keys included in the exchange. Such transaction does not Hellman half-keys in the exchange. Such a transaction does not
change the actual TGK but updates other information like change the actual TGK but updates other information such as
security policy parameters for example. To only update the security policy parameters. To update the non-key related
non-key related information, [DHi] and [DHr, DHi] SHALL be left information only, [DHi] and [DHr, DHi] SHALL be left out.
out.
4. 4. DHHMAC Payload Formats
DHHMAC payload formats
This section specifies the payload formats and data type values for This section specifies the payload formats and data type values for
DHHMAC, see also [3] chapter 6 for a definition of the MIKEY DHHMAC; see also [2] section 6, for a definition of the MIKEY
payloads. payloads.
This document does not define new payload formats but re-uses MIKEY This document does not define new payload formats but re-uses MIKEY
payloads for DHHMAC as referenced: payloads for DHHMAC as referenced:
* Common header payload (HDR), see section 4.1 and [3] section 6.1 * Common header payload (HDR); see section 4.1 and [2] section 6.1.
* SRTP ID sub-payload, see [3] section 6.1.1, * SRTP ID sub-payload; see [2] section 6.1.1.
* Key data transport payload (KEMAC), see section 4.2 and [3] section * Key data transport payload (KEMAC); see section 4.2 and [2] section
6.2 6.2.
* DH data payload, see [3] section 6.4 * DH data payload; see [2] section 6.4.
* Timestamp payload, [3] section 6.6 * Timestamp payload; see [2] section 6.6.
* ID payload, [3] section 6.7 * ID payload; [2] section 6.7.
* Security Policy payload (SP), [3] section 6.10 * Security Policy payload (SP); see [2] section 6.10.
* RAND payload (RAND), [3] section 6.11 * RAND payload (RAND); see [2] section 6.11.
* Error payload (ERR), [3] section 6.12 * Error payload (ERR); see [2] section 6.12.
* General Extension Payload, [3] section 6.15 * General Extension Payload; see [2] section 6.15.
4.1. Common header payload (HDR) 4.1. Common Header Payload (HDR)
Referring to [3] section 6.1, for DHHMAC the following data types Referring to [2] section 6.1, the following data types SHALL be used
SHALL be used: for DHHMAC:
Data type | Value | Comment Data type | Value | Comment
------------------------------------------------------------- -------------------------------------------------------------
DHHMAC init | 7 | Initiator's DHHMAC exchange message DHHMAC init | 7 | Initiator's DHHMAC exchange message
DHHMAC resp | 8 | Responder's DHHMAC exchange message DHHMAC resp | 8 | Responder's DHHMAC exchange message
Error | 6 | Error message, see [3] section 6.12 Error | 6 | Error message; see [2] section 6.12
Table 4.1.a Table 4.1.a
Note: A responder is able to recognize the MIKEY DHHMAC protocol Note: A responder is able to recognize the MIKEY DHHMAC protocol by
by evaluating the data type field as 7 or 8. This is how the evaluating the data type field as 7 or 8. This is how the responder
responder can differentiate between MIKEY and MIKEY DHHMAC. can differentiate between MIKEY and MIKEY DHHMAC.
The next payload field SHALL be one of the following values: The next payload field SHALL be one of the following values:
Next payload| Value | Section Next payload| Value | Section
---------------------------------------------------------------- ----------------------------------------------------------------
Last payload| 0 | - Last payload| 0 | -
KEMAC | 1 | section 4.2 and [3] section 6.2 KEMAC | 1 | section 4.2 and [2] section 6.2
DH | 3 | [3] section 6.4 DH | 3 | [2] section 6.4
T | 5 | [3] section 6.6 T | 5 | [2] section 6.6
ID | 6 | [3] section 6.7 ID | 6 | [2] section 6.7
SP | 10 | [3] section 6.10 SP | 10 | [2] section 6.10
RAND | 11 | [3] section 6.11 RAND | 11 | [2] section 6.11
ERR | 12 | [3] section 6.12 ERR | 12 | [2] section 6.12
General Ext.| 21 | [3] section 6.15 General Ext.| 21 | [2] section 6.15
Table 4.1.b Table 4.1.b
Other defined next payload values defined in [3] SHALL not be Other defined next payload values defined in [2] SHALL not be applied
applied to DHHMAC. to DHHMAC.
The responder in case of a decoding error or of a failed HMAC In case of a decoding error or of a failed HMAC authentication
authentication verification SHALL apply the Error payload data verification, the responder SHALL apply the Error payload data type.
type.
4.2. Key data transport payload (KEMAC) 4.2. Key Data Transport Payload (KEMAC)
DHHMAC SHALL apply this payload for conveying the HMAC result DHHMAC SHALL apply this payload for conveying the HMAC result along
along with the indicated authentication algorithm. KEMAC when used with the indicated authentication algorithm. When used in
in conjunction with DHHMAC SHALL not convey any encrypted data; 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 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 to 0, and Encr data SHALL be left empty. The AES key wrap method
(see [23]) SHALL not be applied for DHHMAC. (see [16]) SHALL not be applied for DHHMAC.
For DHHMAC, this key data transport payload SHALL be the last For DHHMAC, this key data transport payload SHALL be the last payload
payload in the message. Note that the Next payload field SHALL be in the message. Note that the Next payload field SHALL be set to
set to Last payload. The HMAC is then calculated over the entire Last payload. The HMAC is then calculated over the entire MIKEY
MIKEY message excluding the MAC field using auth_key as described message, excluding the MAC field using auth_key as described in [2]
in [3] section 5.2 and then stored within the MAC field. section 5.2, and then stored within the MAC field.
MAC alg | Value | Comments MAC alg | Value | Comments
------------------------------------------------------------------ ------------------------------------------------------------------
HMAC-SHA-1 | 0 | Mandatory, Default (see [4]) HMAC-SHA-1 | 0 | Mandatory, Default (see [3])
NULL | 1 | Very restricted use, see NULL | 1 | Very restricted use; see
| [3] section 4.2.4 | [2] section 4.2.4
Table 4.2.a Table 4.2.a
HMAC-SHA-1 is the default hash function that MUST be implemented HMAC-SHA-1 is the default hash function that MUST be implemented as
as part of the DHHMAC. The length of the HMAC-SHA-1 result is 160 part of the DHHMAC. The length of the HMAC-SHA-1 result is 160 bits.
bits.
4.3. ID payload (ID) 4.3. ID Payload (ID)
For DHHMAC, this payload SHALL only hold a non-certificate based For DHHMAC, this payload SHALL only hold a non-certificate-based
identity. identity.
4.4. General Extension Payload 4.4. General Extension Payload
For DHHMAC and to avoid bidding-down attacks, this payload SHALL For DHHMAC, to avoid bidding-down attacks, this payload SHALL list
list all key management protocol identifiers of a surrounding all key management protocol identifiers of a surrounding
encapsulation protocol such as for example, SDP [5]. The General encapsulation protocol, such as SDP [4]. The General Extension
Extension Payload SHALL be integrity-protected with the HMAC using Payload SHALL be integrity protected with the HMAC using the shared
the shared secret. secret.
Type | Value | Comments Type | Value | Comments
SDP IDs | 1 | List of SDP key management IDs (allocated for SDP IDs | 1 | List of SDP key management IDs (allocated for
use in [5]); see also [3] section 6.15. use in [4]); see also [2] section 6.15.
Table 4.4.a Table 4.4.a
5. 5. Security Considerations
Security Considerations
This document addresses key management security issues throughout. This document addresses key management security issues throughout.
For a comprehensive explanation of MIKEY security considerations, For a comprehensive explanation of MIKEY security considerations,
please refer to MIKEY [3] section 9. please refer to MIKEY [2] section 9.
In addition to that, this document addresses security issues In addition, this document addresses security issues according to
according to [8] where the following security considerations apply in [7], where the following security considerations apply in particular
particular to this document: to this document:
5.1. Security environment 5.1. Security Environment
Generally, the DHHMAC security protocol described in this document The DHHMAC security protocol described in this document focuses
focuses primarily on communication security; i.e. the security issues primarily on communication security; i.e., the security issues
concerned with the MIKEY DHHMAC protocol. Nevertheless, some system concerned with the MIKEY DHHMAC protocol. Nevertheless, some system
security issues are of interest as well that are not explicitly security issues are also of interest that are not explicitly defined
defined by the DHHMAC protocol, but should be provided locally in by the DHHMAC protocol, but that should be provided locally in
practice. practice.
The system that runs the DHHMAC protocol entity SHALL provide the The system that runs the DHHMAC protocol entity SHALL provide the
capability to generate (pseudo) random numbers as input to the capability to generate (pseudo) random numbers as input to the
Diffie-Hellman operation (see [9], [15]). Furthermore, the system Diffie-Hellman operation (see [8]). Furthermore, the system SHALL be
SHALL be capable of storing the generated (pseudo) random data, capable of storing the generated (pseudo) random data, secret data,
secret data, keys and other secret security parameters securely (i.e. keys, and other secret security parameters securely (i.e.,
confidential and safe from unauthorized tampering). confidential and safe from unauthorized tampering).
5.2. Threat model 5.2. Threat Model
The threat model, to which this document adheres, covers the issues The threat model, to which this document adheres, covers the issues
of end-to-end security in the Internet generally, without ruling out of end-to-end security in the Internet generally, without ruling out
the possibility that MIKEY DHHMAC can be deployed in a corporate, the possibility that MIKEY DHHMAC can be deployed in a corporate,
closed IP environment. This also includes the possibility that MIKEY closed IP environment. This also includes the possibility that MIKEY
DHHMAC can be deployed on a hop-by-hop basis with some intermediate DHHMAC can be deployed on a hop-by-hop basis with some intermediate
trusted "MIKEY DHHMAC proxies" involved. trusted "MIKEY DHHMAC proxies" involved.
Since DHHMAC is a key management protocol, the following security Since DHHMAC is a key management protocol, the following security
threats are of concern: threats are of concern:
* Unauthorized interception of plain TGKs: * Unauthorized interception of plain TGKs: For DHHMAC, this threat
For DHHMAC this threat does not occur since the TGK is not actually does not occur since the TGK is not actually transmitted on the
transmitted on the wire (not even in encrypted fashion). 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 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 considered not to yield any
significant security risk.
* Masquerade of either entity: * Eavesdropping of other, transmitted keying information: DHHMAC
This security threat must be avoided and if a masquerade attack protocol does not explicitly transmit the TGK at all. Instead, by
would be attempted, appropriate detection means must be in place. using the Diffie-Hellman "encryption" operation, which conceals the
DHHMAC addresses this threat by providing mutual peer entity secret (pseudo) random values, only partial information (i.e., the
authentication. DH half-key) for construction of the TGK is transmitted. It is
fundamentally assumed that availability of such Diffie-Hellman
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.
* Man-in-the-middle attacks: * Masquerade of either entity: This security threat must be avoided,
Such attacks threaten the security of exchanged, non-authenticated and if a masquerade attack would be attempted, appropriate
messages. Man-in-the-middle attacks usually come with masquerade detection means must be in place. DHHMAC addresses this threat by
and or loss of message integrity (see below). Man-in-the-middle providing mutual peer entity authentication.
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: * Man-in-the-middle attacks: Such attacks threaten the security of
This security threat relates to unauthorized replay, deletion, exchanged, non-authenticated messages. Man-in-the-middle attacks
insertion and manipulation of messages. While any such attacks usually come with masquerade and or loss of message integrity (see
cannot be avoided they must be detected at least. DHHMAC addresses below). Man-in-the-middle attacks must be avoided and, if present
this threat by providing message integrity. or attempted, must be detected appropriately. DHHMAC addresses
this threat by providing mutual peer entity authentication and
message integrity.
* Bidding-down attacks: * 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.
When multiple key management protocols each of a distinct security * Bidding-down attacks: When multiple key management protocols, each
level are offered (e.g., such as is possible by SDP [5]), avoiding of a distinct security level, are offered (such as those made
bidding-down attacks is of concern. DHHMAC addresses this threat possible by SDP [4]), avoiding bidding-down attacks is of concern.
by reusing the MIKEY General Extension Payload mechanism, where DHHMAC addresses this threat by reusing the MIKEY General Extension
all key management protocol identifiers are be listed within the Payload mechanism, where all key management protocol identifiers
MIKEY General Extension Payload. are to be listed within the MIKEY General Extension Payload.
Some potential threats are not within the scope of this threat model: Some potential threats are not within the scope of this threat model:
* Passive and off-line cryptanalysis of the Diffie-Hellman algorithm: * Passive and off-line cryptanalysis of the Diffie-Hellman algorithm:
Under certain reasonable assumptions (see 5.4 below) it is widely Under certain reasonable assumptions (see 5.4, below), it is widely
believed that DHHMAC is sufficiently secure and that such attacks believed that DHHMAC is sufficiently secure and that such attacks
are infeasible, although the possibility of a successful attack are infeasible, although the possibility of a successful attack
cannot be ruled out. cannot be ruled out.
* Non-repudiation of the receipt or of the origin of the message: * Non-repudiation of the receipt or of the origin of the message:
These are not requirements within the context of DHHMAC in this These are not requirements within the context of DHHMAC in this
environment and thus related countermeasures are not provided at environment, and thus related countermeasures are not provided at
all. all.
* Denial-of-service or distributed denial-of-service attacks: * Denial-of-service or distributed denial-of-service attacks: Some
Some considerations are given on some of those attacks, but DHHMAC considerations are given on some of those attacks, but DHHMAC does
does not claim to provide full countermeasure against any of those not claim to provide full countermeasure against any of those
attacks. For example, stressing the availability of the entities attacks. For example, stressing the availability of the entities
are not thwarted by means of the key management protocol; some is not thwarted by means of the key management protocol; some other
other local countermeasures should be applied. Further, some DoS local countermeasures should be applied. Further, some DoS attacks
attacks are not countered such as interception of a valid DH- are not countered, such as interception of a valid DH- request and
request and its massive instant duplication. Such attacks might at its massive instant duplication. Such attacks might at least be
least be countered partially by some local means that are outside countered partially by some local means that are outside the scope
the scope of this document. of this document.
* Identity protection: * Identity protection: Like MIKEY, identity protection is not a major
Like MIKEY, identity protection is not a major design requirement design requirement for MIKEY-DHHMAC, either; see [2]. No security
for MIKEY-DHHMAC either, see [3]. No security protocol is known so protocol is known so far that is able to provide the objectives of
far, that is able to provide the objectives of DHHMAC as stated in DHHMAC as stated in section 5.3, including identity protection
section 5.3 including identity protection within just a single within just a single roundtrip. MIKEY-DHHMAC trades identity
roundtrip. MIKEY-DHHMAC trades identity protection for better protection for better security for the keying material and shorter
security for the keying material and shorter roundtrip time. Thus, roundtrip time. Thus, MIKEY-DHHMAC does not provide identity
MIKEY-DHHMAC does not provide identity protection on its own but protection on its own but may inherit such property from a security
may inherit such property from a security protocol underneath that protocol underneath that actually features identity protection.
actually features identity protection.
The DHHMAC security protocol (see section 3) and the TGK re-keying The DHHMAC security protocol (see section 3) and the TGK re-keying
security protocol (see section 3.1) provide the option not to security protocol (see section 3.1) provide the option not to
supply identity information. This option is only applicable if supply identity information. This option is only applicable if
some other means are available of supplying trustworthy identity some other means are available to supply trustworthy identity
information; e.g., by relying on secured links underneath of MIKEY information; e.g., by relying on secured links underneath MIKEY
that supply trustworthy identity information otherwise. However, that supply trustworthy identity information some other way.
it is understood that without identity information present, the However, it is understood that without identity information, the
MIKEY key management security protocols might be subject to MIKEY key management security protocols might be subject to
security weaknesses such as masquerade, impersonation and security weaknesses such as masquerade, impersonation, and
reflection attacks particularly in end-to-end scenarios where no reflection attacks, particularly in end-to-end scenarios where no
other secure means of assured identity information is provided. other secure means of assured identity information are provided.
Leaving identity fields optional if possible thus should not be Leaving identity fields optional (if doing so is possible) thus
seen as a privacy method either, but rather as a protocol should not be seen as a privacy method, either, but rather as a
optimization feature. protocol optimization feature.
5.3. Security features and properties 5.3. Security Features and Properties
With the security threats in mind, this draft provides the following With the security threats in mind, this document provides the
security features and yields the following properties: following security features and yields the following properties:
* Secure key agreement with the establishment of a TGK at both peers: * Secure key agreement with the establishment of a TGK at both peers:
This is achieved using an authenticated Diffie-Hellman key This is achieved using an authenticated Diffie-Hellman key
management protocol. management protocol.
* Peer-entity authentication (mutual): * Peer-entity authentication (mutual): This authentication
This authentication corroborates that the host/user is authentic in corroborates that the host/user is authentic in that possession of
that possession of a pre-assigned secret key is proven using keyed a pre-assigned secret key is proven using keyed HMAC.
HMAC. Authentication occurs on the request and on the response Authentication occurs on the request and on the response message;
message, thus authentication is mutual. thus authentication is mutual.
The HMAC computation corroborates for authentication and message The HMAC computation corroborates for authentication and message
integrity of the exchanged Diffie-Hellman half-keys and associated integrity of the exchanged Diffie-Hellman half-keys and associated
messages. The authentication is absolutely necessary in order to messages. The authentication is absolutely necessary in order to
avoid man-in-the-middle attacks on the exchanged messages in avoid man-in-the-middle attacks on the exchanged messages in
transit and in particular, on the otherwise non-authenticated transit and, in particular, on the otherwise non-authenticated
exchanged Diffie-Hellman half keys. exchanged Diffie-Hellman half-keys.
Note: This document does not address issues regarding Note: This document does not address issues regarding
authorization; this feature is not provided explicitly. However, authorization; this feature is not provided explicitly. However,
DHHMAC authentication means support and facilitate realization of DHHMAC authentication means support and facilitate realization of
authorization means (local issue). authorization means (local issue).
* Cryptographic integrity check: * Cryptographic integrity check: The cryptographic integrity check is
The cryptographic integrity check is achieved using a message achieved using a message digest (keyed HMAC). It includes the
digest (keyed HMAC). It includes the exchanged Diffie-Hellman exchanged Diffie-Hellman half-keys but covers the other parts of
half-keys but covers the other parts of the exchanged message as the exchanged message as well. Both mutual peer entity
well. Both mutual peer entity authentication and message integrity authentication and message integrity provide effective
provide effective countermeasures against man-in-the-middle countermeasures against man-in-the-middle attacks.
attacks.
The initiator may deploy a local timer that fires when the awaited The initiator may deploy a local timer that fires when the awaited
response message did not arrive in a timely manner. This is to response message did not arrive in a timely manner. This is
detect deletion of entire messages. intended to detect deletion of entire messages.
* Replay protection of the messages is achieved using embedded * Replay protection of the messages is achieved using embedded
timestamps. In order to detect replayed messages it is essential timestamps: In order to detect replayed messages, it is essential
that the clocks among initiator and sender be roughly synchronized. that the clocks among initiator and sender be roughly synchronized.
The reader is referred to [3] section 5.4 and [3] section 9.3 that The reader is referred to [2] section 5.4, and [2] section 9.3,
provide further considerations and give guidance on clock which provide further considerations and give guidance on clock
synchronization and timestamp usage. Should the clock synchronization and timestamp usage. Should the clock
synchronization be lost, then end systems cannot detect replayed synchronization be lost, end systems cannot detect replayed
messages anymore resulting that the end systems cannot securely messages anymore, and the end systems cannot securely establish
establish keying material. This may result in a denial-of-service, keying material. This may result in a denial-of-service; see [2]
see [3] section 9.5. section 9.5.
* Limited DoS protection: * Limited DoS protection: Rapid checking of the message digest allows
Rapid checking of the message digest allows verifying the verifying the authenticity and integrity of a message before
authenticity and integrity of a message before launching CPU launching CPU intensive Diffie-Hellman operations or starting other
intensive Diffie-Hellman operations or starting other resource resource consuming tasks. This protects against some denial-of-
consuming tasks. This protects against some denial-of-service service attacks: malicious modification of messages and spam
attacks: malicious modification of messages and spam attacks with attacks with (replayed or masqueraded) messages. DHHMAC probably
(replayed or masqueraded) messages. DHHMAC probably does not does not explicitly counter sophisticated distributed, large-scale
explicitly counter sophisticated distributed, large-scale denial- denial-of-service attacks that compromise system availability, for
of-service attacks that compromise system availability for example. example. Some DoS protection is provided by inclusion of the
Some DoS protection is provided by inclusion of the initiator's initiator's identity payload in the I_message. This allows the
identity payload in the I_message. This allows the recipient to recipient to filter out those (replayed) I_messages that are not
filter out those (replayed) I_messages that are not targeted for targeted for him and to avoid creating unnecessary MIKEY sessions.
him and avoids the recipient from creating unnecessary MIKEY
sessions.
* Perfect-forward secrecy (PFS): * Perfect-forward secrecy (PFS): Other than the MIKEY pre-shared and
Other than the MIKEY pre-shared and public-key based key public-key-based key distribution protocols, the Diffie-Hellman key
distribution protocols, the Diffie-Hellman key agreement protocol agreement protocol features a security property called perfect
features a security property called perfect forward secrecy. That forward secrecy. That is, even if the long-term pre-shared key is
is, that even if the long-term pre-shared key would be compromised compromised at some point in time, this does not compromise past or
at some point in time, this would not render past or future session future session keys.
keys compromised.
Neither the MIKEY pre-shared nor the MIKEY public-key protocol Neither the MIKEY pre-shared nor the MIKEY public-key protocol
variants are able to provide the security property of perfect- variants are able to provide the security property of perfect-
forward secrecy. Thus, none of the other MIKEY protocols is able forward secrecy. Thus, none of the other MIKEY protocols is able
to substitute the Diffie-Hellman PFS property. to substitute the Diffie-Hellman PFS property.
As such, DHHMAC, as well as digitally signed DH, provides a far As such, DHHMAC and digitally signed DH provide a far superior
superior security level over the pre-shared or public-key based key security level to that of the pre-shared or public-key-based key
distribution protocol in that respect. distribution protocol in that respect.
* Fair, mutual key contribution: * Fair, mutual key contribution: The Diffie-Hellman key management
The Diffie-Hellman key management protocol is not a strict key protocol is not a strict key distribution protocol per se, in which
distribution protocol per se with the initiator distributing a key the initiator distributes a key to its peers. Actually, both
to its peers. Actually, both parties involved in the protocol parties involved in the protocol exchange are able to contribute to
exchange are able to equally contribute to the common Diffie- the common Diffie-Hellman TEK traffic generating key equally. This
Hellman TEK traffic generating key. This reduces the risk of reduces the risk of either party cheating or unintentionally
either party cheating or unintentionally generating a weak session generating a weak session key. This makes the DHHMAC a fair key
key. This makes the DHHMAC a fair key agreement protocol. One may agreement protocol. One may view this property as an additional
view this property as an additional distributed security measure distributed security measure that increases security robustness
that is increasing security robustness over the case where all the over that of the case where all the security depends just on the
security depends just on the proper implementation of a single proper implementation of a single entity.
entity.
In order for Diffie-Hellman key agreement to be secure, each party For Diffie-Hellman key agreement to be secure, each party SHALL
SHALL generate its xi or xr values using a strong, unpredictable generate its xi or xr values using a strong, unpredictable pseudo-
pseudo-random generator if a source of true randomness is not random generator if a source of true randomness is not available.
available. Further, these values xi or xr SHALL be kept private. Further, these values xi or xr SHALL be kept private. It is
It is RECOMMENDED that these secret values be destroyed once the RECOMMENDED that these secret values be destroyed once the common
common Diffie-Hellman shared secret key has been established. Diffie-Hellman shared secret key has been established.
* Efficiency and performance: * Efficiency and performance: Like the MIKEY-public key protocol, the
Like the MIKEY-public key protocol, the MIKEY DHHMAC key agreement MIKEY DHHMAC key agreement protocol securely establishes a TGK
protocol securely establishes a TGK within just one roundtrip. within just one roundtrip. Other existing key management
Other existing key management techniques like IPsec-IKE [14], techniques, such as IPsec-IKE [12], IPsec-IKEv2 [14], TLS [11], and
IPsec-IKEv2 [21] and TLS [13] and other schemes are not deemed other schemes, are not deemed adequate in addressing those real-
adequate in addressing sufficiently those real-time and security time and security requirements sufficiently; they all use more than
requirements; they all use more than a single roundtrip. All the a single roundtrip. All the MIKEY key management protocols are
MIKEY key management protocols are able to complete their task of able to complete their task of security policy parameter
security policy parameter negotiation including key-agreement or negotiation, including key-agreement or key distribution, in one
key distribution in one roundtrip. However, the MIKEY pre-shared roundtrip. However, the MIKEY pre-shared and MIKEY public-key
and the MIKEY public-key protocol both are able to complete their protocol are both able to complete their task even in a half-
task even in a half-round trip when the confirmation messages are roundtrip when the confirmation messages are omitted.
omitted.
Using HMAC in conjunction with a strong one-way hash function such Using HMAC in conjunction with a strong one-way hash function (such
as SHA1 may be achieved more efficiently in software than expensive as SHA1) may be achieved more efficiently in software than
public-key operations. This yields a particular performance expensive public-key operations. This yields a particular
benefit of DHHMAC over signed DH or the public-key encryption performance benefit of DHHMAC over signed DH or the public-key
protocol. encryption protocol.
If a very high security level is desired for long-term secrecy of If a very high security level is desired for long-term secrecy of
the negotiated Diffie-Hellman shared secret, longer hash values may the negotiated Diffie-Hellman shared secret, longer hash values may
be deployed such as SHA256, SHA384 or SHA512 provide, possibly in be deployed, such as SHA256, SHA384, or SHA512 provide, possibly in
conjunction with stronger Diffie-Hellman groups. This is left as conjunction with stronger Diffie-Hellman groups. This is left as
for further study. for further study.
For the sake of improved performance and reduced round trip delay For the sake of improved performance and reduced roundtrip delay,
either party may off-line pre-compute its public Diffie-Hellman either party may pre-compute its public Diffie-Hellman half-key
half-key. off-line.
On the other side and under reasonable conditions, DHHMAC consumes On the other side and under reasonable conditions, DHHMAC consumes
more CPU cycles than the MIKEY pre-shared key distribution more CPU cycles than the MIKEY pre-shared key distribution
protocol. The same might hold true quite likely for the MIKEY protocol. The same might hold true quite likely for the MIKEY
public-key distribution protocol (depending on choice of the public-key distribution protocol (depending on choice of the
private and public key lengths). private and public key lengths). As such, it can be said that
DHHMAC provides sound performance when compared with the other
As such, it can be said that DHHMAC provides sound performance when MIKEY protocol variants.
compared with the other MIKEY protocol variants.
The use of optional identity information (with the constraints The use of optional identity information (with the constraints
stated in section 5.2) and optional Diffie-Hellman half-key fields stated in section 5.2) and optional Diffie-Hellman half-key fields
provides a means to increase performance and shorten the consumed provides a means to increase performance and shorten the consumed
network bandwidth. network bandwidth.
* Security infrastructure: * Security infrastructure: This document describes the HMAC-
This document describes the HMAC-authenticated Diffie-Hellman key authenticated Diffie-Hellman key agreement protocol, which
agreement protocol that completely avoids digital signatures and completely avoids digital signatures and the associated public-key
the associated public-key infrastructure as would be necessary for infrastructure, as would be necessary for the X.509 RSA public-
the X.509 RSA public-key based key distribution protocol or the key-based key distribution protocol or the digitally signed
digitally signed Diffie-Hellman key agreement protocol as described Diffie-Hellman key agreement protocol as described in MIKEY.
in MIKEY. Public-key infrastructures may not always be available Public-key infrastructures may not always be available in certain
in certain environments nor may they be deemed adequate for real- environments, nor may they be deemed adequate for real-time
time multimedia applications when taking additional steps for multimedia applications when additional steps are taken for
certificate validation and certificate revocation methods with certificate validation and certificate revocation methods with
additional round-trips into account. additional roundtrips into account.
DHHMAC does not depend on PKI nor do implementations require PKI DHHMAC does not depend on PKI, nor do implementations require PKI
standards and thus is believed to be much simpler than the more standards. Thus, it is believed to be much simpler than the more
complex PKI facilities. complex PKI facilities.
DHHMAC is particularly attractive in those environments where DHHMAC is particularly attractive in those environments where
provisioning of a pre-shared key has already been accomplished. provisioning of a pre-shared key has already been accomplished.
* NAT-friendliness: * NAT-friendliness: DHHMAC is able to operate smoothly through
DHHMAC is able to operate smoothly through firewall/NAT devices as firewall/NAT devices as long as the protected identity information
long as the protected identity information of the end entity is not of the end entity is not an IP/transport address.
an IP /transport address.
* Scalability: * Scalability: Like the MIKEY signed Diffie-Hellman protocol, DHHMAC
Like the MIKEY signed Diffie-Hellman protocol, DHHMAC does not does not scale to any larger configurations beyond peer-to-peer
scale to any larger configurations beyond peer-to-peer groups. groups.
5.4. Assumptions 5.4. Assumptions
This document states a couple of assumptions upon which the security This document states a couple of assumptions upon which the security
of DHHMAC significantly depends. It is assumed, that of DHHMAC significantly depends. The following conditions are
assumed:
* the parameters xi, xr, s and auth_key are to be kept secret. * The parameters xi, xr, s, and auth_key are to be kept secret.
* the pre-shared key s has sufficient entropy and cannot be * The pre-shared key s has sufficient entropy and cannot be
effectively guessed. effectively guessed.
* the pseudo-random function (PRF) is secure, yields indeed the * The pseudo-random function (PRF) is secure, yields the pseudo-
pseudo-random property and maintains the entropy. random property, and maintains the entropy.
* a sufficiently large and secure Diffie-Hellman group is applied. * A sufficiently large and secure Diffie-Hellman group is applied.
* the Diffie-Hellman assumption holds saying basically that even with * The Diffie-Hellman assumption holds saying basically that even with
knowledge of the exchanged Diffie-Hellman half-keys and knowledge knowledge of the exchanged Diffie-Hellman half-keys and knowledge
of the Diffie-Hellman group, it is infeasible to compute the TGK or 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 to derive the secret parameters xi or xr. The latter is also
called the discrete logarithm assumption. Please see [7], [11] or called the discrete logarithm assumption. Please see [6], [9], or
[12] for more background information regarding the Diffie-Hellman [10] for more background information regarding the Diffie-Hellman
problem and its computational complexity assumptions. problem and its computational complexity assumptions.
* the hash function (SHA1) is secure; i.e. that it is computationally * The hash function (SHA1) is secure; i.e., it is computationally
infeasible to find a message which corresponds to a given message infeasible to find a message that corresponds to a given message
digest, or to find two different messages that produce the same digest, or to find two different messages that produce the same
message digest. message digest.
* the HMAC algorithm is secure and does not leak the auth_key. In * The HMAC algorithm is secure and does not leak the auth_key. In
particular, the security depends on the message authentication particular, the security depends on the message authentication
property of the compression function of the hash function H when property of the compression function of the hash function H when it
applied to single blocks (see [6]). is applied to single blocks (see [5]).
* a source capable of producing sufficiently many bits of (pseudo) * A source capable of producing sufficiently many bits of (pseudo)
randomness is available. randomness is available.
* the system upon which DHHMAC runs is sufficiently secure. * The system upon which DHHMAC runs is sufficiently secure.
5.5. Residual Risk
5.5. Residual risk
Although these detailed assumptions are non-negligible, security Although these detailed assumptions are non-negligible, security
experts generally believe that all these assumptions are reasonable experts generally believe that all these assumptions are reasonable
and that the assumptions made can be fulfilled in practice with and that the assumptions made can be fulfilled in practice with
little or no expenses. little or no expenses.
The mathematical and cryptographic assumptions of the properties of The mathematical and cryptographic assumptions of the properties of
the PRF, the Diffie-Hellman algorithm (discrete log-assumption), the the PRF, the Diffie-Hellman algorithm (discrete log-assumption), the
HMAC algorithm and SHA1 algorithms have been neither proven or HMAC algorithm, and the SHA1 algorithms have been neither proven nor
disproven at this time. disproven at this time.
Thus, a certain residual risk remains, which might threaten the Thus, a certain residual risk remains, which might threaten the
overall security at some unforeseeable time in the future. overall security at some unforeseeable time in the future.
The DHHMAC would be compromised as soon as any of the listed The DHHMAC would be compromised as soon as any of the listed
assumptions do not hold anymore. assumptions no longer hold.
The Diffie-Hellman mechanism is a generic security technique that is The Diffie-Hellman mechanism is a generic security technique that is
not only applicable to groups of prime order or of characteristic not only applicable to groups of prime order or of characteristic
two. This is because of the fundamental mathematical assumption that two. This is because of the fundamental mathematical assumption that
the discrete logarithm problem is also a very hard one in general the discrete logarithm problem is also a very hard one in general
groups. This enables Diffie-Hellman to be deployed also for GF(p)*, groups. This enables Diffie-Hellman to be deployed also for GF(p)*,
for sub-groups of sufficient size and for groups upon elliptic for sub-groups of sufficient size, and for groups upon elliptic
curves. RSA does not allow such generalization, as the core curves. RSA does not allow such generalization, as the core
mathematical problem is a different one (large integer mathematical problem is a different one (large integer
factorization). factorization).
RSA asymmetric keys tend to become increasingly lengthy (1536 bits RSA asymmetric keys tend to become increasingly lengthy (1536 bits
and more) and thus very computationally intensive. Nevertheless, and more) and thus very computationally intensive. Nevertheless,
elliptic curve Diffie-Hellman (ECDH) allows to cut-down key lengths Elliptic Curve Diffie-Hellman (ECDH) allows key lengths to be cut
substantially (say 170 bits or more) while maintaining at least the down substantially (say 170 bits or more) while maintaining at least
security level and providing even more significant performance the security level and providing even more significant performance
benefits in practice. Moreover, it is believed that elliptic curve benefits in practice. Moreover, it is believed that elliptic-curve
techniques provide much better protection against side channel techniques provide much better protection against side channel
attacks due to the inherent redundancy in the projective coordinates. attacks due to the inherent redundancy in the projective coordinates.
For all these reasons, one may view elliptic-curve-based Diffie- For all these reasons, one may view elliptic-curve-based Diffie-
Hellman as being more "future-proof" and robust against potential Hellman as being more "future-proof" and robust against potential
threats than RSA. Note, that an elliptic-curve Diffie-Hellman threats than RSA is. Note that Elliptic Curve Diffie-Hellman
variant of MIKEY remains for further study. variants of MIKEY are defined in [31].
It is not recommended to deploy DHHMAC for any other usage than HMAC-SHA1 is a key security mechanism within DHHMAC on which the
depicted in section 2. Otherwise any such misapplication might lead overall security of MIKEY DHHMAC depends. MIKEY DHHMAC uses HMAC-
to unknown, undefined properties. 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 5.6. Authorization and Trust Model
Basically, similar remarks on authorization as stated in [3] section Basically, similar remarks on authorization as those stated in [2]
4.3.2. hold also for DHHMAC. However, as noted before, this key section 4.3.2 hold also for DHHMAC. However, as noted before, this
management protocol does not serve full groups. key management protocol does not serve full groups.
One may view the pre-established shared secret to yield some pre- One may view the pre-established shared secret as yielding some pre-
established trust relationship between the initiator and the established trust relationship between the initiator and the
responder. This results in a much simpler trust model for DHHMAC responder. This results in a much simpler trust model for DHHMAC
than would be the case for some generic group key management protocol than would be the case for some generic group key management protocol
and potential group entities without any pre-defined trust and potential group entities without any pre-defined trust
relationship. The common group controller in conjunction with the relationship. In conjunction with the assumption of a shared key,
assumption of a shared key simplifies the communication setup of the the common group controller simplifies the communication setup of the
entities. entities.
One may view the pre-established trust relationship through the pre- One may view the pre-established trust relationship through the pre-
shared secret as some means for pre-granted, implied authorization. shared secret as some means for pre-granted, implied authorization.
This document does not define any particular authorization means but This document does not define any particular authorization means but
leaves this subject to the application. leaves this subject to the application.
6. Acknowledgments 6. Acknowledgments
This document incorporates kindly valuable review feedback from This document incorporates kindly, valuable review feedback from
Steffen Fries, Hannes Tschofenig, Fredrick Lindholm, Mary Barnes and Steffen Fries, Hannes Tschofenig, Fredrick Lindholm, Mary Barnes, and
Russell Housley and general feedback by the MSEC WG. Russell Housley and general feedback by the MSEC WG.
7. IANA considerations 7. IANA Considerations
This document does not define its own new name spaces for DHHMAC, This document does not define its own new name spaces for DHHMAC,
beyond the IANA name spaces that have been assigned for MIKEY, see beyond the IANA name spaces that have been assigned for MIKEY; see
[3] section 10 and section 10.1, see also IANA MIKEY payload name [2] sections 10 and 10.1 and IANA MIKEY payload name spaces [37].
spaces [37].
In order to align Table 4.1.a with [3] table 6.1.a, IANA is 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 requested to add the following entries to their MIKEY Payload Name
Space: Space:
Data Type Value Reference Data Type Value Reference
--------------- ----- --------- --------------- ----- ---------
DHHMAC init 7 RFC 4650
DHHMAC init 7 [RFCxxxx] DHHMAC resp 8 RFC 4650
DHHMAC resp 8 [RFCxxxx]
[Note to the RFC editor: Please replace RFCxxxx with the RFC number of
this document prior to publication.]
8. References 8. References
8.1 Normative References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", 8.1. Normative References
BCP 9, RFC 2026, October 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Requirement Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[3] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman; [2] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
"MIKEY: Multimedia Internet KEYing", RFC 3830 IETF, August 2004. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August
2004.
[4] NIST, FIBS-PUB 180-1, "Secure Hash Standard", April 1995, [3] NIST, FIBS-PUB 180-2, "Secure Hash Standard", April 1995,
http://csrc.nist.gov/fips/fip180-1.ps. http://csrc.nist.gov/publications/fips/fips180-2/
fips180-2withchangenotice.pdf.
[5] J. Arkko, E. Carrara et al: "Key Management Extensions for SDP [4] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E.
and RTSP", Internet Draft <draft-ietf-mmusic-kmgmt-ext-14.txt>, Carrara, "Key Management Extensions for Session Description
Work in Progress (MMUSIC WG), IETF, March 2005. Protocol (SDP) and Real Time Streaming Protocol (RTSP)", RFC
4567, July 2006.
[6] H. Krawczyk, M. Bellare, R. Canetti: "HMAC: Keyed-Hashing for [5] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
Message Authentication", RFC 2104, February 1997. for Message Authentication", RFC 2104, February 1997.
8.2 Informative References 8.2. Informative References
[7] A.J. Menezes, P. van Oorschot, S. A. Vanstone: "Handbook of [6] A.J. Menezes, P. van Oorschot, S. A. Vanstone: "Handbook of
Applied Cryptography", CRC Press 1996. Applied Cryptography", CRC Press 1996.
[8] E. Rescorla, B. Korver: " Guidelines for Writing RFC Text on [7] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on
Security Considerations", RFC 3552, IETF, July 2003. Security Considerations", BCP 72, RFC 3552, July 2003.
[9] D. Eastlake, S. Crocker: "Randomness Recommendations for
Security", RFC 1750, IETF, December 1994.
[10] S.M. Bellovin, C. Kaufman, J. I. Schiller: "Security [8] Eastlake 3rd, D., Crocker, S., and J. Schiller, "Randomness
Mechanisms for the Internet", RFC 3631, IETF, December 2003. Recommendations for Security", RFC 1750, December 1994.
[11] Ueli M. Maurer, S. Wolf: "The Diffie-Hellman Protocol", [9] Ueli M. Maurer, S. Wolf: "The Diffie-Hellman Protocol",
Designs, Codes, and Cryptography, Special Issue Public Key Designs, Codes, and Cryptography, Special Issue Public Key
Cryptography, Kluwer Academic Publishers, vol. 19, pp. 147-171, Cryptography, Kluwer Academic Publishers, vol. 19, pp. 147-171,
2000. ftp://ftp.inf.ethz.ch/pub/crypto/publications/MauWol00c.ps 2000.
ftp://ftp.inf.ethz.ch/pub/crypto/publications/MauWol00c.ps.
[12] Discrete Logarithms and the Diffie-Hellman Protocol;
http://www.crypto.ethz.ch/research/ntc/dldh/
[13] T. Dierks, C. Allen: "The TLS Protocol Version 1.0.", RFC 2246,
IETF, January 1999.
[14] D. Harkins, D. Carrel: "The Internet Key Exchange (IKE).", RFC [10] Discrete Logarithms and the Diffie-Hellman Protocol,
2409, IETF, November 1998. http://www.crypto.ethz.ch/research/ntc/dldh/.
[15] Donald E. Eastlake, Jeffrey I. Schiller, Steve Crocker: [11] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
"Randomness Requirements for Security"; <draft-eastlake- Protocol Version 1.1", RFC 4346, April 2006.
randomness2-10.txt>; Work in Progress, IETF, January 2005.
[16] J. Schiller: "Strong Security Requirements for Internet [12] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
Engineering Task Force Standard Protocols", RFC 3365, IETF, RFC 2409, November 1998.
2002.
[17] C. Meadows: "Advice on Writing an Internet Draft Amenable to [13] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Security Analysis", Work in Progress, <draft-irtf-cfrg-advice- Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
00.txt>, IRTF, October 2002. Session Initiation Protocol", RFC 3261, June 2002.
[18] T. Narten: "Guidelines for Writing an IANA Considerations [14] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
Section in RFCs", RFC 2434, IETF, October 1998. 4306, December 2005.
[19] J. Reynolds: "Instructions to Request for Comments (RFC) [15] ITU-T Recommendation H.235.7: " H.323 Security framework: Usage
Authors", Work in Progress, <draft-rfc-editor-rfc2223bis- of the MIKEY Key Management Protocol for the Secure Real Time
08.txt>, IETF, August 2004. Transport Protocol (SRTP) within H.235"; 9/2005.
[20] J. Rosenberg et all: "SIP: Session Initiation Protocol", RFC [16] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES)
3261, IETF, June 2002. Key Wrap Algorithm", RFC 3394, September 2002.
[21] Ch. Kaufman: "Internet Key Exchange (IKEv2) Protocol", Work in [17] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group
Progress (IPSEC WG), <draft-ietf-ipsec-ikev2-17.txt>, Internet Domain of Interpretation", RFC 3547, July 2003.
Draft, Work in Progress (IPSEC WG).
[22] ITU-T Recommendation H.235 Annex G: "Usage of the MIKEY [18] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP:
Key Management Protocol for the Secure Real Time Transport Group Secure Association Key Management Protocol", RFC 4535,
Protocol (SRTP) within H.235"; 1/2005. June 2006.
[23] Schaad, J., Housley R.: "Advanced Encryption Standard (AES) [19] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm,
Key Wrap Algorithm", RFC 3394, IETF, September 2002. "Multicast Security (MSEC) Group Key Management Architecture",
RFC 4046, April 2005.
[24] Baugher, M., Weis, B., Hardjono, T., Harney, H.: "The Group [20] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Domain of Interpretation", RFC 3547, IETF, July 2003. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC
3711, March 2004.
[25] Harney, H., Colegrove, A., Harder, E., Meth, U., Fleischer, R.: [21] ITU-T Recommendation H.235.0, " H.323 Security framework:
"Group Secure Association Key Management Protocol", <draft-ietf- Security framework for H-series (H.323 and other H.245 based)
msec-gsakmp-sec-08.txt>, Internet Draft, Work in Progress (MSEC multimedia systems", (09/2005).
WG).
[26] Baugher, M., Canetti, R., Dondeti, L., and Lindholm, F.: "Group [22] Adams, C., Farrell, S., Kause, T., and T. Mononen, "Internet
Key Management Architecture", <draft-ietf-msec-gkmarch-08.txt>, X.509 Public Key Infrastructure Certificate Management Protocol
Internet Draft, Work in Progress (MSEC WG). (CMP)", RFC 4210, September 2005.
[27] Baugher, McGrew, Oran, Blom, Carrara, Naslund: "The Secure [23] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams,
Real-time Transport Protocol", RFC 3711, IETF, March 2004. "X.509 Internet Public Key Infrastructure Online Certificate
Status Protocol - OCSP", RFC 2560, June 1999.
[28] ITU-T Recommendation H.235V3Amd1 Corr1, "Security and [24] Adams, C., Sylvester, P., Zolotarev, M., and R. Zuccherato,
encryption for H-series (H.323 and other H.245-based) multimedia "Internet X.509 Public Key Infrastructure Data Validation and
terminals", (01/2005). Certification Server Protocols", RFC 3029, February 2001.
[29] C. Adams et al: "Internet X.509 Public Key Infrastructure [25] Schaad, J., "Internet X.509 Public Key Infrastructure
Certificate Management Protocols"; draft-ietf-pkix-rfc2510bis- Certificate Request Message Format (CRMF)", RFC 4211, September
09.txt, Internet Draft, Work in Progress (PKIX WG). 2005.
[30] M. Myers et al: "X.509 Internet Public Key Infrastructure [26] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R.
Online Certificate Status Protocol - OCSP", RFC 2560, IETF, June Nicholas, "Internet X.509 Public Key Infrastructure:
1999. Certification Path Building", RFC 4158, September 2005.
[31] C. Adams et al: "Internet X.509 Public Key Infrastructure Data [27] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Validation and Certification Server Protocols", RFC 3029, IETF, Session Description Protocol (SDP)", RFC 3264, June 2002.
February 2001.
[32] M. Myers: "Internet X.509 Certificate Request Message Format", [37] IANA MIKEY Payload Name Spaces per RFC 3830, see
RFC 2511, IETF, March 1999. http://www.iana.org/assignments/mikey-payloads.
[33] M. Cooper et al: "Internet X.509 Public Key Infrastructure: [29] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes
Certification Path Building", <draft-ietf-pkix-certpathbuild- in Internet Protocols", RFC 4270, November 2005.
05.txt>, Internet Draft, Work in Progress (PKIX WG).
[34] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3978, [30] Bellovin, S.M. and E.K. Rescorla: "Deploying a New Hash
March 2005. Algorithm", October 2005,
http://www.cs.columbia.edu/~smb/papers/new-hash.pdf.
[35] Bradner, S., "Intellectual Property Rights in IETF Technology", [31] Milne, A., Blaser, M., Brown, D., and L. Dondetti, "ECC
BCP 79, RFC 3979, March 2005. Algorithms For MIKEY", Work in Progress, June 2005.
[36] J. Rosenberg, H. Schulzrinne: "An Offer/Answer Model with the [32] Bellare, M.: "New Proofs for NMAC and HMAC: Security Without
Session Description Protocol (SDP)", RFC 3264, IETF, June 2002. Collision-Resistance", http://eprint.iacr.org/2006/043.pdf,
November 2005.
[37] IANA MIKEY Payload Name Spaces per [RFC3830], see [33] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "An
http://www.iana.org/assignments/mikey-payloads additional mode of key Distribution in MIKEY: MIKEY-RSA-R",
Work in Progress, August 2006.
Appendix A Usage of MIKEY-DHHMAC in H.235 Appendix A. Usage of MIKEY-DHHMAC in H.235
This appendix provides informative overview how MIKEY-DHHMAC can be This appendix provides informative overview how MIKEY-DHHMAC can be
applied in some H.323-based multimedia environments. Generally, applied in some H.323-based multimedia environments. Generally,
MIKEY is applicable for multimedia applications including IP MIKEY is applicable for multimedia applications including IP
telephony. [22] describes various use cases of the MIKEY key telephony. [15] describes various use cases of the MIKEY key
management protocols (MIKEY-PS, MIKEY-PK, MIKEY-DHSIGN and MIKEY- management protocols (MIKEY-PS, MIKEY-PK, MIKEY-DHSIGN and MIKEY-
DHHMAC) with the purpose to establish TGK keying material among DHHMAC) with the purpose to establish TGK keying material among H.323
H.323 endpoints. The TGKs are then used for media encryption by endpoints. The TGKs are then used for media encryption by applying
applying SRTP [27]. Addressed scenarios include point-to-point with SRTP [20]. Addressed scenarios include point-to-point with one or
one or more intermediate gatekeepers (trusted or partially trusted) more intermediate gatekeepers (trusted or partially trusted) in
in-between. between.
One particular use case addresses MIKEY-DHHMAC to establish a media One particular use case addresses MIKEY-DHHMAC to establish a media
connection from an endpoint B calling (through a gatekeeper) to connection from an endpoint B calling (through a gatekeeper) to
another endpoint A that is located within that same gatekeeper zone. 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, While EP-A and EP-B typically do not share any auth_key a priori,
some separate protocol exchange means are achieved outside the some separate protocol exchange means are achieved outside the actual
actual call setup procedure to establish an auth_key for the time call setup procedure to establish an auth_key for the time while
while endpoints are being registered with the gatekeeper; such endpoints are being registered with the gatekeeper; such protocols
protocols exist [22] but are not shown in this document. The exist [15] but are not shown in this document. The auth_key between
auth_key between the endpoints is being used to authenticate and the endpoints is being used to authenticate and integrity protect the
integrity protect the MIKEY-DHHMAC messages. MIKEY-DHHMAC messages.
To establish a call, it is assumed that endpoint B has obtained To establish a call, it is assumed that endpoint B has obtained
permission from the gatekeeper (not shown). Endpoint B as the permission from the gatekeeper (not shown). Endpoint B as the caller
caller builds the MIKEY-DHHMAC I_message(see section 3) and sends builds the MIKEY-DHHMAC I_message (see section 3) and sends the
the I_message encapsulated within the H.323-SETUP to endpoint A. A I_message encapsulated within the H.323-SETUP to endpoint A. A
routing gatekeeper (GK) would forward this message to endpoint B; in routing gatekeeper (GK) would forward this message to endpoint B; in
case of a non-routing gatekeeper, endpoint B sends the SETUP case of a non-routing gatekeeper, endpoint B sends the SETUP directly
directly to endpoint A. In either case, H.323 inherent security to endpoint A. In either case, H.323 inherent security mechanisms
mechanisms [28] are applied to protect the (encapsulation) message [21] are applied to protect the (encapsulation) message during
during transfer. This is not depicted here. The receiving endpoint transfer. This is not depicted here. The receiving endpoint A is
A is able to verify the conveyed I_message and can compute a TGK. 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 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 MIKEY-DHHMAC R_message and sends the response as part of the
CallProceeding-to-Connect message back to the calling endpoint B CallProceeding-to-Connect message back to the calling endpoint B
(possibly through a routing gatekeeper). Endpoint B processes the (possibly through a routing gatekeeper). Endpoint B processes the
conveyed R_message to compute the same TGK as the called endpoint A. 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]) 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 [, 2.) EP-A -> (GK) -> EP-B: CallProceeding-to-CONNECT(R_fwd_message
R_rev_message]) [, R_rev_message])
Notes: If it is necessary to establish directional TGKs for full- Notes: If it is necessary to establish directional TGKs for full-
duplex links in both directions B->A and A->B, then the duplex links in both directions B->A and A->B, then the
calling endpoint B instantiates the DHHMAC protocol twice: calling endpoint B instantiates the DHHMAC protocol twice:
once in the direction B->A using I_fwd_message and another once in the direction B->A using I_fwd_message and another run
run in parallel in the direction A->B using I_rev_message. in parallel in the direction A->B using I_rev_message. In
In that case, two MIKEY-DHHMAC I_messages are encapsulated that case, two MIKEY-DHHMAC I_messages are encapsulated within
within SETUP (I_fwd_message and I_rev_message) and two SETUP (I_fwd_message and I_rev_message) and two MIKEY-DHHMAC
MIKEY-DHHMAC R_messages (R_fwd_message and R_rev_message) R_messages (R_fwd_message and R_rev_message) are encapsulated
are encapsulted within CallProceeding-to-CONNECT. The within CallProceeding-to-CONNECT. The I_rev_message
I_rev_message corresponds with the I_fwd_message. corresponds with the I_fwd_message. Alternatively, the called
Alternatively, the called endpoint A may instantiate the endpoint A may instantiate the DHHMAC protocol in a separate
DHHMAC protocol in a separate run with endpoint B (not run with endpoint B (not shown); however, this requires a
shown); however, this requires a third handshake to third handshake to complete.
complete.
For more details on how the MIKEY protocols may be deployed For more details on how the MIKEY protocols may be deployed
with H.235, please refer to [22]. 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
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2006).
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. 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 This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Rights Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed to
to pertain to the implementation or use of the technology described pertain to the implementation or use of the technology described in
in this document or the extent to which any license under such this document or the extent to which any license under such rights
rights might or might not be available; nor does it represent that might or might not be available; nor does it represent that it has
it has made any independent effort to identify any such rights. made any independent effort to identify any such rights. Information
Information on the procedures with respect to rights in RFC on the procedures with respect to rights in RFC documents can be
documents can be found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use attempt made to obtain a general license or permission for the use of
of such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository specification can be obtained from the IETF on-line IPR repository at
at http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Expiration Date Acknowledgement
This Internet Draft expires on 30 October 2005.
[Note to the RFC editor: Please remove the entire following section
prior to publication.]
Revision History
Changes against draft-ietf-msec-mikey-dhhmac-10.txt:
* A few editorial bugs removed.
* References updated.
Changes against draft-ietf-msec-mikey-dhhmac-09.txt:
*IESG review feedback incorporated; generally, only editorial
corrections.
* Section 2.1.1 moved into new Appendix A.
* IANA considerations section reworked and clarified.
Changes against draft-ietf-msec-mikey-dhhmac-08.txt:
* PKIX removed; some minor editorials.
Changes against draft-ietf-msec-mikey-dhhmac-07.txt:
* Feedback addressed from AD review.
* added considerations on the possible impact of PKIX protocols and
operations to end systems with real-time constraints (section 1).
* added note that DH group is transmitted explicitly but not the
parameters g and p; see section 3.
* added considerations on clock synchronization and timestamps in
section 2 and in section 5.3 in the view of consequences on replay
protection.
* references updated.
* editorial corrections and cleanup.
Changes against draft-ietf-msec-mikey-dhhmac-06.txt:
* Abstract reworded.
* used new RFC boilerplate: changed/moved IPR statement (now at
the beginning), status of Memo, and Intellectual Property Rights
section in accordance with RFC 3667, RFC 3668.
* ID nits removal.
* References updated.
* Note added to section 4.1 explaining how to differentiate
between MIKEY and DHHMAC.
* New section 4.4 added that describes the use of the general
extension payload to avoid bidding-down attacks.
* Description of the bidding-down avoidance mechanism removed from
the threat model in section 5.2.
* IANA considerations section re-written and aligned with MIKEY.
* Open issue on KMID pointed in IANA considerations section.
* editorial clean-up.
Changes against draft-ietf-msec-mikey-dhhmac-05.txt:
* HMAC-SHA1-96 option removed (see section 1.2, 4.2, 5.3,). This
option does not really provide much gain; removal reduces
number
of options.
* IDr added to I_message for DoS protection of the recipient; see
section 3, 3.1, 5.3.
* References updated.
Changes against draft-ietf-msec-mikey-dhhmac-04.txt:
* Introduction section modified: PFS property of DH, requirement
for 4th MIKEY key management variant motivated.
* MIKEY-DHSIGN, MIKEY-PK and MIKEY-PS added to section 1.2
Abbreviations.
* Note on secure time synchronization added to section 2.0.
* New section 2.2 "Relation to GMKARCH" added.
* New section 2.1.1 "Usage in H.235" added: this section outlines
a use case of DHHMAC in the context of H.235.
* Trade-off between identity-protection and security & performance
added to section 5.1.
* New section 5.6 "Authorization and Trust Model" added.
* Some further informative references added.
Changes against draft-ietf-msec-mikey-dhhmac-03.txt:
* RFC 3552 available; some references updated.
Changes against draft-ietf-msec-mikey-dhhmac-02.txt:
* text allows both random and pseudo-random values.
* exponentiation ** changed to ^.
* Notation aligned with MIKEY-07.
* Clarified that the HMAC is calculated over the entire MIKEY
message excluding the MAC field.
* Section 4.2: The AES key wrap method SHALL not be applied.
* Section 1: Relationship with other, existing work mentioned.
Changes against draft-ietf-msec-mikey-dhhmac-01.txt:
* bidding-down attacks addressed (see section 5.2).
* optional [X], [X, Y] defined and clarified (see section 1.1,
5.3).
* combination of options defined in key update procedure (see
section 3.1).
* ID payloads clarified (see section 3 and 5.2).
* relationship with MIKEY explained (roundtrip, performance).
* new section 2.1 on applicability of DHHMAC for SIP/SDP and
H.323 added.
* more text due to DH resolution incorporated in section 5.3
regarding PFS, security robustness of DH, generalization
capability of DH to general groups in particular EC and
"future-proofness".
* a few editorials and nits.
* references adjusted and cleaned-up.
Changes against draft-ietf-msec-mikey-dhhmac-00.txt:
* category set to proposed standard.
* identity protection clarified.
* aligned with MIKEY-05 DH protocol, notation and with payload
* some editorials and nits.
Changes against draft-euchner-mikey-dhhmac-00.txt:
* made a MSEC WG draft
* aligned with MIKEY-03 DH protocol, notation and with payload
formats
* clarified that truncated HMAC actually truncates the HMAC result
rather than the SHA1 intermediate value.
* improved security considerations section completely rewritten in
the spirit of [8].
* IANA consideration section added
* a few editorial improvements and corrections
* IPR clarified and IPR section changed.
Author's Addresses
Martin Euchner
Email: martin_euchner@hotmail.com
Phone: +49 89 722 55790 Hofmannstr. 51
Fax: +49 89 722 62366
81359 Munich, Germany Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 224 change blocks. 
835 lines changed or deleted 683 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/