HMAC-authenticated Diffie-Hellman for MIKEY May 2004
Internet Engineering Task Force - MSEC WG
Internet Draft M. Euchner
Intended Category: Proposed Standard
Expires: December 2004 May 2004
HMAC-authenticated Diffie-Hellman for MIKEY
<draft-ietf-msec-mikey-dhhmac-06.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
The distribution of this memo is unlimited.
Comments should be sent to the MSEC WG mailing list at
msec@securemulticast.org and to the author.
Abstract
This document describes a light-weight point-to-point key management
protocol variant for the multimedia Internet keying (MIKEY). In
particular, the classic Diffie-Hellman key agreement protocol is
used
for key establishment in conjunction with a keyed hash (HMAC-SHA1)
Euchner Expires =96 December 2004 [Page 1]
HMAC-authenticated Diffie-Hellman for MIKEY May 2004
for achieving mutual authentication and message integrity of the key
management messages exchanged. This MIKEY variant is called the
HMAC-authenticated Diffie-Hellmann (DHHMAC). It addresses the
security and performance constraints of multimedia key management in
MIKEY.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this
document are to be interpreted as described in RFC-2119 [2].
Table of Contents
1. Introduction................................................3
1.1. Definitions.................................................5
1.2. Abbreviations...............................................6
2. Scenario....................................................7
2.1. Applicability...............................................8
3. DHHMAC Security Protocol...................................10
3.1. TGK re-keying..............................................12
4. DHHMAC payload formats.....................................12
4.1. Common header payload (HDR)................................13
4.2. Key data transport payload (KEMAC).........................14
4.3. ID payload (ID)............................................15
5. Security Considerations....................................15
5.1. Security environment.......................................15
5.2. Threat model...............................................15
5.3. Security features and properties...........................18
5.4. Assumptions................................................22
5.5. Residual risk..............................................23
IANA considerations.............................................25
Intellectual Property Rights....................................25
References......................................................26
Normative References............................................26
Informative References..........................................26
Acknowledgments.................................................28
Conclusions.....................................................28
Full Copyright Statement........................................29
Expiration Date.................................................29
Revision History................................................30
Euchner Expires =96 December 2004 [Page 2]
HMAC-authenticated Diffie-Hellman for MIKEY May 2004
Author's Addresses..............................................31
1. Introduction
There is work done in IETF to develop key management schemes. For
example, IKE [14] is a widely accepted unicast scheme for IPsec, and
the MSEC WG is developing other schemes, addressed to group
communication [24], [25]. For reasons discussed below, there is
however a need for a scheme with low latency, suitable for demanding
cases such as real-time data over heterogeneous networks, and small
interactive groups.
As pointed out in MIKEY (see [3]), secure real-time multimedia
applications demand a particular adequate light-weight key management
scheme that cares for how to securely and efficiently establish
dynamic session keys in a conversational multimedia scenario.
In general, MIKEY scenarios cover peer-to-peer, simple-one-to-many
and small-sized groups. MIKEY in particular, describes three key
management schemes for the peer-to-peer case that all finish their
task within one round trip:
- a symmetric key distribution protocol (MIKEY-PS) based upon
pre-shared master keys;
- a public-key encryption-based key distribution protocol
(MIKEY-PK) assuming a public-key infrastructure with RSA-based
(Rivest, Shamir and Adleman) private/public keys and digital
certificates;
- and a Diffie-Hellman key agreement protocol (MIKEY-DHSIGN)
deploying digital signatures and certificates.
All these three key management protocols are designed such that they
complete their work within just one round trip. This requires
depending on loosely synchronized clocks and deploying timestamps
within the key management protocols.
However, it is known [7] that each of the three key management
schemes has its subtle constraints and limitations:
- The symmetric key distribution protocol (MIKEY-PS) is simple
to
Euchner Expires =96 December 2004 [Page 3]
HMAC-authenticated Diffie-Hellman for MIKEY May 2004
implement but does not nicely scale in any larger
configuration
of potential peer entities due to the need of mutually pre-
assigned shared master secrets.
Moreover, the security provided does not achieve the property
of perfect forward secrecy; i.e. compromise of the shared
master secret would render past and even future session keys
susceptible to compromise.
Further, the generation of the session key happens just at the
initiator. Thus, the responder has to fully trust the
initiator on choosing a good and secure session secret; the
responder neither is able to participate in the key generation
nor to influence that process. This is considered as a
specific limitation in less trusted environments.
- The public-key encryption scheme (MIKEY-PK) depends upon a
public-key infrastructure that certifies the private-public
keys by issuing and maintaining digital certificates. While
such a key management scheme provides full scalability in
large
networked configurations, public-key infrastructures are still
not widely available and in general, implementations are
significantly more complex.
Further, additional round trips might be necessary for each
side in order to ascertain verification of the digital
certificates.
Finally, as in the symmetric case, the responder depends
completely upon the initiator choosing good and secure session
keys.
- The third MIKEY-DHSIGN key management protocol deploys the
Diffie-Hellman key agreement scheme and authenticates the
exchange of the Diffie-Hellman half-keys in each direction by
using a digital signature upon. As in the previous method,
this introduces the dependency upon a public-key
infrastructure
with its strength on scalability but also the limitations on
computational costs in performing the asymmetric long-integer
operations and the potential need for additional communication
for verification of the digital certificates.
Euchner Expires =96 December 2004 [Page 4]
HMAC-authenticated Diffie-Hellman for MIKEY May 2004
However, the Diffie-Hellman key agreement protocol is known
for
its subtle security strengths in that it is able to provide
full perfect forward secrecy (PFS) and further have both
parties actively involved in session key generation. This
special security property - despite the somewhat higher
computational costs - makes Diffie-Hellman techniques
attractive in practice.
In order to overcome some of the limitations as outlined above, a
special need has been recognized for another efficient key agreement
protocol variant in MIKEY. This protocol variant aims to provide the
capability of perfect forward secrecy as part of a key agreement with
low latency without dependency on a public-key infrastructure.
This document describes such a fourth light-weight key management
scheme for MIKEY that could somehow be seen as a synergetic
optimization between the pre-shared key distribution scheme and the
Diffie-Hellman key agreement.
The idea of that protocol is to apply the Diffie-Hellman key
agreement but instead of deploying a digital signature for
authenticity of the exchanged keying material rather uses a keyed-
hash upon using symmetrically pre-assigned shared secrets. This
combination of security mechanisms is called the HMAC-authenticated
Diffie-Hellman (DH) key agreement for MIKEY (DHHMAC).
The DHHMAC variant closely follows the design and philosophy of MIKEY
and reuses MIKEY protocol payload components and MIKEY mechanisms to
its maximum benefit and for best compatibility.
Like the MIKEY Diffie-Hellman protocol, DHHMAC does not scale beyond
a point-to-point constellation; thus, both MIKEY Diffie-Hellman
protocols do not support group-based keying for any group size larger
than two entities.
1.1. Definitions
The definitions and notations in this document are aligned with
MIKEY, see [3] and [3] sections 1.3 - 1.4.
Euchner Expires =96 December 2004 [Page 5]
HMAC-authenticated Diffie-Hellman for MIKEY May 2004
All large integer computations in this document should be understood
as being mod p within some fixed group G for some large prime p; see
[3] section 3.3; however, the DHHMAC protocol is applicable in
general to other appropriate finite, cyclical groups as well.
It is assumed that a pre-shared key s is known by both entities
(initiator and responder). The authentication key auth_key is
derived from the pre-shared secret s using the pseudo-random function
PRF; see [3] sections 4.1.3 and 4.1.5.
In this text, [X] represents an optional piece of information.
Generally throughout the text, X SHOULD be present unless certain
circumstance MAY allow X being optional and not be present thereby
resulting in weaker security potentially. Likewise [X, Y] represents
an optional compound piece of information where the pieces X and Y
SHOULD be either both present or MAY optionally be both absent.
1.2. Abbreviations
auth_key pre-shared authentication key, PRF-derived from
pre-shared key s.
DH Diffie-Hellman
DHi public Diffie-Hellman half key g^(xi) of
Initiatior
DHr public Diffie-Hellman half key g^(xr) of Responder
DHHMAC HMAC-authenticated Diffie-Hellman
DoS Denial-of-service
G Diffie-Hellman group
HDR MIKEY common header payload
HMAC keyed Hash Message Authentication Code
HMAC-SHA1 HMAC using SHA1 as hash function (160-bit result)
IDi Identity of initiator
IDr Identity of receiver
IKE Internet Key Exchange
IPSec Internet Protocol Security
MIKEY Multimedia Internet KEYing
MIKEY-DHHMAC MIKEY Diffie-Hellman key management protocol using
HMAC
MIKEY-DHSIGN MIKEY Diffie-Hellman key agreement protocol
MIKEY-PK MIKEY public-key encryption-based key distribution
protocol
MIKEY-PS MIKEY pre-shared key distribution protocol
p Diffie-Hellman prime modulus
Euchner Expires =96 December 2004 [Page 6]
HMAC-authenticated Diffie-Hellman for MIKEY May 2004
PRF MIKEY pseudo-random function (see [3] section
4.1.3.)
RSA Rivest, Shamir and Adleman
s pre-shared key
SDP Session Description Protocol
SOI Son-of-IKE, IKEv2
SP MIKEY Security Policy (Parameter) Payload
T timestamp
TEK Traffic Encryption Key
TGK MIKEY TEK Generation Key as the common Diffie-
Hellman shared secret
TLS Transport Layer Security
xi secret, (pseudo) random Diffie-Hellman key of the
Initiator
xr secret, (pseudo) random Diffie-Hellman key of the
Responder
2. Scenario
The HMAC-authenticated Diffie-Hellman key agreement protocol (DHHMAC)
for MIKEY addresses the same scenarios and scope as the other three
key management schemes in MIKEY address.
DHHMAC is applicable in a peer-to-peer group where no access to a
public-key infrastructure can be assumed available. Rather, pre-
shared master secrets are assumed available among the entities in
such an environment.
In a pair-wise group, it is assumed that each client will be setting
up a session key for its outgoing links with it's peer using the DH-
MAC key agreement protocol.
As is the case for the other three MIKEY key management protocol,
DHHMAC assumes loosely synchronized clocks among the entities in the
small group.
Note: To synchronize the clocks in a secure manner, some operational
or procedural means are recommended. However, MIKEY-DHHMAC does not
describe any secure time synchronization measures and leaves such
tasks to the discretion of the implementation.
Euchner Expires =96 December 2004 [Page 7]
HMAC-authenticated Diffie-Hellman for MIKEY May 2004
2.1. Applicability
MIKEY-DHHMAC as well as the other MIKEY key management protocols are
optimized and targeted for the purpose of multimedia applications
with application-level key management needs under real-time session
setup and session management constraints.
As the MIKEY-DHHMAC key management protocol terminates in one
roundtrip, DHHMAC is applicable for integration into two-way
handshake session- or call signaling protocols such as
a) SIP/SDP (see [5]) where the encoded MIKEY messages are
encapsulated and transported in SDP containers of the SDP
offer/answer handshake,
b) H.323 (see [22]) where the encoded MIKEY messages are transported
in the H.225.0 fast start call signaling handshake.
MIKEY-DHHMAC is offered as option to the other MIKEY key management
variants (MIKEY-pre-shared, MIKEY-public-key and MIKEY-DH-SIGN) for
all those cases where DHHMAC has its peculiar strengths (see section
5).
2.1.1. Usage in H.235
This section provides informative overview how MIKEY-DHHMAC can be
applied in some H.323-based multimedia environments. Generally,
MIKEY is applicable for multimedia applications including IP
telephony. [22] describes various use cases of the MIKEY key
management protocols (MIKEY-PS, MIKEY-PK, MIKEY-DHSIGN and MIKEY-
DHHMAC) with the purpose to establish TGK keying material among
H.323
endpoints. The TGKs are then used for media encryption by applying
SRTP [27]. Addressed scenarios include point-to-point with one or
more intermediate gatekeepers (trusted or partially trusted) in-
between.
One particular use case addresses MIKEY-DHHMAC to establish a media
connection from an endpoint B calling (through a gatekeeper) to
another endpoint A that is located within that same gatekeeper zone.
While EP-A and EP-B typically do not share any auth_key a priori,
some separate protocol exchange means are achieved outside the
actual
call setup procedure to establish an auth_key for the time while
Euchner Expires =96 December 2004 [Page 8]
HMAC-authenticated Diffie-Hellman for MIKEY May 2004
endpoints are being registered with the gatekeeper; such protocols
exist [22] but are not shown in this document. The auth_key between
the endpoints is being used to authenticate and integrity protect
the
MIKEY-DHHMAC messages.
To establish a call, it is assumed that endpoint B has obtained
permission from the gatekeeper (not shown). Endpoint B as the
caller
builds the MIKEY-DHHMAC I_message(see section 3) and sends the
I_message encapsulated within the H.323-SETUP to endpoint A. A
routing gatekeeper (GK) would forward this message to endpoint B; in
case of a non-routing gatekeeper, endpoint B sends the SETUP
directly
to endpoint A. In either case, H.323 inherent security mechanisms
[28] are applied to protect the (encapsulation) message during
transfer. This is not depicted here. The receiving endpoint A is
able to verify the conveyed I_message and can compute a TGK.
Assuming that endpoint A would accept the call, EP-A then builds the
MIKEY-DHHMAC R_message and sends the response as part of the
CallProceeding-to-Connect message back to the calling endpoint B
(possibly through a routing gatekeeper). Endpoint B processes the
conveyed R_message to compute the same TGK as the called endpoint A.
1.) EP-B -> (GK) -> EP-A: SETUP(I_fwd_message [, I_rev_message])
2.) EP-A -> (GK) -> EP-B: CallProceeding-to-CONNECT(R_fwd_message [,
R_rev_message])
Notes: If it is necessary to establish directional TGKs for full-
duplex links in both directions B->A and A->B, then the
calling endpoint B instantiates the DHHMAC protocol twice:
once in the direction B->A using I_fwd_message and another
run in parallel in the direction A->B using I_rev_message.
In that case, two MIKEY-DHHMAC I_messages are encapsulated
within SETUP (I_fwd_message and I_rev_message) and two
MIKEY-DHHMAC R_messages (R_fwd_message and R_rev_message)
are encapsulted within CallProceeding-to-CONNECT. The
I_rev_message corresponds with the I_fwd_message.
Alternatively, the called endpoint A may instantiate the
DHHMAC protocol in a separate run with endpoint B (not
shown); however, this requires a third handshake to
complete.
For more details on how the MIKEY protocols may be deployed
with H.235, please refer to [22].
Euchner Expires =96 December 2004 [Page 9]
HMAC-authenticated Diffie-Hellman for MIKEY May 2004
2.2. Relation to GKMARCH
The Group key management architecture (GKMARCH) [26] describes a
generic architecture for multicast security group key management
protocols. In the context of this architecture, MIKEY-DHHMAC may
operate as a registration protocol. The main entities involved in
the architecture are a group controller/key server (GCKS), the
receiver(s), and the sender(s). Due to the pair-wise nature of the
Diffie-Hellman operation and the 1-roundtrip constraint, usage of
MIKEY-DHHMAC rules out any deployment as a group key management
protocol with more than two group entities. Only the degenerate case
with two peers is possible where for example the responder acts as
the group controller.
Note that MIKEY does not provide re-keying in the GKMARCH sense, only
updating of the keys by normal unicast messages.
3. DHHMAC Security Protocol
The following figure defines the security protocol for DHHMAC:
Initiator Responder
I_message =3D HDR, T, RAND, [IDi], IDr,
{SP}, DHi, KEMAC
I_message
-----------------------> R_message =3D HDR, T,
[IDr], IDi, DHr,
DHi, KEMAC
R_message
<----------------------
TGK =3D g^(xi * yi) TGK =3D g^(xi * yi)
Figure 1: HMAC-authenticated Diffie-Hellman key based exchange,
where xi and xr are (pseudo) randomly chosen respectively
by the initiator and the responder.
Euchner Expires =96 December 2004 [Page 10]
HMAC-authenticated Diffie-Hellman for MIKEY May 2004
The DHHMAC key exchange SHALL be done according to Figure 1. The
initiator chooses a (pseudo) random value xi, and sends an HMACed
message including g^(xi) and a timestamp to the responder. It is
recommended that the initiator SHOULD always include the identity
payloads IDi and IDr within the I_message; unless the receiver can
defer the initiator's identity by some other means, then IDi MAY
optionally be left out. The initiator SHALL always include the
recipient=92s identity.
The group parameters (e.g., the group G) are a set of parameters
chosen by the initiator. The responder chooses a (pseudo) random
positive integer xr, and sends an HMACed message including g^(xr)
and the timestamp to the initiator. The responder SHALL always
include the initiator's identity IDi regardless of whether the
I_message conveyed any IDi. It is recommended that the responder
SHOULD always include the identity payload IDr within the
R_message; unless the initiator can defer the reponder's identity
by some other means, then IDr MAY optionally be left out.
Both parties then calculate the TGK, g^(xi * xr).
The HMAC authentication is due to provide authentication of the DH
half-keys, and is necessary to avoid man-in-the-middle attacks.
This approach is less expensive than digitally signed Diffie-
Hellman. It requires first of all, that both sides compute one
exponentiation and one HMAC, then one HMAC verification and
finally
another Diffie-Hellman exponentiation.
With off-line pre-computation, the initial Diffie-Hellman half-key
MAY be computed before the key management transaction and thereby
MAY further reduce the overall round trip delay as well as reduce
the risk of denial-of-service attacks.
Processing of the TGK SHALL be accomplished as described in MIKEY
[3] chapter 4.
The computed HMAC result SHALL be conveyed in the KEMAC payload
field where the MAC fields holds the HMAC result. The HMAC shall
be computed over the entire message excluding the MAC field using
auth_key, see also section 4.2.
Euchner Expires =96 December 2004 [Page 11]
HMAC-authenticated Diffie-Hellman for MIKEY May 2004
3.1. TGK re-keying
TGK re-keying for DHHMAC generally proceeds as described in [3]
section 4.5. Specifically, figure 2 provides the message fields
for DHHMAC update message.
Initiator Responder
I_message =3D HDR, T, [IDi], IDr,
{SP}, [DHi], KEMAC
I_message
-----------------------> R_message =3D HDR, T,
[IDr], IDi,
[DHr, DHi], KEMAC
R_message
<----------------------
[TGK =3D g^(xi * yi)] [TGK =3D g^(xi * yi)]
Figure 2: DHHMAC update message
TGK re-keying supports two procedures:
a) True re-keying by exchanging new and fresh Diffie-Hellman half-
keys. For this, the initiator SHALL provide a new, fresh DHi
and the responder SHALL respond with a new, fresh DHr and the
received DHi.
b) Non-key related information update without any Diffie-Hellman
half-keys included in the exchange. Such transaction does not
change the actual TGK but updates other information like
security policy parameters for example. To only update the
non-key related information, [DHi] and [DHr, DHi] SHALL be
left
out.
4. DHHMAC payload formats
Euchner Expires =96 December 2004 [Page 12]
HMAC-authenticated Diffie-Hellman for MIKEY May 2004
This section specifies the payload formats and data type values for
DHHMAC, see also [3] chapter 6 for a definition of the MIKEY
payloads.
The following referenced MIKEY payloads are used for DH-MAC:
* Common header payload (HDR), see section 4.1 and [3] section 6.1
* SRTP ID sub-payload, see [3] section 6.1.1,
* Key data transport payload (KEMAC), see section 4.2 and [3] section
6.2
* DH data payload, see [3] section 6.4
* Timestamp payload, [3] section 6.6
* ID payload, [3] section 6.7
* Security Policy payload (SP), [3] section 6.10
* RAND payload (RAND), [3] section 6.11
* Error payload (ERR), [3] section 6.12
* General Extension Payload, [3] section 6.15
4.1. Common header payload (HDR)
Referring to [3] section 6.1, for DHHMAC the following data types
SHALL be used:
Data type | Value | Comment
-------------------------------------------------------------
DHHMAC init | 7 | Initiator's DHHMAC exchange message
DHHMAC resp | 8 | Responder's DHHMAC exchange message
Error | 6 | Error message, see [3] section 6.12
Euchner Expires =96 December 2004 [Page 13]
HMAC-authenticated Diffie-Hellman for MIKEY May 2004
The next payload field shall be one of the following values:
Next payload| Value | Section
----------------------------------------------------------------
Last payload| 0 | -
KEMAC | 1 | section 4.2 and [3] section 6.2
DH | 3 | [3] section 6.4
T | 5 | [3] section 6.6
ID | 6 | [3] section 6.7
SP | 10 | [3] section 6.10
RAND | 11 | [3] section 6.11
ERR | 12 | [3] section 6.12
General Ext.| 21 | [3] section 6.15
Other defined next payload values defined in [3] SHALL not be
applied to DHHMAC.
The responder in case of a decoding error or of a failed HMAC
authentication verification SHALL apply the Error payload data
type.
4.2. Key data transport payload (KEMAC)
DHHMAC SHALL apply this payload for conveying the HMAC result
along
with the indicated authentication algorithm. KEMAC when used 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 to 0
and Encr data SHALL be left empty. The AES key wrap method (see
[23]) SHALL not be applied for DHHMAC.
For DHHMAC, this key data transport payload SHALL be the last
payload in the message. Note that the Next payload field SHALL be
set to Last payload. The HMAC is then calculated over the entire
MIKEY message excluding the MAC field using auth_key as described
in [3] section 5.2 and then stored within MAC field.
MAC alg | Value | Comments
------------------------------------------------------------------
HMAC-SHA-1 | 0 | Mandatory, Default (see [4])
NULL | 1 | Very restricted use, see
| [3] section 4.2.4
Euchner Expires =96 December 2004 [Page 14]
HMAC-authenticated Diffie-Hellman for MIKEY May 2004
HMAC-SHA-1 is the default hash function that MUST be implemented
as
part of the DHHMAC. The length of the HMAC-SHA-1 result is 160
bits.
4.3. ID payload (ID)
For DHHMAC, this payload SHALL only hold a non-certificate based
identity.
5. Security Considerations
This document addresses key management security issues throughout.
For a comprehensive explanation of MIKEY security considerations,
please refer to MIKEY [3] section 9.
In addition to that, this document addresses security issues
according to [8] where the following security considerations apply in
particular to this document:
5.1. Security environment
Generally, the DHHMAC security protocol described in this document
focuses primarily on communication security; i.e. the security issues
concerned with the MIKEY DHHMAC protocol. Nevertheless, some system
security issues are of interest as well that are not explicitly
defined by the DHHMAC protocol, but should be provided locally in
practice.
The system where the DHHMAC protocol entity runs upon shall provide
the capability to generate (pseudo) random numbers as input to the
Diffie-Hellman operation (see [9], [15]). Further, the system shall
be capable of storing the generated (pseudo) random data, secret
data, keys and other secret security parameters securely (i.e.
confidential and safe from unauthorized tampering).
5.2. Threat model
The threat model that this document adheres to cover the issues of
end-to-end security in the Internet generally; without ruling out the
Euchner Expires =96 December 2004 [Page 15]
HMAC-authenticated Diffie-Hellman for MIKEY May 2004
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
DHHMAC proxies" involved.
Since DHHMAC is a key management protocol, the following security
threats are of concern:
* Unauthorized interception of plain TGKs.
This threat shall not occur. Nevertheless, for DHHMAC this threat
does not occur since the TGK is not actually transmitted on the
wire (not even in encrypted fashion).
* Eavesdropping of other, transmitted keying information:
DHHMAC protocol does not explicitly transmit the TGK at all.
Rather, by the Diffie-Hellman "encryption" operation, that conceals
the secret (pseudo) random values, only partial information (i.e.
the DH- half key) for construction of the TGK is transmitted. It
is fundamentally assumed that availability of such Diffie-Hellman
half-keys to an eavesdropper does not result in any substantial
security risk; see 5.4. Further, the DHHMAC carries other data
such as timestamps, (pseudo) random values, identification
information or security policy parameters; eavesdropping of any
such data is considered not to yield any significant security risk.
* Masquerade of either entity:
This security threat must be avoided and if a masquerade attack
would be attempted, appropriate detection means must be in place.
DHHMAC addresses this threat by providing mutual peer entity
authentication.
* Man-in-the-middle attacks:
Such attacks threaten the security of exchanged, non-authenticated
messages. Man-in-the-middle attacks usually come with masquerade
and or loss of message integrity (see below). Man-in-the-middle
attacks must be avoided, and if present or attempted must be
detected appropriately. DHHMAC addresses this threat by providing
mutual peer entity authentication and message integrity.
* Loss of integrity:
This security threat relates to unauthorized replay, deletion,
insertion and manipulation of messages. While any such attacks
Euchner Expires =96 December 2004 [Page 16]
HMAC-authenticated Diffie-Hellman for MIKEY May 2004
cannot be avoided they must be detected at least. DHHMAC addresses
this threat by providing message integrity.
* Bidding-down attacks:
When multiple key management protocols each of a distinct security
level are offered (e.g., such as is possible by SDP [5]), avoiding
bidding-down attacks is of concern. DHHMAC addresses this threat
by reusing the MIKEY mechanism as described in [3] section 7.1,
where all key management protocol identifiers must be listed
within
the MIKEY General Extension Payload. The protocol identifier for
DHHMAC shall be "mikeydhhmac". The General Extension Payload must
be integrity-protected with the HMAC using the shared secret.
Some potential threats are not within the scope of this threat model:
* Passive and off-line cryptanalysis of the Diffie-Hellman algorithm:
Under certain reasonable assumptions (see 5.4 below) it is widely
believed that DHHMAC is sufficiently secure and that such attacks
be infeasible although the possibility of a successful attack
cannot be ruled out completely.
* Non-repudiation of the receipt or of the origin of the message:
These are not requirements of this environment and thus related
countermeasures are not provided at all.
* Denial-of-service or distributed denial-of-service attacks:
Some considerations are given on some of those attacks, but DHHMAC
does not claim to provide full countermeasure against any of those
attacks. For example, stressing the availability of the entities
are not thwarted by means of the key management protocol; some
other local countermeasures should be applied. Further, some DoS
attacks are not countered such as interception of a valid DH-
request and its massive instant duplication. Such attacks might at
least be countered partially by some local means that are outside
the scope of this document.
* Identity protection:
Like MIKEY, identity protection is not a major design requirement
for MIKEY-DHHMAC either, see [3]. No security protocol is known so
far, that is able to provide the objectives of DHHMAC as stated in
section 5.3 including identity protection within just a single
roundtrip. MIKEY-DHHMAC trades identity protection for better
Euchner Expires =96 December 2004 [Page 17]
HMAC-authenticated Diffie-Hellman for MIKEY May 2004
security for the keying material and shorter roundtrip time. Thus,
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 ([20], [5]); both those protocols do not provide end-to-end
identity protection either.
The DHHMAC security protocol (see section 3) and the TGK re-keying
security protocol (see section 3.1) provide the option not to
supply identity information. This option is only applicable if
some other means are available of supplying trustworthy identity
information; e.g., by relying on secured links underneath of MIKEY
that supply trustworthy identity information otherwise. However,
it is understood that without identity information present, the
MIKEY key management security protocols might be subject to
security weaknesses such as masquerade, impersonation and
reflection attacks particularly in end-to-end scenarios where no
other secure means of assured identity information is provided.
Leaving identity fields optional if possible thus should not be
seen as a privacy method either, but rather as a protocol
optimization feature.
5.3. Security features and properties
With the security threats in mind, this draft provides the following
security features and yields the following properties:
* Secure key agreement with the establishment of a TGK at both peers:
This is achieved using an authenticated Diffie-Hellman key
management protocol.
* Peer-entity authentication (mutual):
This authentication corroborates that the host/user is authentic in
that possession of a pre-assigned secret key is proven using keyed
HMAC. The authentication occurs on the request and on the response
message, thus authentication is mutual.
The HMAC computation corroborates for authentication and message
integrity of the exchanged Diffie-Hellman half-keys and associated
Euchner Expires =96 December 2004 [Page 18]
HMAC-authenticated Diffie-Hellman for MIKEY May 2004
messages. The authentication is absolutely necessary in order to
avoid man-in-the-middle attacks on the exchanged messages in
transit and in particular, on the otherwise non-authenticated
exchanged Diffie-Hellman half keys.
Note: This document does not address issues regarding
authorization; this feature is not provided explicitly. However,
DHHMAC authentication means support and facilitate realization of
authorization means (local issue).
* Cryptographic integrity check:
The cryptographic integrity check is achieved using a message
digest (keyed HMAC). It includes the exchanged Diffie-Hellman
half-keys but covers the other parts of the exchanged message as
well. Both mutual peer entity authentication and message integrity
provide effective countermeasure against man-in-the-middle attacks.
The initiator may deploy a local timer that fires when the awaited
response message did not arrive timely. This is to detect deletion
of entire messages.
* Replay protection of the messages is achieved using embedded
timestamps.
* Limited DoS protection:
Rapid checking of the message digest allows verifying the
authenticity and integrity of a message before launching CPU
intensive Diffie-Hellman operations or starting other resource
consuming tasks. This protects against some denial-of-service
attacks: malicious modification of messages and spam attacks with
(replayed or masqueraded) messages. DHHMAC probably does not
explicitly counter sophisticated distributed, large-scale denial-
of-service attacks that compromise system availability for example.
Some DoS protection is provided by inclusion of the initiator=92s
identity payload in the I_message. This allows the recipient to
filter out those (replayed) I_messages that are not targeted for
him and avoids the recipient from creating unnecessary MIKEY
sessions.
* Perfect-forward secrecy (PFS):
Other than the MIKEY pre-shared and public-key based key
distribution protocols, the Diffie-Hellman key agreement protocol
features a security property called perfect forward secrecy. That
Euchner Expires =96 December 2004 [Page 19]
HMAC-authenticated Diffie-Hellman for MIKEY May 2004
is, that even if the long-term pre-shared key would be compromised
at some point in time, this would not render past or future session
keys compromised.
Neither the MIKEY pre-shared nor the MIKEY public-key protocol
variants are able to provide the security property of perfect-
forward secrecy. Thus, none of the other MIKEY protocols is able
to substitute the Diffie-Hellman PFS property.
As such, DHHMAC but also digitally signed DH provides a far
superior security level over the pre-shared or public-key based key
distribution protocol in that respect.
* Fair, mutual key contribution:
The Diffie-Hellman key management protocol is not a strict key
distribution protocol per se with the initiator distributing a key
to its peers. Actually, both parties involved in the protocol
exchange are able to equally contribute to the common Diffie-
Hellman TEK traffic generating key. This reduces the risk of
either party cheating or unintentionally generating a weak session
key. This makes the DHHMAC a fair key agreement protocol. One may
view this property as an additional distributed security measure
that is increasing security robustness over the case where all the
security depends just on the proper implementation of a single
entity.
In order for Diffie-Hellman key agreement to be secure, each party
shall generate its xi or xr values using a strong, unpredictable
pseudo-random generator if a source of true randomness is not
available. Further, these values xi or xr shall be kept private.
It is recommended that these secret values be destroyed once the
common Diffie-Hellman shared secret key has been established.
* Efficiency and performance:
Like the MIKEY-public key protocol, the MIKEY DHHMAC key agreement
protocol securely establishes a TGK within just one roundtrip.
Other existing key management techniques like IPSEC-IKE [14],
IPSEC-IKEv2 [21] and TLS [13] and other schemes are not deemed
adequate in addressing sufficiently those real-time and security
requirements; they all use more than a single roundtrip. All the
MIKEY key management protocols are able to complete their task of
security policy parameter negotiation including key-agreement or
key distribution in one roundtrip. However, the MIKEY pre-shared
Euchner Expires =96 December 2004 [Page 20]
HMAC-authenticated Diffie-Hellman for MIKEY May 2004
and the MIKEY public-key protocol both are able to complete their
task even in a half-round trip when the confirmation messages are
omitted.
Using HMAC in conjunction with a strong one-way hash function such
as SHA1 may be achieved more efficiently in software than expensive
public-key operations. This yields a particular performance
benefit of DHHMAC over signed DH or the public-key encryption
protocol.
If a very high security level is desired for long-term secrecy of
the negotiated Diffie-Hellman shared secret, longer hash values may
be deployed such as SHA256, SHA384 or SHA512 provide, possibly in
conjunction with stronger Diffie-Hellman groups. This is left as
for further study.
For the sake of improved performance and reduced round trip delay
either party may off-line pre-compute its public Diffie-Hellman
half-key.
On the other side and under reasonable conditions, DHHMAC consumes
more CPU cycles than the MIKEY pre-shared key distribution
protocol. The same might hold true quite likely for the MIKEY
public-key distribution protocol (depending on choice of the
private and public key lengths).
As such, it can be said that DHHMAC provides sound performance when
compared with the other MIKEY protocol variants.
The use of optional identity information (with the constraints
stated in section 5.2) and optional Diffie-Hellman half-key fields
provides a means to increase performance and shorten the consumed
network bandwidth.
* Security infrastructure:
This document describes the HMAC-authenticated Diffie-Hellman key
agreement protocol that completely avoids digital signatures and
the associated public-key infrastructure as would be necessary for
the X.509 RSA public-key based key distribution protocol or the
digitally signed Diffie-Hellman key agreement protocol as described
in MIKEY. Public-key infrastructures may not always be available
in certain environments nor may they be deemed adequate for real-
time multimedia applications when taking additional steps for
Euchner Expires =96 December 2004 [Page 21]
HMAC-authenticated Diffie-Hellman for MIKEY May 2004
certificate validation and certificate revocation methods with
additional round-trips into account.
DHHMAC does not depend on PKI nor do implementations require PKI
standards and thus is believed to be much simpler than the more
complex PKI facilities.
DHHMAC is particularly attractive in those environments where
provisioning of a pre-shared key has already been accomplished.
* NAT/Firewall-friendliness:
DHHMAC is able to operate smoothly through firewall/NAT devices as
long as the protected identity information of the end entity is not
an IP /transport address. Of course, DHHMAC does not necessarily
require a firewall/NAT to operate.
* Scalability:
Like the MIKEY signed Diffie-Hellman protocol, DHHMAC does not
scale to any larger configurations beyond peer-to-peer groups.
5.4. Assumptions
This document states a couple of assumptions upon which the security
of DHHMAC significantly depends. It is assumed, that
* the parameters xi, xr, s and auth_key are to be kept secret.
* the pre-shared key s has sufficient entropy and cannot be
effectively guessed.
* the pseudo-random function (PRF) is secure, yields indeed the
pseudo-random property and maintains the entropy.
* a sufficiently large and secure Diffie-Hellman group is applied.
* the Diffie-Hellman assumption holds saying basically that even with
knowledge of the exchanged Diffie-Hellman half-keys and knowledge
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
called the discrete logarithm assumption. Please see [7], [11] or
[12] for more background information regarding the Diffie-Hellman
problem and its computational complexity assumptions.
Euchner Expires =96 December 2004 [Page 22]
HMAC-authenticated Diffie-Hellman for MIKEY May 2004
* the hash function (SHA1) is secure; i.e. that it is computationally
infeasible to find a message which corresponds to a given message
digest, or to find two different messages that produce the same
message digest.
* the HMAC algorithm is secure and does not leak the auth_key. In
particular, the security depends on the message authentication
property of the compression function of the hash function H when
applied to single blocks (see [6]).
* A source capable of producing sufficiently many bits of (pseudo)
randomness is available.
* 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
Although these detailed assumptions are non-negligible, security
experts generally believe that all these assumptions are reasonable
and that the assumptions made can be fulfilled in practice with
little or no expenses.
The mathematical and cryptographic assumptions upon the properties of
the PRF, the Diffie-Hellman algorithm (discrete log-assumption), the
HMAC and SHA1 algorithms have not been proved yet nor have they been
disproved by the time of this writing.
Thus, a certain residual risk remains, which might threaten the
overall security at some unforeseeable time in the future.
The DHHMAC would be compromised as soon as
* the discrete logarithm problem could be solved efficiently,
* the hash function could be subverted (efficient collisions become
feasible),
* the HMAC method be broken (leaking the auth_key),
Euchner Expires =96 December 2004 [Page 23]
HMAC-authenticated Diffie-Hellman for MIKEY May 2004
* systematic brute force attacks are effective by which an attacker
attempts to discover the shared secret. It is assumed that the
shared secret yields sufficient entropy to make such attacks
infeasible,
* or some other yet unknown attacking technique will be discovered.
The Diffie-Hellman mechanism is a generic security technique that is
not only applicable to groups of prime order or of characteristic
two. This is because of the fundamental mathematical assumption that
the discrete logarithm problem is also a very hard one in general
groups. This enables Diffie-Hellman to be deployed also for GF(p)*,
for sub-groups of sufficient size and for groups upon elliptic
curves. RSA does not allow such generalization, as the core
mathematical problem is a different one (large integer
factorization).
RSA asymmetric keys tend to become increasingly lengthy (1536 bits
and more) and thus very computational intensive. Neverthess,
elliptic curve Diffie-Hellman (ECDH) allows to cut-down key lengths
substantially (say 170 bits or more) while maintaining at least the
security level and providing even significant performance benefits in
practice. Moreover, it is believed that elliptic curve techniques
provide much better protection against side channel attacks due to
the inherent redundancy in the projective coordinates. For all these
reasons, one may view elliptic-curve-based Diffie-Hellman as being
more "future-proof" and robust against potential threats than RSA.
Note, that an elliptic-curve Diffie-Hellman variant of MIKEY remains
for further study.
It is not recommended to deploy DHHMAC for any other usage than
depicted in section 2. Otherwise any such misapplication might lead
to unknown, undefined properties.
5.6. Authorization and Trust Model
Basically, similar remarks on authorization as stated in [3] section
4.3.2. hold also for DHHMAC. However, as noted before, this key
management protocol does not serve full groups.
One may view the pre-established shared secret to yield some pre-
established trust relationship between the initiator and the
Euchner Expires =96 December 2004 [Page 24]
HMAC-authenticated Diffie-Hellman for MIKEY May 2004
responder. This results in a much simpler trust model for DHHMAC
than would be the case for some generic group key management protocol
and potential group entities without any pre-defined trust
relationship. The common group controller in conjunction with the
assumption of a shared key simplifies the communication setup of the
entities.
One may view the pre-established trust relationship through the pre-
shared secret as some means for pre-granted, implied authorization.
This document does not define any particular authorization means but
leaves this subject to the application.
IANA considerations
This document does not define its own new name spaces for DHHMAC,
rather additional values for DHHMAC are defined as part of the MIKEY
fields. Thus, close alignment between DHHMAC values and MIKEY
values
shall be maintained; see also [3] section 10.
Intellectual Property Rights
This proposal is in full conformity with [RFC-2026].
The author is aware of related intellectual property rights
currently being held by Infineon. Pursuant to the provisions of
[RFC-2026], the author represents that he has disclosed the
existence of any proprietary or intellectual property rights in
the
contribution that are reasonably and personally known to the
author. The author does not represent that he personally knows of
all potentially pertinent proprietary and intellectual property
rights owned or claimed by the organizations he represents or
third
parties.
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described
in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on
the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made
Euchner Expires =96 December 2004 [Page 25]
HMAC-authenticated Diffie-Hellman for MIKEY May 2004
to obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification
can be obtained from the IETF Secretariat.
References
Normative References
[1] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman;
"MIKEY: Multimedia Internet KEYing", Internet Draft <draft-ietf-
msec-mikey-08.txt>, Work in Progress (MSEC WG), IETF, December
2003.
[4] NIST, FIBS-PUB 180-1, "Secure Hash Standard", April 1995,
http://csrc.nist.gov/fips/fip180-1.ps.
[5] J. Arkko, E. Carrara et al: "Key Management Extensions for SDP
and RTSP", Internet Draft <draft-ietf-mmusic-kmgmt-ext-11.txt>,
Work in Progress (MMUSIC WG), IETF, April 2004.
[6] H. Krawczyk, M. Bellare, R. Canetti: "HMAC: Keyed-Hashing for
Message Authentication", RFC 2104, February 1997.
Informative References
[7] A.J. Menezes, P. van Oorschot, S. A. Vanstone: "Handbook of
Applied Cryptography", CRC Press 1996.
[8] E. Rescorla, B. Korver: " Guidelines for Writing RFC Text on
Security Considerations", RFC 3552, IETF, July 2003.
[9] D. Eastlake, S. Crocker: "Randomness Recommendations for
Security", RFC 1750, IETF, December 1994.
[10] S.M. Bellovin, C. Kaufman, J. I. Schiller: "Security
Mechanisms for the Internet", RFC 3631, IETF, December 2003.
Euchner Expires =96 December 2004 [Page 26]
HMAC-authenticated Diffie-Hellman for MIKEY May 2004
[11] Ueli M. Maurer, S. Wolf: "The Diffie-Hellman Protocol",
Designs, Codes, and Cryptography, Special Issue Public Key
Cryptography, Kluwer Academic Publishers, vol. 19, pp. 147-171,
2000. ftp://ftp.inf.ethz.ch/pub/crypto/publications/MauWol00c.ps
[12] Discrete Logarithms and the Diffie-Hellman Protocol;
http://www.crypto.ethz.ch/research/ntc/dldh/
[13] T. Dierks, C. Allen: "The TLS Protocol Version 1.0.", RFC 2246,
IETF, January 1999.
[14] D. Harkins, D. Carrel: "The Internet Key Exchange (IKE).", RFC
2409, IETF, November 1998.
[15] Donald E. Eastlake, Jeffrey I. Schiller, Steve Crocker:
"Randomness Requirements for Security"; <draft-eastlake-
randomness2-06.txt>; Work in Progress, IETF, April 2004.
[16] J. Schiller: "Strong Security Requirements for Internet
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>, IRTF, October 2002.
[18] T. Narten: "Guidelines for Writing an IANA Considerations
Section in RFCs", RFC 2434, IETF, October 1998.
[19] J. Reynolds: "Instructions to Request for Comments (RFC)
Authors", Work in Progress, <draft-rfc-editor-rfc2223bis-
07.txt>, IETF, August 2003.
[20] J. Rosenberg et all: "SIP: Session Initiation Protocol", RFC
3261, IETF, June 2002.
[21] Ch. Kaufman: "Internet Key Exchange (IKEv2) Protocol", Work in
Progress (IPSEC WG), <draft-ietf-ipsec-ikev2-13.txt>, IETF,
March 2004.
[22] Draft ITU-T Recommendation H.235 Annex G: "Usage of the MIKEY
Key Management Protocol for the Secure Real Time Transport
Protocol (SRTP) within H.235"; 5/2004.
Euchner Expires =96 December 2004 [Page 27]
HMAC-authenticated Diffie-Hellman for MIKEY May 2004
[23] Schaad, J., Housley R.: "Advanced Encryption Standard (AES)
Key Wrap Algorithm", RFC 3394, IETF, September 2002.
[24] Baugher, M., Weis, B., Hardjono, T., Harney, H.: "The Group
Domain of Interpretation", RFC 3547, IETF, July 2003.
[25] Harney, H., Colegrove, A., Harder, E., Meth, U., Fleischer, R.:
"Group Secure Association Key Management Protocol", <draft-ietf-
msec-gsakmp-sec-05.txt>, Internet Draft, Work in Progress (MSEC
WG).
[26] Baugher, M., Canetti, R., Dondeti, L., and Lindholm, F.: "Group
Key Management Architecture", < draft-ietf-msec-gkmarch-07.txt>,
Internet Draft, Work in Progress (MSEC WG).
[27] Baugher, McGrew, Oran, Blom, Carrara, Naslund: "The Secure
Real-
time Transport Protocol", RFC 3711, IETF, March 2004.
[28] ITU-T Recommendation H.235V3Amd1, Security and encryption for
H-
series (H.323 and other H.245-based) multimedia terminals,
(04/2004)
Acknowledgments
This document incorporates kindly review feedback by Steffen Fries
and Fredrick Lindholm and general feedback by the MSEC WG.
Conclusions
Key management for environments and applications with real-time and
performance constraints are becoming of interest. Existing key
management techniques like IPSEC-IKE [14] and IPSEC-IKEv2 [22], TLS
[13] and other schemes are not deemed adequate in addressing
sufficiently those real-time and security requirements.
MIKEY defines three key management security protocols addressing
real-time constraints. DHHMAC as described in this document defines
a fourth MIKEY variant aiming at the same target.
Euchner Expires =96 December 2004 [Page 28]
HMAC-authenticated Diffie-Hellman for MIKEY May 2004
While each of the four key management protocols has its own merits
there are also certain limitations of each approach. As such there
is no single ideal solution and none of the variants is able to
subsume the other remaining variants.
It is concluded that DHHMAC features useful security and performance
properties that none of the other three MIKEY variants is able to
provide.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
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
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.
Expiration Date
This Internet Draft expires on 30 December 2004.
Euchner Expires =96 December 2004 [Page 29]
HMAC-authenticated Diffie-Hellman for MIKEY May 2004
Revision History
Changes against draft-ietf-msec-mikey-dhhmac-05.txt:
* HMAC-SHA1-96 option removed (see section 1.2, 4.2, 5.3,). This
option does not really provide much gain; removal reduces
number
of options.
* IDr added to I_message for DoS protection of the recipient; see
section 3, 3.1, 5.3.
* References updated.
Changes against draft-ietf-msec-mikey-dhhmac-04.txt:
* Introduction section modified: PFS property of DH, requirement
for 4th MIKEY key management variant motivated.
* MIKEY-DHSIGN, MIKEY-PK and MIKEY-PS added to section 1.2
Abbreviations.
* Note on secure time synchronization added to section 2.0.
* New section 2.2 "Relation to GMKARCH" added.
* New section 2.1.1 "Usage in H.235" added: this section outlines
a use case of DHHMAC in the context of H.235.
* Trade-off between identity-protection and security & performance
added to section 5.1.
* New section 5.6 "Authorization and Trust Model" added.
* Some further informative references added.
Changes against draft-ietf-msec-mikey-dhhmac-03.txt:
* RFC 3552 available; some references updated.
Changes against draft-ietf-msec-mikey-dhhmac-02.txt:
* text allows both random and pseudo-random values.
* exponentiation ** changed to ^.
* Notation aligned with MIKEY-07.
* Clarified that the HMAC is calculated over the entire MIKEY
message excluding the MAC field.
* Section 4.2: The AES key wrap method SHALL not be applied.
* Section 1: Relationship with other, existing work mentioned.
*
Euchner Expires =96 December 2004 [Page 30]
HMAC-authenticated Diffie-Hellman for MIKEY May 2004
Changes against draft-ietf-msec-mikey-dhhmac-01.txt:
* bidding-down attacks addressed (see section 5.2).
* optional [X], [X, Y] defined and clarified (see section 1.1,
5.3).
* combination of options defined in key update procedure (see
section 3.1).
* ID payloads clarified (see section 3 and 5.2).
* relationship with MIKEY explained (roundtrip, performance).
* new section 2.1 on applicability of DHHMAC for SIP/SDP and
H.323 added.
* more text due to DH resolution incorporated in section 5.3
regarding PFS, security robustness of DH, generalization
capability of DH to general groups in particular EC and
"future-proofness".
* a few editorials and nits.
* references adjusted and cleaned-up.
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
* aligned with MIKEY-03 DH protocol, notation and with payload
formats
* clarified that truncated HMAC actually truncates the HMAC result
rather than the SHA1 intermediate value.
* improved security considerations section completely rewritten in
the spirit of [8].
* IANA consideration section added
* a few editorial improvements and corrections
* IPR clarified and IPR section changed.
Author's Addresses
Euchner Expires =96 December 2004 [Page 31]
HMAC-authenticated Diffie-Hellman for MIKEY May 2004
Martin Euchner
Email: martin_euchner@hotmail.com
Phone: +49 89 722 55790 Hofmannstr. 51
Fax: +49 89 722 62366
81359 Munich, Germany
Euchner Expires =96 December 2004 [Page 32]
