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

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