draft-ietf-msec-mikey-dhhmac-09.txt   draft-ietf-msec-mikey-dhhmac-10.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: July 2005 February 2005 Expires: September 2005 March 2005
HMAC-authenticated Diffie-Hellman for MIKEY HMAC-authenticated Diffie-Hellman for MIKEY
<draft-ietf-msec-mikey-dhhmac-09.txt> <draft-ietf-msec-mikey-dhhmac-10.txt>
IPR Statement Status of this Memo
By submitting this Internet-Draft, I certify that any applicable patent 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 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 disclosed, and any of which I become aware will be disclosed, in accordance
with RFC 3668. with RFC 3668.
Status of this Memo
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet- Drafts. may also distribute working documents as Internet- Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and Internet-Drafts are draft documents valid for a maximum of six months and
may be updated, replaced, or obsoleted by other documents at any time. may be updated, replaced, or obsoleted by other documents at any time.
It is inappropriate to use Internet-Drafts as reference material or to It is inappropriate to use Internet-Drafts as reference material or to
cite them other than a "work in progress." cite them other than a "work in progress."
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
HMAC-authenticated Diffie-Hellman for MIKEY March 2005
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 the MIKEY, as defined in RFC 3830. In particular, this variant deploys the
classic Diffie-Hellman key agreement protocol for key establishment classic Diffie-Hellman key agreement protocol for key establishment
featuring perfect forward secrecy in conjunction with a keyed hash message featuring perfect forward secrecy in conjunction with a keyed hash message
authentication code for achieving mutual authentication and message authentication code for achieving mutual authentication and message
integrity of the key management messages exchanged. This protocol integrity of the key management messages exchanged. This protocol
addresses the security and performance constraints of multimedia key addresses the security and performance constraints of multimedia key
management in MIKEY. management in MIKEY.
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...............................................7 1.2. Abbreviations.............................................7
2. Scenario......................................................8 2. Scenario....................................................8
2.1. Applicability...............................................8 2.1. Applicability.............................................9
2.2. Relation to GKMARCH........................................10 2.2. Relation to GKMARCH.......................................9
3. DHHMAC Security Protocol.....................................11 3. DHHMAC Security Protocol...................................10
3.1. TGK re-keying..............................................13 3.1. TGK re-keying............................................11
4. DHHMAC payload formats.......................................14 4. DHHMAC payload formats.....................................12
4.1. Common header payload (HDR)................................14 4.1. Common header payload (HDR)..............................13
4.2. Key data transport payload (KEMAC).........................15 4.2. Key data transport payload (KEMAC).......................14
4.3. ID payload (ID)............................................16 4.3. ID payload (ID)..........................................15
4.4. General Extension Payload..................................16 4.4. General Extension Payload................................15
5. Security Considerations......................................16 5. Security Considerations....................................15
5.1. Security environment.......................................17 5.1. Security environment.....................................15
5.2. Threat model...............................................17 5.2. Threat model.............................................16
5.3. Security features and properties...........................20 5.3. Security features and properties.........................19
5.4. Assumptions................................................24 5.4. Assumptions..............................................23
HMAC-authenticated Diffie-Hellman for MIKEY January 2005 5.5. Residual risk............................................24
HMAC-authenticated Diffie-Hellman for MIKEY March 2005
5.5. Residual risk..............................................25 5.6. Authorization and Trust Model............................25
5.6. Authorization and Trust Model..............................26 6. Acknowledgments............................................25
6. Acknowledgments............................................26 7. IANA considerations........................................25
Conclusions.....................................................26 8. References.................................................26
7. IANA considerations..........................................27 8.1 Normative References.......................................26
8. References...................................................27 8.2 Informative References.....................................27
8.1 Normative References.......................................27 Appendix A Usage of MIKEY-DHHMAC in H.235......................29
8.2 Informative References.....................................28 Full Copyright Statement........................................31
Full Copyright Statement........................................30 Expiration Date.................................................32
Expiration Date.................................................31
Revision History................................................32 Revision History................................................32
Author's Addresses..............................................34 Author's Addresses..............................................35
1. Introduction 1. Introduction
There is work done in IETF to develop key management schemes. For example, There is work done in IETF to develop key management schemes. For example,
IKE [14] is a widely accepted unicast scheme for IPsec, and the MSEC WG IKE [14] is a widely accepted unicast scheme for IPsec, and the MSEC WG
is developing other schemes, addressed to group communication [24], [25]. is developing other schemes, addressed to group communication [24], [25].
For reasons discussed below, there is however a need for a scheme with For reasons discussed below, there is however a need for a scheme with
low latency, suitable for demanding cases such as real-time data over low latency, suitable for demanding cases such as real-time data over
heterogeneous networks, and small interactive groups. heterogeneous networks, and small interactive groups.
skipping to change at page 3, line 43 skipping to change at page 4, line 4
small-sized groups. MIKEY in particular, describes three key management small-sized groups. MIKEY in particular, describes three key management
schemes for the peer-to-peer case that all finish their task within one schemes for the peer-to-peer case that all finish their task within one
round trip: 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
(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 March 2005
- and a Diffie-Hellman key agreement protocol (MIKEY-DHSIGN) - and a Diffie-Hellman key agreement protocol (MIKEY-DHSIGN)
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
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 depending complete their work within just one round trip. This requires depending
on loosely synchronized clocks and deploying timestamps within the key on loosely synchronized clocks and deploying timestamps within the key
management protocols. management protocols.
However, it is known [7] that each of the three key management schemes However, it is known [7] that each of the three key management schemes
has its subtle constraints and limitations: has its subtle constraints and limitations:
- The symmetric key distribution protocol (MIKEY-PS) is simple - The symmetric key distribution protocol (MIKEY-PS) is simple
to implement but does not nicely scale in any larger configuration to implement, however, was not intended to scale to support any
of potential peer entities due to the need of mutually pre-assigned configurations beyond peer-to-peer, simple one-to-many, and
shared master secrets. small-size (interactive) groups, due to the need of mutually
pre-assigned shared master secrets.
Moreover, the security provided does not achieve the property of Moreover, the security provided does not achieve the property of
perfect forward secrecy; i.e. compromise of the shared master perfect forward secrecy; i.e. compromise of the shared master
secret would render past and even future session keys susceptible secret would render past and even future session keys susceptible
to compromise. to compromise.
Further, the generation of the session key happens just at the Further, the generation of the session key happens just at the
initiator. Thus, the responder has to fully trust the initiator initiator. Thus, the responder has to fully trust the initiator
on choosing a good and secure session secret; the responder neither on choosing a good and secure session secret; the responder neither
is able to participate in the key generation nor to influence that is able to participate in the key generation nor to influence that
skipping to change at page 4, line 42 skipping to change at page 5, line 4
- 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 keys public-key infrastructure that certifies the private-public keys
by issuing and maintaining digital certificates. While such a key by issuing and maintaining digital certificates. While such a key
management scheme provides full scalability in large networked management scheme provides full scalability in large networked
configurations, public-key infrastructures are still not widely configurations, public-key infrastructures are still not widely
available and in general, implementations are significantly more available and in general, implementations are significantly more
complex. complex.
Further, additional round trips and computational processing might Further, additional round trips and computational processing might
be necessary for each end system in order to ascertain verification be necessary for each end system in order to ascertain verification
HMAC-authenticated Diffie-Hellman for MIKEY March 2005
of the digital certificates. For example, typical operations in of the digital certificates. For example, typical operations in
the context of a public-key infrastructure such as validating the context of a public-key infrastructure such as validating
digital certificates (RFC 3029, [31]), ascertaining the revocation digital certificates (RFC 3029, [31]), ascertaining the revocation
status of digital certificates (RFC 2560, [30]) and asserting status of digital certificates (RFC 2560, [30]) and asserting
HMAC-authenticated Diffie-Hellman for MIKEY January 2005 certificate policies, construction of certification path(s) ([33]),
requesting and obtaining necessary certificates (RFC 2511, [32])
certificate policies, construction of certification path(s) and management of certificates for such purposes ([29]) may involve
([33]), requesting and obtaining necessary certificates (RFC 2511, extra network communication handshakes with the public-key
[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 infrastructure and with certification authorities and may
typically involve additional processing steps in the end systems. typically involve additional processing steps in the end systems.
Such steps and tasks all result in further delay of the key agreement Such steps and tasks all result in further delay of the key agreement
or key establishment phase among the end systems, negatively or key establishment phase among the end systems, negatively
impacting setup time. Any extra PKI handshakes and processing are impacting setup time. Any extra PKI handshakes and processing are
not in scope of MIKEY and since this document deploys symmetric not in scope of MIKEY and since this document deploys symmetric
security mechanisms only, aspects of PKI, digital certificates and security mechanisms only, aspects of PKI, digital certificates and
related processing are not further covered in this document. related processing are not further covered in this document.
Finally, as in the symmetric case, the responder depends completely Finally, as in the symmetric case, the responder depends completely
upon the initiator choosing good and secure session keys. upon the initiator choosing good and secure session 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 exchange Diffie-Hellman key agreement scheme and authenticates the exchange
of the Diffie-Hellman half-keys in each direction by using a digital of the Diffie-Hellman half-keys in each direction by using a digital
signature. As in the previous method, this introduces the signature. This approach has the same advantages and deficiencies
dependency upon a public-key infrastructure with its strength on as described in the previous section in terms of a public-key
scalability but also the limitations on computational costs in infrastructure.
performing the asymmetric long-integer operations and the
potential need for additional communication for verification of the
digital certificates.
However, the Diffie-Hellman key agreement protocol is known for its However, the Diffie-Hellman key agreement protocol is known for its
subtle security strengths in that it is able to provide full perfect subtle security strengths in that it is able to provide full perfect
forward secrecy (PFS) and further have both parties actively forward secrecy (PFS) and further have both parties actively
involved in session key generation. This special security property involved in session key generation. This special security property
- despite the somewhat higher computational costs - makes - despite the somewhat higher computational costs - makes
Diffie-Hellman techniques attractive in practice. Diffie-Hellman techniques attractive in practice.
In order to overcome some of the limitations as outlined above, a special In order to overcome some of the limitations as outlined above, a special
need has been recognized for another efficient key agreement protocol need has been recognized for another efficient key agreement protocol
variant in MIKEY. This protocol variant aims to provide the capability variant in MIKEY. This protocol variant aims to provide the capability
of perfect forward secrecy as part of a key agreement with low latency of perfect forward secrecy as part of a key agreement with low latency
without dependency on a public-key infrastructure. without dependency on a public-key infrastructure.
HMAC-authenticated Diffie-Hellman for MIKEY January 2005 HMAC-authenticated Diffie-Hellman for MIKEY March 2005
This document describes such a fourth light-weight key management scheme This document describes such a fourth light-weight key management scheme
for MIKEY that could somehow be seen as a synergetic optimization between for MIKEY that could somehow be seen as a synergetic optimization between
the pre-shared key distribution scheme and the Diffie-Hellman key the pre-shared key distribution scheme and the Diffie-Hellman key
agreement. agreement.
The idea of that protocol is to apply the Diffie-Hellman key agreement The idea of the protocol in this document is to apply the Diffie-Hellman
but instead of deploying a digital signature for authenticity of the key agreement, but rather than deploying a digital signature for
exchanged keying material rather uses a keyed-hash upon using authenticity of the exchanged keying material, instead uses a keyed-hash
symmetrically pre-assigned shared secrets. This combination of security upon using symmetrically pre-assigned shared secrets. This combination
mechanisms is called the HMAC-authenticated Diffie-Hellman (DH) key of security mechanisms is called the HMAC-authenticated Diffie-Hellman
agreement for MIKEY (DHHMAC). (DH) key agreement for MIKEY (DHHMAC).
The DHHMAC variant closely follows the design and philosophy of MIKEY and The DHHMAC variant closely follows the design and philosophy of MIKEY and
reuses MIKEY protocol payload components and MIKEY mechanisms to its reuses MIKEY protocol payload components and MIKEY mechanisms to its
maximum benefit and for best compatibility. maximum benefit and for best compatibility.
Like the MIKEY Diffie-Hellman protocol, DHHMAC does not scale beyond a Like the MIKEY Diffie-Hellman protocol, DHHMAC does not scale beyond a
point-to-point constellation; thus, both MIKEY Diffie-Hellman protocols point-to-point constellation; thus, both MIKEY Diffie-Hellman protocols
do not support group-based keying for any group size larger than two do not support group-based keying for any group size larger than two
entities. entities.
1.1. Definitions 1.1. Definitions
The definitions and notations in this document are aligned with MIKEY, The definitions and notations in this document are aligned with MIKEY,
see [3] and [3] sections 1.3 - 1.4. see [3], sections 1.3 - 1.4.
All large integer computations in this document should be understood as 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 [3] section 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 general to other 3.3; however, the DHHMAC protocol is applicable in general to other
appropriate finite, cyclical groups as well. appropriate finite, cyclical groups as well.
It is assumed that a pre-shared key s is known by both entities (initiator It is assumed that a pre-shared key s is known by both entities (initiator
and responder). The authentication key auth_key is derived from the and responder). The authentication key auth_key is derived from the
pre-shared secret s using the pseudo-random function PRF; see [3] sections pre-shared secret s using the pseudo-random function PRF; see [3] sections
4.1.3 and 4.1.5. 4.1.3 and 4.1.5.
HMAC-authenticated Diffie-Hellman for MIKEY March 2005
In this text, [X] represents an optional piece of information. Generally In this text, [X] represents an optional piece of information. Generally
throughout the text, X SHOULD be present unless certain circumstance MAY throughout the text, X SHOULD be present unless certain circumstance MAY
allow X being optional and not be present thereby resulting in weaker allow X being optional and not be present thereby resulting in weaker
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
security potentially. Likewise [X, Y] represents an optional compound security potentially. Likewise [X, Y] represents an optional compound
piece of information where the pieces X and Y SHOULD be either both present piece of information where the pieces X and Y SHOULD be either both present
or MAY optionally be both absent. {X} denotes zero or more occurrences or MAY optionally be both absent. {X} denotes zero or more occurrences
of X. 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
skipping to change at page 7, line 42 skipping to change at page 8, line 4
HMAC HMAC
MIKEY-DHSIGN MIKEY Diffie-Hellman key agreement protocol MIKEY-DHSIGN MIKEY Diffie-Hellman key agreement protocol
MIKEY-PK MIKEY public-key encryption-based key distribution MIKEY-PK MIKEY public-key encryption-based key distribution
protocol protocol
MIKEY-PS MIKEY pre-shared key distribution protocol MIKEY-PS MIKEY pre-shared key distribution protocol
p Diffie-Hellman prime modulus p Diffie-Hellman prime modulus
PKI Public-key Infrastructure PKI Public-key Infrastructure
PRF MIKEY pseudo-random function (see [3] section PRF MIKEY pseudo-random function (see [3] section
4.1.3.) 4.1.3.)
RSA Rivest, Shamir and Adleman RSA Rivest, Shamir and Adleman
HMAC-authenticated Diffie-Hellman for MIKEY March 2005
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
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
T timestamp T timestamp
TEK Traffic Encryption Key TEK Traffic Encryption Key
TGK MIKEY TEK Generation Key as the common Diffie- TGK MIKEY TEK Generation Key as the common Diffie-
Hellman shared secret Hellman shared secret
TLS Transport Layer Security TLS Transport Layer Security
xi secret, (pseudo) random Diffie-Hellman key of the xi secret, (pseudo) random Diffie-Hellman key of the
Initiator Initiator
xr secret, (pseudo) random Diffie-Hellman key of the xr secret, (pseudo) random Diffie-Hellman key of the
Responder Responder
skipping to change at page 8, line 28 skipping to change at page 8, line 32
The HMAC-authenticated Diffie-Hellman key agreement protocol (DHHMAC) for The HMAC-authenticated Diffie-Hellman key agreement protocol (DHHMAC) for
MIKEY addresses the same scenarios and scope as the other three key MIKEY addresses the same scenarios and scope as the other three key
management schemes in MIKEY address. management schemes in MIKEY address.
DHHMAC is applicable in a peer-to-peer group where no access to a DHHMAC is applicable in a peer-to-peer group where no access to a
public-key infrastructure can be assumed available. Rather, pre-shared public-key infrastructure can be assumed available. Rather, pre-shared
master secrets are assumed available among the entities in such an master secrets are assumed available among the entities in such an
environment. environment.
In a pair-wise group, it is assumed that each client will be setting up 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-MAC key a session key for its outgoing links with its peer using the DH-MAC key
agreement protocol. agreement protocol.
As is the case for the other three MIKEY key management protocol, DHHMAC As is the case for the other three MIKEY key management protocols, DHHMAC
assumes loosely synchronized clocks among the entities in the small group. assumes, at least, loosely synchronized clocks among the entities in the
small group.
Note: To synchronize the clocks in a secure manner, some operational or To synchronize the clocks in a secure manner, some operational or
procedural means are recommended. However, MIKEY-DHHMAC does not describe procedural means are recommended. MIKEY-DHHMAC does not define any secure
any secure time synchronization measures and leaves such tasks to the time synchronization measures, however, sections 5.4 and 9.3 of [3]
discretion of the implementation. The reader is referred to [3] section provide implementation guidance on clock synchronization and timestamps.
5.4 and [3] section 9.3 that give guidance on clock synchronization and
timestamps. HMAC-authenticated Diffie-Hellman for MIKEY March 2005
2.1. Applicability 2.1. Applicability
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
MIKEY-DHHMAC as well as the other MIKEY key management protocols are MIKEY-DHHMAC, as well as the other MIKEY key management protocols, is
optimized and targeted for the purpose of multimedia applications with intended for application-level key management and is optimized for
application-level key management needs under real-time session setup and multimedia applications with real-time session setup and session
session management constraints. management constraints.
As the MIKEY-DHHMAC key management protocol terminates in one roundtrip, As the MIKEY-DHHMAC key management protocol terminates in one roundtrip,
DHHMAC is applicable for integration into two-way handshake session- or DHHMAC is applicable for integration into two-way handshake session- or
call signaling protocols such as call signaling protocols such as
a) SIP/SDP (see [5]) where the encoded MIKEY messages are encapsulated a) SIP/SDP where the encoded MIKEY messages are encapsulated and
and transported in SDP containers of the SDP offer/answer handshake, transported in SDP containers of the SDP offer/answer [RFC 3264]
handshake as described in [5],
b) H.323 (see [22]) where the encoded MIKEY messages are transported in b) H.323 (see [22]) where the encoded MIKEY messages are transported in
the H.225.0 fast start call signaling handshake. the H.225.0 fast start call signaling handshake. Appendix A outlines
the usage of MIKEY-DHHMAC within H.235.
MIKEY-DHHMAC is offered as 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 all variants (MIKEY-pre-shared, MIKEY-public-key and MIKEY-DH-SIGN) for all
those cases where DHHMAC has its peculiar strengths (see section 5). those cases where DHHMAC has its particular strengths (see section 5).
2.1.1. Usage in H.235
This section provides informative overview how MIKEY-DHHMAC can be
applied in some H.323-based multimedia environments. Generally, MIKEY
is applicable for multimedia applications including IP telephony. [22]
describes various use cases of the MIKEY key management protocols
(MIKEY-PS, MIKEY-PK, MIKEY-DHSIGN and MIKEY-DHHMAC) with the purpose to
establish TGK keying material among H.323 endpoints. The TGKs are then
used for media encryption by applying SRTP [27]. Addressed scenarios
include point-to-point with one or more intermediate gatekeepers (trusted
or partially trusted) in-between.
One particular use case addresses MIKEY-DHHMAC to establish a media
connection from an endpoint B calling (through a gatekeeper) to 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, some separate
protocol exchange means are achieved outside the actual call setup
procedure to establish an auth_key for the time while endpoints are being
registered with the gatekeeper; such protocols exist [22] but are not
shown in this document. The auth_key between the endpoints is being used
to authenticate and integrity protect the MIKEY-DHHMAC messages.
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
To establish a call, it is assumed that endpoint B has obtained permission
from the gatekeeper (not shown). Endpoint B as the caller builds the
MIKEY-DHHMAC I_message(see section 3) and sends the I_message
encapsulated within the H.323-SETUP to endpoint A. A routing gatekeeper
(GK) would forward this message to endpoint B; in case of a non-routing
gatekeeper, endpoint B sends the SETUP directly to endpoint A. In either
case, H.323 inherent security mechanisms [28] are applied to protect the
(encapsulation) message during transfer. This is not depicted here. The
receiving endpoint A is 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 MIKEY-DHHMAC R_message and sends the response as part of the
CallProceeding-to-Connect message back to the calling endpoint B
(possibly through a routing gatekeeper). Endpoint B processes the
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])
2.) EP-A -> (GK) -> EP-B: CallProceeding-to-CONNECT(R_fwd_message [,
R_rev_message])
Notes: If it is necessary to establish directional TGKs for full-
duplex links in both directions B->A and A->B, then the calling
endpoint B instantiates the DHHMAC protocol twice: once in the
direction B->A using I_fwd_message and another run in parallel
in the direction A->B using I_rev_message. In that case, two
MIKEY-DHHMAC I_messages are encapsulated within SETUP
(I_fwd_message and I_rev_message) and two MIKEY-DHHMAC
R_messages (R_fwd_message and R_rev_message) are encapsulted
within CallProceeding-to-CONNECT. The I_rev_message
corresponds with the I_fwd_message.
Alternatively, the called endpoint A may instantiate the DHHMAC
protocol in a separate run with endpoint B (not shown); however,
this requires a third handshake to complete.
For more details on how the MIKEY protocols may be deployed with
H.235, please refer to [22].
2.2. Relation to GKMARCH 2.2. Relation to GKMARCH
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
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 main operate as a registration protocol, see also [3] section 2.4. The main
entities involved in the architecture are a group controller/key server entities involved in the architecture are a group controller/key server
(GCKS), the receiver(s), and the sender(s). Due to the pair-wise nature (GCKS), the receiver(s), and the sender(s). Due to the pair-wise nature
of the Diffie-Hellman operation and the 1-roundtrip constraint, usage of the Diffie-Hellman operation and the 1-roundtrip constraint, usage
of MIKEY-DHHMAC rules out any deployment as a group key management of MIKEY-DHHMAC rules out any deployment as a group key management
protocol with more than two group entities. Only the degenerate case protocol with more than two group entities. Only the degenerate case
with two peers is possible where for example the responder acts as the with two peers is possible where for example the responder acts as the
group controller. group controller.
HMAC-authenticated Diffie-Hellman for MIKEY March 2005
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, only
updating of the keys by normal unicast messages. 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
I_message = HDR, T, RAND, [IDi], IDr, I_message = HDR, T, RAND, [IDi], IDr,
skipping to change at page 12, line 4 skipping to change at page 10, line 32
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 defer payloads IDi and IDr within the I_message; unless the receiver can defer
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
the initiator's identity by some other means, then IDi MAY optionally the initiator's identity by some other means, then IDi MAY optionally
be omitted. The initiator SHALL always include the recipient's be omitted. The initiator SHALL always include the recipient's
identity. identity.
The group parameters (e.g., the group G) are a set of parameters chosen The group parameters (e.g., the group G) are a set of parameters chosen
by the initiator. Note, that like in the MIKEY protocol, both sender by the initiator. Note, that like in the MIKEY protocol, both sender
and receiver explicitly transmit the Diffie-Hellman group G within the and receiver explicitly transmit the Diffie-Hellman group G within the
Diffie-Hellman payload DHi or DHr through an encoding (e.g., OAKELEY Diffie-Hellman payload DHi or DHr through an encoding (e.g., OAKLEY
group numbering, see [3] section 6.4); the actual group parameters g group numbering, see [3] section 6.4); the actual group parameters g
and p however are not explicitly transmitted but can be deduced from and p however are not explicitly transmitted but can be deduced from
the Diffie-Hellman group G. The responder chooses a (pseudo) random the Diffie-Hellman group G. The responder chooses a (pseudo) random
HMAC-authenticated Diffie-Hellman for MIKEY March 2005
positive integer xr, and sends an HMACed message including g^(xr) and positive integer xr, and sends an HMACed message including g^(xr) and
the timestamp to the initiator. The responder SHALL always include the the timestamp to the initiator. The responder SHALL always include the
initiator's identity IDi regardless of whether the I_message conveyed initiator's identity IDi regardless of whether the I_message conveyed
any IDi. It is RECOMMENDED that the responder SHOULD always include any IDi. It is RECOMMENDED that the responder SHOULD always include
the identity payload IDr within the R_message; unless the initiator can the identity payload IDr within the R_message; unless the initiator can
defer the reponder's identity by some other means, then IDr MAY defer the reponder's identity by some other means, then IDr MAY
optionally be left out. 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-keys, The HMAC authentication provides authentication of the DH half-keys,
and is necessary to avoid man-in-the-middle attacks. and is necessary to avoid man-in-the-middle attacks.
This approach is less expensive than digitally signed Diffie-Hellman. This approach is less expensive than digitally signed Diffie-Hellman
It requires first of all, that both sides compute one exponentiation in that both sides compute first one exponentiation and one HMAC, then
and one HMAC, then one HMAC verification and finally another one HMAC verification and finally another Diffie-Hellman
Diffie-Hellman exponentiation. exponentiation.
With off-line pre-computation, the initial Diffie-Hellman half-key MAY 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 the risk further reduce the overall round trip delay as well as reduce the risk
of denial-of-service attacks. of denial-of-service attacks.
Processing of the TGK SHALL be accomplished as described in MIKEY [3] Processing of the TGK SHALL be accomplished as described in MIKEY [3]
chapter 4. chapter 4.
The computed HMAC result SHALL be conveyed in the KEMAC payload field The computed HMAC result SHALL be conveyed in the KEMAC payload field
where the MAC fields holds the HMAC result. The HMAC SHALL be computed where the MAC fields holds the HMAC result. The HMAC SHALL be computed
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
over the entire message excluding the MAC field using auth_key, see also over the entire message excluding the MAC field using auth_key, see also
section 4.2. section 4.2.
3.1. TGK re-keying 3.1. TGK re-keying
HMAC-authenticated Diffie-Hellman for MIKEY March 2005
TGK re-keying for DHHMAC generally proceeds as described in [3] section TGK re-keying for DHHMAC generally proceeds as described in [3] section
4.5. Specifically, figure 2 provides the message exchange for the 4.5. Specifically, figure 2 provides the message exchange for the
DHHMAC update message. 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
TGK re-keying supports two procedures: TGK re-keying supports two procedures:
a) True re-keying by exchanging new and fresh Diffie-Hellman a) True re-keying by exchanging new and fresh Diffie-Hellman half-keys.
half-keys. For this, the initiator SHALL provide a new, fresh DHi For this, the initiator SHALL provide a new, fresh DHi and the
and the responder SHALL respond with a new, fresh DHr 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 security change the actual TGK but updates other information like security
policy parameters for example. To only update the non-key related policy parameters for example. To only update the non-key related
information, [DHi] and [DHr, DHi] SHALL be left out. information, [DHi] and [DHr, DHi] SHALL be left out.
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
4. DHHMAC payload formats 4. DHHMAC payload formats
This section specifies the payload formats and data type values for DHHMAC, This section specifies the payload formats and data type values for DHHMAC,
see also [3] chapter 6 for a definition of the MIKEY payloads. see also [3] chapter 6 for a definition of the MIKEY payloads.
This document does not define new payload formats but re-uses MIKEY This document does not define new payload formats but re-uses MIKEY
payloads for DHHMAC as referenced: payloads for DHHMAC as referenced:
* Common header payload (HDR), see section 4.1 and [3] section 6.1 * Common header payload (HDR), see section 4.1 and [3] section 6.1
HMAC-authenticated Diffie-Hellman for MIKEY March 2005
* SRTP ID sub-payload, see [3] section 6.1.1, * SRTP ID sub-payload, see [3] section 6.1.1,
* Key data transport payload (KEMAC), see section 4.2 and [3] section * Key data transport payload (KEMAC), see section 4.2 and [3] section
6.2 6.2
* DH data payload, see [3] section 6.4 * DH data payload, see [3] section 6.4
* Timestamp payload, [3] section 6.6 * Timestamp payload, [3] section 6.6
skipping to change at page 15, line 4 skipping to change at page 13, line 35
4.1. Common header payload (HDR) 4.1. Common header payload (HDR)
Referring to [3] section 6.1, for DHHMAC the following data types SHALL Referring to [3] section 6.1, for DHHMAC the following data types SHALL
be used: 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
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
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 by
evaluating the data type field as 7 or 8. This is how the responder evaluating the data type field as 7 or 8. This is how the responder
can differentiate between MIKEY and MIKEY DHHMAC. can differentiate between MIKEY and MIKEY DHHMAC.
HMAC-authenticated Diffie-Hellman for MIKEY March 2005
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
skipping to change at page 16, line 4 skipping to change at page 14, line 39
DHHMAC SHALL apply this payload for conveying the HMAC result along with DHHMAC SHALL apply this payload for conveying the HMAC result along with
the indicated authentication algorithm. KEMAC when used in conjunction the indicated authentication algorithm. KEMAC when used in conjunction
with DHHMAC SHALL not convey any encrypted data; thus Encr alg SHALL 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 and Encr data 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 [23]) SHALL not be applied be left empty. The AES key wrap method (see [23]) SHALL not be applied
for DHHMAC. for DHHMAC.
For DHHMAC, this key data transport payload SHALL be the last payload For DHHMAC, this key data transport payload SHALL be the last payload
in the message. Note that the Next payload field SHALL be set to Last in the message. Note that the Next payload field SHALL be set to Last
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
payload. The HMAC is then calculated over the entire MIKEY message payload. The HMAC is then calculated over the entire MIKEY message
excluding the MAC field using auth_key as described in [3] section 5.2 excluding the MAC field using auth_key as described in [3] section 5.2
and then stored within MAC field. and then stored within the MAC field.
MAC alg | Value | Comments MAC alg | Value | Comments
------------------------------------------------------------------ ------------------------------------------------------------------
HMAC-SHA-1 | 0 | Mandatory, Default (see [4]) HMAC-SHA-1 | 0 | Mandatory, Default (see [4])
HMAC-authenticated Diffie-Hellman for MIKEY March 2005
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 MUST be implemented as part HMAC-SHA-1 is the default hash function that MUST be implemented as part
of the DHHMAC. The length of the HMAC-SHA-1 result is 160 bits. of the DHHMAC. The length of the HMAC-SHA-1 result is 160 bits.
4.3. ID payload (ID) 4.3. ID payload (ID)
skipping to change at page 17, line 5 skipping to change at page 15, line 38
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. For This document addresses key management security issues throughout. For
a comprehensive explanation of MIKEY security considerations, please a comprehensive explanation of MIKEY security considerations, please
refer to MIKEY [3] section 9. refer to MIKEY [3] section 9.
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
In addition to that, this document addresses security issues according In addition to that, this document addresses security issues according
to [8] where the following security considerations apply in particular to [8] where the following security considerations apply in particular
to this document: to this document:
5.1. Security environment 5.1. Security environment
HMAC-authenticated Diffie-Hellman for MIKEY March 2005
Generally, the DHHMAC security protocol described in this document focuses Generally, the DHHMAC security protocol described in this document focuses
primarily on communication security; i.e. the security issues concerned primarily on communication security; i.e. the security issues concerned
with the MIKEY DHHMAC protocol. Nevertheless, some system security issues with the MIKEY DHHMAC protocol. Nevertheless, some system security issues
are of interest as well that are not explicitly defined by the DHHMAC are of interest as well that are not explicitly defined by the DHHMAC
protocol, but should be provided locally in practice. protocol, but should be provided locally in practice.
The system that runs the DHHMAC protocol entity SHALL provide the The system that runs the DHHMAC protocol entity SHALL provide the
capability to generate (pseudo) random numbers as input to the capability to generate (pseudo) random numbers as input to the
Diffie-Hellman operation (see [9], [15]). Furthermore, the system SHALL Diffie-Hellman operation (see [9], [15]). Furthermore, the system SHALL
be capable of storing the generated (pseudo) random data, secret data, be capable of storing the generated (pseudo) random data, secret data,
keys and other secret security parameters securely (i.e. confidential and keys and other secret security parameters securely (i.e. confidential and
safe from unauthorized tampering). safe from unauthorized tampering).
5.2. Threat model 5.2. Threat model
The threat model that this document adheres to cover the issues of The threat model, to which this document adheres, covers 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 can 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 can
deployed on a hop-by-hop basis with some intermediate trusted "MIKEY be deployed on a hop-by-hop basis with some intermediate trusted "MIKEY
DHHMAC proxies" involved. DHHMAC proxies" involved.
Since DHHMAC is a key management protocol, the following security threats Since DHHMAC is a key management protocol, the following security threats
are of concern: 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. Rather, DHHMAC protocol does not explicitly transmit the TGK at all. Instead,
by the Diffie-Hellman "encryption" operation, that conceals the secret by using the Diffie-Hellman "encryption" operation, which conceals the
(pseudo) random values, only partial information (i.e. the DH- half key) secret (pseudo) random values, only partial information (i.e. the DH-
for construction of the TGK is transmitted. It is fundamentally assumed half key) for construction of the TGK is transmitted. It is
HMAC-authenticated Diffie-Hellman for MIKEY January 2005 fundamentally assumed that availability of such Diffie-Hellman
half-keys to an eavesdropper does not result in any substantial security
risk; see 5.4. Furthermore, the DHHMAC carries other data such as
timestamps, (pseudo) random values, identification information or
security policy parameters; eavesdropping of any such data is considered
not to yield any significant security risk.
that availability of such Diffie-Hellman half-keys to an eavesdropper HMAC-authenticated Diffie-Hellman for MIKEY March 2005
does not result in any substantial security risk; see 5.4. Furthermore,
the DHHMAC carries other data such as timestamps, (pseudo) random
values, identification information or security policy parameters;
eavesdropping of any such data is considered not to yield any significant
security risk.
* Masquerade of either entity: * Masquerade of either entity:
This security threat must be avoided and if a masquerade attack would This security threat must be avoided and if a masquerade attack would
be attempted, appropriate detection means must be in place. DHHMAC be attempted, appropriate detection means must be in place. DHHMAC
addresses this threat by providing mutual peer entity authentication. addresses this threat by providing mutual peer entity authentication.
* 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 and messages. Man-in-the-middle attacks usually come with masquerade and
or loss of message integrity (see below). Man-in-the-middle attacks or loss of message integrity (see below). Man-in-the-middle attacks
skipping to change at page 18, line 44 skipping to change at page 17, line 38
are offered (e.g., such as is possible by SDP [5]), avoiding are offered (e.g., such as is possible by SDP [5]), avoiding
bidding-down attacks is of concern. DHHMAC addresses this threat by bidding-down attacks is of concern. DHHMAC addresses this threat by
reusing the MIKEY General Extension Payload mechanism, where all key reusing the MIKEY General Extension Payload mechanism, where all key
management protocol identifiers are be listed within the MIKEY General management protocol identifiers are be listed within the MIKEY General
Extension Payload. 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 be believed that DHHMAC is sufficiently secure and that such attacks are
HMAC-authenticated Diffie-Hellman for MIKEY January 2005 infeasible, although the possibility of a successful attack cannot be
ruled out.
infeasible although the possibility of a successful attack cannot be
ruled out completely.
* Non-repudiation of the receipt or of the origin of the message: * Non-repudiation of the receipt or of the origin of the message:
These are not requirements of this environment and thus related These are not requirements within the context of DHHMAC in this
countermeasures are not provided at all. environment and thus related countermeasures are not provided at all.
HMAC-authenticated Diffie-Hellman for MIKEY March 2005
* Denial-of-service or distributed denial-of-service attacks: * Denial-of-service or distributed denial-of-service attacks:
Some considerations are given on some of those attacks, but DHHMAC does Some considerations are given on some of those attacks, but DHHMAC does
not claim to provide full countermeasure against any of those attacks. not claim to provide full countermeasure against any of those attacks.
For example, stressing the availability of the entities are not thwarted For example, stressing the availability of the entities are not thwarted
by means of the key management protocol; some other local by means of the key management protocol; some other local
countermeasures should be applied. Further, some DoS attacks are not countermeasures should be applied. Further, some DoS attacks are not
countered such as interception of a valid DH-request and its massive countered such as interception of a valid DH-request and its massive
instant duplication. Such attacks might at least be countered partially instant duplication. Such attacks might at least be countered partially
by some local means that are outside the scope of this document. by some local means that are outside the scope of this document.
* Identity protection: * Identity protection:
Like MIKEY, identity protection is not a major design requirement for Like MIKEY, identity protection is not a major design requirement for
MIKEY-DHHMAC either, see [3]. No security protocol is known so far, MIKEY-DHHMAC either, see [3]. No security protocol is known so far,
that is able to provide the objectives of DHHMAC as stated in section that is able to provide the objectives of DHHMAC as stated in section
5.3 including identity protection within just a single roundtrip. 5.3 including identity protection within just a single roundtrip.
MIKEY-DHHMAC trades identity protection for better security for the MIKEY-DHHMAC trades identity protection for better security for the
keying material and shorter roundtrip time. Thus, MIKEY-DHHMAC does not keying material and shorter roundtrip time. Thus, MIKEY-DHHMAC does not
provide identity protection on its own but may inherit such property provide identity protection on its own but may inherit such property
from a security protocol underneath that actually features identity from a security protocol underneath that actually features identity
protection. On the other hand, it is expected that MIKEY-DHHMAC is protection.
typically being deployed within SDP/SIP ([20], [5]); both those
protocols do not provide end-to-end identity protection either.
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 supply security protocol (see section 3.1) provide the option not to supply
identity information. This option is only applicable if some other means identity information. This option is only applicable if some other means
are available of supplying trustworthy identity information; e.g., by are available of supplying trustworthy identity information; e.g., by
relying on secured links underneath of MIKEY that supply trustworthy relying on secured links underneath of MIKEY that supply trustworthy
identity information otherwise. However, it is understood that without identity information otherwise. However, it is understood that without
identity information present, the MIKEY key management security identity information present, the MIKEY key management security
protocols might be subject to security weaknesses such as masquerade, protocols might be subject to security weaknesses such as masquerade,
impersonation and reflection attacks particularly in end-to-end impersonation and reflection attacks particularly in end-to-end
scenarios where no other secure means of assured identity information scenarios where no other secure means of assured identity information
is provided. is provided.
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
Leaving identity fields optional if possible thus should not be seen Leaving identity fields optional if possible thus should not be seen
as a privacy method either, but rather as a protocol optimization as a privacy method either, but rather as a protocol optimization
feature. feature.
HMAC-authenticated Diffie-Hellman for MIKEY March 2005
5.3. Security features and properties 5.3. Security features and properties
With the security threats in mind, this draft provides the following With the security threats in mind, this 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 management This is achieved using an authenticated Diffie-Hellman key management
protocol. protocol.
* Peer-entity authentication (mutual): * Peer-entity authentication (mutual):
skipping to change at page 20, line 43 skipping to change at page 19, line 39
Note: This document does not address issues regarding authorization; Note: This document does not address issues regarding authorization;
this feature is not provided explicitly. However, DHHMAC authentication this feature is not provided explicitly. However, DHHMAC authentication
means support and facilitate realization of authorization means (local means support and facilitate realization of authorization means (local
issue). issue).
* Cryptographic integrity check: * Cryptographic integrity check:
The cryptographic integrity check is achieved using a message digest The cryptographic integrity check is achieved using a message digest
(keyed HMAC). It includes the exchanged Diffie-Hellman half-keys but (keyed HMAC). It includes the exchanged Diffie-Hellman half-keys but
covers the other parts of the exchanged message as well. Both mutual covers the other parts of the exchanged message as well. Both mutual
peer entity authentication and message integrity provide effective peer entity authentication and message integrity provide effective
countermeasure against man-in-the-middle attacks. countermeasures against man-in-the-middle attacks.
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
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 of response message did not arrive in a timely manner. This is to detect
entire messages. deletion of entire messages.
* Replay protection of the messages is achieved using embedded * Replay protection of the messages is achieved using embedded
HMAC-authenticated Diffie-Hellman for MIKEY March 2005
timestamps. In order to detect replayed messages it is essential that timestamps. In order to detect replayed messages it is essential that
the clocks among initiator and sender be roughly synchronized. The 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 reader is referred to [3] section 5.4 and [3] section 9.3 that provide
further considerations and give guidance on clock synchronization and further considerations and give guidance on clock synchronization and
timestamp usage. Should the clock synchronization be lost, then end timestamp usage. Should the clock synchronization be lost, then end
systems cannot detect replayed messages anymore resulting that the end systems cannot detect replayed messages anymore resulting that the end
systems cannot securely establish keying material. This may result in systems cannot securely establish keying material. This may result in
a denial-of-service, see [3] section 9.5. a denial-of-service, see [3] section 9.5.
* Limited DoS protection: * Limited DoS protection:
skipping to change at page 22, line 5 skipping to change at page 20, line 41
protocols, the Diffie-Hellman key agreement protocol features a protocols, the Diffie-Hellman key agreement protocol features a
security property called perfect forward secrecy. That is, that even security property called perfect forward secrecy. That is, that even
if the long-term pre-shared key would be compromised at some point in if the long-term pre-shared key would be compromised at some point in
time, this would not render past or future session keys compromised. time, this would not render past or future session keys compromised.
Neither the MIKEY pre-shared nor the MIKEY public-key protocol variants Neither the MIKEY pre-shared nor the MIKEY public-key protocol variants
are able to provide the security property of perfect-forward secrecy. are able to provide the security property of perfect-forward secrecy.
Thus, none of the other MIKEY protocols is able to substitute the Thus, none of the other MIKEY protocols is able to substitute the
Diffie-Hellman PFS property. Diffie-Hellman PFS property.
HMAC-authenticated Diffie-Hellman for MIKEY January 2005 As such, DHHMAC, as well asdigitally signed DH, provides a far superior
As such, DHHMAC but also digitally signed DH provides a far superior
security level over the pre-shared or public-key based key distribution security level over the pre-shared or public-key based key distribution
protocol in that respect. protocol in that respect.
* Fair, mutual key contribution: * Fair, mutual key contribution:
HMAC-authenticated Diffie-Hellman for MIKEY March 2005
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 to distribution protocol per se with the initiator distributing a key to
its peers. Actually, both parties involved in the protocol exchange its peers. Actually, both parties involved in the protocol exchange
are able to equally contribute to the common Diffie-Hellman TEK traffic are able to equally contribute to the common Diffie-Hellman TEK traffic
generating key. This reduces the risk of either party cheating or generating key. This reduces the risk of either party cheating or
unintentionally generating a weak session key. This makes the DHHMAC unintentionally generating a weak session key. This makes the DHHMAC
a fair key agreement protocol. One may view this property as an a fair key agreement protocol. One may view this property as an
additional distributed security measure that is increasing security additional distributed security measure that is increasing security
robustness over the case where all the security depends just on the robustness over the case where all the security depends just on the
proper implementation of a single entity. proper implementation of a single entity.
skipping to change at page 22, line 33 skipping to change at page 21, line 28
In order for Diffie-Hellman key agreement to be secure, each party SHALL In order for Diffie-Hellman key agreement to be secure, each party SHALL
generate its xi or xr values using a strong, unpredictable pseudo-random generate its xi or xr values using a strong, unpredictable pseudo-random
generator if a source of true randomness is not available. Further, generator if a source of true randomness is not available. Further,
these values xi or xr SHALL be kept private. It is RECOMMENDED that these values xi or xr SHALL be kept private. It is RECOMMENDED that
these secret values be destroyed once the common Diffie-Hellman shared these secret values be destroyed once the common Diffie-Hellman shared
secret key has been established. 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. Other protocol securely establishes a TGK within just one roundtrip. Other
existing key management techniques like IPsec-IKE [14], IPsec-IKEv2 existing key management techniques like IPsec-IKE [14], IPsec-IKEv2 [21]
[21] and TLS [13] and other schemes are not deemed adequate in addressing and TLS [13] and other schemes are not deemed adequate in addressing
sufficiently those real-time and security requirements; they all use sufficiently those real-time and security requirements; they all use
more than a single roundtrip. All the MIKEY key management protocols more than a single roundtrip. All the MIKEY key management protocols
are able to complete their task of security policy parameter negotiation are able to complete their task of security policy parameter negotiation
including key-agreement or key distribution in one roundtrip. However, including key-agreement or key distribution in one roundtrip. However,
the MIKEY pre-shared and the MIKEY public-key protocol both are able the MIKEY pre-shared and the MIKEY public-key protocol both are able
to complete their task even in a half-round trip when the confirmation to complete their task even in a half-round trip when the confirmation
messages are omitted. messages are omitted.
Using HMAC in conjunction with a strong one-way hash function such as Using HMAC in conjunction with a strong one-way hash function such as
SHA1 may be achieved more efficiently in software than expensive SHA1 may be achieved more efficiently in software than expensive
public-key operations. This yields a particular performance benefit public-key operations. This yields a particular performance benefit
of DHHMAC over signed DH or the public-key encryption protocol. of DHHMAC over signed DH or the public-key encryption protocol.
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
If a very high security level is desired for long-term secrecy of the If a very high security level is desired for long-term secrecy of the
negotiated Diffie-Hellman shared secret, longer hash values may be negotiated Diffie-Hellman shared secret, longer hash values may be
deployed such as SHA256, SHA384 or SHA512 provide, possibly in deployed such as SHA256, SHA384 or SHA512 provide, possibly in
HMAC-authenticated Diffie-Hellman for MIKEY March 2005
conjunction with stronger Diffie-Hellman groups. This is left as for conjunction with stronger Diffie-Hellman groups. This is left as for
further study. further study.
For the sake of improved performance and reduced round trip delay either For the sake of improved performance and reduced round trip delay either
party may off-line pre-compute its public Diffie-Hellman half-key. party may off-line pre-compute its public Diffie-Hellman half-key.
On the other side and under reasonable conditions, DHHMAC consumes more On the other side and under reasonable conditions, DHHMAC consumes more
CPU cycles than the MIKEY pre-shared key distribution protocol. The CPU cycles than the MIKEY pre-shared key distribution protocol. The
same might hold true quite likely for the MIKEY public-key distribution same might hold true quite likely for the MIKEY public-key distribution
protocol (depending on choice of the private and public key lengths). protocol (depending on choice of the private and public key lengths).
skipping to change at page 24, line 5 skipping to change at page 23, line 5
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 complex standards and thus is believed to be much simpler than the more complex
PKI facilities. PKI facilities.
DHHMAC is particularly attractive in those environments where DHHMAC is particularly attractive in those environments where
provisioning of a pre-shared key has already been accomplished. provisioning of a pre-shared key has already been accomplished.
* NAT-friendliness: * NAT-friendliness:
HMAC-authenticated Diffie-Hellman for MIKEY January 2005 HMAC-authenticated Diffie-Hellman for MIKEY March 2005
DHHMAC is able to operate smoothly through firewall/NAT devices as long DHHMAC is able to operate smoothly through firewall/NAT devices as long
as the protected identity information of the end entity is not an IP as the protected identity information of the end entity is not an IP
/transport address. /transport address.
* Scalability: * Scalability:
Like the MIKEY signed Diffie-Hellman protocol, DHHMAC does not scale Like the MIKEY signed Diffie-Hellman protocol, DHHMAC does not scale
to any larger configurations beyond peer-to-peer groups. to any larger configurations beyond peer-to-peer groups.
5.4. Assumptions 5.4. Assumptions
skipping to change at page 25, line 5 skipping to change at page 24, line 5
* 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 digest, infeasible to find a message which corresponds to a given message digest,
or to find two different messages that produce the same message digest. or to find two different messages that produce the same message digest.
* the HMAC algorithm is secure and does not leak the auth_key. In * the HMAC algorithm is secure and does not leak the auth_key. In
particular, the security depends on the message authentication property particular, the security depends on the message authentication property
of the compression function of the hash function H when applied to single of the compression function of the hash function H when applied to single
blocks (see [6]). blocks (see [6]).
HMAC-authenticated Diffie-Hellman for MIKEY January 2005 HMAC-authenticated Diffie-Hellman for MIKEY March 2005
* a source capable of producing sufficiently many bits of (pseudo) * a source capable of producing sufficiently many bits of (pseudo)
randomness is available. randomness is available.
* the system upon which DHHMAC runs is sufficiently secure. * the system upon which DHHMAC runs is sufficiently secure.
5.5. Residual risk 5.5. Residual risk
Although these detailed assumptions are non-negligible, security experts Although these detailed assumptions are non-negligible, security experts
generally believe that all these assumptions are reasonable and that the generally believe that all these assumptions are reasonable and that the
assumptions made can be fulfilled in practice with little or no expenses. assumptions made can be fulfilled in practice with little or no expenses.
The mathematical and cryptographic assumptions upon the properties of the The mathematical and cryptographic assumptions of the properties of the
PRF, the Diffie-Hellman algorithm (discrete log-assumption), the HMAC and PRF, the Diffie-Hellman algorithm (discrete log-assumption), the HMAC
SHA1 algorithms have not been proved yet nor have they been disproved by algorithm and SHA1 algorithms have been neither proven or disproven at
the time of this writing. this time.
Thus, a certain residual risk remains, which might threaten the overall Thus, a certain residual risk remains, which might threaten the overall
security at some unforeseeable time in the future. security at some unforeseeable time in the future.
The DHHMAC would be compromised as soon as any of the listed assumptions The DHHMAC would be compromised as soon as any of the listed assumptions
do not hold anymore. do not hold anymore.
The Diffie-Hellman mechanism is a generic security technique that is not The Diffie-Hellman mechanism is a generic security technique that is not
only applicable to groups of prime order or of characteristic two. This only applicable to groups of prime order or of characteristic two. This
is because of the fundamental mathematical assumption that the discrete is because of the fundamental mathematical assumption that the discrete
skipping to change at page 25, line 37 skipping to change at page 24, line 37
do not hold anymore. do not hold anymore.
The Diffie-Hellman mechanism is a generic security technique that is not The Diffie-Hellman mechanism is a generic security technique that is not
only applicable to groups of prime order or of characteristic two. This only applicable to groups of prime order or of characteristic two. This
is because of the fundamental mathematical assumption that the discrete is because of the fundamental mathematical assumption that the discrete
logarithm problem is also a very hard one in general groups. This enables logarithm problem is also a very hard one in general groups. This enables
Diffie-Hellman to be deployed also for GF(p)*, for sub-groups of Diffie-Hellman to be deployed also for GF(p)*, for sub-groups of
sufficient size and for groups upon elliptic curves. RSA does not allow sufficient size and for groups upon elliptic curves. RSA does not allow
such generalization, as the core mathematical problem is a different one such generalization, as the core mathematical problem is a different one
(large integer factorization). (large integer factorization).
RSA asymmetric keys tend to become increasingly lengthy (1536 bits and RSA asymmetric keys tend to become increasingly lengthy (1536 bits and
more) and thus very computational intensive. Neverthess, elliptic curve more) and thus very computationally intensive. Neverthess, elliptic curve
Diffie-Hellman (ECDH) allows to cut-down key lengths substantially (say Diffie-Hellman (ECDH) allows to cut-down key lengths substantially (say
170 bits or more) while maintaining at least the security level and 170 bits or more) while maintaining at least the security level and
providing even significant performance benefits in practice. Moreover, providing even more significant performance benefits in practice.
it is believed that elliptic curve techniques provide much better Moreover, it is believed that elliptic curve techniques provide much
protection against side channel attacks due to the inherent redundancy better protection against side channel attacks due to the inherent
in the projective coordinates. For all these reasons, one may view HMAC-authenticated Diffie-Hellman for MIKEY March 2005
elliptic-curve-based Diffie-Hellman as being more "future-proof" and
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
redundancy in the projective coordinates. For all these reasons, one may
view elliptic-curve-based Diffie-Hellman as being more "future-proof" and
robust against potential threats than RSA. Note, that an elliptic-curve robust against potential threats than RSA. Note, that an elliptic-curve
Diffie-Hellman variant of MIKEY remains for further study. Diffie-Hellman variant of MIKEY remains for further study.
It is not recommended to deploy DHHMAC for any other usage than depicted It is not recommended to deploy DHHMAC for any other usage than depicted
in section 2. Otherwise any such misapplication might lead to unknown, in section 2. Otherwise any such misapplication might lead to unknown,
undefined properties. 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.
4.3.2. hold also for DHHMAC. However, as noted before, this key management hold also for DHHMAC. However, as noted before, this key management
protocol does not serve full groups. protocol does not serve full groups.
One may view the pre-established shared secret to yield some One may view the pre-established shared secret to yield some
pre-established trust relationship between the initiator and the pre-established trust relationship between the initiator and the
responder. This results in a much simpler trust model for DHHMAC than responder. This results in a much simpler trust model for DHHMAC than
would be the case for some generic group key management protocol and would be the case for some generic group key management protocol and
potential group entities without any pre-defined trust relationship. The potential group entities without any pre-defined trust relationship. The
common group controller in conjunction with the assumption of a shared common group controller in conjunction with the assumption of a shared
key simplifies the communication setup of the entities. key simplifies the communication setup of the entities.
One may view the pre-established trust relationship through the pre-shared One may view the pre-established trust relationship through the pre-shared
secret as some means for pre-granted, implied authorization. This secret as some means for pre-granted, implied authorization. This
document does not define any particular authorization means but leaves document does not define any particular authorization means but leaves
this subject to the application. this subject to the application.
6. Acknowledgments 6. Acknowledgments
This document incorporates kindly valuable review feedback from Steffen This document incorporates kindly valuable review feedback from Steffen
Fries, Hannes Tschofenig, Fredrick Lindholm and Russell Housley and Fries, Hannes Tschofenig, Fredrick Lindholm, Mary Barnes and Russell
general feedback by the MSEC WG. Housley and general feedback by the MSEC WG.
Conclusions
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
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
schemes are not deemed adequate in addressing sufficiently those real-time
and security requirements.
MIKEY defines three key management security protocols addressing
real-time constraints. DHHMAC as described in this document defines a
fourth MIKEY variant aiming at the same target.
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.
It is concluded that DHHMAC features useful security and performance
properties that none of the other three MIKEY variants is able to provide.
7. IANA considerations 7. IANA considerations
HMAC-authenticated Diffie-Hellman for MIKEY March 2005
This document does not define its own new name spaces for DHHMAC, beyond 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 the IANA name spaces that have been assigned for MIKEY, see [3] section
10 and section 10.1. 10 and section 10.1, see also IANA MIKEY payload name spaces [37].
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):
* data type (Table 4.1.a); to be aligned with [3] table 6.1.a. In order to align Table 4.1.a with [3] table 6.1.a, IANA is requested to
add the following entries to their MIKEY Payload Name Space:
Data Type Value Reference
--------------- ----- ---------
DHHMAC init 7 [RFCxxxx]
DHHMAC resp 8 [RFCxxxx]
[Note to the RFC editor: Please replace RFCxxxx with the RFC number of this
document prior to publication.]
8. References 8. References
8.1 Normative References 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.
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
[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.
[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.
HMAC-authenticated Diffie-Hellman for MIKEY March 2005
8.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.
[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.
2000. ftp://ftp.inf.ethz.ch/pub/crypto/publications/MauWol00c.ps 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:
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
"Randomness Requirements for Security"; "Randomness Requirements for Security";
<draft-eastlake-randomness2-10.txt>; Work in Progress, IETF, <draft-eastlake-randomness2-10.txt>; Work in Progress, IETF,
January 2005. January 2005.
[16] J. Schiller: "Strong Security Requirements for Internet [16] J. Schiller: "Strong Security Requirements for Internet
Engineering Task Force Standard Protocols", RFC 3365, IETF, 2002. Engineering Task Force Standard Protocols", RFC 3365, IETF, 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, Security Analysis", Work in Progress,
<draft-irtf-cfrg-advice-00.txt>, IRTF, October 2002. <draft-irtf-cfrg-advice-00.txt>, IRTF, October 2002.
HMAC-authenticated Diffie-Hellman for MIKEY March 2005
[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-08.txt>, Authors", Work in Progress, <draft-rfc-editor-rfc2223bis-08.txt>,
IETF, August 2004. 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.
skipping to change at page 30, line 4 skipping to change at page 28, line 37
[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", "Group Secure Association Key Management Protocol",
<draft-ietf-msec-gsakmp-sec-07.txt>, Internet Draft, Work in <draft-ietf-msec-gsakmp-sec-07.txt>, Internet Draft, Work in
Progress (MSEC WG). Progress (MSEC WG).
[26] Baugher, M., Canetti, R., Dondeti, L., and Lindholm, F.: "Group [26] Baugher, M., Canetti, R., Dondeti, L., and Lindholm, F.: "Group
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
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).
[27] Baugher, McGrew, Oran, Blom, Carrara, Naslund: "The Secure Real-time [27] Baugher, McGrew, Oran, Blom, Carrara, Naslund: "The Secure Real-time
Transport Protocol", RFC 3711, IETF, March 2004. Transport Protocol", RFC 3711, IETF, March 2004.
[28] ITU-T Recommendation H.235V3Amd1 Corr1, "Security and encryption for [28] ITU-T Recommendation H.235V3Amd1 Corr1, "Security and encryption for
H-series (H.323 and other H.245-based) multimedia terminals", H-series (H.323 and other H.245-based) multimedia terminals",
(01/2005). (01/2005).
HMAC-authenticated Diffie-Hellman for MIKEY March 2005
[29] C. Adams et al: "Internet X.509 Public Key Infrastructure Certificate [29] C. Adams et al: "Internet X.509 Public Key Infrastructure Certificate
Management Protocols"; draft-ietf-pkix-rfc2510bis-09.txt, Management Protocols"; draft-ietf-pkix-rfc2510bis-09.txt,
Internet Draft, Work in Progress (PKIX WG). Internet Draft, Work in Progress (PKIX WG).
[30] M. Myers et al: "X.509 Internet Public Key Infrastructure Online [30] M. Myers et al: "X.509 Internet Public Key Infrastructure Online
Certificate Status Protocol - OCSP", RFC 2560, IETF, June 1999. Certificate Status Protocol - OCSP", RFC 2560, IETF, June 1999.
[31] C. Adams et al: "Internet X.509 Public Key Infrastructure Data [31] C. Adams et al: "Internet X.509 Public Key Infrastructure Data
Validation and Certification Server Protocols", RFC 3029, IETF, Validation and Certification Server Protocols", RFC 3029, IETF,
February 2001. February 2001.
skipping to change at page 30, line 41 skipping to change at page 29, line 32
Certification Path Building", Certification Path Building",
<draft-ietf-pkix-certpathbuild-05.txt>, Internet Draft, Work in <draft-ietf-pkix-certpathbuild-05.txt>, Internet Draft, Work in
Progress (PKIX WG). Progress (PKIX WG).
[34] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667, [34] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667,
February 2004. February 2004.
[35] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP [35] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP
79, RFC 3668, February 2004. 79, RFC 3668, February 2004.
[36] J. Rosenberg, H. Schulzrinne: "An Offer/Answer Model with the Session
Description Protocol (SDP)", RFC 3264, IETF, June 2002.
[37] IANA MIKEY Payload Name Spaces per [RFC3830], see
http://www.iana.org/assignments/mikey-payloads
Appendix A Usage of MIKEY-DHHMAC in H.235
This appendix provides informative overview how MIKEY-DHHMAC can be
applied in some H.323-based multimedia environments. Generally, MIKEY
is applicable for multimedia applications including IP telephony. [22]
describes various use cases of the MIKEY key management protocols
(MIKEY-PS, MIKEY-PK, MIKEY-DHSIGN and MIKEY-DHHMAC) with the purpose to
establish TGK keying material among H.323 endpoints. The TGKs are then
HMAC-authenticated Diffie-Hellman for MIKEY March 2005
used for media encryption by applying SRTP [27]. Addressed scenarios
include point-to-point with one or more intermediate gatekeepers (trusted
or partially trusted) in-between.
One particular use case addresses MIKEY-DHHMAC to establish a media
connection from an endpoint B calling (through a gatekeeper) to 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, some separate
protocol exchange means are achieved outside the actual call setup
procedure to establish an auth_key for the time while endpoints are being
registered with the gatekeeper; such protocols exist [22] but are not
shown in this document. The auth_key between the endpoints is being used
to authenticate and integrity protect the MIKEY-DHHMAC messages.
To establish a call, it is assumed that endpoint B has obtained permission
from the gatekeeper (not shown). Endpoint B as the caller builds the
MIKEY-DHHMAC I_message(see section 3) and sends the I_message
encapsulated within the H.323-SETUP to endpoint A. A routing gatekeeper
(GK) would forward this message to endpoint B; in case of a non-routing
gatekeeper, endpoint B sends the SETUP directly to endpoint A. In either
case, H.323 inherent security mechanisms [28] are applied to protect the
(encapsulation) message during transfer. This is not depicted here. The
receiving endpoint A is 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 MIKEY-DHHMAC R_message and sends the response as part of the
CallProceeding-to-Connect message back to the calling endpoint B
(possibly through a routing gatekeeper). Endpoint B processes the
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])
2.) EP-A -> (GK) -> EP-B: CallProceeding-to-CONNECT(R_fwd_message [,
R_rev_message])
Notes: If it is necessary to establish directional TGKs for full-
duplex links in both directions B->A and A->B, then the calling
endpoint B instantiates the DHHMAC protocol twice: once in the
direction B->A using I_fwd_message and another run in parallel
in the direction A->B using I_rev_message. In that case, two
MIKEY-DHHMAC I_messages are encapsulated within SETUP
HMAC-authenticated Diffie-Hellman for MIKEY March 2005
(I_fwd_message and I_rev_message) and two MIKEY-DHHMAC
R_messages (R_fwd_message and R_rev_message) are encapsulted
within CallProceeding-to-CONNECT. The I_rev_message
corresponds with the I_fwd_message.
Alternatively, the called endpoint A may instantiate the DHHMAC
protocol in a separate run with endpoint B (not shown); however,
this requires a third handshake to complete.
For more details on how the MIKEY protocols may be deployed with
H.235, please refer to [22].
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject to Copyright (C) The Internet Society (2004). This document is subject to
the rights, licenses and restrictions contained in BCP 78, and except as the rights, licenses and restrictions contained in BCP 78, and except as
set forth therein, the authors retain all their rights. set forth therein, the authors retain all their rights.
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
This document and the information contained herein are provided on an "AS This document and the information contained herein are provided on an "AS
IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS
SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE. FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Rights Intellectual Property Rights
skipping to change at page 31, line 28 skipping to change at page 32, line 4
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in this pertain to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or document or the extent to which any license under such rights might or
might not be available; nor does it represent that it has made any might not be available; nor does it represent that it has made any
independent effort to identify any such rights. Information on the independent effort to identify any such rights. Information on the
procedures with respect to rights in ISOC Documents can be found in BCP procedures with respect to rights in ISOC Documents can be found in BCP
78 and BCP 79. 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances Copies of IPR disclosures made to the IETF Secretariat and any assurances
of licenses to be made available, or the result of an attempt made to obtain of licenses to be made available, or the result of an attempt made to obtain
HMAC-authenticated Diffie-Hellman for MIKEY March 2005
a general license or permission for the use of such proprietary rights a general license or permission for the use of such proprietary rights
by implementers or users of this specification can be obtained from the by implementers or users of this specification can be obtained from the
IETF on-line IPR repository at http://www.ietf.org/ipr. IETF on-line IPR repository 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 rights copyrights, patents or patent applications, or other proprietary rights
that may cover technology that may be required to implement this standard. that may cover technology that may be required to implement this standard.
Please address the information to the IETF at 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 July 2005. This Internet Draft expires on 30 September 2005.
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
[Note to the RFC editor: Please remove the entire following section prior [Note to the RFC editor: Please remove the entire following section prior
to publication.] to publication.]
Revision History Revision History
Changes against draft-ietf-msec-mikey-dhhmac-09.txt:
*IESG review feedback incorporated; generally, only editorial
corrections.
* Section 2.1.1 moved into new Appendix A.
* IANA considerations section reworked and clarified.
Changes against draft-ietf-msec-mikey-dhhmac-08.txt: Changes against draft-ietf-msec-mikey-dhhmac-08.txt:
* PKIX removed; some minor editorials. * PKIX removed; some minor editorials.
Changes against draft-ietf-msec-mikey-dhhmac-07.txt: Changes against draft-ietf-msec-mikey-dhhmac-07.txt:
* Feedback addressed from AD review. * Feedback addressed from AD review.
* added considerations on the possible impact of PKIX protocols and * added considerations on the possible impact of PKIX protocols and
operations to end systems with real-time constraints (section 1). operations to end systems with real-time constraints (section 1).
* added note that DH group is transmitted explicitly but not the parameters * added note that DH group is transmitted explicitly but not the parameters
g and p; see section 3. g and p; see section 3.
* added considerations on clock synchronization and timestamps in section * added considerations on clock synchronization and timestamps in section
2 and in section 5.3 in the view of consequences on replay protection. 2 and in section 5.3 in the view of consequences on replay protection.
HMAC-authenticated Diffie-Hellman for MIKEY March 2005
* references updated. * references updated.
* editorial corrections and cleanup. * 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 section beginning), status of Memo, and Intellectual Property Rights section
in accordance with RFC 3667, RFC 3668. in accordance with RFC 3667, RFC 3668.
* ID nits removal. * ID nits removal.
skipping to change at page 33, line 5 skipping to change at page 33, line 30
* New section 4.4 added that describes the use of the general extension * New section 4.4 added that describes the use of the general extension
payload to avoid bidding-down attacks. payload to avoid bidding-down attacks.
* Description of the bidding-down avoidance mechanism removed from the * Description of the bidding-down avoidance mechanism removed from the
threat model in section 5.2. 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 January 2005
* 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.
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 for * Introduction section modified: PFS property of DH, requirement for
4th MIKEY key management variant motivated. 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 a use * New section 2.1.1 "Usage in H.235" added: this section outlines a use
case of DHHMAC in the context of H.235. case of DHHMAC in the context of H.235.
HMAC-authenticated Diffie-Hellman for MIKEY March 2005
* 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:
skipping to change at page 34, line 4 skipping to change at page 34, line 29
* 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).
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
* optional [X], [X, Y] defined and clarified (see section 1.1, * optional [X], [X, Y] defined and clarified (see section 1.1,
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).
* 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:
HMAC-authenticated Diffie-Hellman for MIKEY March 2005
* category set to proposed standard. * category set to proposed standard.
* identity protection clarified. * identity protection clarified.
* aligned with MIKEY-05 DH protocol, notation and with payload * aligned with MIKEY-05 DH protocol, notation and with payload
* some editorials and nits. * some editorials and nits.
Changes against draft-euchner-mikey-dhhmac-00.txt: Changes against draft-euchner-mikey-dhhmac-00.txt:
* made a MSEC WG draft * made a MSEC WG draft
* aligned with MIKEY-03 DH protocol, notation and with payload * aligned with MIKEY-03 DH protocol, notation and with payload
formats formats
skipping to change at page 35, line 4 skipping to change at page 35, line 28
rather than the SHA1 intermediate value. rather than the SHA1 intermediate value.
* improved security considerations section completely rewritten in * improved security considerations section completely rewritten in
the spirit of [8]. the spirit of [8].
* IANA consideration section added * IANA consideration section added
* 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
HMAC-authenticated Diffie-Hellman for MIKEY January 2005
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
81359 Munich, Germany 81359 Munich, Germany
 End of changes. 

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