Internet DRAFT - draft-clancy-eap-rekeying
draft-clancy-eap-rekeying
Network Working Group T. Clancy
Internet-Draft N. Petroni
Expires: August 8, 2004 W. Arbaugh
University of Maryland
February 8, 2004
Technique for Method-Specific Fast EAP Rekeying
draft-clancy-eap-rekeying-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 8, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
A technique for fast rekeying with EAP is described here. The actual
implementation is specific to each EAP method, but in general a
master session key can be evolved with each client association such
that the authentication requires as many packets exchanges as a
"canned success". The concept is explained, with a specific
implementation described for EAP-TLS with 802.11i.
Clancy, et al. Expires August 8, 2004 [Page 1]
Internet-Draft Fast EAP Rekeying February 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Language Requirements . . . . . . . . . . . . . . . . . . . . 3
1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Protocol Specification . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. Example: EAP-TLS and 802.11i . . . . . . . . . . . . . . . . . 8
6. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 9
Normative References . . . . . . . . . . . . . . . . . . . . . 9
Informative References . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . 12
Clancy, et al. Expires August 8, 2004 [Page 2]
Internet-Draft Fast EAP Rekeying February 2004
1. Introduction
This document describes an EAP [I-D.ietf-eap-rfc2284bis]
method-specific rekeying technique that is both fast and secure. The
goal is to provide a technique by which a client and an
authentication server can use a preexisting master key and master
session key to establish a new session key in a minimal number of
packet exchanges.
Fast rekeying is desirable in many situations. For example, a mobile
802.11 client using 802.1X authentication would benefit from the
ability to quickly derive new keys when associating with a new
wireless access point.
In this document, the protocol and cryptographic operations required
to implement this fast rekeying technique are described, and a
complete example using TLS is provided.
1.1 Language Requirements
In this document, several words are used to signify the requirements
of the specification. These words are often capitalized. 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].
1.2 Terminology
Much of this terminology is defined in the EAP Key Management
Framework [I-D.ietf-eap-keying].
peer
The end client wishing to authenticate.
authenticator
The device initiating and enforcing authentication, often passing
the authentication through to a backend EAP server through an AAA
server. In 802.11, this is the Access Point (AP).
AAA server
Authentication, authorization, and accounting server responsible
for passing EAP requests from the authenticator to the local EAP
server methods.
Clancy, et al. Expires August 8, 2004 [Page 3]
Internet-Draft Fast EAP Rekeying February 2004
EAP server
Backend of the EAP methods, responsible for performing
authentication and key generation.
EAP protocol
The protocol between the peer and authenticator.
AAA protocol
The protocol between the authenticator and the AAA server.
MK
Master Key between the peer and EAP server from which all other
EAP method session keys are derived. In TLS, this is the master
secret.
MSK
Master Session Key generated from the MK and exported by the EAP
method to the authenticator.
EMSK
Extended Master Session Key also generated from the MK and
contains additional keying material for future use.
These terms are illustrated in the following figure.
Clancy, et al. Expires August 8, 2004 [Page 4]
Internet-Draft Fast EAP Rekeying February 2004
+--------+ MK +--------+
| | <-------------------------------> | |
| EAP | <---------------+---------------- | EAP |
| method | | MSK | method |
+--------+ V +--------+
| | +---------+ | |
| EAP | EAP | | protocol | EAP |
| peer | <===============================> | server |
+--------+ | | +--------+
| | MAC/LLC | Authen- | AAA | |
| client | <========> | ticator | <========> | AAA |
| | protocol | | protocol | server |
+--------+ +---------+ +--------+
Figure 1: Overview of EAP Terminology
2. Overview
The fast rekeying protocol, which utilizes the EAP Identity message
to notify the EAP server of a request for fast handoff, minimizes the
number of messages between the authenticator and the AAA server and
requires no changes to the existing EAP or AAA protocols. In fact, to
the casual observer the exchange looks exactly like a "canned
success", the term provided by [I-D.ietf-eap-rfc2284bis] for granting
network access immediately without performing authentication.
However, while in the case of "canned success" all clients are
provided access, the fast authentication scheme described here
actually encapsulates its proof of identity inside of the EAP
Identity Response so that the EAP server can make an informed
decision without performing a complete authentication. The principle
behind the scheme is simple--reduce the conversation to the minimal
number of messages required by the existing infrastructure and
provide the necessary protections to insure the result is no less
secure than a full authentication.
One of the fundamental design goals of this reactive approach is to
avoid changes to the authenticator. This goal is motivated by EAP's
popularity in 802.11 and 802.1X environments. Here, an access point
(AP) acts as the authenticator, and is likely the most difficult and
costly equipment to replace and upgrade. The ability to upgrade to a
fast-handoff scheme without buying new equipment or spending large
amounts of time reflashing old equipment is a clear win. Second, the
majority of 802.1X equipment on the market has been well tested for
interoperability. Vendors would have far less overhead in rapidly
deploying a fast-handoff scheme if fewer protocol changes needed to
be made. Unlike access points, clients and AAA servers are more
Clancy, et al. Expires August 8, 2004 [Page 5]
Internet-Draft Fast EAP Rekeying February 2004
easily upgraded. AAA servers are fewer in number than access points
and typically have general purpose processors and operating systems.
Client updates are simple as well since the work load is divided
among users who can trivially install software patches.
+--------+ <------- EAP ID +---------+ +--------+
| | Request | | | |
| | | | | |
| | EAP ID -------> | | Access -------> | |
| | Response | | Request | |
| CLIENT | | AUTHEN- | | AAA |
| | <---------- EAP | TICATOR | <------- Access | SERVER |
| | Success | | Accept | |
| | | | | |
| | <-- Secure ---> | | | |
+--------+ Association +---------+ +--------+
Figure 2: The Reactive Fast-Handoff Exchange
The protocol detailed in the figure above starts with the standard
EAP Identity Request and Response sequence. The fast rekeying only
works after a normal, full authentication has begun the user's
session. This full authentication uses a specific EAP method to
produce a Master Key that is then used to bootstrap a set of keys for
communication between the peer and the authenticator. Once this MK
and a corresponding MSK are in place, future MSKs can be calculated
by both the client and authentication server.
In this scheme, a client that is using a valid MSK can request a fast
handoff by including proof of knowledge of the MSK in the identity
response, along with the user's identity. The authentication server
then performs a trivial check for whether or not the Identity
Response contains such proof, checks to make sure the proof is valid,
and if so, immediately responds with an Access Accept containing an
EAP Success packet and the new MSK (encrypted for the authenticator).
For this protocol we define the MSKID, which serves as proof of
knowledge of the MSK.
3. Protocol Specification
One of the main benefits of this keying technique is that the AAA and
EAP protocols do not need to be altered. The only difference is a
change in the encoding of the identity in the EAP Identity Response
message. The MSKID can be appended to the null-terminated string
identifying the authenticating entity. This string is then passed
unaltered by the authenticator to the AAA server. The AAA server can
Clancy, et al. Expires August 8, 2004 [Page 6]
Internet-Draft Fast EAP Rekeying February 2004
recognize additional data exists beyond the null character by
noticing the field length is not equal to the string length.
Provided the AAA server can validate the client-supplied MSKID, the
remainder of the exchanges conform to the EAP canned-success method
as described in [I-D.ietf-eap-rfc2284bis], where an EAP success
message is followed with keying messages.
Note that some EAP methods encode additional options after a null
byte in the identity response. If this is the case, structure may be
required following the null character to identify the options.
After the MSKID has been verified by the EAP server, both the EAP
server and the EAP peer need to generate the new MSK and EMSK. These
values must be a function of both the MK and MSK or EMSK
respectively. The exact manner this is done is method specific, but
it should be computationally difficult to recover the MK, or
determine the new MSK without knowledge of the MK and old MSK.
The new MSK and EMSK can now be exported from the EAP method and used
to generate other session-specific keys.
4. Security Considerations
The goal of this scheme is provide a mechanism to further derive
pairwise keys between the EAP server, authenticator, and EAP peer,
and consequently new session keys between the client and
authenticator. Since only the EAP peer and EAP server know the MK, a
new MSK derived from them is only initially known by the EAP peer and
EAP server. Therefore, we need not trust authenticators to which we
are no longer associated.
It is important that the keys derived from the new MSK are used for
link-layer encryption. In this fast-rekeying scheme, a client is not
authenticated until the new keys are used, and the client proves he
or she indeed knows them. Knowledge of the MSKID is not sufficient.
The MSKID is used primarily for efficiency reasons, as it offers
little protocol security. Anyone could perform a man-in-the-middle
attack to obtain the EAP Identity Response packet containing the
MSKID, and use it to authenticate. However without both the MK and
old MSK, the attacker cannot compute the new MSK, and therefore would
not be able to decrypt the new keying material and communicate with
the authenticator. The purpose of the MSKID is to make sure a client
is capable of computing the new MSK by proving he or she knows the
old one. If the EAP server receives an invalid MSKID, it can
immediately request a full authentication without the initial
reauthentication first failing.
Clancy, et al. Expires August 8, 2004 [Page 7]
Internet-Draft Fast EAP Rekeying February 2004
The worst an attacker could do is force a client to perform a full
authentication during each reassociation, however significantly more
detrimental denial of service attacks exist for most link-layer
protocols.
5. Example: EAP-TLS and 802.11i
Here we present a concrete example that uses the transaction layer
security (TLS) EAP method, under the protocol recommendations of
802.11i. A version of our original diagram is presented below, with
the EAP-TLS and 802.11i vocabulary substituted for the original
terms.
+--------+ Master Secret (MS) +--------+
| EAP- | <-------------------------------> | EAP- |
| TLS | <---------------+---------------- | TLS |
| method | Pairwise|Master Key (PMK) | method |
+--------+ V +--------+
| | +---------+ | |
| supp- | EAP | | protocol | EAP |
| licant | <===============================> | server |
+--------+ | | +--------+
| | 802.11 | Access | RADIUS | |
| client | <========> | Point | <========> | RADIUS |
| | protocol | | protocol | server |
+--------+ +---------+ +--------+
Figure 3: Network Diagram for 802.11i using EAP-TLS
With EAP-TLS, the MSKID used is the 802.11i-defined PMKID. This is
computed by concatenating the string "PMK Name" with the 6-byte
802.11 MAC addresses of the access point and wireless client, and
then putting that string through a SHA-1 hash keyed with the current
PMK. The supplicant obviously knows its own MAC and the MAC of the AP
to which it is associated. Additionally, the RADIUS protocol provides
all the necessary MAC addresses to the EAP server methods.
PMKID = HMAC-SHA1-128 (PMK, "PMK Name" || AP-MAC-address ||
Client-MAC-Address)
Thus, the resulting EAP Identity Response packet is as follows:
Clancy, et al. Expires August 8, 2004 [Page 8]
Internet-Draft Fast EAP Rekeying February 2004
|<---- Standard EAP Identity Response ---->|
+------+--------+--------+------+----------+------+---------+
| Code | 1-byte | 2-byte | Type | Identity | 0x00 | 16-byte |
| 0x01 | ID | Length | 0x01 | | | PMKID |
+------+--------+--------+------+----------+------+---------+
|<--- length field value -->|
Figure 4
Next, the master secret and the TLS pseudorandom function (PRF) are
used to generate new keys. The PMK is concatenated with the AP and
Client MAC addresses and sent through the TLS pseudorandom function.
PMK' = TLS-PRF (MS, PMK || AP-MAC-Address || Client-MAC-Address)
6. Acknowledgment
The authors would like to thank Pasi Eronen of the Nokia Research
Center, and Kyunghun Jang and Insun Lee of Samsung Electronics for
contributions and feedback. This work was funded in part by a grant
from Samsung Electronics, 0307158417, and the U.S. National Institute
for Standards and Technology Critical Infrastructure Grant
60NANB1D0113.
Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication
Protocol", RFC 2716, October 1999.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
Dial In User Service) Support For Extensible
Authentication Protocol (EAP)", RFC 3579, September 2003.
[I-D.ietf-eap-rfc2284bis]
Blunk, L., "Extensible Authentication Protocol (EAP)",
draft-ietf-eap-rfc2284bis-07 (work in progress), December
2003.
[I-D.ietf-eap-keying]
Aboba, B., Simon, D., Arkko, J., Eronen, P. and H.
Levkowetz, "EAP Key Management Framework",
Clancy, et al. Expires August 8, 2004 [Page 9]
Internet-Draft Fast EAP Rekeying February 2004
draft-ietf-eap-keying-02b (work in progress), November
2003.
[IEEE.80211]
Institute of Electrical and Electronics Engineers,
"Information technology - Telecommunications and
information exchange between systems - Local and
metropolitan area networks - Specific Requirements Part
11: Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) Specifications", IEEE Standard 802.11-1997,
1997.
[IEEE.80211i]
Institute of Electrical and Electronics Engineers, "Draft
Supplement to STANDARD FOR Telecommunications and
Information Exchange between Systems - LAN/MAN Specific
Requirements - Part 11: Wireless Medium Access Control
(MAC) and physical layer (PHY) specifications:
Specification for Enhanced Security", IEEE Draft 802.11I/
D6.1, August 2003.
Informative References
[MIS04] Mishra, A., Shin, M., Petroni, N., Clancy, T. and W.
Arbaugh, "Proactive Key Distribution Using Neighbor Graphs",
IEEE Wireless Communications, February 2004.
Authors' Addresses
T. Charles Clancy III
University of Maryland, College Park
A.V. Williams Building
College Park, MD 20742
USA
EMail: clancy@cs.umd.edu
Nick L. Petroni, Jr.
University of Maryland, College Park
A.V. Williams Building
College Park, MD 20742
USA
EMail: npetroni@cs.umd.edu
Clancy, et al. Expires August 8, 2004 [Page 10]
Internet-Draft Fast EAP Rekeying February 2004
William A. Arbaugh
University of Maryland, College Park
A.V. Williams Building
College Park, MD 20742
USA
EMail: waa@cs.umd.edu
Clancy, et al. Expires August 8, 2004 [Page 11]
Internet-Draft Fast EAP Rekeying February 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Clancy, et al. Expires August 8, 2004 [Page 12]
Internet-Draft Fast EAP Rekeying February 2004
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Clancy, et al. Expires August 8, 2004 [Page 13]
