draft-ietf-msec-mikey-dhhmac-00.txt   draft-ietf-msec-mikey-dhhmac-01.txt 
Internet Engineering Task Force M. Euchner Internet Engineering Task Force M. Euchner
Internet Draft Siemens AG Internet Draft Siemens AG
Intended Category: Informational Intended Category: Proposed Standard
Expires: February 2003 August 2002 Expires: June 2003 January 2003
HMAC-authenticated Diffie-Hellman for MIKEY HMAC-authenticated Diffie-Hellman for MIKEY
(draft-ietf-msec-mikey-dhhmac-00.txt) (draft-ietf-msec-mikey-dhhmac-01.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. all provisions of Section 10 of RFC2026.
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 1, line 41 skipping to change at page 1, line 41
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
The distribution of this memo is unlimited. The distribution of this memo is unlimited.
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
the classic Diffie-Hellman key agreement protocol is used for key particular, the classic Diffie-Hellman key agreement protocol is
establishment in conjunction with a keyed hash (HMAC-SHA1) for used for key establishment in conjunction with a keyed hash (HMAC-
achieving mutual authentication and message integrity of the key SHA1) for achieving mutual authentication and message integrity of
management messages exchanged. This MIKEY variant is called the the key management messages exchanged. This MIKEY variant is
HMAC-authenticated Diffie-Hellmann (DH-HMAC). It addresses the called the HMAC-authenticated Diffie-Hellmann (DHHMAC). It
security and performance constraints of multimedia key management addresses the security and performance constraints of multimedia
in MIKEY. key management in MIKEY.
HMAC-authenticated Diffie-Hellman for MIKEY August 2002 HMAC-authenticated Diffie-Hellman for MIKEY January 2003
Table of Contents Table of Contents
1. Introduction.....................................................3 1. Introduction..................................................2
1.1. Notational Conventions.........................................4 1.1. Notational Conventions........................................4
1.2. Definitions....................................................5 1.2. Definitions...................................................4
1.3. Abbreviations..................................................5 1.3. Abbreviations.................................................4
2. Scenario.........................................................6 2. Scenario......................................................5
3. DH-HMAC Security Protocol........................................6 3. DHHMAC Security Protocol......................................5
3.1. TGK re-keying..................................................7 3.1. TGK re-keying.................................................7
4. DH-HMAC payload formats..........................................8 4. DHHMAC payload formats........................................7
4.1. Common header payload (HDR)....................................8 4.1. Common header payload (HDR) ..................................8
4.2. Key data transport payload (KEMAC).............................9 4.2. Key data transport payload (KEMAC) ...........................8
4.3. ID payload (ID)................................................9 4.3. ID payload (ID) ..............................................9
5. Security Considerations.........................................10 5. Security Considerations.......................................9
5.1. Security environment..........................................10 5.1. Security environment..........................................9
5.2. Threat model..................................................10 5.2. Threat model..................................................9
5.3. Security features and properties..............................11 5.3. Security features and properties.............................11
5.4. Assumptions...................................................14 5.4. Assumptions..................................................14
5.5. Residual risk.................................................15 5.5. Residual risk................................................15
6. IANA considerations.............................................16 6. IANA considerations..........................................15
7. Intellectual Property Rights....................................16 7. Intellectual Property Rights.................................15
8. Acknowledgements................................................16 8. Acknowledgements.............................................16
9. Conclusions.....................................................16 9. Conclusions..................................................16
10. Normative References...........................................17 10. Normative References.........................................17
11. Informative References.........................................17 11. Informative References.......................................17
12. Author's Address...............................................18 12. Author's Address.............................................18
13. Expiration Date................................................18 13. Full Copyright Statement.....................................18
14. Revision History...............................................18 14. Expiration Date..............................................19
HMAC-authenticated Diffie-Hellman for MIKEY August 2002 15. Revision History.............................................19
1. Introduction 1. Introduction
As pointed out in MIKEY (see [1]), secure real-time multimedia As pointed out in MIKEY (see [1]), secure real-time multimedia
applications demand a particular adequate key management scheme that applications demand a particular adequate key management scheme that
cares for how to securely and efficiently establish dynamic session cares for how to securely and efficiently establish dynamic session
keys in a conversational multimedia scenario. keys in a conversational multimedia scenario.
In general, MIKEY scenarios cover peer-to-peer, simple-one-to-many In general, MIKEY scenarios cover peer-to-peer, simple-one-to-many
and small-sized groups. MIKEY in particular, describes three key and small-sized groups. MIKEY in particular, describes three key
management schemes for the peer-to-peer case that all finish their management schemes for the peer-to-peer case that all finish their
task within one round trip: task within one round trip:
- a symmetric key distribution protocol based upon pre-shared - a symmetric key distribution protocol based upon pre-shared
master keys; master keys;
- a public-key encryption-based key distribution protocol - a public-key encryption-based key distribution protocol
assuming a public-key infrastructure with RSA-based private/public assuming a public-key infrastructure with RSA-based (Rivest,
keys and digital certificates; Shamir and Adleman) private/public keys and digital
certificates;
- and a Diffie-Hellman key agreement protocol deploying digital - and a Diffie-Hellman key agreement protocol deploying digital
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
HMAC-authenticated Diffie-Hellman for MIKEY January 2003
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 [4] that each of the three key management However, it is known [5] 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
implement but does not nicely scale in any larger implement but does not nicely scale in any larger
configuration of potential peer entities due to the need of configuration of potential peer entities due to the need of
mutually pre-assigned shared master secrets. mutually pre-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 4, line 5 skipping to change at page 3, line 36
as a specific limitation in less trusted environments. as a specific limitation in less trusted environments.
- The public-key encryption scheme depends upon a public-key - The public-key encryption scheme depends upon a public-key
infrastructure that certifies the private-public keys by infrastructure that certifies the private-public keys by
issuing and maintaining digital certificates. While such a issuing and maintaining digital certificates. While such a
key management scheme provides full scalability in large key management scheme provides full scalability in large
networked configurations, public-key infrastructures are networked configurations, public-key infrastructures are
still not widely available and in general, implementations still not widely available and in general, implementations
are significantly more complex. are significantly more complex.
HMAC-authenticated Diffie-Hellman for MIKEY August 2002
Further additional round trips might be necessary for each Further additional round trips might be necessary for each
side in order to ascertain verification of the digital side in order to ascertain verification of the digital
certificates. certificates.
Finally, as in the symmetric case, the responder depends Finally, as in the symmetric case, the responder depends
completely upon the initiator choosing good and secure completely upon the initiator choosing good and secure
session keys. session keys.
- 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 Hellman key agreement scheme and authenticates the exchange
skipping to change at page 4, line 30 skipping to change at page 4, line 5
with its strength on scalability but also the limitations on with 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 operations and the potential need for additional
communication for verification of the digital certificates. communication for verification of the digital certificates.
However, the Diffie-Hellman key agreement protocol is known However, the Diffie-Hellman key agreement protocol is known
for its subtle security strengths in that it is able to for its subtle security strengths in that it is able to
provide full perfect secrecy and further have both parties provide full perfect secrecy and further have both parties
actively involved in session key generation. actively involved in session key generation.
HMAC-authenticated Diffie-Hellman for MIKEY January 2003
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.
The idea of that protocol is to apply the Diffie-Hellman key The idea of that protocol is to apply the Diffie-Hellman key
agreement but instead of deploying a digital signature for agreement but instead of deploying a digital signature for
authenticity of the exchanged keying material rather uses a keyed- authenticity of the exchanged keying material rather uses a keyed-
hash upon using symmetrically pre-assigned shared secrets. This hash upon using symmetrically pre-assigned shared secrets. This
combination of security mechanisms is called the HMAC-authenticated combination of security mechanisms is called the HMAC-authenticated
Diffie-Hellman key agreement for MIKEY (DH-HMAC). Diffie-Hellman (DH) key agreement for MIKEY (DHHMAC).
Like the MIKEY Diffie-Hellman protocol, DH-HMAC does not scale beyond Like the MIKEY Diffie-Hellman protocol, DHHMAC does not scale beyond
a point-to-point constellation; thus, both MIKEY Diffie-Hellman a point-to-point constellation; thus, both MIKEY Diffie-Hellman
protocols do not support group-based keying for any group size larger protocols do not support group-based keying for any group size larger
than two entities. than two entities.
1.1. Notational Conventions 1.1. Notational Conventions
The key word "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key word "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119. this document are to be interpreted as described in RFC-2119.
HMAC-authenticated Diffie-Hellman for MIKEY August 2002
1.2. Definitions 1.2. Definitions
The definitions and notations in this document are aligned with The definitions and notations in this document are aligned with
MIKEY, see [1] and [1] sections 1.2 - 1.3. MIKEY, see [1] and [1] sections 1.2 - 1.3.
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
[1] section 3.3; however, the DH-HMAC protocol is applicable in [1] section 3.3; however, the DHHMAC protocol is applicable in
general to other appropriate groups as well. general to other appropriate 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 derived (initiator and responder). The authentication key auth_key is
from the pre-shared secret s using the pseudo-random function PRF; derived from the pre-shared secret s using the pseudo-random function
see [1] sections 4.1.3 and 4.1.5. PRF; see [1] sections 4.1.3 and 4.1.5.
1.3. Abbreviations 1.3. 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 DHi public Diffie-Hellman half key g**(xi) of
Initiatior Initiatior
DHr public Diffie-Hellman half key g**(xr) of Responder DHr public Diffie-Hellman half key g**(xr) of Responder
DH-HMAC HMAC-authenticated Diffie-Hellman DHHMAC HMAC-authenticated Diffie-Hellman
HMAC-authenticated Diffie-Hellman for MIKEY January 2003
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)
HMAC-SHA-1-96 HMAC-SHA1 truncated to 96 bits HMAC-SHA-1-96 HMAC-SHA1 truncated to 96 bits
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
skipping to change at page 6, line 4 skipping to change at page 5, line 31
s pre-shared key s pre-shared key
SOI Son-of-IKE SOI Son-of-IKE
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, random Diffie-Hellman key of Initiator xi secret, random Diffie-Hellman key of Initiator
xr secret, random Diffie-Hellman key of Responder xr secret, random Diffie-Hellman key of Responder
HMAC-authenticated Diffie-Hellman for MIKEY August 2002
2. Scenario 2. Scenario
The HMAC-authenticated Diffie-Hellman key agreement protocol The HMAC-authenticated Diffie-Hellman key agreement protocol (DHHMAC)
(DH-HMAC) for MIKEY addresses the same scenarios and scope as the for MIKEY addresses the same scenarios and scope as the other three
other three key management schemes in MIKEY address. key management schemes in MIKEY address.
DH-HMAC is applicable in a peer-to-peer group where no access to a DHHMAC is applicable in a peer-to-peer group where no access to a
public-key infrastructure can be assumed available. Rather, pre- public-key infrastructure can be assumed available. Rather, pre-
shared master secrets are assumed available among the entities in shared master secrets are assumed available among the entities in
such an environment. such an environment.
In a pair-wise group, it is assumed that each client will be setting In a pair-wise group, it is assumed that each client will be setting
up a session key for its outgoing links with it's peer using the DH- up a session key for its outgoing links with it's peer using the DH-
MAC key agreement protocol. MAC key agreement protocol.
As is the case for the other three MIKEY key management protocol, As is the case for the other three MIKEY key management protocol,
DH-HMAC assumes loosely synchronized clocks among the entities in the DHHMAC assumes loosely synchronized clocks among the entities in the
small group. small group.
3. DH-HMAC Security Protocol 3. DHHMAC Security Protocol
The following figure defines the security protocol for DH-HMAC: The following figure defines the security protocol for DHHMAC:
HMAC-authenticated Diffie-Hellman for MIKEY January 2003
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
-----------------------> R_message = HDR, T, -----------------------> R_message = HDR, T,
[Idr], IDi, DHr, DHi, [IDr], IDi, DHr, DHi,
KEMAC KEMAC
R_message R_message
<---------------------- <----------------------
TGK = g**(xi * yi) TGK = g**(xi * yi) TGK = g**(xi * yi) TGK = g**(xi * yi)
Figure 1: HMAC-authenticated Diffie-Hellman key based exchange, Figure 1: HMAC-authenticated Diffie-Hellman key based exchange,
where xi and xr are randomly chosen respectively where xi and xr are randomly chosen respectively
by the initiator and the responder. by the initiator and the responder.
The DH-HMAC 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 random value xi, and sends an HMACed message initiator chooses a random value xi, and sends an HMACed message
including g**xi and a timestamp to the responder (optionally also including g**xi and a timestamp to the responder (optionally also
including its identity). including its identity).
The group parameters (e.g., the group G) are a set of parameters The group parameters (e.g., the group G) are a set of parameters
chosen by the initiator. The responder chooses a random positive chosen by the initiator. The responder chooses a random positive
integer xr, and sends an HMACed message including g**xr and the integer xr, and sends an HMACed message including g**xr and the
HMAC-authenticated Diffie-Hellman for MIKEY August 2002
timestamp to the initiator (optionally also providing its timestamp to the initiator (optionally also providing its
identity). identity).
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 the 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 exponentiation and one HMAC, then one HMAC verification and
finally another Diffie-Hellman exponentiation. finally another Diffie-Hellman exponentiation.
With off-line pre-computation, the initial Diffie-Hellman half-key With off-line pre-computation, the initial Diffie-Hellman half-key
MAY be computed before the key management transaction and thereby MAY be computed before the key management transaction and thereby
MAY further reduce the overall round trip delay as well as reduce MAY further reduce the overall round trip delay as well as reduce
the risk of denial-of-service attacks. the risk of denial-of-service attacks.
Processing of the TGK SHALL be accomplished as described in MIKEY Processing of the TGK SHALL be accomplished as described in MIKEY
[1] chapter 4. [1] chapter 4.
The computed HMAC result SHALL be conveyed in the KEMAC payload The computed HMAC result SHALL be conveyed in the KEMAC payload
field where the MAC fields holds the HMAC result. The HMAC shall field where the MAC fields holds the HMAC result. The HMAC shall
be computed over the entire message using auth_key, see also be computed over the entire message using auth_key, see also
section 4.2. section 4.2.
HMAC-authenticated Diffie-Hellman for MIKEY January 2003
3.1. TGK re-keying 3.1. TGK re-keying
TGK re-keying for DH-HMAC generally proceeds as described in [1] TGK re-keying for DHHMAC generally proceeds as described in [1]
section 4.5. Specifically, figure 2 provides the message fields section 4.5. Specifically, figure 2 provides the message fields
for DH-HMAC 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, [DHr, Dhi], [IDr], IDi, [DHr, DHi],
KEMAC KEMAC
R_message R_message
<---------------------- <----------------------
[TGK = g**(xi * yi)] [TGK = g**(xi * yi)] [TGK = g**(xi * yi)] [TGK = g**(xi * yi)]
Figure 2: DH-HMAC update message Figure 2: DHHMAC update message
HMAC-authenticated Diffie-Hellman for MIKEY August 2002
4. DH-HMAC payload formats 4. DHHMAC payload formats
This section specifies the payload formats and data type values for This section specifies the payload formats and data type values for
DH-HMAC, see also [1] chapter 6 for a definition of the MIKEY DHHMAC, see also [1] chapter 6 for a definition of the MIKEY
payloads. payloads.
The following referenced MIKEY payloads are used for DH-MAC: The following referenced MIKEY payloads are used for DH-MAC:
* Common header payload (HDR), see section 4.1 and [1] section 6.1 * Common header payload (HDR), see section 4.1 and [1] section 6.1
* SRTP ID sub-payload, see [1] section 6.1.1, * SRTP ID sub-payload, see [1] section 6.1.1,
* Key data transport payload (KEMAC), see section 4.2 and [1] section * Key data transport payload (KEMAC), see section 4.2 and [1] section
6.2 6.2
* DH data payload, see [1] section 6.4 * DH data payload, see [1] section 6.4
* Timestamp payload, [1] section 6.6 * Timestamp payload, [1] section 6.6
* ID payload, [1] section 6.7 * ID payload, [1] section 6.7
* Security Policy payload (SP), [1] section 6.10 * Security Policy payload (SP), [1] section 6.10
HMAC-authenticated Diffie-Hellman for MIKEY January 2003
* RAND payload (RAND), [1] section 6.11 * RAND payload (RAND), [1] section 6.11
* Error payload (ERR), [1] section 6.12 * Error payload (ERR), [1] section 6.12
* General Extension Payload, [1] section 6.15 * General Extension Payload, [1] section 6.15
4.1. Common header payload (HDR) 4.1. Common header payload (HDR)
Referring to [1] section 6.1, for DH-HMAC the following data type Referring to [1] section 6.1, for DHHMAC the following data type
SHALL be used: SHALL be used:
Data type | Value | Comment Data type | Value | Comment
-------------------------------------- DHHMAC init | 7 | Initiator's DHHMAC exchange message
DHHMAC init | 7 | Initiator's DH-HMAC exchange message DHHMAC resp | 8 | Responder's DHHMAC exchange message
DHHMAC resp | 8 | Responder's DH-HMAC exchange message
Error | 6 | Error message, see [1] section 6.12 Error | 6 | Error message, see [1] section 6.12
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 [1] section 6.2 KEMAC | 1 | section 4.2 and [1] section 6.2
DH | 3 | [1] section 6.4 DH | 3 | [1] section 6.4
T | 5 | [1] section 6.6 T | 5 | [1] section 6.6
ID | 6 | [1] section 6.7 ID | 6 | [1] section 6.7
SP | 10 | [1] section 6.10 SP | 10 | [1] section 6.10
RAND | 11 | [1] section 6.11 RAND | 11 | [1] section 6.11
HMAC-authenticated Diffie-Hellman for MIKEY August 2002
ERR | 12 | [1] section 6.12 ERR | 12 | [1] section 6.12
General Ext.| 21 | [1] section 6.15 General Ext.| 21 | [1] section 6.15
Other defined next payload values defined in [1] shall not be Other defined next payload values defined in [1] SHALL not be
applied to DH-HMAC. 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 authentication verification SHALL apply the Error payload data
type. type.
4.2. Key data transport payload (KEMAC) 4.2. Key data transport payload (KEMAC)
DH-HMAC shall apply this payload for conveying the HMAC result DHHMAC SHALL apply this payload for conveying the HMAC result
along with the indicated authentication algorithm. KEMAC when used along with the indicated authentication algorithm. KEMAC when used
in conjunction with DH-HMAC shall not convey any encrypted data; in conjunction with DHHMAC SHALL not convey any encrypted data;
thus Encr alg shall be set to 2 (NULL), Encr data len shall be set thus Encr alg SHALL be set to 2 (NULL), Encr data len shall be set
to 0 and Encr data shall be left empty. to 0 and Encr data SHALL be left empty.
For DH-HMAC, this key data transport payload shall be the last For DHHMAC, this key data transport payload SHALL be the last
payload in the message. Note that the Next payload field is set to payload in the message. Note that the Next payload field SHALL be
Last payload. The HMAC is then calculated over the entire MIKEY set to Last payload. The HMAC is then calculated over the entire
message using auth_key as described in [1] section 5.2 and then MIKEY message using auth_key as described in [1] section 5.2 and
stored within MAC field. then stored within MAC field.
HMAC-authenticated Diffie-Hellman for MIKEY January 2003
MAC alg | Value | Comments MAC alg | Value | Comments
--------------------------------------------------------
HMAC-SHA-1 | 0 | Mandatory, Default (see [SHA1]) HMAC-SHA-1 | 0 | Mandatory, Default (see [SHA1])
NULL | 1 | Very restricted use, see NULL | 1 | Very restricted use, see
| [1] section 4.2.4 | [1] section 4.2.4
HMAC-SHA-1-96 | 5 | Optional, HMAC-SHA1 truncated to the 96 HMAC-SHA-1-96 | 5 | Optional, HMAC-SHA1 truncated to the 96
| leftmost bits of the HMAC-SHA-1 result | leftmost bits of the HMAC-SHA-1 result
| when represented in network byte order. | when represented in network byte order.
HMAC-SHA-1 is the default hash function that MUST be implemented HMAC-SHA-1 is the default hash function that MUST be implemented
as part of the DH-HMAC. The length of the HMAC-SHA-1 result is 160 as part of the DHHMAC. The length of the HMAC-SHA-1 result is 160
bits. bits.
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 DH-HMAC, this payload shall only hold a non-certificate based For DHHMAC, this payload SHALL only hold a non-certificate based
identify. identify.
HMAC-authenticated Diffie-Hellman for MIKEY August 2002
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 [1] section 9. please refer to MIKEY [1] section 9.
In addition to that, this document addresses security issues In addition to that, this document addresses security issues
according to [5] where the following security considerations apply in according to [6] where the following security considerations apply in
particular to this document: particular to this document:
5.1. Security environment 5.1. Security environment
Generally, the DH-HMAC security protocol described in this document Generally, the DHHMAC security protocol described in this document
focuses primarily on communication security; i.e. the security issues focuses primarily on communication security; i.e. the security issues
concerned with the MIKEY DH-HMAC protocol. Nevertheless, some system concerned with the MIKEY DHHMAC protocol. Nevertheless, some system
security issues are of interest as well that are not explicitly security issues are of interest as well that are not explicitly
defined by the DH-HMAC protocol, but should be provided locally in defined by the DHHMAC protocol, but should be provided locally in
practice. The system where the DH-HMAC protocol entity runs upon practice. The system where the DHHMAC protocol entity runs upon
shall provide the capability to generate random numbers as input to shall provide the capability to generate random numbers as input to
the Diffie-Hellman operation (see [6], [14]). Further, the system the Diffie-Hellman operation (see [7], [15]). Further, the system
shall be capable of storing the generated random data, secret data, shall be capable of storing the generated random data, secret data,
keys and other secret security parameters securely (i.e. confidential keys and other secret security parameters securely (i.e. confidential
and safe from unauthorized tampering). and safe from unauthorized tampering).
5.2. Threat model 5.2. Threat model
The threat model that this documents adheres to covers the issues of The threat model that this documents adheres to covers the issues of
end-to-end security in the Internet generally; without ruling out the end-to-end security in the Internet generally; without ruling out the
possibility that MIKEY DH-HMAC be deployed in a corporate, closed IP HMAC-authenticated Diffie-Hellman for MIKEY January 2003
environment. This also includes the possibility that MIKEY DH-HMAC be
possibility that MIKEY DHHMAC be deployed in a corporate, closed IP
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
DH-HMAC proxies" involved. DHHMAC proxies" involved.
Since DH-HMAC 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.
This threat shall not occur. Nevertheless, for DH-HMAC 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:
DH-HMAC 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 Rather, by the Diffie-Hellman "encryption" operation, that
conceals the secret, random values, only partial information (i.e. conceals the secret, 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
is assumed that availability of such Diffie-Hellman half-keys to is assumed that availability of such Diffie-Hellman half-keys to
an eavesdropper does not result in any risk; see 5.4. Further, the an eavesdropper does not result in any risk; see 5.4. Further,
DH-HMAC carries other data such as timestamps, random values, the DHHMAC carries other data such as timestamps, random values,
identification information or security policy parameters; identification information or security policy parameters;
eavesdropping of any such data is considered not to yield any eavesdropping of any such data is considered not to yield any
significant security risk. significant security risk.
* Masquerade of either entity: * Masquerade of either entity:
HMAC-authenticated Diffie-Hellman for MIKEY August 2002
This security threat must be avoided and if a masquerade attack This security threat must be avoided and if a masquerade attack
would be attempted, appropriate detection means must be in place. would be attempted, appropriate detection means must be in place.
DH-HMAC addresses this threat by providing mutual peer entity DHHMAC addresses this threat by providing mutual peer entity
authentication. 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 messages. Man-in-the-middle attacks usually come with masquerade
and or loss of message integrity (see below). Man-in-the-middle and or loss of message integrity (see below). Man-in-the-middle
attacks must be avoided, and if present or attempted must be attacks must be avoided, and if present or attempted must be
detected appropriately. DH-HMAC addresses this threat by providing detected appropriately. DHHMAC addresses this threat by providing
mutual peer entity authentication and message integrity. mutual peer entity authentication and message integrity.
* Loss of integrity: * Loss of integrity:
This security threats relates to unauthorized replay, deletion, This security threats relates to unauthorized replay, deletion,
insertion and manipulation of messages. While any such attacks insertion and manipulation of messages. While any such attacks
cannot be avoided they must be detected at least. DH-HMAC cannot be avoided they must be detected at least. DHHMAC addresses
addresses this threat by providing message integrity. this threat by providing message integrity.
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 DH-HMAC 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
cannot be ruled out completely. cannot be ruled out completely.
HMAC-authenticated Diffie-Hellman for MIKEY January 2003
* Non-repudiation of the receipt or of the origin of the message: * Non-repudiation of the receipt or of the origin of the message:
These are not requirements of this environment and thus related These are not requirements of this environment and thus related
countermeasures not provided at all. countermeasures not provided at all.
* 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 Some considerations are given on some of those attacks, but DHHMAC
DH-HMAC does not claim to provide full countermeasure against any does not claim to provide full countermeasure against any of those
of those attacks. For example, stressing the availability of the attacks. For example, stressing the availability of the entities
entities are not thwarted by means of the key management protocol; are not thwarted by means of the key management protocol; some
some other local countermeasures should be applied. Further, some other local countermeasures should be applied. Further, some DoS
DoS attacks are not countered such as interception of a valid DH- attacks are not countered such as interception of a valid DH-
requests and its massive instant duplication. Such attacks might requests and its massive instant duplication. Such attacks might
at least be countered partially by some local means that are at least be countered partially by some local means that are
outside the scope of this document. outside the scope of this document.
* Identity protection:
Like MIKEY, identity protection is not a major design requirement
for MIKEY-DHHMAC either, see [1]. No security protocol is known
so far, that is able to provide the objectives of DHHMAC as stated
in section 5.3 including identity protection within just a single
roundtrip. As such, MIKEY-DHHMAC does not provide identity
protection on its own but may inherit such property from a
security protocol underneath that actually features identity
protection. On the other hand, it is expected that MIKEY-DHHMAC
is typically being deployed within SDP/SIP ([21], [22]); both
those protocols do not provide end-to-end identity protection.
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 This is achieved using an authenticated Diffie-Hellman key
management protocol. management protocol.
HMAC-authenticated Diffie-Hellman for MIKEY August 2002
* Peer-entity authentication (mutual): * Peer-entity authentication (mutual):
This authentication corroborates that the host/user is authentic This authentication corroborates that the host/user is authentic
in that possession of a pre-assigned secret key is proven using in that possession of a pre-assigned secret key is proven using
keyed HMAC. The authentication occurs on the request and on the keyed HMAC. The authentication occurs on the request and on the
response message, thus authentication is mutual. response message, thus authentication is mutual.
The HMAC computation corroborates for authentication and message The HMAC computation corroborates for authentication and message
integrity of the exchanged Diffie-Hellman half-keys and associated integrity of the exchanged Diffie-Hellman half-keys and associated
messages. The authentication is absolutely necessary in order to messages. The authentication is absolutely necessary in order to
avoid man-in-the-middle attacks on the exchanged messages in avoid man-in-the-middle attacks on the exchanged messages in
transit and in particular, on the otherwise non-authenticated transit and in particular, on the otherwise non-authenticated
exchanged Diffie-Hellman half keys. exchanged Diffie-Hellman half keys.
Note: This document does not address issues regarding Note: This document does not address issues regarding
authorization; this feature is not provided explicitly. However, authorization; this feature is not provided explicitly. However,
DH-HMAC authentication means support and facilitate realization of HMAC-authenticated Diffie-Hellman for MIKEY January 2003
DHHMAC authentication means support and facilitate realization of
authorization means (local issue). authorization means (local issue).
* Cryptographic integrity check: * Cryptographic integrity check:
The cryptographic integrity check is achieved using a message The cryptographic integrity check is achieved using a message
digest (keyed HMAC). It includes the exchanged Diffie-Hellman digest (keyed HMAC). It includes the exchanged Diffie-Hellman
half-keys but covers the other parts of the exchanged message as half-keys but covers the other parts of the exchanged message as
well. Both mutual peer entity authentication and message integrity well. Both mutual peer entity authentication and message
provide effective countermeasure against man-in-the-middle integrity provide effective countermeasure against man-in-the-
attacks. 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
of entire messages. deletion of entire messages.
* Replay protection of the messages is achieved using embedded * Replay protection of the messages is achieved using
timestamps. embeddedtimestamps.
* Limited DoS protection: * Limited DoS protection:
Rapid checking of the message digest allows verifying the Rapid checking of the message digest allows verifying the
authenticity and integrity of a message before launching CPU authenticity and integrity of a message before launching CPU
intensive Diffie-Hellman operations or starting other resource intensive Diffie-Hellman operations or starting other resource
consuming tasks. This protects against some denial-of-service consuming tasks. This protects against some denial-of-service
attacks: malicious modification of messages and spam attacks with attacks: malicious modification of messages and spam attacks with
(replayed or masqueraded) messages. DH-HMAC probably does not (replayed or masqueraded) messages. DHHMAC probably does not
explicitly counter sophisticated distributed denial-of-service explicitly counter sophisticated distributed denial-of-service
attacks that compromise system availability for example. attacks that compromise system availability for example.
* Perfect-forward secrecy (PFS): * Perfect-forward secrecy (PFS):
Other than the MIKEY pre-shared and public-key based key Other than the MIKEY pre-shared and public-key based key
distribution protocols, the Diffie-Hellman key agreement protocol distribution protocols, the Diffie-Hellman key agreement protocol
features a security property called perfect forward secrecy. That features a security property called perfect forward secrecy. That
is, that even if the long-term pre-shared key would be compromised is, that even if the long-term pre-shared key would be compromised
at some point in time, this would not render past or future at some point in time, this would not render past or future
session keys compromised. session keys compromised.
HMAC-authenticated Diffie-Hellman for MIKEY August 2002 As such, DHHMAC but also digitally signed DH provides a far
As such, DH-HMAC but also digitally signed DH provides a far
superior security level over the pre-shared or public-key based superior security level over the pre-shared or public-key based
key distribution protocol in that respect. key distribution protocol in that respect.
* Fair, mutual key contribution: * Fair, mutual key contribution:
The Diffie-Hellman key management protocol is not a strict key The Diffie-Hellman key management protocol is not a strict key
distribution protocol per se with the initiator distributing a key distribution protocol per se with the initiator distributing a key
to its peers. Actually, both parties involved in the protocol to its peers. Actually, both parties involved in the protocol
exchange are able to equally contribute to the common Diffie- exchange are able to equally contribute to the common Diffie-
Hellman TEK traffic generating key. This reduces the risk of Hellman TEK traffic generating key. This reduces the risk of
either party cheating or unintentionally generating a weak session either party cheating or unintentionally generating a weak session
key. This makes the DH-HMAC a fair key agreement protocol. key. This makes the DHHMAC a fair key agreement protocol.
In order for Diffie-Hellman key agreement to be secure, each party In order for Diffie-Hellman key agreement to be secure, each party
shall generate its xi or xr values using a strong, unpredictable shall generate its xi or xr values using a strong, unpredictable
pseudo-random generator. Further these values xi or xr shall be pseudo-random generator. Further these values xi or xr shall be
kept private. It is recommended that these secret values be kept private. It is recommended that these secret values be
HMAC-authenticated Diffie-Hellman for MIKEY January 2003
destroyed once the common Diffie-Hellman shared secret key has destroyed once the common Diffie-Hellman shared secret key has
been established. been established.
* Efficiency and performance: * Efficiency and performance:
The DH-HMAC key agreement protocol securely establishes a TGK The DHHMAC key agreement protocol securely establishes a TGK
within just one roundtrip. Other existing key management within just one roundtrip. Other existing key management
techniques like IPSEC-IKE [13], IPSEC-SOI and TLS [12] and other techniques like IPSEC-IKE [14], IPSEC-SOI and TLS [13] and other
schemes are not deemed adequate in addressing sufficiently those schemes are not deemed adequate in addressing sufficiently those
real-time and security requirements. real-time and security requirements; they all use more than a
single roundtrip.
Using HMAC in conjunction with a strong one-way hash function such Using HMAC in conjunction with a strong one-way hash function such
as SHA1 may be achieved more efficiently in software than as SHA1 may be achieved more efficiently in software than
expensive public-key operations. This yields a particular expensive public-key operations. This yields a particular
performance benefit of DH-HMAC over signed DH or the public-key performance benefit of DHHMAC over signed DH or the public-key
encryption protocol. encryption protocol.
DH-HMAC optionally features a variant where the HMAC-SHA-1 result DHHMAC optionally features a variant where the HMAC-SHA-1 result
is truncated to 96-bit instead of 160 bits. It is believed that is 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 security provided would not suffer; it appears even reasonable
that the shorter HMAC could provide increased security against that the shorter HMAC could provide increased security against
known-plaintext crypt-analysis, see RFC 2104 for more details. In known-plaintext crypt-analysis, see RFC 2104 for more details. In
any way, truncated DH-HMAC 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 longer hash values may be deployed such as SHA256, SHA384 or
SHA512 provide, possibly in conjunction with stronger Diffie- SHA512 provide, possibly in conjunction with stronger Diffie-
Hellman groups. Hellman 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
either party may off-line pre-compute its public Diffie-Hellman either party may off-line pre-compute its public Diffie-Hellman
half-key. half-key.
On the other side and under reasonable conditions, DH-HMAC On the other side and under reasonable conditions, DHHMAC consumes
consumes more CPU cycles than the MIKEY pre-shared key more CPU cycles than the MIKEY pre-shared key distribution
distribution protocol. The same might hold true quite likely for protocol. The same might hold true quite likely for the MIKEY
HMAC-authenticated Diffie-Hellman for MIKEY August 2002 public-key distribution protocol (depending on choice of the
private and public key lengths).
the MIKEY public-key distribution protocol (depending on choice of
the private and public key lengths).
As such, it can be said that DH-HMAC provides sound performance As such, it can be said that DHHMAC provides sound performance
when compared with the other MIKEY protocol variants. when compared with the other MIKEY protocol variants.
* 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 agreement protocol that completely avoids digital signatures and
the associated public-key infrastructure as would be necessary for the associated public-key infrastructure as would be necessary for
the X.509 RSA public-key based key distribution protocol or the the X.509 RSA public-key based key distribution protocol or the
digitally signed Diffie-Hellman key agreement protocol as digitally signed Diffie-Hellman key agreement protocol as
described in MIKEY. Public-key infrastructures may not always be described in MIKEY. Public-key infrastructures may not always be
available in certain environments nor may they be deemed adequate available in certain environments nor may they be deemed adequate
for real-time multimedia applications when taking additional steps for real-time multimedia applications when taking additional steps
HMAC-authenticated Diffie-Hellman for MIKEY January 2003
for certificate validation and certificate revocation methods with for certificate validation and certificate revocation methods with
additional round-trips into account. additional round-trips into account.
DH-HMAC 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.
DH-HMAC 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.
* Firewall-friendliness: * NAT/Firewall-friendliness:
DH-HMAC is able to operate smoothly through firewall/NAT devices DHHMAC is able to operate smoothly through firewall/NAT devices as
as long as the protected identity information of the end entity is long as the protected identity information of the end entity is
not an IP /transport address. Of course, DH-HMAC does not not an IP /transport address. Of course, DHHMAC does not
necessarily require a firewall/NAT to operate. necessarily require a firewall/NAT to operate.
* Scalability: * Scalability:
Like the MIKEY signed Diffie-Hellman protocol, DH-HMAC does not Like the MIKEY signed Diffie-Hellman protocol, DHHMAC does not
scale to any larger configurations beyond peer-to-peer groups. scale to any larger configurations beyond peer-to-peer groups.
5.4. Assumptions 5.4. Assumptions
This document states a couple of assumptions upon which the security This document states a couple of assumptions upon which the security
of DH-HMAC significantly depends. It is assumed, that of DHHMAC significantly depends. It is assumed, that
* the parameters xi, xr, s and auth_key are to be kept secret. * the parameters xi, xr, s and auth_key are to be kept secret.
* the pre-shared key s has sufficient entropy and cannot be * the pre-shared key s has sufficient entropy and cannot
effectively guessed. beeffectively guessed.
* the pseudo-random function (PRF) is secure, yields indeed the * the pseudo-random function (PRF) is secure, yields indeed
pseudo-random property and maintains the entropy. thepseudo-random property and maintains the entropy.
* a sufficiently large and secure Diffie-Hellman group is applied. * a sufficiently large and secure Diffie-Hellman group is applied.
* the Diffie-Hellman assumption holds saying basically that even with * the Diffie-Hellman assumption holds saying basically that even with
knowledge of the exchanged Diffie-Hellman half-keys and knowledge knowledge of the exchanged Diffie-Hellman half-keys and knowledge
of the Diffie-Hellman group, it is infeasible to compute the TGK of the Diffie-Hellman group, it is infeasible to compute the TGK
or to derive the secret parameters xi or xr. The latter is also or to derive the secret parameters xi or xr. The latter is also
HMAC-authenticated Diffie-Hellman for MIKEY August 2002 called the discrete logarithm assumption. Please see [10], [11]
or [12] for more background information regarding the Diffie-
called the discrete logarithm assumption. Please see [9], [10] or Hellman problem and its computational complexity assumptions.
[11] for more background information regarding the Diffie-Hellman
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
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 [2]). applied to single blocks (see [2]).
* A source capable of producing sufficiently many bits of randomness HMAC-authenticated Diffie-Hellman for MIKEY January 2003
is available.
* The systems upon which DH-HMAC runs are sufficiently secure. * A source capable of producing sufficiently many bits of
randomnessis available.
The assumptions must be met as far as they can be enforced. * The systems upon which DHHMAC runs are sufficiently secure.
The assumptions MUST be met as far as they can be enforced.
5.5. Residual risk 5.5. Residual risk
Although these detailed assumptions are non-negligible, security Although these detailed assumptions are non-negligible, security
experts generally believe that all these assumptions are reasonable experts generally believe that all these assumptions are reasonable
and that the assumptions made can be fulfilled in practice with and that the assumptions made can be fulfilled in practice with
little or no expenses. little or no expenses.
The mathematical and cryptographic assumptions upon the properties of The mathematical and cryptographic assumptions upon the properties of
the PRF, the Diffie-Hellman algorithm (discrete log-assumption), the the PRF, the Diffie-Hellman algorithm (discrete log-assumption), the
HMAC and SHA1 algorithms have not been proved yet nor have they been HMAC and SHA1 algorithms have not been proved yet nor have they been
disproved by the time of this writing. disproved by the time of this writing.
Thus, a certain residual risk remains, which might threaten the Thus, a certain residual risk remains, which might threaten the
overall security at some unforeseeable time in the future. overall security at some unforeseeable time in the future.
The DH-HMAC would be compromised as soon as The DHHMAC would be compromised as soon as
* the discrete logarithm problem could be solved efficiently, * the discrete logarithm problem could be solved efficiently,
* the hash function could be subverted (efficient collisions become * the hash function could be subverted (efficient collisions
feasible), become feasible),
* 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 shared attempts to discover the shared secret. It is assumed that the
secret yields sufficient entropy to make such attacks infeasible, shared secret yields sufficient entropy to make such attacks
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 August 2002 It is not recommended to deploy DHHMAC for any other usage than
It is not recommended to deploy DH-HMAC for any other usage than
depicted in section 2. Otherwise any such misapplication might lead depicted in section 2. Otherwise any such misapplication might lead
to unknown, undefined properties. to unknown, undefined properties.
6. IANA considerations 6. IANA considerations
This document does not define its own new name spaces for DH-HMAC, This document does not define its own new name spaces for DHHMAC,
rather additional values for DH-HMAC are defined as part of the rather additional values for DHHMAC and EC are defined as part of
MIKEY fields. Thus, close alignment between DH-HMAC values and the MIKEY fields. Thus, close alignment between DHHMAC values and
MIKEY values shall be maintained; see also [1] section 10. MIKEY values shall be maintained; see also [1] section 10.
7. Intellectual Property Rights 7. Intellectual Property Rights
HMAC-authenticated Diffie-Hellman for MIKEY January 2003
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 existence of any proprietary or intellectual property rights in
the contribution that are reasonably and personally known to the 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
skipping to change at page 16, line 56 skipping to change at page 16, line 42
8. Acknowledgements 8. Acknowledgements
This document incorporates kindly review feedback by Steffen Fries This document incorporates kindly review feedback by Steffen Fries
and Fredrick Lindholm. and Fredrick Lindholm.
9. Conclusions 9. 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 [13] and IPSEC-SOI, TLS [12] and management techniques like IPSEC-IKE [14] and IPSEC-SOI, TLS [13] and
HMAC-authenticated Diffie-Hellman for MIKEY August 2002
other schemes are not deemed adequate in addressing sufficiently other schemes are not deemed adequate in addressing sufficiently
those real-time and security requirements. those real-time and security requirements.
MIKEY defines three key management security protocols addressing MIKEY defines three key management security protocols addressing
real-time constraints. DH-HMAC described in this document defines a real-time constraints. DHHMAC described in this document defines a
fourth MIKEY variant aiming at the same target. 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 is there are also certain limitations of each approach. As such there
no single ideal solution and none of the variants is able to subsume is no single ideal solution and none of the variants is able to
the other remaining variants. subsume the other remaining variants.
It is concluded that DH-HMAC features useful security and performance It is concluded that DHHMAC features useful security and performance
properties that none of the other three MIKEY variants is able to properties that none of the other three MIKEY variants is able to
provide. provide.
HMAC-authenticated Diffie-Hellman for MIKEY January 2003
10. Normative References 10. Normative References
[1] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman; [1] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman;
"MIKEY:Multimedia Internet KEYing", Internet Draft <draft-ietf-msec- "MIKEY:Multimedia Internet KEYing", Internet Draft <draft-ietf-msec-
mikey-04.txt>, Work in Progress (MSEC WG) mikey-05.txt>, Work in Progress (MSEC WG)
[2] H. Krawczyk, M. Bellare, R. Canetti; "HMAC: Keyed-Hashing for [2] H. Krawczyk, M. Bellare, R. Canetti; "HMAC: Keyed-Hashing for
Message Authentication", RFC 2104, February 1997. Message Authentication", RFC 2104, February 1997.
[3] NIST, FIBS-PUB 180-1, "Secure Hash Standard", April 1995, [3] 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
[4] S. Bradner: "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
11. Informative References 11. Informative References
[4] A.J. Menezes, P v. Oorschot, S. Vanstone: "Applied Cryptography", [5] A.J. Menezes, P v. Oorschot, S. Vanstone: "Applied Cryptography",
CRC Press, 1996 CRC Press, 1996
[5] E. Rescorla, B. Korver: " Guidelines for Writing RFC Text on [6] E. Rescorla, B. Korver: " Guidelines for Writing RFC Text on
Security Considerations", Work in Progress <draft-iab-sec-cons-00.txt>, Security Considerations", Work in Progress <draft-iab-sec-cons-01.txt>,
August 2002. October 2002.
[6] D. Eastlake, S. Crocker: "Randomness Recommendations for Security", [7] D. Eastlake, S. Crocker: "Randomness Recommendations for Security",
1750, IETF, December 1994. 1750, IETF, December 1994.
[7] S.M. Bellovin, J. I. Schiller: "Security Mechanisms for the [8] S.M. Bellovin, J. I. Schiller: "Security Mechanisms for the
Internet", Work in Progress <draft-iab-secmech-01.txt>, June 2002. Internet", Work in Progress <draft-iab-secmech-01.txt>, June 2002.
[8] S. Bradner: "The Internet Standards Process -- Revision 3", RFC [9] S. Bradner: "The Internet Standards Process -- Revision 3", RFC
2026, IETF, October 1996 2026, IETF, October 1996
[9] A.J. Menezes, P. van Oorschot, S. A. Vanstone: "Handbook of Applied [10] A.J. Menezes, P. van Oorschot, S. A. Vanstone: "Handbook of
Cryptography", CRC Press 1996. Applied Cryptography", CRC Press 1996.
[10] Ueli M. Maurer, S. Wolf: "The Diffie-Hellman Protocol", Designs, [11] Ueli M. Maurer, S. Wolf: "The Diffie-Hellman Protocol", Designs,
Codes, and Cryptography, Special Issue Public Key Cryptography, Kluwer Codes, and Cryptography, Special Issue Public Key Cryptography, Kluwer
HMAC-authenticated Diffie-Hellman for MIKEY August 2002
Academic Publishers, vol. 19, pp. 147-171, 2000. Academic Publishers, vol. 19, pp. 147-171, 2000.
ftp://ftp.inf.ethz.ch/pub/crypto/publications/MauWol00c.ps ftp://ftp.inf.ethz.ch/pub/crypto/publications/MauWol00c.ps
[11] 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/
[12] 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.
[13] D. Harkins, D. Carrel: "The Internet Key Exchange (IKE).", RFC HMAC-authenticated Diffie-Hellman for MIKEY January 2003
[14] D. Harkins, D. Carrel: "The Internet Key Exchange (IKE).", RFC
2409, IETF, November 1998. 2409, IETF, November 1998.
[14] Donald E. Eastlake, Jeffrey I. Schiller, Steve Crocker: [15] Donald E. Eastlake, Jeffrey I. Schiller, Steve Crocker:
"Randomness Requirements for Security"; <draft-eastlake-randomness2- "Randomness Requirements for Security"; <draft-eastlake-randomness2-
03.txt>; Work in Progress, IETF, 7/2002. 03.txt>; Work in Progress, IETF, 7/2002.
[15] 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
Security Analysis", Work in Progress < draft-irtf-cfrg-advice-00.txt>,
October 2002.
[18] Steven M. Bellovin: "Security Mechanisms for the Internet", Work
in Progress <draft-iab-secmech-01.txt>, June 2002.
[19] T. Narten: "Guidelines for Writing an IANA Considerations Section
in RFCs", RFC 2434, October 1998.
[20] J. Reynolds: "Instructions to Request for Comments (RFC) Authors",
Work in Progress, <draft-rfc-editor-rfc2223bis-03.txt>, IETF, 12
October 2002.
[21] J. Rosenberg et all: "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[22] J. Arkko et al: "Key Management Extensions for SDP and RTSP", Work
in Progress, <draft-ietf-mmusic-kmgmt-ext-05.txt>, June, 2002.
12. Author's Address 12. Author's Address
Please address all comments to: Please address all comments to:
Martin Euchner Siemens AG Martin Euchner Siemens AG
Email: martin.euchner@icn.siemens.de ICN M SR 3 Email: martin.euchner@siemens.com ICN M SR 3
Phone: +49 89 722 55790 Hofmannstr. 51 Phone: +49 89 722 55790 Hofmannstr. 51
Fax: +49 89 722 47713 81359 Munich, Germany Fax: +49 89 722 62366
13. Expiration Date 81359 Munich, Germany
This Internet Draft expires on 30 February 2003. 13. Full Copyright Statement
14. Revision History Copyright (C) The Internet Society (2003). All Rights Reserved.
Changes against draft-euchner-MIKEY-DHHMAC-00.txt: This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
HMAC-authenticated Diffie-Hellman for MIKEY January 2003
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
14. Expiration Date
This Internet Draft expires on 30 June 2003.
15. Revision History
Changes against draft-ietf-msec-mikey-dhhmac-00.txt:
* category set to proposed standard.
* identity protection clarified.
* aligned with MIKEY-05 DH protocol, notation and with payload
* some editorials and nits.
Changes against draft-euchner-mikey-dhhmac-00.txt:
* made a MSEC WG draft * 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 [5]. the spirit of [6].
* IANA consideration section added * IANA consideration section added
* a few editorial improvements and corrections * a few editorial improvements and corrections
* IPR clarified and IPR section changed * IPR clarified and IPR section changed.
 End of changes. 

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