Network Working Group M. Nakhjiri
Internet-Draft Motorola Labs
Expires: August 14, 2006 February 10, 2006
A Keying hierarchy for managing Wireless Handover security
draft-nakhjiri-hokey-hierarchy-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 August 14, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The Problem of AAA-based key management for faciliating secure
handovers in a wireless mobile environment has been described in
[I-D.nakhjiri-aaa-hokey-ps]. The intention with this document is to
provide a starting point for developing a solution for that problem
by introducing a key hierarchy using EAP generated keys.
Nakhjiri Expires August 14, 2006 [Page 1]
Internet-Draft Handover Keying Hierarchy Description February 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Assumptions . . . . . . . . . . . . . . . . . 5
3. Key Hierarchy and Generation . . . . . . . . . . . . . . . . . 6
4. Security report Card . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . . 11
8.2. Informative references . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Nakhjiri Expires August 14, 2006 [Page 2]
Internet-Draft Handover Keying Hierarchy Description February 2006
1. Introduction
Wireless networks deploy specific access nodes (AN) providing link
layer service to the peers. While the primary function of the AN is
provide network connectivity and operator policy enforcement on the
services rendered, it can do so only after the required
authentication and security procedures are successfully performed.
This typically involves exchange of authentication signaling between
the peer and a backend AAA server through the AN and provisioning of
keys for securing the link between the peer and the AN.
The Extensible Authentication Protocol (EAP) framework, including
[RFC3748] and the keying framework [I-D.ietf-eap-keying] have been
used to perform authentication and to generate the EAP master keys
(MSK and EMSK) at both backend server and the peer. The EAP
framework also allows transport of MSK to a pass-through
authenticator and recommends this transport be done through a AAA
protocol. When the AN implements the authenticator and AAA client
function, it can then after receiving the MSK engage in a key
management schema with the peer to establish a secure link with the
peer.
The process described above may be sufficient in an environment where
the authentication, AAA client and AN are co-located and the peer
does not have move between different ANs. However, it will cause
difficulties when those conditions do not apply. If the MSK is
transported to an AN, when the peer moves to another AN, using the
same MSK at the new AN will violate the principle of least privilage
[I-D.housley-aaa-key-mgmt] and can result in a so-called domino
effect. Creating a new MSK at the new AN, on the other hand could
require performance of another round of lengthy EAP method
authentication exchange, which is detrimental to handover
performance, especially when real time services are in active
session.
As described in [I-D.nakhjiri-aaa-hokey-ps] an architecture deploying
a key holder, KH, (shown in Figure 1) that can act as a AAA client
and receive the master keys transmitted by the AAA server seems to
gain more acceptance in the industry due to its strength in
addressing this issue more effectively.
EAP working group is currently working on specification of
methodology [I-D.ietf-eap-keying] that allows the use of EAP method
generated master keys (MSK and EMSK) in assisting AAA-based key
management procedures. The notion of application master session key
(AMSK) has been recognized as a useful concept. While some basic
tenets about AMSK use has been discussed in IETF EAP WG, the process
of AMSK generation, caching and distribution is not yet standardized
Nakhjiri Expires August 14, 2006 [Page 3]
Internet-Draft Handover Keying Hierarchy Description February 2006
in IETF.
In the handover problem description document
[I-D.nakhjiri-aaa-hokey-ps] we tried to reduce the dependency of a
handover keying solution to the AMSK for that reason by introducing
the notion of XMSK as the master key that is pushed/pulled into each
key holder. Distinguishing between AMSK and XMSK serves two notions:
1) from one AMSK generated for handover, multiple XMSKs (one for each
key holder, KH) can be generated. This way the architecture is
capable of supporting Inter-KH handovers if need be. At the same
time it can comply with the concern that only the AMSK and not the
EMSK can be available at the AAA server, while the EMSK needs to stay
(or possibly deleted) at the EAP server. 2) The XMSK, created at the
AAA server for key holder and transported to the each KH, can be
deleted from AAA server cache, if required. The AMSK can on the
other stay at the AAA server for future use (such as XMSK generation
for other, not currently identified KHs).
Nakhjiri Expires August 14, 2006 [Page 4]
Internet-Draft Handover Keying Hierarchy Description February 2006
(HO-AMSK,HO-AAA-REAUTH-KEY)
<-------------------------------------------->
(XMSK,HO-KH-REAUTH-KEY)
<---------------------------->
LSK,LSAP-MK
<------------>
+-+-+-+-+-+LSK +-+-+-+ LSAP-MK1
| MN/ |-----| AN11|---+
|EAP Peer | +-+-+-+ | +-+-+-+
+-+-+-+-+-+ +-----|KH 1 |-+XMSK1
+-----+ | +-----+ |
| AN12|---|LSAP-MK2 ^
+-----+ | |
. | |
. | | +-+-+-+-+-+
+-+-+-+ | | |AAA/EAP |
| AN1n|---+ +--+--| Server |
+-+-+-+ | +---------+
|
+-+-+-+ +-----+ |
| AN21|---------|kH 2 |----+XMSK2
+-+-+-+ +-+-+-+ |
. . |
. . |
+-+-+-+ +-----+ |
| ANm1|---------|kH m |----+ XMSK3
+-+-+-+ +-+-+-+
. |
. |
+-+-+-+ |
| ANmk|-----------+
+-+-+-+
Figure 1: A keying architecture deploying key holders
This document intends to provide an example of how the various keys
in handover keying architecture shown in figure Figure 1 can be
generated. The document leaves the transport aspects of the key
distribution for future discussion. Some of our key binding ideas
may be self-evident through inclusion of various identifiers in the
expressions provided for generation of various keys, however, these
expression will need to examined more closely through further
discussions.
2. Terminology and Assumptions
Nakhjiri Expires August 14, 2006 [Page 5]
Internet-Draft Handover Keying Hierarchy Description February 2006
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].
For a complete description of the terminology, the reader is referred
to [I-D.nakhjiri-aaa-hokey-ps]
X-Master Session Key (XMSK): A key that will be used as the root key
to solve the handover keying problem.
Link Secure Association Protocol (LSAP): The term Link Secure
Association Protocol refers to the process used between the peer
and the AN to generate and manage the security associations used
to protect the peer-AN link (layer 2 or layer 3). The LSAP
protocol uses LSAP-MK (below) as a root key and arrives at LSKs.
LSAP Master key (LSAP-MK): The master key used by the peer and the AN
during LSAP run to arrive at LSKs between the peer and the AN.
LSAP-MK is derived from XMSK through one or more steps in ways to
be explored.
Link Session Keys (LSK): The keys derived upon completion of LSAP and
used to secure the access link between the peer and the AN. In a
special case, where the AN and the authenticator are co-located
and use the same identifiers.
3. Key Hierarchy and Generation
Upon successful completion of the EAP authentiation method, the EAP
server generates the EAP MSK and EMSK as defined by the method that
was executed. From this EMSK, an AMSK designated for handover keying
application can be generated. We call this AMSK, the HO-AMSK
HO-AMSK=AMSK-PRF (EMSK, "AMSK for Handover" | EAP session ID | Key_ID
| AAA server ID)
EAP session ID is supposed to be unique between peer and the server,
identified by the peer-ID and EAP server ID, respectively.
The current assumption is that the EMSK cannot be exported from the
EAP layer down to the AAA layer, but the HO-AMSK can. Hence from
this point, we assume that the AAA server can maintain a cache of HO-
AMSK if it needs to. The HO-AMSK is then used to create further
keys:
HO-AAA-REAUTH-KEY= HO-PRF (HO-AMSK, "Key for re-authentication to AAA
server" | EAP session ID | Key_ID )
Nakhjiri Expires August 14, 2006 [Page 6]
Internet-Draft Handover Keying Hierarchy Description February 2006
KH-MK= HO-PRF (AMSK, "master Key for all key holders" | EAP session
ID | Key_ID )
HO-AAA-REAUTH-KEY is a key that can be used by the peer, if it needs
to indicate to the AAA server that it has moved to an area served by
a new key holder. The key allows for a quick re-authorization
process in the course of inter-KH handover, without requiring a new
EAP. Proof of possession of this key, authorizes the peer to receive
key generation services through a new key holder. Note that the peer
may not necessarily need to know that it has moved to a new key
holder; the AAA server can request proof of possession of this key
through a request. HO-AAA-REAUTH-KEY does not leave the AAA server
and is not exposed to any other entity in the network. The peer is
able to generate this key through knowledge of AMSK.
KH-MK is a key that does not leave the AAA server and is used by the
AAA server as a root key when generating XMSK for a key holder number
i:
XMSK for KH i= XMSKi= KH-i-MK=
HO-PRF (KH-MK, "XMSK generation" | EAP session ID | Key ID | Key
holder i ID)
Note that the peer may not have knowledge of the key holder
identifier, hence some sort of domain identifier corresponding to the
key holder needs to be used. Such domain identifiers can be
broadcast through the advertisements provided by the AN to the peer.
The AAA server now can send the XMSKi to the key holder i through a
secure transport (possibly a secured AAA message). The AAA server
can now delete the XMSKi, if required for compliance with principle
of least privilage.
The key holder i (KHi) receives the XMSKi. From this point on, we
refer to this key as XMSK or XMSK-current to comply with the
description provided in the handover keying problem description
[I-D.nakhjiri-aaa-hokey-ps]
The XMSK is meant to be cached at the key holder and not distributed
to any other entities. The key holder uses the XMSK as for all the
key generation activities within its domain (i.e. for all the ANs it
serves). In the following we assume key holder i is the key holder 1
shown Figure 1) and the first AN the peer is connecting to is AN1.
So the KH1 creates the LSAP-MK1 for the (peer-AN1) interaction as
follows:
LSAP-MK1 = LSAPMK-PRF (XMSK-i, "LSAP master key generation" | EAP
Nakhjiri Expires August 14, 2006 [Page 7]
Internet-Draft Handover Keying Hierarchy Description February 2006
Session ID | Key-ID | AN1-Device-Id)
The LSAP-MK1 is transported to the AN1 through a secure transport at
some point in conjunction to the handover
To maintain a level of integrity in the design, we provision another
authorization key (we call this HO-KH-REAUTH-KEY) so that the peer
can use this key to gain authorization from the key holder to
handover to another key. The need for proof of possession of this
key as part of handover is to be tested later on, but its
provisioning eliminates the need for interaction with the backend AAA
server (e.g. fast re-authentication procedures with the AAA server).
The KO-KH-REAUTH-KEY can be calculated as follows:
HO-KH-REAUTH-KEY= HO-PRF (XMSK, "Key for re-authentication to key
holder" | EAP session ID | Key_ID )
Once the LSAP-MK1 is obtained by the AN1, the peer and AN1 can engage
in an LSAP exchange to arrive at the LSKs. The exact process of LSAP
is dictated by the SDO governing the specification of the
communications link between the peer and ANs. So the following is
simply an example:
LSK-encryption=LSK-PRF (LSAP-MK1, "Link encryption key", EAP session
ID | Key ID | peer-link-ID | AN-link-ID | peer-nonce | AN1-nonce),
LSK-Authentication=LSK-PRF (LSAP-MK1, "Link authentication key", EAP
session ID | Key ID | peer-link-ID | AN1-link-ID | peer-nonce | AN-
nonce),
Where the nonces are exchanged as part of an exchange between the
peer and AN1. The link IDs are the identifiers through which the
peer and the AN recognize each other over the wireless link.
As the mobile node hands off from AN1 to another AN, through some
method that we do not discuss at this point, the key holder is
notified about the move and about the device ID of AN2. The Key
holder may require proof of possession of the HO-KH-REAUTH-KEY from
the peer. The key holder calculates the LSAP-MK2 for the AN2:
LSAP-MK2 = LSAPMK-PRF (XMSK-i, "LSAP master key generation" | EAP
Session ID | Key-ID | AN2-Device-Id)
and transports the LSAP-MK2 to AN2, which engages in LSAP with the
peer as described earlier.
The details of the signaling are to be explored later. For instance
the timing and triggers for various authorization messaging or keying
Nakhjiri Expires August 14, 2006 [Page 8]
Internet-Draft Handover Keying Hierarchy Description February 2006
material transport needs to be fine tuned based on the physical
conditions of the (peer-AN1), (peer-AN2) and (AN1, AN2) links.
For instance, authorization request for handover to AN2 and even
LSAP-MK2 transport may happen prior to or following a handover to
AN2. The former is for instance possible through the KH encrypting
and signing the keying material for the AN2 through a (KH-AN2) shared
key and sending it to the AN1, which then can through a simple
context transfer move to the AN2, without much security requirements.
transfer.
Another example is if the AN or the peer could request LSAP-MKs for a
list of candidate ANs as part of the request to the key holder. The
key holder could then send signed (peer ID, AN-ID,
encrypted(LSAP-MK)) triplets for each of the ANs.
Finally, As discussed in the problem statement draft, a key holder
seems to be a necessary part of the architecture. However, the
realization of this architecture can take various shapes. the
recommendation here is to use the following architecture to use EAP
keying framework.
+-+-+-+-+-+
| Key Hldr|
| AAAC |-----+
+-+-+-+-+-+ \
| \
| \
V \
+-+-+-+-+ +-+-+-+-+-+ \ +-+-+-+-+-+
| | | Athr | +-| |
| EAP |--------| AAAC |------------| EAP/AAA |
| Peer | | AN | | Server |
+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
Figure 2: off-EAP-path key holder function
4. Security report Card
This section of the document provides a test of the provided key
hierarchy agains the security goals stated in the kandover keying
problem statement draft [I-D.nakhjiri-aaa-hokey-ps]
Nakhjiri Expires August 14, 2006 [Page 9]
Internet-Draft Handover Keying Hierarchy Description February 2006
Key Context and scope, prevention of domino effect: The context
and scope for each key is defined. The entire purpose of the
hierarchy is to abide with the principle of least privilage to
prevent the domino effect. Master keys are deleted after
transport. Keys generated at each level of the hierarchy are
unique to entities. for instance, XMSK for each key holder is only
specific to that key holder, the same as LSAP-MK for each AN.
Key Naming: All keying material starting from XMSK and the
derivatives are uniquely named, using the identity of the parties
sharing the key.
Key Freshness: Use of EAP session ID should provide adequate level
of freshness, in cases where the identity of an entity within the
architecture is not known to the peer and in case of LSAP-MK
generation. Generation of link level keys (LSKs) is outside
control of IETF. The examples provided in this document, use peer
and AN nonces for that purpose.
Handover Vulnerabilities: The key hierarchy introduced here,
provides a hierarchy in authorization as well, e.g. HO-AAA-
REAUTH-KEY versus HO-KH-REAUTH-KEY. This way, the entity that
generates the keys is making the authorization decisions.
Authentication of all the parties: The hierarchy allows for peer-
AAA server, peer-key holder and peer-AN authentication through
introduction of specific keys. AAA server-key holder, key
holder-AN authentication mechanisms are outside control of this
document.
Channel binding: The keys introduced in this document are named in
a way that allows for proper binding. Exact signaling procedures
for channel binding are to be investigated.
EAP method independence: The key hierarchy in this document stems
from the EAP method generated keys (MSK and EMSK). As long as the
method is capable of creating EMSKs, this hierarchy is method
independent.
5. Security Considerations
This document discusses branching a key hierarchy from root keys
provided by the EAP key management in order for providing keying
solutions for wireless mobile networks. Key caching and non-
transport requirements (i.e. storing a key at the origin without
transporting it) are discussed throughout the document. However, the
solution relies on the secure (encrypted and authenticated) transport
of keys. Such secure transport of keying material between pairs such
as (AAA server, key holder) and (key holder, AN) may be subject to
security issues that are outside control of this docuemnt. Future
revisions of this document is to provide recommendations for the
transport mechanisms.
Nakhjiri Expires August 14, 2006 [Page 10]
Internet-Draft Handover Keying Hierarchy Description February 2006
6. IANA consideration
This document does not require any actions by IANA.
7. Acknowledgements
The authors would like to thank Jari Arrko for useful suggestions on
use of AMSK for handover key hierarchy and Mohan Parthasarathy for
providing feedback.
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-eap-keying]
Aboba, B., "Extensible Authentication Protocol (EAP) Key
Management Framework", draft-ietf-eap-keying-09 (work in
progress), January 2006.
[I-D.nakhjiri-aaa-hokey-ps]
Nakhjiri, M., "AAA based Keying for Wireless Handovers:
Problem Statement", draft-nakhjiri-aaa-hokey-ps-01 (work
in progress), January 2006.
8.2. Informative references
[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.
[I-D.housley-aaa-key-mgmt]
Housley, R. and B. Aboba, "Guidance for AAA Key
Management", draft-housley-aaa-key-mgmt-01 (work in
progress), November 2005.
Nakhjiri Expires August 14, 2006 [Page 11]
Internet-Draft Handover Keying Hierarchy Description February 2006
[I-D.arkko-eap-service-identity-auth]
Arkko, J. and P. Eronen, "Authenticated Service
Information for the Extensible Authentication Protocol
(EAP)", draft-arkko-eap-service-identity-auth-04 (work in
progress), October 2005.
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible
Authentication Protocol (EAP) Method Requirements for
Wireless LANs", RFC 4017, March 2005.
Nakhjiri Expires August 14, 2006 [Page 12]
Internet-Draft Handover Keying Hierarchy Description February 2006
Author's Address
Madjid Nakhjiri
Motorola Labs
Email: Madjid.nakhjiri@motorola.com
Nakhjiri Expires August 14, 2006 [Page 13]
Internet-Draft Handover Keying Hierarchy Description February 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.
Nakhjiri Expires August 14, 2006 [Page 14]