draft-ietf-eap-keying-01.txt   draft-ietf-eap-keying-02.txt 
EAP Working Group B. Aboba EAP Working Group Bernard Aboba
Internet-Draft D. Simon INTERNET-DRAFT Dan Simon
Expires: April 26, 2004 Microsoft Category: Informational Microsoft
J. Arkko <draft-ietf-eap-keying-02.txt> J. Arkko
Ericsson 26 June 2004 Ericsson
P. Eronen
Nokia
H. Levkowetz, Ed. H. Levkowetz, Ed.
ipUnplugged ipUnplugged
October 27, 2003
EAP Key Management Framework Extensible Authentication Protocol (EAP) Key Management Framework
<draft-ietf-eap-keying-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress". material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at
www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 26, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This document provides a framework for EAP key management, including The Extensible Authentication Protocol (EAP), defined in [RFC3748],
a statement of applicability and guidelines for generation, transport enables extensible network access authentication. This document
and usage of EAP keying material. Algorithms for key derivation or provides a framework for the generation, transport and usage of
mechanisms for key transport are not specified in this document. keying material generated by EAP authentication algorithms, known as
Rather, this document provides a framework within which algorithms "methods".
and transport mechanisms can be discussed and evaluated.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction .......................................... 4
1.1 Requirements Language . . . . . . . . . . . . . . . . 4 1.1 Requirements Language ........................... 4
1.2 Terminology . . . . . . . . . . . . . . . . . . . . . 4 1.2 Terminology ..................................... 4
1.3 Conversation Overview . . . . . . . . . . . . . . . . 6 1.3 Overview ........................................ 5
1.3.1 Discovery Phase . . . . . . . . . . . . . . . . 7 1.4 EAP Invariants .................................. 11
1.3.2 Authentication Phase . . . . . . . . . . . . . . 8 2. EAP Key Hierarchy ..................................... 13
1.3.3 Secure Association Phase . . . . . . . . . . . . 9 2.1 Key Terminology ................................. 13
1.4 Authorization issues . . . . . . . . . . . . . . . . . 9 2.2 Key Hierarchy ................................... 15
1.4.1 Correctness in fast handoff . . . . . . . . . . 11 2.3 Key Lifetimes ................................... 17
2. EAP Key Hierarchy . . . . . . . . . . . . . . . . . . . . . 13 2.4 AAA-Key Scope ................................... 24
2.1 EAP Invariants . . . . . . . . . . . . . . . . . . . . 14 2.5 Fast Handoff Support ............................ 26
2.1.1 Media Independence . . . . . . . . . . . . . . . 14 3. Security associations ................................. 30
2.1.2 Method Independence . . . . . . . . . . . . . . 14 3.1 EAP Method SA ................................... 31
2.1.3 Ciphersuite Independence . . . . . . . . . . . . 14 3.2 EAP-Key SA ...................................... 33
2.2 Key Hierarchy . . . . . . . . . . . . . . . . . . . . 15 3.3 AAA SA(s) ....................................... 33
2.3 Exchanges . . . . . . . . . . . . . . . . . . . . . . 19 3.4 Service SA(s) ................................... 34
3. Security Associations . . . . . . . . . . . . . . . . . . . 22 3.5 SA Naming ....................................... 37
3.1 EAP SA (peer - EAP server) . . . . . . . . . . . . . . 23 4. Security Considerations .............................. 39
3.2 EAP method SA (peer - EAP server) . . . . . . . . . . 23 4.1 Security Terminology ............................ 39
3.2.1 Example: EAP-TLS . . . . . . . . . . . . . . . . 24 4.2 Threat Model .................................... 39
3.2.2 Example: EAP-AKA . . . . . . . . . . . . . . . . 24 4.3 Security Analysis ............................... 41
3.3 EAP-key SA . . . . . . . . . . . . . . . . . . . . . . 25 4.4 Man-in-the-middle Attacks ....................... 45
3.4 AAA SA(s) (authenticator - backend auth. server) . . . 25 4.5 Denial of Service Attacks ....................... 45
3.4.1 Example: RADIUS . . . . . . . . . . . . . . . . 25 4.6 Impersonation ................................... 46
3.4.2 Example: Diameter with TLS . . . . . . . . . . . 25 4.7 Channel Binding ................................. 47
3.5 Unicast Secure Association SA . . . . . . . . . . . . 26 4.8 Key Strength .................................... 48
3.6 Multicast Secure Association SA . . . . . . . . . . . 27 4.9 Key Wrap ........................................ 48
3.7 Key Naming . . . . . . . . . . . . . . . . . . . . . . 28 5. Security Requirements ................................. 49
4. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 29 5.1 EAP Method Requirements ......................... 49
4.1 Security Assumptions . . . . . . . . . . . . . . . . . 29 5.2 AAA Protocol Requirements ....................... 52
4.2 Security Requirements . . . . . . . . . . . . . . . . 32 5.3 Secure Association Protocol Requirements ........ 54
4.2.1 EAP method requirements . . . . . . . . . . . . 32 5.4 Ciphersuite Requirements ........................ 55
4.2.2 AAA Protocol Requirements . . . . . . . . . . . 34 6. IANA Considerations ................................... 56
4.2.3 Secure Association Protocol Requirements . . . . 36 7. References ............................................ 56
4.2.4 Ciphersuite Requirements . . . . . . . . . . . . 37 7.1 Normative References ............................ 56
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 38 7.2 Informative References .......................... 57
6. Security Considerations . . . . . . . . . . . . . . . . . . 38 Acknowledgments .............................................. 60
6.1 Key Strength . . . . . . . . . . . . . . . . . . . . . 38 Author's Addresses ........................................... 61
6.2 Key Wrap . . . . . . . . . . . . . . . . . . . . . . . 38 Appendix A - Ciphersuite Keying Requirements ................. 62
6.3 Man-in-the-middle Attacks . . . . . . . . . . . . . . 39 Appendix B - Transient EAP Key (TEK) Hierarchy ............... 63
6.4 Impersonation . . . . . . . . . . . . . . . . . . . . 39 Appendix C - EAP Key Hierarchy ............................... 64
6.5 Denial of Service Attacks . . . . . . . . . . . . . . 40 Appendix D - Transient Session Key (TSK) Derivation .......... 66
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41 Appendix E - AAA-Key Derivation .............................. 67
Normative References . . . . . . . . . . . . . . . . . . . . 41 Intellectual Property Statement .............................. 68
Informative References . . . . . . . . . . . . . . . . . . . 41 Full Copyright Statement ..................................... 68
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 45
A. Ciphersuite Keying Requirements . . . . . . . . . . . . . . 46
B. Transient EAP Key (TEK) Hierarchy . . . . . . . . . . . . . 47
C. MSK and EMSK Hierarchy . . . . . . . . . . . . . . . . . . . 48
D. Transient Session Key (TSK) Derivation . . . . . . . . . . . 51
E. AAA-Key Derivation . . . . . . . . . . . . . . . . . . . . . 52
F. Open issues . . . . . . . . . . . . . . . . . . . . . . . . 53
Intellectual Property and Copyright Statements . . . . . . . 54
1. Introduction 1. Introduction
The Extensible Authentication Protocol (EAP), defined in The Extensible Authentication Protocol (EAP), defined in [RFC3748],
[I-D.ietf-eap-rfc2284bis], was designed to enable extensible was designed to enable extensible authentication for network access
authentication for network access in situations in which the IP in situations in which the IP protocol is not available. Originally
protocol is not available. Originally developed for use with PPP developed for use with PPP [RFC1661], it has subsequently also been
[RFC1661], it has subsequently also been applied to IEEE 802 wired applied to IEEE 802 wired networks [IEEE8021X].
networks [IEEE8021X].
This document provides a framework for the generation, transport and This document provides a framework for the generation, transport and
usage of keying material generated by EAP authentication algorithms, usage of keying material generated by EAP authentication algorithms,
known as "methods". Since in EAP keying material is generated by EAP known as "methods". Since in EAP keying material is generated by EAP
methods, transported by AAA protocols, transformed into session keys methods, transported by AAA protocols, transformed into session keys
by secure association protocols and used by lower layer ciphersuites, by Secure Association Protocols and used by lower layer ciphersuites,
it is necessary to describe each of these elements and provide a it is necessary to describe each of these elements and provide a
system-level security analysis. system-level security analysis.
1.1 Requirements Language 1.1. Requirements Language
In this document, several words are used to signify the requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
of the specification. These words are often capitalized. The key "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", document are to be interpreted as described in BCP 14 [RFC2119].
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
are to be interpreted as described in BCP 14 [RFC2119].
1.2 Terminology 1.2. Terminology
This document frequently uses the following terms: This document frequently uses the following terms:
authenticator authenticator
The end of the link initiating EAP authentication. Where no The end of the link initiating EAP authentication. The term
backend authentication server is present, the authenticator acts Authenticator is used in [IEEE-802.1X], and authenticator has the
as the EAP server, terminating the EAP conversation with the peer. same meaning in this document.
Where a backend authentication server is present, the
authenticator may act as a pass-through for one or more peer The end of the link that responds to the authenticator. In
authentication methods and for non-local users. This terminology [IEEE-802.1X], this end is known as the Supplicant.
is also used in [IEEE8021X], and has the same meaning in this
document. Supplicant
The end of the link that responds to the authenticator in
[IEEE-802.1X]. In this document, this end of the link is called
the peer.
backend authentication server backend authentication server
A backend authentication server is an entity that provides an A backend authentication server is an entity that provides an
authentication service to an authenticator. When used, this authentication service to an authenticator. When used, this server
server typically executes EAP Methods for the authenticator. This typically executes EAP methods for the authenticator. This
terminology is also used in [IEEE8021X]. terminology is also used in [IEEE-802.1X].
AAA-Token AAA Authentication, Authorization and Accounting. AAA protocols with
The package within which keying material and one or more EAP support include RADIUS [RFC3579] and Diameter [I-D.ietf-aaa-
attributes is transported between the backend authentication eap]. In this document, the terms "AAA server" and "backend
server and the authenticator. The attributes provide the authentication server" are used interchangeably.
authenticator with usage context and key names suitable to bind
the key to the appropriate context. The format and wrapping of the
AAA-Token, which is intended to be accessible only to the backend
authentication server and authenticator, is defined by the AAA
protocol. Examples include RADIUS [RFC2548], and Diameter
[I-D.ietf-aaa-eap].
Cryptographic binding EAP server
The demonstration of the EAP peer to the EAP server that a single The entity that terminates the EAP authentication method with the
entity has acted as the EAP peer for all methods executed within a peer. In the case where no backend authentication server is used,
sequence or tunnel. Binding MAY also imply that the EAP server the EAP server is part of the authenticator. In the case where the
demonstrates to the peer that a single entity has acted as the EAP authenticator operates in pass-through mode, the EAP server is
server for all methods executed within a sequence or tunnel. If located on the backend authentication server.
executed correctly, binding serves to mitigate man-in-the-middle
vulnerabilities.
Cryptographic separation security association
Two keys (x and y) are "cryptographically separate" if an A set of policies and key(s) used to protect information. This
adversary that knows all messages exchanged in the protocol cannot information in the security association is stored by each party of
compute x from y or y from x without "breaking" some cryptographic the security association and must be consistent among the parties.
assumption. In particular, this definition allows that the Elements of a security association include cryptographic keys,
adversary has the knowledge of all nonces sent in cleartext as negotiated ciphersuites and other parameters, counters, sequence
well as all predictable counter values used in the protocol. spaces, authorization attributes, etc.
Breaking a cryptographic assumption would typically require
inverting a one-way function or predicting the outcome of a
cryptographic pseudo-random number generator without knowledge of
the secret state. In other words, if the keys are
cryptographically separate, there is no shortcut to compute x from
y or y from x.
EAP server 1.3. Overview
The entity which terminates EAP authentication with the peer is
known as the EAP server. Where pass-through is supported, the
backend authentication server functions as the EAP server; where
authentication occurs locally, the EAP server is the
authenticator.
AAA-Key EAP is typically deployed in order to support extensible network
A key derived by the EAP peer and EAP server and transported to access authentication in situations where a peer desires network
the authenticator. In 802.11 terminology, the first 32 octets of access via one or more authenticators. The situation is illustrated
the AAA-Key is known as the Pairwise Master Key (PMK). in Figure 1.
Key strength Since both the peer and authenticator may have more than one physical
If the effective key strength is N bits, the best currently known or logical port, a given peer may simultaneously access the network
methods to recover the key (with non-negligible probability) via multiple authenticators, or via multiple physical or logical
require an effort comparable to 2^N operations of a typical block ports on a given authenticator. Similarly, an authenticator may
cipher. offer network access to multiple peers, each via a separate physical
or logical port.
Mutual authentication The peer may be stationary, in which case it may establish
This refers to an EAP method in which, within an interlocked communications with one or more authenticators while remaining in one
exchange, the authenticator authenticates the peer and the peer location. Alternatively, the peer may be mobile, changing its point
authenticates the authenticator. Two one-way conversations, of attachment from one authenticator to another, or moving between
running in opposite directions do not provide mutual points of attachment on a single authenticator.
authentication as defined here.
peer Where authenticators are deployed standalone, the EAP conversation
The end of the link that responds to the authenticator. In occurs between the peer and authenticator, and the authenticator must
[IEEE8021X], this end is known as the Supplicant. locally implement an EAP method acceptable to the peer.
1.3 Conversation Overview However, one of the advantages of EAP is that it enables deployment
of new authentication methods without requiring development of new
code on the authenticator. While the authenticator may implement
some EAP methods locally and use those methods to authenticate local
users, it may at the same time act as a pass-through for other users
and methods, forwarding EAP packets back and forth between the
backend authentication server and the peer.
Where EAP key derivation is supported, EAP authentication is +-+-+-+-+
typically a component of a three phase exchange: | |
| EAP |
| Peer |
| |
+-+-+-+-+
| | | Peer Ports
/ | \
/ | \
Phase 0: Discovery / | \
Phase 1: Authentication / | \
Phase 2: Secure / | \
Association / | \
/ | \
/ | \
| | | | | | | | | Authenticator Ports
+-+-+-+-+ +-+-+-+-+ +-+-+-+-+
| | | | | |
| Auth. | | Auth. | | Auth. |
| | | | | |
+-+-+-+-+ +-+-+-+-+ +-+-+-+-+
\ | /
\ | /
\ | /
EAP over AAA \ | /
(optional) \ | /
\ | /
\ | /
\ | /
+-+-+-+-+
| |
| AAA |
|Server |
| |
+-+-+-+-+
Discovery phase (phase 0) Figure 1: Relationship between peer, authenticator and backend server
EAP authentication, key derivation and transport (phase 1)
Unicast and multicast secure association establishment (phase 2)
In the discovery phase (phase 0), the EAP peers locate each other This is accomplished by encapsulating EAP packets within the
and discover their capabilities. This can include an EAP peer Authentication, Authorization and Accounting (AAA) protocol, spoken
locating an authenticator suitable for access to a particular between the authenticator and backend authentication server. AAA
network, or it could involve an EAP peer locating an authenticator protocols supporting EAP include RADIUS [RFC3579] and Diameter [I-
behind a bridge with which it desires to establish a secure D.ietf-aaa-eap].
association. Typically the discovery phase takes place between the
EAP peer and authenticator.
Once the EAP peer and authenticator discover each other, EAP Where EAP key derivation is supported, the conversation between the
authentication may begin (phase 1a). EAP enables deployment of new peer and the authenticator typically takes place in three phases:
authentication methods without requiring development of new code on
the authenticator. While the authenticator may implement some EAP
methods locally and use those methods to authenticate local users, it
may at the same time act as a pass-through for other users and
methods, forwarding EAP packets back and forth between the backend
authentication server and the peer.
As described in Section 2, in addition to supporting authentication, Phase 0: Discovery
EAP methods may also support derivation of keying material for Phase 1: Authentication
purposes including protection of the EAP conversation and subsequent 1a: EAP authentication
data exchanges. EAP key derivation takes place between the EAP peer 1b: AAA-Key Transport (optional)
and EAP server, and methods supporting key derivation MUST also Phase 2: Secure Association Establishment
support mutual authentication. Where an authenticator server is 2a: Unicast Secure Association
present, it acts as the EAP server and transports derived keying 2b: Multicast Secure Association (optional)
material (known as the AAA-Key) to the authenticator (phase 1b).
EAP methods may mutually authenticate and derive keys. However a In the discovery phase (phase 0), peers locate authenticators and
distinct secure association exchange is required in order to manage discover their capabilities. For example, a peer may locate an
the creation and deletion of unicast (phase 2a) and multicast (phase authenticator providing access to a particular network, or a peer may
2b) security associations between the EAP peer and authenticator. locate an authenticator behind a bridge with which it desires to
establish a Secure Association.
The phases and the relationship between the parties is illustrated The authentication phase (phase 1) may begin once the peer and
below. authenticator discover each other. This phase always includes EAP
authentication (phase 1a). Where the chosen EAP method supports key
derivation, in phase 1a keying material is derived on both the peer
and the EAP server. This keying material may be used for multiple
purposes, including protection of the EAP conversation and subsequent
data exchanges.
An additional step (phase 1b) is required in deployments which
include a backend authentication server, in order to transport keying
material (known as the AAA-Key) from the backend authentication
server to the authenticator.
A Secure Association exchange (phase 2) then occurs between the peer
and authenticator in order to manage the creation and deletion of
unicast (phase 2a) and multicast (phase 2b) security associations
between the peer and authenticator.
The conversation phases and relationship between the parties is shown
in Figure 2.
EAP peer Authenticator Auth. Server EAP peer Authenticator Auth. Server
-------- ------------- ------------ -------- ------------- ------------
|<----------------------------->| | |<----------------------------->| |
| Discovery (phase 0) | | | Discovery (phase 0) | |
|<----------------------------->|<----------------------------->| |<----------------------------->|<----------------------------->|
| EAP auth (phase 1a) | AAA pass-through (optional) | | EAP auth (phase 1a) | AAA pass-through (optional) |
| | | | | |
| |<----------------------------->| | |<----------------------------->|
| | AAA-Key transport | | | AAA-Key transport |
| | (optional; phase 1b) | | | (optional; phase 1b) |
|<----------------------------->| | |<----------------------------->| |
| Unicast Secure association | | | Unicast Secure association | |
| (phase 2a) | | | (phase 2a) | |
| | | | | |
|<----------------------------->| | |<----------------------------->| |
| Multicast Secure association | | | Multicast Secure association | |
| (optional; phase 2b) | | | (optional; phase 2b) | |
| | | | | |
Figure 1: Conversation Overview Figure 2: Conversation Overview
1.3.1 Discovery Phase 1.3.1. Discovery Phase
In the peer discovery exchange (phase 0), the EAP peer and In the discovery phase (phase 0), the EAP peer and authenticator
authenticator locate each other and discover each other's locate each other and discover each other's capabilities. Discovery
capabilities. For example, PPPoE [RFC2516] includes support for a can occur manually or automatically, depending on the lower layer
Discovery Stage to allow a peer to identify the Ethernet MAC address over which EAP runs. Since discovery is handled outside of EAP,
of one or more authenticators and establish a PPPoE SESSION_ID. In there is no need to provide this functionality within EAP.
IEEE 802.11 [IEEE80211], the EAP peer (also known as the Station or
STA) discovers the authenticator (Access Point or AP) and determines
its capabilities using Beacon or Probe Request/Response frames.
Since device discovery is handled outside of EAP, there is no need to
provide this functionality within EAP.
Device discovery can occur manually or automatically. In EAP For example, where EAP runs over PPP, the EAP peer might be
implementations running over PPP, the EAP peer might be configured configured with a phone book providing phone numbers of
with a phone book providing phone numbers of authenticators and authenticators and associated capabilities such as supported rates,
associated capabilities such as supported rates, authentication authentication protocols or ciphersuites.
protocols or ciphersuites.
Since device discovery can occur prior to authentication and key In contrast, PPPoE [RFC2516] provides support for a Discovery Stage
derivation, it may not be possible for the discovery phase to be to allow a peer to identify the Ethernet MAC address of one or more
protected using keying material derived during an authentication authenticators and establish a PPPoE SESSION_ID.
exchange. As a result, device discovery protocols may be insecure,
leaving them vulnerable to spoofing unless the discovered parameters
can subsequently be securely verified.
1.3.2 Authentication Phase IEEE 802.11 [IEEE80211] also provides integrated discovery support
utilizing Beacon and/or Probe Request/Response frames, allowing the
peer (known as the station or STA) to determine the MAC address and
capabilities of one or more authenticators (known as Access Point or
APs).
Once the EAP peer and authenticator discover each other, they 1.3.2. Authentication Phase
exchange EAP packets. Typically, the peer desires access to the
network, and the authenticators are Network Access Servers (NASes) Once the peer and authenticator discover each other, they exchange
providing that access. In such a situation, access to the network EAP packets. Typically, the peer desires access to the network, and
can be provided by any authenticator attaching to the desired the authenticators provide that access. In such a situation, access
network, and the EAP peer is typically willing to send data traffic to the network can be provided by any authenticator attaching to the
through any authenticator that can demonstrate that it is authorized desired network, and the EAP peer is typically willing to send data
to provide access to the desired network. traffic through any authenticator that can demonstrate that it is
authorized to provide access to the desired network.
An EAP authenticator may handle the authentication locally, or it may An EAP authenticator may handle the authentication locally, or it may
act as a pass-through to a backend authentication server. In the act as a pass-through to a backend authentication server. In the
latter case the EAP exchange occurs between the EAP peer and a latter case the EAP exchange occurs between the EAP peer and a
backend authenticator server, with the authenticator forwarding EAP backend authenticator server, with the authenticator forwarding EAP
packets between the two. The entity which terminates EAP packets between the two. The entity which terminates EAP
authentication with the peer is known as the EAP server. Where authentication with the peer is known as the EAP server. Where pass-
pass-through is supported, the backend authentication server through is supported, the backend authentication server functions as
functions as the EAP server; where authentication occurs locally, the the EAP server; where authentication occurs locally, the EAP server
EAP server is the authenticator. Where a backend authentication is the authenticator. Where a backend authentication server is
server is present, at the successful completion of an authentication present, at the successful completion of an authentication exchange,
exchange, the AAA-Key is transported to the authenticator (phase 1b). the AAA-Key is transported to the authenticator (phase 1b).
EAP may also be used when it is desired for two network devices (e.g. EAP may also be used when it is desired for two network devices (e.g.
two switches or routers) to authenticate each other, or where two two switches or routers) to authenticate each other, or where two
peers desire to authenticate each other and set up a secure peers desire to authenticate each other and set up a secure
association suitable for protecting data traffic. association suitable for protecting data traffic.
Some EAP methods exist which only support one-way authentication; Some EAP methods exist which only support one-way authentication;
however, EAP methods deriving keys are required to support mutual however, EAP methods deriving keys are required to support mutual
authentication. In either case, it can be assumed that the parties authentication. In either case, it can be assumed that the parties
do not utilize the link to exchange data traffic unless their do not utilize the link to exchange data traffic unless their
authentication requirements have been met. For example, a peer authentication requirements have been met. For example, a peer
completing mutual authentication with an EAP server will not send completing mutual authentication with an EAP server will not send
data traffic over the link until the EAP server has authenticated data traffic over the link until the EAP server has authenticated
successfully to the peer, and a secure association has been successfully to the peer, and a Secure Association has been
negotiated. negotiated.
Since EAP is a peer-to-peer protocol, an independent and simultaneous Since EAP is a peer-to-peer protocol, an independent and simultaneous
authentication may take place in the reverse direction. Both peers authentication may take place in the reverse direction. Both peers
may act as authenticators and authenticatees at the same time. may act as authenticators and authenticatees at the same time.
Successful completion of EAP authentication and key derivation by an Successful completion of EAP authentication and key derivation by a
EAP peer and EAP server does not necessarily imply that the peer is peer and EAP server does not necessarily imply that the peer is
committed to joining the network associated with an EAP server. committed to joining the network associated with an EAP server.
Rather, this commitment is implied by the creation of a security Rather, this commitment is implied by the creation of a security
association between the EAP peer and authenticator, as part of the association between the EAP peer and authenticator, as part of the
secure association protocol (phase 2). As a result, EAP may be used Secure Association Protocol (phase 2). As a result, EAP may be used
for "pre-authentication" in situations where it is necessary to for "pre-authentication" in situations where it is necessary to pre-
pre-establish EAP security associations in order to decrease handoff establish EAP security associations in order to decrease handoff or
or roaming latency. roaming latency.
1.3.3 Secure Association Phase 1.3.3. Secure Association Phase
The secure association phase (phase 2) always occurs after the The Secure Association phase (phase 2) always occurs after the
completion of EAP authentication (phase 1a) and key transport (phase completion of EAP authentication (phase 1a) and key transport (phase
1b), and typically supports the following features: 1b), and typically supports the following features:
[1] The secure negotiation of capabilities. This includes usage [1] Entity Naming. A basic feature of a Secure Association Protocol is
modes, session parameters and ciphersuites, and required filters, the naming of the parties engaged in the exchange. As illustrated
including confirmation of the capabilities discovered during in Figure 1, it is possible for both the peer and NAS to have more
phase 0. By securely negotiating session parameters, the secure than one physical or virtual port. For the purposes of
association protocol protects against spoofing during the identification, it is therefore not possible to identify either
discovery phase and ensures that the peer and authenticator are peers or NAS devices using port identifiers. Proper identification
in agreement about how data is to be secured. of the parties is critical to the Secure Association phase, since
without this the parties engaged in the exchange are not identified
[2] Generation of fresh transient session keys. This is typically and the scope of the transient session keys (TSKs) generated during
accomplished via the exchange of nonces within the secure the exchange is undefined.
association protocol, and includes generation of both unicast
(phase 2a) and multicast (phase 2b) session keys. By not using
the AAA-Key directly to protect data, the secure association
protocol protects against compromise of the AAA-Key, and by
guaranteeing the freshness of transient session key, assures that
session keys are not reused.
[3] Key activation and deletion.
[4] Mutual proof of possession of the AAA-Key. This demonstrates
that both the EAP peer and authenticator have been authenticated
and authorized by the AAA server. Since mutual proof of
possession is not the same as mutual authentication, the EAP peer
cannot verify authenticator assertions (including the
authenticator identity) as a result of this exchange.
1.4 Authorization issues
In a typical network access scenario (dial-in, wireless LAN, etc.)
access control mechanisms are typically applied. These mechanisms
include user authentication as well as authorization for the offered
service.
As a part of the authentication process, the AAA network determines
the user's authorization profile. The user authorizations are
transmitted by the AAA server to the EAP authenticator (also known as
the Network Access Server or NAS) included with the AAA-Token, which
also contains the AAA-Key, in Phase 1b of the EAP conversation.
Typically, the profile is determined based on the user identity, but
a certificate presented by the user may also provide authorization
information.
The AAA server is responsible for making a user authorization
decision, answering the following questions:
o Is this a legitimate user for this particular network?
o Is this user allowed the type of access he or she is requesting?
o Are there any specific parameters (mandatory tunneling, bandwidth,
filters, and so on) that the access network should be aware of for
this user?
o Is this user within the subscription rules regarding time of day?
o Is this user within his limits for concurrent sessions?
o Are there any fraud, credit limit, or other concerns that indicate
that access should be denied?
While the authorization decision is in principle simple, the process
is complicated by the distributed nature of AAA decision making.
Where brokering entities or proxies are involved, all of the AAA
devices in the chain from the NAS to the home AAA server are involved
in the decision. For instance, a broker can disallow access even if
the home AAA server would allow it, or a proxy can add authorizations
(e.g., bandwidth limits).
Decisions can be based on static policy definitions and profiles as
well as dynamic state (e.g. time of day or limits on the number of
concurrent sessions). In addition to the Accept/Reject decision made
by the AAA chain, parameters or constraints can be communicated to
the NAS.
The criteria for Accept/Reject decisions or the reasons for choosing
particular authorizations are typically not communicated to the NAS,
only the final result. As a result, the NAS has no way to know what
the decision was based on. Was a set of authorization parameters
sent because this service is always provided to the user, or was the
decision based on the time/day and the capabilities of the requesting
NAS device?
Within EAP, "fast handoff" is defined as a conversation in which the
EAP exchange (phase 1a) and associated AAA passthrough is bypassed,
so as to reduce latency. Depending on the fast handoff mechanism,
AAA-Key transport (phase 1b) may also be bypassed in favor a context
transfer (see [IEEE80211f] and [I-D.aboba-802-context]) or it may be
provided in a pre-emptive manner as in [IEEE-03-084] and
[I-D.irtf-aaaarch-handoff].
As we will discuss, the introduction of fast handoff creates a new
class of security vulnerabilities as well as requirements for the
secure handling of authorization context.
1.4.1 Correctness in fast handoff
Bypassing all or portions of the AAA conversation creates challenges
in ensuring that authorization is properly handled. These include:
o Consistent application of session time limits. A fast handoff
should not automatically increase the available session time,
allowing a user to endlessly extend their network access by
changing the point of attachment.
o Avoidance of privilege elevation. A fast handoff should not
result in a user being granted access to services which they are
not entitled to.
o Consideration of dynamic state. In situations in which dynamic
state is involved in the access decision (day/time, simultaneous
session limit) it should be possible to take this state into
account either before or after access is granted. Note that
consideration of network-wide state such as simultaneous session
limits can typically only be taken into account by the AAA server.
o Encoding of restrictions. Since a NAS may not be aware of the
criteria considered by a AAA server when allowing access, in order
to ensure consistent authorization during a fast handoff it may be
necessary to explicitly encode the restrictions within the
authorizations provided in the AAA-Token.
o State validity. The introduction of fast handoff should not
render the authentication server incapable of keeping track of
network-wide state.
A fast handoff mechanism capable of addressing these concerns is said
to be "correct". One condition for correctness is as follows:
For a fast handoff to be "correct" it MUST establish on the new
device the same context as would have been created had the new device
completed a AAA conversation with the authentication server.
A properly designed fast handoff scheme will only succeed if it is
"correct" in this way. If a successful fast handoff would establish
"incorrect" state, it is preferable for it to fail, in order to avoid
creation of incorrect context.
Some AAA server and NAS configurations are incapable of meeting this
definition of "correctness". For example, if the old and new device
differ in their capabilities, it may be difficult to meet this
definition of correctness in a fast handoff mechanism that bypasses
AAA. AAA servers often perform conditional evaluation, in which the
authorizations returned in an Access-Accept message are contingent on
the NAS or on dynamic state such as the time of day or number of
simultaneous sessions. For example, in a heterogeneous deployment,
the AAA server might return different authorizations depending on the
NAS making the request, in order to make sure that the requested
service is consistent with the NAS capabilities.
If differences between the new and old device would result in the AAA
server sending a different set of messages to the new device than
were sent to the old device, then if the fast handoff mechanism
bypasses AAA, then the fast handoff cannot be carried out correctly.
For example, if some NAS devices within a deployment support dynamic
VLANs while others do not, then attributes present in the
Access-Request (such as the NAS-IP-Address, NAS-Identifier,
Vendor-Identifier, etc.) could be examined to determine when VLAN
attributes will be returned, as described in [RFC3580]. VLAN
support is defined in [IEEE8021Q]. If a fast handoff bypassing the
AAA server were to occur between a NAS supporting dynamic VLANs and
another NAS which does not, then a guest user with access restricted
to a guest VLAN could be given unrestricted access to the network.
Similarly, in a network where access is restricted based on the day
and time, SSID, Calling-Station-Id or other factors, unless the
restrictions are encoded within the authorizations, or a partial AAA
conversation is included, then a fast handoff could result in the
user bypassing the restrictions.
In practice, these considerations limit the situations in which fast
handoff mechanisms bypassing AAA can be expected to be successful.
Where the deployed devices implement the same set of services, it may
be possible to do successful fast handoffs within such mechanisms.
However, where the supported services differ between devices, the
fast handoff may not succeed. For example, [RFC2865], section 1.1
states:
"A NAS that does not implement a given service MUST NOT implement
the RADIUS attributes for that service. For example, a NAS that
is unable to offer ARAP service MUST NOT implement the RADIUS
attributes for ARAP. A NAS MUST treat a RADIUS access-accept
authorizing an unavailable service as an access-reject instead."
Note that this behavior only applies to attributes that are known,
but not implemented. For attributes that are unknown, section of 5
of [RFC2865] states:
"A RADIUS server MAY ignore Attributes with an unknown Type. A
RADIUS client MAY ignore Attributes with an unknown Type."
In order to perform a correct fast handoff, if a new device is [2] Secure capabilities negotiation. This provides for the secure
provided with RADIUS context for a known but unavailable service, negotiation of usage modes, session parameters (such as key
then it MUST process this context the same way it would handle a lifetimes), ciphersuites, and required filters, including
RADIUS Access-Accept requesting an unavailable service. This MUST confirmation of the capabilities discovered during phase 0. By
cause the fast handoff to fail. However, if a new device is provided securely negotiating session parameters, the secure Association
with RADIUS context that indicates an unknown attribute, then this Protocol protects against spoofing during the discovery phase and
attribute MAY be ignored. ensures that the peer and authenticator are in agreement about how
data is to be secured.
Although it may seem somewhat counter-intuitive, failure is indeed [3] Generation of fresh transient session keys (TSKs). The Secure
the "correct" result where a known but unsupported service is Association Protocol typically guarantees the freshness of session
requested. Presumably a correctly configured AAA server would not keys by exchanging nonces between both parties and then mixing the
request that a device carry out a service that it does not implement. nonces with the AAA-Key in order to generate fresh unicast (phase
This implies that if the new device were to complete a AAA 2a) and multicast (phase 2b) session keys. By not using the AAA-
conversation that it would be likely to receive different service Key directly to protect data, the secure Association Protocol
instructions. In such a case, failure of the fast handoff is the protects against compromise of the AAA-Key, and by guaranteeing the
desired result. This will cause the new device to go back to the AAA freshness of transient session keys, assures that they are not
server in order to receive the appropriate service definition. reused.
In practice, this implies that fast handoff mechanisms which bypass [4] Key activation and deletion. In order for the peer and
AAA are most likely to be successful within a homogeneous device authenticator to communicate securely, it is necessary for both
deployment within a single administrative domain. For example, it sides to derive the same session keys, and remain in sync with
would not be advisable to carry out a fast handoff bypassing AAA respect to key state going forward. One of the functions of the
between a NAS providing confidentiality and another NAS that does not Secure Association Protocol is to synchronize the activation and
support this service. The correct result of such a fast handoff deletion of keys so as to enable seamless rekey, or recovery from
would be a failure, since if the handoff were blindly carried out, partial or complete loss of key state by the peer or authenticator.
then the user would be moved from a secure to an insecure channel
without permission from the AAA server. Thus the definition of a
"known but unsupported service" MUST encompass requests for
unavailable security services. This includes vendor-specific
attributes related to security, such as those described in
[RFC2548]."
2. EAP Key Hierarchy [5] Mutual proof of possession of the AAA-Key. This demonstrates that
both the peer and authenticator have been authenticated and
authorized by the backend authentication server. Since mutual
proof of possession is not the same as mutual authentication, the
peer cannot verify authenticator assertions (including the
authenticator identity) as a result of this exchange.
2.1 EAP Invariants 1.4. EAP Invariants
The EAP key management framework assumes that certain basic By utilizing a three phase exchange, the EAP key management framework
characteristics, known as the "EAP Invariants" hold true for all guarantees that certain basic characteristics, known as the "EAP
implementations of EAP. These include: Invariants" hold true for all implementations of EAP. These include:
Media independence Media independence
Method independence Method independence
Ciphersuite independence Ciphersuite independence
2.1.1 Media Independence 1.4.1. Media Independence
As described in [I-D.ietf-eap-rfc2284bis], EAP authentication can run One of the goals of EAP is to allow EAP methods to function on any
over multiple lower layers, including PPP [RFC1661] and IEEE 802 lower layer meeting the criteria outlined in [RFC3748], Section 3.1.
wired networks [IEEE8021X]. Use with IEEE 802.11 wireless LANs is For example, as described in [RFC3748], EAP authentication can be run
also contemplated [IEEE80211i]. Since EAP methods cannot be assumed over PPP [RFC1661], IEEE 802 wired networks [IEEE8021X], and IEEE
to have knowledge of the lower layer over which they are transported, 802.11 wireless LANs [IEEE80211i].
EAP methods can function on any lower layer meeting the criteria
outlined in [I-D.ietf-eap-rfc2284bis], Section 3.1. As a result, EAP
methods should not utilize identifiers associated with a particular
usage environment (e.g. MAC addresses).
2.1.2 Method Independence In order to maintain media independence, it is necessary for EAP to
avoid inclusion of media-specific elements. For example, EAP methods
cannot be assumed to have knowledge of the lower layer over which
they are transported, and cannot utilize identifiers associated with
a particular usage environment (e.g. MAC addresses).
Supporting pass-through of authentication to the backend The need for media independence has also motivated the development of
authentication server enables the authenticator to support any the three phase exchange. Since discovery is typically media-
authentication method implemented on the backend authentication specific, this function is handled outside of EAP, rather than being
server and peer, not just locally implemented methods. incorporated within it. Similarly, the Secure Association Protocol
often contains media dependencies such as negotiation of media-
specific ciphersuites or session parameters, and as a result this
functionality also cannot be incorporated within EAP.
This implies that the authenticator need not implement code for each Note that media independence may be retained within EAP methods that
EAP method required by authenticating peers. In fact, the support channel binding or method-specific identification. An EAP
authenticator is not required to implement any EAP methods at all, method need not be aware of the content of an identifier in order to
nor can it be assumed to implement code specific to any EAP method. use it. This enables an EAP method to use media-specific identifiers
such as MAC addresses without compromising media independence. To
support channel binding, an EAP method can pass binding parameters to
the AAA server in the form of an opaque blob, and receive
confirmation of whether the parameters match, without requiring
media-specific knowledge.
1.4.2. Method Independence
By enabling pass-through, authenticators can support any method
implemented on the peer and server, not just locally implemented
methods. This allows the authenticator to avoid implementing code
for each EAP method required by peers. In fact, since a pass-through
authenticator is not required to implement any EAP methods at all, it
cannot be assumed to support any EAP method-specific code.
As a result, as noted in [RFC3748], authenticators must by default be
capable of supporting any EAP method. Since the Discovery and Secure
Association exchanges are also method independent, an authenticator
can carry out the three phase exchange without having an EAP method
in common with the peer.
This is useful where there is no single EAP method that is both This is useful where there is no single EAP method that is both
mandatory-to-implement and offers acceptable security for the media mandatory-to-implement and offers acceptable security for the media
in use. For example, the [I-D.ietf-eap-rfc2284bis] in use. For example, the [RFC3748] mandatory-to-implement EAP method
mandatory-to-implement EAP method (MD5-Challenge) does not provide (MD5-Challenge) does not provide dictionary attack resistance, mutual
dictionary attack resistance, mutual authentication or key authentication or key derivation, and as a result is not appropriate
derivation, and as a result is not appropriate for use in wireless for use in wireless LAN authentication [WLANREQ]. However, despite
authentication. this it is possible for the peer and authenticator to interoperate as
long as a suitable EAP method is supported on the EAP server.
2.1.3 Ciphersuite Independence 1.4.3. Ciphersuite Independence
While EAP methods may negotiate the ciphersuite used in protection of While EAP methods may negotiate the ciphersuite used in protection of
the EAP conversation, the ciphersuite used for the protection of data the EAP conversation, the ciphersuite used for the protection of data
is negotiated within the secure association protocol, out-of-band of is negotiated within the Secure Association Protocol, out-of-band of
EAP. The backend authentication server is not a party to this EAP.
negotiation nor is it an intermediary in the data flow between the
EAP peer and authenticator. The backend authentication server may The backend authentication server is not a party to this negotiation
not even have knowledge of the ciphersuites implemented by the peer nor is it an intermediary in the data flow between the EAP peer and
and authenticator, or be aware of the ciphersuite negotiated between authenticator. The backend authentication server may not even have
knowledge of the ciphersuites implemented by the peer and
authenticator, or be aware of the ciphersuite negotiated between
them, and therefore does not implement ciphersuite-specific code. them, and therefore does not implement ciphersuite-specific code.
Since ciphersuite negotiation occurs in the secure association Since ciphersuite negotiation occurs in the Secure Association
protocol, not in EAP, ciphersuite-specific key generation, if protocol, not in EAP, ciphersuite-specific key generation, if
implemented within an EAP method, would potentially conflict with the implemented within an EAP method, would potentially conflict with the
transient session key derivation occurring in the secure association transient session key derivation occurring in the Secure Association
protocol. As a result, EAP methods generate keying material that is protocol. As a result, EAP methods generate keying material that is
ciphersuite-independent. Additional advantages of ciphersuite-independent. Additional advantages of ciphersuite-
ciphersuite-independence include: independence include:
Update requirements Update requirements
If EAP methods were to specify how to derive transient session If EAP methods were to specify how to derive transient session keys
keys for each ciphersuite, they would need to be updated each time for each ciphersuite, they would need to be updated each time a new
a new ciphersuite is developed. In addition, backend ciphersuite is developed. In addition, backend authentication
authentication servers might not be usable with all EAP-capable servers might not be usable with all EAP-capable authenticators,
authenticators, since the backend authentication server would also since the backend authentication server would also need to be
need to be updated each time support for a new ciphersuite is updated each time support for a new ciphersuite is added to the
added to the authenticator. authenticator.
EAP method complexity EAP method complexity
Requiring each EAP method to include ciphersuite-specific code for Requiring each EAP method to include ciphersuite-specific code for
transient session key derivation would increase the complexity of transient session key derivation would increase method complexity
each EAP method and would result in duplicated effort. and result in duplicated effort.
Knowledge of capabilities Knowledge of capabilities
In practice, an EAP method may not have knowledge of the In practice, an EAP method may not have knowledge of the
ciphersuite that has been negotiated between the peer and ciphersuite that has been negotiated between the peer and
authenticator. In PPP, ciphersuite negotiation occurs in the authenticator, since this negotiation typically occurs within the
Encryption Control Protocol (ECP) [RFC1968]. Since ECP Secure Association Protocol.
negotiation occurs after authentication, unless an EAP method is
utilized that supports ciphersuite negotiation, the peer,
authenticator and backend authentication server may not be able to
anticipate the negotiated ciphersuite and therefore this
information cannot be provided to the EAP method. Since
ciphersuite negotiation is assumed to occur out-of-band, there is
no need for ciphersuite negotiation within EAP.
2.2 Key Hierarchy For example, PPP ciphersuite negotiation occurs in the Encryption
Control Protocol (ECP) [RFC1968]. Since ECP negotiation occurs
after authentication, unless an EAP method is utilized that
supports ciphersuite negotiation, the peer, authenticator and
backend authentication server may not be able to anticipate the
negotiated ciphersuite and therefore this information cannot be
provided to the EAP method. Since ciphersuite negotiation is
assumed to occur out-of-band, there is no need for ciphersuite
negotiation within EAP.
The EAP keying hierarchy, illustrated in Figure 2, makes use of the 2. EAP Key Hierarchy
following types of keys:
EAP Master key (MK) 2.1. Key Terminology
A key derived between the EAP client and server during the EAP
authentication process, and that is kept local to the EAP method The EAP Key Hierarchy makes use of the following types of keys:
and not exported or made available to a third party.
Long Term Credential
EAP methods frequently make use of long term secrets in order to
enable authentication between the peer and server. In the case of
a method based on pre-shared key authentication, the long term
credential is the pre-shared key. In the case of a public-key
based method, the long term credential is the corresponding private
key.
Master Session Key (MSK) Master Session Key (MSK)
Keying material (at least 64 octets) that is derived between the Keying material that is derived between the EAP peer and server and
EAP client and server and exported by the EAP method. exported by the EAP method. The MSK is at least 64 octets in
length.
Extended Master Session Key (EMSK)
Additional keying material derived between the peer and server that
is exported by the EAP method. The EMSK is at least 64 octets in
length, and is never shared with a third party.
AAA-Key AAA-Key
Where a backend authentication server is present, acting as an EAP A key derived by the peer and EAP server, used by the peer and
server, keying material known as the AAA-Key is transported from authenticator in the derivation of Transient Session Keys (TSKs).
the authentication server to the authenticator wrapped within the Where a backend authentication server is present, the AAA-Key is
AAA-Token. The AAA-Key is used by the EAP peer and authenticator transported from the backend authentication server to the
in the derivation of Transient Session Keys (TSKs) for the authenticator, wrapped within the AAA-Token; it is therefore known
ciphersuite negotiated between the EAP peer and authenticator. As by the peer, authenticator and backend authentication server.
a result, the AAA-Key is typically known by all parties in the EAP However, despite the name, the AAA-Key is computed regardless of
exchange: the peer, authenticator and the authentication server whether a backend authentication server is present. AAA-Key
(if present). AAA-Key derivation is discussed in Appendix E. derivation is discussed in Appendix E; in existing implementations
the MSK is used as the AAA-Key.
Extended Master Session Key (EMSK) Application-specific Master Session Keys (AMSKs)
Additional keying material (64 octets) derived between the EAP Keys derived from the EMSK which are cryptographically separate
client and server that is exported by the EAP method. The EMSK is from each other and may be subsequently used in the derivation of
known only to the EAP peer and server and is not provided to a Transient Session Keys (TSKs) for extended uses. AMSK derivation
third party. is discussed in Appendix E.
AAA-Token
Where a backend server is present, the AAA-Key and one or more
attributes is transported between the backend authentication server
and the authenticator within a package known as the AAA-Token. The
format and wrapping of the AAA-Token, which is intended to be
accessible only to the backend authentication server and
authenticator, is defined by the AAA protocol. Examples include
RADIUS [RFC2548] and Diameter [I-D.ietf-aaa-eap].
Initialization Vector (IV) Initialization Vector (IV)
A quantity of at least 64 octets, suitable for use in an A quantity of at least 64 octets, suitable for use in an
initialization vector field, that is derived between the EAP initialization vector field, that is derived between the peer and
client and server. Since the IV is a known value in methods such EAP server. Since the IV is a known value in methods such as EAP-
as EAP-TLS [RFC2716], it cannot be used by itself for computation TLS [RFC2716], it cannot be used by itself for computation of any
of any quantity that needs to remain secret. As a result, its use quantity that needs to remain secret. As a result, its use has
has been deprecated and EAP methods are not required to generate been deprecated and EAP methods are not required to generate it.
it. However, when it is generated it MUST be unpredictable.
Pairwise Master Key (PMK) Pairwise Master Key (PMK)
The AAA-Key is divided into two halves, the "Peer to Authenticator The AAA-Key is divided into two halves, the "Peer to Authenticator
Encryption Key" (Enc-RECV-Key) and "Authenticator to Peer Encryption Key" (Enc-RECV-Key) and "Authenticator to Peer
Encryption Key" (Enc-SEND-Key) (reception is defined from the Encryption Key" (Enc-SEND-Key) (reception is defined from the point
point of view of the authenticator). Within [IEEE80211i] Octets of view of the authenticator). Within [IEEE80211i] Octets 0-31 of
0-31 of the AAA-Key (Enc-RECV-Key) are known as the Pairwise the AAA-Key (Enc-RECV-Key) are known as the Pairwise Master Key
Master Key (PMK). IEEE 802.11i ciphersuites [IEEE80211i] derive (PMK). In [IEEE80211i] the TKIP and AES CCMP ciphersuites derive
their Transient Session Keys (TSKs) solely from the PMK, whereas their Transient Session Keys (TSKs) solely from the PMK, whereas
the WEP ciphersuite, when used with [IEEE8021X], as noted in the WEP ciphersuite as noted in [RFC3580], derives its TSKs from
[RFC3580], derives its TSKs from both halves of the AAA-Key, the both halves of the AAA-Key.
Enc-RECV-Key and the Enc-SEND-Key.
Transient EAP Keys (TEKs) Transient EAP Keys (TEKs)
Session keys which are used to establish a protected channel Session keys which are used to establish a protected channel
between the EAP peer and server during the EAP authentication between the EAP peer and server during the EAP authentication
exchange. The TEKs are appropriate for use with the ciphersuite exchange. The TEKs are appropriate for use with the ciphersuite
negotiated between EAP peer and server for use in protecting the negotiated between EAP peer and server for use in protecting the
EAP conversation. Note that the ciphersuite used to set up the EAP conversation. Note that the ciphersuite used to set up the
protected channel between the EAP peer and server during EAP protected channel between the EAP peer and server during EAP
authentication is unrelated to the ciphersuite used to authentication is unrelated to the ciphersuite used to subsequently
subsequently protect data sent between the EAP peer and protect data sent between the EAP peer and authenticator. An
authenticator. An example TEK key hierarchy is described in example TEK key hierarchy is described in Appendix C.
Appendix C.
Transient Session Keys (TSKs)
Session keys used to protect data which are appropriate for the
ciphersuite negotiated between the EAP peer and authenticator. The
TSKs are derived from AAA-Key during the Secure Association
Protocol. In the case of [IEEE80211i] the Secure Association
Protocol consists of the 4-way handshake and group key derivation.
An example TSK derivation is provided in Appendix D.
2.2. Key Hierarchy
The EAP Key Hierarchy, illustrated in Figure 3, has at the root the
long term credential utilized by the selected EAP method. If
authentication is based on a pre-shared key, the parties store the
EAP method to be used and the pre-shared key. The EAP server also
stores the peer's identity and/or other information necessary to
decide whether access to some service should be granted. The peer
stores information necessary to choose which secret to use for which
service.
If authentication is based on proof of possession of the private key
corresponding to the public key contained within a certificate, the
parties store the EAP method to be used and the trust anchors used to
validate the certificates. The EAP server also stores the peer's
identity and/or other information necessary to decide whether access
to some service should be granted. The peer stores information
necessary to choose which certificate to use for which service.
Based on the long term credential established between the peer and
the server, EAP derives four types of keys:
[1] Keys calculated locally by the EAP method but not exported
by the EAP method, such as the TEKs.
[2] Keys exported by the EAP method: MSK, EMSK, IV
[3] Keys calculated from exported quantities: AAA-Key, AMSKs.
[4] Keys calculated by the Secure Association Protocol: TSKs.
In order to protect the EAP conversation, methods supporting key
derivation typically negotiate a ciphersuite and derive Transient EAP
Keys (TEKs) for use with that ciphersuite. The TEKs are stored
locally by the EAP method and are not exported.
As noted in [RFC3748] Section 7.10, EAP methods generating keys are
required to calculate and export the MSK and EMSK, which must be at
least 64 octets in length. EAP methods also may export the IV;
however, the use of the IV is deprecated.
On both the peer and EAP server, the exported MSK and EMSK are
utilized in order to calculate the AAA-Key, as described in Appendix
E.
Where a backend authentication server is present, the AAA-Key is
transported from the backend authentication server to the
authenticator within the AAA-Token, using the AAA protocol.
Once EAP authentication completes and is successful, the peer and
authenticator obtain the AAA-Key and the Secure Association Protocol
is run between the peer and authenticator in order to securely
negotiate the ciphersuite, derive fresh TSKs used to protect data,
and provide mutual proof of possession of the AAA-Key.
When the authenticator acts as an endpoint of the EAP conversation
rather than a pass-through, EAP methods are implemented on the
authenticator as well as the peer. If the EAP method negotiated
between the EAP peer and authenticator supports mutual authentication
and key derivation, the EAP Master Session Key (MSK) and Extended
Master Session Key (EMSK) are derived on the EAP peer and
authenticator and exported by the EAP method. In this case, the MSK
and EMSK are known only to the peer and authenticator and no other
parties. The TEKs and TSKs also reside solely on the peer and
authenticator. This is illustrated in Figure 4. As demonstrated in
[I-D.ietf-roamops-cert], in this case it is still possible to support
roaming between providers, using certificate-based authentication.
Where a backend authentication server is utilized, the situation is
illustrated in Figure 5. Here the authenticator acts as a pass-
through between the EAP peer and a backend authentication server. In
this model, the authenticator delegates the access control decision
to the backend authentication server, which acts as a Key
Distribution Center (KDC). In this case, the authenticator
encapsulates EAP packet with a AAA protocol such as RADIUS [RFC3579]
or Diameter [I-D.ietf-aaa-eap], and forwards packets to and from the
backend authentication server, which acts as the EAP server. Since
the authenticator acts as a pass-through, EAP methods reside only on
the peer and EAP server As a result, the TEKs, MSK and EMSK are
derived on the peer and EAP server.
On completion of EAP authentication, EAP methods on the peer and EAP
server export the Master Session Key (MSK) and Extended Master
Session Key (EMSK). The peer and EAP server then calculate the AAA-
Key from the MSK and EMSK, and the backend authentication server
sends an Access-Accept to the authenticator, providing the AAA-Key
within a protected package known as the AAA-Token.
The AAA-Key is then used by the peer and authenticator within the
Secure Association Protocol to derive Transient Session Keys (TSKs)
required for the negotiated ciphersuite. The TSKs are known only to
the peer and authenticator.
2.3. Key Lifetimes
As noted earlier, the EAP Key Management framework includes several
types of keys, including:
[1] Keys calculated locally by the EAP method but not exported
by the EAP method, such as the TEKs.
[2] Keys exported by the EAP method: MSK, EMSK, IV
[3] Keys calculated from exported quantities: AAA-Key, AMSKs.
[4] Keys calculated by the Secure Association Protocol: TSKs.
Key lifetime issues associated with each type of key are discussed in
the sections that follow. Challenges include:
[a] Security. Where key lifetimes cannot be assumed, it may be
necessary to negotiate them. While key lifetimes may be announced
or negotiated in the clear, a protected lifetime negotiation is
RECOMMENDED.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | ^ | | ^
| EAP Method | | | EAP Method | |
| | | | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | |
| | | | | | | | | | | |
| | EAP Method Key | | | | | EAP Method Key |<->| Long-Term | | |
| | Derivation | | | | | Derivation | | Credential | | |
| | | | Local | | | | | | | |
| | | | to EAP | | | | +-+-+-+-+-+-+-+ | Local to |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Method | | | | | EAP |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Method |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| V | | | | | V | | | |
| +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | | | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | |
| | TEK | | MSK | |EMSK | |IV | | | | | TEK | | MSK | |EMSK | |IV | | |
| |Derivation | |Derivation | |Derivation | |Derivation | | | | |Derivation | |Derivation | |Derivation | |Derivation | | |
| +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | | | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | |
| | | | | | | | | | | |
| | | | | V | | | | | V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | | ^ | | | ^
| MSK (64B) | EMSK (64B) | IV (64B) |
| | | | | | | |
| MSK (64B) | EMSK (64B) | IV (64B) |
| | | Exported | | | | Exported |
| | | by EAP | | | | by |
V V V Method | V V V EAP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ Method|
| AAA Key Derivation, | | Known | | | AAA Key Derivation, | | Known | |
| Naming & Binding | |(Not Secret) | | | Naming & Binding | |(Not Secret) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ V +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ V
| ---+ | ---+
| Transported | | Transported |
| AAA-Key by AAA | | AAA-Key by AAA |
| Protocol | | Protocol |
V V V V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | ^ | | ^
| TSK | Ciphersuite | | TSK | Ciphersuite |
| Derivation | Specific | | Derivation | Specific |
| | V | | V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
Figure 2: EAP Key Hierarchy Figure 3: EAP Key Hierarchy
Transient Session Keys (TSKs)
Session keys used to protect data which are appropriate for the
ciphersuite negotiated between the EAP peer and authenticator.
The TSKs are derived from the keying material included in the
AAA-Token via the secure association protocol. In the case of IEEE
802.11, the role of the secure association protocol is handled by
the 4-way handshake and group key derivation. An example TSK
derivation is provided in Appendix D.
2.3 Exchanges
EAP supports both a two party exchange between an EAP peer and an
authenticator, as well as a three party exchange between an EAP peer,
an authenticator and an EAP server.
Figure 3 illustrates the two party exchange. Here EAP is spoken
between the peer and authenticator, encapsulated within a lower layer
protocol, such as PPP, defined in [RFC1661] or IEEE 802, defined in
[IEEE802].
Since the authenticator acts as an endpoint of the EAP conversation
rather than a pass-through, EAP methods are implemented on the
authenticator as well as the peer. If the EAP method negotiated
between the EAP peer and authenticator supports mutual authentication
and key derivation, the EAP Master Session Key (MSK) and Extended
Master Session Key (EMSK) are derived on the EAP peer and
authenticator and exported by the EAP method.
Where no backend authentication server is present, the MSK and EMSK
are known only to the peer and authenticator and neither is
transported to a third party. As demonstrated in
[I-D.ietf-roamops-cert], despite the absence of a backend
authentication server, such exchanges can support roaming between
providers; it is even possible to support fast handoff without
re-authentication. However, this is typically only possible where
both the EAP peer and authenticator support certificate-based
authentication, or where the user base is sufficiently small that EAP
authentication can occur locally.
In order to protect the EAP conversation, the EAP method may
negotiate a ciphersuite and derive Transient EAP Keys (TEKs) to
provide keys for that ciphersuite in order to protect some or all of
the EAP exchange. The TEKs are stored locally within the EAP method
and are not exported.
Once EAP mutual authentication completes and is successful, the
secure association protocol is run between the peer and
authenticator. This derives fresh transient session keys (TSKs),
provides for the secure negotiation of the ciphersuite used to
protect data, and supports mutual proof of possession of the AAA-Key.
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
| | | | | | | |
| | | |
| Cipher- | | Cipher- | | Cipher- | | Cipher- |
| Suite | | Suite | | Suite | | Suite |
| | | | | | | |
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
^ ^ ^ ^
| | | |
| |
| |
V V V V
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
| | | | | | | |
| |===============| | | |===============| |
| |EAP, TEK Deriv.|Authenti-| | |EAP, TEK Deriv.|Authenti-|
| |<------------->| cator | | |<------------->| cator |
| | | | | | | |
| | Secure Assoc. | | | | Secure Assoc. | |
| peer |<------------->| (EAP | | peer |<------------->| (EAP |
| |===============| server) | | |===============| server) |
| | Link layer | | | | Link layer | |
| | (PPP,IEEE802) | | | | (PPP,IEEE802) | |
| | | | | | | |
|MSK,EMSK | |MSK,EMSK | |MSK,EMSK | |MSK,EMSK |
| AAA-Key | | AAA-Key |
| (TSKs) | | (TSKs) | | (TSKs) | | (TSKs) |
| | | | | | | |
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
^ ^ ^ ^
| | | |
| MSK, EMSK | MSK, EMSK | MSK, EMSK | MSK, EMSK
| | | |
| |
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
| | | | | | | |
| EAP | | EAP | | EAP | | EAP |
| Method | | Method | | Method | | Method |
| | | | | | | |
|(MK,TEKs)| |(MK,TEKs)| | (TEKs) | | (TEKs) |
| | | | | | | |
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
Figure 3: Relationship between EAP peer and authenticator (acting as Figure 4: Relationship between EAP peer and authenticator (acting
an EAP server), where no backend authentication server is present. as an EAP server), where no backend authentication server is
present.
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
| | | | | | | |
| | | | | | | |
| Cipher- | | Cipher- | | Cipher- | | Cipher- |
| Suite | | Suite | | Suite | | Suite |
| | | | | | | |
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
^ ^ ^ ^
| | | |
skipping to change at page 21, line 27 skipping to change at page 20, line 27
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
| |===============| |========| | | |===============| |========| |
| |EAP, TEK Deriv.| | | | | |EAP, TEK Deriv.| | | |
| |<-------------------------------->| backend | | |<-------------------------------->| backend |
| | | | | | | | | | | |
| | Secure Assoc. | | AAA-Key| | | | Secure Assoc. | | AAA-Key| |
| peer |<------------->|Authenti-|<-------| auth | | peer |<------------->|Authenti-|<-------| auth |
| |===============| cator |========| server | | |===============| cator |========| server |
| | Link Layer | | AAA | (EAP | | | Link Layer | | AAA | (EAP |
| | (PPP,IEEE 802)| |Protocol| server) | | | (PPP,IEEE 802)| |Protocol| server) |
| | | | | | |MSK,EMSK | | | | |
|MSK,EMSK | | MSK | |MSK,EMSK | | AAA-Key | | AAA-Key | |MSK,EMSK,|
| (TSKs) | | (TSKs) | | | | (TSKs) | | (TSKs) | | AAA-Key |
| | | | | | | | | | | |
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
^ ^ ^ ^
| | | |
| MSK, EMSK | MSK, EMSK | MSK, EMSK | MSK, EMSK
| | | |
| | | |
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
| | | | | | | |
| EAP | | EAP | | EAP | | EAP |
| Method | | Method | | Method | | Method |
| | | | | | | |
|(MK,TEKs)| |(MK,TEKs)| | (TEKs) | | (TEKs) |
| | | | | | | |
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
Figure 4: Pass-through relationship between EAP peer, authenticator Figure 5: Pass-through relationship between EAP peer, authenticator
and backend authentication server. and backend authentication server.
Where these conditions cannot be met, a backend authentication server [b] Resource reclaimation. While key lifetimes may be securely
is typically required. In this exchange, as described in [RFC3579], negotiated, it is possible for the NAS or peer to reboot or reclaim
the authenticator acts as a pass-through between the EAP peer and a resources, and therefore not be able to cache keys for their full
backend authentication server. In this model, the authenticator lifetime. As a result, lifetime negotiation does not guarantee
delegates the access control decision to the backend authentication that the key cache will remain sychronized. It is therefore
server, which acts as a Key Distribution Center (KDC), supplying RECOMMENDED for the lower layer to provide a mechanism for key
keying material to both the EAP peer and authenticator. state resynchronization. Note that securing this mechanism may be
difficult since in this situation one or more of the parties
initially do not possess a key with which to protect the
resynchronization exchange.
Figure 4 illustrates the case where the authenticator acts as a 2.3.1. Local Key Lifetimes
pass-through. Here EAP is spoken between the peer and authenticator
as before. The authenticator then encapsulates EAP packets within a
AAA protocol such as RADIUS [RFC3579] or Diameter [I-D.ietf-aaa-eap],
and forwards packets to and from the backend authentication server,
which acts as the EAP server. Since the authenticator acts as a
pass-through, EAP methods (as well as the derived EAP Master Key, and
TEKs) reside only on the peer and backend authentication server.
On completion of a successful authentication, EAP methods on the EAP The Transient EAP Keys (TEKs) are session keys used to protect the
peer and EAP server export the Master Session Key (MSK) and Extended EAP conversation. The TEKs are internal to the EAP method and are
Master Session Key (EMSK). The backend authentication server then not exported. They remain valid only for the duration of the EAP
sends a message to the authenticator indicating that authentication conversation, and are lost once the EAP conversation completes.
has been successful, providing the AAA-Key within a protected package
known as the AAA-Token. Along with the keying material, the
AAA-Token contains attributes naming the enclosed keys and providing
context.
The MSK and EMSK are used to derive the AAA-Key and key name which EAP methods may also implement a cache for other local keying
are enclosed within the AAA-Token, transported to the NAS by the AAA material which may persist for multiple EAP conversations. For
server, and used within the secure association protocol for example, EAP methods based on TLS (such as EAP-TLS [RFC2716]) derive
derivation of Transient Session Keys (TSKs) required for the and cache the TLS Master Secret, typically for substantial time
negotiated ciphersuite. The TSKs are known only to the peer and periods. The lifetime of other local keying material calculated
authenticator. within the EAP method is defined by the method.
3. Security Associations 2.3.2. Exported Key Lifetimes
EAP key management involves four types of security associations All EAP methods generating keys are required to generate the MSK and
(SAs): EMSK, and may optionally generate the IV. However, although new
exported keys are generated during reauthentication, the lifetime of
exported keys is conceptually distinct from the reauthentication
time, since while reauthentication causes new exported keys to be
derived, exported keys may be cached on the peer and server after a
session completes and therefore their lifetime may be greater than
the reauthentication time.
[1] EAP SA. This is an SA between the peer and EAP server, which Although exported keys are generated by the EAP method, most existing
allows them to authenticate each other. EAP methods do not negotiate the lifetime of the exported keys. EAP,
defined in [RFC3748], also does not support the negotiation of
lifetimes for exported keying material such as the MSK, EMSK and IV.
[2] EAP method SA. This SA is also between the peer and EAP server. Several mechanisms exist for managing the lifetime of exported EAP
It stores state that can be used for "fast resume" or other keys. Exported EAP keys may be cached on the EAP server as well as
functionality in some EAP methods. Not all EAP methods create on the peer. On the EAP server, it is RECOMMENDED that the lifetime
such an SA. of exported keys be managed as a system parameter. Where the EAP
method does not support the negotiation of the exported key lifetime,
and where a negotiation mechanism is not provided by the lower lower,
it is RECOMMENDED that the peer assume a default value of the
exported key lifetime. A value of 8 hours is suggested.
[3] EAP-Key SA. This is an SA between the peer and EAP server, which Managing the lifetime of exported keys using a AAA attribute is NOT
is used to store the keying material exported by the EAP method. RECOMMENDED. This is problematic because although this would ensure
Current EAP server implementations do not retain this SA after transport of the exported key lifetime between the AAA server and the
the EAP conversation completes, but future implementations could authenticator, the goal is to synchronize the exported key lifetime
use this SA for pre-emptive key distribution. between the peer and EAP server. Providing the the exported key
lifetime on an per-session basis to the authenticator results in
requiring the authenticator to maintain EAP-Key SA state. As a
described in Section 3, EAP-Key SA state is typically only maintained
on the peer and server, so that this represents a substantial
additional burden.
[4] AAA SA(s). These SAs are between the authenticator and the 2.3.3. Calculated Key Lifetimes
backend authentication server. They permit the parties to
mutually authenticate each other and protect the communications
between them.
3.1 EAP SA (peer - EAP server) When keying material exported by EAP methods is replaced, new
calculated keys are also put in place. Similarly, when the keying
material exported by EAP methods expires, so do the calculated keys.
As a result, the lifetime of keys calculated from material exported
by EAP methods can be no larger than the lifetime of the keying
material they are calculated from. Since the lifetime of calculated
keys can be less than that of the exported keys they are derived
from, calculated key lifetimes are conceptually distinct from
exported key lifetimes and reauthentication times, and need to be
managed as a separate parameter.
In order for the peer and EAP server to authenticate each other, they Note that just as the reauthentication time and the exported key
need to store some information. lifetime are conceptually distinct parameters, so too are calculated
key lifetimes conceptually distinct from the reauthentication time.
The authentication can be based on different mechanisms, such as Today AAA protocols such as RADIUS [RFC2865] support the Session-
shared secrets or certificates. If the authentication is based on a Timeout attribute. As described in [RFC3580], this may be used to
shared secret key, the parties store the EAP method to be used and determine the maximum session time prior to reauthentication. Since
the key. The EAP server also stores the peer's identity and/or other reauthentication results in the derivation of new exported keys and
information necessary to decide whether access to some service should the transport of a new AAA-Key, while a session is in progress the
be granted. The peer stores information necessary to choose which maximum session time prior to reauthentication places an upper bound
secret to use for which service. on the AAA-Key lifetime.
3.2 EAP method SA (peer - EAP server) However, after the session has terminated, it is possible for the
AAA-Key to be cached on the authenticator. Therefore the AAA-Key
lifetime may be larger than the reauthentication time. As a result,
the AAA-Key lifetime needs to be managed as a separate parameter.
Since the lifetime of the AAA-Key within the authenticator key cache
is in part determined by authenticator resources, the AAA-Key
lifetime is typically managed as a system parameter on the
authenticator. Since the authenticator may have considerably fewer
resources than either the EAP peer or server, it is possible that
AAA-Key lifetime on the authenticator may be less than exported key
lifetime maintained by the server, or that the authenticator may need
to reclaim AAA-Key resources prior to expiration of the AAA-Key
lifetime.
As a result, the primary issue with managing the AAA-Key lifetime is
the determination by the peer whether a particular AAA-Key exists
within the key cache of a given authenticator. Transmitting the AAA-
Key lifetime from the AAA server to the authenticator is not helpful
in solving this problem in several important scenarios.
Where the AAA-key lifetime is negotiated between the authenticator
and the peer within the Secure Association Protocol, this may be used
by the peer to manage the lifetime of the AAA-Key once the Secure
Association Protocol has completed.
However, should a time gap may exist between the time of completion
of the EAP method and the initiation of the Secure Association
Protocol, the lifetime of the AAA-Key cannot be determined by the
peer during this period. As a result, unless the Secure Association
Protocol always follos the completion of the EAP method exchange
without a gap in time, it may not be possible for the peer and
authenticator to negotiate session-specific value of the AAA-Key
lifetime. For example, where EAP pre-authentication is used, the
AAA-Key may be derived and remain resident on the peer and
authenticator prior to initiation of the Secure Association Protocol.
However, if the AAA-Key lifetime is managed as an authenticator
system parameter, it may be possible for lower layer solutions to
bridge the gap. For example, the lower layer may utilize Discovery
mechanisms to ensure AAA-Key cache synchronization between the peer
and authenticator.
If the authenticator manages the AAA-Key cache by deleting the oldest
AAA-Key first (LIFO), the relative creation time of the last AAA-Key
to be deleted could be advertised with the Discovery phase, enabling
the peer to determine whether a given AAA-Key had been expired from
the authenticator key cache.
2.3.4. TSK Key Lifetimes
Since the TSKs depend on the AAA-Key, replacement of the AAA-Key
implies replacement of the TSKs. However, replacement of the TSKs
only implies replacement of the AAA-Key when the TSKs are taken from
a portion of the AAA-Key.
Therefore while the lifetime of the TSKs may be shorter than or equal
to the AAA-Key lifetime, the TSK lifetime cannot exceed the AAA-Key
lifetime. Where a Secure Association Protocol exists, it is possible
for TSKs to be refreshed prior to reauthentication, and so the TSK
Key Lifetime may also be shorter than or equal to the
reauthentication timeout. It is therefore RECOMMENDED that the TSK
Key lifetime be managed parameter distinct from the reauthentication
timeout and the AAA-Key lifetime (except where the TSK is taken from
the AAA-Key).
Where TSKs are established as the result of a Secure Association
Protocol exchange, it is RECOMMENDED that the Secure Association
Protocol include secure negotiation of the TSK lifetime between the
peer and authenticator. Where the TSK is taken from the AAA-Key,
there is no need to manage the TSK lifetime as a separate parameter,
since the TSK lifetime and AAA-Key lifetime are identical.
As described in Section 3, TSKs are part of Service SAs which reside
on the peer and authenticator and as with the AAA-Key lifetime, the
TSK lifetime is often determined by authenticator resources. As a
result, the AAA server has no insight into the TSK derivation
process, and by the principle of ciphersuite independence, it is not
appropriate for the AAA server to manage any aspect of the TSK
derivation process, including the TSK lifetime.
2.4. AAA-Key Scope
As described in Appendix E, the AAA-Key is calculated from the EMSK
and MSK by the EAP peer and server, and is used as the root of the
ciphersuite-specific key hierarchy. Where a backend authentication
server is present, the AAA-Key is transported from the EAP server to
the authenticator; where it is not present, the AAA-Key is calculated
on the authenticator.
The AAA-Key is restricted to use between the EAP peer that calculates
it, and the authenticator that either calculates it (where no backend
authenticator is present) or receives it from the server (where a
backend authenticator server is present). However, in practice
difficulties arise in ensuring that the AAA-Key is used only within
the defined scope.
A wide variety of authenticator and peer designs need to be
accomodated within the EAP key management framework. An
authenticator may contain multiple physical ports; a single physical
authenticator may, for the purpose of peer discovery, advertise
itself as multiple "virtual authenticators"; authenticators may be
compromised of multiple CPUs; authenticators may utilize clustering
in order to provide load balancing or failover. Similarly, a peer
may support multiple ports; may support multiple CPUs; or may support
clustering.
As illustrated in Figure 1, an EAP peer with multiple ports may be
attached to one or more authenticators, each with multiple ports.
Where an authenticator identifies itself to the peer only via use of
a port identifer (such as a link layer address), it may not be
obvious to the peer which authenticator ports are associated with
which authenticators.
Similarly, where an EAP peer identifies itself using a port
identifier (such as a link layer address), it may not be obvious to
the authenticator which peer ports are associated with which peers.
In such situations, the peer and authenticator may not be able to
determine the appropriate AAA-Key scope.
Additional issues arise when a single physical authenticator
advertises itself as multiple "virtual authenticators". In such a
situation, the EAP peer may act as though each "virtual
authenticator" represented a distinct physical authenticator, thereby
restricting the AAA-Key to use with the "virtual authenticator" that
it interacts with. However, depending on the architecture of the
physical AP, it may or may not share AAA-Keys between "virtual
authenticators". Once again, the peer and authenticator may not be
in agreement on the AAA-key scope.
This lack of synchronization may create security vulnerabilities.
For example, where the AAA-Key is shared between "virtual
authenticators" an EAP peer could authenticate with the "Guest"
"virtual authenticator" and derive a AAA-Key. The peer could then
use that AAA-Key within the Secure Association Protocol in order to
connect to the "Corporate Intranet" "virtual authenticator" within
the same physical authenticator. If the "virtual authenticators"
share a AAA-Key cache, then the attempt will be successful.
Several measures are recommended to address these issues:
[a] Authenticators are REQUIRED to cache associated authorizations
along with the AAA-Key and apply authorizations consistently. This
ensures that an attacker cannot obtain elevated privileges even
where the AAA-Key cache is shared between "virtual authenticators".
[b] It is RECOMMENDED that Secure Association Protocols utilize peer
and authenticator identities that are unambiguous and do not
incorporate implicit assumptions about peer and authenticator
architectures.
For example, using port-specific MAC addresses as identifiers is a
particularly poor choice, given that peers and authenticators may
have multiple ports.
[c] It is RECOMMENDED that physical authenticators maintain separate
AAA-Key caches for each "virtual authenticator".
[d] Where a "virtual authenticator" is implemented, the AAA client MAY
also be virtualized. Where a "virtual AAA client" is implemented,
each "virtual authenticator" identifies itself distinctly to the
AAA server. Where the AAA client and server communicate directly,
this enables the AAA server to authenticate each "virtual AAA
client" distinctly.
[e] The AAA server and authenticator MAY implement additional
attributes in order to further restrict the AAA-Key scope. When
this is done, it is RECOMMENDED that the Secure Association
Protocol be extended to enable the restrictions to be communicated
between the authenticator and the peer. For example, in 802.11,
the AAA server may provide the authenticator with a list of
authorized Called-Station-Ids and/or SSIDs for which the AAA-Key
is valid, restricting the use of the AAA-Key by the peer.
Similarly, the authenticator may provide the peer with a list of
Calling-Station-Ids for which the AAA-Key is valid.
2.5. Fast Handoff Support
Within EAP, "fast handoff" is defined as a conversation in which the
EAP exchange (phase 1a) and associated AAA passthrough is bypassed,
so as to reduce latency. Depending on the fast handoff mechanism,
AAA-Key transport (phase 1b) may also be bypassed or it may be
provided in a pre-emptive manner as in [IEEE-03-084] and [I-D.irtf-
aaaarch-handoff].
The introduction of fast handoff creates a new class of security
vulnerabilities as well as requirements for the secure handling of
authorization context.
2.5.1. Authorization Issues
In a typical network access scenario (dial-in, wireless LAN, etc.)
access control mechanisms are typically applied. These mechanisms
include user authentication as well as authorization for the offered
service.
As a part of the authentication process, the AAA network determines
the user's authorization profile. The user authorizations are
transmitted by the backend authentication server to the EAP
authenticator (also known as the Network Access Server or
authenticator) included with the AAA-Token, which also contains the
AAA-Key, in Phase 1b of the EAP conversation. Typically, the profile
is determined based on the user identity, but a certificate presented
by the user may also provide authorization information.
The backend authentication server is responsible for making a user
authorization decision, answering the following questions:
[a] Is this a legitimate user for this particular network?
[b] Is this user allowed the type of access he or she is requesting?
[c] Are there any specific parameters (mandatory tunneling, bandwidth,
filters, and so on) that the access network should be aware of for
this user?
[d] Is this user within the subscription rules regarding time of day?
[e] Is this user within his limits for concurrent sessions?
[f] Are there any fraud, credit limit, or other concerns that indicate
that access should be denied?
While the authorization decision is in principle simple, the process
is complicated by the distributed nature of AAA decision making.
Where brokering entities or proxies are involved, all of the AAA
devices in the chain from the authenticator to the home AAA server
are involved in the decision. For instance, a broker can disallow
access even if the home AAA server would allow it, or a proxy can add
authorizations (e.g., bandwidth limits).
Decisions can be based on static policy definitions and profiles as
well as dynamic state (e.g. time of day or limits on the number of
concurrent sessions). In addition to the Accept/Reject decision made
by the AAA chain, parameters or constraints can be communicated to
the authenticator.
The criteria for Accept/Reject decisions or the reasons for choosing
particular authorizations are typically not communicated to the
authenticator, only the final result. As a result, the authenticator
has no way to know what the decision was based on. Was a set of
authorization parameters sent because this service is always provided
to the user, or was the decision based on the time/day and the
capabilities of the requesting authenticator device?
2.5.2. Correctness in Fast Handoff
Bypassing all or portions of the AAA conversation creates challenges
in ensuring that authorization is properly handled. These include:
[a] Consistent application of session time limits. A fast handoff
should not automatically increase the available session time,
allowing a user to endlessly extend their network access by
changing the point of attachment.
[b] Avoidance of privilege elevation. A fast handoff should not result
in a user being granted access to services which they are not
entitled to.
[c] Consideration of dynamic state. In situations in which dynamic
state is involved in the access decision (day/time, simultaneous
session limit) it should be possible to take this state into
account either before or after access is granted. Note that
consideration of network-wide state such as simultaneous session
limits can typically only be taken into account by the backend
authentication server.
[d] Encoding of restrictions. Since a authenticator may not be aware
of the criteria considered by a backend authentication server when
allowing access, in order to ensure consistent authorization during
a fast handoff it may be necessary to explicitly encode the
restrictions within the authorizations provided in the AAA-Token.
[e] State validity. The introduction of fast handoff should not render
the authentication server incapable of keeping track of network-
wide state.
A fast handoff mechanism capable of addressing these concerns is
said to be "correct". One condition for correctness is as follows:
For a fast handoff to be "correct" it MUST establish on the new
device the same context as would have been created had the new
device completed a AAA conversation with the authentication server.
A properly designed fast handoff scheme will only succeed if it is
"correct" in this way. If a successful fast handoff would
establish "incorrect" state, it is preferable for it to fail, in
order to avoid creation of incorrect context.
Some backend authentication server and authenticator configurations
are incapable of meeting this definition of "correctness". For
example, if the old and new device differ in their capabilities, it
may be difficult to meet this definition of correctness in a fast
handoff mechanism that bypasses AAA. Backend authentication
servers often perform conditional evaluation, in which the
authorizations returned in an Access-Accept message are contingent
on the authenticator or on dynamic state such as the time of day or
number of simultaneous sessions. For example, in a heterogeneous
deployment, the backend authentication server might return
different authorizations depending on the authenticator making the
request, in order to make sure that the requested service is
consistent with the authenticator capabilities.
If differences between the new and old device would result in the
backend authentication server sending a different set of messages
to the new device than were sent to the old device, then if the
fast handoff mechanism bypasses AAA, then the fast handoff cannot
be carried out correctly.
For example, if some authenticator devices within a deployment
support dynamic VLANs while others do not, then attributes present
in the Access-Request (such as the authenticator-IP-Address,
authenticator-Identifier, Vendor-Identifier, etc.) could be
examined to determine when VLAN attributes will be returned, as
described in [RFC3580]. VLAN support is defined in [IEEE8021Q].
If a fast handoff bypassing the backend authentication server were
to occur between a authenticator supporting dynamic VLANs and
another authenticator which does not, then a guest user with access
restricted to a guest VLAN could be given unrestricted access to
the network.
Similarly, in a network where access is restricted based on the day
and time, Service Set Identifier (SSID), Calling-Station-Id or
other factors, unless the restrictions are encoded within the
authorizations, or a partial AAA conversation is included, then a
fast handoff could result in the user bypassing the restrictions.
In practice, these considerations limit the situations in which
fast handoff mechanisms bypassing AAA can be expected to be
successful. Where the deployed devices implement the same set of
services, it may be possible to do successful fast handoffs within
such mechanisms. However, where the supported services differ
between devices, the fast handoff may not succeed. For example,
[RFC2865], section 1.1 states:
"A authenticator that does not implement a given service MUST
NOT implement the RADIUS attributes for that service. For
example, a authenticator that is unable to offer ARAP service
MUST NOT implement the RADIUS attributes for ARAP. A
authenticator MUST treat a RADIUS access-accept authorizing an
unavailable service as an access-reject instead."
Note that this behavior only applies to attributes that are known,
but not implemented. For attributes that are unknown, section of 5
of [RFC2865] states:
"A RADIUS server MAY ignore Attributes with an unknown Type. A
RADIUS client MAY ignore Attributes with an unknown Type."
In order to perform a correct fast handoff, if a new device is
provided with RADIUS context for a known but unavailable service,
then it MUST process this context the same way it would handle a
RADIUS Access-Accept requesting an unavailable service. This MUST
cause the fast handoff to fail. However, if a new device is
provided with RADIUS context that indicates an unknown attribute,
then this attribute MAY be ignored.
Although it may seem somewhat counter-intuitive, failure is indeed
the "correct" result where a known but unsupported service is
requested. Presumably a correctly configured backend authentication
server would not request that a device carry out a service that it
does not implement. This implies that if the new device were to
complete a AAA conversation that it would be likely to receive
different service instructions. In such a case, failure of the
fast handoff is the desired result. This will cause the new device
to go back to the AAA server in order to receive the appropriate
service definition.
In practice, this implies that fast handoff mechanisms which bypass
AAA are most likely to be successful within a homogeneous device
deployment within a single administrative domain. For example, it
would not be advisable to carry out a fast handoff bypassing AAA
between a authenticator providing confidentiality and another
authenticator that does not support this service. The correct
result of such a fast handoff would be a failure, since if the
handoff were blindly carried out, then the user would be moved from
a secure to an insecure channel without permission from the backend
authentication server. Thus the definition of a "known but
unsupported service" MUST encompass requests for unavailable
security services. This includes vendor-specific attributes
related to security, such as those described in [RFC2548].
3. Security Associations
During EAP authentication and subsequent exchanges, four types of
security associations (SAs) are created:
[1] EAP method SA. This SA is between the peer and EAP server. It
stores state that can be used for "fast resume" or other
functionality in some EAP methods. Not all EAP methods create such
an SA.
[2] EAP-Key SA. This is an SA between the peer and EAP server, which
is used to store the keying material exported by the EAP method.
Current EAP server implementations do not retain this SA after the
EAP conversation completes, but future implementations could use
this SA for purposes such as pre-emptive key distribution.
[3] AAA SA(s). These SAs are between the authenticator and the backend
authentication server. They permit the parties to mutually
authenticate each other and protect the communications between
them.
[4] Service SA(s). These SAs are between the peer and authenticator,
and they are created as a result of phases 1-2 of the conversation
(see Section 1.3).
3.1. EAP Method SA (peer - EAP server)
An EAP method may store some state on the peer and EAP server even An EAP method may store some state on the peer and EAP server even
after phase 1a has completed. after phase 1a has completed.
Typically, this is used for "fast resume": the peer and EAP server Typically, this is used for "fast resume": the peer and EAP server
can confirm that they are still talking to the same party, perhaps can confirm that they are still talking to the same party, perhaps
using fewer roundtrips or less computational power. In this case, using fewer roundtrips or less computational power. In this case,
the EAP method SA is essentially a cache for performance the EAP method SA is essentially a cache for performance
optimization, and either party may remove the SA from its cache at optimization, and either party may remove the SA from its cache at
any point. any point.
skipping to change at page 24, line 10 skipping to change at page 32, line 4
EAP method implementations should consider the appropriate lifetime EAP method implementations should consider the appropriate lifetime
for the EAP method SA. "Fast resume" assumes that the information for the EAP method SA. "Fast resume" assumes that the information
required (primarily the keys in the EAP method SA) hasn't been required (primarily the keys in the EAP method SA) hasn't been
compromised. In case the original authentication was carried out compromised. In case the original authentication was carried out
using, for instance, a smart card, it may be easier to compromise the using, for instance, a smart card, it may be easier to compromise the
EAP method SA (stored on the PC, for instance), so typically the EAP EAP method SA (stored on the PC, for instance), so typically the EAP
method SAs have a limited lifetime. method SAs have a limited lifetime.
Contents: Contents:
o Implicitly, the EAP method this SA refers to o Implicitly, the EAP method this SA refers to
o One or more internal (non-exported) keys o One or more internal (non-exported) keys
o EAP method SA name o EAP method SA name
o SA lifetime o SA lifetime
3.2.1 Example: EAP-TLS 3.1.1. Example: EAP-TLS
In EAP-TLS [RFC2716], after the EAP authentication the client (peer) In EAP-TLS [RFC2716], after the EAP authentication the client (peer)
and server can store the following information: and server can store the following information:
o Implicitly, the EAP method this SA refers to (EAP-TLS) o Implicitly, the EAP method this SA refers to (EAP-TLS)
o Session identifier (a value selected by the server) o Session identifier (a value selected by the server)
o Certificate of the other party (server stores the clients's o Certificate of the other party (server stores the clients's
certificate and vice versa) certificate and vice versa)
o Ciphersuite and compression method o Ciphersuite and compression method
o TLS Master secret (known as the EAP-TLS Master Key or MK) o TLS Master secret (known as the EAP-TLS Master Key or MK)
o SA lifetime (ensuring that the SA is not stored forever) o SA lifetime (ensuring that the SA is not stored forever)
o If the client has multiple different credentials (certificates and o If the client has multiple different credentials (certificates
corresponding private keys), a pointer to those credentials and corresponding private keys), a pointer to those credentials
When the server initiates EAP-TLS, the client can look up the EAP-TLS When the server initiates EAP-TLS, the client can look up the EAP-TLS
SA based on the credentials it was going to use (certificate and SA based on the credentials it was going to use (certificate and
private key), and the expected credentials (certificate or name) of private key), and the expected credentials (certificate or name) of
the server. If an EAP-TLS SA exists, and it is not too old, the the server. If an EAP-TLS SA exists, and it is not too old, the
client informs the server about the existence of this SA by including client informs the server about the existence of this SA by including
its Session-Id in the TLS ClientHello message. The server then looks its Session-Id in the TLS ClientHello message. The server then looks
up the correct SA based on the Session-Id (or detects that it doesn't up the correct SA based on the Session-Id (or detects that it doesn't
yet have one). yet have one).
3.2.2 Example: EAP-AKA 3.1.2. Example: EAP-AKA
In EAP-AKA [I-D.arkko-pppext-eap-aka], after EAP authentication the In EAP-AKA [I-D.arkko-pppext-eap-aka], after EAP authentication the
client and server can store the following information: client and server can store the following information:
o Implicitly, the EAP method this SA refers to (EAP-AKA) o Implicitly, the EAP method this SA refers to (EAP-AKA)
o A re-authentication pseudonym o A re-authentication pseudonym
o The client's permanent identity (IMSI) (server) o The client's permanent identity (IMSI) (server)
o Replay protection counter o Replay protection counter
o Authentication key (K_aut) o Authentication key (K_aut)
o Encryption key (K_encr) o Encryption key (K_encr)
o Original Master Key (MK) o Original Master Key (MK)
o SA lifetime (ensuring that the SA is not stored forever) o SA lifetime (ensuring that the SA is not stored forever)
When the server initiates EAP-AKA, the client can look up the EAP-AKA When the server initiates EAP-AKA, the client can look up the EAP-AKA
SA based on the credentials it was going to use (permanent identity). SA based on the credentials it was going to use (permanent identity).
If an EAP-AKA SA exists, and it is not too old, the client informs If an EAP-AKA SA exists, and it is not too old, the client informs
the server about the existence of this SA by sending its the server about the existence of this SA by sending its re-
re-authentication pseudonym as its identity in EAP Identity Response authentication pseudonym as its identity in EAP Identity Response
message, instead of its permanent identity. The server then looks up message, instead of its permanent identity. The server then looks up
the correct SA based on this identity. the correct SA based on this identity.
3.3 EAP-key SA 3.2. EAP-key SA
This is an SA between the peer and EAP server, which is used to store This is an SA between the peer and EAP server, which is used to store
the keying material exported by the EAP method. Current EAP server the keying material exported by the EAP method. Current EAP server
implementations do not retain this SA after the EAP conversation implementations do not retain this SA after the EAP conversation
completes, but future implementations could use this SA for completes, but future implementations could use this SA for pre-
pre-emptive key distribution. emptive key distribution.
Contents: Contents:
o Name/identifier for this SA o Name/identifier for this SA
o Identities of the parties o Identities of the parties
o MSK and EMSK o MSK and EMSK
o SA lifetime
3.4 AAA SA(s) (authenticator - backend auth. server) 3.3. AAA SA(s) (authenticator - backend authentication server)
In order for the authenticator and backend authentication server to In order for the authenticator and backend authentication server to
authenticate each other, they need to store some information. authenticate each other, they need to store some information.
In case the authenticator and backend authentication server are In case the authenticator and backend authentication server are
colocated, and they communicate using local procedure calls or shared colocated, and they communicate using local procedure calls or shared
memory, this SA need not necessarily contain any information. memory, this SA need not necessarily contain any information.
3.4.1 Example: RADIUS 3.3.1. Example: RADIUS
In RADIUS, where shared secret authentication is used, the client and In RADIUS, where shared secret authentication is used, the client and
server store each other's IP address and the shared secret, which is server store each other's IP address and the shared secret, which is
used to calculate the Response Authenticator [RFC2865] and used to calculate the Response Authenticator [RFC2865] and Message-
Message-Authenticator [RFC3579] values, and to encrypt some Authenticator [RFC3579] values, and to encrypt some attributes (such
attributes (such as the AAA-Key [RFC2548]). as the AAA-Key [RFC2548]).
Where IPsec is used to protect RADIUS [RFC3579] and IKE is used for Where IPsec is used to protect RADIUS [RFC3579] and IKE is used for
key management, the parties store information necessary to key management, the parties store information necessary to
authenticate and authorize the other party (e.g. certificates, trust authenticate and authorize the other party (e.g. certificates, trust
anchors and names). The IKE exchange results in IKE Phase 1 and anchors and names). The IKE exchange results in IKE Phase 1 and
Phase 2 SAs containing information used to protect the conversation Phase 2 SAs containing information used to protect the conversation
(session keys, selected ciphersuite, etc.) (session keys, selected ciphersuite, etc.)
3.4.2 Example: Diameter with TLS 3.3.2. Example: Diameter with TLS
When using Diameter protected by TLS, the parties store information When using Diameter protected by TLS, the parties store information
necessary to authenticate and authorize the other party (e.g. necessary to authenticate and authorize the other party (e.g.
certificates, trust anchors and names). The TLS handshake results in certificates, trust anchors and names). The TLS handshake results in
a short-term TLS SA that contains information used to protect the a short-term TLS SA that contains information used to protect the
actual communications (session keys, selected TLS ciphersuite, etc.). actual communications (session keys, selected TLS ciphersuite, etc.).
3.5 Unicast Secure Association SA 3.4. Service SA(s) (peer - authenticator)
The unicast secure association SA exists between the EAP peer and The service SA stores information about the service being provided.
authenticator. It includes: This includes:
the peer port identifier (Calling-Station-Id) o Service parameters (or at least those parameters
the NAS port identifier (Called-Station-Id) that are still needed)
the unicast Transient Session Keys (TSKs) o On the authenticator, service authorization
the unicast secure association peer nonce information received from the backend authentication
the unicast secure association authenticator nonce server (or necessary parts of it)
the negotiated unicast capabilities and unicast ciphersuite. o On the peer, usually locally configured service
authorization information.
o Transient Session Keys used to protect the communication
o The AAA-Key, if it can be needed again (to refresh
and/or resynchronize other keys or for another reason)
o AAA-Key lifetime
During the phase 2a exchange, the EAP peer and authenticator The information in the service SA can be grouped into several
demonstrate mutual possession of the AAA-Key derived and transported different SAs. This would make sense if, for instance, the service
in phase 1; securely negotiate the session capabilities (including provided is naturally divided into several different subconversations
unicast ciphersuites), and derive fresh unicast transient session with different parameters.
keys. The AAA-Key SA (phase 1b) is therefore used to create the
unicast secure association SA (phase 2a), and in the process the
phase 2a unicast secure association SA is bound to ports on the EAP
peer and authenticator. However in order for a phase 2a security
association to be established, it is not necessary for the phase 1a
exchange to be rerun each time. This enables the EAP exchange to be
bypassed when fast handoff support is desired.
Since both peer and authenticator nonces are used in the creation of How exactly the relevant service SA is chosen at each point depends
the unicast secure association SA, the transient session keys (TSKs) on the protocol; see below for examples.
are guaranteed to be fresh, even if the AAA-Key is not. As a result
one or more unicast secure association SAs (phase 2a) may be derived
from a single AAA-Key SA (phase 1b). The phase 2a security
associations may utilize the same security parameters (e.g. mode,
ciphersuite, etc.) or they may utilize different parameters.
A unicast secure association SA (phase 2a) may not persist longer 3.4.1. Example: 802.11i
than the maximum lifetime of its parent AAA-Key SA (if known).
However, the deletion of a parent EAP or AAA-Key SA does not
necessarily imply deletion of the corresponding unicast secure
association SA. Similarly, the deletion of a unicast secure
association protocol SA does not imply the deletion of the parent
AAA-key SA or EAP SA. Failure to mutually prove possession of the
AAA-Key during the unicast secure association protocol exchange
(phase 2a) need not be grounds for removal of a AAA-Key SA by both
parties; rate-limiting unicast secure association exchanges should
suffice to prevent a brute force attack.
An EAP peer may be able to negotiate multiple phase 2a SAs with a [IEEE802.11i] Section 8.4.1.1 defines the security associations used
single EAP authenticator, or may be able to maintain multiple phase within IEEE 802.11. A summary follows; the standard should be
2a SAs with multiple authenticators, based on a single EAP SA derived consulted for details.
in phase 1a. For example, during a re-key of the secure association
protocol SA, it is possible for two phase 2a SAs to exist during the
period between when the new phase 2a SA parameters (such as the TSKs)
are calculated and when they are installed. Except where explicitly
specified by the semantics of the unicast secure association
protocol, it should not be assumed that the installation of a new
phase 2a SA necessarily implies deletion of the old phase 2a SA.
On some media (e.g. 802.11) a port on an EAP peer may only establish o Pairwise Master Key Security Association (PMKSA)
phase 2a and 2b SAs with a single port of an authenticator within a
given Local Area Network (LAN). This implies that the successful
negotiation of phase 2a and/or 2b SAs between an EAP peer port and a
new authentiator port within a given LAN implies the deletion of
existing phase 2a and 2b SAs with authenticators offering access to
that Local Area Network (LAN). However, since a given IEEE 802.11
SSID may be comprised of multiple LANs, this does not imply an
implicit binding of phase 2a and 2b SAs to an SSID.
3.6 Multicast Secure Association SA The PMKSA is a bi-directional SA, used by both parties for sending
and receiving. It is created on the peer when EAP authentication
completes successfully or a pre-shared key is configured. The
PMKSA is created on the authenticator when the PMK is received or
created on the authenticator or a pre-shared key is configured.
The PMKSA is used to create the PTKSA. PMKSAs are cached for
their lifetimes. The PMKSA consists of the following elements:
The multicast secure association SA includes: - PMKID (security association identifier)
- Authenticator MAC address
- PMK
- Lifetime
- Authenticated Key Management Protocol (AKMP)
- Authorization parameters specified the AAA server or
by local configuration. This can include
parameters such as the peer's authorized SSID.
On the peer, this information can be locally
configured.
- Key replay counters (for EAPOL-Key messages)
- Reference to PTKSA (if any), needed to:
o delete it (e.g. AAA server initiated disconnect)
o replace it when a new four-way handshake is done
- Reference to accounting context (the details of which depend
on the accounting protocol used, and various implementation
and administrative details. In RADIUS, this could include
(e.g. packet and octet counters, and Acct-Multi-Session-Id).
the multicast Transient Session Keys o Pairwise Transient Key Security Association (PTKSA)
the direction vector (for a uni-directional SA)
the negotiated multicast capabilities and multicast ciphersuite
It is possible for more than one multicast secure association SA to The PTKSA is a bi-directional SA created as the result of a
be derived from a single unicast secure association SA. However, a successful four-way handshake. There may only be one PTKSA
multicast secure association SA is bound to a single EAP SA and a between a pair of peer and authenticator MAC addresses. PTKSAs
single AAA-Key SA. are cached for the lifetime of the PMKSA. Since the PTKSA is tied
to the PMKSA, it only has the addititional information from the
4-way handshake. The PTKSA consists of the following:
During a re-key of the multicast secure association protocol SA, it - Key (PTK)
is possible for two phase 2b SAs to exist during the period between - Selected ciphersuite
when the new phase 2b SA parameters (such as the multicast TSKs) are - MAC addresses of the parties
calculated and when they are installed. Except where explicitly - Replay counters, and ciphersuite specific state
specified by the semantics of the multicast secure association - Reference to PMKSA: This is needed when:
protocol, it should not be assumed that the installation of a new o A new four-way handshake is needed (lifetime, TKIP
phase 2b SA necessarily implies deletion of the old phase 2b SA. countermeasures), and we need to know which PMKSA to use
A multicast secure association SA (phase 2b) may not persist longer o Group Transient Key Security Association (GTKSA)
than the maximum lifetime of its parent AAA-Key or unicast secure
association SA. However, the deletion of a parent EAP, AAA-Key or
unicast secure association SA does not necessarily imply deletion of
the corresponding multicast secure association SA. For example, a
unicast secure association SA may be rekeyed without implying a rekey
of the multicast secure association SA.
Similarly, the deletion of a multicast secure association protocol SA The GTKSA is a uni-directional SA created based on the four-way
does not imply the deletion of the parent EAP, AAA-Key or unicast handshake or the group key handshake. A GTKSA consists of the
secure association SA. Failure to mutually prove possession of the following:
AAA-Key during the unicast secure association protocol exchange
(phase 2a) need not be grounds for removal of the AAA-Key, unicast
secure association and multicast secure association SAs;
rate-limiting unicast secure association exchanges should suffice to
prevent a brute force attack.
3.7 Key Naming - Direction vector (whether the GTK is used for transmit or receive)
- Group cipher suite selector
- Key (GTK)
- Authenticator MAC addres
- Via reference to PMKSA, or copied here:
o Authorization parameters
o Reference to accounting context
3.4.2. Example: IKEv2/IPsec
Note that this example is intended to be informative, and it does not
necessarily include all information stored.
o IKEv2 SA
- Protocol version
- Identitities of the parties
- IKEv2 SPIs
- Selected ciphersuite
- Replay protection counters (Message ID)
- Keys for protecting IKEv2 messages (SK_ai/SK_ar/SK_ei/SK_er)
- Key for deriving keys for IPsec SAs (SK_d)
- Lifetime information
- On the authenticator, service authorization information
received from the backend authentication server.
When processing an incoming message, the correct SA is looked up based
on the SPIs.
o IPsec SAs/SPD
- Traffic selectors
- Replay protection counters
- Selected ciphersuite
- IPsec SPI
- Keys
- Lifetime information
- Protocol mode (tunnel or transport)
The correct SA is looked up based on SPI (for inbound packets), or
SPD traffic selectors (for outbound traffic). A separate IPsec SA
exists for each direction.
3.4.3. Sharing service SAs
A single service may be provided by multiple logical or physical
service elements. Each service is responsible for specifying how
changing service elements is handled. Some approaches include:
Transparent sharing
If the service parameters visible to the other party (either peer
or authenticator) do not change, the service can be moved without
requiring cooperation from the other party.
Whether such a move should be supported or used depends on
implementation and administrative considerations. For instance, an
administrator may decide to configure a group of IKEv2/IPsec
gateways in a cluster for high-availability purposes, if the
implementation used supports this. The peer does not necessarily
have any way of knowing when the change occurs.
No sharing
If the service parameters require changing, some changes may
require terminating the old service, and starting a new
conversation from phase 0. This approach is used by all services
for at least some parameters, and it doesn't require any protocol
for transferring the service SA between the service elements.
The service may support keeping the old service element active
while the new conversation takes phase, to decrease the time the
service is not available.
Some sharing
The service may allow changing some parameters by simply agreeing
about the new values. This may involve a similar exchange as in
phase 2, or perhaps a shorter conversation.
This option usually requires some protocol for transferring the
service SA between the elements. An administrator may decide not to
enable this feature at all, and typically the sharing is restricted
to some particular service elements (defined either by a service
parameter, or simple administrative decision). If the old and new
service element do not support such "context transfer", this
approach falls back to the previous option (no transfer).
Services supporting this feature should also consider what changes
require new authorization from the backend authentication server
(see Section 1.7).
Note that these considerations are not limited to service
parameters related to the authenticator--they apply to peer's
parameters as well.
3.5. SA Naming
In order to support the correct processing of phase 2 security In order to support the correct processing of phase 2 security
associations, the secure association (phase 2) protocol supports the associations, the Secure Association (phase 2) protocol supports the
naming of phase 2 security associations and associated transient naming of phase 2 security associations and associated transient
session keys, so that the correct set of transient session keys can session keys, so that the correct set of transient session keys can
be identified for processing a given packet. Explicit creation and be identified for processing a given packet. Explicit creation and
deletion operations are also typically supported so that deletion operations are also typically supported so that
establishment and re-establishment of transient session keys can be establishment and re-establishment of transient session keys can be
synchronized between the parties. synchronized between the parties.
In order to securely bind the AAA SA (phase 1b) to its child phase 2 In order to securely bind the AAA SA (phase 1b) to its child phase 2
security associations, the phase 2 secure association protocol allows security associations, the phase 2 Secure Association Protocol allows
the EAP peer and authenticator to mutually prove possession of the the EAP peer and authenticator to mutually prove possession of the
AAA-Key. In order to avoid confusion in the case where an EAP peer AAA-Key. In order to avoid confusion in the case where an EAP peer
has more than one AAA-Key (phase 1b) applicable to establishment of a has more than one AAA-Key (phase 1b) applicable to establishment of a
phase 2 security association, it is necessary for the secure phase 2 security association, it is necessary for the secure
association protocol (phase 2) to support key selection, so that the Association Protocol (phase 2) to support key selection, so that the
appropriate phase 1b keying material can be utilized by both parties appropriate phase 1b keying material can be utilized by both parties
in the secure association protocol exchange. in the Secure Association Protocol exchange.
For example, a peer might be pre-configured with policy indicating For example, a peer might be pre-configured with policy indicating
the ciphersuite to be used in communicating with a given the ciphersuite to be used in communicating with a given
authenticator. Within PPP, the ciphersuite is negotiated within the authenticator. Within PPP, the ciphersuite is negotiated within the
Encryption Control Protocol (ECP), after EAP authentication is Encryption Control Protocol (ECP), after EAP authentication is
completed. Within [IEEE80211i], the AP ciphersuites are advertised completed. Within [IEEE80211i], the AP ciphersuites are advertised
in the Beacon and Probe Responses, and are securely verified during a in the Beacon and Probe Responses, and are securely verified during a
4-way exchange after EAP authentication has completed. 4-way exchange after EAP authentication has completed.
As part of the secure association protocol (phase 2), it is necessary As part of the Secure Association Protocol (phase 2), it is necessary
to bind the Transient Session Keys (TSKs) to the keying material to bind the Transient Session Keys (TSKs) to the keying material
provided in the AAA-Token. This ensures that the EAP peer and provided in the AAA-Token. This ensures that the EAP peer and
authenticator are both clear about what key to use to provide mutual authenticator are both clear about what key to use to provide mutual
proof of possession. Keys within the EAP key hierarchy are named as proof of possession.
follows:
EAP SA name Keys within the EAP key hierarchy are named as follows:
The EAP security association is negotiated between the EAP peer
and EAP server, and is uniquely named as follows <EAP peer name,
EAP server name, EAP Method Type, EAP peer nonce, EAP server
nonce>. Here the EAP peer name and EAP server name are the
identifiers securely exchanged within the EAP method. Since
multiple EAP SAs may exist between an EAP peer and EAP server, the
EAP peer nonce and EAP server nonce allow EAP SAs to be
differentiated. The inclusion of the Method Type in the EAP SA
name ensures that each EAP method has a distinct EAP SA space.
MK Name EAP SA name
The EAP Master Key, if supported by an EAP method, is named by the The EAP security association is negotiated between the EAP peer and
concatenation of the EAP SA name and a method-specific session-id. EAP server, and is uniquely named as follows <EAP peer name, EAP
server name, EAP Method Type, EAP peer nonce, EAP server nonce>.
Here the EAP peer name and EAP server name are the identifiers
securely exchanged within the EAP method. Since multiple EAP SAs
may exist between an EAP peer and EAP server, the EAP peer nonce
and EAP server nonce allow EAP SAs to be differentiated. The
inclusion of the Method Type in the EAP SA name ensures that each
EAP method has a distinct EAP SA space.
AAA-Key Name AAA-Key Name
The AAA-Key is named by the concatenation of the EAP SA name, The AAA-Key is named by the concatenation of the EAP SA name, "AAA-
"AAA-Key" and the authenticator name, since the AAA-Key is bound Key" and the authenticator name, since the AAA-Key is bound to a
to a particular authenticator. For the purpose of identification, particular authenticator. For the purpose of identification, the
the NAS-Identifier attribute is recommended. In order to ensure NAS-Identifier attribute is recommended. In order to ensure that
that all parties can agree on the NAS name this requires the NAS all parties can agree on the NAS name this requires the NAS to
to advertise its name (typically using a media-specific mechanism, advertise its name (typically using a media-specific mechanism,
such as the 802.11 Beacon/Probe Response)." such as the 802.11 Beacon/Probe Response)."
4. Threat Model 4. Security considerations
4.1 Security Assumptions 4.1. Security Terminology
Figure 5 illustrates the relationship between the peer, authenticator Cryptographic binding
and backend authentication server. As noted in the figure, each party The demonstration of the EAP peer to the EAP server that a single
in the exchange mutually authenticates with each of the other entity has acted as the EAP peer for all methods executed within a
parties, and derives a unique key. All parties in the diagram have tunnel method. Binding MAY also imply that the EAP server
access to the AAA-Key. demonstrates to the peer that a single entity has acted as the EAP
server for all methods executed within a tunnel method. If
executed correctly, binding serves to mitigate man-in-the-middle
vulnerabilities.
Cryptographic separation
Two keys (x and y) are "cryptographically separate" if an adversary
that knows all messages exchanged in the protocol cannot compute x
from y or y from x without "breaking" some cryptographic
assumption. In particular, this definition allows that the
adversary has the knowledge of all nonces sent in cleartext as well
as all predictable counter values used in the protocol. Breaking a
cryptographic assumption would typically require inverting a one-
way function or predicting the outcome of a cryptographic pseudo-
random number generator without knowledge of the secret state. In
other words, if the keys are cryptographically separate, there is
no shortcut to compute x from y or y from x, but the work an
adversary must do to perform this computation is equivalent to
performing exhaustive search for the secret state value.
Key strength
If the effective key strength is N bits, the best currently known
methods to recover the key (with non-negligible probability)
require on average an effort comparable to 2^(N-1) operations of a
typical block cipher.
Mutual authentication
This refers to an EAP method in which, within an interlocked
exchange, the authenticator authenticates the peer and the peer
authenticates the authenticator. Two independent one-way methods,
running in opposite directions do not provide mutual authentication
as defined here.
4.2. Threat Model
The EAP threat model is described in [RFC3748], Section 7.1. In
order to address these threats, EAP relies on the security properties
of EAP methods (known as "security claims", described in [RFC3784],
Section 7.2.1). EAP method requirements for application such as
Wireless LAN authentication are described in [WLANREQ].
The RADIUS threat model is described in [RFC3579] Section 4.1, and
responses to these threats are described in [RFC3579] Sections 4.2
and 4.3. Among other things, [RFC3579] Section 4.2 recommends the
use of IPsec ESP with non-null transform to provide per-packet
authentication and confidentiality, integrity and replay protection
for RADIUS/EAP.
Given the existing documentation of EAP and AAA threat models and
responses, there is no need to duplicate that material here.
However, there are many other system-level threats no covered in
these document which have not been described or analyzed elsewhere.
These include:
[1] An attacker may try to modify or spoof Secure Association Protocol
packets.
[2] An attacker compromising an authenticator may provide incorrect
information to the EAP peer and/or server via out-of-band
mechanisms (such as via a AAA or lower layer protocol). This
includes impersonating another authenticator, or providing
inconsistent information to the peer and EAP server.
[3] An attacker may attempt to perform downgrading attacks on the
ciphersuite negotiation within the Secure Association Protocol in
order to ensure that a weaker ciphersuite is used to protect data.
Depending on the lower layer, these attacks may be carried out
without requiring physical proximity.
In order to address these threats, [Housley56] describes the
mandatory system security properties:
Algorithm independence
Wherever cryptographic algorithms are chosen, the algorithms must
be negotiable, in order to provide resilient against compromise of
a particular algorithm. Algorithm independence must be
demonstrated within all aspects of the system, including within
EAP, AAA and the Secure Association Protocol. However, for
interoperability, at least one suite of algorithms MUST be
implemented.
Strong, fresh session keys
Session keys must be demonstrated to be strong and fresh in all
circumstances, while at the same time retaining algorithm
independence.
Replay protection
All protocol exchanges must be replay protected. This includes
exchanges within EAP, AAA, and the Secure Association Protocol.
Authentication
All parties need to be authenticated. The confidentiality of the
authenticator must be maintained. No plaintext passwords are
allowed.
Authorization
EAP peer and authenticator authorization must be performed.
Session keys
Confidentiality of session keys must be maintained.
Ciphersuite negotiation
The selection of the "best" ciphersuite must be securely confirmed.
Unique naming
Session keys must be uniquely named.
Domino effect
Compromise of a single authenticator cannot compromise any other
part of the system, including session keys and long-term secrets.
Key binding
The key must be bound to the appropriate context.
4.3. Security Analysis
Figure 6 illustrates the relationship between the peer, authenticator
and backend authentication server.
EAP peer EAP peer
/\\ /\
/ \\ / \
Protocol: EAP / \\ Protocol: Secure Association Protocol: EAP / \ Protocol: Secure Association
Auth: Mutual / \\ Auth: Mutual Auth: Mutual / \ Auth: Mutual
Unique keys: MK, / \\ Unique keys: TSKs Unique keys: / \ Unique keys: TSKs
TEKs,EMSK / \\ TEKs,EMSK / \
/ \\ / \
Auth. server +--------------+ Authenticator EAP server +--------------+ Authenticator
Protocol: AAA Protocol: AAA
Auth: Mutual Auth: Mutual
Unique key: AAA session key Unique key: AAA session key
Figure 5: Three-party EAP key distribution Figure 6: Relationship between peer, authenticator and auth. server
The peer and EAP server communicate using EAP [RFC3748]. The
security properties of this communication are largely determined by
the chosen EAP method. Method security claims are described in
[RFC3748] Section 7.2. These include the key strength, protected
ciphersuite negotiation, mutual authentication, integrity protection,
replay protection, confidentiality, key derivation, key strength,
dictionary attack resistance, fast reconnect, cryptographic binding,
session independence, fragmentation and channel binding claims. At a
minimum, methods claiming to support key derivation must also support
mutual authentication. As noted in [RFC3748] Section 7.10:
EAP Methods deriving keys MUST provide for mutual authentication
between the EAP peer and the EAP Server.
Ciphersuite independence is also required:
Keying material exported by EAP methods MUST be independent of the
ciphersuite negotiated to protect data.
In terms of key strength and freshness, [RFC3748] Section 10 says:
EAP methods SHOULD ensure the freshness of the MSK and EMSK even
in cases where one party may not have a high quality random number
generator.... In order to preserve algorithm independence, EAP
methods deriving keys SHOULD support (and document) the protected
negotiation of the ciphersuite used to protect the EAP
conversation between the peer and server... In order to enable
deployments requiring strong keys, EAP methods supporting key
derivation SHOULD be capable of generating an MSK and EMSK, each
with an effective key strength of at least 128 bits.
The authenticator and backend authentication server communicate using
a AAA protocol such as RADIUS [RFC3579] or Diameter [I-D.ietf-aaa-
eap]. As noted in [RFC3588] Section 13, Diameter must be protected
by either IPsec ESP with non-null transform or TLS. As a result,
Diameter requires per-packet integrity and confidentiality. Replay
protection must be supported. For RADIUS, [RFC3579] Section 4.2
recommends that RADIUS be protected by IPsec ESP with a non-null
transform, and where IPsec is implemented replay protection must be
supported.
The peer and authenticator communicate using the Secure Association
Protocol.
As noted in the figure, each party in the exchange mutually
authenticates with each of the other parties, and derives a unique
key. All parties in the diagram have access to the AAA-Key.
The EAP peer and backend authentication server mutually authenticate The EAP peer and backend authentication server mutually authenticate
via the EAP method, and derive the MK, TEKs and EMSK which are known via the EAP method, and derive the TEKs and EMSK which are known only
only to them. The TEKs are used to protect some or all of the EAP to them. The TEKs are used to protect some or all of the EAP
conversation between the peer and authenticator, so as to guard conversation between the peer and authenticator, so as to guard
against modification or insertion of EAP packets by an attacker. The against modification or insertion of EAP packets by an attacker. The
degree of protection afforded by the TEKs is determined by the EAP degree of protection afforded by the TEKs is determined by the EAP
method; some methods may protect the entire EAP packet, including the method; some methods may protect the entire EAP packet, including the
EAP header, while other methods may only protect the contents of the EAP header, while other methods may only protect the contents of the
Type-Data field, defined in [I-D.ietf-eap-rfc2284bis]. Type-Data field, defined in [RFC3748].
Since EAP is spoken only between the EAP peer and server, if a Since EAP is spoken only between the EAP peer and server, if a
backend authentication server is present then the EAP conversation backend authentication server is present then the EAP conversation
does not provide mutual authentication between the peer and does not provide mutual authentication between the peer and
authenticator, only between the EAP peer and EAP server (backend authenticator, only between the EAP peer and EAP server (backend
authentication server). As a result, mutual authentication between authentication server). As a result, mutual authentication between
the peer and authenticator only occurs where a secure association the peer and authenticator only occurs where a Secure Association
protocol is used, such the unicast and group key derivation handshake protocol is used, such the unicast and group key derivation handshake
supported in [IEEE80211i]. This means that absent use of a secure supported in [IEEE80211i]. This means that absent use of a secure
association protocol, from the point of view of the peer, EAP mutual Association Protocol, from the point of view of the peer, EAP mutual
authentication only proves that the authenticator is trusted by the authentication only proves that the authenticator is trusted by the
backend authentication server; the identity of the authenticator is backend authentication server; the identity of the authenticator is
not confirmed. not confirmed.
Utilizing the AAA protocol, the authenticator and backend Utilizing the AAA protocol, the authenticator and backend
authentication server mutually authenticate and derive session keys authentication server mutually authenticate and derive session keys
known only to them, used to provide per-packet integrity and replay known only to them, used to provide per-packet integrity and replay
protection, authentication and confidentiality. The MSK is protection, authentication and confidentiality. The AAA-Key is
distributed by the backend authentication server to the authenticator distributed by the backend authentication server to the authenticator
over this channel, bound to attributes constraining its usage, as over this channel, bound to attributes constraining its usage, as
part of the AAA-Token. The binding of attributes to the MSK within a part of the AAA-Token. The binding of attributes to the AAA-Key
protected package is important so the authenticator receiving the within a protected package is important so the authenticator
AAA-Token can determine that it has not been compromised, and that receiving the AAA-Token can determine that it has not been
the keying material has not been replayed, or mis-directed in some compromised, and that the keying material has not been replayed, or
way. mis-directed in some way.
The security properties of the EAP exchange are dependent on each leg The security properties of the EAP exchange are dependent on each leg
of the triangle: the selected EAP method, AAA protocol and the secure of the triangle: the selected EAP method, AAA protocol and the Secure
association protocol. Association Protocol.
Assuming that the AAA protocol provides protection against rogue Assuming that the AAA protocol provides protection against rogue
authenticators forging their identity, then the AAA-Token can be authenticators forging their identity, then the AAA-Token can be
assumed to be sent to the correct authenticator, and where it is assumed to be sent to the correct authenticator, and where it is
wrapped appropriately, it can be assumed to be immune to compromise wrapped appropriately, it can be assumed to be immune to compromise
by a snooping attacker. by a snooping attacker.
Where an untrusted AAA intermediary is present, the AAA-Token must Where an untrusted AAA intermediary is present, the AAA-Token must
not be provided to the intermediary so as to avoid compromise of the not be provided to the intermediary so as to avoid compromise of the
AAA-Token. This can be avoided by use of re-direct as defined in AAA-Token. This can be avoided by use of re-direct as defined in
[RFC3588]. [RFC3588].
When EAP is used for authentication on PPP or wired IEEE 802 When EAP is used for authentication on PPP or wired IEEE 802
networks, it is typically assumed that the link is physically secure, networks, it is typically assumed that the link is physically secure,
so that an attacker cannot gain access to the link, or insert a rogue so that an attacker cannot gain access to the link, or insert a rogue
device. EAP methods defined in [I-D.ietf-eap-rfc2284bis] reflect this device. EAP methods defined in [RFC3748] reflect this usage model.
usage model. These include EAP MD5, as well as One-Time Password These include EAP MD5, as well as One-Time Password (OTP) and Generic
(OTP) and Generic Token Card. These methods support one-way Token Card. These methods support one-way authentication (from EAP
authentication (from EAP peer to authenticator) but not mutual peer to authenticator) but not mutual authentication or key
authentication or key derivation. As a result, these methods do not derivation. As a result, these methods do not bind the initial
bind the initial authentication and subsequent data traffic, even authentication and subsequent data traffic, even when the the
when the the ciphersuite used to protect data supports per-packet ciphersuite used to protect data supports per-packet authentication
authentication and integrity protection. As a result, EAP methods not and integrity protection. As a result, EAP methods not supporting
supporting mutual authentication are vulnerable to session hijacking mutual authentication are vulnerable to session hijacking as well as
as well as attacks by rogue devices. attacks by rogue devices.
On wireless networks such as IEEE 802.11 [IEEE80211], these attacks On wireless networks such as IEEE 802.11 [IEEE80211], these attacks
become easy to mount, since any attacker within range can access the become easy to mount, since any attacker within range can access the
wireless medium, or act as an access point. As a result, new wireless medium, or act as an access point. As a result, new
ciphersuites have been proposed for use with wireless LANs ciphersuites have been proposed for use with wireless LANs
[IEEE80211i] which provide per-packet authentication, integrity and [IEEE80211i] which provide per-packet authentication, integrity and
replay protection. In addition, mutual authentication and key replay protection. In addition, mutual authentication and key
derivation, provided by methods such as EAP-TLS [RFC2716] are derivation, provided by methods such as EAP-TLS [RFC2716] are
required [IEEE80211i], so as to address the threat of rogue devices, required [IEEE80211i], so as to address the threat of rogue devices,
and provide keying material to bind the initial authentication to and provide keying material to bind the initial authentication to
skipping to change at page 32, line 7 skipping to change at page 44, line 39
If the selected EAP method does not support mutual authentication, If the selected EAP method does not support mutual authentication,
then the peer will be vulnerable to attack by rogue authenticators then the peer will be vulnerable to attack by rogue authenticators
and backend authentication servers. If the EAP method does not derive and backend authentication servers. If the EAP method does not derive
keys, then TSKs will not be available for use with a negotiated keys, then TSKs will not be available for use with a negotiated
ciphersuite, and there will be no binding between the initial EAP ciphersuite, and there will be no binding between the initial EAP
authentication and subsequent data traffic, leaving the session authentication and subsequent data traffic, leaving the session
vulnerable to hijack. vulnerable to hijack.
If the backend authentication server does not protect against If the backend authentication server does not protect against
authenticator masquerade, or provide the proper binding of the authenticator masquerade, or provide the proper binding of the AAA-
AAA-Key to the session within the AAA-Token, then one or more Key to the session within the AAA-Token, then one or more AAA-Keys
AAA-Keys may be sent to an unauthorized party, and an attacker may be may be sent to an unauthorized party, and an attacker may be able to
able to gain access to the network. If the AAA-Token is provided to gain access to the network. If the AAA-Token is provided to an
an untrusted AAA intermediary, then that intermediary may be able to untrusted AAA intermediary, then that intermediary may be able to
modify the AAA-Key, or the attributes associated with it, as modify the AAA-Key, or the attributes associated with it, as
described in [RFC2607]. described in [RFC2607].
If the secure association protocol does not provide mutual proof of If the Secure Association Protocol does not provide mutual proof of
possession of the AAA-Key material, then the peer will not have possession of the AAA-Key material, then the peer will not have
assurance that it is connected to the correct authenticator, only assurance that it is connected to the correct authenticator, only
that the authenticator and backend authentication server share a that the authenticator and backend authentication server share a
trust relationship (since AAA protocols support mutual trust relationship (since AAA protocols support mutual
authentication). This distinction can become important when multiple authentication). This distinction can become important when multiple
authenticators receive AAA-Keys from the backend authentication authenticators receive AAA-Keys from the backend authentication
server, such as where fast handoff is supported. If the TSK server, such as where fast handoff is supported. If the TSK
derivation does not provide for protected ciphersuite and derivation does not provide for protected ciphersuite and
capabilities negotiation, then downgrade attacks are possible. capabilities negotiation, then downgrade attacks are possible.
4.2 Security Requirements 4.4. Man-in-the-middle Attacks
This section describes the security requirements for EAP methods, AAA As described in [I-D.puthenkulam-eap-binding], EAP method sequences
protocols, secure association protocols and Ciphersuites. These and compound authentication mechanisms may be subject to man-in-the-
requirements MUST be met by specifications requesting publication as middle attacks. When such attacks are successfully carried out, the
an RFC. Based on these requirements, the security properties of EAP attacker acts as an intermediary between a victim and a legitimate
exchanges are analyzed. authenticator. This allows the attacker to authenticate successfully
to the authenticator, as well as to obtain access to the network.
4.2.1 EAP method requirements In order to prevent these attacks, [I-D.puthenkulam-eap-binding]
recommends derivation of a compound key by which the EAP peer and
server can prove that they have participated in the entire EAP
exchange. Since the compound key must not be known to an attacker
posing as an authenticator, and yet must be derived from quantities
that are exported by EAP methods, it may be desirable to derive the
compound key from a portion of the EMSK. In order to provide proper
key hygiene, it is recommended that the compound key used for man-in-
the-middle protection be cryptographically separate from other keys
derived from the EMSK, such as fast handoff keys, discussed in
Appendix E.
4.5. Denial of Service Attacks
The caching of security associations may result in vulnerability to
denial of service attacks. Since an EAP peer may derive multiple EAP
SAs with a given EAP server, and creation of a new EAP SA does not
implicitly delete a previous EAP SA, EAP methods that result in
creation of persistent state may be vulnerable to denial of service
attacks by a rogue EAP peer.
As a result, EAP methods creating persistent state may wish to limit
the number of cached EAP SAs (Phase 1a) corresponding to an EAP peer.
For example, an EAP server may choose to only retain a few EAP SAs
for each peer. This prevents a rogue peer from denying access to
other peers.
Similarly, an authenticator may have multiple AAA-Key SAs
corresponding to a given EAP peer; to conserve resources an
authenticator may choose to limit the number of cached AAA-Key (Phase
1 b) SAs for each peer.
Depending on the media, creation of a new unicast Secure Association
SA may or may not imply deletion of a previous unicast secure
association SA. Where there is no implied deletion, the
authenticator may choose to limit Phase 2 (unicast and multicast)
Secure Association SAs for each peer.
4.6. Impersonation
Both the RADIUS and Diameter protocols are potentially vulnerable to
impersonation by a rogue authenticator.
While AAA protocols such as RADIUS [RFC2865] or Diameter [RFC3588]
support mutual authentication between the authenticator (known as the
AAA client) and the backend authentication server (known as the AAA
server), the security mechanisms vary according to the AAA protocol.
In RADIUS, the shared secret used for authentication is determined by
the source address of the RADIUS packet. As noted in [RFC3579]
Section 4.3.7, it is highly desirable that the source address be
checked against one or more NAS identification attributes so as to
detect and prevent impersonation attacks.
When RADIUS requests are forwarded by a proxy, the NAS-IP-Address or
NAS-IPv6-Address attributes may not correspond to the source address.
Since the NAS-Identifier attribute need not contain an FQDN, it also
may not correspond to the source address, even indirectly. [RFC2865]
Section 3 states:
A RADIUS server MUST use the source IP address of the RADIUS
UDP packet to decide which shared secret to use, so that
RADIUS requests can be proxied.
This implies that it is possible for a rogue authenticator to forge
NAS-IP-Address, NAS-IPv6-Address or NAS-Identifier attributes within
a RADIUS Access-Request in order to impersonate another
authenticator. Among other things, this can result in messages (and
MSKs) being sent to the wrong authenticator. Since the rogue
authenticator is authenticated by the RADIUS proxy or server purely
based on the source address, other mechanisms are required to detect
the forgery. In addition, it is possible for attributes such as the
Called-Station-Id and Calling-Station-Id to be forged as well.
As recommended in [RFC3579], this vulnerability can be mitigated by
having RADIUS proxies check authenticator identification attributes
against the source address.
To allow verification of session parameters such as the Called-
Station- Id and Calling-Station-Id, these can be sent by the EAP peer
to the server, protected by the TEKs. The RADIUS server can then
check the parameters sent by the EAP peer against those claimed by
the authenticator. If a discrepancy is found, an error can be
logged.
While [RFC3588] requires use of the Route-Record AVP, this utilizes
FQDNs, so that impersonation detection requires DNS A/AAAA and PTR
RRs to be properly configured. As a result, it appears that Diameter
is as vulnerable to this attack as RADIUS, if not more so. To address
this vulnerability, it is necessary to allow the backend
authentication server to communicate with the authenticator directly,
such as via the redirect functionality supported in [RFC3588].
4.7. Channel binding
It is possible for a compromised or poorly implemented EAP
authenticator to communicate incorrect information to the EAP peer
and/or server. This may enable an authenticator to impersonate
another authenticator or communicate incorrect information via out-
of-band mechanisms (such as via a AAA or lower layer protocol).
Where EAP is used in pass-through mode, the EAP peer typically does
not verify the identity of the pass-through authenticator, it only
verifies that the pass-through authenticator is trusted by the EAP
server. This creates a potential security vulnerability, described in
Section 7.15 of [RFC2284bis].
Section 4.3.7 of [RFC3579] describes how an EAP pass-through
authenticator acting as a AAA client can be detected if it attempts
to impersonate another authenticator (such by sending incorrect NAS-
Identifier [RFC2865], NAS-IP-Address [RFC2865] or NAS-IPv6-Address
[RFC3162] attributes via the AAA protocol). However, it is possible
for a pass-through authenticator acting as a AAA client to provide
correct information to the AAA server while communicating misleading
information to the EAP peer via a lower layer protocol.
For example, it is possible for a compromised authenticator to
utilize another authenticator's Called-Station-Id or NAS-Identifier
in communicating with the EAP peer via a lower layer protocol, or for
a pass-through authenticator acting as a AAA client to provide an
incorrect peer Calling-Station-Id [RFC2865][RFC3580] to the AAA
server via the AAA protocol.
As noted in Section 7.15 of [RFC3748] this vulnerability can be
addressed by use of EAP methods that support a protected exchange of
channel properties such as endpoint identifiers, including (but not
limited to): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id
[RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address
[RFC2865], and NAS-IPv6-Address [RFC3162].
Using such a protected exchange, it is possible to match the channel
properties provided by the authenticator via out-of-band mechanisms
against those exchanged within the EAP method.
4.8. Key Strength
In order to guard against brute force attacks, EAP methods deriving
keys need to be capable of generating keys with an appropriate
effective symmetric key strength. In order to ensure that key
generation is not the weakest link, it is necessary for EAP methods
utilizing public key cryptography to choose a public key that has a
cryptographic strength meeting the symmetric key strength
requirement.
As noted in Section 5 of [RFC3766], this results in the following
required RSA or DH module and DSA subgroup size in bits, for a given
level of attack resistance in bits:
Attack Resistance RSA or DH Modulus DSA subgroup
(bits) size (bits) size (bits)
----------------- ----------------- ------------
70 947 128
80 1228 145
90 1553 153
100 1926 184
150 4575 279
200 8719 373
250 14596 475
4.9. Key Wrap
As described in [RFC3579], Section 4.3, known problems exist in the
key wrap specified in [RFC2548]. Where the same RADIUS shared secret
is used by a PAP authenticator and an EAP authenticator, there is a
vulnerability to known plaintext attack. Since RADIUS uses the
shared secret for multiple purposes, including per-packet
authentication, attribute hiding, considerable information is exposed
about the shared secret with each packet. This exposes the shared
secret to dictionary attacks. MD5 is used both to compute the RADIUS
Response Authenticator and the Message-Authenticator attribute, and
some concerns exist relating to the security of this hash
[MD5Attack].
As discussed in [RFC3579], Section 4.3, the security vulnerabilities
of RADIUS are extensive, and therefore development of an alternative
key wrap technique based on the RADIUS shared secret would not
substantially improve security. As a result, [RFC3759], Section 4.2
recommends running RADIUS over IPsec. The same approach is taken in
Diameter EAP [I-D.ietf-aaa-eap], which defines cleartext key
attributes, to be protected by IPsec or TLS.
Where an untrusted AAA intermediary is present (such as a RADIUS
proxy or a Diameter agent), and data object security is not used, the
AAA-Key may be recovered by an attacker in control of the untrusted
intermediary. Possession of the AAA-Key enables decryption of data
traffic sent between the peer and a specific authenticator; however
where key separation is implemented, compromise of the AAA-Key does
not enable an attacker to impersonate the peer to another
authenticator, since that requires possession of the MK or EMSK,
which are not transported by the AAA protocol. This vulnerability
may be mitigated by implementation of redirect functionality, as
provided in [RFC3588].
5. Security Requirements
This section summarizes the security requirements that must be met by
EAP methods, AAA protocols, Secure Association Protocols and
Ciphersuites in order to address the security threats described in
this document. These requirements MUST be met by specifications
requesting publication as an RFC. Each requirement provides a
pointer to the sections of this document describing the threat that
it mitigates.
5.1. EAP Method Requirements
It is possible for the peer and EAP server to mutually authenticate It is possible for the peer and EAP server to mutually authenticate
and derive keys. In order to provide keying material for use in a and derive keys. In order to provide keying material for use in a
subsequently negotiated ciphersuite, an EAP method supporting key subsequently negotiated ciphersuite, an EAP method supporting key
derivation MUST export a Master Session Key (MSK) of at least 64 derivation MUST export a Master Session Key (MSK) of at least 64
octets, and an Extended Master Session Key (EMSK) of at least 64 octets, and an Extended Master Session Key (EMSK) of at least 64
octets. EAP Methods deriving keys MUST provide for mutual octets. EAP Methods deriving keys MUST provide for mutual
authentication between the EAP peer and the EAP Server. authentication between the EAP peer and the EAP Server.
The MSK and EMSK MUST NOT be used directly to protect data; however, The MSK and EMSK MUST NOT be used directly to protect data; however,
skipping to change at page 34, line 27 skipping to change at page 51, line 23
situations in which one of the parties discards key state which situations in which one of the parties discards key state which
remains valid on another party. remains valid on another party.
The development and validation of key derivation algorithms is The development and validation of key derivation algorithms is
difficult, and as a result EAP methods SHOULD reuse well established difficult, and as a result EAP methods SHOULD reuse well established
and analyzed mechanisms for key derivation (such as those specified and analyzed mechanisms for key derivation (such as those specified
in IKE [RFC2409] or TLS [RFC2246]), rather than inventing new ones. in IKE [RFC2409] or TLS [RFC2246]), rather than inventing new ones.
EAP methods SHOULD also utilize well established and analyzed EAP methods SHOULD also utilize well established and analyzed
mechanisms for MSK and EMSK derivation. mechanisms for MSK and EMSK derivation.
4.2.2 AAA Protocol Requirements 5.1.1. Requirements for EAP methods
In order for an EAP method to meet the guidelines for EMSK usage it
must meet the following requirements:
o It must specify how to derive the EMSK
o The key material used for the EMSK MUST be
computationally independent of the MSK and TEKs.
o The EMSK MUST NOT be used for any other purpose than the key
derivation described in this document.
o The EMSK MUST be secret and not known to someone observing
the authentication mechanism protocol exchange.
o The EMSK MUST be maintained within the EAP server.
Only keys (AMSKs) derived according to this specification
may be exported from the EAP server.
o The EMSK MUST be unique for each session.
o The EAP mechanism SHOULD provide a way of naming the EMSK.
Implementations of EAP frameworks on the EAP-Peer and EAP-Server
SHOULD provide an interface to obtain AMSKs. The implementation MAY
restrict which callers can obtain which keys.
5.1.2. Requirements for EAP applications
In order for an application to meet the guidelines for EMSK usage it
must meet the following requirements:
o The application MAY use the MSK transmitted to the NAS in any
way it chooses. This is required for backward compatibility. New
applications following this specification SHOULD NOT use the
MSK. If more than one application uses the MSK, then the
cryptographic separation is not achieved. Implementations SHOULD
prevent such combinations.
o The application MUST NOT use the EMSK in any other way except to
derive Application Master Session Keys (AMSK) using the key
derivation specified in this document. It MUST NOT
use the EMSK directly for cryptographic protection of data.
o Applications MUST define distinct key labels, application
specific data, length of derived key material used in the key
derivation described in section 2.4.3.
o Applications MUST define how they use their AMSK to derive TSKs
for their use.
5.2. AAA Protocol Requirements
AAA protocols suitable for use in transporting EAP MUST provide the AAA protocols suitable for use in transporting EAP MUST provide the
following facilities: following facilities:
Security services Security services
AAA protocols used for transport of EAP keying material MUST AAA protocols used for transport of EAP keying material MUST
implement and SHOULD use per-packet integrity and authentication, implement and SHOULD use per-packet integrity and authentication,
replay protection and confidentiality. These requirements are met replay protection and confidentiality. These requirements are met
by Diameter EAP [I-D.ietf-aaa-eap], as well as RADIUS over IPsec by Diameter EAP [I-D.ietf-aaa-eap], as well as RADIUS over IPsec
[RFC3579]. [RFC3579].
skipping to change at page 34, line 50 skipping to change at page 52, line 52
AAA protocols used for transport of EAP keying material MUST AAA protocols used for transport of EAP keying material MUST
implement and SHOULD use dynamic key management in order to derive implement and SHOULD use dynamic key management in order to derive
fresh session keys, as in Diameter EAP [I-D.ietf-aaa-eap] and fresh session keys, as in Diameter EAP [I-D.ietf-aaa-eap] and
RADIUS over IPsec [RFC3579], rather than using a static key, as RADIUS over IPsec [RFC3579], rather than using a static key, as
originally defined in RADIUS [RFC2865]. originally defined in RADIUS [RFC2865].
Mutual authentication Mutual authentication
AAA protocols used for transport of EAP keying material MUST AAA protocols used for transport of EAP keying material MUST
provide for mutual authentication between the authenticator and provide for mutual authentication between the authenticator and
backend authentication server. These requirements are met by backend authentication server. These requirements are met by
Diameter EAP [I-D.ietf-aaa-eap] as well as by RADIUS EAP Diameter EAP [I-D.ietf-aaa-eap] as well as by RADIUS EAP [RFC3579].
[RFC3579].
Authorization Authorization
AAA protocols used for transport of EAP keying material SHOULD AAA protocols used for transport of EAP keying material SHOULD
provide protection against rogue authenticators masquerading as provide protection against rogue authenticators masquerading as
other authenticators. This can be accomplished, for example, by other authenticators. This can be accomplished, for example, by
requiring that AAA agents check the source address of packets requiring that AAA agents check the source address of packets
against the origin attributes (Origin-Host AVP in Diameter, against the origin attributes (Origin-Host AVP in Diameter, NAS-IP-
NAS-IP-Address, NAS-IPv6-Address, NAS-Identifier in RADIUS). For Address, NAS-IPv6-Address, NAS-Identifier in RADIUS). For details,
details, see Section 4.3.7 of [RFC3579]. see Section 4.3.7 of [RFC3579].
Key transport Key transport
Since EAP methods do not export Transient Session Keys (TSKs) in Since EAP methods do not export Transient Session Keys (TSKs) in
order to maintain media and ciphersuite independence, the AAA order to maintain media and ciphersuite independence, the AAA
server MUST NOT transport TSKs from the backend authentication server MUST NOT transport TSKs from the backend authentication
server to authenticator. server to authenticator.
Key transport specification Key transport specification
In order to enable backend authentication servers to provide In order to enable backend authentication servers to provide keying
keying material to the authenticator in a well defined format, AAA material to the authenticator in a well defined format, AAA
protocols suitable for use with EAP MUST define the format and protocols suitable for use with EAP MUST define the format and
wrapping of the AAA-Token. wrapping of the AAA-Token.
EMSK transport EMSK transport
Since the EMSK is a secret known only to the backend Since the EMSK is a secret known only to the backend authentication
authentication server and peer, the AAA-Token MUST NOT transport server and peer, the AAA-Token MUST NOT transport the EMSK from the
the EMSK from the backend authentication server to the backend authentication server to the authenticator.
authenticator.
AAA-Token protection AAA-Token protection
To ensure against compromise, the AAA-Token MUST be integrity To ensure against compromise, the AAA-Token MUST be integrity
protected, authenticated, replay protected and encrypted in protected, authenticated, replay protected and encrypted in
transit, using well-established cryptographic algorithms. transit, using well-established cryptographic algorithms.
Session Keys Session Keys
The AAA-Token SHOULD be protected with session keys as in Diameter The AAA-Token SHOULD be protected with session keys as in Diameter
[RFC3588] or RADIUS over IPsec [RFC3579] rather than static keys, [RFC3588] or RADIUS over IPsec [RFC3579] rather than static keys,
as in [RFC2548]. as in [RFC2548].
Key naming Key naming
In order to ensure against confusion between the appropriate In order to ensure against confusion between the appropriate keying
keying material to be used in a given secure association protocol material to be used in a given Secure Association Protocol
exchange, the AAA-Token SHOULD include explicit key names and exchange, the AAA-Token SHOULD include explicit key names and
context appropriate for informing the authenticator how the keying context appropriate for informing the authenticator how the keying
material is to be used. material is to be used.
Key Compromise Key Compromise
Where untrusted intermediaries are present, the AAA-Token SHOULD Where untrusted intermediaries are present, the AAA-Token SHOULD
NOT be provided to the intermediaries. In Diameter, handling of NOT be provided to the intermediaries. In Diameter, handling of
keys by intermediaries can be avoided using Redirect functionality keys by intermediaries can be avoided using Redirect functionality
[RFC3588]. [RFC3588].
4.2.3 Secure Association Protocol Requirements 5.3. Secure Association Protocol Requirements
The Secure Association Protocol supports the following: The Secure Association Protocol supports the following:
Entity Naming
The peer and authenticator SHOULD identify themselves in a manner
that is independent of their attached ports.
Mutual proof of possession Mutual proof of possession
The peer and authenticator MUST each demonstrate possession of the The peer and authenticator MUST each demonstrate possession of the
keying material transported between the AAA server and keying material transported between the backend authentication
authenticator (AAA-Key). server and authenticator (AAA-Key).
Key Naming Key Naming
The Secure Association Protocol MUST explicitly name the keys used The Secure Association Protocol MUST explicitly name the keys used
in the proof of possession exchange, so as to prevent confusion in the proof of possession exchange, so as to prevent confusion
when more than one set of keying material could potentially be when more than one set of keying material could potentially be used
used as the basis for the exchange. as the basis for the exchange.
Creation and Deletion Creation and Deletion
In order to support the correct processing of phase 2 security In order to support the correct processing of phase 2 security
associations, the secure association (phase 2) protocol MUST associations, the Secure Association (phase 2) protocol MUST
support the naming of phase 2 security associations and associated support the naming of phase 2 security associations and associated
transient session keys, so that the correct set of transient transient session keys, so that the correct set of transient
session keys can be identified for processing a given packet. The session keys can be identified for processing a given packet. The
phase 2 secure association protocol also MUST support transient phase 2 Secure Association Protocol also MUST support transient
session key activation and SHOULD support deletion, so that session key activation and SHOULD support deletion, so that
establishment and re-establishment of transient session keys can establishment and re-establishment of transient session keys can be
be synchronized between the parties. synchronized between the parties.
Integrity and Replay Protection Integrity and Replay Protection
The Secure Association Protocol MUST support integrity and replay The Secure Association Protocol MUST support integrity and replay
protection of all messages. protection of all messages.
Direct operation Direct operation
Since the phase 2 secure association protocol is concerned with Since the phase 2 Secure Association Protocol is concerned with the
the establishment of security associations between the EAP peer establishment of security associations between the EAP peer and
and authenticator, including the derivation of transient session authenticator, including the derivation of transient session keys,
keys, only those parties have "a need to know" the transient only those parties have "a need to know" the transient session
session keys. The secure association protocol MUST operate keys. The Secure Association Protocol MUST operate directly between
directly between the peer and authenticator, and MUST NOT be the peer and authenticator, and MUST NOT be passed-through to the
passed-through to the backend authentication server, or include backend authentication server, or include additional parties.
additional parties.
Derivation of transient session keys Derivation of transient session keys
The secure association protocol negotiation MUST support The Secure Association Protocol negotiation MUST support derivation
derivation of unicast and multicast transient session keys of unicast and multicast transient session keys suitable for use
suitable for use with the negotiated ciphersuite. with the negotiated ciphersuite.
TSK freshness TSK freshness
The secure association (phase 2) protocol MUST support the The Secure Association (phase 2) Protocol MUST support the
derivation of fresh unicast and multicast transient session keys, derivation of fresh unicast and multicast transient session keys,
even when the keying material provided by the AAA server is not even when the keying material provided by the backend
fresh. This is typically supported by including an exchange of authentication server is not fresh. This is typically supported by
nonces within the secure association protocol. including an exchange of nonces within the Secure Association
Protocol.
Bi-directional operation Bi-directional operation
While some ciphersuites only require a single set of transient While some ciphersuites only require a single set of transient
session keys to protect traffic in both directions, other session keys to protect traffic in both directions, other
ciphersuites require a unique set of transient session keys in ciphersuites require a unique set of transient session keys in each
each direction. The phase 2 secure association protocol SHOULD direction. The phase 2 Secure Association Protocol SHOULD provide
provide for the derivation of unicast and multicast keys in each for the derivation of unicast and multicast keys in each direction,
direction, so as not to require two separate phase 2 exchanges in so as not to require two separate phase 2 exchanges in order to
order to create a bi-directional phase 2 security association. create a bi-directional phase 2 security association.
Secure capabilities negotiation Secure capabilities negotiation
The Secure Association Protocol MUST support secure capabilities The Secure Association Protocol MUST support secure capabilities
negotiation. This includes security parameters such as the negotiation. This includes security parameters such as the
security association identifier (SAID) and ciphersuites. It also security association identifier (SAID) and ciphersuites, as well as
includes confirmation of the capabilities discovered during the negotiation of the lifetime of the TSKs, AAA-Key and exported EAP
discovery phase (phase 0), so as to ensure that the announced keys. Secure capabilities negotiation also includes confirmation
capabilities have not been forged. of the capabilities discovered during the discovery phase (phase
0), so as to ensure that the announced capabilities have not been
forged.
4.2.4 Ciphersuite Requirements Key Scoping
The Secure Association Protocol MUST ensure the synchronization of
key scope between the peer and authenticator. This includes
negotiation of restrictions on key usage.
5.4. Ciphersuite Requirements
Ciphersuites suitable for keying by EAP methods MUST provide the Ciphersuites suitable for keying by EAP methods MUST provide the
following facilities: following facilities:
TSK derivation TSK derivation
In order to allow a ciphersuite to be usable within the EAP keying In order to allow a ciphersuite to be usable within the EAP keying
framework, a specification MUST be provided describing how framework, a specification MUST be provided describing how
transient session keys suitable for use with the ciphersuite are transient session keys suitable for use with the ciphersuite are
derived from the AAA-Key. derived from the AAA-Key.
skipping to change at page 38, line 5 skipping to change at page 56, line 11
Algorithms for deriving transient session keys from the AAA-Key Algorithms for deriving transient session keys from the AAA-Key
MUST NOT depend on the EAP method. However, algorithms for MUST NOT depend on the EAP method. However, algorithms for
deriving TEKs MAY be specific to the EAP method. deriving TEKs MAY be specific to the EAP method.
Cryptographic separation Cryptographic separation
The TSKs derived from the AAA-Key MUST be cryptographically The TSKs derived from the AAA-Key MUST be cryptographically
separate from each other. Similarly, TEKs MUST be separate from each other. Similarly, TEKs MUST be
cryptographically separate from each other. In addition, the TSKs cryptographically separate from each other. In addition, the TSKs
MUST be cryptographically separate from the TEKs. MUST be cryptographically separate from the TEKs.
5. IANA Considerations 6. IANA Considerations
This specification does not create any new registries, or define any
new EAP codes or types.
6. Security Considerations
6.1 Key Strength
In order to guard against brute force attacks, EAP methods deriving
keys need to be capable of generating keys with an appropriate
effective symmetric key strength. In order to ensure that key
generation is not the weakest link, it is necessary for EAP methods
utilizing public key cryptography to choose a public key that has a
cryptographic strength meeting the symmetric key strength
requirement.
As noted in Section 5 of [I-D.orman-public-key-lengths], this results
in the following required RSA or DH module and DSA subgroup size in
bits, for a given level of attack resistance in bits:
Attack Resistance RSA or DH Modulus DSA subgroup
(bits) size (bits) size (bits)
----------------- ----------------- ------------
70 947 128
80 1228 145
90 1553 153
100 1926 184
150 4575 279
200 8719 373
250 14596 475
6.2 Key Wrap
As described in [RFC3579], Section 4.3, known problems exist in the
key wrap specified in [RFC2548]. Where the same RADIUS shared secret
is used by a PAP authenticator and an EAP authenticator, there is a
vulnerability to known plaintext attack. Since RADIUS uses the
shared secret for multiple purposes, including per-packet
authentication, attribute hiding, considerable information is exposed
about the shared secret with each packet. This exposes the shared
secret to dictionary attacks. MD5 is used both to compute the RADIUS
Response Authenticator and the Message-Authenticator attribute, and
some concerns exist relating to the security of this hash
[MD5Attack]. As discussed in [RFC3579], Section 4.2, these and other
RADIUS vulnerabilities may be addressed by running RADIUS over IPsec.
Where an untrusted AAA intermediary is present (such as a RADIUS
proxy or a Diameter agent), and data object security is not used, the
AAA-Key may be recovered by an attacker in control of the untrusted
intermediary. Possession of the AAA-Key enables decryption of data
traffic sent between the peer and a specific authenticator; however
where key separation is implemented, compromise of the AAA-Key does
not enable an attacker to impersonate the peer to another
authenticator, since that requires possession of the MK or EMSK,
which are not transported by the AAA protocol. This vulnerability
may be mitigated by implementation of redirect functionality, as
provided in[RFC3588].
6.3 Man-in-the-middle Attacks
As described in [I-D.puthenkulam-eap-binding], EAP method sequences
and compound authentication mechanisms may be subject to
man-in-the-middle attacks. When such attacks are successfully
carried out, the attacker acts as an intermediary between a victim
and a legitimate authenticator. This allows the attacker to
authenticate successfully to the authenticator, as well as to obtain
access to the network.
In order to prevent these attacks, [I-D.puthenkulam-eap-binding]
recommends derivation of a compound key by which the EAP peer and
server can prove that they have participated in the entire EAP
exchange. Since the compound key must not be known to an attacker
posing as an authenticator, and yet must be derived from quantities
that are exported by EAP methods, it may be desirable to derive the
compound key from a portion of the EMSK. In order to provide proper
key hygiene, it is recommended that the compound key used for
man-in-the-middle protection be cryptographically separate from other
keys derived from the EMSK, such as fast handoff keys, discussed in
Appendix E.
6.4 Impersonation
Both the RADIUS and Diameter protocols are potentially vulnerable to
impersonation by a rogue authenticator.
When RADIUS requests are forwarded by a proxy, the NAS-IP-Address or
NAS-IPv6-Address attributes may not correspond to the source address.
Since the NAS-Identifier attribute need not contain an FQDN, it also
may not correspond to the source address, even indirectly. [RFC2865]
Section 3 states:
A RADIUS server MUST use the source IP address of the RADIUS
UDP packet to decide which shared secret to use, so that
RADIUS requests can be proxied.
This implies that it is possible for a rogue authenticator to forge
NAS-IP-Address, NAS-IPv6-Address or NAS-Identifier attributes within
a RADIUS Access-Request in order to impersonate another
authenticator. Among other things, this can result in messages (and
MSKs) being sent to the wrong authenticator. Since the rogue
authenticator is authenticated by the RADIUS proxy or server purely
based on the source address, other mechanisms are required to detect
the forgery. In addition, it is possible for attributes such as the
Called-Station-Id and Calling-Station-Id to be forged as well.
As recommended in [RFC3579], this vulnerability can be mitigated by
having RADIUS proxies check authenticator identification attributes
against the source address.
To allow verification of session parameters such as the
Called-Station- Id and Calling-Station-Id, these can be sent by the
EAP peer to the server, protected by the TEKs. The RADIUS server can
then check the parameters sent by the EAP peer against those claimed
by the authenticator. If a discrepancy is found, an error can be
logged.
While [RFC3588] requires use of the Route-Record AVP, this utilizes
FQDNs, so that impersonation detection requires DNS A/AAAA and PTR
RRs to be properly configured. As a result, it appears that Diameter
is as vulnerable to this attack as RADIUS, if not more so. To address
this vulnerability, it is necessary to allow the backend
authentication server to communicate with the authenticator directly,
such as via the redirect functionality supported in [RFC3588].
6.5 Denial of Service Attacks
The caching of security associations may result in vulnerability to
denial of service attacks. Since an EAP peer may derive multiple EAP
SAs with a given EAP server, and creation of a new EAP SA does not
implicitly delete a previous EAP SA, EAP methods that result in
creation of persistant state may be vulnerable to denial of service
attacks by a rogue EAP peer.
As a result, EAP methods creating persistent state may wish to limit
the number of cached EAP SAs (Phase 1a) corresponding to an EAP peer.
For example, an EAP server may choose to only retain a few EAP SAs
for each peer. This prevents a rogue peer from denying access to
other peers.
Similarly, an authenticator may have multiple AAA-Key SAs
corresponding to a given EAP peer; to conserve resources an
authenticator may choose to limit the number of cached AAA-Key (Phase
1 b) SAs for each peer.
Depending on the media, creation of a new unicast secure association This section provides guidance to the Internet Assigned Numbers
SA may or may not imply deletion of a previous unicast secure Authority (IANA) regarding registration of values related to EAP key
association SA. Where there is no implied deletion, the management, in accordance with BCP 26, [RFC2434].
authenticator may choose to limit Phase 2 (unicast and multicast)
secure association SAs for each peer.
7. Acknowledgements The following terms are used here with the meanings defined in BCP
26: "name space", "assigned value", "registration".
Thanks to Arun Ayyagari, Ashwin Palekar, and Tim Moore of Microsoft, The following policies are used here with the meanings defined in BCP
Dorothy Stanley of Agere, Bob Moskowitz of TruSecure, and Russ 26: "Private Use", "First Come First Served", "Expert Review",
Housley of Vigil Security for useful feedback. "Specification Required", "IETF Consensus", "Standards Action".
Normative References For registration requests where a Designated Expert should be
consulted, the responsible IESG area director should appoint the
Designated Expert. The intention is that any allocation will be
accompanied by a published RFC. But in order to allow for the
allocation of values prior to the RFC being approved for publication,
the Designated Expert can approve allocations once it seems clear
that an RFC will be published. The Designated expert will post a
request to the EAP WG mailing list (or a successor designated by the
Area Director) for comment and review, including an Internet-Draft.
Before a period of 30 days has passed, the Designated Expert will
either approve or deny the registration request and publish a notice
of the decision to the EAP WG mailing list or its successor, as well
as informing IANA. A denial notice must be justified by an
explanation and, in the cases where it is possible, concrete
suggestions on how the request can be modified so as to become
acceptable.
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 7. References
RFC 1661, July 1994.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 7.1. Normative References
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2119]
IANA Considerations Section in RFCs", BCP 26, RFC 2434, Bradner, S., "Key words for use in RFCs to Indicate Requirement
October 1998. Levels", BCP 14, RFC 2119, March 1997.
[I-D.ietf-eap-rfc2284bis] [RFC2434]
Blunk, L., "Extensible Authentication Protocol (EAP)", Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
draft-ietf-eap-rfc2284bis-06 (work in progress), September Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
2003.
[IEEE802] Institute of Electrical and Electronics Engineers, "IEEE [RFC3748]
Standards for Local and Metropolitan Area Networks: Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. Lefkowetz,
Overview and Architecture", ANSI/IEEE Standard 802, 1990. "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
Informative References 7.2. Informative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC [RFC0793]
793, September 1981. Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
April 1992. 1661, July 1994.
[RFC1968] Meyer, G. and K. Fox, "The PPP Encryption Control Protocol [RFC1968] Meyer, G. and K. Fox, "The PPP Encryption Control Protocol
(ECP)", RFC 1968, June 1996. (ECP)", RFC 1968, June 1996.
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
Keyed-Hashing for Message Authentication", RFC 2104, for Message Authentication", RFC 2104, February 1997.
February 1997.
[RFC2246] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. [RFC2246] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A.
and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246,
January 1999. January 1999.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
(IKE)", RFC 2409, November 1998. Internet Protocol", RFC 2401, November 1998.
[RFC2419] Sklower, K. and G. Meyer, "The PPP DES Encryption [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
Protocol, Version 2 (DESE-bis)", RFC 2419, September 1998. RFC 2409, November 1998.
[RFC2420] Kummert, H., "The PPP Triple-DES Encryption Protocol [RFC2419] Sklower, K. and G. Meyer, "The PPP DES Encryption Protocol,
(3DESE)", RFC 2420, September 1998. Version 2 (DESE-bis)", RFC 2419, September 1998.
[RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D. [RFC2420] Kummert, H., "The PPP Triple-DES Encryption Protocol (3DESE)",
and R. Wheeler, "A Method for Transmitting PPP Over RFC 2420, September 1998.
Ethernet (PPPoE)", RFC 2516, February 1999.
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D. and
RFC 2548, March 1999. R. Wheeler, "A Method for Transmitting PPP Over Ethernet
(PPPoE)", RFC 2516, February 1999.
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC
2548, March 1999.
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
Implementation in Roaming", RFC 2607, June 1999. Implementation in Roaming", RFC 2607, June 1999.
[RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol",
Protocol", RFC 2716, October 1999. RFC 2716, October 1999.
[RFC2855] Fujisawa, K., "DHCP for IEEE 1394", RFC 2855, June 2000.
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", RFC
2865, June 2000.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Authentication Dial In User Service (RADIUS)", RFC 2865, June
Zhang, L. and V. Paxson, "Stream Control Transmission 2000.
Protocol", RFC 2960, October 2000.
[RFC3078] Pall, G. and G. Zorn, "Microsoft Point-To-Point Encryption [RFC3078] Pall, G. and G. Zorn, "Microsoft Point-To-Point Encryption
(MPPE) Protocol", RFC 3078, March 2001. (MPPE) Protocol", RFC 3078, March 2001.
[RFC3079] Zorn, G., "Deriving Keys for use with Microsoft [RFC3079] Zorn, G., "Deriving Keys for use with Microsoft Point-to-Point
Point-to-Point Encryption (MPPE)", RFC 3079, March 2001. Encryption (MPPE)", RFC 3079, March 2001.
[RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard
(AES) Key Wrap Algorithm", RFC 3394, September 2002.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial
Dial In User Service) Support For Extensible In User Service) Support For Extensible Authentication
Authentication Protocol (EAP)", RFC 3579, September 2003. Protocol (EAP)", RFC 3579, September 2003.
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese,
"IEEE 802.1X Remote Authentication Dial In User Service "IEEE 802.1X Remote Authentication Dial In User Service
(RADIUS) Usage Guidelines", RFC 3580, September 2003. (RADIUS) Usage Guidelines", RFC 3580, September 2003.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public
Keys Used For Exchanging Symmetric Keys", RFC 3766, April
2004.
[FIPSDES] National Institute of Standards and Technology, "Data [FIPSDES] National Institute of Standards and Technology, "Data
Encryption Standard", FIPS PUB 46, January 1977. Encryption Standard", FIPS PUB 46, January 1977.
[DESMODES] [DESMODES]
National Institute of Standards and Technology, "DES Modes National Institute of Standards and Technology, "DES Modes of
of Operation", FIPS PUB 81, December 1980, <http:// Operation", FIPS PUB 81, December 1980, <http://
www.itl.nist.gov/fipspubs/fip81.htm>. www.itl.nist.gov/fipspubs/fip81.htm>.
[FIPS197] National Institute of Standards and Technology, "Advanced [IEEE802] Institute of Electrical and Electronics Engineers, "IEEE
Encryption Standard (AES)", FIPS PUB 197, November 2001. Standards for Local and Metropolitan Area Networks: Overview
and Architecture", ANSI/IEEE Standard 802, 1990.
[FIPS.180-1.1995]
National Institute of Standards and Technology, "Secure
Hash Standard", FIPS PUB 180-1, April 1995, <http://
www.itl.nist.gov/fipspubs/fip180-1.htm>.
[IEEE80211] [IEEE80211]
Institute of Electrical and Electronics Engineers, Institute of Electrical and Electronics Engineers,
"Information technology - Telecommunications and "Information technology - Telecommunications and information
information exchange between systems - Local and exchange between systems - Local and metropolitan area
metropolitan area networks - Specific Requirements Part networks - Specific Requirements Part 11: Wireless LAN Medium
11: Wireless LAN Medium Access Control (MAC) and Physical Access Control (MAC) and Physical Layer (PHY) Specifications",
Layer (PHY) Specifications", IEEE IEEE Standard IEEE IEEE Standard 802.11-1999, 1999.
802.11-1997, 1997.
[IEEE8021X] [IEEE8021X]
Institute of Electrical and Electronics Engineers, "Local Institute of Electrical and Electronics Engineers, "Local and
and Metropolitan Area Networks: Port-Based Network Access Metropolitan Area Networks: Port-Based Network Access
Control", IEEE Standard 802.1X-2001, June 2002. Control", IEEE Standard 802.1X-2004, September 2004.
[IEEE8021Q] [IEEE8021Q]
Institute of Electrical and Electronics Engineers, "IEEE Institute of Electrical and Electronics Engineers, "IEEE
Standards for Local and Metropolitan Area Networks: Draft Standards for Local and Metropolitan Area Networks: Draft
Standard for Virtual Bridged Local Area Networks", IEEE Standard for Virtual Bridged Local Area Networks", IEEE
Standard 802.1Q/D8, January 1998. Standard 802.1Q/D8, January 1998.
[IEEE80211f] [IEEE80211F]
Institute of Electrical and Electronics Engineers, Institute of Electrical and Electronics Engineers,
"Recommended Practice for Multi-Vendor Access Point "Recommended Practice for Multi-Vendor Access Point
Interoperability via an Inter-Access Point Protocol Across Interoperability via an Inter-Access Point Protocol Across
Distribution Systems Supporting IEEE 802.11 Operation", Distribution Systems Supporting IEEE 802.11 Operation", IEEE
IEEE 802.11F, July 2003. 802.11F, July 2003.
[IEEE80211i] [IEEE80211i]
Institute of Electrical and Electronics Engineers, "Draft Institute of Electrical and Electronics Engineers, "Draft
Supplement to STANDARD FOR Telecommunications and Supplement to STANDARD FOR Telecommunications and Information
Information Exchange between Systems - LAN/MAN Specific Exchange between Systems - LAN/MAN Specific Requirements -
Requirements - Part 11: Wireless Medium Access Control Part 11: Wireless Medium Access Control (MAC) and physical
(MAC) and physical layer (PHY) specifications: layer (PHY) specifications: Specification for Enhanced
Specification for Enhanced Security", IEEE Draft 802.11I/ Security", IEEE Draft 802.11I/ D8, February 2004.
D6.1, August 2003.
[IEEE-02-758] [IEEE-02-758]
Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang,
"Proactive Caching Strategies for IAPP Latency Improvement "Proactive Caching Strategies for IAPP Latency Improvement
during 802.11 Handoff", IEEE 802.11 Working Group, during 802.11 Handoff", IEEE 802.11 Working Group,
IEEE-02-758r1-F Draft 802.11I/D5.0, November 2002. IEEE-02-758r1-F Draft 802.11I/D5.0, November 2002.
[IEEE-03-084] [IEEE-03-084]
Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang,
"Proactive Key Distribution to support fast and secure "Proactive Key Distribution to support fast and secure
roaming", IEEE 802.11 Working Group, IEEE-03-084r1-I, roaming", IEEE 802.11 Working Group, IEEE-03-084r1-I,
http://www.ieee802.org/11/Documents/DocumentHolder/ http://www.ieee802.org/11/Documents/DocumentHolder/ 3-084.zip,
3-084.zip, January 2003. January 2003.
[IEEE-03-155] [IEEE-03-155]
Aboba, B., "Fast Handoff Issues", IEEE 802.11 Working Aboba, B., "Fast Handoff Issues", IEEE 802.11 Working Group,
Group, IEEE-03-155r0-I, http://www.ieee802.org/11/ IEEE-03-155r0-I, http://www.ieee802.org/11/
Documents/DocumentHolder/3-155.zip, March 2003. Documents/DocumentHolder/3-155.zip, March 2003.
[EAPAPI] Microsoft Developer Network, "Windows 2000 EAP API",
http://msdn.microsoft.com/library/default.asp?url=/
library/en-us/eap/eapport_0fj9.asp, August 2000.
[I-D.ietf-roamops-cert] [I-D.ietf-roamops-cert]
Aboba, B., "Certificate-Based Roaming", Aboba, B., "Certificate-Based Roaming", draft-ietf-roamops-
draft-ietf-roamops-cert-02 (work in progress), April 1999. cert-02 (work in progress), April 1999.
[I-D.ietf-aaa-eap] [I-D.ietf-aaa-eap]
Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application", Authentication Protocol (EAP) Application", draft-ietf-aaa-
draft-ietf-aaa-eap-02 (work in progress), July 2003. eap-08 (work in progress), June 2004.
[I-D.irtf-aaaarch-handoff] [I-D.irtf-aaaarch-handoff]
Arbaugh, W. and B. Aboba, "Experimental Handoff Extension Arbaugh, W. and B. Aboba, "Handoff Extension to RADIUS",
to RADIUS", draft-irtf-aaaarch-handoff-03 (work in draft-irtf-aaaarch-handoff-04 (work in progress), October
progress), October 2003. 2003.
[I-D.orman-public-key-lengths]
Orman, H. and P. Hoffman, "Determining Strengths For
Public Keys Used For Exchanging Symmetric Keys",
draft-orman-public-key-lengths-05 (work in progress),
January 2002.
[I-D.puthenkulam-eap-binding] [I-D.puthenkulam-eap-binding]
Puthenkulam, J., "The Compound Authentication Binding Puthenkulam, J., "The Compound Authentication Binding
Problem", draft-puthenkulam-eap-binding-03 (work in Problem", draft-puthenkulam-eap-binding-04 (work in progress),
progress), July 2003. October 2003.
[I-D.aboba-802-context] [I-D.aboba-802-context]
Aboba, B. and T. Moore, "A Model for Context Transfer in Aboba, B. and T. Moore, "A Model for Context Transfer in IEEE
IEEE 802", draft-aboba-802-context-03 (work in progress), 802", draft-aboba-802-context-03 (work in progress), October
October 2003. 2003.
[I-D.arkko-pppext-eap-aka] [I-D.arkko-pppext-eap-aka]
Arkko, J. and H. Haverinen, "EAP AKA Authentication", Arkko, J. and H. Haverinen, "EAP AKA Authentication", draft-
draft-arkko-pppext-eap-aka-10 (work in progress), June arkko-pppext-eap-aka-11 (work in progress), October 2003.
2003.
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", draft-
ietf-ipsec-ikev2-12 (work in progress), March 2004.
[8021XHandoff] [8021XHandoff]
Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff in a Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff in a
Public Wireless LAN Based on IEEE 802.1X Model", School of Public Wireless LAN Based on IEEE 802.1X Model", School of
Computer Science and Engineering, Seoul National Computer Science and Engineering, Seoul National University,
University, Seoul, Korea, 2002. Seoul, Korea, 2002.
[MD5Attack] [MD5Attack]
Dobbertin, H., "The Status of MD5 After a Recent Attack", Dobbertin, H., "The Status of MD5 After a Recent Attack",
CryptoBytes, Vol.2 No.2, 1996. CryptoBytes, Vol.2 No.2, 1996.
Authors' Addresses [WLANREQ] Stanley, D., Walker, J. and B. Aboba, "EAP Method Requirements
for Wireless LANs", draft-walker-ieee802-req-02.txt (work in
progress), July 2004.
[Housley56]
Housley, R., "Key Management in AAA", Presentation to the AAA
WG at IETF 56,
http://www.ietf.org/proceedings/03mar/slides/aaa-5/index.html,
March 2003.
Acknowledgments
Thanks to Arun Ayyagari, Ashwin Palekar, and Tim Moore of Microsoft,
Dorothy Stanley of Agere, Bob Moskowitz of TruSecure, and Russ
Housley of Vigil Security for useful feedback.
Author Addresses
Bernard Aboba Bernard Aboba
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
USA
Phone: +1 425 706 6605
Fax: +1 425 936 6605
EMail: bernarda@microsoft.com EMail: bernarda@microsoft.com
Phone: +1 425 706 6605
Fax: +1 425 936 7329
Dan Simon Dan Simon
Microsoft Research Microsoft Research
Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
USA
EMail: dansimon@microsoft.com
Phone: +1 425 706 6711 Phone: +1 425 706 6711
Fax: +1 425 936 7329 Fax: +1 425 936 7329
EMail: dansimon@microsoft.com
Jari Arkko Jari Arkko
Ericsson Ericsson
Jorvas 02420 Jorvas 02420
Finland Finland
Phone: Phone:
EMail: jari.arkko@ericsson.com EMail: jari.arkko@ericsson.com
Pasi Eronen
Nokia Research Center
P.O. Box 407
FIN-00045 Nokia Group
Finland
EMail: pasi.eronen@nokia.com
Henrik Levkowetz (editor) Henrik Levkowetz (editor)
ipUnplugged AB ipUnplugged AB
Arenavagen 27 Arenavagen 27
Stockholm S-121 28 Stockholm S-121 28
SWEDEN SWEDEN
Phone: +46 708 32 16 08 Phone: +46 708 32 16 08
EMail: henrik@levkowetz.com EMail: henrik@levkowetz.com
Appendix A. Ciphersuite Keying Requirements Appendix A - Ciphersuite Keying Requirements
To date, PPP and IEEE 802.11 ciphersuites are suitable for keying by To date, PPP and IEEE 802.11 ciphersuites are suitable for keying by
EAP. This Appendix describes the keying requirements of common PPP EAP. This Appendix describes the keying requirements of common PPP
and 802.11 ciphersuites. and 802.11 ciphersuites.
PPP ciphersuites include DESEbis [RFC2419], 3DES [RFC2420], and MPPE PPP ciphersuites include DESEbis [RFC2419], 3DES [RFC2420], and MPPE
[RFC3078]. The DES algorithm is described in [FIPSDES], and DES modes [RFC3078]. The DES algorithm is described in [FIPSDES], and DES
(such as CBC, used in [RFC2419] and DES-EDE3-CBC, used in [RFC2420]) modes (such as CBC, used in [RFC2419] and DES-EDE3-CBC, used in
are described in [DESMODES]. For PPP DESEbis, a single 56-bit [RFC2420]) are described in [DESMODES]. For PPP DESEbis, a single
encryption key is required, used in both directions. For PPP 3DES, a 56-bit encryption key is required, used in both directions. For PPP
168-bit encryption key is needed, used in both directions. As 3DES, a 168-bit encryption key is needed, used in both directions. As
described in [RFC2419] for DESEbis and [RFC2420] for 3DES, the IV, described in [RFC2419] for DESEbis and [RFC2420] for 3DES, the IV,
which is different in each direction, is "deduced from an explicit which is different in each direction, is "deduced from an explicit
64-bit nonce, which is exchanged in the clear during the ECP 64-bit nonce, which is exchanged in the clear during the [ECP]
negotiation phase [RFC1968]." There is therefore no need for the IV negotiation phase." There is therefore no need for the IV to be
to be provided by EAP. provided by EAP.
For MPPE, 40-bit, 56-bit or 128-bit encryption keys are required in For MPPE, 40-bit, 56-bit or 128-bit encryption keys are required in
each direction, as described in [RFC3078]. No initialization vector each direction, as described in [RFC3078]. No initialization vector
is required. is required.
While these PPP ciphersuites provide encryption, they do not provide While these PPP ciphersuites provide encryption, they do not provide
per-packet authentication or integrity protection, so an per-packet authentication or integrity protection, so an
authentication key is not required in either direction. authentication key is not required in either direction.
Within [IEEE80211], Transient Session Keys (TSKs) are required both Within [IEEE80211], Transient Session Keys (TSKs) are required both
skipping to change at page 47, line 34 skipping to change at page 63, line 5
protection as well as encryption [IEEE80211i]. These include TKIP, protection as well as encryption [IEEE80211i]. These include TKIP,
which requires a single 128-bit encryption key and a 128-bit which requires a single 128-bit encryption key and a 128-bit
authentication key (used in both directions); AES CCMP, which authentication key (used in both directions); AES CCMP, which
requires a single 128-bit key (used in both directions) in order to requires a single 128-bit key (used in both directions) in order to
authenticate and encrypt data; and WRAP, which requires a single authenticate and encrypt data; and WRAP, which requires a single
128-bit key (used in both directions). 128-bit key (used in both directions).
As with WEP, authentication and encryption keys are also required to As with WEP, authentication and encryption keys are also required to
wrap the multicast encryption (and possibly, authentication) keys. wrap the multicast encryption (and possibly, authentication) keys.
Appendix B. Transient EAP Key (TEK) Hierarchy Appendix B - Transient EAP Key (TEK) Hierarchy
Figure B-1 illustrates the TEK key hierarchy for EAP-TLS [RFC2716], Figure B-1 illustrates the TEK key hierarchy for EAP-TLS [RFC2716],
which is based on the TLS key hierarchy [RFC2246]. The TLS-negotiated which is based on the TLS key hierarchy described in [RFC2246]. The
ciphersuite is used to set up a protected channel for use in TLS-negotiated ciphersuite is used to set up a protected channel for
protecting the EAP conversation, keyed by the derived TEKs. The TEK use in protecting the EAP conversation, keyed by the derived TEKs.
derivation proceeds as follows: The TEK derivation proceeds as follows:
master_secret = TLS-PRF-48(pre_master_secret, "master secret", master_secret = TLS-PRF-48(pre_master_secret, "master secret",
client.random || server.random) client.random || server.random)
TEK = TLS-PRF-X(master_secret, "key expansion", TEK = TLS-PRF-X(master_secret, "key expansion",
server.random || client.random) server.random || client.random)
Where: Where:
TLS-PRF-X = TLS pseudo-random function defined in [RFC2246],
TLS-PRF-X = TLS pseudo-random function [RFC2246], computed to X computed to X octets.
octets.
master_secret = TLS term for the MK. master_secret = TLS term for the MK.
| | | | | |
| | pre_master_secret | | | pre_master_secret |
server| | | client server| | | client
Random| V | Random Random| V | Random
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | | | | | |
| | | | | | | |
+---->| master_secret |<------+ +---->| master_secret |<------+
| | (MK) | | | | (MK) | |
| | | | | | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | | | |
| | | | | |
| | | | | |
V V V V V V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
| Key Block | | Key Block |
| (TEKs) | | (TEKs) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | | | | | | |
| client | server | client | server | client | server | client | server | client | server | client | server
| MAC | MAC | write | write | IV | IV | MAC | MAC | write | write | IV | IV
| | | | | | | | | | | |
V V V V V V V V V V V V
Figure B-1 - TLS [RFC2246] Key Hierarchy Figure B-1 - TLS [RFC2246] Key Hierarchy
Appendix C. MSK and EMSK Hierarchy Appendix C - EAP Key Hierarchy
In EAP-TLS [RFC2716], the MSK is divided into two halves, In EAP-TLS [RFC2716], the MSK is divided into two halves,
corresponding to the "Peer to Authenticator Encryption Key" corresponding to the "Peer to Authenticator Encryption Key" (Enc-
(Enc-RECV-Key, 32 octets, also known as the PMK) and "Authenticator RECV-Key, 32 octets, also known as the PMK) and "Authenticator to
to Peer Encryption Key" (Enc-SEND-Key, 32 octets). In [RFC2548], the Peer Encryption Key" (Enc-SEND-Key, 32 octets). In [RFC2548], the
Enc-RECV-Key (the PMK) is transported in the MS-MPPE-Recv-Key Enc-RECV-Key (the PMK) is transported in the MS-MPPE-Recv-Key
attribute, and the Enc-SEND-Key is transported in the attribute, and the Enc-SEND-Key is transported in the MS-MPPE-Send-
MS-MPPE-Send-Key attribute. Key attribute.
The EMSK is also divided into two halves, corresponding to the "Peer The EMSK is also divided into two halves, corresponding to the "Peer
to Authenticator Authentication Key" (Auth-RECV-Key, 32 octets) and to Authenticator Authentication Key" (Auth-RECV-Key, 32 octets) and
"Authenticator to Peer Authentication Key" (Auth-SEND-Key, 32 "Authenticator to Peer Authentication Key" (Auth-SEND-Key, 32
octets). The IV is a 64 octet quantity that is a known value; octets octets). The IV is a 64 octet quantity that is a known value; octets
0-31 are known as the "Peer to Authenticator IV" or RECV-IV, and 0-31 are known as the "Peer to Authenticator IV" or RECV-IV, and
Octets 32-63 are known as the "Authenticator to Peer IV", or SEND-IV. Octets 32-63 are known as the "Authenticator to Peer IV", or SEND-IV.
In EAP-TLS, the MSK, EMSK and IV are derived from the MK via a In EAP-TLS, the MSK, EMSK and IV are derived from the MK via a one-
one-way function. This ensures that the MK cannot be derived from way function. This ensures that the MK cannot be derived from the
the MSK, EMSK or IV unless the one-way function (TLS PRF) is broken. MSK, EMSK or IV unless the one-way function (TLS PRF) is broken.
Since the MSK is derived from the MK, if the MK is compromised then Since the MSK is derived from the MK, if the MK is compromised then
the MSK is also compromised. the MSK is also compromised.
As described in [RFC2716], the formula for the derivation of the MSK, As described in [RFC2716], the formula for the derivation of the MSK,
EMSK and IV from the MK is as follows: EMSK and IV from the MK is as follows:
MSK = TLS-PRF-64(MK, "client EAP encryption", MSK = TLS-PRF-64(MK, "client EAP encryption",
client.random || server.random) client.random || server.random)
EMSK = second 64 octets of: EMSK = second 64 octets of:
TLS-PRF-128(MK, "client EAP encryption", TLS-PRF-128(MK, "client EAP encryption",
client.random || server.random) client.random || server.random)
IV = TLS-PRF-64("", "client EAP encryption", IV = TLS-PRF-64("", "client EAP encryption",
client.random || server.random) client.random || server.random)
AAA-Key(0,31) = Peer to Authenticator Encryption Key (Enc-RECV-Key) AAA-Key(0,31) = Peer to Authenticator Encryption Key (Enc-RECV-Key)
(MS-MPPE-Recv-Key in [RFC2548]). Also known as the (MS-MPPE-Recv-Key in [RFC2548]). Also known as the
PMK. PMK.
AAA-Key(32,63) = Authenticator to Peer Encryption Key (Enc-SEND-Key) AAA-Key(32,63) = Authenticator to Peer Encryption Key (Enc-SEND-Key)
(MS-MPPE-Send-Key in [RFC2548]) (MS-MPPE-Send-Key in [RFC2548])
EMSK(0,31) = Peer to Authenticator Authentication Key (Auth-RECV-Key)
EMSK(0,31) = Peer to Authenticator Authentication Key EMSK(32,63) = Authenticator to Peer Authentication Key (Auth-Send-Key)
(Auth-RECV-Key) IV(0,31) = Peer to Authenticator Initialization Vector (RECV-IV)
IV(32,63) = Authenticator to Peer Initialization vector (SEND-IV)
EMSK(32,63) = Authenticator to Peer Authentication Key
(Auth-Send-Key)
IV(0,31) = Peer to Authenticator Initialization Vector
(RECV-IV)
IV(32,63) = Authenticator to Peer Initialization vector
(SEND-IV)
Where: Where:
AAA-Key(W,Z) = Octets W through Z inclusive of the AAA-Key. AAA-Key(W,Z) = Octets W through Z includes of the AAA-Key.
IV(W,Z) = Octets W through Z inclusive of the IV. IV(W,Z) = Octets W through Z inclusive of the IV.
MSK(W,Z) = Octets W through Z inclusive of the MSK. MSK(W,Z) = Octets W through Z inclusive of the MSK.
EMSK(W,Z) = Octets W through Z inclusive of the EMSK. EMSK(W,Z) = Octets W through Z inclusive of the EMSK.
MK = TLS master_secret MK = TLS master_secret
TLS-PRF-X = TLS PRF function defined in [RFC2246] computed to X octets
TLS-PRF-X = TLS PRF function [RFC2246], computed to X octets
client.random = Nonce generated by the TLS client. client.random = Nonce generated by the TLS client.
server.random = Nonce generated by the TLS server. server.random = Nonce generated by the TLS server.
Figure C-1 describes the process by which the MSK,EMSK,IV and Figure C-1 describes the process by which the MSK,EMSK,IV and
ultimately the TSKs, are derived from the MK. Note that in ultimately the TSKs, are derived from the MK. Note that in [RFC2716],
[RFC2716], the MK is referred to as the "TLS Master Secret". the MK is referred to as the "TLS Master Secret".
---+ ---+
| ^ | ^
| TLS Master Secret (MK) | | TLS Master Secret (MK) |
| | | |
V | V |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | EAP | | EAP |
| Master Session Key (MSK) | Method | Master Session Key (MSK) | Method |
| Derivation | | | Derivation | |
| | V | | V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ EAP ---+
| | | ^ | | | API ^
| MSK | EMSK | IV EAP | MSK | EMSK | IV |
| | | API | | | |
V V V v V V V v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | | | | |
| | | | | |
| AAA server | | | backend authentication server | |
| | | | | |
| | V | | V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | ^ | | ^
| AAA-Key(0,31) | AAA-Key(32,63) | | AAA-Key(0,31) | AAA-Key(32,63) |
| (PMK) | Transported | (PMK) | Transported |
| | via AAA | | via AAA |
| | | | | |
V V V V V V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | ^ | | ^
| Ciphersuite-Specific Transient Session | Auth. | Ciphersuite-Specific Transient Session | Auth.|
| Key Derivation | | | Key Derivation | |
| | V | | V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
Figure C-1 - EAP TLS [RFC2716] Key hierarchy Figure C-1 - EAP TLS [RFC2716] Key hierarchy
Appendix D. Transient Session Key (TSK) Derivation Appendix D - Transient Session Key (TSK) Derivation
Within IEEE 802.11 RSN, the Pairwise Transient Key (PTK), a transient Within IEEE 802.11 RSN, the Pairwise Transient Key (PTK), a transient
session key used to protect unicast traffic, is derived from the PMK session key used to protect unicast traffic, is derived from the PMK
(octets 0-31 of the MSK), known in [RFC2716] as the Peer to (octets 0-31 of the MSK), known in [RFC2716] as the Peer to
Authenticator Encryption Key. In [IEEE80211i], the PTK is derived Authenticator Encryption Key. In [IEEE80211i], the PTK is derived
from the PMK via the following formula: from the PMK via the following formula:
PTK = EAPOL-PRF-X(PMK, "Pairwise key expansion", PTK = EAPOL-PRF-X(PMK, "Pairwise key expansion", Min(AA,SA) ||
Min(AA,SA) || Max(AA, SA) || Min(ANonce,SNonce) || Max(AA, SA) || Min(ANonce,SNonce) || Max(ANonce,SNonce))
Max(ANonce,SNonce))
Where: Where:
PMK = AAA-Key(0,31) PMK = AAA-Key(0,31)
SA = Station MAC address (Calling-Station-Id) SA = Station MAC address (Calling-Station-Id)
AA = Access Point MAC address (Called-Station-Id) AA = Access Point MAC address (Called-Station-Id)
ANonce = Access Point Nonce ANonce = Access Point Nonce
SNonce = Station Nonce SNonce = Station Nonce
EAPOL-PRF-X = Pseudo-Random Function based on HMAC-SHA1, generating
EAPOL-PRF-X = Pseudo-Random Function based on HMAC-SHA1, a PTK of size X octets.
generating a PTK of size X octets.
TKIP uses X = 64, while CCMP, WRAP, and WEP use X = 48. TKIP uses X = 64, while CCMP, WRAP, and WEP use X = 48.
The EAPOL-Key Confirmation Key (KCK) is used to provide data origin The EAPOL-Key Confirmation Key (KCK) is used to provide data origin
authenticity in the TSK derivation. It utilizes the first 128 bits authenticity in the TSK derivation. It utilizes the first 128 bits
(bits 0-127) of the PTK. The EAPOL-Key Encryption Key (KEK) provides (bits 0-127) of the PTK. The EAPOL-Key Encryption Key (KEK) provides
confidentiality in the TSK derivation. It utilizes bits 128-255 of confidentiality in the TSK derivation. It utilizes bits 128-255 of
the PTK. Bits 256-383 of the PTK are used by Temporal Key 1, and the PTK. Bits 256-383 of the PTK are used by Temporal Key 1, and Bits
Bits 384-511 are used by Temporal Key 2. Usage of TK1 and TK2 is 384-511 are used by Temporal Key 2. Usage of TK1 and TK2 is
ciphersuite specific. Details are available in [IEEE80211i]. ciphersuite specific. Details are available in [IEEE80211i].
Appendix E. AAA-Key Derivation Appendix E - AAA-Key Derivation
Where a AAA-Key is generated as the result of a successful EAP
authentication, the AAA-Key is set to MSK(0,63).
As discussed in [I-D.irtf-aaaarch-handoff], [IEEE-02-758], As discussed in [I-D.irtf-aaaarch-handoff], [IEEE-02-758],
[IEEE-03-084], and [8021XHandoff], keying material may be required [IEEE-03-084], and [8021XHandoff], keying material may be required
for use in fast handoff between IEEE 802.11 authenticators. Where the for use in fast handoff between authenticators. Where the backend
backend authentication server provides keying material to multiple authentication server provides keying material to multiple
authenticators in order to fascilitate fast handoff, it is highly authenticators in order to facilitate fast handoff, it is highly
desirable for the keying material used on different authenticators to desirable for the keying material used on different authenticators to
be cryptographically separate, so that if one authenticator is be cryptographically separate, so that if one authenticator is
compromised, it does not lead to the compromise of other compromised, it does not lead to the compromise of other
authenticators. Where keying material is provided by the backend authenticators. Where keying material is provided by the backend
authentication server, a key hierarchy derived from the EMSK, as authentication server, a key hierarchy derived from the EMSK, can be
suggested in [IEEE-03-155] can be used to provide cryptographically used to provide cryptographically separate keying material for use in
separate keying material for use in fast handoff: fast handoff:
AAA-Key-A = MSK(0,63) AAA-Key-A = MSK(0,63)
AAA-Key-B = PRF(EMSK(0,63),AAA-Key-A, AAA-Key-B = PRF(EMSK(0,63),"EAP AAA-Key derivation for
B-Called-Station-Id,Calling-Station-Id) multiple attachments", AAA-Key-A,B-Called-Station-Id,
Calling-Station-Id,length)
AAA-Key-E = PRF(EMSK(0,63),AAA-Key-A, AAA-Key-E = PRF(EMSK(0,63),"EAP AAA-Key derivation for
E-Called-Station-Id,Calling-Station-Id) multiple attachments",AAA-Key-A,E-Called-Station-Id,
Calling-Station-Id, length)
Where: Where:
Calling-Station-Id = STA MAC address Calling-Station-Id = STA MAC address
B-Called-Station-Id = AP B MAC address B-Called-Station-Id = AP B MAC address
E-Called-Station-Id = AP E MAC address E-Called-Station-Id = AP E MAC address
length = length of derived key material
Here AAA-Key-A is the AAA-Key derived during the initial EAP Here AAA-Key-A is the AAA-Key derived during the initial EAP
authentication between the peer and authenticator A. Based on this authentication between the peer and authenticator A. Based on this
initial EAP authentication, the EMSK is also derived, which can be initial EAP authentication, the EMSK is also derived, which can be
used to derive AAA-Keys for fast authentication between the EAP peer used to derive AAA-Keys for fast authentication between the EAP peer
and authenticators B and E. Since the EMSK is cryptographically and authenticators B and E. Since the EMSK is cryptographically
separate from the MSK, each of these AAA-Keys is cryptographically separate from the MSK, each of these AAA-Keys is cryptographically
separate from each other, and are guaranteed to be unique between the separate from each other, and are guaranteed to be unique between the
EAP peer (also known as the STA) and the authenticator (also known as EAP peer (also known as the STA) and the authenticator (also known as
the AP). the AP).
Appendix F. Open issues
(This section should be removed by the RFC editor before publication)
Open issues relating to this specification are tracked on the
following web site:
http://www.drizzle.com/~aboba/EAP/eapissues.html
The current working documents for this draft are available at this
web site:
http://www.levkowetz.com/pub/ietf/drafts/eap/keying/
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of standards-related documentation can be found in BCP-11. Copies of
skipping to change at page 54, line 29 skipping to change at page 68, line 29
be obtained from the IETF Secretariat. be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English. The limited permissions granted above are perpetual and
will not be revoked by the Internet Society or its successors or
assigns. 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
The limited permissions granted above are perpetual and will not be Open Issues
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an Open issues relating to this specification are tracked on the
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING following web site:
TASK FORCE DISCLAIMS 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.
Acknowledgment http://www.drizzle.com/~aboba/EAP/eapissues.html
Funding for the RFC Editor function is currently provided by the Expiration Date
Internet Society.
This memo is filed as <draft-ietf-eap-keying-02.txt>, and expires
December 22, 2004.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/