Internet DRAFT - draft-nakhjiri-aaa-hokey-ps
draft-nakhjiri-aaa-hokey-ps
Network Working Group M. Nakhjiri
Internet-Draft Motorola Labs
Expires: December 25, 2006 M. Parthasarathy
Nokia
J. Bournelle
GET/INT
H. Tschofenig
Siemens
R. Marin Lopez(Ed.)
TARI
June 23, 2006
AAA based Keying for Wireless Handovers: Problem Statement
draft-nakhjiri-aaa-hokey-ps-03
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 25, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The Extensible Authentication Protocol (EAP) provides a framework for
Nakhjiri, et al. Expires December 25, 2006 [Page 1]
Internet-Draft EAP Keying Handovers: PS June 2006
performing authentication and key management using the AAA
infrastructure. The framework deals with a model which includes a
peer, a pass-through authenticator and a backend authentication
server.
Some of the emerging mobile networks use EAP in handover scenarios in
ways that go beyond currently defined EAP keying framework. This
document provides a problem statement for the usage of EAP in these
emerging mobile networks.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Assumptions . . . . . . . . . . . . . . . . . 4
3. Problem Description . . . . . . . . . . . . . . . . . . . . . 6
4. Security Goals . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Key Context and scope, prevention of domino effect . . . . 11
4.2. Key Naming . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3. Key Freshness . . . . . . . . . . . . . . . . . . . . . . 12
4.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 13
4.5. Authentication of all the parties . . . . . . . . . . . . 13
4.6. Channel Binding . . . . . . . . . . . . . . . . . . . . . 13
4.7. EAP method independence . . . . . . . . . . . . . . . . . 14
4.8. Transport aspects . . . . . . . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 14
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
8.2. Informative references . . . . . . . . . . . . . . . . . . 15
Appendix A. Intra-ADC handover example . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19
Nakhjiri, et al. Expires December 25, 2006 [Page 2]
Internet-Draft EAP Keying Handovers: PS June 2006
1. Introduction
The Extensible Authentication Protocol (EAP) [RFC3748] and the keying
framework [I-D.ietf-eap-keying] documents define an authentication
and key management framework. These specifications define how an EAP
method can be executed between a peer and an EAP server (typically
located at the Home AAA server) through a pass-through authenticator
and explain the key management. EAP Keying framework provide
guidelines for generation of the keying material (MSK in EAP
documents), at the EAP peer and the EAP/AAA servers. It also
discusses transfer of this keying material to a pass-through
authenticator for the purpose of further securing access links (i.e.
deriving transient session keys (TSKs) through the Secure Association
protocol (SAP) as described in [I-D.ietf-eap-keying]) to secure the
link between the peer and the authenticator.
Given that the TSK MAY be bound to particular access link, handover
between different access links would require generation of new TSKs.
Wireless networks deploy specific Access Nodes (ANs) providing link
layer service to the peers, where the ANs are typically defined as
separate elements from the element that controls them. On the other
hand, mapping between those functional elements and the functional
elements defined in EAP keying framework such as authenticator and
authenticator ports has not been clear. This makes the applicability
of EAP keying framework to each wireless technology difficult. As a
result, existing wireless technologies had to create their own
mappings as follows:
o 802.11r [802.11r] has introduced the concept of the key holders
and two levels of key hierarchy between the MSK sent from the AAA
server and the TSKs (called Pairwise Transient Key, PTK in
802.11r) to avoid the need for generation of new MSKs in
conjunction with each AN-handover. The two levels are PMK-R0 and
PMK-R1 (PMK stands for Pairwise Master Key). The PMK-R0 is
created based on MSK and is held at a so-called PMK-R0 key holder,
while the PMK-R1 created from PMK-R0 and is kept at a PMK-R1
holder. This way the PMK-R0 key holder can create master keys
(PMK-R1) for all the access points (AP) it is serving.
o WiMAX (supporting organization for 802.16e) has introduced a two-
part authenticator function, in which one part acts as a key
holder, receiving the MSK from AAA server and calculating keys
specific to ANs, while the other part residing at the AN acts as
an authenticator relay and key receiver that receives the master
keys for link security (authorization key, AK).
In either case, it seems that these SDOs have recognized that the EAP
keying model where the EAP server simply sends the MSK to the pass-
Nakhjiri, et al. Expires December 25, 2006 [Page 3]
Internet-Draft EAP Keying Handovers: PS June 2006
through authenticator to which the EAP peer is directly connected to
is not sufficient to succinctly design a keying solution for a mobile
wireless environment even in cases where the peer hands over between
access nodes that are all served by the same authenticator. What is
even more important to note is that neither of these SDOs have
provided a method for inter-authenticator handovers.
Given that various standard bodies are extending EAP keying framework
in different ways to solve the wireless mobility keying for intra-
authenticator handovers and given that most of these standards do not
deal with inter-authenticator handovers, it seems appropriate to
develop a comprehensive handover keying solutions that deals with
various types of handovers within IETF. This document intends to
provide a problem statement for handover keying. It also describing
the security goals that the specification needs to meet.
2. Terminology and Assumptions
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].
Most of the terminology found in this document uses the EAP keying
document [I-D.ietf-eap-keying]. However, this document defines new
terms in place of several terms defined in EAP keying framework in
order to clearly describe the handover keying problem. Since
wireless technologies that support handover have the architecture of
physically or logically separating network attachment points from the
controller of the network attachment points, it is more reasonable,
than re-using the existing terms, to define the network attachment
points as separate elements from the authenticator and other new
terms that are closely related to this separation of authenticator
and authenticator ports defined in [I-D.ietf-eap-keying].
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.
EAP server: The EAP server in handover keying has the same
functionality of a backend EAP server in [RFC3748] and [I-D.ietf-
eap-keying], i.e, the EAP server terminates the EAP authentication
method with peer through a pass-through authenticator and can
perform keying functions.
Nakhjiri, et al. Expires December 25, 2006 [Page 4]
Internet-Draft EAP Keying Handovers: PS June 2006
EAP pass-through authenticator: The pass-through authenticator is the
entity between a peer and a backend EAP server that is passing
through EAP Request and Response messages ([RFC3748]) without
understanding their data content. It can understand EAP success
and failure messages. The role of pass-through authenticator
during EAP authentication is defined in [RFC3748].
Access Domain Controller: Entity responsible for keying needs within
an Access Domain. ADC holds a per-ADC specific ADMSK for the
authentication domain and uses this ADMSK to derive new LSAP-MK
for different ANs under its control.
Access Domain (AD): A domain whose authentication (with the backend
EAP/AAA server) and key management goes through the same ADC.
Mobile Node (MN) (peer): The entity that receives network access
through an Access Node--> and acts as an EAP peer functionality as
described by [RFC3748] and EAP keying framework [I-D.ietf-eap-
keying], with the exception that mobile node may not have a direct
link to the EAP pass-through authenticator. In this document we
use the terms MN and EAP peer interchangeably.
SA: Security Association.
Handover Root Key (HRK): A key that will be used as the root key to
solve the handover keying problem. We assume that the HRK is
generated as a result of a successful EAP authentication and
keying process and will be available at both the peer and the Home
AAA server. Whether the EAP generated MSK or an AMSK (generated
from EMSK) is used as HRK as the root key is to be determined
later on. In the rest of this document, we will only refer to
HRK.
Access Domain Master Session Key (ADMSK): A key that is sent to each
Access Domain Controller (or the key holder function within the
ADC) that is unique for that ADC and can be used for a root key
for generation further lower level keys within the domain served
by the ADC.
Link Secure Association Protocol (LSAP): In a general case, the
authenticator function is not located at the AN. 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). We
introduce this term to avoid confusion with term Secure
Association Protocol (SAP) defined in [I-D.ietf-eap-keying] that
runs between the peer and the authenticator. The LSAP protocol
Nakhjiri, et al. Expires December 25, 2006 [Page 5]
Internet-Draft EAP Keying Handovers: PS June 2006
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 ADMSK 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, the LSKs in this document and the
transient session keys (TSK) in [I-D.ietf-eap-keying] may become
the same.
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).
3. Problem Description
As mentioned earlier, in wireless access networks, where the peer
hands off between various ANs, using the keying model described in
EAP authentication and key management framework causes some
difficulties in achieving optimized handovers.
As shown in Figure 1, it is more appropriate to consider a functional
model, where a functional entity (we have used the term
Authentication Domain Controller) other than the AN holds the master
key sent from the AAA server and generates per AN master keys for
each AN.
+-+-+-+-+-+ +-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| MN/ |-----| AN |---| ADC |----|EAP/AAA server |
|EAP Peer | +-+-+-+ | | +-+-+-+-+-+-+-+-+
+-+-+-+-+-+ +-+-+-+-+-+-+-+
Figure 1: Wireless access network with separate AN and Access Domain
Controller(ADC)
Important note: EAP pass-through authenticator plays an important
role in execution of EAP authentications in a deployments employing
central EAP and AAA servers. EAP keying also provides specifications
and requirements for a pass-through authenticator. As the handover
Nakhjiri, et al. Expires December 25, 2006 [Page 6]
Internet-Draft EAP Keying Handovers: PS June 2006
keying only uses the results of a previously performed EAP
authentication, the significance and function of pass-through
authenticator in the handover keying process (reception and/or
caching of keys, further derivation, and distribution) may be of less
importance. The expected behavior of a pass-through authenticator as
well as its placement with respect to access domain controller needs
to be investigated, but it is expected that handover keying channel
binding solutions may be different than that required for EAP keying.
For this reason, we will refer to inter-access domain and intra-
access domain handovers instead of inter-authenticator and intra-
authenticators respectively.
Using EAP keying framework on this new architecture model poses some
design issues in two main cases analyzed following:
o Inter-Access Domain Controller handovers: Most of the modern EAP
methods create both an Master Session Key (MSK) and an Extended
Master Session Key (EMSK) upon a success authentication. Most of
existing access technologies that use EAP keying transport MSK to
the authenticator (as suggested by the current EAP keying
framework). This means they cannot support inter-authenticator
handover without depending on either an authenticator-anchoring or
a key context transfer from one authenticator to the next. The
anchoring would cause practical limitations in high speed mobility
environments, while the context transfer will potentially suffer
from the domino effect (see [I-D.housley-aaa-key-mgmt]), where the
compromise of a single authenticator may lead to the compromise of
series. Writing off those two options, handing over to another
authenticator would require generation of another MSK for the new
authenticator (and thus a new EAP authentication). A new key
hierarchy should be developed in a way that handover to a new
authenticator does not require a new full EAP authentication.
This for instance could be achieved by generating lower level keys
(called ADMSK) for each access domain from the HRK. The AAA
server will then transport the ADMSKs to the entity responsible
for keying within the access domain. Since this functionality is
different from the behavior described for the "pass-through
authenticator" within EAP document, we have called this entity the
Access Domain Controller (ADC), even though an ADC will with high
likelihood include pass-through authenticator functionality that
assists the peer with its EAP authentications.
o Intra-Access Domain Controller handovers: The current EAP keying
framework does not specify keying details for topologies where
multiple ANs are grouped under one pass-through authenticator.
The need for separation of master keys at the pass-through
authenticator/ADC (ADMSK delivered from AAA server) and master
keys used for LSAP exchange (called LSAP_MK in this draft) has
Nakhjiri, et al. Expires December 25, 2006 [Page 7]
Internet-Draft EAP Keying Handovers: PS June 2006
been recognized in several SDOs, such as IEEE 802.11r, 802.16e and
WiMAX. The notion of authenticator ports are now being discussed
to deal with this issue. Each AN can correspond to an
authenticator port that may or may not physically be separated
from the authenticator function. However, introducing the notion
of authenticator-port alone does not deal with issues related to
derivation of AN-specific master keys (LSAP_MK) from ADMSK,
including key scoping and channel binding issues. Furthermore, it
does not solve the delicate problem of the delivery of LSAP_MK
from pass-through authenticator/ADC to the AN.
Given both types of handover, some additional issues needs to be
considered:
o Choice of HRK: As mentioned, the inter-authenticator handover
scenario would require that per-authenticator (per-ADC) keys
(ADMSK) would be different from the top level key (HRK) generated
as part of/or as a result of an EAP authentication MSK. Since EAP
methods only generate an MSK and an EMSK, and EMSK is not
transportable and possibly not exportable from the EAP server,
either a MSK or an AMSK generated from the EMSK (as described in
[I-D.salowey-eap-emsk-deriv]) are two choices for HRK. It should
also be noted that at EAP keying framework has required the
transported keys to be deleted after transport. Choosing MSK as
the root for handover keying key hierarchy (HRK) would mean the
MSK can no longer be sent to any authenticator and this would mean
MSK usage would be different in EAP and handover keying solutions.
Choosing AMSK would not cause any backward compatibility (by
redefining previous usage of MSK) but would require generation of
a specification on how AMSK needs to be generated from EMSK.
o Fast Re-authentication: The EAP keying framework does not provide
guidance on fast re-authentication process based on generated keys
as a consequence of a previous EAP authentication without running
a new EAP authentication that would help to improve handover
process.
This would lead us to the following minimum architecture to realize
the handover keying solution (note that, in the Figure 2 we name the
authenticator as Authentication Domain Controller or ADC):
Nakhjiri, et al. Expires December 25, 2006 [Page 8]
Internet-Draft EAP Keying Handovers: PS June 2006
SA1
<----------------------------------------------------->
SA12
<----------------------------------------------------->
SA4 SA3 SA2
<----------> <---------------> <---------------------->
SA5
<---------------------------->
(LSAP-MK)
+-+-+-+-+-+ +-+-+-+
| MN/ |-----| AN1 |---+ (ADMSK1)
|EAP Peer | +-+-+-+ | +--------------+
+-+-+-+-+-+ ^ +-----|ADC1(AUTH_KH) |---+
| SA6 | +--------------+ |
| | | (HRK)
V | | +-+-+-+-+-+
+-+-+-+ | | |AAA/EAP |
| AN2 |---+ +-+---| Server |
+-+-+-+ | +---------+
(ADMSK2) |
+-+-+-+ +--------------+ |
| AN 3|---------|ADC2(AUTH_KH) |-----+
+-+-+-+ +--------------+
Figure 2: A wireless handover keying architecture deploying EAP
As it can be seen in the Figure 2, the EAP pass-through authenticator
is not specified in any particular place. Placing the pass-through
authenticator in the AN is acceptable, as long as the AN is able to
encapsulate the EAP signaling into AAA signaling and the ADC is able
to act as a AAA proxy for AAA signaling. Placing the EAP pass-
through authenticator in the ADC will possibly require specific
considerations in the transfer of EAP signaling from the peer over
the AN and the ADC to the EAP server. In any case, and as it has
been mentioned previously, this will need further study.
Note that, it is assumed that the Home AAA server (AAAH) and the EAP
server are co-located within the same physical device and possibly
interact through internal mechanism, and therefore can be considered
as one trusted party.
As it can also be noted, this document introduces certain Key Holder
(AUTH_KH) and key distribution functionality into the Authentication
Domain Controller (ADC). As mentioned earlier, EAP keying
specification has required of a AAA entity (either a AAA server or a
AAA client) to delete a key (such as ADMSK) after transport. To
Nakhjiri, et al. Expires December 25, 2006 [Page 9]
Internet-Draft EAP Keying Handovers: PS June 2006
accommodate such requirements a few things are required:
1. A per-ADC ADMSK must be generated from HRK and transported to the
ADC instead of the HRK (to comply with the delete after transport
requirement).
2. A stateless AAA server (such as RADIUS server) may also have a
Key Holder (AAA_KH) function that caches the HRK.
Finally and for completion, various security associations (SA)
between the architecture entities shown in Figure 2 are described
below:
1. SA1 is a long term credential established between the MN and the
Home AAA server and used for EAP authentication. Provisioning of
SA1 is outside scope.
2. SA12 is generated as a result of the EAP authentication between
EAP peer and EAP server. For the purpose of handover keying,
SA12 consists of HRK and other information resulting from EAP
authentication, such as authentication lifetime, HRK lifetime and
so on.
3. SA2 pre-exists between the ADC and the EAP/AAA server based on
the AAA infrastructure before the EAP authentication starts. In
roaming environments (multiple administrative domains) this SA
may have to be established through a chain of trust.
4. SA3 is between the Access Node and the ADC to protect signalling
and key transfers. Provisioning of SA3 is important for
distribution of LSAP_MKs from authenticator to the AN. SA3 may
pre-exist or may be created as part of initial keying. The
requirements for SA3 and its creations are to be developed later
on.
5. SA4 is between the peer (MN) and the Access Node and is
established through LSAP exchange. SA4 information includes
LSKs. Providing key derivation guidelines for SA4 is part of the
problem being considered.
6. SA5 is between the MN and the ADC derived from the EAP
authentication and key framework procedures. Providing key
derivation guidelines and specifications for SA5 is part of the
problem being considered.
7. SA6 represents a possible trust relationship between the ANs.
The need for this trust for keying solution is to be
investigated.
Note that as part of establishing new security associations in
conjunction with a handover, network access policies may require re-
authentications to the ADC or the AAA server depending on the type of
handover. A handover keying solution can provide additional keys
(derived from the handover root key) that allow for fast re-
Nakhjiri, et al. Expires December 25, 2006 [Page 10]
Internet-Draft EAP Keying Handovers: PS June 2006
authentication without requiring support of fast re-authentication
from the EAP methods.
As mentioned earlier, the potential physical separation (or
separation of identifiers) of the ADC and AN will present challenges
such as the need for an additional key transport protocol between the
ADC and the AN, channel binding at multiple levels and carrying EAP
signalling between the peer and the ADC through the AN.
The most important goal for this effort is to provide a handover
keying solution that best fit the architecture shown in Figure 2,
whilst meeting the initially defined security goals.
4. Security Goals
The baseline assumption in this document (see Section 3) is to use
AAA based key management possibly using a key hierarchy stemming from
an HRK which is generated through the EAP authentication and keying
process. However, as we described, there are a number of
alternatives for deployment of EAP framework to a wireless mobile
network providing handover keying solutions.
The definition of key material and associated parameters to derive
the keys and security associations from an initial EAP authentication
to support an optimized wireless network handover is the goal of this
work. An important goal is to assess what keys and security
associations (e.g. SA4 and/or SA5 in Figure 2) are to be re-used or
re-generated as part of handover or a re-authentication process. The
assessment is done considering the handover performance as well as
the security goals defined in this document. Definition of
relationship between the key material, such as definition of the
hierarchy and child-parent/sister relationship before and after
handover is part of scope. Although the exact definition of the
actual cryptographic functions (Pseudo Random Functions) may not be
part of the scope, definition of the inputs into the PRFs, e.g. root
keys and associated parameters (e.g. ADC's IDs and nonces) are part
of solution scope.
The section will draw from the guidance provided in [I-D.housley-aaa-
key-mgmt] to further define the security goals to be achieved by a
complete handover keying solution.
4.1. Key Context and scope, prevention of domino effect
Any key, including HRK and the keys derived for the lower levels of
key hierarchy (e.g., ADMSK, LSKs) MUST have a well-defined scope and
MUST be used in a specific context and for the intended use. This
Nakhjiri, et al. Expires December 25, 2006 [Page 11]
Internet-Draft EAP Keying Handovers: PS June 2006
specifically means the lifetime and scope of each key MUST be defined
clearly so that all the entities that are authorized to have access
to the key have the same context during the validity period. In a
hierarchical key structure, the lifetime of lower level keys MUST NOT
exceed the lifetime of higher level keys. This requirement may imply
that the context and the scope parameters (e.g., lifetime, ADC's ID,
authorization information) have to be exchanged. Furthermore, the
semantics (not syntax) of these parameters MUST be defined to provide
proper channel binding specifications. The definition of exact
parameter syntax definition is however part of the design of the
transport protocol used for the parameter exchange and that may be
outside scope of this document.
If a key hierarchy is deployed, compromising lower level keys MUST
NOT result in a compromise of higher level keys which they were used
to derive the lower level keys. The compromise of keys at each level
MUST NOT result in compromise of other keys at the same level. The
same principle applies to entities that hold and manage a particular
key defined in the key hierarchy. For example, an AN cannot have
access to keying material for another AN. That is, compromising keys
on one AN MUST NOT reveal the keys of another AN. Note that, the
compromise of higher level keys has security implications on lower
levels.
Guidance on parameters required, caching, storage and deletion
procedures to ensure adequate security and authorization provisioning
for keying procedures will be defined in a solution document.
4.2. Key Naming
All the keying material starting from HRK and the derivatives MUST be
uniquely named so that it can be managed effectively. For example,
when the peer is engaging in the LSAP, it should be able to identify
the name of the key that is being used.
4.3. Key Freshness
As [I-D.housley-aaa-key-mgmt] defines, a fresh key is one that is
generated for the intended use. This would mean the key hierarchy
must provide for creation of multiple cryptographically separate
child keys from a root key at higher level. For instance, the
LSAP-MK for the LSAP between the MN and two different ANs must be
generated freshly and independently, even when both ANs are under the
same ADC. Furthermore, the keying solution needs to provide
mechanisms for authorized refreshing each of the keys within the key
hierarchy.
Nakhjiri, et al. Expires December 25, 2006 [Page 12]
Internet-Draft EAP Keying Handovers: PS June 2006
4.4. Authorization
The EAP Key management document [I-D.ietf-eap-keying] discusses
several vulnerabilities that are common to handover mechanisms. One
important issue arises from the way the authorization decisions might
be handled at the AAA server during network access authentication.
For example, if AAA proxies are involved, they may also influence in
the authorization decision. Furthermore, the reasons for choosing a
particular decision are not communicated to the AAA clients. In
fact, the AAA client only knows the final authorization result.
If AAA exchange is bypassed, this creates additional challenges to
ensure that authorization is properly handled. Possibly differing
capabilities of the ANs before and after handovers could result in
correctness issues with these authorization as the AN or AAA client
may lack information of proper granularity to make access or
authorization decisions after a handover. The logical descriptions
of each of the parties in the architecture in this document assumes
that all the parties with the same role (ANs, ADCs, etc) have the
same capabilities when dealing with the AAA and keying matters.
4.5. Authentication of all the parties
Each party in the handover keying architecture MUST be authenticated
to any other party with whom it communicates and provides its
identity to any other entity that may require the identity for
defining the key scope. The identity provided must be meaningful
according to the protocol over which the two parties communicate.
4.6. Channel Binding
Channel Binding procedures are needed to avoid a compromised
intermediate authenticator/ADC providing unverified and conflicting
service information to each of the peer and the EAP server. However,
typically only a 3-party model has been considered (see [I-D.arkko-
eap-service-identity-auth]). In the architecture introduced in this
document, there are multiple intermediate entities between the peer
and the backend EAP/AAA server. Various keys need to be established
and scoped between these parties and some of these keys may be
parents to other keys. Hence the Channel Binding for this
architecture will need to consider lying intermediate entities at
each level and make sure that an entity with higher level of trust
can examine the truthfulness of the claims made by intermediate
parties (a discussion about hierarchical channel binding can be found
in [I-D.ohba-eap-channel-binding])
Nakhjiri, et al. Expires December 25, 2006 [Page 13]
Internet-Draft EAP Keying Handovers: PS June 2006
4.7. EAP method independence
The handover keying framework needs to be independent of the chosen
EAP method, as long as the method supports the needs of [RFC4017] and
[I-D.ietf-eap-keying].
4.8. Transport aspects
Depending on the physical architecture and the functionality of the
elements involved, there may be a need for multiple protocols to
perform the key transport between entities involved in the handover
keying architecture. For instance when keys are transported between
AAA server and AAA client, the key transport may be performed through
a AAA protocol. On the other hand, when the ANs and ADCs are
physically disparate, and the ADCs perform key management functions
for the ANs, there will be a need for a key transport protocol
between the AN and the ADCs. Thus, a set of requirements for each of
these protocols (and the parameters they will carry) will be
developed. Following the requirement specifications, recommendations
will be provided as to whether new protocols or extensions to
existing protocols are needed.
As mentioned, the use of existing AAA protocols for carrying EAP
messages and keying material between the AAA server and AAA clients
that have a role within the architecture considered for the keying
problem will be carefully examined. Definition of specific
parameters, required for keying procedures and to be transferred over
any of the links in the architecture, are part of the scope. The
relation of the identities used by the transport protocol and the
identities used for keying also needs to be explored.
5. Security Considerations
This document discusses an enhancement of EAP key management for in
the emerging mobile networks. Security aspects of this enhancement
are discussed throughout the document. When the solution for the
problem statement presented in this document is being specified, the
solution will be checked against the security goals presented
previously.
6. IANA consideration
This document does not require any actions by IANA.
Nakhjiri, et al. Expires December 25, 2006 [Page 14]
Internet-Draft EAP Keying Handovers: PS June 2006
7. Acknowledgements
The authors would like to thank Joe Salowey, Yoshihiro Ohba and
Kuntal Chowdhury for their useful suggestions on forming this problem
statement.
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-13 (work in
progress), May 2006.
8.2. Informative references
[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 8: Fast BSS Transition", IEEE
std. 802.11r/D2.0.
[I-D.housley-aaa-key-mgmt]
Housley, R. and B. Aboba, "Guidance for AAA Key
Management", draft-housley-aaa-key-mgmt-02 (work in
progress), March 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.
[I-D.ohba-eap-channel-binding]
Ohba, Y., "Channel Binding Mechanism based on Parameter
Binding in Key Derivation",
draft-ohba-eap-channel-binding-01 (work in progress),
Nakhjiri, et al. Expires December 25, 2006 [Page 15]
Internet-Draft EAP Keying Handovers: PS June 2006
June 2006.
[I-D.salowey-eap-emsk-deriv]
Salowey, J., "Specification for the Derivation of Usage
Specific Root Keys (USRK) from an Extended Master Session
Key (EMSK)", draft-salowey-eap-emsk-deriv-01 (work in
progress), June 2006.
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible
Authentication Protocol (EAP) Method Requirements for
Wireless LANs", RFC 4017, March 2005.
Nakhjiri, et al. Expires December 25, 2006 [Page 16]
Internet-Draft EAP Keying Handovers: PS June 2006
Appendix A. Intra-ADC handover example
Following and for the sake of clarity, we explain an intra-ADC
handover example. (the example is based on the Figure 2 explained in
Section 3)
Initially, the MN (EAP peer) is connected to AN1 which in turn is
connected to the ADC1. When MN connects to the access network for
the first time (through AN1), it can use EAP [RFC3748] to
authenticate to the access network (AAA server). This EAP
authentication generates cryptographic material needed to generate
the HRK.
The AAA server can upon generating the HRK and then ADMSK1 forwards
the ADMSK1 to ADC1, which in turn creates the LSAP master key
(LSAP-MK) for the LSAP process between AN1 and the peer. The LSAP
exchange leads to creation of a set of link security keys (LSKs)
between the peer and AN1.
When the peer (MN) needs to handoff to another AN (AN2 in Figure 2),
the MN needs to the SA4 and potentially SA5 (e.g. AN2 to AN3
handover) needs to be updated. Thus, a new LSAP-MK is needed to
perform a LSAP with new AN (i.e. AN2) and arrive with new LSKs with
it. Not only the MN needs to know the mechanisms to arrive at a new
LSAP-MK (LSAP-MK2) from the HRK (or its derivatives), but also there
must be an infrastructure to deliver the LSAP-MK2 to AN2 in a secure
and timely manner. An optimal handover keying solution will achieve
both of the above should happen without a new EAP authentication and
possibly without contacting the Home AAA server.
Nakhjiri, et al. Expires December 25, 2006 [Page 17]
Internet-Draft EAP Keying Handovers: PS June 2006
Authors' Addresses
Madjid Nakhjiri
Motorola Labs
Email: Madjid.nakhjiri@motorola.com
Mohan Parthasarathy
Nokia
313 Fairchild Drive
Mountain View CA-94043
US
Email: mohan.parthasarathy@nokia.com
Julien Bournelle
GET/INT
9 rue Charles Fourier
Evry 91011
France
Email: julien.bournelle@int-evry.fr
Hannes Tschofenig
Siemens Corporate Technology
Otto-Hahn-Ring 6
81739 Munich
Germany
Email: Hannes.Tschofenig@siemens.com
Rafael Marin Lopez
Toshiba America Research,Inc
1 Telcordia Dr.
Piscataway, NJ 08854
USA
Email: rmlopez@tari.toshiba.com
Nakhjiri, et al. Expires December 25, 2006 [Page 18]
Internet-Draft EAP Keying Handovers: PS 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.
Nakhjiri, et al. Expires December 25, 2006 [Page 19]
