draft-ietf-msec-mikey-dhhmac-07.txt   draft-ietf-msec-mikey-dhhmac-08.txt 
Internet Engineering Task Force - MSEC WG Internet Engineering Task Force - MSEC WG
Internet Draft M. Euchner Internet Draft M. Euchner
Intended Category: Proposed Standard Intended Category: Proposed Standard
Expires: March 2005 October 2004 Expires: July 2005 January 2005
HMAC-authenticated Diffie-Hellman for MIKEY HMAC-authenticated Diffie-Hellman for MIKEY
<draft-ietf-msec-mikey-dhhmac-07.txt> <draft-ietf-msec-mikey-dhhmac-08.txt>
IPR Statement IPR Statement
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668. disclosed, in accordance with RFC 3668.
The author believes to be aware of related intellectual property
rights presumably currently being held by Infineon. Pursuant to the
provisions of [RFC3668], the author represents that he has disclosed
the existence of any proprietary or intellectual property rights in
the contribution that are reasonably and personally known to the
author. The author does not represent that he personally knows of
all potentially pertinent proprietary and intellectual property
rights owned or claimed by the organizations he represents or third
parties.
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than a "work in progress." material or to cite them other than a "work in progress."
HMAC-authenticated Diffie-Hellman for MIKEY October 2004
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Comments should be sent to the MSEC WG mailing list at Comments should be sent to the MSEC WG mailing list at
msec@securemulticast.org and to the author. msec@securemulticast.org and to the author.
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
Abstract Abstract
This document describes a light-weight point-to-point key management This document describes a light-weight 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 a establishment featuring perfect forward secrecy in conjunction with 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
skipping to change at page 2, line 38 skipping to change at page 2, line 29
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [2]. document are to be interpreted as described in RFC-2119 [2].
Table of Contents Table of Contents
1. Introduction..................................................3 1. Introduction..................................................3
1.1. Definitions.................................................6 1.1. Definitions.................................................6
1.2. Abbreviations...............................................6 1.2. Abbreviations...............................................7
2. Scenario......................................................7 2. Scenario......................................................8
2.1. Applicability...............................................8 2.1. Applicability...............................................9
2.2. Relation to GKMARCH........................................10 2.2. Relation to GKMARCH........................................11
3. DHHMAC Security Protocol.....................................10 3. DHHMAC Security Protocol.....................................11
3.1. TGK re-keying..............................................13
HMAC-authenticated Diffie-Hellman for MIKEY October 2004 4. DHHMAC payload formats.......................................14
4.1. Common header payload (HDR)................................15
4.2. Key data transport payload (KEMAC).........................16
4.3. ID payload (ID)............................................16
4.4. General Extension Payload..................................16
5. Security Considerations......................................17
5.1. Security environment.......................................17
5.2. Threat model...............................................17
5.3. Security features and properties...........................20
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
3.1. TGK re-keying..............................................12 5.4. Assumptions................................................25
4. DHHMAC payload formats.......................................13 5.5. Residual risk..............................................25
4.1. Common header payload (HDR)................................14 5.6. Authorization and Trust Model..............................27
4.2. Key data transport payload (KEMAC).........................15 6. Acknowledgments............................................27
4.3. ID payload (ID)............................................15 Conclusions.....................................................27
4.4. General Extension Payload..................................15 7. IANA considerations..........................................28
5. Security Considerations......................................16 8. References...................................................28
5.1. Security environment.......................................16 8.1 Normative References.......................................28
5.2. Threat model...............................................16 8.2 Informative References.....................................29
5.3. Security features and properties...........................19 Full Copyright Statement........................................31
5.4. Assumptions................................................23 Expiration Date.................................................32
5.5. Residual risk..............................................24 Revision History................................................33
5.6. Authorization and Trust Model..............................25 Author's Addresses..............................................35
6. IANA considerations..........................................25
7. References...................................................27
7.1. Normative References.......................................27
7.2. Informative References.....................................27
8. Acknowledgments..............................................29
1. Introduction 1. 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 [14] 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 [24], [25]. 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.
skipping to change at page 4, line 4 skipping to change at page 3, line 42
scheme that cares for how to securely and efficiently establish scheme that cares for how to securely and efficiently establish
dynamic session keys in a conversational multimedia scenario. dynamic session keys 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 - a symmetric key distribution protocol (MIKEY-PS) based upon
pre-shared master keys; pre-shared master keys;
- a public-key encryption-based key distribution protocol - a public-key encryption-based key distribution protocol
HMAC-authenticated Diffie-Hellman for MIKEY October 2004
(MIKEY-PK) assuming a public-key infrastructure with RSA-based (MIKEY-PK) assuming a public-key infrastructure with RSA-based
(Rivest, Shamir and Adleman) private/public keys and digital (Rivest, Shamir and Adleman) private/public keys and digital
certificates; certificates;
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
- and a Diffie-Hellman key agreement protocol (MIKEY-DHSIGN) - and a Diffie-Hellman key agreement protocol (MIKEY-DHSIGN)
deploying digital signatures and certificates. deploying digital signatures and certificates.
All these three key management protocols are designed such that they All these three key management protocols are designed such 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 [7] that each of the three key management
skipping to change at page 4, line 46 skipping to change at page 4, line 41
specific limitation in less trusted environments. specific limitation in less trusted environments.
- The public-key encryption scheme (MIKEY-PK) depends upon a - The public-key encryption scheme (MIKEY-PK) depends upon a
public-key infrastructure that certifies the private-public public-key infrastructure that certifies the private-public
keys by issuing and maintaining digital certificates. While keys by issuing and maintaining digital certificates. While
such a key management scheme provides full scalability in large such a key management scheme provides full scalability in large
networked configurations, public-key infrastructures are still networked configurations, public-key infrastructures are still
not widely available and in general, implementations are not widely available and in general, implementations are
significantly more complex. significantly more complex.
Further, additional round trips might be necessary for each Further, additional round trips and computational processing
side in order to ascertain verification of the digital might be necessary for each end system in order to ascertain
certificates. verification of the digital certificates. For example, typical
PKIX operations such as validating of digital certificates (RFC
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
HMAC-authenticated Diffie-Hellman for MIKEY October 2004 3029, [31]), ascertaining the revocation status of digital
certificates (RFC 2560, [30]) and asserting certificate
policies, construction of certification path(s) ([33]),
requesting and obtaining necessary certificates (RFC 2511,
[32]) and management of certificates for such purposes ([29])
may involve extra network communication handshakes with the
public-key infrastructure and with certification authorities
and may typically involve additional processing steps in the
end systems. Such steps and tasks all result in further delay
of the key agreement or key establishment phase among the end
systems, negatively impacting setup time. Any extra PKI
handshakes and processing are not in scope of MIKEY and since
this document deploys symmetric security mechanisms only,
aspects of PKI, digital certificates and related processing are
not further covered in 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 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 of the Diffie-Hellman half-keys in each direction by exchange of the Diffie-Hellman half-keys in each direction by
using a digital signature upon. As in the previous method, using a digital signature. As in the previous method, this
this introduces the dependency upon a public-key infrastructure introduces the dependency upon a public-key infrastructure with
with its strength on scalability but also the limitations on its strength on scalability but also the limitations on
computational costs in performing the asymmetric long-integer computational costs in performing the asymmetric long-integer
operations and the potential need for additional communication operations and the potential need for additional communication
for verification of the digital certificates. for verification of the digital certificates.
However, the Diffie-Hellman key agreement protocol is known for However, the Diffie-Hellman key agreement protocol is known for
its subtle security strengths in that it is able to provide its subtle security strengths in that it is able to provide
full perfect forward secrecy (PFS) and further have both full perfect forward secrecy (PFS) and further have both
parties actively involved in session key generation. This parties actively involved in session key generation. This
special security property - despite the somewhat higher special security property - despite the somewhat higher
computational costs - makes Diffie-Hellman techniques computational 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
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
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 such a fourth light-weight key management
scheme for MIKEY that could somehow be seen as a synergetic scheme for MIKEY that could somehow be seen as a synergetic
optimization between the pre-shared key distribution scheme and the optimization between the pre-shared key distribution scheme and the
Diffie-Hellman key agreement. Diffie-Hellman key agreement.
The idea of that protocol is to apply the Diffie-Hellman key The idea of that protocol is to apply the Diffie-Hellman key
agreement but instead of deploying a digital signature for agreement but instead of deploying a digital signature for
authenticity of the exchanged keying material rather uses a keyed- authenticity of the exchanged keying material rather uses a keyed-
hash upon using symmetrically pre-assigned shared secrets. This hash upon using symmetrically pre-assigned shared secrets. This
combination of security mechanisms is called the HMAC-authenticated combination of security mechanisms is called the HMAC-authenticated
Diffie-Hellman (DH) key agreement for MIKEY (DHHMAC). Diffie-Hellman (DH) key agreement for MIKEY (DHHMAC).
HMAC-authenticated Diffie-Hellman for MIKEY October 2004
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
skipping to change at page 6, line 31 skipping to change at page 7, line 5
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 [3] section 3.3; however, the DHHMAC protocol is applicable in
general to other appropriate finite, cyclical groups as well. general 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 [3] sections 4.1.3 and 4.1.5.
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
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 circumstance MAY allow X being optional and not be present thereby
resulting in weaker security potentially. Likewise [X, Y] represents resulting in weaker security potentially. Likewise [X, Y] represents
an optional compound piece of information where the pieces X and Y an optional compound piece of information where the pieces X and Y
SHOULD be either both present or MAY optionally be both absent. SHOULD be either both present or MAY optionally be both 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 Initiatior DHi public Diffie-Hellman half key g^(xi) of the
DHr public Diffie-Hellman half key g^(xr) of Responder Initiatior
DHr public Diffie-Hellman half key g^(xr) of the
Responder
DHHMAC HMAC-authenticated Diffie-Hellman DHHMAC HMAC-authenticated Diffie-Hellman
DoS Denial-of-service DoS Denial-of-service
HMAC-authenticated Diffie-Hellman for MIKEY October 2004
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
PKIX Public-key Infrastructure Operation
PRF MIKEY pseudo-random function (see [3] section PRF MIKEY pseudo-random function (see [3] section
4.1.3.) 4.1.3.)
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
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
skipping to change at page 8, line 5 skipping to change at page 8, line 27
Initiator Initiator
xr secret, (pseudo) random Diffie-Hellman key of the xr secret, (pseudo) random Diffie-Hellman key of the
Responder Responder
2. Scenario 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.
HMAC-authenticated Diffie-Hellman for MIKEY October 2004
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 available. Rather, pre-
shared master secrets are assumed available among the entities in shared master secrets are assumed available among the entities in
such an environment. 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 it's peer using the DH- up a session key for its outgoing links with it's peer using the DH-
MAC key agreement protocol. MAC key agreement protocol.
As is the case for the other three MIKEY key management protocol, As is the case for the other three MIKEY key management protocol,
DHHMAC assumes loosely synchronized clocks among the entities in the DHHMAC assumes loosely synchronized clocks among the entities in the
small group. small group.
Note: To synchronize the clocks in a secure manner, some operational Note: To synchronize the clocks in a secure manner, some operational
or procedural means are recommended. However, MIKEY-DHHMAC does not or procedural means are recommended. However, MIKEY-DHHMAC does not
describe any secure time synchronization measures and leaves such describe any secure time synchronization measures and leaves such
tasks to the discretion of the implementation. tasks to the discretion of the implementation. The reader is
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
referred to [3] section 5.4 and [3] section 9.3 that give guidance on
clock synchronization and timestamps.
2.1. Applicability 2.1. Applicability
MIKEY-DHHMAC as well as the other MIKEY key management protocols are MIKEY-DHHMAC as well as the other MIKEY key management protocols are
optimized and targeted for the purpose of multimedia applications optimized and targeted for the purpose of multimedia applications
with application-level key management needs under real-time session with application-level key management needs under real-time session
setup and session management constraints. setup and session 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
skipping to change at page 9, line 5 skipping to change at page 9, line 33
b) H.323 (see [22]) where the encoded MIKEY messages are transported b) H.323 (see [22]) where the encoded MIKEY messages are transported
in the H.225.0 fast start call signaling handshake. in the H.225.0 fast start call signaling handshake.
MIKEY-DHHMAC is offered as option to the other MIKEY key management MIKEY-DHHMAC is offered as option to the other MIKEY key management
variants (MIKEY-pre-shared, MIKEY-public-key and MIKEY-DH-SIGN) for variants (MIKEY-pre-shared, MIKEY-public-key and MIKEY-DH-SIGN) for
all those cases where DHHMAC has its peculiar strengths (see section all those cases where DHHMAC has its peculiar strengths (see section
5). 5).
2.1.1. Usage in H.235 2.1.1. Usage in H.235
HMAC-authenticated Diffie-Hellman for MIKEY October 2004
This section provides informative overview how MIKEY-DHHMAC can be This section 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. [22] 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 H.323 DHHMAC) with the purpose to establish TGK keying material among H.323
endpoints. The TGKs are then used for media encryption by applying endpoints. The TGKs are then used for media encryption by applying
SRTP [27]. Addressed scenarios include point-to-point with one or SRTP [27]. Addressed scenarios include point-to-point with one or
more intermediate gatekeepers (trusted or partially trusted) in- more intermediate gatekeepers (trusted or partially trusted) 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
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
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 actual some separate protocol exchange means are achieved outside the actual
call setup procedure to establish an auth_key for the time while call setup procedure to establish an auth_key for the time while
endpoints are being registered with the gatekeeper; such protocols endpoints are being registered with the gatekeeper; such protocols
exist [22] but are not shown in this document. The auth_key between exist [22] but are not shown in this document. The auth_key between
the endpoints is being used to authenticate and integrity protect the the endpoints is being used to authenticate and 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
skipping to change at page 9, line 45 skipping to change at page 10, line 32
[28] are applied to protect the (encapsulation) message during [28] are applied to protect the (encapsulation) message during
transfer. This is not depicted here. The receiving endpoint A is transfer. This is not depicted here. The receiving endpoint 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])
HMAC-authenticated Diffie-Hellman for MIKEY October 2004
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 in parallel in the direction A->B using I_rev_message. run in parallel in the direction A->B using I_rev_message.
In that case, two MIKEY-DHHMAC I_messages are encapsulated In that case, two MIKEY-DHHMAC I_messages are encapsulated
within SETUP (I_fwd_message and I_rev_message) and two within SETUP (I_fwd_message and I_rev_message) and two
MIKEY-DHHMAC R_messages (R_fwd_message and R_rev_message) MIKEY-DHHMAC R_messages (R_fwd_message and R_rev_message)
are encapsulted within CallProceeding-to-CONNECT. The are encapsulted within CallProceeding-to-CONNECT. The
I_rev_message corresponds with the I_fwd_message. I_rev_message corresponds with the I_fwd_message.
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
Alternatively, the called endpoint A may instantiate the Alternatively, the called endpoint A may instantiate the
DHHMAC protocol in a separate run with endpoint B (not DHHMAC protocol in a separate run with endpoint B (not
shown); however, this requires a third handshake to shown); however, this requires a 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 [22].
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) [26] 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 [3] section 2.4. The
main entities involved in the architecture are a group controller/key main entities involved in the architecture are a group
server (GCKS), the receiver(s), and the sender(s). Due to the pair- controller/key server (GCKS), the receiver(s), and the sender(s).
wise nature of the Diffie-Hellman operation and the 1-roundtrip Due to the pair-wise nature of the Diffie-Hellman operation and the
constraint, usage of MIKEY-DHHMAC rules out any deployment as a group 1-roundtrip constraint, usage of MIKEY-DHHMAC rules out any
key management protocol with more than two group entities. Only the deployment as a group key management protocol with more than two
degenerate case with two peers is possible where for example the group entities. Only the degenerate case with two peers is
responder acts as the group controller. possible where for example the responder acts as the group
controller.
Note that MIKEY does not provide re-keying in the GKMARCH sense, only Note that MIKEY does not provide re-keying in the GKMARCH sense,
updating of the keys by normal unicast messages. only updating of the keys by normal unicast messages.
3. DHHMAC Security Protocol 3. 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
HMAC-authenticated Diffie-Hellman for MIKEY October 2004
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
<---------------------- <----------------------
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
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, then 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. The responder chooses a (pseudo) random chosen by the initiator. Note, that like in the MIKEY protocol,
positive integer xr, and sends an HMACed message including g^(xr) both sender and receiver explicitly transmit the Diffie-Hellman
and the timestamp to the initiator. The responder SHALL always group G within the Diffie-Hellman payload DHi or DHr through an
include the initiator's identity IDi regardless of whether the encoding (e.g., OAKELEY group numbering, see [3] section 6.4); the
I_message conveyed any IDi. It is RECOMMENDED that the responder actual group parameters g and p however are not explicitly
SHOULD always include the identity payload IDr within the transmitted but can be deduced from the Diffie-Hellman group G.
R_message; unless the initiator can defer the reponder's identity The responder chooses a (pseudo) random positive integer xr, and
by some other means, then IDr MAY optionally be left out. sends an HMACed message including g^(xr) and the timestamp to the
initiator. The responder SHALL always include the initiator's
identity IDi regardless of whether the I_message conveyed any IDi.
It is RECOMMENDED that the responder SHOULD always include the
identity payload IDr within the R_message; unless the initiator can
defer the reponder's identity by some other means, then IDr MAY
optionally be left 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, and is necessary to avoid man-in-the-middle attacks. keys, and is necessary to avoid man-in-the-middle attacks.
HMAC-authenticated Diffie-Hellman for MIKEY October 2004
This approach is less expensive than digitally signed Diffie- This approach is less expensive than digitally signed Diffie-
Hellman. It requires first of all, that both sides compute one Hellman. It requires first of all, that both sides compute one
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
exponentiation and one HMAC, then one HMAC verification and finally exponentiation and one HMAC, then one HMAC verification and finally
another Diffie-Hellman exponentiation. another Diffie-Hellman 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 further reduce the overall round trip delay as well as reduce MAY further reduce the overall round trip delay as well as reduce
the risk of denial-of-service attacks. the risk of 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
[3] chapter 4. [3] chapter 4.
skipping to change at page 12, line 35 skipping to change at page 13, line 32
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 [3]
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
<---------------------- <----------------------
Figure 2: DHHMAC update message Figure 2: DHHMAC update message
HMAC-authenticated Diffie-Hellman for MIKEY October 2004
TGK re-keying supports two procedures: TGK re-keying supports two procedures:
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
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 the responder SHALL respond with a new, fresh DHr and the and the responder SHALL respond with a new, fresh DHr and the
received DHi. received DHi.
b) Non-key related information update without any Diffie-Hellman b) Non-key related information update without any Diffie-Hellman
half-keys included in the exchange. Such transaction does not half-keys included in the exchange. Such transaction does not
change the actual TGK but updates other information like change the actual TGK but updates other information like
security policy parameters for example. To only update the security policy parameters for example. To only update the
non-key related information, [DHi] and [DHr, DHi] SHALL be left non-key related information, [DHi] and [DHr, DHi] SHALL be left
skipping to change at page 14, line 4 skipping to change at page 15, line 4
* Timestamp payload, [3] section 6.6 * Timestamp payload, [3] section 6.6
* ID payload, [3] section 6.7 * ID payload, [3] section 6.7
* Security Policy payload (SP), [3] section 6.10 * Security Policy payload (SP), [3] section 6.10
* RAND payload (RAND), [3] section 6.11 * RAND payload (RAND), [3] section 6.11
* Error payload (ERR), [3] section 6.12 * Error payload (ERR), [3] section 6.12
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
HMAC-authenticated Diffie-Hellman for MIKEY October 2004
* General Extension Payload, [3] section 6.15 * General Extension Payload, [3] 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 [3] section 6.1, for DHHMAC the following data types
SHALL be used: SHALL be used:
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 [3] section 6.12
Table 4.1.a Table 4.1.a
Note: A responder is able to recognize the MIKEY DHHMAC protocol by Note: A responder is able to recognize the MIKEY DHHMAC protocol
evaluating the data type field as 7 or 8. This is how the responder by evaluating the data type field as 7 or 8. This is how the
can differentiate between MIKEY and MIKEY DHHMAC. responder 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 [3] section 6.2
DH | 3 | [3] section 6.4 DH | 3 | [3] section 6.4
T | 5 | [3] section 6.6 T | 5 | [3] section 6.6
ID | 6 | [3] section 6.7 ID | 6 | [3] section 6.7
SP | 10 | [3] section 6.10 SP | 10 | [3] section 6.10
RAND | 11 | [3] section 6.11 RAND | 11 | [3] section 6.11
ERR | 12 | [3] section 6.12 ERR | 12 | [3] section 6.12
General Ext.| 21 | [3] section 6.15 General Ext.| 21 | [3] 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 [3] SHALL not be
applied to DHHMAC. applied to DHHMAC.
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
The responder in case of a decoding error or of a failed HMAC The responder in case of a decoding error or of a failed HMAC
authentication verification SHALL apply the Error payload data authentication verification SHALL apply the Error payload data
type. type.
HMAC-authenticated Diffie-Hellman for MIKEY October 2004
4.2. Key data transport payload (KEMAC) 4.2. Key data transport payload (KEMAC)
DHHMAC SHALL apply this payload for conveying the HMAC result along DHHMAC SHALL apply this payload for conveying the HMAC result along
with the indicated authentication algorithm. KEMAC when used in with the indicated authentication algorithm. KEMAC when used in
conjunction with DHHMAC SHALL not convey any encrypted data; thus conjunction with DHHMAC SHALL not convey any encrypted data; thus
Encr alg SHALL be set to 2 (NULL), Encr data len SHALL be set to 0 Encr alg SHALL be set to 2 (NULL), Encr data len SHALL be set to 0
and Encr data SHALL be left empty. The AES key wrap method (see and Encr data SHALL be left empty. The AES key wrap method (see
[23]) SHALL not be applied for DHHMAC. [23]) 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
skipping to change at page 15, line 30 skipping to change at page 16, line 34
in [3] section 5.2 and then stored within MAC field. in [3] section 5.2 and then stored within 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 [4])
NULL | 1 | Very restricted use, see NULL | 1 | Very restricted use, see
| [3] section 4.2.4 | [3] section 4.2.4
Table 4.2.a Table 4.2.a
HMAC-SHA-1 is the default hash function that SHALL 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
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
For DHHMAC and to avoid bidding-down attacks, this payload SHALL For DHHMAC and to avoid bidding-down attacks, this payload SHALL
list all key management protocol identifiers of a surrounding list all key management protocol identifiers of a surrounding
encapsulation protocol such as for example, SDP [5]. The General encapsulation protocol such as for example, SDP [5]. The General
Extension Payload SHALL be integrity-protected with the HMAC using Extension Payload SHALL be integrity-protected with the HMAC using
the shared secret. the shared secret.
HMAC-authenticated Diffie-Hellman for MIKEY October 2004
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 [5]); see also [3] section 6.15.
Table 4.4.a Table 4.4.a
5. Security Considerations 5. 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,
skipping to change at page 16, line 32 skipping to change at page 17, line 37
5.1. Security environment 5.1. Security environment
Generally, the DHHMAC security protocol described in this document Generally, the DHHMAC security protocol described in this document
focuses primarily on communication security; i.e. the security issues focuses 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 of interest as well that are not explicitly
defined by the DHHMAC protocol, but should be provided locally in defined by the DHHMAC protocol, but should be provided locally in
practice. practice.
The system where the DHHMAC protocol entity runs upon SHALL provide The system that runs the DHHMAC protocol entity SHALL provide the
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 [9], [15]). Furthermore, the system
SHALL be capable of storing the generated (pseudo) random data, SHALL be capable of storing the generated (pseudo) random data,
secret data, keys and other secret security parameters securely (i.e. secret data, 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
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
The threat model that this document adheres to cover the issues of The threat model that this document adheres to cover the issues of
end-to-end security in the Internet generally; without ruling out the end-to-end security in the Internet generally; without ruling out the
possibility that MIKEY DHHMAC be deployed in a corporate, closed IP possibility that MIKEY DHHMAC be deployed in a corporate, closed IP
environment. This also includes the possibility that MIKEY DHHMAC be environment. This also includes the possibility that MIKEY DHHMAC be
deployed on a hop-by-hop basis with some intermediate trusted "MIKEY deployed on a hop-by-hop basis with some intermediate trusted "MIKEY
DHHMAC proxies" involved. DHHMAC proxies" involved.
HMAC-authenticated Diffie-Hellman for MIKEY October 2004
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 does not occur since the TGK is not actually For DHHMAC this threat does not occur since the TGK is not actually
transmitted on the wire (not even in encrypted fashion). transmitted on the wire (not even in encrypted fashion).
* Eavesdropping of other, transmitted keying information: * Eavesdropping of other, transmitted keying information:
DHHMAC protocol does not explicitly transmit the TGK at all. DHHMAC protocol does not explicitly transmit the TGK at all.
Rather, by the Diffie-Hellman "encryption" operation, that conceals Rather, by the Diffie-Hellman "encryption" operation, that conceals
skipping to change at page 17, line 41 skipping to change at page 19, line 4
* Man-in-the-middle attacks: * Man-in-the-middle attacks:
Such attacks threaten the security of exchanged, non-authenticated Such attacks threaten the security of exchanged, non-authenticated
messages. Man-in-the-middle attacks usually come with masquerade messages. Man-in-the-middle attacks usually come with masquerade
and or loss of message integrity (see below). Man-in-the-middle and or loss of message integrity (see below). Man-in-the-middle
attacks must be avoided, and if present or attempted must be attacks must be avoided, and if present or attempted must be
detected appropriately. DHHMAC addresses this threat by providing detected appropriately. DHHMAC addresses this threat by providing
mutual peer entity authentication and message integrity. mutual peer entity authentication and message integrity.
* Loss of integrity: * Loss of integrity:
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
This security threat relates to unauthorized replay, deletion, This security threat relates to unauthorized replay, deletion,
insertion and manipulation of messages. While any such attacks insertion and manipulation of messages. While any such attacks
cannot be avoided they must be detected at least. DHHMAC addresses cannot be avoided they must be detected at least. DHHMAC addresses
this threat by providing message integrity. this threat by providing message integrity.
* Bidding-down attacks: * Bidding-down attacks:
When multiple key management protocols each of a distinct security When multiple key management protocols each of a distinct security
level are offered (e.g., such as is possible by SDP [5]), avoiding level are offered (e.g., such as is possible by SDP [5]), avoiding
bidding-down attacks is of concern. DHHMAC addresses this threat bidding-down attacks is of concern. DHHMAC addresses this threat
HMAC-authenticated Diffie-Hellman for MIKEY October 2004
by reusing the MIKEY General Extension Payload mechanism, where all by reusing the MIKEY General Extension Payload mechanism, where all
key management protocol identifiers are be listed within the MIKEY key management protocol identifiers are be listed within the MIKEY
General Extension Payload. 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
be infeasible although the possibility of a successful attack be infeasible although the possibility of a successful attack
skipping to change at page 18, line 38 skipping to change at page 20, line 4
other local countermeasures should be applied. Further, some DoS other local countermeasures should be applied. Further, some DoS
attacks are not countered such as interception of a valid DH- attacks are not countered such as interception of a valid DH-
request and its massive instant duplication. Such attacks might at request and its massive instant duplication. Such attacks might at
least be countered partially by some local means that are outside least be countered partially by some local means that are outside
the scope of this document. the scope of this document.
* Identity protection: * Identity protection:
Like MIKEY, identity protection is not a major design requirement Like MIKEY, identity protection is not a major design requirement
for MIKEY-DHHMAC either, see [3]. No security protocol is known so for MIKEY-DHHMAC either, see [3]. No security protocol is known so
far, that is able to provide the objectives of DHHMAC as stated in far, that is able to provide the objectives of DHHMAC as stated in
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
section 5.3 including identity protection within just a single section 5.3 including identity protection within just a single
roundtrip. MIKEY-DHHMAC trades identity protection for better roundtrip. MIKEY-DHHMAC trades identity protection for better
security for the keying material and shorter roundtrip time. Thus, security for the keying material and shorter roundtrip time. Thus,
MIKEY-DHHMAC does not provide identity protection on its own but MIKEY-DHHMAC does not provide identity protection on its own but
may inherit such property from a security protocol underneath that may inherit such property from a security protocol underneath that
actually features identity protection. On the other hand, it is actually features identity protection. On the other hand, it is
expected that MIKEY-DHHMAC is typically being deployed within expected that MIKEY-DHHMAC is typically being deployed within
SDP/SIP ([20], [5]); both those protocols do not provide end-to-end SDP/SIP ([20], [5]); both those protocols do not provide end-to-end
identity protection either. identity protection either.
HMAC-authenticated Diffie-Hellman for MIKEY October 2004
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 of supplying trustworthy identity
information; e.g., by relying on secured links underneath of MIKEY information; e.g., by relying on secured links underneath of MIKEY
that supply trustworthy identity information otherwise. However, that supply trustworthy identity information otherwise. However,
it is understood that without identity information present, the it is understood that without identity information present, 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
skipping to change at page 19, line 34 skipping to change at page 21, line 4
With the security threats in mind, this draft provides the following With the security threats in mind, this draft provides the following
security features and yields the following properties: 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 corroborates that the host/user is authentic in This authentication corroborates that the host/user is authentic in
that possession of a pre-assigned secret key is proven using keyed that possession of a pre-assigned secret key is proven using keyed
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
HMAC. Authentication occurs on the request and on the response HMAC. Authentication occurs on the request and on the response
message, thus authentication is mutual. message, 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,
HMAC-authenticated Diffie-Hellman for MIKEY October 2004
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 achieved using a message The cryptographic integrity check is achieved using a message
digest (keyed HMAC). It includes the exchanged Diffie-Hellman digest (keyed HMAC). It includes the exchanged Diffie-Hellman
half-keys but covers the other parts of the exchanged message as half-keys but covers the other parts of the exchanged message as
well. Both mutual peer entity authentication and message integrity well. Both mutual peer entity authentication and message integrity
provide effective countermeasure against man-in-the-middle attacks. provide effective countermeasure against man-in-the-middle 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 timely. This is to detect deletion response message did not arrive timely. This is to detect deletion
of entire messages. of entire messages.
* Replay protection of the messages is achieved using embedded * Replay protection of the messages is achieved using embedded
timestamps. timestamps. In order to detect replayed messages it is essential
that the clocks among initiator and sender be roughly synchronized.
The reader is referred to [3] section 5.4 and [3] section 9.3 that
provide further considerations and give guidance on clock
synchronization and timestamp usage. Should the clock
synchronization be lost, then end systems cannot detect replayed
messages anymore resulting that the end systems cannot securely
establish keying material. This may result in a denial-of-service,
see [3] section 9.5.
* Limited DoS protection: * Limited DoS protection:
Rapid checking of the message digest allows verifying the Rapid checking of the message digest allows verifying the
authenticity and integrity of a message before launching CPU authenticity and integrity of a message before launching CPU
intensive Diffie-Hellman operations or starting other resource intensive Diffie-Hellman operations or starting other resource
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
consuming tasks. This protects against some denial-of-service consuming tasks. This protects against some denial-of-service
attacks: malicious modification of messages and spam attacks with attacks: malicious modification of messages and spam attacks with
(replayed or masqueraded) messages. DHHMAC probably does not (replayed or masqueraded) messages. DHHMAC probably does not
explicitly counter sophisticated distributed, large-scale denial- explicitly counter sophisticated distributed, large-scale denial-
of-service attacks that compromise system availability for example. of-service attacks that compromise system availability for example.
Some DoS protection is provided by inclusion of the initiator's Some DoS protection is provided by inclusion of the initiator's
identity payload in the I_message. This allows the recipient to identity payload in the I_message. This allows the recipient to
filter out those (replayed) I_messages that are not targeted for filter out those (replayed) I_messages that are not targeted for
him and avoids the recipient from creating unnecessary MIKEY him and avoids the recipient from creating unnecessary MIKEY
sessions. sessions.
skipping to change at page 21, line 4 skipping to change at page 22, line 27
* Perfect-forward secrecy (PFS): * Perfect-forward secrecy (PFS):
Other than the MIKEY pre-shared and public-key based key Other than the MIKEY pre-shared and public-key based key
distribution protocols, the Diffie-Hellman key agreement protocol distribution protocols, the Diffie-Hellman key agreement protocol
features a security property called perfect forward secrecy. That features a security property called perfect forward secrecy. That
is, that even if the long-term pre-shared key would be compromised is, that even if the long-term pre-shared key would be compromised
at some point in time, this would not render past or future session at some point in time, this would not render past or future session
keys compromised. 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-
HMAC-authenticated Diffie-Hellman for MIKEY October 2004
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 but also digitally signed DH provides a far As such, DHHMAC but also digitally signed DH provides a far
superior security level over the pre-shared or public-key based key superior security level over 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 protocol is not a strict key The Diffie-Hellman key management protocol is not a strict key
distribution protocol per se with the initiator distributing a key distribution protocol per se with the initiator distributing a key
to its peers. Actually, both parties involved in the protocol to its peers. Actually, both parties involved in the protocol
exchange are able to equally contribute to the common Diffie- exchange are able to equally contribute to the common Diffie-
Hellman TEK traffic generating key. This reduces the risk of Hellman TEK traffic generating key. This reduces the risk of
either party cheating or unintentionally generating a weak session either party cheating or unintentionally generating a weak session
key. This makes the DHHMAC a fair key agreement protocol. One may key. This makes the DHHMAC a fair key agreement protocol. One may
view this property as an additional distributed security measure view this property as an additional distributed security measure
that is increasing security robustness over the case where all the that is increasing security robustness over the case where all the
security depends just on the proper implementation of a single security depends just on the proper implementation of a single
entity. entity.
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
In order for Diffie-Hellman key agreement to be secure, each party In order for Diffie-Hellman key agreement to be secure, each party
SHALL generate its xi or xr values using a strong, unpredictable SHALL generate its xi or xr values using a strong, unpredictable
pseudo-random generator if a source of true randomness is not pseudo-random generator if a source of true randomness is not
available. Further, these values xi or xr SHALL be kept private. available. Further, these values xi or xr SHALL be kept private.
It is RECOMMENDED that these secret values be destroyed once the It is RECOMMENDED that these secret values be destroyed once the
common Diffie-Hellman shared secret key has been established. common Diffie-Hellman shared secret key has been established.
* Efficiency and performance: * Efficiency and performance:
Like the MIKEY-public key protocol, the MIKEY DHHMAC key agreement Like the MIKEY-public key protocol, the MIKEY DHHMAC key agreement
protocol securely establishes a TGK within just one roundtrip. protocol securely establishes a TGK within just one roundtrip.
Other existing key management techniques like IPSEC-IKE [14], Other existing key management techniques like IPsec-IKE [14],
IPSEC-IKEv2 [21] and TLS [13] and other schemes are not deemed IPsec-IKEv2 [21] and TLS [13] and other schemes are not deemed
adequate in addressing sufficiently those real-time and security adequate in addressing sufficiently those real-time and security
requirements; they all use more than a single roundtrip. All the requirements; they all use more than a single roundtrip. All the
MIKEY key management protocols are able to complete their task of MIKEY key management protocols are able to complete their task of
security policy parameter negotiation including key-agreement or security policy parameter negotiation including key-agreement or
key distribution in one roundtrip. However, the MIKEY pre-shared key distribution in one roundtrip. However, the MIKEY pre-shared
and the MIKEY public-key protocol both are able to complete their and the MIKEY public-key protocol both are able to complete their
task even in a half-round trip when the confirmation messages are task even in a half-round trip 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 expensive
HMAC-authenticated Diffie-Hellman for MIKEY October 2004
public-key operations. This yields a particular performance public-key operations. This yields a particular performance
benefit of DHHMAC over signed DH or the public-key encryption benefit of DHHMAC over signed DH or the public-key encryption
protocol. 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 round trip delay
either party may off-line pre-compute its public Diffie-Hellman either party may off-line pre-compute its public Diffie-Hellman
half-key. half-key.
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
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
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 As such, it can be said that DHHMAC provides sound performance when
compared with the other 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.
skipping to change at page 23, line 5 skipping to change at page 24, line 33
in MIKEY. Public-key infrastructures may not always be available in MIKEY. Public-key infrastructures may not always be available
in certain environments nor may they be deemed adequate for real- in certain environments nor may they be deemed adequate for real-
time multimedia applications when taking additional steps for time multimedia applications when taking additional steps for
certificate validation and certificate revocation methods with certificate validation and certificate revocation methods with
additional round-trips into account. additional round-trips 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 and thus is believed to be much simpler than the more
complex PKI facilities. complex PKI facilities.
HMAC-authenticated Diffie-Hellman for MIKEY October 2004
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 firewall/NAT devices as DHHMAC is able to operate smoothly through firewall/NAT devices as
long as the protected identity information of the end entity is not long as the protected identity information of the end entity is not
an IP /transport address. an IP /transport address.
* Scalability: * Scalability:
Like the MIKEY signed Diffie-Hellman protocol, DHHMAC does not Like the MIKEY signed Diffie-Hellman protocol, DHHMAC does not
scale to any larger configurations beyond peer-to-peer groups. scale to any larger configurations beyond peer-to-peer groups.
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
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. It is assumed, that
* 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.
skipping to change at page 24, line 4 skipping to change at page 25, line 36
called the discrete logarithm assumption. Please see [7], [11] or called the discrete logarithm assumption. Please see [7], [11] or
[12] for more background information regarding the Diffie-Hellman [12] 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. that it is computationally
infeasible to find a message which corresponds to a given message infeasible to find a message which 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
HMAC-authenticated Diffie-Hellman for MIKEY October 2004
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
applied to single blocks (see [6]). applied to single blocks (see [6]).
* 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
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
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 upon the properties of The mathematical and cryptographic assumptions upon the properties of
the PRF, the Diffie-Hellman algorithm (discrete log-assumption), the the PRF, the Diffie-Hellman algorithm (discrete log-assumption), the
HMAC and SHA1 algorithms have not been proved yet nor have they been HMAC and SHA1 algorithms have not been proved yet nor have they been
disproved by the time of this writing. disproved by the time of this writing.
skipping to change at page 25, line 4 skipping to change at page 26, line 35
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 computational intensive. Neverthess, and more) and thus very computational intensive. Neverthess,
elliptic curve Diffie-Hellman (ECDH) allows to cut-down key lengths elliptic curve Diffie-Hellman (ECDH) allows to cut-down key lengths
substantially (say 170 bits or more) while maintaining at least the substantially (say 170 bits or more) while maintaining at least the
HMAC-authenticated Diffie-Hellman for MIKEY October 2004
security level and providing even significant performance benefits in security level and providing even significant performance benefits in
practice. Moreover, it is believed that elliptic curve techniques practice. Moreover, it is believed that elliptic curve techniques
provide much better protection against side channel attacks due to provide much better protection against side channel attacks due to
the inherent redundancy in the projective coordinates. For all these the inherent redundancy in the projective coordinates. For all these
reasons, one may view elliptic-curve-based Diffie-Hellman as being reasons, one may view elliptic-curve-based Diffie-Hellman as being
more "future-proof" and robust against potential threats than RSA. more "future-proof" and robust against potential threats than RSA.
Note, that an elliptic-curve Diffie-Hellman variant of MIKEY remains Note, that an elliptic-curve Diffie-Hellman variant of MIKEY remains
for further study. for further study.
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
It is not recommended to deploy DHHMAC for any other usage than It is not recommended to deploy DHHMAC for any other usage than
depicted in section 2. Otherwise any such misapplication might lead depicted in section 2. Otherwise any such misapplication might lead
to unknown, undefined properties. 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 stated in [3] section
4.3.2. hold also for DHHMAC. However, as noted before, this key 4.3.2. hold also for DHHMAC. However, as noted before, this key
management protocol does not serve full groups. management protocol does not serve full groups.
skipping to change at page 25, line 40 skipping to change at page 27, line 31
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. The common group controller in conjunction with the
assumption of a shared key simplifies the communication setup of the assumption of a shared key 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. IANA considerations 6. Acknowledgments
This document does not define its own new name spaces for DHHMAC,
beyond the IANA name spaces that have been assigned for MIKEY, see
[3] section 10 and section 10.1.
HMAC-authenticated Diffie-Hellman for MIKEY October 2004 This document incorporates kindly valuable review feedback from
Steffen Fries, Hannes Tschofenig, Fredrick Lindholm and Russell
Housely and general feedback by the MSEC WG.
The name spaces for the following fields in the Common header payload Conclusions
(from Section 4.1) are requested to be managed by IANA (in bracket is
the reference to the table with the initially registered values):
* data type (Table 4.1.a); to be aligned with [3] table 6.1.a. Key management for environments and applications with real-time and
performance constraints are becoming of interest. Existing key
management techniques like IPsec-IKE [14] and IPsec-IKEv2 [22], TLS
[13] and other schemes are not deemed adequate in addressing
sufficiently those real-time and security requirements.
{editor/authorĘs note: HMAC-authenticated Diffie-Hellman for MIKEY January 2005
Open Issue: Depending on the resolution of the discussion related
with draft-ietf-mmusic-kmgmt-ext-11.txt section 8.3, on whether KMID
becomes an authenticated MIKEY protocol KMID or remains as an
overall key management protocol ID representing all MIKEY protocols,
it is noted that in the former case, a new KMID needs to be
allocated for MIKEY-DHMMAC.
The appropriate KMID to be allocated and to used in the context of MIKEY defines three key management security protocols addressing
this document shall be real-time constraints. DHHMAC as described in this document defines
"mikey-dhhmac" a fourth MIKEY variant aiming at the same target.
}
Intellectual Property Rights While each of the four key management protocols has its own merits
there are also certain limitations of each approach. As such there
is no single ideal solution and none of the variants is able to
subsume the other remaining variants.
The IETF takes no position regarding the validity or scope of It is concluded that DHHMAC features useful security and performance
any intellectual property or other rights that might be claimed properties that none of the other three MIKEY variants is able to
to pertain to the implementation or use of the technology provide.
described in this document or the extent to which any license
under such rights might or might not be available; neither does
it represent that it has made any effort to identify any such
rights. Information on the IETF's procedures with respect to
rights in standards-track and standards-related documentation
can be found in BCP-11. Copies of claims of rights made
available for publication and any assurances of licenses to
be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementors or users of this
specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its 7. IANA considerations
attention any copyrights, patents or patent applications, or
HMAC-authenticated Diffie-Hellman for MIKEY October 2004 This document does not define its own new name spaces for DHHMAC,
beyond the IANA name spaces that have been assigned for MIKEY, see
[3] section 10 and section 10.1.
The name spaces for the following fields in the Common header payload
(from Section 4.1) are requested to be managed by IANA (in bracket is
the reference to the table with the initially registered values):
other proprietary rights which may cover technology that may be * data type (Table 4.1.a); to be aligned with [3] table 6.1.a.
required to practice this standard. Please address the
information to the IETF Executive Director.
7. References 8. References
7.1. Normative References 8.1 Normative References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", [1] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996. BCP 9, RFC 2026, October 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate [2] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman; [3] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman;
"MIKEY: Multimedia Internet KEYing", RFC 3830 IETF, August 2004. "MIKEY: Multimedia Internet KEYing", RFC 3830 IETF, August 2004.
[4] NIST, FIBS-PUB 180-1, "Secure Hash Standard", April 1995, [4] NIST, FIBS-PUB 180-1, "Secure Hash Standard", April 1995,
http://csrc.nist.gov/fips/fip180-1.ps. http://csrc.nist.gov/fips/fip180-1.ps.
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
[5] J. Arkko, E. Carrara et al: "Key Management Extensions for SDP [5] J. Arkko, E. Carrara et al: "Key Management Extensions for SDP
and RTSP", Internet Draft <draft-ietf-mmusic-kmgmt-ext-11.txt>, and RTSP", Internet Draft <draft-ietf-mmusic-kmgmt-ext-11.txt>,
Work in Progress (MMUSIC WG), IETF, April 2004. Work in Progress (MMUSIC WG), IETF, April 2004.
[6] H. Krawczyk, M. Bellare, R. Canetti: "HMAC: Keyed-Hashing for [6] H. Krawczyk, M. Bellare, R. Canetti: "HMAC: Keyed-Hashing for
Message Authentication", RFC 2104, February 1997. Message Authentication", RFC 2104, February 1997.
7.2. Informative References 8.2 Informative References
[7] A.J. Menezes, P. van Oorschot, S. A. Vanstone: "Handbook of [7] 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 [8] E. Rescorla, B. Korver: " Guidelines for Writing RFC Text on
Security Considerations", RFC 3552, IETF, July 2003. Security Considerations", RFC 3552, IETF, July 2003.
[9] D. Eastlake, S. Crocker: "Randomness Recommendations for [9] D. Eastlake, S. Crocker: "Randomness Recommendations for
Security", RFC 1750, IETF, December 1994. Security", RFC 1750, IETF, December 1994.
[10] S.M. Bellovin, C. Kaufman, J. I. Schiller: "Security [10] S.M. Bellovin, C. Kaufman, J. I. Schiller: "Security
Mechanisms for the Internet", RFC 3631, IETF, December 2003. Mechanisms for the Internet", RFC 3631, IETF, December 2003.
HMAC-authenticated Diffie-Hellman for MIKEY October 2004
[11] Ueli M. Maurer, S. Wolf: "The Diffie-Hellman Protocol", [11] 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; [12] Discrete Logarithms and the Diffie-Hellman Protocol;
http://www.crypto.ethz.ch/research/ntc/dldh/ http://www.crypto.ethz.ch/research/ntc/dldh/
[13] T. Dierks, C. Allen: "The TLS Protocol Version 1.0.", RFC 2246, [13] T. Dierks, C. Allen: "The TLS Protocol Version 1.0.", RFC 2246,
IETF, January 1999. IETF, January 1999.
[14] D. Harkins, D. Carrel: "The Internet Key Exchange (IKE).", RFC [14] D. Harkins, D. Carrel: "The Internet Key Exchange (IKE).", RFC
2409, IETF, November 1998. 2409, IETF, November 1998.
[15] Donald E. Eastlake, Jeffrey I. Schiller, Steve Crocker: [15] Donald E. Eastlake, Jeffrey I. Schiller, Steve Crocker:
"Randomness Requirements for Security"; <draft-eastlake- "Randomness Requirements for Security"; <draft-eastlake-
randomness2-08.txt>; Work in Progress, IETF, August 2004. randomness2-10.txt>; Work in Progress, IETF, January 2005.
[16] J. Schiller: "Strong Security Requirements for Internet [16] J. Schiller: "Strong Security Requirements for Internet
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
Engineering Task Force Standard Protocols", RFC 3365, IETF, Engineering Task Force Standard Protocols", RFC 3365, IETF,
2002. 2002.
[17] C. Meadows: "Advice on Writing an Internet Draft Amenable to [17] C. Meadows: "Advice on Writing an Internet Draft Amenable to
Security Analysis", Work in Progress, <draft-irtf-cfrg-advice- Security Analysis", Work in Progress, <draft-irtf-cfrg-advice-
00.txt>, IRTF, October 2002. 00.txt>, IRTF, October 2002.
[18] T. Narten: "Guidelines for Writing an IANA Considerations [18] T. Narten: "Guidelines for Writing an IANA Considerations
Section in RFCs", RFC 2434, IETF, October 1998. Section in RFCs", RFC 2434, IETF, October 1998.
[19] J. Reynolds: "Instructions to Request for Comments (RFC) [19] J. Reynolds: "Instructions to Request for Comments (RFC)
Authors", Work in Progress, <draft-rfc-editor-rfc2223bis- Authors", Work in Progress, <draft-rfc-editor-rfc2223bis-
08.txt>, IETF, August 2004. 08.txt>, IETF, August 2004.
[20] J. Rosenberg et all: "SIP: Session Initiation Protocol", RFC [20] J. Rosenberg et all: "SIP: Session Initiation Protocol", RFC
3261, IETF, June 2002. 3261, IETF, June 2002.
[21] Ch. Kaufman: "Internet Key Exchange (IKEv2) Protocol", Work in [21] Ch. Kaufman: "Internet Key Exchange (IKEv2) Protocol", Work in
Progress (IPSEC WG), <draft-ietf-ipsec-ikev2-15.txt>, Internet Progress (IPSEC WG), <draft-ietf-ipsec-ikev2-17.txt>, Internet
Draft, Work in Progress (IPSEC WG). Draft, Work in Progress (IPSEC WG).
[22] Draft ITU-T Recommendation H.235 Annex G: "Usage of the MIKEY [22] ITU-T Recommendation H.235 Annex G: "Usage of the MIKEY
Key Management Protocol for the Secure Real Time Transport Key Management Protocol for the Secure Real Time Transport
Protocol (SRTP) within H.235"; 11/2004. Protocol (SRTP) within H.235"; 1/2005.
HMAC-authenticated Diffie-Hellman for MIKEY October 2004
[23] Schaad, J., Housley R.: "Advanced Encryption Standard (AES) [23] Schaad, J., Housley R.: "Advanced Encryption Standard (AES)
Key Wrap Algorithm", RFC 3394, IETF, September 2002. Key Wrap Algorithm", RFC 3394, IETF, September 2002.
[24] Baugher, M., Weis, B., Hardjono, T., Harney, H.: "The Group [24] Baugher, M., Weis, B., Hardjono, T., Harney, H.: "The Group
Domain of Interpretation", RFC 3547, IETF, July 2003. Domain of Interpretation", RFC 3547, IETF, July 2003.
[25] Harney, H., Colegrove, A., Harder, E., Meth, U., Fleischer, R.: [25] Harney, H., Colegrove, A., Harder, E., Meth, U., Fleischer, R.:
"Group Secure Association Key Management Protocol", <draft-ietf- "Group Secure Association Key Management Protocol", <draft-ietf-
msec-gsakmp-sec-06.txt>, Internet Draft, Work in Progress (MSEC msec-gsakmp-sec-07.txt>, Internet Draft, Work in Progress (MSEC
WG). WG).
[26] Baugher, M., Canetti, R., Dondeti, L., and Lindholm, F.: "Group [26] Baugher, M., Canetti, R., Dondeti, L., and Lindholm, F.: "Group
Key Management Architecture", <draft-ietf-msec-gkmarch-08.txt>, Key Management Architecture", <draft-ietf-msec-gkmarch-08.txt>,
Internet Draft, Work in Progress (MSEC WG). Internet Draft, Work in Progress (MSEC WG).
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
[27] Baugher, McGrew, Oran, Blom, Carrara, Naslund: "The Secure Real- [27] Baugher, McGrew, Oran, Blom, Carrara, Naslund: "The Secure Real-
time Transport Protocol", RFC 3711, IETF, March 2004. time Transport Protocol", RFC 3711, IETF, March 2004.
[28] ITU-T Recommendation H.235V3Amd1, "Security and encryption for [28] ITU-T Recommendation H.235V3Amd1 Corr1, "Security and encryption
H-series (H.323 and other H.245-based) multimedia terminals", for H-series (H.323 and other H.245-based) multimedia
(04/2004) terminals", (01/2005).
[29] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667,
February 2004.
[30] Bradner, S., "Intellectual Property Rights in IETF Technology",
BCP 79, RFC 3668, February 2004.
8. Acknowledgments
This document incorporates kindly review feedback by Steffen Fries
and Fredrick Lindholm, general feedback by the MSEC WG and editorial
assistance and review by Hannes Tschofenig to finalize the document.
Conclusions [29] C. Adams et al: "Internet X.509 Public Key Infrastructure
Certificate Management Protocols"; draft-ietf-pkix-rfc2510bis-
09.txt, Internet Draft, Work in Progress (PKIX WG).
Key management for environments and applications with real-time and [30] M. Myers et al: "X.509 Internet Public Key Infrastructure Online
performance constraints are becoming of interest. Existing key Certificate Status Protocol - OCSP", RFC 2560, IETF, June 1999.
management techniques like IPSEC-IKE [14] and IPSEC-IKEv2 [22], TLS
HMAC-authenticated Diffie-Hellman for MIKEY October 2004 [31] C. Adams et al: "Internet X.509 Public Key Infrastructure Data
Validation and Certification Server Protocols", RFC 3029, IETF,
February 2001.
[13] and other schemes are not deemed adequate in addressing [32] M. Myers: "Internet X.509 Certificate Request Message Format",
sufficiently those real-time and security requirements. RFC 2511, IETF, March 1999.
MIKEY defines three key management security protocols addressing [33] M. Cooper et al: "Internet X.509 Public Key Infrastructure:
real-time constraints. DHHMAC as described in this document defines Certification Path Building", <draft-ietf-pkix-certpathbuild-
a fourth MIKEY variant aiming at the same target. 05.txt>, Internet Draft, Work in Progress (PKIX WG).
While each of the four key management protocols has its own merits [34] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667,
there are also certain limitations of each approach. As such there February 2004.
is no single ideal solution and none of the variants is able to
subsume the other remaining variants.
It is concluded that DHHMAC features useful security and performance [35] Bradner, S., "Intellectual Property Rights in IETF Technology",
properties that none of the other three MIKEY variants is able to BCP 79, RFC 3668, February 2004.
provide.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. 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
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
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 Intellectual Property Rights
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 pertain to the implementation or use of the technology described to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights. it has made any independent effort to identify any such rights.
Information on the ISOC's procedures with respect to rights in ISOC Information on the procedures with respect to rights in ISOC
Documents can be found in BCP 78 and BCP 79. Documents can be found in BCP 78 and BCP 79.
HMAC-authenticated Diffie-Hellman for MIKEY October 2004
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 such proprietary rights by implementers or users of this of 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 http://www.ietf.org/ipr. at 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 Expiration Date
This Internet Draft expires on 30 March 2005. This Internet Draft expires on 30 July 2005.
[Note to the RFC editor: Please remove the entire following section
prior to publication.]
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
Revision History Revision History
[Note to the RFC editor: Please remove this section prior to
publication.] 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: Changes against draft-ietf-msec-mikey-dhhmac-06.txt:
* Abstract reworded. * Abstract reworded.
* used new RFC boilerplate: changed/moved IPR statement (now at the * used new RFC boilerplate: changed/moved IPR statement (now at the
beginning), status of Memo, and Intellectual Property Rights beginning), status of Memo, and Intellectual Property Rights
section in accordance with RFC 3667, RFC 3668. section in accordance with RFC 3667, RFC 3668.
* ID nits removal. * ID nits removal.
* References updated. * References updated.
* Note added to section 4.1 explaining how to differentiate between * Note added to section 4.1 explaining how to differentiate between
skipping to change at page 32, line 5 skipping to change at page 33, line 41
* New section 4.4 added that describes the use of the general * New section 4.4 added that describes the use of the general
extension payload to avoid bidding-down attacks. extension payload to avoid bidding-down attacks.
* Description of the bidding-down avoidance mechanism removed from * Description of the bidding-down avoidance mechanism removed from
the threat model in section 5.2. the threat model in section 5.2.
* IANA considerations section re-written and aligned with MIKEY. * IANA considerations section re-written and aligned with MIKEY.
* Open issue on KMID pointed in IANA considerations section. * Open issue on KMID pointed in IANA considerations section.
* editorial clean-up. * editorial clean-up.
Changes against draft-ietf-msec-mikey-dhhmac-05.txt: Changes against draft-ietf-msec-mikey-dhhmac-05.txt:
HMAC-authenticated Diffie-Hellman for MIKEY October 2004
* HMAC-SHA1-96 option removed (see section 1.2, 4.2, 5.3,). This * HMAC-SHA1-96 option removed (see section 1.2, 4.2, 5.3,). This
option does not really provide much gain; removal reduces number option does not really provide much gain; removal reduces number
of options. of options.
* IDr added to I_message for DoS protection of the recipient; see * IDr added to I_message for DoS protection of the recipient; see
section 3, 3.1, 5.3. section 3, 3.1, 5.3.
* References updated. * References updated.
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
Changes against draft-ietf-msec-mikey-dhhmac-04.txt: Changes against draft-ietf-msec-mikey-dhhmac-04.txt:
* Introduction section modified: PFS property of DH, requirement * Introduction section modified: PFS property of DH, requirement
for 4th MIKEY key management variant motivated. for 4th MIKEY key management variant motivated.
* MIKEY-DHSIGN, MIKEY-PK and MIKEY-PS added to section 1.2 * MIKEY-DHSIGN, MIKEY-PK and MIKEY-PS added to section 1.2
Abbreviations. Abbreviations.
* Note on secure time synchronization added to section 2.0. * Note on secure time synchronization added to section 2.0.
* New section 2.2 "Relation to GMKARCH" added. * New section 2.2 "Relation to GMKARCH" added.
* New section 2.1.1 "Usage in H.235" added: this section outlines * New section 2.1.1 "Usage in H.235" added: this section outlines a
a use case of DHHMAC in the context of H.235. use case of DHHMAC in the context of H.235.
* Trade-off between identity-protection and security & performance * Trade-off between identity-protection and security & performance
added to section 5.1. added to section 5.1.
* New section 5.6 "Authorization and Trust Model" added. * New section 5.6 "Authorization and Trust Model" added.
* Some further informative references added. * Some further informative references added.
Changes against draft-ietf-msec-mikey-dhhmac-03.txt: Changes against draft-ietf-msec-mikey-dhhmac-03.txt:
* RFC 3552 available; some references updated. * RFC 3552 available; some references updated.
Changes against draft-ietf-msec-mikey-dhhmac-02.txt: Changes against draft-ietf-msec-mikey-dhhmac-02.txt:
* text allows both random and pseudo-random values. * text allows both random and pseudo-random values.
* exponentiation ** changed to ^. * exponentiation ** changed to ^.
* Notation aligned with MIKEY-07. * Notation aligned with MIKEY-07.
* Clarified that the HMAC is calculated over the entire MIKEY * Clarified that the HMAC is calculated over the entire MIKEY
message excluding the MAC field. message excluding the MAC field.
* Section 4.2: The AES key wrap method SHALL not be applied. * Section 4.2: The AES key wrap method SHALL not be applied.
* Section 1: Relationship with other, existing work mentioned. * Section 1: Relationship with other, existing work mentioned.
*
Changes against draft-ietf-msec-mikey-dhhmac-01.txt: Changes against draft-ietf-msec-mikey-dhhmac-01.txt:
* bidding-down attacks addressed (see section 5.2). * bidding-down attacks addressed (see section 5.2).
* optional [X], [X, Y] defined and clarified (see section 1.1, * optional [X], [X, Y] defined and clarified (see section 1.1,
HMAC-authenticated Diffie-Hellman for MIKEY October 2004
5.3). 5.3).
* combination of options defined in key update procedure (see * combination of options defined in key update procedure (see
section 3.1). section 3.1).
* ID payloads clarified (see section 3 and 5.2). * ID payloads clarified (see section 3 and 5.2).
* relationship with MIKEY explained (roundtrip, performance). * relationship with MIKEY explained (roundtrip, performance).
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
* new section 2.1 on applicability of DHHMAC for SIP/SDP and * new section 2.1 on applicability of DHHMAC for SIP/SDP and
H.323 added. H.323 added.
* more text due to DH resolution incorporated in section 5.3 * more text due to DH resolution incorporated in section 5.3
regarding PFS, security robustness of DH, generalization regarding PFS, security robustness of DH, generalization
capability of DH to general groups in particular EC and capability of DH to general groups in particular EC and
"future-proofness". "future-proofness".
* a few editorials and nits. * a few editorials and nits.
* references adjusted and cleaned-up. * references adjusted and cleaned-up.
Changes against draft-ietf-msec-mikey-dhhmac-00.txt: Changes against draft-ietf-msec-mikey-dhhmac-00.txt:
skipping to change at page 34, line 5 skipping to change at page 35, line 43
* a few editorial improvements and corrections * a few editorial improvements and corrections
* IPR clarified and IPR section changed. * IPR clarified and IPR section changed.
Author's Addresses Author's Addresses
Martin Euchner Martin Euchner
Email: martin_euchner@hotmail.com Email: martin_euchner@hotmail.com
Phone: +49 89 722 55790 Hofmannstr. 51 Phone: +49 89 722 55790 Hofmannstr. 51
Fax: +49 89 722 62366 Fax: +49 89 722 62366
HMAC-authenticated Diffie-Hellman for MIKEY October 2004
81359 Munich, Germany 81359 Munich, Germany
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/