Internet DRAFT - draft-cao-hoakey-hierarchical-hokey
draft-cao-hoakey-hierarchical-hokey
Network Working Group Z. Cao
Internet-Draft Peking University
Expires: December 21, 2006 Y. Ma
H. Deng
Hitachi (China)
Q. Li
BeiHang University
June 19, 2006
Handover Key Hierarchy based on Extended Master Session Key (EMSK)
Derivation
draft-cao-hoakey-hierarchical-hokey-00.txt
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 21, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The Extensible Authentication Protocol (EAP) provides a framework
supporting various authentication protocols known as EAP methods. To
avoid a full EAP authentication exchange when there is a handover
Cao, et al. Expires December 21, 2006 [Page 1]
Internet-Draft Handover Key Hierarchy from EMSK June 2006
across EAP authenticators, a handover key hierarchy should be
specified. This document specifies how to derive a handover key
hierarchy from the Extended Master Session Key (EMSK). In our
mechanism, both intra and inter-authenticator handovers can be
supported.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Network Handover Topology . . . . . . . . . . . . . . . . . . 6
4. Handover Key Hierarchy . . . . . . . . . . . . . . . . . . . . 7
4.1. rRK Derivation and Naming . . . . . . . . . . . . . . . . 8
4.2. R0-Key Derivation and Naming . . . . . . . . . . . . . . . 9
4.3. R1-Key Derivation and Naming . . . . . . . . . . . . . . . 9
4.4. TSK Derivation and Naming . . . . . . . . . . . . . . . . 10
5. Key Derivation Function . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15
9. Reference . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Appendix A. Intra-ADC Handover . . . . . . . . . . . . . . . . . 16
Appendix B. Inter-ADC Handover . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19
Cao, et al. Expires December 21, 2006 [Page 2]
Internet-Draft Handover Key Hierarchy from EMSK June 2006
1. Introduction
With the proliferation of wireless technology and mobile service, the
need for seamless handover in such scenario is becoming incresingly
important. When there is a handover across EAP authenticators, a
full EAP re-authentication exchange will inevitably cause
unacceptable network latency. Therefore it is urgent to design a
effective mechanism which makes use of previous EAP authentication
results for fast handover across authenticators.
The Extensible Authentication Protocol (EAP) provides a framework
supporting various authentication protocols known as EAP methods
[RFC3748]. Two keys, a Mater Session Key (MSK) and an Extended
Master Session Key (EMSK) are produced by EAP methods. EAP keying
framework [I-D.ietf-eap-keying] leaves behind the question of EMSK
usage specifications, while [I-D.eap-emsk-deriv] specifies how to
derive USRK from EMSK for different kinds of usages.
In this document, we specify the derivation of a re-authentication
root key (rRK) from EMSK for re-authentication purpose. From the
rRK, a three level handover key hierarchy is derived to support both
intra and inter-authenticator handover. The handover scenario
concerned in this document is based on the problem statement given by
[I.D.aaa-hokey-ps].
Cao, et al. Expires December 21, 2006 [Page 3]
Internet-Draft Handover Key Hierarchy from EMSK June 2006
2. Terminology
The keywords "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 [RFC2119].
The following new terminology and abbreviations are introduced in
this document and all the other general mobility related terms as
defined in [I-D.ietf-eap-keying] and [I.D.aaa-hokey-ps]
Access Node (AN)
The access node is the entity (layer 2 or layer 3) residing at the
edge of network and is responsible for providing access link to
the peer. The access node typically is a R1-Key Holder holding
R1-Key to derive the Transient Session Key (TEK). Multiple Access
Nodes MAY be grouped under one Access Domain Controller.
Access Node Identifier (AN-ID)
The 16 octet identifier that is advertised by an Access Node to
differentiate different ANs.
Access Domain Controller (ADC)
Entity responsible for keying needs within an Access Domain. ADC
typically is a R0-Key Holder that holds a per-ADC specific R0-Key
for the authentication domain and uses this R0-Key to derive R1-
Key for different ANs under its control.
Access Domain (AD)
A logical entity whose authentication (with the backend EAP/AAA
server) and key management goes through the same ADC.
Access Domain Identifier (AD-ID)
The 16 octet identifier that is advertised by an Access Domain to
differentiate different ADs.
Key Holder
The functional entity that holds a root key/s and can perform
further key derivation using that root key. There may be multiple
Key Holders in the network (e.g. at the AAA server or ADC).
rRK
Cao, et al. Expires December 21, 2006 [Page 4]
Internet-Draft Handover Key Hierarchy from EMSK June 2006
The re-authentication root key derived from EMSK. The rRK is a
kind of USRK for re-authentication purpose, and is used to derive
R0-Key.
R0-Key
The first level key in the handover key hierarchy shared between
the supplicant and R0 key holder used to derive R1-Key.
R0Name
A 16 octet identifier used to identify the R0-Key.
R1-Key
The second level key in the handover key hierarchy shared between
the supplicant and R1 key holder used to derive R2-Key.
R1Name
A 16 octet identifier used to identify the R1-Key.
Supplicant Address (SPA)
The link layer address of the EAP supplicant, i.e. the mobile
node.
TSKName
A 16 octet identifier used to identify the TSK
Cao, et al. Expires December 21, 2006 [Page 5]
Internet-Draft Handover Key Hierarchy from EMSK June 2006
3. Network Handover Topology
(R1-Key)
+-+-+-+-+-+ +-+-+-+
| MN/ |-----| AN1 |---+ (R0-Key)
|EAP Peer | +-+-+-+ | +--------------+
+-+-+-+-+-+ +-----| ADC1(R0_KH1) |---+
| +--------------+ | (rRK)
| | +-+-+-+-+-+
+-+-+-+ | | | AAA/EAP |
| AN2 |---+ +-+---| Server |
+-+-+-+ | +---------+
(R0-Key) |
+-+-+-+ +--------------+ |
| AN3 |---------| ADC2(R0_KH2) |-----+
+-+-+-+ +--------------+
Figure 1: Network Handover Topology
From the network handover topology shown in Figure 1, we can have a
base knowledge of intra and inter-ADC handovers. A detailed
description is also available in [I.D.aaa-hokey-ps].
o Intra-ADC Handover: the handover from one Access Node to another
one within the same ADC, e.g. mobile node roams from AN1 to AN2
in Figure 1.
o Inter-ADC Handover: the handover from one Access Node to another
one under a different ADC, e.g. mobile node roams from AN2 to AN3
in Figure 1.
Both intra and inter-ADC handover are supported by the handover key
hierarchy proposed in this document. Example senarios are described
in Appendix A and Appendix B.
Cao, et al. Expires December 21, 2006 [Page 6]
Internet-Draft Handover Key Hierarchy from EMSK June 2006
4. Handover Key Hierarchy
A three level key hierarchy is introduced to ensure cryptographical
seperation of different level keys, and also expedites the
distribution of keys between network entities prior to or during a
handover.
+-------+
| EMSK |
+-------+
|
V
+-------+
| rRK |
+-------+
|
V
+-----------------------+
| |
V V
+-------+ +-------+
|R0-Key1| ... |R0-Keyn|
+-------+ +-------+
| |
V V
+-----------+ +-----------+
| | | |
V V V V
+-------+ +-------+ +-------+ +-------+
|R1-Key1|...|R1-Keyn| |R1-Key1|...|R1-Keym|
+-------+ +-------+ +-------+ +-------+
| | | |
V V V V
+-------+ +-------+ +-------+ +-------+
| TSK1 |...| TSKn | | TSK1 |...| TSKm |
+-------+ +-------+ +-------+ +-------+
Figure 2: Fast Handover Key Hierarchy
Key derivation in this hierarchy MUST ensure that compromise of such
keying material is isolated to only that branch of the hierarchy.
As shown in Figure 2, the key hierarchy consists of three levels
(between the EMSK and TSK) whose keys are derived using the KDF (Key
Derivation Function) described in Section 5.
Cao, et al. Expires December 21, 2006 [Page 7]
Internet-Draft Handover Key Hierarchy from EMSK June 2006
o rRK: the re-authentication root key which is a kind of USRK for
roaming. The rRK is mutually derived by the supplicant and the
EAP server, and is never shared with a third party.
o R0-Key: the fist level of the handover key hierarchy; this key is
derived as a function of the rRK and AD-ID and stored by the
Access Domain Controller (ADC). This key is mutually derived by
the supplicant and the ADC. This key is named by the SPA and
AD-ID.
o R1-Key: the second level of the key hierarchy; this key is
mutually derived by the supplicant and the AN. This key is named
by the SPA, AN-ID and AD-ID.
o TSK: the last level of the key hierarchy that defines the EAP
lower layer protection keys. The TSK is the negotiation result
of the Secure Association Protocol. This key is named by SNonce,
ANonce, SPA, AN-ID and AD-ID.
4.1. rRK Derivation and Naming
The rRK is mutually derived by the supplicant and EAP server using
the methods specified in [I-D.eap-emsk-deriv]. That is:
rRK = KDF-USRK(EMSK, key label, optional data, length)
where:
- KDF-USRK is the Key Derivation Function as defined in [I-D.eap-
emsk-deriv]
- key label MAY be a string like "handover@domain". The key label
is intended to provide global uniqueness. Rules for the
allocation of these labels are given in [I-D.eap-emsk-deriv].
- the optional data, with which the KDF-USRK MUST be capable of
processing at least 2048 opaque octets. Here we define the
optional data to "Roaming USRK Derivation"
- The length is a 2 byte unsigned integer in network byte order.
As RECOMMENDED in [I-D.eap-emsk-deriv], the rRK is 64 octets long.
rRK is named and referenced as follows:
rRK-Name = prf-64( EAP Session-ID, key-label ).
where prf-64 is the first 64 bits from the output.
Cao, et al. Expires December 21, 2006 [Page 8]
Internet-Draft Handover Key Hierarchy from EMSK June 2006
The use of names based on the Session-ID in [I-D.ietf-eap-keying] is
RECOMMENDED.
4.2. R0-Key Derivation and Naming
The R0-Key is the top level 256 bit keying material used to derive
the next level keys (R1-Keys). R0-Key binds the SPA and Access
Domain Identifier.
R0-Key = KDF-256(rRK, "R0 Key Derivation", AD-ID || SPA)
where:
- KDF-256 is the KDF function as defined in Section 5 used to
generate a 256 bit key.
- "R0 Key derivation" is the literal string consisting of the
sequence of letters 'R', '0', ' ', 'K', 'e','y',' ', 'd', 'e',
'r', 'i', 'v', 'a', 't', 'i', 'o', and 'n' (no null terminator).
- AD-ID: The 16 octet identifier that is advertised by an Access
Node to differentiate itself from other ANs.
- SPA: The link layer address of the Supplicant.
We can truncate rRK to 256 bit to meet the requirement of the KDF
defined in Section 5.
R0-Key is named and referenced as follows:
R0Name = Truncate-128(SHA-256(R0-Key || "R0 Key Name" || AD-ID ||
SPA))
where Truncate-128(-) returns the first 128 bits of its argument, and
securely destroys the remainder.
The entity that holds this key typically an Access Domain Controller
(ADC) that is identified by a 16 octet string referred to as the
AD-ID. The advertisement of AD-ID is outside the scope of this
document.
4.3. R1-Key Derivation and Naming
The second level handover key hierarchy. R1-Key is a 256 bit key
used to derive the Transient Session Keys (TSK). R1-Key binds the
SPA, top level and second level key holders.
Cao, et al. Expires December 21, 2006 [Page 9]
Internet-Draft Handover Key Hierarchy from EMSK June 2006
R1-Key = KDF-256(R0-Key, "R1 Key Derivation", AD-ID || AN-ID ||
SPA)
where:
- KDF-256 is the KDF function as defined in Section 5 used to
generate a 256 bit key.
- "R1 Key derivation" is the literal string consisting of the
sequence of letters 'R', '1', ' ', 'K', 'e','y',' ', 'd', 'e',
'r', 'i', 'v', 'a', 't', 'i', 'o', and 'n' (no null terminator).
- AD-ID: The 16 octet identifier that is advertised by an Access
Node to differentiate itself from other ANs.
- AN-ID: The 16 octet identifier that is advertised by an Access
Domain to differentiate itself from other ADs.
- SPA: The link layer address of the Supplicant.
R1-Key is named and referenced as follows:
R1Name = Truncate-128(SHA-256(R0Name || AD-ID || AN-ID || SPA))
where Truncate-128(-) returns the first 128 bits of its argument, and
securely destroys the remainder.
The entity that holds this key typically an Access Node that is
identified by a 16 octet string referred to as the AN-ID. The
advertisement of AN-ID is outside the scope of this document.
4.4. TSK Derivation and Naming
The last level handover key hierarchy. TSK is derived from R1-Key
and used to protect data exchanged after EAP authentication has
successfully completed, using the ciphersuite negotiated between the
supplicant and authenticator as a result of Secure Association
Protocol (SAP) such as 802.11i [802.11i].
TSK = KDF-TSKLen(R1-Key, "TSK Key derivation", SNonce || ANonce ||
AD-ID || AN-ID || SPA)
where:
- KDF-TSKLen is the KDF function as defined in Section 5 used to
generate a TSK of length TSKLen.
Cao, et al. Expires December 21, 2006 [Page 10]
Internet-Draft Handover Key Hierarchy from EMSK June 2006
- TSKlen is the total number of bits to derive, e.g. number of bits
of the TSK. The length is dependent on the negotiated
ciphersuites by SAP.
- "TSK Key derivation" is the literal string consisting of the
sequence of letters 'T', 'S', 'K', ' ', 'K', 'e','y',' ', 'd',
'e', 'r', 'i', 'v', 'a', 't', 'i', 'o', and 'n' (no null
terminator).
- SNonce is a 256 bit random bit string contributed by the
supplicant in the SAP.
- ANonce is a 256 bit random bit string contributed by the
authenticator in the SAP.
The TSK is named and referenced as follows:
TSKName = Truncate-128(SHA-256(R1Name || AD-ID || AN-ID ||SNonce
|| ANonce || SPA))
where Truncate-128(-) returns the first 128 bits of its argument, and
securely destroys the remainder.
Cao, et al. Expires December 21, 2006 [Page 11]
Internet-Draft Handover Key Hierarchy from EMSK June 2006
5. Key Derivation Function
The definition of the KDF (Key Derivation Function) is taken from
802.11r [802.11r].
Algorithm kdf:
Output = KDF-Length (K, label, Context)
Input:
- K, a 256 bit key derivation key
- label, a string identifying the purpose of the keys derived
using this KDF
- Context, a bit string that provides context to identify the
derived key
- Length, the length of the derived key in bits
Output: a length-bit derived key.
result = ""
iterations = (Length+159)/160
do i = 1 to iterations
result = result || HMAC-SHA1(K, i || label || 0x00 || Context
|| Length)
od
return first Length bits of result, and securely delete all unused
bits
Cao, et al. Expires December 21, 2006 [Page 12]
Internet-Draft Handover Key Hierarchy from EMSK June 2006
6. Security Considerations
This document specifies a handover key hierarchy derived from EMSK.
Both the key lifetime, key scope in the hierarchy MUST comply with
EAP keying framework [I-D.ietf-eap-keying]. When the handover
solutions are based on the hierarchy proposed in this document, they
MUST also meet the security requirements present in
[I.D.aaa-hokey-ps].
Cao, et al. Expires December 21, 2006 [Page 13]
Internet-Draft Handover Key Hierarchy from EMSK June 2006
7. IANA Considerations
This specification does not request the creation of any new parameter
registries, nor does it require any other IANA assignments.
Cao, et al. Expires December 21, 2006 [Page 14]
Internet-Draft Handover Key Hierarchy from EMSK June 2006
8. Acknowledgement
TBD.
9. Reference
[802.11i] Institute of Electrical and Electronics Engineer, "IEEE
Standard for Information technology!a Telecommunications
and information exchange between systems!aLocal and
metropolitan area networks!aSpecific requirements. Part
11: Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) specifications. Amendment 6: Medium Access
Control (MAC) Security Enhancements", July 2004, <IEEE
std. 802.11i>.
[802.11r] Institute of Electrical and Electronics Engineer, "Draft
Amendment to STANDARD FOR Information Technology -
Telecommunications and Information Exchange Between
Systems - LAN/MAN Specific Requirements. Part 11:Wireless
LAN Medium Access Control (MAC) and Physical Layer (PHY)
Specifications: Amendment 2: Fast BSS Transition",
May 2006, <IEEE std. 802.11r/D2.1>.
[I-D.eap-emsk-deriv]
Salowey, J. and et. al, "Specification for the Derivation
of Usage Specific Root Keys (USRK) from an Extended
Master Session Key (EMSK)",
<draft-salowey-eap-emsk-deriv-00.txt (work in progress)>.
[I-D.ietf-eap-keying]
Aboba, B., "Extensible Authentication Protocol (EAP) Key
Management Framework", <draft-ietf-eap-keying-13.txt (work
in progress)>.
[I.D.aaa-hokey-ps]
Nakhjiri, M., Parthasarathy, M., and al. et, "AAA based
Keying for Wireless Handovers: Problem Statement",
May 2005, <draft-nakhjiri-aaa-hokey-ps-02.txt (work in
progress)>.
[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.
Cao, et al. Expires December 21, 2006 [Page 15]
Internet-Draft Handover Key Hierarchy from EMSK June 2006
Appendix A. Intra-ADC Handover
Following and for the sake of clarity, we first explain an intra
Access Domain Controller (ADC) handover example. The example is
based on Figure 1 explained in Section 3.
Initially, when the MN connects to the access network for the first
time (through AN1), it can use EAP to authenticate to the access
network. This EAP authentication generates EMSK which in turn is to
derive the handover root key (rRK) specified in Section 4.1.
The AAA server generates the R0-Keys and then forwards them to the
Access Domain Controllers in different Access Domains (AD). The ADC
then generates R1-Keys and distributes them to different Access Nodes
on the lower layer of the hierarchy. In the end, the MN and AN1
mutually derive the TSK for data protection between the MN and AN1.
When the MN handovers to another Access Node (e.g. AN2) under the
control of ADC1 , a new security association SHOULD be established
before any application data communication occurs. If the R0-Key from
the previous authentication does not expire, the MN SHALL associate
with AN2 and mutually derive R1-Key from R0-Key. Mutual proof of
possession of R1-Key and mutual derivation of TSK from R1-Key are
both provided by the Secure Asscociation Protocol (SAP). In this way
new SA is established without another EAP exchange.
If the R0-Key from the previous authentication expires, the MN MUST
authenticate to the access network through AN2 with a full EAP
exchange.
Cao, et al. Expires December 21, 2006 [Page 16]
Internet-Draft Handover Key Hierarchy from EMSK June 2006
Appendix B. Inter-ADC Handover
Following and for the sake of clarity, we then explain an inter
Access Domain Controller (ADC) handover example. The example is
based on Figure 1 explained in Section 3.
Initially, the MN connects the AN1 under control of ADC1, the same
things happen as described in Appendix A.
This time, the MN handovers to AN3 that is under control of ADC2. If
the R0-Key associated with ADC2 does not expire, the Secure
Association Protocol will take the responsibility of the
establishment of the new SA between the MN and AN3.
If the R0-Key from the previous authentication expires, the MN MUST
authenticate to the access network through AN3 with a full EAP
exchange.
Cao, et al. Expires December 21, 2006 [Page 17]
Internet-Draft Handover Key Hierarchy from EMSK June 2006
Authors' Addresses
Zhen Cao
Peking University
No.1 Science Building Room 1534
5 Yi He Yuan Lu
Hai Dian District
Beijing 100871
China
Email: caozhen@pku.edu.cn
Yuanchen Ma
Hitachi (China)
Beijing Fortune Bldg. 1701
5 Dong San Huan Bei-Lu
Chao Yang District
Beijing 100004
China
Email: ycma@hitachi.cn
Hui Deng
Hitachi (China)
Beijing Fortune Bldg. 1701
5 Dong San Huan Bei-Lu
Chao Yang District
Beijing 100004
China
Email: hdeng@hitachi.cn
Qin Li
BeiHang University
Department of Computer Science
Beijing 100083
China
Email: quinn.liqin@gmail.com
Cao, et al. Expires December 21, 2006 [Page 18]
Internet-Draft Handover Key Hierarchy from EMSK June 2006
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Cao, et al. Expires December 21, 2006 [Page 19]
