One document matched: draft-nakhjiri-aaa-hokey-ps-01.txt
Differences from draft-nakhjiri-aaa-hokey-ps-00.txt
Network Working Group M. Nakhjiri
Internet-Draft Motorola Labs
Expires: July 30, 2006 M. Parthasarathy
Nokia
J. Bournelle
GET/INT
H. Tschofenig
Siemens
January 26, 2006
AAA based Keying for Wireless Handovers: Problem Statement
draft-nakhjiri-aaa-hokey-ps-01
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 July 30, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The Extensible Authentication Protocol (EAP) provides a framework for
performing authentication and key management using the AAA
infrastructure. The framework deals with a model which includes a
Nakhjiri, et al. Expires July 30, 2006 [Page 1]
Internet-Draft EAP Keying Handovers: PS January 2006
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 . . . . . . . . . . . . . . . . . 5
3. Problem Description . . . . . . . . . . . . . . . . . . . . . 8
4. Security Goals . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Key Context and scope, prevention of domino effect . . . . 12
4.2. Key Naming . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3. Key Freshness . . . . . . . . . . . . . . . . . . . . . . 13
4.4. Handover Vulnerabilities . . . . . . . . . . . . . . . . . 14
4.5. Authentication of all the parties . . . . . . . . . . . . 14
4.6. Channel binding . . . . . . . . . . . . . . . . . . . . . 14
4.7. EAP method independence . . . . . . . . . . . . . . . . . 14
4.8. Non goals . . . . . . . . . . . . . . . . . . . . . . . . 15
4.8.1. Transport aspects . . . . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
5.1. open issues . . . . . . . . . . . . . . . . . . . . . . . 15
6. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 16
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . . 16
8.2. Informative references . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19
Nakhjiri, et al. Expires July 30, 2006 [Page 2]
Internet-Draft EAP Keying Handovers: PS January 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 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 (TSK) through the Secure Association
protocol (SAP) as described in [I-D.ietf-eap-keying]) to secure the
link between the peer and the authenticator.
Wireless networks deploy specific access nodes (AN) providing link
layer service to the peers. The EAP keying framework has been used
for these environments to arrive at TSKs to secure the peer-AN link.
This however means, the authenticator would have to either be co-
located at the AN or deploy specific ports at the AN to be able to
perform SAP exchanges with the peer based on the MSK received from
the EAP/AAA server (hence required AAA client functionality at the
authenticator) to generate TSKs with the peer.
Use of this model (authenticator colocated with AN) for mobile
networks poses some difficulties. When the peer hands off to another
AN, it needs to renegotiate new TSKs with that AN. Since the MSK is
typically the only secret used in derivation of TSK (the other
information exchanged in SAP is visible to outsiders), protecting the
TSK at new AN from the old AN would require derivation of new MSK at
the new AN. Deriving a new MSK would require performing a new EAP
authentication with the EAP server through the new authenticator (new
AN) and this could result in significant handover performance
degradation.
In an effort to improve mobility performance, the latest access
technologies have made architectural changes to avoid the need for
authenticator-relocation and new MSK derivation. However, the
approach has not been uniform:
802.11r has introduced the concept of key holder that maintains MSKs,
so that the authenticator does not have access to the MSK. The
authenticator instead uses lower level keys (pairwise master key 1,
PMK-R1) in exchanges leading to TSKs (called pairwise transient keys,
PTKs in 802.11r).
WiMAX (supporting organization for 802.16e) has introduced a two-part
Nakhjiri, et al. Expires July 30, 2006 [Page 3]
Internet-Draft EAP Keying Handovers: PS January 2006
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 the picture shown in Figure 1, where
the peer connects to an AN rather than an authenticator, is more
representative of the actual deployment of the EAP keying and the
pass-through authenticator function as a single logical and physical
entity as defined in EAP framwork documents is not sufficient to
succintly design a keying solution for a mobile wireless environment.
Using EAP keying framework on this new architecture model poses some
design issues that are being exarcerbated by the ambiguities in the
current collection of EAP documentation.
+-+-+-+-+-+ +-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| MN/ |-----| AN |---|Authenticator|----|EAP/AAA server |
|EAP Peer | +-+-+-+ | /key holder | +-+-+-+-+-+-+-+-+
+-+-+-+-+-+ +-+-+-+-+-+-+-+
Figure 1: Wireless access network with separate AN and pass-through
authenticators
First, EAP framework describes the delivery of master keys only to
pass-through authenticators, and not to the ANs or to key holders,
that are not collocated with the authenticator. Since, EAP framework
needs to be mode independent (2 party or 3 party authentication), it
does not clarify the role of pass-through authenticator in the AAA
infrastructure (AAA client) transporting the MSK. In the design of a
mobile network handover keying architecture we can safely assume the
existence of both edge devices and backend AAA servers. Therefore we
can and need to clarify the AAA roles in master key transport.
Furthermore, the current EAP keying documentation requires AAA layer
entities to delete the transported keys and this may imply a logical
authenticator or AAA client will not be able to act as a key holder.
Second, the EAP framework is currently ambiguious in whether the AAA
key, MSK or AMSK is to be used in generation of keys for applications
such as handover keying. It is also not clear what the role of each
of EAP server and AAA server in authorizing, generating, caching and
transferring AMSKs from EMSK is. It is the goal of this work to
investigate the feasibility of concepts such as AMSK generation and
usage in providing an appropriate AAA-based keying mechanism.
Third, some deployments of EAP framework have introduced the notion
of authenticator ports to address the scenarios where the AN is
separate from the authenticator and the keys at the AN and the
Nakhjiri, et al. Expires July 30, 2006 [Page 4]
Internet-Draft EAP Keying Handovers: PS January 2006
authenticator are at different levels of key hierarchy. The issue is
that the current EAP documentation does not specify the channel
binding solution for each hierarchy level. Specific identities for
authenticator and authenticator ports (ANs) would be needed at both
peer (through advertising) and the network entities (see 802.11r
R0KH-ID, R0 key holder identifier, and R1KH-ID, R1 keyholder IDs in
document [IEEE P802.11r/D1.0].
Finally, the EAP framework does not provide guidance on processes
such as pre-authentication, fast re-authentication that will help to
improve handover process.
Given that various standard bodies are extending EAP keying framework
in a different way to solve the wireless mobility keying, it may be
appropriate to use the IETF as a forum for development of such
extensions. For exampel, it would be very useful to provide
specifications that describe how the EAP derived keys, such as AMSK
can be used to provide keying solutions for the handover problem
without requiring new excution of full EAP exchanges with the EAP
server. Topics to be addressed can range from possible inclusion of
additional entities required for holding the keys, generating keys
according some hierarchy and distributing the keys to proper entities
to key hierarchy itself (relation to the EAP keys such as
AMSK),channel binding and so on.
This docuemnt 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]. Some additional terms and
clarifications are included below.
EAP server: The EAP server in handover keying has the 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 July 30, 2006 [Page 5]
Internet-Draft EAP Keying Handovers: PS January 2006
AAA server: The entity that is the main point of trust and
authorization (AAA) in the administrative domain, and maintains
peer information and possibly keying information. The AAA server
relies on EAP server for execution of EAP-method authentications.
Party: A party is a processing entity that has a logically separate
role in the architecture. In order to provide appropriate
security for the key management design, in this document, we treat
each party as if it were physically separate from the other
parties, although in practice one or more parties may be inserted
in the same physical box.
Mobile Node (MN) (peer): The entity that receives network access
through a point to point link to an Access Node and acts as an EAP
peer functionality as described by [RFC3748] and keying frameworks
[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.
Access Node: 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 physical implementation of AN may or
may not include EAP pass-through authenticator or AAA client
functions (described separately). Therefore, we consider AN and
pass-through authenticator as separate parties. However, the AN
is responsible for de-encapsulation of EAP messages over access-
technology-specific link protocols (e.g. encapsulating EAP over
EAPOL for 802.11 or over PKMv2 for 802.16e).
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 understand
EAP success and failure messages. The authenticator may not
necessarily be the terminating point for the physical access link
to the peer.
AAA client: We use AAA client in two senses in this document. 1) the
first AAA entity (from mobile node side), that engages in AAA
protocol conversation with the AAA infrastructure leading to the
home AAA server. This entity is also responsible for
encapsulating EAP messaging inside AAA protocol messages (RADIUS
[RFC3579] or Diameter [RFC4072]). 2) An entity such the key holder
that acts as a client dealing with the AAA server.
Nakhjiri, et al. Expires July 30, 2006 [Page 6]
Internet-Draft EAP Keying Handovers: PS January 2006
SA: Security Association.
X-Master Session Key (XMSK): A key that will be used as the root key
to solve the handover keying problem. We assume that the XMSK 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. Exact correlation of XMSK with the EAP keys (e.g.
MSK, EMSK, AMSK) is to be determined. In the rest of this
document, we will only refer to XMSK.
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
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, the LSKs in this document and the
transient session keys (TSK) in [I-D.ietf-eap-keying] may become
the same.
Key holder: This entity is the one that holds the root key/s for a
key derivation process. There may be multiple key holders in the
network and depending on their interaction with the AAA
infrastructure, they may need to have AAA client functionality,
especially if the key holder receives a key such as XMSK from a
AAA server.
Pseudo Random Function (PRF): The function used in generation of a
keying material. There may be multiple PRFs (PRF1/PRF2/..PRFn)
involved dealing with generation various keys between each pair in
the architecture. Cryptographic specification of the PRFs is
outside scope of this document, as it may be governed by outside
SDO. For instance a PRF used between the peer and AN to generate
LSKs is specified by the SDO standardizing the access link.
Nakhjiri, et al. Expires July 30, 2006 [Page 7]
Internet-Draft EAP Keying Handovers: PS January 2006
AAA protocol: AAA based keying relies on tranferring the XMSK from
AAA server to a AAA client using a AAA protocol. The AAA protocol
needs to support secure key wrapping and transfer as well as
transfer of authorization and usage material if needed.
3. Problem Description
As mentioned earlier, in wireless access networks using EAP
authentication and key management framework, it is not appropriate to
store the XMSK from the EAP process at the AN. Otherwise, as the
peer hands off from one AN to another, it would have to perform a
complete EAP authentication to receive a new XMSK unique for the new
AN. Since, the EAP keying framework assumes the XMSK is tranported
to the pass-through authenticator, the need to keep XMSK unchanged
would mean the XMSK needs to be stored at a key holder other than the
AN. This would lead us to the following minimum archiecture to
realize the handover keying solution:
SA1
<----------------------------------------->
SA12
<----------------------------------------->
SA4 SA3 SA2
<--------> <--------------> <------------->
SA5
<--------------------->
+-+-+-+-+-+ +-+-+-+
| MN/ |-----| AN1 |---+
|EAP Peer | +-+-+-+ | +-+-+-+
+-+-+-+-+-+ ^ +-----|KH 1 |-+
| SA6 | +-----+ |
| | |
V | | +-+-+-+-+-+
+-+-+-+ | | |AAA/EAP |
| AN2 |---+ +--+--| Server |
+-+-+-+ | +---------+
|
+-+-+-+ +-----+ |
| AN 3|---------+kH 2 +----+
+-+-+-+ +-+-+-+
Nakhjiri, et al. Expires July 30, 2006 [Page 8]
Internet-Draft EAP Keying Handovers: PS January 2006
Figure 2: A wireless handover keying architecture deploying EAP
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 mechanisms, and therefore can be considered
as one trusted party.
As can also be noted, this document introduces a key holder into the
architecture. Another reason for introducing a key holder is, EAP
keying specification currently requires a AAA entity (either a AAA
server or a AAA client) to delete a key (such as XMSK) after
transport. To accomodate the key management functions (storage,
further key derivation and distribution) required, we assume the AAA
infrastructure passes the keys to the key holders (KH). A local key
holder that receives keys from the AAA server may need to be a AAA
client.
As shown in Figure 2, the MN (EAP peer) is connected to AN1 which in
turn is connected to the Authenticator 1 (Athr1). We will discuss
alternatives on authenticator placement shortly, but let us assume
for now the Athr1 is at key holder 1 (KH1). 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) through
authenticator 1. The AAA server forwards the XMSK to KH1, 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. The
ultimate solution may include levels of hierarchies and key holders
betwen XMSK and LSAP-MK, but that is not important for this
discussion at the moment. When the peer (MN) needs to handoff to
another AN (AN2 in figure Figure 2), the MN needs to have a new
LSAP-MK to perform a LSAP with AN2 and arrive with new LSKs with AN2.
Not only the MN needs to know the mechanisms to arrive at a new
LSAP-MK (LSAP-MK2) from the XMSK (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 achive
both of the above should happen without a new EAP authentication and
possibly without contacting the home AAA server.
For completion, various security associations (SA) between the
archiecture entities in figure 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 XMSK and other information resulting from EAP
authentication, such as authentication life time, XMSK life time
Nakhjiri, et al. Expires July 30, 2006 [Page 9]
Internet-Draft EAP Keying Handovers: PS January 2006
and so on.
3. SA2 pre-exists between the key holder 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 pre-exists between the Access Node and the key holder to
protect signaling and key transfers. Provisioning of SA3 is
outside scope of this document, unless it is required by IETF to
provide guidance for the SDOs using the handover keying
architecture.
5. SA4 is between the peer (MN) and the Access Node and is
established through LSAP exchange. SA4 information includes
LSKs.
6. SA5 is between the EAP peer and the key holder derived from the
EAP authentication and key framework procedures.
7. SA6 represent a possible trust relationship between the ANs. The
need for this trust for keying solution is to be investigated.
As the mobile node hands off from AN1 to another AN, the SA4 and
potentially SA5 (e.g. AN2 to AN3 handover) needs to be updated.
Depending on the solution and the coverage domain of the key holder,
a change of SA5 may also require a change of SA12 and thereby require
a full EAP authentication. However, handover performance
requirements may dictate that handover keying should not involve full
EAP authentication exchange.
Currently, there are no clear guidelines on how the EAP keying
framework and its master keys (MSK, EMSK) can be used further in the
access network to derive keys for SA1, SA4 and SA5.
As mentioned earlier, the EAP keying specifications only discuss
transport of XMSK to an authenticator and therefore, we recommended
separating the AN and authenticator functions and introduction of a
key holder into the architecture to receive and hold the XMSK. This
makes the physical placement of pass-through authenticator and AAA
client in our architecture uncertain. There are several alternatives
for placing the pass-through authenticator and AAA client
functionalities on the table:
Alternative 1: Authenticator, AAA client and key holder are co-
located. AN has only access technology functionality, encapsulates
EAP over link technology on the peer side and over a TBD protocol to
the EAP pass-through authenticator. The AAA client/authenticator/key
holder encapsulates EAP inside AAA protocol and receives XMSK from
the AAA server. The issue with this alternative is that,
authenticator handovers are equivalent to key holder handovers. In
other word, when an AN handovers leads to a key holder handover (AN2
Nakhjiri, et al. Expires July 30, 2006 [Page 10]
Internet-Draft EAP Keying Handovers: PS January 2006
to AN3 handover in Figure 2), require derivation of new XMSKs. In
wireless networks, the link between AN and the authenticator may be
the link carrying backhaul traffic and hence may be bandwidth-
limited. This will constrain the AN to key holder ratio in the
handover keying architecture and therefore may have an adverse effect
on over all system handover performance as the likelihood of a
handover leading to a key holder handover (and hence interaction with
backend server) will increase.
+-+-+-+-+ +-+-+-+-+-+ +-+-+-+ +-+-+-+-+-+
| | | | |KH | | |
| EAP |--------| Access |-------|Athr |------| EAP/AAA |
| Peer | | Node | |AAAC | | Server |
+-+-+-+-+ +-+-+-+-+-+ +-+-+-+ +-+-+-+-+-+
Figure 3: Alternative 1: AN with almost no AAA or EAP functionality
Alternative 2: Authenticator and AAA client are located in the AN: as
previous case, however the key holder is not on the AAA signaling
path and acts as separate AAA client receiving the XMSK from the
server. In this alternative a key holder can serve many
authenticators and hence the Number of ANs (AN_No)per key holder is
not directly limited by the backhaul issues. The AN_No/key holder
ratio can be higher than AN_No/ authenticator ratio. However, issues
related to key transfer from AAA server to key holder (instead of
authenticator) need to be resolved.
+-+-+-+-+-+
| Key Hldr|
| AAAC |-----+
+-+-+-+-+-+ \
| \
| \
V \
+-+-+-+-+ +-+-+-+-+-+ \ +-+-+-+-+-+
| | | Athr | +-| |
| EAP |--------| AAAC |------------| EAP/AAA |
| Peer | | AN | | Server |
+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
Figure 4: Alternative 2: off-AAA-path key holder function
As it can be clearly seen, there are many architecture, protocol
design, security and authorization issues to be resolved as part of
definition of the problem and solution for handover keying.
This document is merely serving as a statement for a problem to be
Nakhjiri, et al. Expires July 30, 2006 [Page 11]
Internet-Draft EAP Keying Handovers: PS January 2006
solved without going into the specifics of the solution. The actual
specifications will be part of the later solution documents.
The most important goal for this effort is to provide a keying
solution that best fit the architecture shown in Figure 2, whilst
meeting the initially defined security goals.. This will most likely
involve choosing one of the realization alternatives described in
Figure 3 to Figure 4 which is agreed by the involved experts as the
most deployable and the one with the highest probability of providing
best handover performance, For an initial discussion on the pros and
cons of each of these alternatives, the reader is referred to
[I-D.nakhjiri-eap-ho].
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 XMSK delivered 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 association to support initial entry to
wireless network and handover is the goal of this work. An important
goal is to assess what keys and security associations (e.g. SA4
and/or SA5) are to be re-used or re-generated as part of handover or
re-authentication. 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 (PRFs) may not be
part of the scope, definition of the inputs into the PRF, e.g. root
keys and the parameters e.g. holder 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 XMSK and the keys derived for the lower layers of
key hierarchy (e.g., LSKs) MUST have a well-defined scope and MUST be
used a specific context. This specifically means the lifetime and
scope of each key MUST be defined clearly so that all the entities
Nakhjiri, et al. Expires July 30, 2006 [Page 12]
Internet-Draft EAP Keying Handovers: PS January 2006
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, key holder 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, the lower layer key holder MUST NOT
have access to keying material for the higher layer key holder or
another key holder at the same layer, e.g., an AN cannot have access
to keying material for another AN. The compromise of keys on one
Access Node SHOULD NOT reveal the keys of another Access Node. Note
that, the compromise of higher level key holders (such as AAA server
data base) does have have security implications on lower levels.
Depending on the outcome of [I-D.ietf-eap-keying] in EAP WG if the
AAA layer (as an EAP lower layer) is not authorized to keep any
transported keys, the role of AAA entities (AAA client and server)
and their interaction with the key holders within the keying
architecture must be defined.
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 XMSK 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
Session keys produced at each level of key hierarchy, e.g. LSAP-MK
for LSAP or between each two parties SHOULD be fresh. The strength
of these keys are abstracted by the choice of Pseudo Random Function
(PRF) used to derive the keys at that level. The same key at a
higher level can be used to derive multiple keys at lower layers.
The keying material at the key holder may be used to derive keying
material for multiple ANs under that key holder, as long as the
keying material for the Access Nodes are not derived from each other
in whole or partially.
Nakhjiri, et al. Expires July 30, 2006 [Page 13]
Internet-Draft EAP Keying Handovers: PS January 2006
4.4. Handover Vulnerabilities
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.
If AAA proxies are involved, they may also influence the decision.
The reasons for choosing a particular decision is not communicated to
the AAA clients. The AAA client (and thereby AN in this
architecture) knows only the final result. When the 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, key holders, etc) have the same
capabilities when dealing with the AAA and keying matters.
4.5. Authentication of all the parties
Each party in the keying framework 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
(channel binding). 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 pass-
through entity providing unverified and conflicting service
information to each of the peer and the EAP server. The current
solutions [I-D.arkko-eap-service-identity-auth] [I-D.ohba-eap-aaakey-
binding] only address 3-party models. In the architecture introduced
in this document, there are multiple intermediate parties 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.
4.7. EAP method independence
The keying framework needs to be independent of the chosen EAP
method, as long as the method supports the needs of [RFC4017] and
Nakhjiri, et al. Expires July 30, 2006 [Page 14]
Internet-Draft EAP Keying Handovers: PS January 2006
[I-D.ietf-eap-keying].
4.8. Non goals
This section deals with items that are considered out of scope for
the handover keying problem space defined in this paper.
4.8.1. Transport aspects
Except between the AAA server and the AAA client, specification of
the transport (including message formats) of EAP messages between the
different parties, e.g., between the peer and the AN (such as use of
PKMv2/802.16e for 802.16 ANs) and the backhaul between the AN and the
key holder may be a responsibility of other standards organizations
and therefore possibly outside scope of this work. This document may
however pose restrictions on the protocol and the mechanism used
between the AN and key holder for key transport between the AN and
the key holder and may provide recommendations for protocols between
the peer and AN (e.g., parameters for channel binding, etc).
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. As the solution for the
problem statement presented in this document is specified, the
solution will be checked against the security goals presented
previously.
5.1. open issues
It is yet to be determined whether the solution will depend on a key
hierarchy and whether the key holder at each hierarchy level need to
maintain a cache of each key as it is transported to lower layer
entities.
It is also yet to be understood what are the role of a central AAA
server and of the local entities in the authorization and generation
Nakhjiri, et al. Expires July 30, 2006 [Page 15]
Internet-Draft EAP Keying Handovers: PS January 2006
of keys. generation. For that reason, until the "role" of which each
entity is to play in a successfully implemented mobile environment,
and specifically its access to particular keys according to this
principle is to be defined and the risks of compromise of any
entities resulted from the compromise of this entity is also to be
determined. It is intuitively predicted that the higher the key
holder is in the key hierarchy, the more impact on the lower layer
key holders.
6. IANA consideration
This document does not require any actions by IANA.
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-09 (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.
Nakhjiri, et al. Expires July 30, 2006 [Page 16]
Internet-Draft EAP Keying Handovers: PS January 2006
[I-D.nakhjiri-eap-ho]
Nakhjiri, M., "EAP keying and handover support",
draft-nakhjiri-eap-ho-00 (work in progress), June 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.
[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-aaakey-binding]
Yanagiya, M. and Y. Ohba, "AAA-Key Derivation with Lower-
Layer Parameter Binding", draft-ohba-eap-aaakey-binding-01
(work in progress), July 2005.
[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 July 30, 2006 [Page 17]
Internet-Draft EAP Keying Handovers: PS January 2006
Authors' Addresses
Madjid Nakhjiri
Motorola Labs
Email: Madjid.nakhjiri@motorola.com
Mohan Parthasarathy
Nokia
313 Fairchild Drive
Moutain 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
Nakhjiri, et al. Expires July 30, 2006 [Page 18]
Internet-Draft EAP Keying Handovers: PS January 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 July 30, 2006 [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-23 04:08:17 |