with the indicated authentication algorithm. When used in
conjunction with DHHMAC, KEMAC 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 [16]) 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 [2]
section 5.2, and then stored within the MAC field.
MAC alg | Value | Comments
------------------------------------------------------------------
HMAC-SHA-1 | 0 | Mandatory, Default (see [3])
NULL | 1 | Very restricted use; see
| [2] section 4.2.4
Table 4.2.a
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.
4.4. General Extension Payload
For DHHMAC, to avoid bidding-down attacks, this payload SHALL list
all key management protocol identifiers of a surrounding
encapsulation protocol, such as SDP [4]. The General Extension
Payload SHALL be integrity protected with the HMAC using the shared
secret.
Type | Value | Comments
SDP IDs | 1 | List of SDP key management IDs (allocated for
use in [4]); see also [2] section 6.15.
Table 4.4.a
5. Security Considerations
This document addresses key management security issues throughout.
For a comprehensive explanation of MIKEY security considerations,
please refer to MIKEY [2] section 9.
In addition, this document addresses security issues according to
[7], where the following security considerations apply in particular
to this document:
5.1. Security Environment
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 also of interest that are not explicitly defined
by the DHHMAC protocol, but that should be provided locally in
practice.
The system that runs the DHHMAC protocol entity SHALL provide the
capability to generate (pseudo) random numbers as input to the
Diffie-Hellman operation (see [8]). Furthermore, 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, to which this document adheres, covers the issues
of end-to-end security in the Internet generally, without ruling out
the possibility that MIKEY DHHMAC can be deployed in a corporate,
closed IP environment. This also includes the possibility that MIKEY
DHHMAC can 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: 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. Instead, by
using the Diffie-Hellman "encryption" operation, which 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. Furthermore, the DHHMAC carries other data
such as timestamps, (pseudo) random values, identification
information or security policy parameters; eavesdropping of any
such data is not considered 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.
Although any such attacks cannot be avoided, they must at least be
detected. DHHMAC addresses this threat by providing message
integrity.
* Bidding-down attacks: When multiple key management protocols, each
of a distinct security level, are offered (such as those made
possible by SDP [4]), avoiding bidding-down attacks is of concern.
DHHMAC addresses this threat by reusing the MIKEY General Extension
Payload mechanism, where all key management protocol identifiers
are to be listed within the MIKEY General Extension Payload.
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
are infeasible, although the possibility of a successful attack
cannot be ruled out.
* Non-repudiation of the receipt or of the origin of the message:
These are not requirements within the context of DHHMAC in 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
is 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 [2]. 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 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.
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 to supply trustworthy identity
information; e.g., by relying on secured links underneath MIKEY
that supply trustworthy identity information some other way.
However, it is understood that without identity information, 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 are provided.
Leaving identity fields optional (if doing so is 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 document 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.
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
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
countermeasures against man-in-the-middle attacks.
The initiator may deploy a local timer that fires when the awaited
response message did not arrive in a timely manner. This is
intended to detect deletion of entire messages.
* Replay protection of the messages is achieved using embedded
timestamps: In order to detect replayed messages, it is essential
that the clocks among initiator and sender be roughly synchronized.
The reader is referred to [2] section 5.4, and [2] section 9.3,
which provide further considerations and give guidance on clock
synchronization and timestamp usage. Should the clock
synchronization be lost, end systems cannot detect replayed
messages anymore, and the end systems cannot securely establish
keying material. This may result in a denial-of-service; see [2]
section 9.5.
* 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’s identity payload in the I_message. This allows the
recipient to filter out those (replayed) I_messages that are not
targeted for him and to avoid 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 is, even if the long-term pre-shared key is
compromised at some point in time, this does not compromise past or
future session keys.
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 and digitally signed DH provide a far superior
security level to that of 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, in which
the initiator distributes a key to its peers. Actually, both
parties involved in the protocol exchange are able to contribute to
the common Diffie-Hellman TEK traffic generating key equally. 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 increases security robustness
over that of the case where all the security depends just on the
proper implementation of a single entity.
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, such as IPsec-IKE [12], IPsec-IKEv2 [14], TLS [11], and
other schemes, are not deemed adequate in addressing those real-
time and security requirements sufficiently; 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 and MIKEY public-key
protocol are both able to complete their task even in a half-
roundtrip 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 roundtrip delay,
either party may pre-compute its public Diffie-Hellman half-key
off-line.
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, which
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 additional steps are taken for
certificate validation and certificate revocation methods with
additional roundtrips into account.
DHHMAC does not depend on PKI, nor do implementations require PKI
standards. Thus, it 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-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.
* 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. The following conditions are
assumed:
* 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 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 [6], [9], or
[10] for more background information regarding the Diffie-Hellman
problem and its computational complexity assumptions.
* The hash function (SHA1) is secure; i.e., it is computationally
infeasible to find a message that 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 it
is applied to single blocks (see [5]).
* A source capable of producing sufficiently many bits of (pseudo)
randomness is available.
* The system upon which DHHMAC runs is sufficiently secure.
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 of the properties of
the PRF, the Diffie-Hellman algorithm (discrete log-assumption), the
HMAC algorithm, and the SHA1 algorithms have been neither proven nor
disproven at this time.
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 any of the listed
assumptions no longer hold.
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 computationally intensive. Nevertheless,
Elliptic Curve Diffie-Hellman (ECDH) allows key lengths to be cut
down substantially (say 170 bits or more) while maintaining at least
the security level and providing even more significant performance
benefits in practice. Moreover, it is believed that elliptic-curve
techniques provide much better protection against side channel
attacks due to the inherent redundancy in the projective coordinates.
For all these reasons, one may view elliptic-curve-based Diffie-
Hellman as being more "future-proof" and robust against potential
threats than RSA is. Note that Elliptic Curve Diffie-Hellman
variants of MIKEY are defined in [31].
HMAC-SHA1 is a key security mechanism within DHHMAC on which the
overall security of MIKEY DHHMAC depends. MIKEY DHHMAC uses HMAC-
SHA1 in combination with the classic Diffie-Hellman key agreement
scheme. HMAC-SHA1 is a keyed one-way hash function that involves a
secret in its computation. DHHMAC applies HMAC-SHA1 for protection
of the MIKEY payload. Likewise, the pseudo-random function PRF
within MIKEY [2] uses the HMAC-SHA1 mechanism as a key derivation
function. While certain attacks have been reported against SHA1 and
MD5 (see [29]), with current knowledge (see [29], [30]), no attacks
have been reported against the HMAC-SHA1 security mechanism. In
fact, [32] proves that HMAC possesses the property of a pseudo-random
function PRF assuming solely that the (SHA1) hash function is a
pseudo-random function. [32] also provides evidence that HMAC is
robust against collision attacks on the underlying hash function. It
is believed that MIKEY DHHMAC should be considered secure enough for
the time being. Thus, there is no need to change the underlying
security mechanism within the MIKEY DHHMAC protocol.
It is not recommended to deploy DHHMAC for any other use than that
depicted in section 2. Any misapplication might lead to unknown,
undefined properties.
5.6. Authorization and Trust Model
Basically, similar remarks on authorization as those stated in [2]
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 as yielding some pre-
established trust relationship between the initiator and the
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. In conjunction with the assumption of a shared key,
the common group controller 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.
6. Acknowledgments
This document incorporates kindly, valuable review feedback from
Steffen Fries, Hannes Tschofenig, Fredrick Lindholm, Mary Barnes, and
Russell Housley and general feedback by the MSEC WG.
7. IANA Considerations
This document does not define its own new name spaces for DHHMAC,
beyond the IANA name spaces that have been assigned for MIKEY; see
[2] sections 10 and 10.1 and IANA MIKEY payload name spaces [37].
In order to align Table 4.1.a with Table 6.1.a in [2], IANA is
requested to add the following entries to their MIKEY Payload Name
Space:
Data Type Value Reference
--------------- ----- ---------
DHHMAC init 7 RFC 4650
DHHMAC resp 8 RFC 4650
8. References
8.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August
2004.
[3] NIST, FIBS-PUB 180-2, "Secure Hash Standard", April 1995,
http://csrc.nist.gov/publications/fips/fips180-2/
fips180-2withchangenotice.pdf.