Network Working Group M. Nakhjiri, Ed.
Internet-Draft Huawei USA
Expires: December 24, 2007 Y. Ohba, Ed.
Toshiba
June 22, 2007
Derivation, delivery and management of EAP based keys for handover and
re-authentication
draft-ietf-hokey-key-mgm-00
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 December 24, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document describes a delivery framework for usage and/ or domain
specific keys, derived as part of an EAP EMSK hierarchy, and
delivered from an EAP 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 required for security
Nakhjiri & Ohba Expires December 24, 2007 [Page 1]
Internet-Draft Hokey hierarchy June 2007
protection of key requests and delivery signaling. The key delivery
framework also includes proper specification and conveyance of the
context and scope of the keys being delivered. Derivation of the
EMSK based handover root key (HRK) and domain specific handover root
keys (DSHRK) for use in the problem of handover keying and re-
authentication is also described.
Table of Contents
1. Introduction and Problem statement . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. EMSK key delivery architecture . . . . . . . . . . . . . . . . 6
4. Distribution of EAP based keys to a third party . . . . . . . 10
4.1. Overview of the 3 party key distribution exchange (KDE) . 11
4.2. 3 party key exchange scenarios . . . . . . . . . . . . . . 13
4.3. Derivation of keys protecting the KDE . . . . . . . . . . 14
4.3.1. keys protecting the KDE within a domain . . . . . . . 16
4.4. Specification of context and scope for distributed keys . 17
5. key derivation and delivery scenarios . . . . . . . . . . . . 17
5.1. Derivation and delivery of Handover Root Key . . . . . . . 17
5.1.1. Delivery of HRK to HOKEY server . . . . . . . . . . . 18
5.2. Derivation and delivery of Domain Specific Root keys . . . 20
5.2.1. Delivery of DSRK to domain server . . . . . . . . . . 20
5.3. Domain Specific Handover Root key . . . . . . . . . . . . 22
5.4. key delivery within a domain . . . . . . . . . . . . . . . 22
6. Security Considerations . . . . . . . . . . . . . . . . . . . 23
7. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 24
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.1. Normative References . . . . . . . . . . . . . . . . . . . 24
9.2. Informative references . . . . . . . . . . . . . . . . . . 25
Appendix A. Appendix A: Roaming hieararchy based on HRK . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . . . 28
Nakhjiri & Ohba Expires December 24, 2007 [Page 2]
Internet-Draft Hokey hierarchy June 2007
1. Introduction and Problem statement
The ability of Extensible Authentication Protocol (EAP) framework
([RFC3748] ) in incorporating desired authentication methods and
generating master session keys [I-D.ietf-eap-keying]) has led to the
idea of using EAP authentication and the resulting key material for
bootstrap further keys for a variety of security mechanisms. Out of
two master session keys, generated from EAP, the MSK is used heavily
for bootstrapping the security associations for the wireless link
between the peer and the network. However, the combination of the
heavy deployment of these solution and their issues around mobility
performance and agility ([I-D.nakhjiri-aaa-hokey-ps],
[I-D.ohba-hokey-3party-keydist-ps] and [I-D.ietf-hokey-reauth-ps])
had led the IETF HOKEY to consider use of the extended master session
key (EMSK) for providing future security bootstrapping problems, such
as handover keying, re-authentications and IP mobility provisioning
signaling.
Currently, specifications on use of EAP EMSK for generating further
keys in still work under progress. A general guideline document
([I-D.ietf-hokey-emsk-hierarchy]) describes how one can use EMSK to
generate the following child keys:
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.
DSRK: Domain Specific Root key. A root key generated from EMSK and
is used within a specific domain that peer is authorized to
receive services from or roam into, following an EAP
authentication. DSRK is usage independent.
DSUSRK: Domain Specific Usage Specific Root key. A root key
generated from EMSK and is used for a specific usage within a
specific domain that peer is authorized to receive services from,
following an EAP authentication. DSUSRK is both usage and domain
dependent.
EMSK
________________|_____________________________
| | | | | |
DSRK1 .. DSRKn USRK1..USRKm DSUSRK1 DSUSRKj
Figure 1: Different categories of EMSK Child keys
Nakhjiri & Ohba Expires December 24, 2007 [Page 3]
Internet-Draft Hokey hierarchy June 2007
[I-D.ietf-hokey-emsk-hierarchy] also describes how the knowledge
related to a specific usage or an administrative domain can be used
as standardized format input data into a cryptographic function to
generate USRKs, DSRK and DSUSRKs. The guidelines assure that
different child keys generated from the EMSK are cryptographically
separate from each other, so that compromise any EMSK child key does
not lead to compromise of the parent EMSK or the sibling child keys.
It should be noted that a USRK can be used to generate domain
specific keys for that specific usage (DSUSRK), while on the other
hand, a DSRK may have been authorized to a specific domain for a set
of allowed services. So it is also possible to create DSUSRKs for
those services at that domain. Thus coordination is necessary
between the home and visited domain on which DSUSRKs are generated
from USRK at home, which DSUSRKs can be generated from DSRK at
visited domain and which DSUSRKs can be generated directly as EMSK
child keys at the EAP server.
Since EAP authentication is a 2 party protocol, additional measures
should be taken to properly utilize the EAP generated keys in a 3
party key management arrangement. While USRK, DSRK and DSUSRK are
typically stored and utilized at third party key holders (e.g. AAA
servers/ entities) logically or physically separate from the EAP
server or peer, the security restrictions ([I-D.ietf-eap-keying])
forbid against transport of EMSK outside the EAP server/ layer. On
the other hand, EAP authentication and EMSK generation process is
oblivious to the future service requests and authorizations. This
will imply that the input data required for creation of the USRK,
DSRK or DSUSRK needs to be delivered to the EAP server, performing
the derivation function, followed by a secure delivery of the
resulting keys to these third party key holders. It is the purpose
of this document to show how such input data can be delivered to the
EAP server, and how the generated key material is delivered to the
third party key holder in a secure manner, while considering the
security requirements and principles defined in
[I-D.housley-aaa-key-mgmt] and [I-D.ohba-hokey-3party-keydist-ps]
into account. Thus, the specification includes derivation of key
material required for secure key delivery and channel binding
procedures 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.
To provide a complete solution for the problem of handover keying and
re-authentication, the key hierarchy specified in this document
includes specification of use of EMSK in derivation of top level
handover root keys (HRK), domain specific root keys (DSRK) and the
DSUSRK specifically for handover, called domain specific handover
root key (DSHRK), according to [I-D.ietf-hokey-emsk-hierarchy] and
Nakhjiri & Ohba Expires December 24, 2007 [Page 4]
Internet-Draft Hokey hierarchy June 2007
the delivery of these keys to the intended third parties.
The purpose of this document is not to provide exact syntax for the
signaling, only the general semantics for the parameters involved are
defined. The exact syntax for these parameters when carried by
specific protocols, such as AAA protocols or EAP protocols are out of
scope of this document.
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].
DSRK: Domain Specific Root key. A root key generated from EMSK and
is used within a specific domain that peer is authorized to
receive services from or roam into, following an EAP
authentication. DSRK is usage independent.
DSRK holder (DSR-KH): The DSR-KH is responsible for receiving,
holding and protection of the DSRK derived directly from EMSK.
The DSR-KH is possibly 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: Domain Specific Usage Specific Root key. A root key
generated from EMSK and is used for a specific usage within a
specific domain that peer is authorized to receive services from,
following an EAP authentication. DSUSRK is both usage and domain
dependent.
DSUSRK holder (DSUSR-KH): The DSUSR-KH is responsible for receiving,
holding and protection of the DSUSRK derived directly from EMSK.
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 the domain for the specific usage
at hand.
HOKEY server: This is essentially a usage specific server, that
deals with handover and re-authentication as specific usage
(USR-KH for HOKEY). For the purpose of this document, a HOKEY
server is domain independent and interacts directly with EAP
server to receive HRK from EAP server. This top level HOKEY
Nakhjiri & Ohba Expires December 24, 2007 [Page 5]
Internet-Draft Hokey hierarchy June 2007
server can generate and deliver domain specific HRKs (DSHRK) to
domain HOKEY servers.
domain HOKEY server: This is a server handling HOKEY service and
holding the domain specific HRK (DSHRK) for a specific domain.
For practical purposes, this can be a domain AAA server handling
HOKEY service. When DSHRK is generated from HRK, domain HOKEY
server deals with top level HOKEY server. When DSHRK is generated
directly from EMSK, the domain HOKEY server deals directly with
EAP server.
HRK: Handover root key is a key that will be used as the root key to
solve the handover keying and re-authentication problem. The HRK
is considered a usage specific root key (USRK) (defined in
[I-D.ietf-hokey-emsk-hierarchy]) and is derived directly from
EMSK. HRK is a domain independent specific root key for re-
authentication and handover, meaning that it can be used to create
domain-specific HRK for various domains (DSHRK). HRK is generated
using a Pseudo random function (PRF) that complies with
requirements and guidance in [I-D.ietf-hokey-emsk-hierarchy]. For
simplicity we refer to this PRF as USRK_PRF.
DSHRK: Domain specific handover root key: A key that can only be
used for HOKEY service within a specific domain.
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.
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.
USRK holder (USR-KH): The USR-KH is responsible for receiving,
holding and protection of the USRK derived directly from EMSK.
The USR-KH is possibly responsible for derivation and distribution
of any child keys derived from USRK for that specific usage.
3. EMSK key delivery architecture
As mentioned earlier, EMSK can be used to generate any of the USRKs,
DSRK and DSUSRKs. It should however be noted that a USRK can be used
to generate domain specific keys for that specific usage (DSUSRK),
while on the other hand, a DSRK may have been authorized to a
specific domain for a set of allowed services. So it is also
possible to create DSUSRKs for those services at that domain. While
the end result, a DSUSRK, is the same, the way to arrive at and
Nakhjiri & Ohba Expires December 24, 2007 [Page 6]
Internet-Draft Hokey hierarchy June 2007
deliver the DSUSRK to the proper destination is important: First,
coordination is necessary between the home and visited domain on
which DSUSRKs are generated from USRK at home, which DSUSRKs can be
generated from DSRK at visited domain and which DSUSRKs can be
generated directly as EMSK child keys. Second, the destination to
which the key is delivered is dictated by the type of key being
generated. This is important, since the EAP keying framework
([I-D.ietf-eap-keying]) forbids against transport of EMSK outside the
EAP server/ layer to ensure the security of EMSK. On the other hand,
the EAP server is not expected to be involved in any service
authorization decisions. To keep the generality of the specification
of the key delivery mechanism, we introduce the notion of key
holders:
USRK holder (USR-KH): For the purpose of the key delivery mechanism
specified in this document, this is an entity acting as a
recipient of the usage specific root key (USRK) derived from the
EMSK and delivered from the EAP server. Also, for the purpose of
the key delivery mechanism, the USR-KH has a interface with the
EAP server and is responsible for delivering the usage specific
input data required for derivation of USRK from EMSK to the EAP
server. Thus USR-KH is responsible for receiving, holding and
protection of the USRK derived directly from EMSK. The USR-KH is
possibly responsible for derivation and distribution of any child
keys derived from USRK for that specific usage.
DSRK holder (DSR-KH): For the purpose of the key delivery mechanism
specified in this document, this is an entity acting as a
recipient of the domain specific root key (DSRK) derived from the
EMSK and delivered from the EAP server. Also, for the purpose of
the key delivery mechanism, the DSR-KH has a interface with the
EAP server and is responsible for delivering the domain specific
input data required for derivation of DSRK from EMSK to the EAP
server. Thus DSR-KH is responsible for receiving, holding and
protection of the DSRK derived directly from EMSK. The DSR-KH is
possibly 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): For the purpose of the key delivery
mechanism specified in this document, this is an entity acting as
a recipient of the domain specific and usage specific root key
(DSUSRK) derived from the EMSK and delivered from the EAP server.
Also, for the purpose of the key delivery mechanism, the DSUSR-KH
has a interface with the EAP server and is responsible for
delivering the domain and usage specific input data required for
Nakhjiri & Ohba Expires December 24, 2007 [Page 7]
Internet-Draft Hokey hierarchy June 2007
derivation of USRK from EMSK to the EAP server. Thus DSUSR-KH is
responsible for receiving, holding and protection of the DSUSRK
derived directly from EMSK. 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 the domain for
the specific usage at hand.
In a general case, we can assume that the EAP server at the time of
authentication is unaware of any future service authorization
requests from the peer. Thus, the EAP server caches EMSK and creates
each of the EMSK child keys based on request, using its cache of
EMSK. Thus, the key holder needs to provide the EAP server with
proper input data before receiving the requested key. For instance a
visited domain HOKEY server, needs to authorize the peer for handover
keying and re-authentication service, and then request a handover
root key for its domain (visited domain HRK, VHRK) from the EAP
server. A home domain may also operate a home HOKEY server that uses
a home handover root key (HHRK) to serve the peer's re-authentication
and handover keying needs within home domain. The following figure
shows the assumed logical architecture for each type of EMSK child
key being created and delivered:
Nakhjiri & Ohba Expires December 24, 2007 [Page 8]
Internet-Draft Hokey hierarchy June 2007
+-+-+-+-+-+-+
| EAP server|
+-+-+-+-+-+-+
USRK1 / \ USRK2
(HRK) / \ (XYZ)
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+
| USR-KH1 | | USR-KH2 |
| HOKEY server | | XYZ server|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+
+-+-+-+-+-+-+
| peer |
+-+-+-+-+-+-+
(A)
+-+-+-+-+-+-+
| EAP server|
+-+-+-+-+-+-+
DSUSRK1 / \ DSUSRK2
(HHRK) / \ (VHRK)
+-+-+-+-+-+-+-+ +-+-+-+-+-+-+
| Domain 1 | | Domain 2 |
| DSUSR-KH | | DSUSR-KH |
|(home domain | |(visited domain|
|HOKEY server)| |HOKEY server) |
+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+
| peer |
+-+-+-+-+-+-+
(B)
+-+-+-+-+-+-+-+-+-+
| EAP server |
+-+-+-+-+-+-+-+-+-+
/ DSRK1 \ DSRK2
/ \
+-+-+-+-+-+-+ +-+-+-+-+-+-+-+
| DSR-KH1 | | DSR-KH2 |
+-+-+-+-+-+-+ +-+-+-+-+-+-+-+
+-+-+-+-+-+-+
| peer |
+-+-+-+-+-+-+
(C)
Nakhjiri & Ohba Expires December 24, 2007 [Page 9]
Internet-Draft Hokey hierarchy June 2007
Figure 2: 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. The general
mechanism for delivering a key to 3rd party is described in the
following section.
4. Distribution of EAP based keys to a third party
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. However, providing a
keying service, such as the handover keying and re-authentication
services, involves a set of key management services, including
creation of a key hierarchy and installation of specific keys at one
or more of such third party intermediaries (figure 2). Requirements
for such AAA/ EAP based key management procedures are stated in
several documents ([I-D.housley-aaa-key-mgmt],
[I-D.ietf-hokey-reauth-ps], [I-D.ohba-hokey-3party-keydist-ps] ).
Requirements such as well-defined key scope and authentication of all
parties are addressed by the following 3 party key distribution
mechanism, which allows distribution of a key, initially only known
to two parties (typically directly and mutually authenticated), to a
well-identified third party.
As seen above handover keying and re-authentication service requires
distribution of keys a variety of intermediaries. In the following
we describe the mechanism for a 3 party key distribution exchange
(KDE), where a key is distributed from a network server (with parent
key holder) to a generic third party. The following shows a generic
trust model for the 3 party key distribution mechanism. The peer (P)
and a parent key holder, called "server" (S) in this model share a
parent key from the key hierarchy. From this parent key, a key (Kpt)
is to be generated and distributed to a third party intermediary (T).
We keep the generation of Kpt out of the general description of the
KDE (key distribution exchange) as the goal is show the process for
distribution of Kpt from S to T. To support the key distribution
mechanism, we assume that the peer and the server share a set of
security associations, including keys for integrity and privacy
protection of the signaling between the peer and the server (KIps and
KCps for integrity and privacy protection). We also assume that the
server (S) and the third party (T) share a similar set security
association (KIts, KCts).
Nakhjiri & Ohba Expires December 24, 2007 [Page 10]
Internet-Draft Hokey hierarchy June 2007
+-+-+-+-+ +-+-+-+-+-+-+-+
| | shared SA1 | |
| |------------------------------| server |
| Peer | | KH |
+-+-+-+-+ +-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+ V
| 3 rd party | | SA2 (Kpt)
| KH | ----------|
+-+-+-+-+-+-+
Figure 3: Distribution of a child key from a parent key key holder to
a 3rd party child key key holder
4.1. Overview of the 3 party key distribution exchange (KDE)
The key distribution mechanism described below is a modified version
of the Otway-Rees protocol that meets the requirements for such
3-party lay-out. The description below can be carried over a generic
transport and thus is independent of the exact type of protocol that
is used. However for the purpose of this document the assumption is
that the 3 party mechanism parameters are carried for EAP messages
that are themselves encapsulated over a lower layer such as a AAA
protocol or an access protocol.
The exchange proposed below is to perform a channel binding and avoid
the lying intermediary scenario, where the intermediary announces 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 peer token to calculate the MIC in the
third party token ([PID, UTID]KIts) and if there 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.
The 3 party key distribution 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.
0 Third party to peer: (DTID, DID)
Nakhjiri & Ohba Expires December 24, 2007 [Page 11]
Internet-Draft Hokey hierarchy June 2007
1 Peer to Third party: Int[ KIps, (PID, DTID, DID, Np,KN_KIps)]
2 Third party to Server: Int[KIts, (PID, UTID)], Int[ KIps, (PID,
DTID, DID, Np,KN_KIps)]
3 Server to third party: {PID,TID,KN_Kpt, KL_Kpt, Kpt}KCts, Int[
KIps, (PID, TID, DID, Np+1,KN_Kpt,KL_Kpt, KN_KIps)]
4 Third party to Peer: Int[KIps, (PID, TID, DID, Np+1,
KN_Kpt,KL_Kpt, KNps)]
the notation is as follows:
PID: peer ID. The information is expected by carried by an existing
attribute within EAP and/or AAA protocols.
DID: Domain ID, used for generation of domain specific keys, such as
HHRK (see key generation).
TID: third party ID (obtained by the peer through beacon
announcements or other means)
DTID: third party ID as perceived by the peer (down link ID)
UTID: third party ID as perceived by the server (uplink ID)
{X}K: X encrypted with key K
Int[K, X]: X || MIC (K, X), where MIC Message Integrity Code over X
with key K.
KIps: A symmetric key shared between peer and Server for signing and
identified by KN_KIps.
KCps: A symmetric key shared between peer and Server for encryption
and identified by KN_KCps
KCts: A symmetric key shared between third party and Server for
encryption (provisioned out of band).
KIts: A symmetric key between third party and server for signing
(provisioned out of band).
Kpt: A symmetric key to be shared between peer and third party (key
to be distributed to third party). The key is named as KN_Kpt.
KL_Kx : Key lifetime for key x
Nakhjiri & Ohba Expires December 24, 2007 [Page 12]
Internet-Draft Hokey hierarchy June 2007
KN_Kx: Key name for Key x, e.g. KN_KIas: key name for KIas
Nx : Nonce provided by the party X
Int[ KIps, (PID, DTID, DID, Np,KN_KIps)] is called the peer request
token (PRT), which carries the identities of both peer and the third
party along with a signature. The signature is called the peer
request authenticator (PRA).
Int[KIts, (PID, UTID)] is called thirdparty_ID_token (TIT), which
carries a signature, called third party ID authenticator.
{PID,TID,KN_Kpt, KL_Kpt, Kpt}KCts is called key_token (KT), which
carries the Kpt wrapped with KCts (encryption key shared between the
third party and server).
Int[ KIps, (PID, TID, DID, Np+1,KN_Kpt,KL_Kpt, KN_KIps)] is called
Server_authorization_token (SAT).
4.2. 3 party key exchange scenarios
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.
EAP server to USR-KH: The service requested by the peer (e.g.
Handover keying and re-authentication keying service) is provided
by the a server that also authorizes that service. This server is
a AAA-style server other than the EAP server (e.g. a HOKEY
server), since EAP server is typically only in charge of EAP
authentication and MSK/EMSK generation. For the purpose of this
document, we assume that this server is the USR-KH for that
service (usage). Following the authorization of the service
(usage) a request is placed with the EAP server and the USRK is
generated and delivered to USR-KH. The USR-KH is domain
independent and the USR-KH can use USRK to generate DSUSRK for
other domain. It is possible that this USR-KH server is not
physically disjunct from the EAP server and thus is identified
with the same identity as the EAP server. In such cases, the
existence of USR-KH server is to off-load the EAP server from the
need to handle usage specific services, such as HOKEY service, for
multiple domains. Security Requirements for delivery of USRK from
EAP server to a collocated USR-KH is currently TBD. However, to
keep the 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 according to the KDE. The specific
use case considered in this document is HOKEY service: The USR-KH
Nakhjiri & Ohba Expires December 24, 2007 [Page 13]
Internet-Draft Hokey hierarchy June 2007
is a HOKEY service and USRK is HRK. The EAP server delivers the
HRK to the USR-KH (HOKEY server). The details of this procedure
is discussed later in this document. The trigger and mechanism
for key delivery may involve a specific request from the peer and
another intermediary (such as authenticator) for HOKEY service.
EAP server to DSR-KH In this scenario, a domain server, typically a
domain AAA server requires delivery of a DSRK for all allowed
usage within the domain. DSR-KH are EAP server are physically
disjunct. Thus deployment of 3 party key distribution exchange is
required.
USR-KH to DSUSR-KH: This stage assumes that both peer and USR-KH
server possess USRK, and further operation between peer and the
domain that the peer intends to attach to, depends on delivery of
a domain specific USRK (DSUSRK) to the DSUSR-KH. It is best to
assume that the USR-KH and DSUSR-KH HOKEY are physically separate
and thus deployment of the 3 party KDE is required for the
delivery of DSUSRK.
domain specific key management operations: Domain specific scenarios
can involve delivery of keys that are at lower levels of the key
hierarchy, for instance keys that are children of USRK, DSRK or
DSUSRK and not children of EMSK. Such key generation and
management scenarios do not involve EAP server, but still can and
need to use a 3 party key distribution exchange mechanism to
ensure secure delivery of the key to a third party. An example is
delivery of per-authenticator keys from domain HOKEY server to an
authenticator.
4.3. 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 an EMSK child key (USRK, DSRK,
or DSUSRK), these two keys are generated directly from EMSK.
Nakhjiri & Ohba Expires December 24, 2007 [Page 14]
Internet-Draft Hokey hierarchy June 2007
EMSK
________________|________________
| | | | |
DSRK USRK DSUSRK CK IK
Figure 4: Key delivery keys as EMSK Child keys
Cipher key (CK) and Integrity Key (IK) are generated from EMSK as
domain independent USRKs. CK and IK are used to protect KDE for
delivery of USRK, DSRK and those DSUSRKs that are generated from EMSK
directly.
We refer to PRF used to generate the USRKs, USRK-PRF, and assume that
it can generate Z bits of output.
In order to be able to perform the key delivery exchange,
IK | IK_name_key=USRK-PRF (EMSK, "Integrity Key" | NULL | peer_ID |
Key_length )
IK_name=First(128, HMAC_SHA256(IK_name_key "Integrity Key"| NULL|
peer_ID)
CK | CK_name_key=USRK-PRF (EMSK, "Cipher Key" | NULL | peer_ID |
Key_length )
CK_name=First(128, HMAC_SHA256(CK_name_key, "Cipher Key" | NULL |
peer_ID)
Where, First (N, X) refers to the first N bits of X and it is assumed
that USRK_PRF generates Z=X+Y bits, where the first X bits are used
for key itself, while the remaining Y bits are used for key_name_key,
which is used to create temporal uniqueness in the key name
generation. Choice of Z and X are outside scope of this document.
The "Usage_label" value is to be assigned by IANA to the strings
"Integrity Key" and "Cipher Key".
NULL as domain label, since the IK and CK are considered to be a
usage specific, but domain independent keys. Thus domain label is
wild carded.
Peer_ID is the identifier for the peer. This identifier is exchanged
in the key distribution exchange (KDE) as described shortly.
It is assumed the parties involved in the key distribution exchange
will need to be able to have access (or derive??) to the CK and IK to
Nakhjiri & Ohba Expires December 24, 2007 [Page 15]
Internet-Draft Hokey hierarchy June 2007
protect the key delivery signaling.
4.3.1. keys protecting the KDE within a domain
The following provides an example of derivation of integrity and
cipher keys for distributions of service related keys within a
domain. We assume that the keys to be delivered (KX or KY) are
derived from a DSUSRK for that domain and specific usage. We call
the cipher key and integrity key for delivering a domain and usage
specific child of DSUSRK, the DUCK and DUIK, respectively.
DSUSRK
______|________________
| | | |
KX KY DUCK DUIK
Figure 5: Keys for delivery of service keys within a domain
DUIK | DUIK_name_key=PRF (DSUSRK, "domain usage Integrity Key" |
Domain Label | peer_ID | Key_length )
DUIK_name=First(128, HMAC_SHA256(DUIK_name_key "domain usage
Integrity Key"| Domain Label | peer_ID)
DUCK | DUCK_name_key=PRF (DSUSRK, "domain usage Cipher Key" | Domain
Label | peer_ID | Key_length )
DUCK_name=First(128, HMAC_SHA256(DUCK_name_key, " domain usage Cipher
Key" | Domain Label | peer_ID)
KX and KY above are both keys related to a specific service as
defined in generation of DSUSRK.
It is also possible to use the same keys to protect delivery of keys
for all services within a domain, as long as service independent root
keys (DSRK) are available. In that case, the key delivery keys
(integrity and cipher keys for KDE protection) are derived from a
DSRK, so that the same keys can be used to protect KDE for delivery
of keys for any type of key derived from DSRK.
DSRK
______|________________
| | | |
KX KY DCK DIK
Figure 6: Keys for delivery of keys within a domain
Nakhjiri & Ohba Expires December 24, 2007 [Page 16]
Internet-Draft Hokey hierarchy June 2007
DIK | DIK_name_key=PRF (DSRK, "domain Integrity Key" | Domain Label |
peer_ID | Key_length )
DIK_name=First(128, HMAC_SHA256(DIK_name_key "domain Integrity Key"|
Domain Label | peer_ID)
DCK | DCK_name_key=PRF (DSRK, "domain Cipher Key" | Domain Label |
peer_ID | Key_length )
DCK_name=First(128, HMAC_SHA256(DCK_name_key, " domain Cipher Key" |
Domain Label | peer_ID)
4.4. Specification of context and scope for distributed keys
To be completed.
5. key derivation and delivery scenarios
5.1. Derivation and delivery of Handover Root Key
Depending on the deployment and trust models, several key hierarchy
models can be considered for solving the handover and re-
authentication problem, based on the category of the EMSK child key
categories used. In this section we will discuss derivation and
delivery of handover root key (HRK) as a top level root key for
handover keying and re-authentication usage. This will not only
serve as an example for derivation and delivery of a USRK, but also
provide enough specification to support other handover keying and re-
authentication specifications. HRK is considered as USRK. The
USR-KH to cache and maintain HRK is called HOKEY server. Since the
top level HRK is domain independent, a domain independent HOKEY
server can hold HRK and can act authorization server for service to
multiple domains, delivering domain specific HRK (DSHRK) to each
domain as needed. Domain dependent HOKEY servers are deployed in
each domain to be only responsible for receiving DSHRK and
authorization and delivery of handover keying and re-authentication
services within that domain.
In this section we only discuss delivery of HRK to top level HOKEY
server, leaving delivery of DSHRKs for later.
subscribing to the model of USRK for HRK derivation and delivery, the
following portions of the EMSK hierarchy are considered in this
section. As mentioned in [I-D.ietf-hokey-emsk-hierarchy] the USRK-
PRF used below can be negotiated, pre-configured based on network
policy. We assume that it can generate Z=X+Y bits of output, where
the first X bits are used for HRK, while the remaining Y bits are
Nakhjiri & Ohba Expires December 24, 2007 [Page 17]
Internet-Draft Hokey hierarchy June 2007
used for HRK_name_key, which is used to create temporal uniqueness in
the key name generation.
EMSK
________|_____________
| | |
HRK CK IK
Figure 7: Using EMSK for HRK derivation and delivery
HRK | HRK_name_Key=USRK-PRF (EMSK, Usage_label | NULL | Peer_ID |
Key_length)
HRK_name=First (128, HMAC_SHA256(HRK_name_Key, "Usage_label | NULL |
peer_ID))
The "Usage_label" value is to be assigned by IANA to the string
"Handover Root Key".
NULL as domain label, since the HRK is considered to be a usage
specific (for handover keying and re-authentication) but domain
independent root key. Thus domain label is wild carded. This way
the same HRK can be used to create root keys for all visited and home
domains.
Peer_ID is the identifier for the peer as known to the server
generating HRK. This identifier is exchanged in the key distribution
exchange (KDE) as described shortly.
The HRK is stored at this HOKEY server database. We can call this
database the HRK key holder (HRK-KH).
HOKEY server can for instance generate a home HRK (HHRK) for the home
HOKEY server or AAA server and a visited HRK (VHRK) for the visited
HOKEY server or AAA server.
5.1.1. Delivery of HRK to HOKEY server
The HOKEY server is a USR-KH, which is considered a third party to
the initial EAP parties (peer and EAP server). The key distribution
exchange (KDE) can be used to the deliver the HRK from EAP server to
the domain independent HOKEY server, using the CK and IK derived from
EMSK (described in earlier section). Since HRK is domain
independent, domain information is omitted from exchanged tokens.
Nakhjiri & Ohba Expires December 24, 2007 [Page 18]
Internet-Draft Hokey hierarchy June 2007
0 HOKEY server to peer: (DHID)
1 Peer to HOKEY server: Int[ IK, (PID, DHID, Np,KN_IK)]
2 HOKEY server to EAP Server: Int[KIhs, (PID, UHID)], Int[ IK, (PID,
DHID, Np,KN_IK)]
3 EAP Server to HOKEY server: {PID,HID,KN_HRK, KL_HRK, HRK}KChs,
Int[ IK, (PID, HID, Np+1,KN_HRK,KL_HRK, KN_IK)]
4 HOKEY server to Peer: Int[IK, (PID, HID, Np+1, KN_HRK,KL_HRK,
KN_IK)]
the notation is as follows:
PID: peer ID. The information is expected by carried by an existing
attribute within EAP and/or AAA protocols.
HID: HOKEY server ID (obtained by the peer through beacon
announcements or other means)
DHID: downlink HOKEY server ID as perceived by the peer (down link
ID)
UHID: Uplink HOKEY server ID as perceived by the EAP server (uplink
ID)
{X}K: X encrypted with key K
Int[K, X]: X || MIC (K, X), where MIC Message Integrity Code over X
with key K.
IK: Integrity key, A symmetric key shared between peer and EAP Server
for signing and identified by KN_IK.
CK: A symmetric key shared between peer and EAP Server for encryption
and identified by KN_CK
KChs: A symmetric key shared between HOKEY and EAP servers for
encryption (provisioned out of band).
KIhs: A symmetric key between HOKEY and EAP servers for signing
(provisioned out of band).
HRK: to be shared between peer and HOKEY server. The key is named as
KN_HRK.
KLx : Key lifetime for key x
Nakhjiri & Ohba Expires December 24, 2007 [Page 19]
Internet-Draft Hokey hierarchy June 2007
KN_Kx: Key name for Key x, e.g. KN_KIas: key name for KIas
Nx : Nonce provided by the party X
Roaming between two administrative domains, e.g. from home domain to
visited domain, while mid-session, would require involvement of a top
level HOKEY server, so that it can generate a domain-specific HRK
(DSHRK) for that domain.
5.2. Derivation and delivery of Domain Specific Root keys
A domain server acts as an authority for authorizing services, and
DSRK holder (DSR-KH) and can authorize and generate keys for a set of
services for which DSRK is generated (see
[I-D.ietf-hokey-emsk-hierarchy]). In this model each domain server
needs to refer to the EAP server to derive DSRK directly from the
EMSK.
DSRK | DSRK_name_Key=DSRK_PRF(EMSK, NULL | Domain_ID | Peer_ID |
Key_length)
DSRK_name=First (128, HMAC_SHA256(DSRK_name_Key, NULL | peer_ID))
Where Usage label is wild carded by inserting a NULL.
the Domain_ID is the identifier of the domain for which the DSRK is
being derived, e.g. Home_domain_ID for DSHRK.
5.2.1. Delivery of DSRK to domain server
The DSR-KH is considered as a third party and thus the key
distribution exchange is to be used for distributing DSRKs to the
DSR-KH. CK and IK derived from EMSK (described in earlier section)
are used for protecting the signaling. The delivery of DSRK to
DSR-KH is very similar to delivery of USRK to USR-KH, except the
domain ID needs to be communicated to both peer and EAP server.
0 Domain server to peer: (DDID, DID)
1 Peer to Domain server: Int[ IK, (PID, DDID, DID, Np,KN_IK)]
2 Domain server to EAP Server: Int[KIds, (PID, UDID)], Int[ IK,
(PID, DDID, DID, Np,KN_IK)]
3 EAP Server to Domain server: {PID,DID,KN_DSRK, KL_DSRK, DSRK}KCds,
Int[ IK, (PID, DID, Np+1,KN_DSRK,KL_DSRK, KN_IK)]
Nakhjiri & Ohba Expires December 24, 2007 [Page 20]
Internet-Draft Hokey hierarchy June 2007
4 Domain server to Peer: Int[IK, (PID, DID, Np+1, KN_DSRK,KL_DSRK,
KN_IK)]
the notation is as follows:
PID: peer ID. The information is expected by carried by an existing
attribute within EAP and/or AAA protocols.
DID: Domain server ID (obtained by the peer through beacon
announcements or other means)
DDID: down link Domain server ID as perceived by the peer (down link
ID)
UDID: Uplink Domain server ID as perceived by the EAP server (uplink
ID)
{X}K: X encrypted with key K
Int[K, X]: X || MIC (K, X), where MIC Message Integrity Code over X
with key K.
IK: Integrity key, A symmetric key shared between peer and EAP Server
for signing and identified by KN_IK.
CK: A symmetric key shared between peer and EAP Server for encryption
and identified by KN_CK
KCds: A symmetric key shared between Domain and EAP servers for
encryption (provisioned out of band).
KIds: A symmetric key between Domain and EAP servers for signing
(provisioned out of band).
DSRK: to be shared between peer and domain server. The key is named
as KN_DSRK.
KLx : Key lifetime for key x
KN_Kx: Key name for Key x, e.g. KN_KIas: key name for KIas
Nx : Nonce provided by the party X
Roaming between two administrative domains, e.g. from home domain to
visited domain, while mid-session, would require involvement of EAP
server, so that it can generate a domain-specific HRK (DSRK) for that
domain based on the knowledge of peer and domain server identities.
Nakhjiri & Ohba Expires December 24, 2007 [Page 21]
Internet-Draft Hokey hierarchy June 2007
5.3. Domain Specific Handover Root key
A domain server can act as domain HOKEY server, holding the DSUSRK
for HOKEY usage (DSUSR-KH). In this model each domain HOKEY server
needs to refer to the EAP server to derive DSHRK directly from the
EMSK.
DSHRK | DSHRK_name_Key=DSUSRK_PRF(EMSK, Usage_lable| Domain_ID |
Peer_ID | Key_length)
DSHRK_name=First (128, HMAC_SHA256(DSHRK_name_Key, Usage_label |
peer_ID))
Where Usage label is "Domain Handover Root Key".
the Domain_ID is the identifier of the domain for which the DSHRK is
being derived, e.g. Home_domain_ID for HHRK.
When roaming from one domain to the next, a domain specific handover
root key (DSHRK) needs to be requested and generated from the EMSK
and based on the knowledge of peer and domain server identities.
5.4. key delivery within a domain
In this section we describe the use of KDE in delivery a key within a
domain. We use delivery of a key to be shared between a peer and an
authenticator (Kpa) from a domain HOKEY server to an authenticator as
an example. The domain HOKEY server holds a domain specific handover
root key (DSHRK) and thus is a DSUSR-KH. The peer and the domain
HOKEY server share the DSHRK and can be both generate the Kpa. The
authenticator is considered as a third party. The KDE is used to
deliver the Kpa to the authenticator. However, since the KDE is
performed within a domain, domain and usage specific IK and CK (DUIK
and DUCK) are used for protecting the signaling. The derivation of
DUIK and DUCK is described in section XXX.
0 Authenticator to peer: (DAID, DID)
1 Peer to Authenticator: Int[ DUIK, (PID, DAID, DID, Np,KN_DUIK)]
2 Authenticator to Domain HOKEY Server: Int[KIas, (PID, UAID)], Int[
DUIK, (PID, DAID, DID, Np,KN_DUIK)]
3 Domain HOKEY server to Authenticator: {PID,DID,KN_Kpa, KL_Kpa,
Kpa}KCas, Int[ DUIK, (PID, DID, Np+1,KN_Kpa,KL_Kpa, KN_DUIK)]
Nakhjiri & Ohba Expires December 24, 2007 [Page 22]
Internet-Draft Hokey hierarchy June 2007
4 Authenticator to Peer: Int[DUIK, (PID, DID, Np+1, KN_Kpa,KL_Kpa,
KN_DUIK)]
the specific notation is as follows:
PID: peer ID. The information is expected by carried by an existing
attribute within EAP and/or AAA protocols.
DID: Domain ID, used for generation of domain specific keys, such as
HHRK (see key generation).
AID: Authenticator ID (obtained by the peer through beacon
announcements or as part of EAP Identity Request)
DAID: Authenticator ID as perceived by the peer (down link ID)
UAID: Authenticator ID as perceived by the server (uplink ID)
{X}K: X encrypted with key K
Int[K, X]: X | MIC (K, X) Message Integrity Code over X with key K.
X(Y): Y carried with X protocol
DUIK: Integrity key, A symmetric key shared between peer and domain
HOKEY server for signing and identified by KN_DUIK.
DUCK: A symmetric key shared between peer and domain HOKEY server for
encryption and identified by KN_DUCK
KCas: A symmetric key shared between authenticator and Server for
encryption (provisioned out of band).
KIas: A symmetric key between authentication and server for MDCs for
signing (provisioned out of band).
Kpa: A symmetric key to be shared between peer and authenticator.
The key is named as KN_Kpa.
KLx : Key lifetime for key x
KN_Kx: Key name for Key x, e.g. KN_KIas: key name for KIas
Nx : Nonce provided by the party X
6. Security Considerations
Nakhjiri & Ohba Expires December 24, 2007 [Page 23]
Internet-Draft Hokey hierarchy June 2007
7. IANA consideration
This document defines new usage labels, such as those used in
generation of CK, IK, HRK. The corresponding labels (e.g.
"Integrity Key" and "Cipher key") need to be assigned numerical
values by IANA.
8. Acknowledgements
The author would like to thank XX feedback.
9. References
9.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-eap-keying]
Aboba, B., "Extensible Authentication Protocol (EAP) Key
Management Framework", draft-ietf-eap-keying-18 (work in
progress), February 2007.
[I-D.nakhjiri-aaa-hokey-ps]
Nakhjiri, M., "AAA based Keying for Wireless Handovers:
Problem Statement", draft-nakhjiri-aaa-hokey-ps-03 (work
in progress), June 2006.
[I-D.ietf-hokey-reauth-ps]
Clancy, C., "Handover Key Management and Re-authentication
Problem Statement", draft-ietf-hokey-reauth-ps-01 (work in
progress), January 2007.
[I-D.ietf-hokey-emsk-hierarchy]
Salowey, J., "Specification for the Derivation of Usage
Specific Root Keys (USRK) from an Extended Master Session
Key (EMSK)", draft-ietf-hokey-emsk-hierarchy-00 (work in
progress), January 2007.
[I-D.ohba-hokey-3party-keydist-ps]
Ohba, Y., "Problem Statement and Requirements on a 3-Party
Key Distribution Protocol for Handover Keying",
Nakhjiri & Ohba Expires December 24, 2007 [Page 24]
Internet-Draft Hokey hierarchy June 2007
draft-ohba-hokey-3party-keydist-ps-01 (work in progress),
March 2007.
[I-D.nakhjiri-hokey-hierarchy]
Nakhjiri, M., "Keying and signaling for wireless access
and handover using EAP (EAP-HR)",
draft-nakhjiri-hokey-hierarchy-04 (work in progress),
April 2007.
[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.
9.2. Informative references
[I-D.housley-aaa-key-mgmt]
Housley, R. and B. Aboba, "Guidance for AAA Key
Management", draft-housley-aaa-key-mgmt-09 (work in
progress), February 2007.
Appendix A. Appendix A: Roaming hieararchy based on HRK
The HOKEY server can use HRK to generate separate domain specific
handover root keys (DSHRK) for each domain, e.g. a home HRK (HHRK)
for home domain and a visited HRK (VHRK) for each visited domain.
HHRK | HHRK_name_Key=HO_PRF(HRK, Peer_ID | home_domain_ID |
Key_length)
VHRK | VHRK_name_Key=HO_PRF(HRK, Peer_ID | visited_domain_ID |
Key_length)
Since HHRK and VHRK are no longer derived from the EMSK, the PRF used
for generating these keys may or may need to comply with the
requirements in [I-D.ietf-hokey-emsk-hierarchy] and thus we have used
the notion of HO_PRF to indicate this flexibility.
HHRK_name=First (128, HMAC_SHA256(HHRK_name_Key, "domain handover
root key derivation"| peer_ID))
VHRK_name=First (128, HMAC_SHA256(VHRK_name_Key, "domain handover
root key derivation"| peer_ID))
Nakhjiri & Ohba Expires December 24, 2007 [Page 25]
Internet-Draft Hokey hierarchy June 2007
Home_domain_ID or the Visited_domain_ID are the identifier for the
home or visited domain as known to both peer and the HOKEY server
generating HHRK or VHRK. When roaming from one domain to the next,
the peer needs to request for the domain specific handover root key
(DSHRK) to be generated from the HRK and exchange its own identity as
well as the domain identity with the server.
It should be mentioned that HHRK and VHRKs can be generated directly
from EMSK as usage and specific root keys (USDSRK). In that case it
would be the EAP server that has to generate such domain specific
handover root keys (DSHRK), which means each DSHRK request needs to
be made directly to the EAP server, along with domain_label for the
domain. The preferred method is to generate DSHRK from HRK instead.
Domain specific HRKs (DSHRK) are delivered to the domain HOKEY
servers through secure transport and cached at domain HOKEY servers,
at a so called DSHRK key holder (DSHRK-KH). Proper care needs to be
taken to assure that DSHRK is bound to the identity of the HOKEY
server caching the DSHRK. This is described later on.
In case the peer is at home domain, HHRK is delivered to the home
HOKEY server.
Providing re-authentication and handover keying service within each
domain is upon the HOKEY server within that domain. This means
integrity and cipher keys (IK and CK) for re-authentication and
handover keying signaling can be domain specific (DSIK and CSIK).
Also the mobility domain master session keys (MDMSK) passed to the
authenticators within the administrative domain are also domain
specific. This means DSHRK is used for calculation of these keys.
It should be obvious that DSHRK, DSIK and DSCK are only accessible to
the peer and domain HOKEY server, but not to the authenticator within
the domain. The following describes derivation of IK and CK for home
domain (HUIK and CUIK) from HHRK:
HUIK | HUIK_name_key=HO-PRF (HHRK, "domain integrity Key" |
peer_ID | Home_domain_ID | Key_length )
HUIK_name=First(128, HMAC_SHA256(HUIK_name_key "domain integrity
Key"| peer_ID)
HUCK | HUCK_name_key=HO-PRF (HHRK, "domain cipher Key" | peer_ID |
Home_domain_ID | Key_length )
HUCK_name=First(128, HMAC_SHA256(HUCK_name_key, "domain cipher
Key"| peer_ID)
Nakhjiri & Ohba Expires December 24, 2007 [Page 26]
Internet-Draft Hokey hierarchy June 2007
Authors' Addresses
Madjid Nakhjiri (editor)
Huawei USA
Email: mnakhjiri@huawei.com
Yoshihiro Ohba (editor)
Toshiba
Email: yohba@tari.toshiba.com
Nakhjiri & Ohba Expires December 24, 2007 [Page 27]
Internet-Draft Hokey hierarchy June 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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 December 24, 2007 [Page 28]
