Network Working Group M. Nakhjiri
Internet-Draft Motorola
Expires: August 28, 2008 Y. Ohba
Toshiba
February 25, 2008
Derivation, delivery and management of EAP based keys for handover and
re-authentication
draft-ietf-hokey-key-mgm-03
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on August 28, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This document describes a framework and a mechanism for deliverying
usage specific root keys (USRK and DSUSRK), derived as part of an EAP
EMSK hierarchy, and delivered from a server to an intended third
party key holder. The framework description includes different
scenarios for key delivery, depending on the type of keys being
delivered. It also includes, specification of derivation of keys
Nakhjiri & Ohba Expires August 28, 2008 [Page 1]
Internet-Draft HOKEY Key Distribution Exchange February 2008
required for security protection of key requests and delivery
signaling. The mechanism description includes the definition for a
three-party key distribution exchange (KDE) protocol.
Table of Contents
1. Introduction and Problem statement . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Key Delivery Architecture . . . . . . . . . . . . . . . . . . 5
3.1. Three Party Key Distribution Exchange (KDE) . . . . . . . 7
3.2. Derivation of keys protecting the KDE . . . . . . . . . . 10
3.3. Specification of context and scope for distributed keys . 11
3.4. Automated key management for KIts and KCts . . . . . . . . 11
3.5. Key distribution exchange scenarios . . . . . . . . . . . 12
4. KDE Message Format . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Message Syntax . . . . . . . . . . . . . . . . . . . . . . 14
4.2. Message Encoding . . . . . . . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
5.1. Security Association between Server and Third Party . . . 17
5.2. Replay Protection . . . . . . . . . . . . . . . . . . . . 18
5.3. Distribution of Duplicate Kpt . . . . . . . . . . . . . . 18
6. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 18
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Normative References . . . . . . . . . . . . . . . . . . . 19
8.2. Informative references . . . . . . . . . . . . . . . . . . 20
Appendix A. KDE Transport . . . . . . . . . . . . . . . . . . . . 20
A.1. KDE Transport over UDP . . . . . . . . . . . . . . . . . . 20
A.2. KDE Transport over AAA . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 22
Nakhjiri & Ohba Expires August 28, 2008 [Page 2]
Internet-Draft HOKEY Key Distribution Exchange February 2008
1. Introduction and Problem statement
The ability of Extensible Authentication Protocol (EAP) framework
[RFC3748] in incorporating desired authentication methods and
generating master session keys (MSK and EMSK) [I-D.ietf-eap-keying]
has led to the idea of using MSK and/or EMSK for bootstrapping
further keys for a variety of security mechanisms. Especially, the
MSK has been widely used for bootstrapping the wireless link security
associations between the peer and the network attachment points.
Issues arising from the use of MSK and the current bootstrapping
methods when it comes to mobility performance and security are
described in [I-D.ietf-hokey-reauth-ps]. Thus new efforts are under
way to use EMSK instead of MSK for bootstrapping of keys for future
use cases [I-D.ietf-hokey-emsk-hierarchy], [I-D.ietf-hokey-erx]. For
instance [I-D.ietf-hokey-emsk-hierarchy] defines ways to create usage
specific root keys (USRK) for bootstrapping security of a specific
use case. [I-D.ietf-hokey-emsk-hierarchy] also defines ways to
create domain specific root keys for bootstrapping security of a set
of services within a domain.
Along with those lines, this document on the other hand provides a
specification of a mechanism for secure delivery of such EMSK child
keys from the EAP server, holding the EMSK, to the intended third
party destinations. This is to address the following concerns:
1. EAP authentication is a 2 party protocol executed between an EAP
peer and an EAP server and the EMSK is only generated and held at
these two parties [I-D.ietf-eap-keying], while USRK and DSUSRK
are also generated only by these two parties, but they typically
need to be stored and utilized at third party key holders (e.g.
AAA servers/entities) that are logically or even physically
separate from the EAP server or peer. For instance, handover
keying and re-authentication service requires distribution of
keys a variety of intermediaries. This would mean these root
keys need to be delivered to these third party key holders (KH)
in a secure manner, while considering the requirements stated in
[RFC4962]
2. EAP authentication and EMSK generation process is oblivious to
the service and authorization requests following the initial EAP
authentication. Thus at the time of EAP authentication, the EAP
parties do not have access to the input data required for
creation of the USRK or DSUSRK [I-D.ietf-hokey-emsk-hierarchy].
Such input data is typically acquired and delivered to a server
(the EAP server or DSR-KH) at a later stage. The server then
performs the derivation function, followed by a secure delivery
of the resulting keys to these third party key holders.
Nakhjiri & Ohba Expires August 28, 2008 [Page 3]
Internet-Draft HOKEY Key Distribution Exchange February 2008
One purpose of this document is to show how the required input data
for root key derivation can be delivered to the server, and how the
generated key material is delivered to the third party key holder in
a secure manner. The specification also includes derivation of key
material required for secure delivery and channel binding procedures
for these key materials to ensure that not only the keys are not
exposed to unintended parties during delivery, but also the scope and
usage context for the key is properly understood and agreed upon by
the initial parties.
Another purpose of this document is to provide exact syntax for a
three-party key distribution exchange (KDE) protocol, a protocol used
for delivering USRK and and DSUSRK from a server to a third-party.
2. Terminology
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 [RFC2119].
USRK: Usage Specific Root key. A root key generated from EMSK and
is used for a specific usage that is authorized for a peer,
following an EAP authentication. USRK is domain independent.
USR-KH: USRK holder. The USR-KH is responsible for receiving,
holding and protection of the USRK derived directly from EMSK.
DSRK: Domain Specific Root key. A root key generated from EMSK and
is used within a specific domain that EAP-authenticated peer is
authorized to receive services from or roam into. DSRK is usage
independent.
DSR-KH: DSRK holder. The DSRK holder is responsible for receiving,
holding and protection of the DSRK derived directly from EMSK.
DSUSRK: Domain Specific Usage Specific Root key. A root key
generated from DSRK and is used for a specific usage within a
specific domain that an EAP-authenticated peer is authorized to
receive services from. DSUSRK is both usage and domain dependent.
DSUSR-KH: DSRK holder. The DSUSRK holder is responsible for
receiving, holding and protection of the DSUSRK.
IK and CK: Integrity and cipher keys, used to protect the key
delivery signaling between the peer and the EAP server. These two
keys are some times referred to as key delivery keys.
Nakhjiri & Ohba Expires August 28, 2008 [Page 4]
Internet-Draft HOKEY Key Distribution Exchange February 2008
3. Key Delivery Architecture
The EAP server is only responsible for performing EAP authentication
and is not expected to be involved in any service authorization
decisions, neither is the EAP server aware of the future service
requests at the time of authentication. The authorization decisions
based on the user service profile and provisioning of services
including support for service security is expected to happen by third
parties, such as AAA servers or service servers. When EAP-based
keying is used, such servers will cache and use the USRKs, DSRKs or
DSUSRKs, generated from EMSK, as root keys for derivation of further
keys to secure the services they are providing. Thus they are
considered third party key holders (KH) with respect to the initial
two EAP parties (EAP peer and server). However, since EMSK cannot be
exported from EAP server, such third parties need to request the EAP
server to generate the relevant root key (USRK) from the EMSK and
deliver the requested key to them. The third party needs to provide
the required input data to be used along with the pseudo random
function (PRF) to the EAP server to generate the requested key. The
following types of top level key holders can be envisioned:
USRK holder (USR-KH): An entity acting as a recipient and then
holder of the usage specific root key (USRK). The USR-KH is
possibly responsible for derivation and distribution of any child
keys derived from USRK for that specific usage. It is possible
that this USR-KH server is not physically disjunct from the EAP
server but is simply considered as a separate logic to off-load
the EAP server from the need to handle usage specific services,
such as HOKEY service. However, to keep the security
specifications generic here, we assume that USR-KH and EAP server
are physically separate and specify the delivery of USRK from EAP
server to USR-KH accordingly.
DSRK holder (DSR-KH): An entity acting as a recipient and then
holder of the domain specific root key (DSRK). The DSR-KH is
responsible for derivation and distribution of any child keys
derived from DSRK for that specific domain. The most likely
realization of DSR-KH is a AAA server in the corresponding domain,
responsible for setting the policies for usage of DSRK within the
domain.
DSUSRK holder (DSUSR-KH): An entity acting as a recipient and then
holder of the domain specific and usage specific root key (DSUSRK)
delivered from the EAP server. The DSUSR-KH is possibly
responsible for derivation and distribution of any child keys
derived from DSUSRK for that specific domain and usage. The most
likely realization of DSUSR-KH is a AAA server in the
corresponding domain, responsible for the service offered within
Nakhjiri & Ohba Expires August 28, 2008 [Page 5]
Internet-Draft HOKEY Key Distribution Exchange February 2008
the domain for the specific usage at hand.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EAP server |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | \
/ | \
USRK1 / | USRK2 \ USRK3
(ABC) / | (XYZ) \(DSRK1)
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+
| USR-KH1 | | USR-KH2 | | DSR-KH1 |
| HOKEY server | | XYZ server| +-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+ |
+-+-+-+-+-+-+-+
| Domain 1 |
| DSUSR-KH |
|(home domain |
|HOKEY server)|
+-+-+-+-+-+-+-+
+-+-+-+-+-+-+
| peer |
+-+-+-+-+-+-+
Figure 1: Key delivery for various EMSK child key cateories
As one can see, depending on the type of key being delivered,
different third party key holders are involved. Each of the top
level key holders (USR-KH, DSR-KH has a interface with the EAP
server, for delivering usage specific (and/or domain specific) input
data needed for root key generation (USRK, DSRK) to the EAP server
and receiving the resulting root key from the EAP server. The
DSUSR-KH is considered a second-level key holder and has an interface
with DSR-KH.
Regardless of the type of key being delivered, the model for EAP
based key derivation and delivery interface can be generalized as a 3
party key distribution model, since EAP authentication method
signaling and the following EMSK generation is performed between the
peer and the EAP server in a manner that is almost transparent to all
intermediaries, while the EMSK is used to derive the top level root
keys and deliver those to a third party key holder, such as USR-KH or
DSR-KH.
Nakhjiri & Ohba Expires August 28, 2008 [Page 6]
Internet-Draft HOKEY Key Distribution Exchange February 2008
3.1. Three Party Key Distribution Exchange (KDE)
In the following we describe the generic mechanism for a three- party
key distribution exchange (KDE), where a key is distributed from a
network server (with parent key holder) to a third party. The
following shows a generic trust model for the key distribution
mechanism to the third party. The peer (P) and a parent key holder,
called "server" (S) in this model share a parent key (Kps) and a set
of security associations (SA1) for integrity and privacy protection
of signaling between the peer and the server (KIps and KCps). The
goal of the keying solution is to use the parent key (Kps) and
generate a child key (Kpt) to be shared between the peer and the
third party intermediary (T). The peer is able to generate Kpt, but
Kpt needs to be distributed to a third party intermediary (T). The
goal of this section is to provide a the general description of the
KDE (key distribution exchange) for distribution of Kpt from S to T.
We also assume that the server (S) and the third party (T) share a
similar set security association, SA2 (KIts, KCts).
+-+-+-+-+ +-+-+-+-+-+-+-+
| | shared SA1 | |
| |------------------------------| server |
| Peer | | KH |
+-+-+-+-+ +-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+ V
| 3 rd party| | SA2 (Kpt)
| KH | ----------|
+-+-+-+-+-+-+
Figure 2: Distribution of a child key from a parent key key holder to
a 3rd party child key key holder
The key distribution exchange described here meets the requirements
for such 3-party lay-out, providing channel binding and avoids the
lying intermediary scenario. The exchange proposed below is to
perform a channel binding and avoid the lying intermediary scenario.
The description below can be carried over a generic transport and
thus is independent of the exact type of protocol that is used.
The key distribution to a third-party basically consists of 1
exchange, i.e. 2 messages between the peer and the server. However,
in most scenarios each message traverses through the intermediary,
i.e. Over two logical hops (peer-third party) and (third party-
server) even though the exchange seems to consist of 4 logical
messages. It should be noted that the information in message 0 is
typically conveyed as an advertisement through other means and hence
message 0 is optional.
Nakhjiri & Ohba Expires August 28, 2008 [Page 7]
Internet-Draft HOKEY Key Distribution Exchange February 2008
peer Third party server
----- -------- -------
| KDE0*(TID, SID, DID*, KT) | |
|<----------------------------| |
| KDE1 (PRT) | KDE2 (TRT) |
|---------------------------->|------------------->|
| KDE4 (SAT) | KDE3 (TOK) |
|<----------------------------|<-------------------|
(*) optional
Figure 3: Handover using EAP-HR
KDE message 0 (optional): Third party sends its own identifier
(TID), the Server ID (SID), the Domain ID (DID) and the KT (Key
Type) to peer. These identifiers need to be recognizable by the
server S and when AAA signaling is used may be carried as AAA
attributes. KT is used for uniquely identifying the type of the
key. DID is used to create domain specific keys or to assist in
key distribution. DID is not included when the KT is other than 0
(DSRK) or 2 (DS-rRK).
KDE message 1: Peer sends a peer request token (PRT) to the third
party including the TID reported by the third party and a
freshness value. The contents of PRT are detailed below.
KDE message 2: Third party uses the PRT and creates a third party
request token (TRT) and sends it to the server. The contents of
TRT are detailed below.
KDE message 3: Server sends the Kpt to third party wrapped inside a
token called Key Token (TOK). The TOK carries a Server
Authorization Token (SAT) destined for the peer, carrying
assurance for the peer that the server has sent the key Kpt to the
properly identified third party (identified by TID).
KDE message 4: The third party extracts the SAT from the server and
forwards it to the peer. The successful receipt of message 4 by
peer means that the third party has successfully verified
integrity of message 3 and decrypted Kpt.
{X}K: X encrypted with key K
Int[K, X]: X || MIC (K, X), where MIC Message Integrity Code over X
with key K.
Nakhjiri & Ohba Expires August 28, 2008 [Page 8]
Internet-Draft HOKEY Key Distribution Exchange February 2008
PRT : Int[KIps, (SEQps, PID, TID, SID, DID*, KT, KN_KIps)]
PRT (Peer Request Token) carries a sequence number (SEQps), the
identities of the peer (PID), the server (SID), the third party
(TID) and the domain (DID), the KT (Key Type) and the name of KIps
along with the signature. The signature is called the peer
request authenticator (PRA). KIps is a symmetric key shared
between peer and Server for signing and identified by KN_KIps.
SEQps is a sequence number generated by the peer and maintained
between the peer and server. The initial sequence number starts
from one (1). When the sequence number wraps up, then SA1 MUST be
deleted and any KDE message MUST NOT be generated or processed
thereafter. DID is not included when KT is other than 0 (DSRK) or
or 2 (DS-rRK).
TRT : Int[KIts, (Nt, PID, TID, PRT)]
TRT (Third party Request Token) carries the token from the peer
along with the third party and peer IDs and a signature for
integrity protection. KIts is the shared key used for signing
purposes. Nt is a nonce generated by the third party. Providing
third party identifier both explicitly by the third party and both
implicitly through PRT allows the server to detect a lying third
party.
TOK : Int[KIts, (Nt+1, PID, TID, SID, DID*, KT, {Kpt, KN_Kpt,
KL_Kpt}KCts, SAT)]
TOK(Key Token) carries the key to be distributed to the third
party (Kpt) wrapped with an encryption key (KCts). KL_Kx is the
key lifetime for key Kx.
SAT : Int[KIps,(SEQps+1, PID, TID, SID, DID*, KN_Kpt, KL_Kpt,
KN_KIps)]
SAT (Server Authorization Token) carries assurance (in form of
signature on the incremented nonce value) for the peer that the
server has sent the key Kpt to the properly identified third party
(identified by TID). DID is not included when KT is other than 0
(DSRK) or 2 (DS-rRK).
The exchange proposed above can avoid the lying intermediary
scenario, as follows: if an intermediary decided to announce two
different identifiers to the peer versus to the server, e.g. a down
link ID to the peer (DTID) and a different uplink ID to the server
(UTID). The peer uses DTID in its token towards the server, while
the intermediary uses its UTID in its token to the server. Server
must use the UTID from PRT to calculate the MIC in TRT and if there
Nakhjiri & Ohba Expires August 28, 2008 [Page 9]
Internet-Draft HOKEY Key Distribution Exchange February 2008
is a match, then the server can verify that DTID and UTID are the
same as the TID and proceed with generating and provisioning of Kpt,
otherwise the server MUST return a failure code instead of generating
an Kpt.
3.2. Derivation of keys protecting the KDE
As shown in the generic description of the key distribution exchange,
to protect the exchange, at least one (or two) keys are required to
protect the exchange. These keys are an integrity and a cipher key.
These keys are generated from the EMSK hierarchy themselves.
However, as discussed when enumerating the various KDE use case
scenarios, the KDE can and need to be used in many different
scenarios for delivering keys. Depending on the key that is being
delivered, the integrity and cipher keys can be generated at
different levels of the key hierarchy as well. For instance to
protect the KDE performed to deliver a USRK, these two keys are
generated directly from EMSK.
KDRK
|
+----+---+
| |
CK IK
Figure 4: Key delivery keys as EMSK Child keys
Cipher key (CK) and Integrity Key (IK) are used to protect KDE for
delivery of USRKs and DSUSRKs. CK and IK are generated from KDRK
(Key Distribution Root Key) which is either EMSK or DSRK in the use
cases described in this document. When KDRK is EMSK, CK and IK are
defined as USRKs. When KDRK is DSRK, CK and IK are defined as
DSUSRKs. The lengthes of CK and IK depends on actual integrity and
encryption algorithms in use.
If KDRK is the EMSK, then CK and IK are defined using the USRK
derivation algorithm defined in [I-D.ietf-hokey-emsk-hierarchy] as
follows:
IK = USRK(usage="kde-integrity-key@ietf.org", length)
CK = USRK(usage="kde-cipher-key@ietf.org", length)
USRK(usage, length) is the USRK key derivation function with the
usage and key length specified in the first and second parameters,
respectively.
If KDRK is the DSRK for domain="example.net", then CK and IK are
Nakhjiri & Ohba Expires August 28, 2008 [Page 10]
Internet-Draft HOKEY Key Distribution Exchange February 2008
defined using the DSUSRK derivation algorithm defined in
[I-D.ietf-hokey-emsk-hierarchy] as follows:
IK = DSUSRK(usage="kde-integrity-key@ietf.org", domain, length)
CK = DSUSRK(usage="kde-cipher-key@ietf.org", domain, length)
DSUSRK(usage, domain, length) is the DSUSRK key derivation function
with the usage, domain and key length specified in the first, second
and third parameters, respectively.
If KDRK is other than the EMSK or DSRK, then CK and IK are defined
using the KDF defined in [I-D.ietf-hokey-emsk-hierarchy] as follows:
IK = KDF(KDRK, "kde-integrity-key@ietf.org" + length)
CK = KDF(KDRK, "kde-cipher-key@ietf.org" + length)
In this case, the IK and CK names are defined as SHA-1-64(KDRK-name +
"kde-integrity-key@ietf.org") and SHA-1-64(KDRK-name +
"kde-cipher@ietf.org"), respectively, where SHA-1-64 is the first 64-
octet of SHA-1.
3.3. Specification of context and scope for distributed keys
The key lifetime of each distributed key MUST NOT be greater than
that of its parent key.
The key context of each distributed key is determined by the sequence
of KTs in the key hierarchy. When a DSRK is being delivered and the
DSRK applies to only a specific set of services, the service types
may need to be carried as part of context for the key. Carrying such
a specific set of services are outside the scope of this document.
The key scope of each distributed key is determined by the sequence
of (PID, SID, TID, DID, KT)-tuples in the key hierarchy.
3.4. Automated key management for KIts and KCts
KIts and KCts require automated key management [RFC4107] since these
are long-term session keys used by more than two parties. Kerberos
[RFC4120] MAY be used as an automated key management protocol for
distributing KIts and KCts. If there is no direct trust relationship
between the third-party and the server, then inter-realm Kerberos MAY
be used to create a direct trust relationship between the third-party
and the server from a chain of trust relationships.
Note that the automated key management mechanism described above is
Nakhjiri & Ohba Expires August 28, 2008 [Page 11]
Internet-Draft HOKEY Key Distribution Exchange February 2008
not required if hop-by-hop security is used for protecting KDE
messages. See Section 5 for more discussion.
3.5. Key distribution exchange scenarios
As mentioned earlier, EMSK can be used to generate any of the USRKs,
DSRKs and DSUSRKs. The following scenarios can be envisioned for
distribution of a key to a 3rd party. All scenarios assume the peer
and the EAP server have mutually authenticated to each other using an
EAP method and have generated an EMSK. Since the EAP server
performing EAP method authentication and EMSK generation resides in
peer's home domain, for practical purposes, for the mechanisms
described in this document, the USR-KH MUST reside in this domain.
Note that other key distribution scenarios may also be possible since
the key distribution protocol is designed to be generic.
Scenario 1: EAP server to USR-KH: In this scenario, an EAP server
delivers a USRK to a USR-KH. The trigger and mechanism for key
delivery may involve a specific request from the peer and another
intermediary (such as authenticator). In the case of HOKEY re-
authentication service, a DSRK or an rRK is distributed.
Scenario 2: DSR-KH to DSUSR-KH: In this scenario, a DSR-KH in a
specific domain delivers keying material to the DSUSR-KH in the
same domain. In the case of HOKEY re-authentication service, a
DS-rRK is distributed.
The mapping between the protocol parameters in each scenario to the
protocol parameters of the KDE protocol defined in Section 3.1 is
given below, where IK_X and CK_X are IK and CK derived from key X,
respectively. The keyName-NAI is defined in [I-D.ietf-hokey-erx].
Nakhjiri & Ohba Expires August 28, 2008 [Page 12]
Internet-Draft HOKEY Key Distribution Exchange February 2008
+------------+-------------+-------------+
| KDE Param. | Scenario 1 | Scenario 2 |
+------------+-------------+-------------+
| PID | keyName-NAI |
+------------+-------------+-------------+
| SID |EAP Server ID| DSR-KH ID |
+------------+-------------+-------------+
| TID | USR-KH ID | DSUSR-KH ID |
+------------+-------------+-------------+
| Kpt | USRK | DSUSRK |
+------------+-------------+-------------+
| KIps | IK_EMSK | IK_DSRK |
+------------+-------------+-------------+
| KCps | CK_EMSK | CK_DSRK |
+------------+-------------+-------------+
| KIts | Any pre-existing key |
+------------+---------------------------+
| KCts | Any pre-existing key |
+------------+---------------------------+
The key distribution exchanges for some of the above scenarios can be
recursively combined into a single 1.5-roundtrip exchange. For
example, a combined key distribution exchange for Scenarios 1 and 2
is illustrated in Figure 5 where KDE[1-4] and KDE'[1-4] are messages
for Scenarios 1 and 2, respectively.
peer DSUSR-KH DSR-KH EAP Server
----- -------- ------- -----
| KDE1 | KDE1 | KDE2 |
| KDE1' | KDE2' | |
|------------------>|---------------->|--------------->|
| KDE4 | KDE4 | KDE3 |
| KDE4' | KDE3' | |
|<------------------|<--------------- |<---------------|
| | | |
Figure 5: Combined Message Exchange
4. KDE Message Format
The format of KDE messages is defined here in terms of Abstract
Syntax Notation One (ASN.1) [X680], which provides a syntax for
specifying both the abstract layout of protocol messages as well as
their encodings.
Nakhjiri & Ohba Expires August 28, 2008 [Page 13]
Internet-Draft HOKEY Key Distribution Exchange February 2008
4.1. Message Syntax
The syntax of KDE messages is defined here in terms of Abstract
Syntax Notation One (ASN.1) [X680], which provides a syntax for
specifying both the abstract layout of protocol messages as well as
their encodings.
-- OID for KDE
HokeyKdeV1 {
iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) hokey(to be assigned by IANA)
kde-v1(1)
} DEFINITIONS AUTOMATIC TAGS ::= BEGIN
-- OID arc for HOKEY KDE
--
-- This OID may be used to identify HOKEY KDE messages
-- encapsulated in other protocols.
--
-- This OID also designates the OID arc for HOKEY KDE-related OIDs.
--
id-hokey-kde-v1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) hokey(to be assigned by IANA)
kde-v1(1)
}
UInt32 ::= INTEGER (0..4294967295)
-- unsigned 32 bit values
KDE-PDU ::= SEQUENCE {
version INTEGER (1..255)
-- Version of KDE protocol (=1 in this document)
payload KDE-Payload
-- Payload of KDE message
}
-- A payload contains one or more KDE messages.
-- The payload contains one or more KDE messages. Two or more KDE
-- messsage are allowed to support combined exchange.
KDE-Payload ::= SEQUENCE OF {
CHOICE {
kde0 KDE0 -- KDE0
kde1 KDE1, -- KDE1
kde2 KDE2, -- KDE2
kde3 KDE3, -- KDE3
kde4 KDE4 -- KDE4
Nakhjiri & Ohba Expires August 28, 2008 [Page 14]
Internet-Draft HOKEY Key Distribution Exchange February 2008
}
}
KDE0 ::= SEQUENCE {
tid OCTET STRING, -- Third-party ID
sid OCTET STRING, -- Server ID
did OCTET STRING OPTIONAL, -- Domain ID
keytype INTEGER(0..255)
-- Key Type of Kpt (IANA assigned value)
}
KDE1 ::= SEQUENCE {
prt PRT -- Peer Request Token
}
KDE2 ::= SEQUENCE {
trt TRT -- Third Party Request Token
}
KDE3 ::= SEQUENCE {
tot TOT -- Key Token
}
KDE4 ::= SEQUENCE {
tot SAT -- Server Authorization Token
}
-- PRT (Peer Request Token)
PRT ::= SEQUENCE {
seq Uint32, -- Sequence Number (intial value is 1)
pid OCTET STRING, -- Peer ID
tid OCTET STRING, -- Third-party ID
sid OCTET STRING, -- Server ID
did OCTET STRING OPTIONAL,
-- Domain ID
keytype INTEGER(0..255)
-- Key Type of Kpt (IANA assigned value)
kips-name OCTET STRING, -- Key name of KIps
integrity-data IntegrityData
-- Integrity protection with KIps
}
-- TRT (Third party Request Token)
TRT ::= SEQUENCE {
tnonce Uint32 -- Third-party Nonce
pid OCTET STRING, -- Peer ID
tid OCTET STRING, -- Third-party ID
prt PRT
Nakhjiri & Ohba Expires August 28, 2008 [Page 15]
Internet-Draft HOKEY Key Distribution Exchange February 2008
}
-- TOK (Key Token)
TOK ::= SEQUENCE {
tnonce Uint32 -- Third-party Nonce+1
pid OCTET STRING, -- Peer ID
tid OCTET STRING, -- Third-party ID
sid OCTET STRING, -- Server ID
did OCTET STRING OPTIONAL,
-- Domain ID
keytype INTEGER(0..255)
-- Key Type of Kpt (IANA assigned value)
enc-kpt EnctyptedData
-- Kpt and its name and lifetime encrypted with KCts
sat SAT,
integrity-data IntegrityData
-- Integrity protection with KIts
}
-- SAT (Server Authorization Token)
SAT ::= SEQUENCE {
seq Uint32, -- Sequence Number + 1
pid OCTET STRING, -- Peer ID
tid OCTET STRING, -- Third-party ID
sid OCTET STRING, -- Server ID
did OCTET STRING OPTIONAL,
-- Domain ID
kpt-name OCTET STRING, -- Key name of Kpt
kpt-lifetime Uint32 -- Lifetime of Kpt in seconds
kps-name OCTET STRING, -- Key name of Kps
integrity-data IntegrityData
-- Integrity protection with KIps
}
-- Integrity Data
IntegrityData ::= SEQUENCE {
integrity-algorithm IntegirityAlgorithm, -- integrity algorithm
mac OCTET_STRING -- message authentication code
}
-- Encrypted Data
EncryptedData ::= SEQUENCE {
encryption-algorithm EncryptionAlgorithm, -- encryption algorithm
cipher OCTET_STRING -- encrypted data
}
-- Encryption algorithm. The data contains an IKEv2 Transform ID of
-- Transform Type 1 [RFC4306] for the encryption algorithm. All KDE
Nakhjiri & Ohba Expires August 28, 2008 [Page 16]
Internet-Draft HOKEY Key Distribution Exchange February 2008
-- implementations MUST support ENCR_AES_CBC [RFC3602]. It is allowed
-- to use null encryption (ENCR_NULL) for KDE2 and KDE3 in the case
-- where hop-by-hop security between third party and server is
-- acceptable.
EncryptionAlgorithm ::= UInt32
-- Integrith algorithm. The data contains an IKEv2 Transform ID of
-- Transform Type 3 [RFC4306] for the integrity algorithm. All KDE
-- implementations MUST support AUTH_HMAC_SHA1_160 (7) [RFC4595].
-- It is allowed to use a null integrity mechanism (NONE) for
-- for KDE2 and KDE3 in the case where hop-by-hop security between
-- third party and server is acceptable.
IntegrityAlgorithm ::= UInt32
END
4.2. Message Encoding
The default encoding of KDE protocol messages shall obey the PER
(Packed Encoding Rules) of ASN.1 as described in [X691]. A KDE
transport protocol may specify other ASN.1 encoding method.
5. Security Considerations
5.1. Security Association between Server and Third Party
The key distribution mechanism described in this document is designed
to work with both end-to-end and hop-by-hop security association
between a server and a third party.
When end-to-end security is used, the key distribution mechanism
assumes existence of a direct trust relationship between the server
and the third party key holder. When such a direct trust
relationship may be dynamically created from a chain of transitive
trust relationships with the use of inter-realm Kerberos to
distribute KIts and KCts as described in Section 3.4. Therefore, the
key distribution method described in this document eliminates the
need for hop-by-hop security associations along the transitive trust
relationship.
When hop-by-hop security is used, no integrity protection and
encryption is provided within the KDE protocol. A null encryption
algorithm (ENCR_NULL) and a null integrity protection (NONE) are
specified in KDE. In this case, underlying transport protocol
security such as IPsec and (D)TLS MUST be used instead. The use of
Nakhjiri & Ohba Expires August 28, 2008 [Page 17]
Internet-Draft HOKEY Key Distribution Exchange February 2008
hop-by-hop security implies that an intermediary on each hop can
access the distributed key material. Hence the use of hop-by-hop
security SHOULD be limited to an environment where an intermediary is
trusted not to use the distributed key material.
5.2. Replay Protection
The KDE protocol defines two freshness values to provide replay
protection. Sequence numbers generated by peer and maintained by
peer and server provide anti-replay for KDE messages 1, 2 and 4.
Nonces generated by third-party provide anti-replay for KDE message
3.
5.3. Distribution of Duplicate Kpt
If a Kpt is a USRK or a DSUSRK, it should be sufficient that
distribution of the Kpt happens only once during the lifetime of it's
root key, i.e., EMSK. Nevertheless, a peer may attempt to execute
the KDE protocol multiple times via the same third party with
specifying the same parameters in KDE message 1 except for sequence
number, for some reason such as loss of key state due to temporal
disconnection from the network. The server may accept such an
attempt and distribute a copy of the same Kpt back to the third
party, given that the lifetime of the Kpt (KL_Kpt) is recomputed such
that the key expiration time of the Kpt will not change for all
copies of the same Kpt.
6. IANA consideration
This document defines a new SMI Security for Mechanism Code for
hokey(to be assigned by IANA).
This document defines a new SMI Security for Mechanism hokey Code for
kde-v1(1).
This document defines new usage labels, such as those used in
generation of CK and IK. The corresponding labels, i.e.,
"kde-cipher-key@ietf.org" for CK and "kde-integrity-key@ietf.org" for
IK, need to be assigned numerical values by IANA.
The Key Type namespace is used to identify the type of Kpt. The range
of values 0 - 65,535 are for permanent, standard message types,
allocated by IETF Consensus [IANA]. This document defines the values
0 (DSRK), 1 (rRK) and 2 (DS-rRK).
Nakhjiri & Ohba Expires August 28, 2008 [Page 18]
Internet-Draft HOKEY Key Distribution Exchange February 2008
7. Acknowledgements
The author would like to thank Dan Harkins, Chunqiang Li, Rafael
Marin Lopez and Charles Clancy for their valuable contributions to
the formation of the KDE.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[I-D.ietf-hokey-emsk-hierarchy]
Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri,
"Specification for the Derivation of Root Keys from an
Extended Master Session Key (EMSK)",
draft-ietf-hokey-emsk-hierarchy-04 (work in progress),
February 2008.
[I-D.ietf-hokey-erx]
Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re-
authentication Protocol (ERP)", draft-ietf-hokey-erx-12
(work in progress), February 2008.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
Dial In User Service) Support For Extensible
Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application", RFC 4072,
August 2005.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120,
July 2005.
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication,
Authorization, and Accounting (AAA) Key Management",
BCP 132, RFC 4962, July 2007.
[X680] "Abstract Syntax Notation One (ASN.1): Specification of
Basic Notation, ITU-T Recommendation X.680 (2002).",
Nakhjiri & Ohba Expires August 28, 2008 [Page 19]
Internet-Draft HOKEY Key Distribution Exchange February 2008
July 2002.
[X691] "Abstract Syntax Notation One (ASN.1): ASN.1 encoding
rules: Specification of Packed Encoding Rules (PER), ITU-T
Recommendation X.691 (2002).", July 2002.
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
8.2. Informative references
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
Key Management", BCP 107, RFC 4107, June 2005.
[I-D.ietf-eap-keying]
Aboba, B., Simon, D., and P. Eronen, "Extensible
Authentication Protocol (EAP) Key Management Framework",
draft-ietf-eap-keying-22 (work in progress),
November 2007.
[I-D.ietf-hokey-reauth-ps]
Clancy, C., Nakhjiri, M., Narayanan, V., and L. Dondeti,
"Handover Key Management and Re-authentication Problem
Statement", draft-ietf-hokey-reauth-ps-09 (work in
progress), February 2008.
Appendix A. KDE Transport
A.1. KDE Transport over UDP
This section defines UDP transport of KDE. A well-known port number
(to be assigned by IANA) is assigned for KDE.
For any KDE-PDU sent in response to another KDE-PDU received from the
other peer, the source port is set to the well-known port number (to
be assigned by IANA) assigned for KDE and the destination port is
copied from the source port of the received KDE-PDU. For other KDE-
PDUs, both the source and destination port numbers are set to the
well-known port number (to be assigned by IANA) assigned for KDE.
A.2. KDE Transport over AAA
When KDE messages are carried in AAA protocols, they are carried in a
RADIUS attribute or a corresponding Diameter AVP. The RADIUS
attribute for KDE is defined as follows:
Nakhjiri & Ohba Expires August 28, 2008 [Page 20]
Internet-Draft HOKEY Key Distribution Exchange February 2008
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | KDE-PDU ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: RADIUS Attribute for KDE
Type
IANA-TBD for KDE
Length
>=4
KDE-PDU
One KDE-PDU is included.
Authors' Addresses
Madjid Nakhjiri
Motorola
Email: madjid.nakhjiri@motorola.com
Yoshihiro Ohba
Toshiba
Email: yohba@tari.toshiba.com
Nakhjiri & Ohba Expires August 28, 2008 [Page 21]
Internet-Draft HOKEY Key Distribution Exchange February 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Nakhjiri & Ohba Expires August 28, 2008 [Page 22]
