Internet DRAFT - draft-dondeti-eapext-ps
draft-dondeti-eapext-ps
Network Working Group L. Dondeti
Internet-Draft V. Narayanan
Expires: December 21, 2006 QUALCOMM, Inc.
June 19, 2006
EAP Extensions Problem Statement
draft-dondeti-eapext-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 December 21, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The extensible authentication protocol (EAP), specified in RFC3748
[1] is a generic framework supporting multiple authentication
methods. The EAP keying hierarchy specified in [2] has two top level
keys: a master session key (MSK) and an extended MSK (EMSK). The MSK
is used for access control enforcement, whereas the purpose of EMSK
is to be defined. Several proposals for the use of the EMSK have
been made, among them are support for efficient re-authentication of
the EAP peer as it moves from one authenticator to another,
Dondeti & Narayanan Expires December 21, 2006 [Page 1]
Internet-Draft EAPext PS June 2006
bootstrapping preshared keys, visited domain key management. In this
document, we explore the various proposed uses of the EMSK key
hierarchy and the design considerations in specifying the EMSK key
hierarchy.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Candidate use cases . . . . . . . . . . . . . . . . . . . 3
1.2. Key material selection for additional uses of EAP
authentication . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Proposed and potential use cases for EMSK . . . . . . . . 5
3.2. Summary of Gaps in EAP . . . . . . . . . . . . . . . . . . 6
3.3. Scope of Proposed Work . . . . . . . . . . . . . . . . . . 7
4. Applicability and Related Work . . . . . . . . . . . . . . . . 7
4.1. IEEE 802.11r Applicability . . . . . . . . . . . . . . . 7
4.2. CAPWAP Applicability . . . . . . . . . . . . . . . . . . . 8
4.3. Kerberos Applicability . . . . . . . . . . . . . . . . . . 8
5. Design goals and constraints . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. References . . . . . . . . . . . . . . . . . . . . . . . . 10
9.2. References . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13
Dondeti & Narayanan Expires December 21, 2006 [Page 2]
Internet-Draft EAPext PS June 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.
1.1. Candidate use cases
When a peer moves from one authenticator to another, it is desirable
to avoid full EAP authentication. The full EAP exchange with another
run of the EAP method takes several round trips and significant time
to complete, causing delays in handoff times. Some methods specify
the use of state from the initial authentication to finish subsequent
authentications to finish in fewer roundtrips. However, most methods
do not offer this feature. Thus, it is beneficial to have efficient
re-authentication support in EAP rather than in individual methods.
For this purpose we need key material derived via a full EAP
authentication.
Related to an efficient re-authentication is faster roaming in a
visited domain. While basic EAP handles visited domain
authentication via the home EAP/AAA server, any authentication must
pass through the home server every time. It is desirable to optimize
handoffs while in the visited domain. 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. It is important that such a
solution attempt to preserve the stateless nature of AAA proxies.
Another candidate use case is pre-configuration of shared secrets
between the peer and other entity that provides network services.
Setting up such PSKs is an administrative burden. The most common
solution is to configure a password or a symmetric key and use it for
several purposes: entity authentication and key generation in various
uncoordinated ways. In most cases, PSKs are generally not changed
often enough in practice and are not as strong as they need to be.
Dondeti & Narayanan Expires December 21, 2006 [Page 3]
Internet-Draft EAPext PS June 2006
If a bootstrapping key for such upper layer services can, in fact, be
derived from the EAP keying hierarchy in place of such PSKs, it can
yield stronger and periodically changing keys, allowing for better
security practices without the administrative burden.
1.2. Key material selection for additional uses of EAP authentication
Given that the proposal is to reuse key material from an earlier EAP
authentication, there are two choices as the root key for these
various use cases: the MSK and the EMSK.
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 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. 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 the MSK for general purpose key material
derivation. The EMSK key hierarchy on the other hand is in initial
stages of specification.
From the discussion so far, it is clear that the EMSK is the
appropriate root key for extensions to EAP keying hierarchy.
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.
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 [3].
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:
Dondeti & Narayanan Expires December 21, 2006 [Page 4]
Internet-Draft EAPext PS June 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 [4].
3. Problem Statement
The overarching problem we propose to tackle is to take stock of the
various proposed and potential use cases of the EAP key material.
MSK handling by various EAP lower layers in disparate ways is
acceptable since the stated handling of that key is to deliver it to
the authenticator, an entity within the realm of the lower layer, and
allow the authenticator to use it as required by the lower layer.
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.
To avoid uncoordinated and potentially unsafe uses of the EMSK, or
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.
3.1. Proposed and potential use cases for EMSK
We discuss three proposed use cases for keys from the key hierarchy
in the following:
EAP fast re-authentication There have been significant discussions
around the area of faster handoffs within and across technologies
that employ EAP-based authentication. Inter-authenticator
handoffs typically result in a full EAP exchange, leading to
unacceptable handoff latency. A more efficient EAP re-
authentication mechanism will allow for faster authentication
procedures. This has also been termed as "handover keying" in the
HOAKEY discussions and documents. There is a need to develop such
a re-authentication mechanism at the IETF in a link layer agnostic
manner to allow easy adoption across the different link layers
using EAP.
EMSK KH for visited domains: Related to an efficient re-
authentication is faster roaming in a visited domain. While basic
EAP handles visited domain authentication via the home EAP/AAA
server, any authentication must pass through the home server every
Dondeti & Narayanan Expires December 21, 2006 [Page 5]
Internet-Draft EAPext PS June 2006
time. It is desirable to optimize handoffs while in the visited
domain. 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. It is important that such a solution attempt to preserve
the stateless nature of AAA proxies.
PSK bootstrapping: Many upper layer protocols require the pre-
configuration of shared secrets between the peer and the AAA
server for setting up a security association between the peer and
a third entity. Setting up such PSKs is an administrative burden.
In order to circumvent this issue, a single root key for a client
is often configured and shared for several purposes. Further,
such PSKs are generally not changed often enough in practice and
are not as strong as they need to be. If a bootstrapping key for
such upper layer services can, in fact, be derived from the EAP
keying hierarchy in place of such PSKs, it can yield stronger and
periodically changing keys, allowing for better security practices
without the administrative burden. Largely, all of the work
discussed above is likely to require the use of the EAP EMSK.
With the definition of EMSK usage leading to Usage Specific Root
Keys (USRKs), additional work is required to actually define a
USRK and its usage.
3.2. Summary of Gaps in EAP
The EAP specification and the EAP keying framework have some gaps in
the specification that are brought to fore by the proposed and
potential usage cases specified above. A gap analysis on EAP keying
is provided in [5]. A brief summary of the gaps in EAP are as listed
below.
EMSK usage specification: The EMSK usage is currently undefined in
EAP keying. The usage of EMSKs for Usage Specific Root Key (USRK)
derivation is separately described in [4].
EAP re-authentication protocol and key hierarchy specification EAP
currently does not have a re-authentication mechanism. Some EAP
methods do have fast re-authentication or session resumption -
however, those still require a minimum of two roundtrips to the
server.
Visited domain key hierarchy specification EAP keying currently
provides no optimization for authentication in the visited domain.
Dondeti & Narayanan Expires December 21, 2006 [Page 6]
Internet-Draft EAPext PS June 2006
Specification of PSK provisioning using EAP keying EAP is currently
only specified for network access and provides keying material
that is used by the authenticator for providing lower layer
security.
Definition of channel binding The term channel binding is somewhat
loosely defined in [2]. The term is used by different people to
mean different things in terms of what it provides and how it can
be achieved. A good analysis of what can be achieved via channel
binding and a study of practical implications of the same are yet
to be done.
3.3. Scope of Proposed Work
Given the background, the use cases, and the gap analysis, there is a
long list of EAP related work items to be done at the IETF. However,
a prioritization is necessary to get the most important and urgent
work done in a timely manner. We propose the following subset of the
work items:
EMSK usage specification
EAP re-authentication protocol and key hierarchy specification
Visited domain key hierarchy specification
Specification of PSK provisioning using EAP keying
4. Applicability 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 how
the proposed work differs from it.
4.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.
Dondeti & Narayanan Expires December 21, 2006 [Page 7]
Internet-Draft EAPext PS June 2006
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.
4.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 protocol 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. Hence, this is complementary and does not
conflict with the CAPWAP work.
4.3. Kerberos Applicability
Upper layer PSK bootstrapping and visited domain roaming are part of
the proposed work items. The motivation for this work has already
been discussed. At a concept level, however, Kerberos provides some
of the functionality needed to solve these problems.
Kerberos provides a means of authenticating to the home
authentication infrastructure. This establishes keying material that
Dondeti & Narayanan Expires December 21, 2006 [Page 8]
Internet-Draft EAPext PS June 2006
can be used to derive new keying material for applications and
services. One of the applications and services clients can get
keying material for is visited domain authentication infrastructure.
There is a relatively fast exchange to prove knowledge of keying
material and to use that to derive keying material for a new service
that the client needs to access.
Kerberos has been a candidate for fast handoffs as shown by proposals
for inter-provider roaming in RADIUS, the early IEEE 802.11i design
(which mandated Kerberos support), and the IEEE 802.11r MDC protocol
design (which looked at writing a Kerberized application for inter-
authenticator handoff). For example, it is possible for the peer to
obtain a ticket as a result of the original EAP exchange. The AAA
server could return the ticket in the Access-Accept, and the
authenticator could give it to the peer via a link-layer exchange.
There are, however, a number of questions that would need to be
answered as to how this would work, and whether this can use Kerberos
as is, or whether it requires extensions or a new "Kerberos-like"
protocol. For instance, the authenticators cannot be assumed to
support Kerberos. Also, IP address use for link layer access is
typically not a good model.
Further, while shared key bootstrapping for applications using
Kerberos is well defined, similar concerns exist. For instance,
support for Kerberos in all the parties involved cannot be assumed,
while the support for AAA-based models do exist in systems that
employ EAP. Also, the goal of PSK bootstrapping via EAP is to be
able to leverage the keying material produced during network access
to provide stronger PSKs for services in cases where the support for
Kerberos cannot be assumed.
5. Design goals and constraints
The following are the design goals for protocols extending the EAP
keying hierarchy.
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 EAP method independence - No changes to EAP methods should be
required as a result of the extensions to EAP itself.
Dondeti & Narayanan Expires December 21, 2006 [Page 9]
Internet-Draft EAPext PS June 2006
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 [6].
o Compatibility with the currently defined fast transition
mechanisms in IEEE 802.11r is strongly desired.
o The keying hierarchy or protocol extensions must not preclude the
use of the CAPWAP protocol.
6. Security Considerations
In this version of the draft, we just note that the "Guidance for AAA
Key Management" [6] applies to the protocols and key hierarchies
developed to solve the problems listed within.
7. IANA Considerations
This document does not request any IANA assignments.
8. Acknowledgments
In writing this draft, we benefited from discussing the problem space
with a number of folks including, Bernard Aboba, Jari Arkko, Sam
Hartman, Russ Housley, Joe Salowey, and Jesse Walker. Note that this
does not necessarily mean that they endorse this work or support it.
9. References
9.1. References
[1] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748,
June 2004.
[2] Aboba, B., "Extensible Authentication Protocol (EAP) Key
Management Framework", draft-ietf-eap-keying-13 (work in
progress), May 2006.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
Dondeti & Narayanan Expires December 21, 2006 [Page 10]
Internet-Draft EAPext PS June 2006
9.2. References
[4] Salowey, J., "Specification for the Derivation of Usage Specific
Root Keys (USRK) from an Extended Master Session Key (EMSK)",
draft-salowey-eap-emsk-deriv-00 (work in progress), May 2006.
[5] Narayanan, V. and L. Dondeti, "Gap analysis on the EAP keying
hierarchy", draft-vidya-eap-keying-gap-analysis-00 (work in
progress), April 2006.
[6] Housley, R. and B. Aboba, "Guidance for AAA Key Management",
draft-housley-aaa-key-mgmt-02 (work in progress), March 2006.
Dondeti & Narayanan Expires December 21, 2006 [Page 11]
Internet-Draft EAPext PS June 2006
Authors' Addresses
Lakshminath Dondeti
QUALCOMM, Inc.
5775 Morehouse Dr
San Diego, CA
USA
Phone: +1 858-845-1267
Email: ldondeti@qualcomm.com
Vidya Narayanan
QUALCOMM, Inc.
5775 Morehouse Dr
San Diego, CA
USA
Phone: +1 858-845-2483
Email: vidyan@qualcomm.com
Dondeti & Narayanan Expires December 21, 2006 [Page 12]
Internet-Draft EAPext 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.
Dondeti & Narayanan Expires December 21, 2006 [Page 13]
