Network Working Group V. Narayanan
Internet-Draft L. Dondeti
Intended status: Informational QUALCOMM, Inc.
Expires: April 18, 2007 October 15, 2006
Problem Statement on EAP Efficient Re-authentication and Key Management
draft-vidya-eap-reauth-ps-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 April 18, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The extensible authentication protocol (EAP), specified in RFC3748
[1] is a generic framework for network access authentication, in
which a peer engages in a full EAP conversation each time. A full
EAP conversation involves several roundtrips between the peer and the
authentication server in the home domain, and that is not acceptable
for fast roaming. In this document, we explain the requirements for
low-latency EAP re-authentication and associated key management.
Narayanan & Dondeti Expires April 18, 2007 [Page 1]
Internet-Draft EAPext PS October 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. EAP Efficient Re-authentication Problem Statement . . . . . . 4
4. Design goals and constraints . . . . . . . . . . . . . . . . . 5
5. Extending the EAP keying hierarchy to support
re-authentication . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Root key selection for efficient EAP re-authentication . . 5
5.2. Specification of the EMSK hierarchy and key derivation
thereof . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Use Cases and Related Work . . . . . . . . . . . . . . . . . . 6
6.1. IEEE 802.11r Applicability . . . . . . . . . . . . . . . 7
6.2. CAPWAP Applicability . . . . . . . . . . . . . . . . . . . 7
6.3. Inter-technology Roaming . . . . . . . . . . . . . . . . . 8
6.4. Inter-domain Roaming . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. References . . . . . . . . . . . . . . . . . . . . . . . . 9
10.2. References . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 11
Narayanan & Dondeti Expires April 18, 2007 [Page 2]
Internet-Draft EAPext PS October 2006
1. Introduction
The extensible authentication protocol (EAP), specified in RFC3748
[1] is a generic framework supporting multiple authentication
methods. The primary purpose of EAP is network access control and a
key generating method is recommended for that purpose. The EAP
keying hierarchy defines two keys that are derived at the top level -
the master session key (MSK) and the extended MSK (EMSK). In the
most common deployment scenario, an EAP peer and server authenticate
each other through a third party known as the authenticator. The
authenticator or an entity controlled by the authenticator enforces
access control. After successful authentication, the server
transports the MSK to the authenticator; the authenticator and the
peer derive transient session keys (TSK) using the MSK as the
authentication key or a key derivation key and use the TSK and use
the TSK for per-packet access enforcement.
The EAP model of authentication is unfortunately not efficient in
case of mobile and wireless networks for the following reasons:
When a peer associates with an authenticator, it is expected to
run an EAP method irrespective of whether it has been
authenticated to the network recently and has unexpired keying
material. A full or even a reduced roundtrip EAP method execution
involves several roundtrips between the EAP peer and the server.
Each EAP conversation runs between the peer and its home domain,
resulting in unacceptable latency.
There have been attempts to solve the problem of efficient re-
authentication in various ways. However, those solutions are either
EAP method-specific, EAP lower-layer specific, or otherwise limited
in scope, or do not conform to the AAA keying requirements specified
in [4].
In this document, we provide a detailed description of EAP efficient
re-authentication protocol requirements.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [2].
This document follows the terminology that has been defined in
RFC3748 [1] and the EAP Keying I-D. In addition, this document uses
the following terms:
Narayanan & Dondeti Expires April 18, 2007 [Page 3]
Internet-Draft EAPext PS October 2006
Usage Specific Root Key (USRK) is keying material derived from the
EMSK for a particular usage definition as specified in this document.
It is used to derive child keys in a way defined by its usage
definition. USRKs are defined and specified in [5].
3. EAP Efficient Re-authentication Problem Statement
When a peer moves from one authenticator and reattaches to another
authenticator, it is required to engage in a full EAP exchange with
the authentication server in its home domain [1]. There are two
issues with this requirement:
o A full EAP method exchange at every authenticator - An EAP
conversation with a full EAP method run takes several round trips
and significant time to complete, causing delays in handoff times.
Some methods [6] specify the use of keys and state from the
initial authentication to finish subsequent authentications in
fewer roundtrips. However, even in those cases, several
roundtrips to the EAP server are involved. Furthermore, most EAP
methods do not offer such a fast re-authentication feature. In
summary, it is undesirable to have to run a full EAP method each
time a peer associates with a new authenticator; furthermore, it
is desirable to specify a method-independent efficient re-
authentication protocol. Key material from the full
authentication can be used to enable efficient re-authentication.
o A full EAP method exchange with the authentication server in the
home domain - The other issue of EAP authentication is that the
peer needs to talk to the EAP server in the home domain. In some
networks, e.g., UMTS networks, the authenticating entity talks to
a server in the visited network to support low latency operation.
To be appealing to a wide-range of access networks, it is
necessary for EAP re-authenticatin to support visited domain
authentication. The home EAP/AAA server may enable brokering a
trust relationship between the peer and a local EAP/AAA server, so
that subsequent authentications can be done between the peer and
the visited domain server, without having to traverse the home
domain server.
The two problems identified above are the primary issues to be
resolved. In solving them, there are a number of constraints to
conform to and those result in some additional work to be done in the
area of EAP keying.
Narayanan & Dondeti Expires April 18, 2007 [Page 4]
Internet-Draft EAPext PS October 2006
4. Design goals and constraints
The following are the goals and constraints in designing the EAP re-
authentication and key management protocol:
o Low latency operation - Be responsive to handover and re-
authentication latency performance objectives within a mobile
wireless access network.
o EAP lower layer independence - Any keying hierarchy and protocol
defined should be lower layer independent in order to provide the
capability over heterogeneous technologies. The defined protocols
may, however, require some additional support from the lower
layers that use it.
o Inter-technology hanover - Any keying hierarchy and protocol
defined should accommodate inter-technology heterogeneous handover
and roaming.
o EAP method independence - No changes to EAP methods should be
required as a result of the extensions to EAP itself.
o AAA protocol compatibility - any extensions to EAP and EAP keying
must still be compatible with RADIUS and Diameter.
o The designs and protocols must satisfy the AAA key management
requirements specified in [4].
o Compatibility and especially co-existence with the currently
defined fast transition mechanisms, for instance, IEEE 802.11r is
strongly desired.
o The keying hierarchy or protocol extensions must not preclude the
use of the CAPWAP protocol.
5. Extending the EAP keying hierarchy to support re-authentication
To avoid a full EAP method exchange, we reuse key material from an
earlier EAP authentication: there are two choices for the root key
for re-authentication: the MSK and the EMSK.
5.1. Root key selection for efficient EAP re-authentication
After successful authentication, the MSK is delivered to the
authenticator and used differently by different lower layers. For
instance, IKEv2 uses the MSK for entity authentication alone, while
lower layers like 802.11 and 802.16 use it in the secure association
Narayanan & Dondeti Expires April 18, 2007 [Page 5]
Internet-Draft EAPext PS October 2006
protocol to derive TSKs. Also, different lower layers use different
parts of the MSK to derive other keys from it. For example, IEEE
802.11 uses the first 256 bits of the MSK for TSK derivation and
802.11's Task Group r (TGr) uses the second 256 bits to derive
PMKs-R1 for fast BSS transition. IEEE 802.16 uses the first 320 bits
of the MSK to derive TSKs. Such disparate uses of the MSK at the
lower layers makes it infeasible to use that key as the root key for
re-authentication in a lower-layer independent fashion.
The EMSK key hierarchy on the other hand seems best suited for this
purpose, as it is currently unused and can be specified in such a
manner as to be acceptable to all lower layers. The proposed use
cases for the EMSK are expected to be lower layer agnostic, which is
logical, as it allows us to get around the limitations of lower
layers. For instance the IEEE 802.11r solution for re-association
and re-authentication is limited to a single extended service set
(ESS). Presumably 802.11 would require an IETF defined protocol and
key hierarchy for efficient roaming between ESSs. Most other lower
layers do not currently have a scheme for efficient re-
authentication, and they can make use of the protocols and key
management mechanisms defined at the IETF.
From the discussion so far, it is clear that the EMSK is the
appropriate root key for extensions to EAP keying hierarchy.
5.2. Specification of the EMSK hierarchy and key derivation thereof
To avoid uncoordinated and potentially unsafe uses of the EMSK, or
child key material derived from that key, we propose that one of the
first steps to take is to evaluate the use cases for the EAP key
material and define the EMSK key derivation, caching and delivery
semantics.
Next, we note that some use cases requiring extensions to the EAP
keying hierarchy need more urgent work than the others: the fast re-
authentication application being one such use case. However, given
that the key material may need to come from the EMSK hierarchy for
this and various other purposes, it is imperative that the key
hierarchy development be done in parallel with the usage specific
protocol and hierarchy development.
6. Use Cases and Related Work
In order to further clarify the items listed in scope of the proposed
work, this section provides some background on related work and the
use cases envisioned for the proposed work.
Narayanan & Dondeti Expires April 18, 2007 [Page 6]
Internet-Draft EAPext PS October 2006
6.1. IEEE 802.11r Applicability
One of the EAP lower layers, IEEE 802.11, provides a mechanism to
avoid the problem of repeated full EAP exchanges in a limited
setting, by introducing a two-level key hierarchy. The EAP
authenticator is collocated with what is known as an R0 Key Holder
(R0-KH), which of course receives the MSK from the EAP server. A
pairwise master key (PMK-R0) is derived from the second half (last 32
octets) of the MSK. Subsequently, the R0-KH derives an PMK-R1 to be
handed out to the attachment point of the peer. When the peer moves
from one R1-KH to another, a new PMK-R1 is generated by the R0-KH and
handed out to the new R1-KH. The transport protocol used between the
R0-KH and the R1-KH is not specified at the moment.
In some cases, a mobile may seldom move beyond the domain of the
R0-KH and this model works well. A full EAP authentication will
generally be repeated when the PMK-R0 expires. However, in general
cases mobiles may roam beyond the domain of R0-KHs (or EAP
authenticators), and the latency of full EAP authentication remains
an issue.
Another consideration is that there needs to be a key transfer
protocol between the R0-KH and the R1-KH; in other words, there is
either a star configuration of security associations between the key
holder and a centralized entity that serves as the R0-KH, or if the
first authenticator is the default R0-KH, there will be a full-mesh
of security associations between all authenticators. This is
undesirable.
Furthermore, in the 802.11r architecture, the R0-KH may actually be
located close to the edge, thereby creating a vulnerability: If the
R0-KH is compromised, all PMK-R1s derived from the corresponding PMK-
R0s will also be compromised.
The proposed work on EAP efficient re-authentication protocol aims at
addressing the problem in a lower layer agnostic manner that also can
operate without some of the restrictions or shortcomings of 802.11r
mentioned above.
6.2. CAPWAP Applicability
The IETF CAPWAP WG is developing a protocol between what is termed an
Access Controller (AC) and Wireless Termination Points (WTP). The AC
and WTP can be mapped to a WLAN switch and Access Point respectively.
The CAPWAP model supports both split and integrated MAC
architectures.
The proposed work on EAP efficient re-authentication protocol
Narayanan & Dondeti Expires April 18, 2007 [Page 7]
Internet-Draft EAPext PS October 2006
addresses an inter-authenticator roaming problem from an EAP
perspective. Depending on the architecture of WLAN deployment, this
may apply during handoff across ACs or across WTPs. Inter-controller
handoffs is a topic yet to be addressed in great detail and the re-
authentication work can potentially address that in an effective
manner.
6.3. Inter-technology Roaming
EAP is used for access authentication by several technogies and is
under consideration for use over several other technologies going
forward. Given that, it should be feasible to support smoother
handoffs across technologies. That is one of the big advantages of
using a common authentication protocol. Authentication procedures
typically add substantial handoff delays.
An EAP peer that has multiple radio technologies (802.11 and GSM, for
instance) must perform the full EAP exchange on each interface upon
every horizontal or vertical handoff. With a method independent EAP
efficient re-authentication, it is feasible to support faster
handoffs even in the vertical handoff cases, when the peer may be
roaming from one technology to another.
6.4. Inter-domain Roaming
In several wireless systems, it is common for mobile devices to roam
to domains outside their home domain. For instance, a mobile device
whose home domain operator is based in Europe could be attached to an
operator network in Asia. Typically, the EAP authentication takes
place with the home domain EAP server. Upon handoff across EAP
authenticators, the full EAP exchange with the home domain must
occur. This adds unreasonable latency to the handoffs occurring
within the visited domain.
A method independent EAP efficient re-authentication protocol can be
carried out within the visited domain with the help of a server
located in the visited domain. In this case, it is envisioned that
there are inter-domain trust relationships in place, using which a
trust relationship can be brokered between the peer and the visited
domain server.
7. Security Considerations
In this version of the draft, we just note that the "Guidance for AAA
Key Management" [4] applies to the protocols and key hierarchies
developed to solve the problems listed within.
Narayanan & Dondeti Expires April 18, 2007 [Page 8]
Internet-Draft EAPext PS October 2006
8. IANA Considerations
This document does not request any IANA assignments.
9. Acknowledgments
Thanks to Joe Salowey, Bernard Aboba, Russ Housley, Michaela
Vanderveen, George Tsirtsis and Hesham Soliman for various
discussions on this topic.
10. References
10.1. References
[1] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748,
June 2004.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Aboba, B., "Extensible Authentication Protocol (EAP) Key
Management Framework", draft-ietf-eap-keying-14 (work in
progress), June 2006.
10.2. References
[4] Housley, R. and B. Aboba, "Guidance for AAA Key Management",
draft-housley-aaa-key-mgmt-04 (work in progress), October 2006.
[5] 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.
[6] Arkko, J. and H. Haverinen, "Extensible Authentication Protocol
Method for 3rd Generation Authentication and Key Agreement (EAP-
AKA)", RFC 4187, January 2006.
[7] Narayanan, V. and L. Dondeti, "Gap analysis on the EAP keying
hierarchy", draft-vidya-eap-keying-gap-analysis-00 (work in
progress), April 2006.
Narayanan & Dondeti Expires April 18, 2007 [Page 9]
Internet-Draft EAPext PS October 2006
Authors' Addresses
Vidya Narayanan
QUALCOMM, Inc.
5775 Morehouse Dr
San Diego, CA
USA
Phone: +1 858-845-2483
Email: vidyan@qualcomm.com
Lakshminath Dondeti
QUALCOMM, Inc.
5775 Morehouse Dr
San Diego, CA
USA
Phone: +1 858-845-1267
Email: ldondeti@qualcomm.com
Narayanan & Dondeti Expires April 18, 2007 [Page 10]
Internet-Draft EAPext PS October 2006
Full 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.
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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Narayanan & Dondeti Expires April 18, 2007 [Page 11]