draft-ietf-msec-mikey-dhhmac-03.txt   draft-ietf-msec-mikey-dhhmac-04.txt 
HMAC-authenticated Diffie-Hellman for MIKEY July 2003 HMAC-authenticated Diffie-Hellman for MIKEY October 2003
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: January 2004 July 2003 Expires: March 2004 October 2003
HMAC-authenticated Diffie-Hellman for MIKEY HMAC-authenticated Diffie-Hellman for MIKEY
<draft-ietf-msec-mikey-dhhmac-03.txt> <draft-ietf-msec-mikey-dhhmac-04.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1]. all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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.
Abstract Abstract
This document describes a point-to-point key management protocol This document describes a point-to-point key management protocol
variant for the multimedia Internet keying (MIKEY). In particular, variant for the multimedia Internet keying (MIKEY). In particular,
the classic Diffie-Hellman key agreement protocol is used for key the classic Diffie-Hellman key agreement protocol is used for key
establishment in conjunction with a keyed hash (HMAC-SHA1) for establishment in conjunction with a keyed hash (HMAC-SHA1) for
HMAC-authenticated Diffie-Hellman for MIKEY July 2003 HMAC-authenticated Diffie-Hellman for MIKEY October 2003
achieving mutual authentication and message integrity of the key achieving mutual authentication and message integrity of the key
management messages exchanged. This MIKEY variant is called the management messages exchanged. This MIKEY variant is called the
HMAC-authenticated Diffie-Hellmann (DHHMAC). It addresses the HMAC-authenticated Diffie-Hellmann (DHHMAC). It addresses the
security and performance constraints of multimedia key management in security and performance constraints of multimedia key management in
MIKEY. 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",
skipping to change at page 3, line 4 skipping to change at page 3, line 4
IANA considerations.............................................22 IANA considerations.............................................22
Intellectual Property Rights....................................22 Intellectual Property Rights....................................22
References......................................................23 References......................................................23
Normative References............................................23 Normative References............................................23
Informative References..........................................24 Informative References..........................................24
Acknowledgments.................................................25 Acknowledgments.................................................25
Conclusions.....................................................25 Conclusions.....................................................25
Full Copyright Statement........................................26 Full Copyright Statement........................................26
Expiration Date.................................................27 Expiration Date.................................................27
Revision History................................................27 Revision History................................................27
HMAC-authenticated Diffie-Hellman for MIKEY July 2003 HMAC-authenticated Diffie-Hellman for MIKEY October 2003
Author's Addresses..............................................28 Author's Addresses..............................................28
1. Introduction 1. Introduction
There is work done in IETF to develop key management schemes. For There is work done in IETF to develop key management schemes. For
example, IKE [14] is a widely accepted unicast scheme for IPsec, and example, IKE [14] is a widely accepted unicast scheme for IPsec, and
the MSEC WG is developing other schemes, addressed to group the MSEC WG is developing other schemes, addressed to group
communication [24], [25]. For reasons discussed below, there is communication [24], [25]. For reasons discussed below, there is
however a need for a scheme with low latency, suitable for demanding however a need for a scheme with low latency, suitable for demanding
skipping to change at page 4, line 4 skipping to change at page 4, line 4
signatures and certificates. signatures and certificates.
All these three key management protocols are designed such that they All these three key management protocols are designed such that they
complete their work within just one round trip. This requires complete their work within just one round trip. This requires
depending on loosely synchronized clocks and deploying timestamps depending on loosely synchronized clocks and deploying timestamps
within the key management protocols. within the key management protocols.
However, it is known [7] that each of the three key management However, it is known [7] that each of the three key management
schemes has its subtle constraints and limitations: schemes has its subtle constraints and limitations:
- The symmetric key distribution protocol is simple to - The symmetric key distribution protocol is simple to
HMAC-authenticated Diffie-Hellman for MIKEY July 2003 HMAC-authenticated Diffie-Hellman for MIKEY October 2003
implement but does not nicely scale in any larger configuration implement but does not nicely scale in any larger configuration
of potential peer entities due to the need of mutually pre- of potential peer entities due to the need of mutually pre-
assigned shared master secrets. assigned shared master secrets.
Moreover, the security provided does not achieve the property Moreover, the security provided does not achieve the property
of perfect forward secrecy; i.e. compromise of the shared of perfect forward secrecy; i.e. compromise of the shared
master secret would render past and even future session keys master secret would render past and even future session keys
susceptible to compromise. susceptible to compromise.
skipping to change at page 5, line 5 skipping to change at page 5, line 5
- The third MIKEY key management protocol deploys the Diffie- - The third MIKEY key management protocol deploys the Diffie-
Hellman key agreement scheme and authenticates the exchange of Hellman key agreement scheme and authenticates the exchange of
the Diffie-Hellman half-keys in each direction by using a the Diffie-Hellman half-keys in each direction by using a
digital signature upon. As in the previous method, this digital signature upon. As in the previous method, this
introduces the dependency upon a public-key infrastructure with introduces the dependency upon a public-key infrastructure with
its strength on scalability but also the limitations on its strength on scalability but also the limitations on
computational costs in performing the asymmetric long-integer computational costs in performing the asymmetric long-integer
operations and the potential need for additional communication operations and the potential need for additional communication
for verification of the digital certificates. for verification of the digital certificates.
HMAC-authenticated Diffie-Hellman for MIKEY July 2003 HMAC-authenticated Diffie-Hellman for MIKEY October 2003
However, the Diffie-Hellman key agreement protocol is known for However, the Diffie-Hellman key agreement protocol is known for
its subtle security strengths in that it is able to provide its subtle security strengths in that it is able to provide
full perfect secrecy and further have both parties actively full perfect secrecy and further have both parties actively
involved in session key generation. involved in session key generation.
This document describes a fourth key management scheme for MIKEY that This document describes a fourth key management scheme for MIKEY that
could somehow be seen as a synergetic optimization between the pre- could somehow be seen as a synergetic optimization between the pre-
shared key distribution scheme and the Diffie-Hellman key agreement. shared key distribution scheme and the Diffie-Hellman key agreement.
skipping to change at page 6, line 5 skipping to change at page 6, line 5
All large integer computations in this document should be understood All large integer computations in this document should be understood
as being mod p within some fixed group G for some large prime p; see as being mod p within some fixed group G for some large prime p; see
[3] section 3.3; however, the DHHMAC protocol is applicable in [3] section 3.3; however, the DHHMAC protocol is applicable in
general to other appropriate finite, cyclical groups as well. general to other appropriate finite, cyclical groups as well.
It is assumed that a pre-shared key s is known by both entities It is assumed that a pre-shared key s is known by both entities
(initiator and responder). The authentication key auth_key is (initiator and responder). The authentication key auth_key is
derived from the pre-shared secret s using the pseudo-random function derived from the pre-shared secret s using the pseudo-random function
PRF; see [3] sections 4.1.3 and 4.1.5. PRF; see [3] sections 4.1.3 and 4.1.5.
HMAC-authenticated Diffie-Hellman for MIKEY July 2003 HMAC-authenticated Diffie-Hellman for MIKEY October 2003
In this text, [X] represents an optional piece of information. In this text, [X] represents an optional piece of information.
Generally throughout the text, X SHOULD be present unless certain Generally throughout the text, X SHOULD be present unless certain
circumstance MAY allow X being optional and not be present thereby circumstance MAY allow X being optional and not be present thereby
resulting in weaker security potentially. Likewise [X, Y] represents resulting in weaker security potentially. Likewise [X, Y] represents
an optional compound piece of information where the pieces X and Y an optional compound piece of information where the pieces X and Y
SHOULD be either both present or MAY optionally be both absent. SHOULD be either both present or MAY optionally be both absent.
1.2. Abbreviations 1.2. Abbreviations
skipping to change at page 7, line 4 skipping to change at page 7, line 4
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 Initiator xi secret, (pseudo) random Diffie-Hellman key of Initiator
xr secret, (pseudo) random Diffie-Hellman key of Responder xr secret, (pseudo) random Diffie-Hellman key of Responder
HMAC-authenticated Diffie-Hellman for MIKEY July 2003 HMAC-authenticated Diffie-Hellman for MIKEY October 2003
2. Scenario 2. Scenario
The HMAC-authenticated Diffie-Hellman key agreement protocol (DHHMAC) The HMAC-authenticated Diffie-Hellman key agreement protocol (DHHMAC)
for MIKEY addresses the same scenarios and scope as the other three for MIKEY addresses the same scenarios and scope as the other three
key management schemes in MIKEY address. key management schemes in MIKEY address.
DHHMAC is applicable in a peer-to-peer group where no access to a DHHMAC is applicable in a peer-to-peer group where no access to a
public-key infrastructure can be assumed available. Rather, pre- public-key infrastructure can be assumed available. Rather, pre-
shared master secrets are assumed available among the entities in shared master secrets are assumed available among the entities in
skipping to change at page 8, line 5 skipping to change at page 8, line 5
encapsulated and transported in SDP containers of the SDP encapsulated and transported in SDP containers of the SDP
offer/answer handshake, offer/answer handshake,
b) H.323 (see [22]) where the encoded MIKEY messages are transported b) H.323 (see [22]) where the encoded MIKEY messages are transported
in the H.225.0 fast start call signaling handshake. in the H.225.0 fast start call signaling handshake.
MIKEY-DHHMAC is offered as option to the other MIKEY key management MIKEY-DHHMAC is offered as option to the other MIKEY key management
variants (MIKEY-pre-shared, MIKEY-public-key and MIKEY-DH-SIGN) for variants (MIKEY-pre-shared, MIKEY-public-key and MIKEY-DH-SIGN) for
all those cases where DHHMAC has its peculiar strengths (see section all those cases where DHHMAC has its peculiar strengths (see section
5). 5).
HMAC-authenticated Diffie-Hellman for MIKEY July 2003 HMAC-authenticated Diffie-Hellman for MIKEY October 2003
3. DHHMAC Security Protocol 3. DHHMAC Security Protocol
The following figure defines the security protocol for DHHMAC: The following figure defines the security protocol for DHHMAC:
Initiator Responder Initiator Responder
I_message = HDR, T, RAND, [IDi], I_message = HDR, T, RAND, [IDi],
{SP}, DHi, KEMAC {SP}, DHi, KEMAC
I_message I_message
skipping to change at page 9, line 5 skipping to change at page 9, line 5
The group parameters (e.g., the group G) are a set of parameters The group parameters (e.g., the group G) are a set of parameters
chosen by the initiator. The responder chooses a (pseudo) random chosen by the initiator. The responder chooses a (pseudo) random
positive integer xr, and sends an HMACed message including g^(xr) positive integer xr, and sends an HMACed message including g^(xr)
and the timestamp to the initiator. The responder SHALL always and the timestamp to the initiator. The responder SHALL always
include the initiator's identity IDi regardless of whether the include the initiator's identity IDi regardless of whether the
I_message conveyed any IDi. It is recommended that the responder I_message conveyed any IDi. It is recommended that the responder
SHOULD always include the identity payload IDr within the SHOULD always include the identity payload IDr within the
R_message; unless the initiator can defer the reponder's identity R_message; unless the initiator can defer the reponder's identity
by some other means, then IDr MAY optionally be left out. by some other means, then IDr MAY optionally be left out.
HMAC-authenticated Diffie-Hellman for MIKEY July 2003 HMAC-authenticated Diffie-Hellman for MIKEY October 2003
Both parties then calculate the TGK, g^(xi * xr). Both parties then calculate the TGK, g^(xi * xr).
The HMAC authentication is due to provide authentication of the DH The HMAC authentication is due to provide authentication of the DH
half-keys, and is necessary to avoid man-in-the-middle attacks. half-keys, and is necessary to avoid man-in-the-middle attacks.
This approach is less expensive than digitally signed Diffie- This approach is less expensive than digitally signed Diffie-
Hellman. It requires first of all, that both sides compute one Hellman. It requires first of all, that both sides compute one
exponentiation and one HMAC, then one HMAC verification and finally exponentiation and one HMAC, then one HMAC verification and finally
another Diffie-Hellman exponentiation. another Diffie-Hellman exponentiation.
skipping to change at page 10, line 4 skipping to change at page 10, line 4
for DHHMAC update message. for DHHMAC update message.
Initiator Responder Initiator Responder
I_message = HDR, T, [IDi], I_message = HDR, T, [IDi],
{SP}, [DHi], KEMAC {SP}, [DHi], KEMAC
I_message I_message
-----------------------> R_message = HDR, T, -----------------------> R_message = HDR, T,
[IDr], IDi, [IDr], IDi,
[DHr, DHi], KEMAC [DHr, DHi], KEMAC
HMAC-authenticated Diffie-Hellman for MIKEY July 2003 HMAC-authenticated Diffie-Hellman for MIKEY October 2003
R_message R_message
<---------------------- <----------------------
[TGK = g^(xi * yi)] [TGK = g^(xi * yi)] [TGK = g^(xi * yi)] [TGK = g^(xi * yi)]
Figure 2: DHHMAC update message Figure 2: DHHMAC update message
TGK re-keying supports two procedures: TGK re-keying supports two procedures:
a) True re-keying by exchanging new and fresh Diffie-Hellman half- a) True re-keying by exchanging new and fresh Diffie-Hellman half-
skipping to change at page 11, line 4 skipping to change at page 11, line 4
* 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
* ID payload, [3] section 6.7 * ID payload, [3] section 6.7
HMAC-authenticated Diffie-Hellman for MIKEY July 2003 HMAC-authenticated Diffie-Hellman for MIKEY October 2003
* 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)
skipping to change at page 12, line 5 skipping to change at page 12, line 5
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
Other defined next payload values defined in [3] SHALL not be Other defined next payload values defined in [3] SHALL not be
applied to DHHMAC. applied to DHHMAC.
HMAC-authenticated Diffie-Hellman for MIKEY July 2003 HMAC-authenticated Diffie-Hellman for MIKEY October 2003
The responder in case of a decoding error or of a failed HMAC The responder in case of a decoding error or of a failed HMAC
authentication verification SHALL apply the Error payload data authentication verification SHALL apply the Error payload data
type. type.
4.2. Key data transport payload (KEMAC) 4.2. Key data transport payload (KEMAC)
DHHMAC SHALL apply this payload for conveying the HMAC result along DHHMAC SHALL apply this payload for conveying the HMAC result along
with the indicated authentication algorithm. KEMAC when used in with the indicated authentication algorithm. KEMAC when used in
conjunction with DHHMAC SHALL not convey any encrypted data; thus conjunction with DHHMAC SHALL not convey any encrypted data; thus
skipping to change at page 13, line 5 skipping to change at page 13, line 5
HMAC-SHA-1-96 produces a slightly shorter HMAC result where the HMAC-SHA-1-96 produces a slightly shorter HMAC result where the
HMAC-SHA-1 result SHALL be truncated to the 96 leftmost bits when HMAC-SHA-1 result SHALL be truncated to the 96 leftmost bits when
represented in network byte order. This saves some bandwidth. represented in network byte order. This saves some bandwidth.
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.
HMAC-authenticated Diffie-Hellman for MIKEY July 2003 HMAC-authenticated Diffie-Hellman for MIKEY October 2003
5. Security Considerations 5. Security Considerations
This document addresses key management security issues throughout. This document addresses key management security issues throughout.
For a comprehensive explanation of MIKEY security considerations, For a comprehensive explanation of MIKEY security considerations,
please refer to MIKEY [3] section 9. please refer to MIKEY [3] section 9.
In addition to that, this document addresses security issues In addition to that, this document addresses security issues
according to [8] where the following security considerations apply in according to [8] where the following security considerations apply in
particular to this document: particular to this document:
skipping to change at page 14, line 5 skipping to change at page 14, line 5
possibility that MIKEY DHHMAC be deployed in a corporate, closed IP possibility that MIKEY DHHMAC be deployed in a corporate, closed IP
environment. This also includes the possibility that MIKEY DHHMAC be environment. This also includes the possibility that MIKEY DHHMAC be
deployed on a hop-by-hop basis with some intermediate trusted "MIKEY deployed on a hop-by-hop basis with some intermediate trusted "MIKEY
DHHMAC proxies" involved. DHHMAC proxies" involved.
Since DHHMAC is a key management protocol, the following security Since DHHMAC is a key management protocol, the following security
threats are of concern: threats are of concern:
* Unauthorized interception of plain TGKs. * Unauthorized interception of plain TGKs.
HMAC-authenticated Diffie-Hellman for MIKEY July 2003 HMAC-authenticated Diffie-Hellman for MIKEY October 2003
This threat shall not occur. Nevertheless, for DHHMAC this threat This threat shall not occur. Nevertheless, for DHHMAC this threat
does not occur since the TGK is not actually transmitted on the does not occur since the TGK is not actually transmitted on the
wire (not even in encrypted fashion). wire (not even in encrypted fashion).
* Eavesdropping of other, transmitted keying information: * Eavesdropping of other, transmitted keying information:
DHHMAC protocol does not explicitly transmit the TGK at all. DHHMAC protocol does not explicitly transmit the TGK at all.
Rather, by the Diffie-Hellman "encryption" operation, that conceals Rather, by the Diffie-Hellman "encryption" operation, that conceals
the secret (pseudo) random values, only partial information (i.e. the secret (pseudo) random values, only partial information (i.e.
the DH- half key) for construction of the TGK is transmitted. It the DH- half key) for construction of the TGK is transmitted. It
skipping to change at page 15, line 4 skipping to change at page 15, line 4
cannot be avoided they must be detected at least. DHHMAC addresses cannot be avoided they must be detected at least. DHHMAC addresses
this threat by providing message integrity. this threat by providing message integrity.
* Bidding-down attacks: * Bidding-down attacks:
When multiple key management protocols each of a distinct security When multiple key management protocols each of a distinct security
level are offered (e.g., such as is possible by SDP [5]), avoiding level are offered (e.g., such as is possible by SDP [5]), avoiding
bidding-down attacks is of concern. DHHMAC addresses this threat bidding-down attacks is of concern. DHHMAC addresses this threat
by reusing the MIKEY mechanism as described in [3] section 7.1, by reusing the MIKEY mechanism as described in [3] section 7.1,
where all key management protocol identifiers must be listed within where all key management protocol identifiers must be listed within
the MIKEY General Extension Payload. The protocol identifier for the MIKEY General Extension Payload. The protocol identifier for
HMAC-authenticated Diffie-Hellman for MIKEY July 2003 HMAC-authenticated Diffie-Hellman for MIKEY October 2003
DHHMAC shall be "mikeydhhmac". The General Extension Payload must DHHMAC shall be "mikeydhhmac". The General Extension Payload must
be integrity-protected with the HMAC using the shared secret. be integrity-protected with the HMAC using the shared secret.
Some potential threats are not within the scope of this threat model: Some potential threats are not within the scope of this threat model:
* Passive and off-line cryptanalysis of the Diffie-Hellman algorithm: * Passive and off-line cryptanalysis of the Diffie-Hellman algorithm:
Under certain reasonable assumptions (see 5.4 below) it is widely Under certain reasonable assumptions (see 5.4 below) it is widely
believed that DHHMAC is sufficiently secure and that such attacks believed that DHHMAC is sufficiently secure and that such attacks
be infeasible although the possibility of a successful attack be infeasible although the possibility of a successful attack
skipping to change at page 16, line 4 skipping to change at page 16, line 4
protection on its own but may inherit such property from a security protection on its own but may inherit such property from a security
protocol underneath that actually features identity protection. On protocol underneath that actually features identity protection. On
the other hand, it is expected that MIKEY-DHHMAC is typically being the other hand, it is expected that MIKEY-DHHMAC is typically being
deployed within SDP/SIP ([20], [5]); both those protocols do not deployed within SDP/SIP ([20], [5]); both those protocols do not
provide end-to-end identity protection. provide end-to-end identity protection.
The DHHMAC security protocol (see section 3) and the TGK re-keying The DHHMAC security protocol (see section 3) and the TGK re-keying
security protocol (see section 3.1) provide the option not to security protocol (see section 3.1) provide the option not to
supply identity information. This option is only applicable if supply identity information. This option is only applicable if
some other means are available of supplying trustworthy identity some other means are available of supplying trustworthy identity
HMAC-authenticated Diffie-Hellman for MIKEY July 2003 HMAC-authenticated Diffie-Hellman for MIKEY October 2003
information; e.g., by relying on secured links underneath of MIKEY information; e.g., by relying on secured links underneath of MIKEY
that supply trustworthy identity information otherwise. However, that supply trustworthy identity information otherwise. However,
it is understood that without identity information present, the it is understood that without identity information present, the
MIKEY key management security protocols might be subject to MIKEY key management security protocols might be subject to
security weaknesses such as masquerade, impersonation and security weaknesses such as masquerade, impersonation and
reflection attacks particularly in end-to-end scenarios where no reflection attacks particularly in end-to-end scenarios where no
other secure means of assured identity information is provided. other secure means of assured identity information is provided.
Leaving identity fields optional if possible thus should not be Leaving identity fields optional if possible thus should not be
seen as a privacy method either, but rather as a protocol seen as a privacy method either, but rather as a protocol
skipping to change at page 17, line 5 skipping to change at page 17, line 5
transit and in particular, on the otherwise non-authenticated transit and in particular, on the otherwise non-authenticated
exchanged Diffie-Hellman half keys. exchanged Diffie-Hellman half keys.
Note: This document does not address issues regarding Note: This document does not address issues regarding
authorization; this feature is not provided explicitly. However, authorization; this feature is not provided explicitly. However,
DHHMAC authentication means support and facilitate realization of DHHMAC authentication means support and facilitate realization of
authorization means (local issue). authorization means (local issue).
* Cryptographic integrity check: * Cryptographic integrity check:
HMAC-authenticated Diffie-Hellman for MIKEY July 2003 HMAC-authenticated Diffie-Hellman for MIKEY October 2003
The cryptographic integrity check is achieved using a message The cryptographic integrity check is achieved using a message
digest (keyed HMAC). It includes the exchanged Diffie-Hellman digest (keyed HMAC). It includes the exchanged Diffie-Hellman
half-keys but covers the other parts of the exchanged message as half-keys but covers the other parts of the exchanged message as
well. Both mutual peer entity authentication and message integrity well. Both mutual peer entity authentication and message integrity
provide effective countermeasure against man-in-the-middle attacks. provide effective countermeasure against man-in-the-middle attacks.
The initiator may deploy a local timer that fires when the awaited The initiator may deploy a local timer that fires when the awaited
response message did not arrive timely. This is to detect deletion response message did not arrive timely. This is to detect deletion
of entire messages. of entire messages.
skipping to change at page 18, line 4 skipping to change at page 18, line 4
forward secrecy. Thus, none of the other MIKEY protocols is able forward secrecy. Thus, none of the other MIKEY protocols is able
to substitute the Diffie-Hellman PFS property. to substitute the Diffie-Hellman PFS property.
As such, DHHMAC but also digitally signed DH provides a far As such, DHHMAC but also digitally signed DH provides a far
superior security level over the pre-shared or public-key based key superior security level over the pre-shared or public-key based key
distribution protocol in that respect. distribution protocol in that respect.
* Fair, mutual key contribution: * Fair, mutual key contribution:
The Diffie-Hellman key management protocol is not a strict key The Diffie-Hellman key management protocol is not a strict key
distribution protocol per se with the initiator distributing a key distribution protocol per se with the initiator distributing a key
HMAC-authenticated Diffie-Hellman for MIKEY July 2003 HMAC-authenticated Diffie-Hellman for MIKEY October 2003
to its peers. Actually, both parties involved in the protocol to its peers. Actually, both parties involved in the protocol
exchange are able to equally contribute to the common Diffie- exchange are able to equally contribute to the common Diffie-
Hellman TEK traffic generating key. This reduces the risk of Hellman TEK traffic generating key. This reduces the risk of
either party cheating or unintentionally generating a weak session either party cheating or unintentionally generating a weak session
key. This makes the DHHMAC a fair key agreement protocol. One may key. This makes the DHHMAC a fair key agreement protocol. One may
view this property as an additional distributed security measure view this property as an additional distributed security measure
that is increasing security robustness over the case where all the that is increasing security robustness over the case where all the
security depends just on the proper implementation of a single security depends just on the proper implementation of a single
entity. entity.
skipping to change at page 19, line 4 skipping to change at page 19, line 4
public-key operations. This yields a particular performance public-key operations. This yields a particular performance
benefit of DHHMAC over signed DH or the public-key encryption benefit of DHHMAC over signed DH or the public-key encryption
protocol. protocol.
DHHMAC optionally features a variant where the HMAC-SHA-1 result is DHHMAC optionally features a variant where the HMAC-SHA-1 result is
truncated to 96-bit instead of 160 bits. It is believed that truncated to 96-bit instead of 160 bits. It is believed that
although the truncated HMAC appears significantly shorter, the although the truncated HMAC appears significantly shorter, the
security provided would not suffer; it appears even reasonable that security provided would not suffer; it appears even reasonable that
the shorter HMAC could provide increased security against known- the shorter HMAC could provide increased security against known-
plaintext crypt-analysis, see RFC 2104 [6] for more details. In plaintext crypt-analysis, see RFC 2104 [6] for more details. In
HMAC-authenticated Diffie-Hellman for MIKEY July 2003 HMAC-authenticated Diffie-Hellman for MIKEY October 2003
any way, truncated DHHMAC is able to reduce the bandwidth during any way, truncated DHHMAC is able to reduce the bandwidth during
Diffie-Hellman key agreement and yield better round trip delay on Diffie-Hellman key agreement and yield better round trip delay on
low-bandwidth links. If a very high security level is desired for low-bandwidth links. If a very high security level is desired for
long-term secrecy of the negotiated Diffie-Hellman shared secret, long-term secrecy of the negotiated Diffie-Hellman shared secret,
longer hash values may be deployed such as SHA256, SHA384 or SHA512 longer hash values may be deployed such as SHA256, SHA384 or SHA512
provide, possibly in conjunction with stronger Diffie-Hellman provide, possibly in conjunction with stronger Diffie-Hellman
groups. This is left as for further study. groups. This is left as for further study.
For the sake of improved performance and reduced round trip delay For the sake of improved performance and reduced round trip delay
skipping to change at page 20, line 5 skipping to change at page 20, line 5
in MIKEY. Public-key infrastructures may not always be available in MIKEY. Public-key infrastructures may not always be available
in certain environments nor may they be deemed adequate for real- in certain environments nor may they be deemed adequate for real-
time multimedia applications when taking additional steps for time multimedia applications when taking additional steps for
certificate validation and certificate revocation methods with certificate validation and certificate revocation methods with
additional round-trips into account. additional round-trips into account.
DHHMAC does not depend on PKI nor do implementations require PKI DHHMAC does not depend on PKI nor do implementations require PKI
standards and thus is believed to be much simpler than the more standards and thus is believed to be much simpler than the more
complex PKI facilities. complex PKI facilities.
HMAC-authenticated Diffie-Hellman for MIKEY July 2003 HMAC-authenticated Diffie-Hellman for MIKEY October 2003
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/Firewall-friendliness: * NAT/Firewall-friendliness:
DHHMAC is able to operate smoothly through firewall/NAT devices as DHHMAC is able to operate smoothly through firewall/NAT devices as
long as the protected identity information of the end entity is not long as the protected identity information of the end entity is not
an IP /transport address. Of course, DHHMAC does not necessarily an IP /transport address. Of course, DHHMAC does not necessarily
require a firewall/NAT to operate. require a firewall/NAT to operate.
skipping to change at page 21, line 4 skipping to change at page 21, line 4
called the discrete logarithm assumption. Please see [7], [11] or called the discrete logarithm assumption. Please see [7], [11] or
[12] for more background information regarding the Diffie-Hellman [12] for more background information regarding the Diffie-Hellman
problem and its computational complexity assumptions. problem and its computational complexity assumptions.
* the hash function (SHA1) is secure; i.e. that it is computationally * the hash function (SHA1) is secure; i.e. that it is computationally
infeasible to find a message which corresponds to a given message infeasible to find a message which corresponds to a given message
digest, or to find two different messages that produce the same digest, or to find two different messages that produce the same
message digest. message digest.
* the HMAC algorithm is secure and does not leak the auth_key. In * the HMAC algorithm is secure and does not leak the auth_key. In
HMAC-authenticated Diffie-Hellman for MIKEY July 2003 HMAC-authenticated Diffie-Hellman for MIKEY October 2003
particular, the security depends on the message authentication particular, the security depends on the message authentication
property of the compression function of the hash function H when property of the compression function of the hash function H when
applied to single blocks (see [6]). applied to single blocks (see [6]).
* A source capable of producing sufficiently many bits of (pseudo) * A source capable of producing sufficiently many bits of (pseudo)
randomness is available. randomness is available.
* The systems upon which DHHMAC runs are sufficiently secure. * The systems upon which DHHMAC runs are sufficiently secure.
skipping to change at page 22, line 5 skipping to change at page 22, line 5
* the HMAC method be broken (leaking the auth_key), * the HMAC method be broken (leaking the auth_key),
* systematic brute force attacks are effective by which an attacker * systematic brute force attacks are effective by which an attacker
attempts to discover the shared secret. It is assumed that the attempts to discover the shared secret. It is assumed that the
shared secret yields sufficient entropy to make such attacks shared secret yields sufficient entropy to make such attacks
infeasible, infeasible,
* or some other yet unknown attacking technique will be discovered. * or some other yet unknown attacking technique will be discovered.
HMAC-authenticated Diffie-Hellman for MIKEY July 2003 HMAC-authenticated Diffie-Hellman for MIKEY October 2003
The Diffie-Hellman mechanism is a generic security technique that is The Diffie-Hellman mechanism is a generic security technique that is
not only applicable to groups of prime order or of characteristic not only applicable to groups of prime order or of characteristic
two. This is because of the fundamental mathematical assumption that two. This is because of the fundamental mathematical assumption that
the discrete logarithm problem is also a very hard one in general the discrete logarithm problem is also a very hard one in general
groups. This enables Diffie-Hellman to be deployed also for GF(p)*, groups. This enables Diffie-Hellman to be deployed also for GF(p)*,
for sub-groups of sufficient size and for groups upon elliptic for sub-groups of sufficient size and for groups upon elliptic
curves. RSA does not allow such generalization, as the core curves. RSA does not allow such generalization, as the core
mathematical problem is a different one (large integer mathematical problem is a different one (large integer
factorization). factorization).
skipping to change at page 23, line 4 skipping to change at page 23, line 4
fields. Thus, close alignment between DHHMAC values and MIKEY values fields. Thus, close alignment between DHHMAC values and MIKEY values
shall be maintained; see also [3] section 10. shall be maintained; see also [3] section 10.
Intellectual Property Rights Intellectual Property Rights
This proposal is in full conformity with [RFC-2026]. This proposal is in full conformity with [RFC-2026].
The author is aware of related intellectual property rights The author is aware of related intellectual property rights
currently being held by Infineon. Pursuant to the provisions of currently being held by Infineon. Pursuant to the provisions of
[RFC-2026], the author represents that he has disclosed the [RFC-2026], the author represents that he has disclosed the
existence of any proprietary or intellectual property rights in the existence of any proprietary or intellectual property rights in the
HMAC-authenticated Diffie-Hellman for MIKEY July 2003 HMAC-authenticated Diffie-Hellman for MIKEY October 2003
contribution that are reasonably and personally known to the contribution that are reasonably and personally known to the
author. The author does not represent that he personally knows of author. The author does not represent that he personally knows of
all potentially pertinent proprietary and intellectual property all potentially pertinent proprietary and intellectual property
rights owned or claimed by the organizations he represents or third rights owned or claimed by the organizations he represents or third
parties. parties.
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 or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
skipping to change at page 24, line 5 skipping to change at page 24, line 5
[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-07.txt>, and RTSP", Internet Draft <draft-ietf-mmusic-kmgmt-ext-07.txt>,
Work in Progress (MMUSIC WG), IETF, February 2003. Work in Progress (MMUSIC WG), IETF, February 2003.
[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 July 2003 HMAC-authenticated Diffie-Hellman for MIKEY October 2003
Informative References Informative References
[7] A.J. Menezes, P. van Oorschot, S. A. Vanstone: "Handbook of [7] A.J. Menezes, P. van Oorschot, S. A. Vanstone: "Handbook of
Applied Cryptography", CRC Press 1996. Applied Cryptography", CRC Press 1996.
[8] E. Rescorla, B. Korver: " Guidelines for Writing RFC Text on [8] E. Rescorla, B. Korver: " Guidelines for Writing RFC Text on
Security Considerations", Work in Progress <draft-iab-sec-cons- Security Considerations", RFC 3552, IETF, July 2003.
03.txt>, IETF, January 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", Work in Progress <draft-iab- Mechanisms for the Internet", Work in Progress <draft-iab-
secmech-02.txt>, IETF, January 2003. secmech-03.txt>, IETF, July 2003.
[11] Ueli M. Maurer, S. Wolf: "The Diffie-Hellman Protocol", [11] Ueli M. Maurer, S. Wolf: "The Diffie-Hellman Protocol",
Designs, Codes, and Cryptography, Special Issue Public Key Designs, Codes, and Cryptography, Special Issue Public Key
Cryptography, Kluwer Academic Publishers, vol. 19, pp. 147-171, Cryptography, Kluwer Academic Publishers, vol. 19, pp. 147-171,
2000. ftp://ftp.inf.ethz.ch/pub/crypto/publications/MauWol00c.ps 2000. ftp://ftp.inf.ethz.ch/pub/crypto/publications/MauWol00c.ps
[12] Discrete Logarithms and the Diffie-Hellman Protocol; [12] Discrete Logarithms and the Diffie-Hellman Protocol;
http://www.crypto.ethz.ch/research/ntc/dldh/ http://www.crypto.ethz.ch/research/ntc/dldh/
[13] T. Dierks, C. Allen: "The TLS Protocol Version 1.0.", RFC 2246, [13] T. Dierks, C. Allen: "The TLS Protocol Version 1.0.", RFC 2246,
IETF, January 1999. IETF, January 1999.
[14] D. Harkins, D. Carrel: "The Internet Key Exchange (IKE).", RFC [14] D. Harkins, D. Carrel: "The Internet Key Exchange (IKE).", RFC
2409, IETF, November 1998. 2409, IETF, November 1998.
[15] Donald E. Eastlake, Jeffrey I. Schiller, Steve Crocker: [15] Donald E. Eastlake, Jeffrey I. Schiller, Steve Crocker:
"Randomness Requirements for Security"; <draft-eastlake- "Randomness Requirements for Security"; <draft-eastlake-
randomness2-03.txt>; Work in Progress, IETF, July 2002. randomness2-04.txt>; Work in Progress, IETF, August 2003.
[16] J. Schiller: "Strong Security Requirements for Internet [16] J. Schiller: "Strong Security Requirements for Internet
Engineering Task Force Standard Protocols", RFC 3365, IETF, Engineering Task Force Standard Protocols", RFC 3365, IETF,
2002. 2002.
[17] C. Meadows: "Advice on Writing an Internet Draft Amenable to [17] C. Meadows: "Advice on Writing an Internet Draft Amenable to
Security Analysis", Work in Progress <draft-irtf-cfrg-advice- Security Analysis", Work in Progress <draft-irtf-cfrg-advice-
00.txt>, IRTF, October 2002. 00.txt>, IRTF, October 2002.
HMAC-authenticated Diffie-Hellman for MIKEY July 2003
[18] T. Narten: "Guidelines for Writing an IANA Considerations [18] T. Narten: "Guidelines for Writing an IANA Considerations
HMAC-authenticated Diffie-Hellman for MIKEY October 2003
Section in RFCs", RFC 2434, IETF, October 1998. Section in RFCs", RFC 2434, IETF, October 1998.
[19] J. Reynolds: "Instructions to Request for Comments (RFC) [19] J. Reynolds: "Instructions to Request for Comments (RFC)
Authors", Work in Progress, <draft-rfc-editor-rfc2223bis- Authors", Work in Progress, <draft-rfc-editor-rfc2223bis-
06.txt>, IETF, June 2003. 06.txt>, IETF, June 2003.
[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-08.txt>, IETF, May Progress (IPSEC WG), <draft-ietf-ipsec-ikev2-10.txt>, IETF,
2003. August 2003.
[22] Draft ITU-T Recommendation H.235 Annex G: "Usage of the Secure [22] Draft ITU-T Recommendation H.235 Annex G: "Usage of the MIKEY
Real Time Transport Protocol (SRTP) in conjunction with the Key Management Protocol for the Secure Real Time Transport
MIKEY Key Management Protocol within H.235"; 5/2003. Protocol (SRTP) within H.235"; 9/2003.
[23] Schaad, J., Housley R.: "Advanced Encryption Standard (AES) [23] Schaad, J., Housley R.: "Advanced Encryption Standard (AES)
Key Wrap Algorithm", IETF, RFC 3394. Key Wrap Algorithm", IETF, RFC 3394.
[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, July 2003. Domain of Interpretation", RFC 3547, July 2003.
[25] Harney, H., Colegrove, A., Harder, E., Meth, U., Fleischer, R.: [25] Harney, H., Colegrove, A., Harder, E., Meth, U., Fleischer, R.:
"Group Secure Association Key Management Protocol", <draft-ietf- "Group Secure Association Key Management Protocol", <draft-ietf-
msec-gsakmp-sec-02.txt>, Internet Draft, Work in Progress (MSEC msec-gsakmp-sec-02.txt>, Internet Draft, Work in Progress (MSEC
skipping to change at page 26, line 5 skipping to change at page 26, line 5
and Fredrick Lindholm and general feedback by the MSEC WG. and Fredrick Lindholm and general feedback by the MSEC WG.
Conclusions Conclusions
Key management for environments and applications with real-time and Key management for environments and applications with real-time and
performance constraints are becoming of interest. Existing key performance constraints are becoming of interest. Existing key
management techniques like IPSEC-IKE [14] and IPSEC-IKEv2 [22], TLS management techniques like IPSEC-IKE [14] and IPSEC-IKEv2 [22], TLS
[13] and other schemes are not deemed adequate in addressing [13] and other schemes are not deemed adequate in addressing
sufficiently those real-time and security requirements. sufficiently those real-time and security requirements.
HMAC-authenticated Diffie-Hellman for MIKEY July 2003 HMAC-authenticated Diffie-Hellman for MIKEY October 2003
MIKEY defines three key management security protocols addressing MIKEY defines three key management security protocols addressing
real-time constraints. DHHMAC as described in this document defines real-time constraints. DHHMAC as described in this document defines
a fourth MIKEY variant aiming at the same target. a fourth MIKEY variant aiming at the same target.
While each of the four key management protocols has its own merits While each of the four key management protocols has its own merits
there are also certain limitations of each approach. As such there there are also certain limitations of each approach. As such there
is no single ideal solution and none of the variants is able to is no single ideal solution and none of the variants is able to
subsume the other remaining variants. subsume the other remaining variants.
skipping to change at page 27, line 5 skipping to change at page 27, line 5
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
HMAC-authenticated Diffie-Hellman for MIKEY July 2003 HMAC-authenticated Diffie-Hellman for MIKEY October 2003
Expiration Date Expiration Date
This Internet Draft expires on 30 January 2004. This Internet Draft expires on 30 March 2004.
Revision History Revision History
Changes against draft-ietf-msec-mikey-dhhmac-03.txt:
* RFC 3552 available; some references updated.
Changes against draft-ietf-msec-mikey-dhhmac-02.txt: Changes against draft-ietf-msec-mikey-dhhmac-02.txt:
* text allows both random and pseudo-random values. * text allows both random and pseudo-random values.
* exponentiation ** changed to ^. * exponentiation ** changed to ^.
* Notation aligned with MIKEY-07. * Notation aligned with MIKEY-07.
* Clarified that the HMAC is calculated over the entire MIKEY * Clarified that the HMAC is calculated over the entire MIKEY
message excluding the MAC field. message excluding the MAC field.
* Section 4.2: The AES key wrap method SHALL not be applied. * Section 4.2: The AES key wrap method SHALL not be applied.
* Section 1: Relationship with other, existing work mentioned. * Section 1: Relationship with other, existing work mentioned.
* *
skipping to change at page 27, line 45 skipping to change at page 28, line 4
* 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:
* category set to proposed standard. * category set to proposed standard.
HMAC-authenticated Diffie-Hellman for MIKEY October 2003
* 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 July 2003
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/