draft-ietf-eap-keying-10.txt   draft-ietf-eap-keying-11.txt 
EAP Working Group Bernard Aboba EAP Working Group Bernard Aboba
INTERNET-DRAFT Dan Simon INTERNET-DRAFT Dan Simon
Category: Standards Track Microsoft Category: Standards Track Microsoft
<draft-ietf-eap-keying-10.txt> J. Arkko <draft-ietf-eap-keying-11.txt> J. Arkko
5 March 2006 Ericsson 3 April 2006 Ericsson
P. Eronen P. Eronen
Nokia Nokia
H. Levkowetz, Ed. H. Levkowetz, Ed.
ipUnplugged ipUnplugged
Extensible Authentication Protocol (EAP) Key Management Framework Extensible Authentication Protocol (EAP) Key Management Framework
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 The list of current Internet-Drafts can be accessed at
http://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 August 22, 2006. This Internet-Draft will expire on October 10, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society 2006. Copyright (C) The Internet Society 2006.
Abstract Abstract
The Extensible Authentication Protocol (EAP), defined in [RFC3748], The Extensible Authentication Protocol (EAP), defined in [RFC3748],
enables extensible network access authentication. This document enables extensible network access authentication. This document
provides a framework for the transport and usage of keying material provides a framework for the transport and usage of keying material
generated by EAP authentication algorithms, known as "methods". It generated by EAP authentication algorithms, known as "methods". It
also specifies the EAP key hierarchy. also specifies the EAP key hierarchy.
Table of Contents Table of Contents
1. Introduction .......................................... 3 1. Introduction .......................................... 3
1.1 Requirements Language ........................... 3 1.1 Requirements Language ........................... 3
1.2 Terminology ..................................... 3 1.2 Terminology ..................................... 3
1.3 Overview ........................................ 5 1.3 Overview ........................................ 5
1.4 EAP Invariants .................................. 9 1.4 EAP Key Hierarchy ............................... 8
2. Lower Layer Operation ................................. 12 1.5 Security Goals .................................. 11
2.1 Overview ........................................ 12 1.6 EAP Invariants .................................. 12
2.2 Layering ........................................ 14 2. Lower Layer Operation ................................. 15
2.3 Transient Session Keys .......................... 16 2.1 Transient Session Keys .......................... 16
2.4 Authenticator Architecture ...................... 19 2.2 Authenticator Architecture ...................... 18
2.5 Key Scope ....................................... 22 3. Key Management ........................................ 22
3. Key Management ........................................ 24 3.1 Secure Association Protocol ..................... 22
3.1 Secure Association Protocol ..................... 24 3.2 Key Scope ....................................... 25
3.2 Parent-Child Relationships ...................... 27 3.3 Parent-Child Relationships ...................... 26
3.3 Local Key Lifetimes ............................. 27 3.4 Local Key Lifetimes ............................. 26
3.4 Exported and Calculated Key Lifetimes ........... 28 3.5 Exported and Calculated Key Lifetimes ........... 27
3.5 Key Cache Synchronization ....................... 29 3.6 Key Cache Synchronization ....................... 28
3.6 Key Strength .................................... 30 3.7 Key Strength .................................... 29
3.7 Key Wrap ........................................ 31 3.8 Key Wrap ........................................ 29
4. Handoff Vulnerabilities ............................... 31 4. Handoff Vulnerabilities ............................... 30
4.1 Authorization ................................... 32 4.1 Authorization ................................... 30
4.2 Correctness ..................................... 33 4.2 Correctness ..................................... 32
5. Security Considerations .............................. 36 5. Security Considerations .............................. 34
5.1 Security Terminology ............................ 36 5.1 Threat Model .................................... 35
5.2 Threat Model .................................... 36 5.2 Authenticator Compromise ........................ 36
5.3 Authenticator Compromise ........................ 37 5.3 Spoofing ........................................ 36
5.4 Spoofing ........................................ 38 5.4 Downgrade Attacks ............................... 37
5.5 Downgrade Attacks ............................... 39 5.5 Unauthorized Disclosure ......................... 38
5.6 Unauthorized Disclosure ......................... 39 5.6 Replay Protection ............................... 39
5.7 Replay Protection ............................... 41 5.7 Key Freshness ................................... 40
5.8 Key Freshness ................................... 42 5.8 Elevation of Privilege .......................... 41
5.9 Elevation of Privilege .......................... 43 5.9 Man-in-the-Middle Attacks ....................... 42
5.10 Man-in-the-Middle Attacks ....................... 44 5.10 Denial of Service Attacks ....................... 42
5.11 Denial of Service Attacks ....................... 44 5.11 Impersonation ................................... 43
5.12 Impersonation ................................... 45 5.12 Channel Binding ................................. 44
5.13 Channel Binding ................................. 46 6. IANA Considerations ................................... 45
6. IANA Considerations ................................... 47 7. References ............................................ 45
7. References ............................................ 47 7.1 Normative References ............................ 45
7.1 Normative References ............................ 47 7.2 Informative References .......................... 46
7.2 Informative References .......................... 47 Acknowledgments .............................................. 50
Acknowledgments .............................................. 52 Author's Addresses ........................................... 50
Author's Addresses ........................................... 53 Appendix A - Exported Parameters in Existing Methods ......... 52
Appendix A - Exported Parameters in Existing Methods ......... 54 Intellectual Property Statement .............................. 53
Intellectual Property Statement .............................. 55 Disclaimer of Validity ....................................... 54
Disclaimer of Validity ....................................... 56 Copyright Statement .......................................... 54
Copyright Statement .......................................... 56
1. Introduction 1. Introduction
The Extensible Authentication Protocol (EAP), defined in [RFC3748], The Extensible Authentication Protocol (EAP), defined in [RFC3748],
was designed to enable extensible authentication for network access was designed to enable extensible authentication for network access
in situations in which the IP protocol is not available. Originally in situations in which the IP protocol is not available. Originally
developed for use with PPP [RFC1661], it has subsequently also been developed for use with PPP [RFC1661], it has subsequently also been
applied to IEEE 802 wired networks [IEEE-802.1X]. applied to IEEE 802 wired networks [IEEE-802.1X], wireless networks
such as [IEEE-802.11i] and [IEEE-802.16e], and IKEv2 [RFC4306].
This document provides a framework for the transport and usage of This document provides a framework for the transport and usage of
keying material generated by EAP authentication algorithms, known as keying material generated by EAP authentication algorithms, known as
"methods". In EAP, keying material is generated by EAP methods. "methods". In EAP, keying material is generated by EAP methods.
Part of this keying material may be used by EAP methods themselves Part of this keying material may be used by EAP methods themselves
and part of this material may be exported. The exported keying and part of this material may be exported. The exported keying
material may be transported by AAA protocols or used by Secure material may be transported by AAA protocols and used by Secure
Association Protocols in the generation or transport of session keys Association Protocols in the generation or transport of session keys
which are used by lower layer ciphersuites. This document describes which are used by lower layer ciphersuites. This document describes
each of these elements and provides a system-level security analysis. each of these elements and provides a system-level security analysis.
It also specifies the EAP key hierarchy. It also specifies the EAP key hierarchy.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119]. document are to be interpreted as described in [RFC2119].
1.2. Terminology 1.2. Terminology
This document frequently uses the following terms: This document frequently uses the following terms:
AAA Authentication, Authorization and Accounting. AAA protocols with
EAP support include RADIUS [RFC3579] and Diameter [RFC4072]. In
this document, the terms "AAA server" and "backend authentication
server" are used interchangeably.
authenticator authenticator
The end of the link initiating EAP authentication. The term The end of the link initiating EAP authentication. The term
Authenticator is used in [IEEE-802.1X], and authenticator has the Authenticator is used in [IEEE-802.1X], and authenticator has the
same meaning in this document. same meaning in this document.
peer The end of the link that responds to the authenticator. In peer The end of the link that responds to the authenticator.
[IEEE-802.1X], this end is known as the Supplicant.
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 server authentication service to an authenticator. When used, this server
typically executes EAP methods for the authenticator. This typically executes EAP methods for the authenticator. This
terminology is also used in [IEEE-802.1X]. terminology is also used in [IEEE-802.1X].
AAA Authentication, Authorization and Accounting. AAA protocols with Channel Binding
EAP support include RADIUS [RFC3579] and Diameter [RFC4072]. In The communication within an EAP method of integrity-protected
this document, the terms "AAA server" and "backend authentication channel properties such as endpoint identifiers which can be
server" are used interchangeably. compared to values communicated via out of band mechanisms (such as
via a AAA or lower layer protocol).
EAP server EAP server
The entity that terminates the EAP authentication method with the The entity that terminates the EAP authentication method with the
peer. In the case where no backend authentication server is used, peer. In the case where no backend authentication server is used,
the EAP server is part of the authenticator. In the case where the the EAP server is part of the authenticator. In the case where the
authenticator operates in pass-through mode, the EAP server is authenticator operates in pass-through mode, the EAP server is
located on the backend authentication server. located on the backend authentication server.
security association
A set of policies and cryptographic state used to protect
information. Elements of a security association may include
cryptographic keys, negotiated ciphersuites and other parameters,
counters, sequence spaces, authorization attributes, etc.
Long Term Credential Long Term Credential
EAP methods frequently make use of long term secrets in order to EAP methods frequently make use of long term secrets in order to
enable authentication between the peer and server. In the case of enable authentication between the peer and server. In the case of
a method based on pre-shared key authentication, the long term a method based on pre-shared key authentication, the long term
credential is the pre-shared key. In the case of a public-key credential is the pre-shared key. In the case of a public-key
based method, the long term credential is the corresponding private based method, the long term credential is the corresponding private
key. key.
Master Session Key (MSK) Master Session Key (MSK)
Keying material that is derived between the EAP peer and server and Keying material that is derived between the EAP peer and server and
exported by the EAP method. The MSK is at least 64 octets in exported by the EAP method. The MSK is at least 64 octets in
length. length.
AAA-Key
The term AAA-Key is synonymous with MSK.
Extended Master Session Key (EMSK) Extended Master Session Key (EMSK)
Additional keying material derived between the peer and server that Additional keying material derived between the peer and server that
is exported by the EAP method. The EMSK is at least 64 octets in is exported by the EAP method. The EMSK is at least 64 octets in
length, and is never shared with a third party. length, and is never shared with a third party.
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 peer and initialization vector field, that is derived between the peer and
EAP server. Since the IV is a known value in methods such as EAP- EAP server. Since the IV is a known value in methods such as EAP-
TLS [RFC2716], it cannot be used by itself for computation of any TLS [RFC2716], it cannot be used by itself for computation of any
quantity that needs to remain secret. As a result, its use has quantity that needs to remain secret. As a result, its use has
been deprecated and EAP methods are not required to generate it. been deprecated and EAP methods are not required to generate it.
However, when it is generated it MUST be unpredictable. However, when it is generated it MUST be unpredictable.
Pairwise Master Key (PMK) Pairwise Master Key (PMK)
Lower layers use MSK in lower-layer dependent manner. For Lower layers use the MSK in lower-layer dependent manner. For
instance, in [IEEE-802.11i] Octets 0-31 of the MSK are known as the instance, in [IEEE-802.11i] Octets 0-31 of the MSK are known as the
Pairwise Master Key (PMK). In [IEEE-802.11i] the TKIP and AES CCMP Pairwise Master Key (PMK). In [IEEE-802.11i] the TKIP and AES CCMP
ciphersuites derive their Transient Session Keys (TSKs) solely from ciphersuites derive their Transient Session Keys (TSKs) solely from
the PMK, whereas the WEP ciphersuite as noted in [RFC3580], derives the PMK, whereas the WEP ciphersuite as noted in [RFC3580], derives
its TSKs from both halves of the MSK. In [802.16e], the MSK is its TSKs from both halves of the MSK. In [802.16e], the MSK is
truncated to 40 octets for PMK and 20 octets for PMK2. truncated to 20 octets for PMK and 20 octets for PMK2.
security association
A set of policies and cryptographic state used to protect
information. Elements of a security association may include
cryptographic keys, negotiated ciphersuites and other parameters,
counters, sequence spaces, authorization attributes, etc.
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. The TEKs are stored locally by the EAP method EAP conversation. The TEKs are stored locally by the EAP method
and are not exported. Note that the ciphersuite used to set up the and are not exported. 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 subsequently authentication is unrelated to the ciphersuite used to subsequently
protect data sent between the EAP peer and authenticator. protect data sent between the EAP peer and authenticator.
Transient Session Keys (TSKs) Transient Session Keys (TSKs)
Session keys used to protect data exchanged after EAP Session keys used to protect data exchanged after EAP
authentication has successfully completed, using the ciphersuite authentication has successfully completed, using the ciphersuite
negotiated between the EAP peer and authenticator. negotiated between the EAP peer and authenticator.
AAA-Key
The term AAA-Key is synonymous with MSK.
1.3. Overview 1.3. Overview
Where EAP key derivation is supported, the conversation typically
takes place in three phases:
Phase 0: Discovery
Phase 1: Authentication
1a: EAP authentication
1b: AAA Key Transport (optional)
Phase 2: Secure Association Protocol
2a: Unicast Secure Association
2b: Multicast Secure Association (optional)
Of these phases, Phase 0, 1b and Phase 2 are handled external to EAP.
Phases 0 and 2 are handled by the lower layer protocol and phase 1b
is typically handled by a AAA protocol.
In the discovery phase (phase 0), peers locate authenticators and
discover their capabilities. A peer may locate an authenticator
providing access to a particular network, or a peer may locate an
authenticator behind a bridge with which it desires to establish a
Secure Association. Discovery can occur manually or automatically,
depending on the lower layer over which EAP runs.
EAP peer Authenticator Auth. Server
-------- ------------- ------------
|<----------------------------->| |
| Discovery (phase 0) | |
|<----------------------------->|<----------------------------->|
| EAP auth (phase 1a) | AAA pass-through (optional) |
| | |
| |<----------------------------->|
| | AAA Key transport |
| | (optional; phase 1b) |
|<----------------------------->| |
| Unicast Secure association | |
| (phase 2a) | |
| | |
|<----------------------------->| |
| Multicast Secure association | |
| (optional; phase 2b) | |
| | |
Figure 1: Conversation Overview
The authentication phase (phase 1) may begin once the peer and
authenticator discover each other. This phase, if it occurs, always
includes EAP authentication (phase 1a). Where the chosen EAP method
supports key derivation, in phase 1a EAP keying material is derived
on both the peer and the EAP server.
An additional step (phase 1b) is required in deployments which
include a backend authentication server, in order to transport keying
material from the backend authentication server to the authenticator.
In order to obey the principle of Mode Independence (see Section
1.6.1), where a backend server is present, all keying material which
is required by the lower layer needs to be transported from the EAP
server to the authenticator. Since existing TSK derivation and
transport techniques depend solely on the MSK, in existing
implementations, this is the only keying material replicated in the
AAA key transport phase 1b.
Successful completion of EAP authentication and key derivation by a
peer and EAP server does not necessarily imply that the peer is
committed to joining the network associated with an EAP server.
Rather, this commitment is implied by the creation of a security
association between the EAP peer and authenticator, as part of the
Secure Association Protocol (phase 2). The Secure Association
Protocol exchange (phase 2) 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 between the parties is shown in
Figure 1.
1.3.1. Examples
Existing EAP lower layers implement phase 0, 2a and 2b in different
ways:
PPP PPP, defined in [RFC1661] does not support discovery, nor does it
include a Secure Association Protocol.
PPPOE
PPPOE, defined in [RFC2516], includes support for a Discovery stage
(phase 0). In this step, the EAP peer sends a PPPoE Active
Discovery Initiation (PADI) packet to the broadcast address,
indicating the service it is requesting. The Access Concentrator
replies with a PPPOE Active Discovery Offer (PADO) packet
containing its name, the service name and an indication of the
services offered by the concentrator. The discovery phase is not
secured. PPPOE, like PPP, does not include a Secure Association
Protocol.
IKEv2
IKEv2, defined in [RFC4306], handles the establishment of unicast
security associations (phase 2a), while the establishment of
multicast security associations (phase 2b) may be handled by a
group key management protocol such as GDOI [RFC3547], GSAKMP
[GSAKMP], MIKEY [RFC3830], or GKDP [GKDP]. Several mechanisms have
been proposed for discovery of IPsec security gateways. [RFC2230]
discusses the use of KX Resource Records (RRs) for IPsec gateway
discovery; while KX RRs are supported by many DNS server
implementations, they have not yet been widely deployed.
Alternatively, DNS SRV [RFC2782] can be used for this purpose.
Where DNS is used for gateway location, DNS security mechanisms
such as DNSSEC ([RFC2535], [RFC2931]), TSIG [RFC2845], and Simple
Secure Dynamic Update [RFC3007] are available.
IEEE 802.11i
IEEE 802.11, defined in [IEEE-802.11], handles discovery via the
Beacon and Probe Request/Response mechanisms. IEEE 802.11 access
points periodically announce their Service Set Identifiers (SSIDs)
as well as capabilities using Beacon frames. Stations can query
for access points by sending a Probe Request to the broadcast
address. Neither Beacon nor Probe Request/Response frames are
secured. The 4-way handshake defined in [IEEE-802.11i] enables the
derivation of unicast (phase 2a) and multicast/broadcast (phase 2b)
secure associations. Since the group key exchange transports a
group key from the access point to the station, two 4-way
handshakes may be required in order to support peer-to-peer
communications. A proof of the security of the IEEE 802.11i 4-way
handshake when used with EAP-TLS [RFC2716], is provided in [He].
IEEE 802.1X
IEEE 802.1X-2004, defined in [IEEE-802.1X] does not support
discovery (phase 0), nor does it provide for derivation of unicast
or multicast secure associations.
1.4. EAP Key Hierarchy
EAP, defined in [RFC3748], is a two-party protocol spoken between the EAP, defined in [RFC3748], is a two-party protocol spoken between the
EAP peer and server. Within EAP, keying material is generated by EAP EAP peer and server. Within EAP, keying material is generated by EAP
methods. Part of this keying material may be used by EAP methods methods. Part of this keying material may be used by EAP methods
themselves and part of this material may be exported. In addition to themselves and part of this material may be exported. In addition to
export of keying material, EAP methods may also export associated export of keying material, EAP methods may also export associated
parameters, and may import and export Channel Bindings from the lower parameters, and may import and export Channel Bindings from the lower
layer. layer.
As illustrated in Figure 1, the EAP method key derivation has at the As illustrated in Figure 2, the EAP method key derivation has at the
root the long term credential utilized by the selected EAP method. root the long term credential utilized by the selected EAP method.
If authentication is based on a pre-shared key, the parties store the 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 EAP method to be used and the pre-shared key. The EAP server also
stores the peer's identity as well as other information associated stores the peer's identity as well as other information associated
with it. This information may be used to determine whether access to with it. This information may be used to determine whether access to
some service should be granted. The peer stores information necessary some service should be granted. The peer stores information necessary
to choose which secret to use for which service. to choose which secret to use for which service.
If authentication is based on proof of possession of the private key If authentication is based on proof of possession of the private key
corresponding to the public key contained within a certificate, the corresponding to the public key contained within a certificate, the
skipping to change at page 6, line 19 skipping to change at page 9, line 5
[1] Keys calculated locally by the EAP method but not exported [1] Keys calculated locally by the EAP method but not exported
by the EAP method, such as the TEKs. by the EAP method, such as the TEKs.
[2] Keying material exported by the EAP method: MSK, EMSK, IV. [2] Keying material exported by the EAP method: MSK, EMSK, IV.
As noted in [RFC3748] Section 7.10, EAP methods generating keys are 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 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; least 64 octets in length. EAP methods also may export the IV;
however, the use of the IV is deprecated. however, the use of the IV is deprecated.
EAP methods also MAY export method-specific peer and server
identifiers (peer-ID and server-ID), a method-specific EAP
conversation identifier known as the Method-ID, and the lifetime of
the exported keys, known as the Key-Lifetime. EAP methods MAY also
support the import and export of Channel Bindings. New EAP method
specifications MUST define the Peer-ID, Server-ID and Method-ID. The
combination of the Peer-ID and Server-ID uniquely specifies the
endpoints of the EAP method exchange when they are provided.
Peer-ID
As described in [RFC3748] Section 7.3, the identity provided in the
EAP-Response/Identity, may be different from the peer identity
authenticated by the EAP method. Where the EAP method authenticates
the peer identity, that identity is exported by the method as the
Peer-ID. A suitable EAP peer name may not always be available.
Where an EAP method does not define a method-specific peer identity,
the Peer-ID is the null string. The Peer-ID for existing EAP
methods is defined in Appendix A.
Server-ID
Where the EAP method authenticates the server identity, that identity
is exported by the method as the Server-ID. A suitable EAP server
name may not always be available. Where an EAP method does not
define a method-specific peer identity, the Server-ID is the null
string. The Server-ID for existing EAP methods is defined in
Appendix A.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | ^ | | ^
| EAP Method | | | EAP Method | |
| | | | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | |
| | | | | | | | | | | | | |
| | EAP Method Key |<->| Long-Term | | | | | EAP Method Key |<->| Long-Term | | |
| | Derivation | | Credential | | | | | Derivation | | Credential | | |
| | | | | | | | | | | | | |
| | | +-+-+-+-+-+-+-+ | Local to | | | | +-+-+-+-+-+-+-+ | Local to |
| | | | EAP | | | | | EAP |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Method | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Method |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | |
| | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | | | | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | |
| | | TEK | |MSK, EMSK | |IV | | | | | | TEK | |MSK, EMSK | |IV | | |
| | |Derivation | |Derivation | |Derivation | | | | | |Derivation | |Derivation | |Derivation | | |
| | | | | | |(Deprecated) | | | | | | | | | |(Deprecated) | | |
| | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | | | | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | |
| | ^ | | | | | | ^ | | | |
| | | | | | V | | | | | | V
+-+-|-+-+-+-+-+-+-+-+-|-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+ ---+ +-+-|-+-+-+-+-+-+-+-+-|-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+ ---+
| | | | ^ | | | | ^
| Peer-ID, | | | Exported | | Peer-ID, | | | Exported |
| Server-ID, | Channel | MSK (64+B) | IV (64B) by | | Server-ID, | Channel | MSK (64+B) | IV (64B) by |
| Method-ID, | Bindings | EMSK (64+B) | (Optional) EAP | | Session-ID, | Bindings | EMSK (64+B) | (Optional) EAP |
| Key-Lifetime | & Result | | Method | | Key-Lifetime | & Result | | Method |
V V V V V V V V V V
Figure 1: EAP Method Parameter Import/Export Figure 2: EAP Method Parameter Import/Export
EAP methods also MAY export method-specific peer and server
identifiers (peer-ID and server-ID), a method-specific EAP
conversation identifier known as the Session-ID, and the lifetime of
the exported keys, known as the Key-Lifetime. EAP methods MAY also
support the import and export of Channel Bindings. New EAP method
specifications MUST define the Peer-ID, Server-ID and Method-ID. The
combination of the Peer-ID and Server-ID uniquely specifies the
endpoints of the EAP method exchange when they are provided. The
Peer-ID, Server-ID, and Method-ID for existing EAP methods is defined
in Appendix A.
Peer-ID
As described in [RFC3748] Section 7.3, the identity provided in the
EAP-Response/Identity, may be different from the peer identity
authenticated by the EAP method. Where the EAP method authenticates
the peer identity, that identity is exported by the method as the
Peer-ID. A suitable EAP peer name may not always be available.
Where an EAP method does not define a method-specific peer identity,
the Peer-ID is the null string.
Server-ID
Where the EAP method authenticates the server identity, that identity
is exported by the method as the Server-ID. A suitable EAP server
name may not always be available. Where an EAP method does not
define a method-specific peer identity, the Server-ID is the null
string.
Method-ID Method-ID
EAP method specifications deriving keys MUST specify a temporally EAP method specifications deriving keys MUST specify a temporally
unique method identifier known as the Method-ID. The EAP Method-ID unique method identifier known as the Method-ID. The EAP Method-ID
uniquely identifies an EAP session of a given Type between an EAP uniquely identifies an EAP session of a given Type between an EAP
peer and server. The Method-ID is typically constructed from nonces peer and server. The Method-ID is typically constructed from nonces
or counters used within the EAP method exchange. The Method-ID for or counters used within the EAP method exchange.
existing EAP methods is defined in Appendix A.
Session-ID Session-ID
The Session-ID uniquely identifies an EAP session between an EAP peer The Session-ID uniquely identifies an EAP session between an EAP peer
(as identified by the Peer-ID) and server (as identified by the (as identified by the Peer-ID) and server (as identified by the
Server-ID). The EAP Session-ID consists of the concatenation of the Server-ID). The EAP Session-ID consists of the concatenation of the
Expanded EAP Type Code (including the Type, Vendor-ID and Vendor-Type Expanded EAP Type Code (including the Type, Vendor-ID and Vendor-Type
fields defined in [RFC3748] Section 5.7) and the Method-ID. The fields defined in [RFC3748] Section 5.7) and the Method-ID. The
inclusion of the Expanded Type Code in the EAP Session-Id ensures inclusion of the Expanded Type Code in the EAP Session-ID ensures
that each EAP method has a distinct Session-ID space. Since an EAP that each EAP method has a distinct Session-ID space. Since an EAP
session is not bound to a particular authenticator or specific ports session is not bound to a particular authenticator or specific ports
on the peer and authenticator, the authenticator port or identity are on the peer and authenticator, the authenticator port or identity are
not included in the Session-Id. not included in the Session-ID.
Key-Lifetime Key-Lifetime
While EAP itself does not support key lifetime negotiation, it is While EAP itself does not support key lifetime negotiation, it is
possible to specify methods that do. However, systems that rely on possible to specify methods that do. However, systems that rely on
such negotiation for exported keys would only function with these such negotiation for exported keys would only function with these
methods. As a result, it is NOT RECOMMENDED to use this approach as methods. As a result, it is NOT RECOMMENDED to use this approach as
the sole way to determine key lifetimes. the sole way to determine key lifetimes.
Channel Bindings Channel Bindings
Channel Bindings include lower layer parameters that are verified for Channel Bindings include lower layer parameters that are verified for
consistency between the EAP peer and server. In order to avoid consistency between the EAP peer and server. In order to avoid
introducing media dependencies, EAP methods that transport Channel introducing media dependencies, EAP methods that transport Channel
Binding data MUST treat this data as opaque octets. Typically the Binding data MUST treat this data as opaque octets. Typically the
EAP method imports Channel Bindings from the lower layer on the peer, EAP method imports Channel Bindings from the lower layer on the peer,
and transmits them securely to the EAP server, which exports them to and transmits them securely to the EAP server, which exports them to
the lower layer. However, transport may occur from EAP server to the lower layer or AAA layer. However, transport may occur from EAP
peer, or may be bi-directional. On the side of the exchange (peer or server to peer, or may be bi-directional. On the side of the
server) where Channel Bindings are verified, the lower layer passes exchange (peer or server) where Channel Bindings are verified, the
the result of the verification (TRUE or FALSE) up to the EAP method. lower layer or AAA layer passes the result of the verification (TRUE
or FALSE) up to the EAP method. While the verification can be done
either by the peer or the server, typically only the server has the
knowledge to determine the correctness of the values, as opposed to
merely verifying their equality.
1.3.1. Key Naming 1.4.1. Key Naming
Each key created within the EAP key management framework has a name Each key created within the EAP key management framework has a name
(a unique identifier), as well as a scope (the parties to whom the (a unique identifier), as well as a scope (the parties to whom the
key is available). The scope of exported parameters is defined by key is available). The scope of exported parameters is defined by
the EAP peer name (if securely exchanged within the method) and the the EAP peer name (if securely exchanged within the method) and the
EAP server name (also only if securely exchanged). Where a peer or EAP server name (also only if securely exchanged). Where a peer or
server name is missing the null string is used. server name is missing the null string is used.
MSK and EMSK Names MSK and EMSK Names
These parameters are exported by the EAP peer and EAP server, and These parameters are exported by the EAP peer and EAP server, and
skipping to change at page 9, line 17 skipping to change at page 11, line 48
TEK Name TEK Name
The TEKs may or may not be named. Their naming is specified in the The TEKs may or may not be named. Their naming is specified in the
EAP method. EAP method.
TSK Name TSK Name
The TSKs are typically named. Their naming is specified in the The TSKs are typically named. Their naming is specified in the
lower layer so that the correct set of transient session keys can lower layer so that the correct set of transient session keys can
be identified for processing a given packet. be identified for processing a given packet.
1.4. EAP Invariants 1.5. Security Goals
The goal of the EAP conversation is to derive fresh session keys
between the EAP peer and authenticator that are known only to those
parties, and for both the EAP peer and authenticator to demonstrate
that they are authorized to perform their roles either by each other
or by a trusted third party (the backend authentication server).
Completion of an EAP method exchange (Phase 1a) supporting key
derivation results in the derivation of EAP keying material (MSK,
EMSK, TEKs) known only to the EAP peer (identified by the Peer-ID)
and server (identified by the Server-ID). Both the EAP peer and EAP
server know the exported keying material to be fresh. Key freshness
is discussed in Sections 3.4, 3.5 and 5.7.
Completion of the AAA exchange (Phase 1b) results in the transport of
EAP keying material from the EAP server (identified by the Server-ID)
to the EAP authenticator (identified by the NAS-Identifier) without
disclosure to any other party. Both the EAP server and EAP
authenticator know this keying material to be fresh. Disclosure
issues are discussed in Section 5.6; security properties of AAA
protocols are discussed in Sections 5.2-5.8, and 5.11.
Completion of the Secure Association Protocol (Phase 2) results in
the derivation or transport of Transient Session Keys (TSKs) known
only to the EAP peer (identified by the Peer-ID) and authenticator
(identified by the NAS-Identifier). Both the EAP peer and
authenticator know the TSKs to be fresh. Both the EAP peer and
authenticator demonstrate that they are authorized to perform their
roles. Authorization issues are discussed in Section 5.8 and 5.9;
security properties of Secure Association Protocols are discussed in
Section 3.1.
1.6. EAP Invariants
Certain basic characteristics, known as "EAP Invariants", hold true Certain basic characteristics, known as "EAP Invariants", hold true
for EAP implementations on all media: for EAP implementations on all media:
Mode independence Mode independence
Media independence Media independence
Method independence Method independence
Ciphersuite independence Ciphersuite independence
1.4.1. Mode Independence 1.6.1. Mode Independence
EAP is typically deployed in order to support extensible network EAP is typically deployed to support extensible network access
access authentication in situations where a peer desires network authentication in situations where a peer desires network access via
access via one or more authenticators. Where authenticators are one or more authenticators. Where authenticators are deployed
deployed standalone, the EAP conversation occurs between the peer and standalone, the EAP conversation occurs between the peer and
authenticator, and the authenticator must locally implement an EAP authenticator, and the authenticator must locally implement an EAP
method acceptable to the peer. However, one of the advantages of EAP method acceptable to the peer. However, when utilized in "pass-
is that it enables deployment of new authentication methods without through" mode, EAP enables deployment of new authentication methods
requiring development of new code on the authenticator. without requiring development of new code on the authenticator.
While the authenticator may implement some EAP methods locally and While the authenticator may implement some EAP methods locally and
use those methods to authenticate local users, it may at the same use those methods to authenticate local users, it may at the same
time act as a pass-through for other users and methods, forwarding time act as a pass-through for other users and methods, forwarding
EAP packets back and forth between the backend authentication server EAP packets back and forth between the backend authentication server
and the peer. This is accomplished by encapsulating EAP packets and the peer. This is accomplished by encapsulating EAP packets
within the Authentication, Authorization and Accounting (AAA) within the Authentication, Authorization and Accounting (AAA)
protocol, spoken between the authenticator and backend authentication protocol, spoken between the authenticator and backend authentication
server. AAA protocols supporting EAP include RADIUS [RFC3579] and server. AAA protocols supporting EAP include RADIUS [RFC3579] and
Diameter [RFC4072]. Diameter [RFC4072].
It is a fundamental property of EAP that at the EAP method layer, the It is a fundamental property of EAP that at the EAP method layer, the
conversation between the EAP peer and server is unaffected by whether conversation between the EAP peer and server is unaffected by whether
the EAP authenticator is operating in "pass-through" mode. EAP the EAP authenticator is operating in "pass-through" mode. EAP
methods operate identically in all aspects, including key derivation methods operate identically in all aspects, including key derivation
and parameter import/export, regardless of whether the authenticator and parameter import/export, regardless of whether the authenticator
is operating as a pass-through or not. is operating as a pass-through or not.
The successful completion of an EAP method that supports key The successful completion of an EAP method that supports key
derivation results in the export of keying material on the EAP peer derivation results in the export of keying material and parameters on
and server. Even though the EAP peer or server may import Channel- the EAP peer and server. Even though the EAP peer or server may
Bindings that may include the identity of the EAP authenticator, import Channel-Bindings that may include the identity of the EAP
this information is treated as opaque octets. As a result, within authenticator, this information is treated as opaque octets. As a
EAP the only relevant identities are the Peer-ID and Server-ID. result, within EAP the only relevant identities are the Peer-ID and
Channel Bindings are only interpreted by the lower layer. Server-ID. Channel Bindings are only interpreted by the lower layer.
Within EAP, the primary function of the AAA protocol is to maintain Within EAP, the primary function of the AAA protocol is to maintain
the principle of Mode Independence, so that as far as the EAP peer is the principle of Mode Independence, so that as far as the EAP peer is
concerned, its conversation with the EAP authenticator, and all concerned, its conversation with the EAP authenticator, and all
consequences of that conversation, are identical, regardless of the consequences of that conversation, are identical, regardless of the
authenticator mode of operation. authenticator mode of operation.
1.4.2. Media Independence 1.6.2. Media Independence
One of the goals of EAP is to allow EAP methods to function on any One of the goals of EAP is to allow EAP methods to function on any
lower layer meeting the criteria outlined in [RFC3748], Section 3.1. lower layer meeting the criteria outlined in [RFC3748], Section 3.1.
For example, as described in [RFC3748], EAP authentication can be run For example, as described in [RFC3748], EAP authentication can be run
over PPP [RFC1661], IEEE 802 wired networks [IEEE-802.1X], and IEEE over PPP [RFC1661], IEEE 802 wired networks [IEEE-802.1X], and
802.11 wireless LANs [IEEE-802.11i]. wireless networks such as 802.11 [IEEE-802.11i] and 802.16
[IEEE-802.16e].
In order to maintain media independence, it is necessary for EAP to In order to maintain media independence, it is necessary for EAP to
avoid consideration of media-specific elements. For example, EAP avoid consideration of media-specific elements. For example, EAP
methods cannot be assumed to have knowledge of the lower layer over methods cannot be assumed to have knowledge of the lower layer over
which they are transported, and cannot be restricted to identifiers which they are transported, and cannot be restricted to identifiers
associated with a particular usage environment (e.g. MAC addresses). associated with a particular usage environment (e.g. MAC addresses).
Note that media independence may be retained within EAP methods that Note that media independence may be retained within EAP methods that
support Channel-Bindings or method-specific identification. An EAP support Channel-Bindings or method-specific identification. An EAP
method need not be aware of the content of an identifier in order to method need not be aware of the content of an identifier in order to
use it. This enables an EAP method to use media-specific identifiers use it. This enables an EAP method to use media-specific identifiers
such as MAC addresses without compromising media independence. such as MAC addresses without compromising media independence.
Channel-Bindings are treated as opaque octets by EAP methods, so that Channel-Bindings are treated as opaque octets by EAP methods, so that
handling them does not require media-specific knowledge. handling them does not require media-specific knowledge.
1.4.3. Method Independence 1.6.3. Method Independence
By enabling pass-through, authenticators can support any method By enabling pass-through, authenticators can support any method
implemented on the peer and server, not just locally implemented implemented on the peer and server, not just locally implemented
methods. This allows the authenticator to avoid implementing code methods. This allows the authenticator to avoid implementing code
for each EAP method required by peers. In fact, since a pass-through 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 authenticator is not required to implement any EAP methods at all, it
cannot be assumed to support any EAP method-specific code. cannot be assumed to support any EAP method-specific code.
As a result, as noted in [RFC3748], authenticators must by default be As a result, as noted in [RFC3748], authenticators must by default be
capable of supporting any EAP method. This is useful where there is capable of supporting any EAP method. This is useful where there is
no single EAP method that is both mandatory-to-implement and offers no single EAP method that is both mandatory-to-implement and offers
acceptable security for the media in use. For example, the [RFC3748] acceptable security for the media in use. For example, the [RFC3748]
mandatory-to-implement EAP method (MD5-Challenge) does not provide mandatory-to-implement EAP method (MD5-Challenge) does not provide
dictionary attack resistance, mutual authentication or key dictionary attack resistance, mutual authentication or key
derivation, and as a result is not appropriate for use in wireless derivation, and as a result is not appropriate for use in wireless
LAN authentication [RFC4017]. However, despite this it is possible LAN authentication [RFC4017]. However, despite this it is possible
for the peer and authenticator to interoperate as long as a suitable for the peer and authenticator to interoperate as long as a suitable
EAP method is supported on the EAP server. EAP method is supported on the EAP server.
1.4.4. Ciphersuite Independence 1.6.4. Ciphersuite Independence
Ciphersuite Independence is a requirement for Media Independence. Ciphersuite Independence is a requirement for Media Independence.
Since lower layer ciphersuites vary between media, media independence Since lower layer ciphersuites vary between media, media independence
requires that EAP keying material needs to be large enough (with requires that EAP keying material needs to be large enough (with
sufficient entropy) to handle any ciphersuite. sufficient entropy) to handle any ciphersuite.
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 the the EAP conversation, the ciphersuite used for the protection of the
data exchanged after EAP authentication has completed is negotiated data exchanged after EAP authentication has completed is negotiated
between the peer and authenticator within the lower layer, outside of between the peer and authenticator within the lower layer, outside of
skipping to change at page 11, line 40 skipping to change at page 15, line 9
Encryption Control Protocol (ECP) defined in [RFC1968], after EAP Encryption Control Protocol (ECP) defined in [RFC1968], after EAP
authentication is completed. Within [IEEE-802.11i], the AP authentication is completed. Within [IEEE-802.11i], the AP
ciphersuites are advertised in the Beacon and Probe Responses prior ciphersuites are advertised in the Beacon and Probe Responses prior
to EAP authentication, and are securely verified during a 4-way to EAP authentication, and are securely verified during a 4-way
handshake exchange. handshake exchange.
Since the ciphersuites used to protect data depend on the lower Since the ciphersuites used to protect data depend on the lower
layer, requiring EAP methods have knowledge of lower layer layer, requiring EAP methods have knowledge of lower layer
ciphersuites would compromise the principle of Media Independence. ciphersuites would compromise the principle of Media Independence.
Since ciphersuite negotiation occurs in the lower layer, there is no Since ciphersuite negotiation occurs in the lower layer, there is no
need for ciphersuite negotiation within EAP, and EAP methods generate need for lower layer ciphersuite negotiation within EAP, and EAP
keying material that is ciphersuite-independent. methods generate keying material that is ciphersuite-independent.
Algorithms for deriving TSKs MUST NOT depend on the EAP method,
although algorithms for TEK derivation MAY be specific to the EAP
method.
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 TSKs framework, a specification MUST be provided describing how TSKs
suitable for use with the ciphersuite are derived from exported EAP suitable for use with the ciphersuite are derived from exported EAP
keying parameters. keying parameters. To maintain Method Independence, algorithms for
deriving TSKs MUST NOT depend on the EAP method, although algorithms
for TEK derivation MAY be specific to the EAP method.
Advantages of ciphersuite-independence include: Advantages of ciphersuite-independence include:
Reduced update requirements Reduced update requirements
If EAP methods were to specify how to derive transient session keys If EAP methods were to specify how to derive transient session keys
for each ciphersuite, they would need to be updated each time a new for each ciphersuite, they would need to be updated each time a new
ciphersuite is developed. In addition, backend authentication ciphersuite is developed. In addition, backend authentication
servers might not be usable with all EAP-capable authenticators, servers might not be usable with all EAP-capable authenticators,
since the backend authentication server would also need to be since the backend authentication server would also need to be
updated each time support for a new ciphersuite is added to the updated each time support for a new ciphersuite is added to the
skipping to change at page 12, line 34 skipping to change at page 15, line 50
As a result, the EAP server may not have knowledge of the As a result, the EAP server may not have knowledge of the
ciphersuites and negotiation policies implemented by the peer and ciphersuites and negotiation policies implemented by the peer and
authenticator, or be aware of the ciphersuite negotiated between authenticator, or be aware of the ciphersuite negotiated between
them. For example, since ECP negotiation occurs after them. For example, since ECP negotiation occurs after
authentication, when run over PPP, the EAP peer and server may not authentication, when run over PPP, the EAP peer and server may not
anticipate the negotiated ciphersuite and therefore this anticipate the negotiated ciphersuite and therefore this
information cannot be provided to the EAP method. information cannot be provided to the EAP method.
2. Lower Layer Operation 2. Lower Layer Operation
2.1. Overview On completion of EAP authentication, keying material and material and
parameters exported by the EAP method are provided to the lower layer
Where EAP key derivation is supported, the conversation typically and AAA layer (if present). These include the Master Session Key
takes place in three phases: (MSK), Extended Master Session Key (EMSK), Peer-ID, Server-ID,
Session-ID and Key-Lifetime. The Initialization Vector (IV) is
Phase 0: Discovery
Phase 1: Authentication
1a: EAP authentication
1b: AAA Key Transport (optional)
Phase 2: Secure Association Establishment
2a: Unicast Secure Association
2b: Multicast Secure Association (optional)
Of these phases, Phase 0, 1b and Phase 2 are handled external to EAP.
Phases 0 and 2 are handled by the lower layer protocol and phase 1b
is typically handled by a AAA protocol. In the discovery phase
(phase 0), peers locate authenticators and discover their
capabilities. A peer may locate an authenticator providing access to
a particular network, or a peer may locate an authenticator behind a
bridge with which it desires to establish a Secure Association.
Discovery can occur manually or automatically, depending on the lower
layer over which EAP runs.
The authentication phase (phase 1) may begin once the peer and
authenticator discover each other. This phase, if it occurs, always
includes EAP authentication (phase 1a). Where the chosen EAP method
supports key derivation, in phase 1a EAP keying material is derived
on both the peer and the EAP server.
An additional step (phase 1b) is required in deployments which
include a backend authentication server, in order to transport keying
material from the backend authentication server to the authenticator.
In order to obey the principle of Mode Independence, where a backend
server is present, all keying material which is required by the lower
layer needs to be transported from the EAP server to the
authenticator. Since existing TSK derivation techniques depend
solely on the MSK, in existing implementations, this is the only
keying material replicated in the AAA key transport phase 1b.
Successful completion of EAP authentication and key derivation by a
peer and EAP server does not necessarily imply that the peer is
committed to joining the network associated with an EAP server.
Rather, this commitment is implied by the creation of a security
association between the EAP peer and authenticator, as part of the
Secure Association Protocol (phase 2).
The Secure Association exchange (phase 2) 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 between the parties is
shown in Figure 2.
Existing EAP lower layers implement phase 0, 2a and 2b in different
ways:
PPP PPP, defined in [RFC1661] does not support discovery, nor does it
include a Secure Association Protocol.
PPPOE
PPPOE, defined in [RFC2516], includes support for a Discovery stage
(phase 0). In this step, the EAP peer sends a PPPoE Active
Discovery Initiation (PADI) packet to the broadcast address,
indicating the service it is requesting. The Access Concentrator
replies with a PPPOE Active Discovery Offer (PADO) packet
containing its name, the service name and an indication of the
services offered by the concentrator. The discovery phase is not
secured. PPPOE, like PPP, does not include a Secure Association
Protocol.
IKEv2
IKEv2, defined in [RFC4306], handles the derivation of unicast
security associations (phase 2a), while the derivation of multicast
security associations (phase 2b) is handled in a separate group key
management protocol, as described in [RFC4046]. Several mechanisms
have been proposed for discovery of IPsec security gateways.
[RFC2230] discusses the use of KX Resource Records (RRs) for IPsec
gateway discovery; while KX RRs are supported by many DNS server
implementations, they have not yet been widely deployed.
Alternatively, DNS SRV [RFC2782] can be used for this purpose.
Where DNS is used for gateway location, DNS security mechanisms
such as DNSSEC ([RFC2535], [RFC2931]), TSIG [RFC2845], and Simple
Secure Dynamic Update [RFC3007] are available.
IEEE 802.11i
IEEE 802.11, defined in [IEEE-802.11], handles discovery via the
Beacon and Probe Request/Response mechanisms. IEEE 802.11 access
points periodically announce their Service Set Identifiers (SSIDs)
as well as capabilities using Beacon frames. Stations can query
for access points by sending a Probe Request to the broadcast
address. Neither Beacon nor Probe Request/Response frames are
secured. The 4-way handshake defined in [IEEE-802.11i] enables the
derivation of unicast (phase 2a) and multicast/broadcast (phase 2b)
secure associations. Since the group key exchange transports a
group key from the access point to the station, two 4-way
handshakes may be required in order to support peer-to-peer
communications.
IEEE 802.1X-2004
IEEE 802.1X-2004, defined in [IEEE-802.1X-2004] does not support
discovery (phase 0), nor does it provide for derivation of unicast
or multicast secure associations.
2.2. Layering
As illustrated in Figure 3, on completion of EAP authentication, EAP
methods export the Master Session Key (MSK), Extended Master Session
Key (EMSK), Peer-ID, Server-ID, Session-ID and Key-Lifetime to the
EAP peer or authenticator layers. The Initialization Vector (IV) is
deprecated. deprecated.
The EAP peer and authenticator layers MUST NOT modify or cache keying
material or parameters (including Channel Bindings) passing in either
direction between the EAP method layer and the EAP layer. The EAP
layer also MUST NOT cache keying material or parameters (including
Channel Bindings) passed to it, whether by the EAP peer/authenticator
layer, the lower layer or the AAA layer.
EAP peer Authenticator Auth. Server
-------- ------------- ------------
|<----------------------------->| |
| Discovery (phase 0) | |
|<----------------------------->|<----------------------------->|
| EAP auth (phase 1a) | AAA pass-through (optional) |
| | |
| |<----------------------------->|
| | AAA Key transport |
| | (optional; phase 1b) |
|<----------------------------->| |
| Unicast Secure association | |
| (phase 2a) | |
| | |
|<----------------------------->| |
| Multicast Secure association | |
| (optional; phase 2b) | |
| | |
Figure 2: Conversation Overview
Based on the Method-ID exported by the EAP method, the EAP layer
forms the EAP Session-ID by concatenating the EAP Expanded Type with
the Method-ID. Together with the MSK, IV (deprecated), Peer-ID,
Server-ID, and Key-Lifetime, the EAP layer passes the Session-ID down
to the lower layer. The Method-ID is exported by EAP methods rather
than the Session-ID so as to prevent EAP methods from writing into
each other's Session- ID space.
The EMSK MUST NOT be provided to an entity outside the EAP server or
peer, nor is it permitted to pass any quantity to an entity outside
the EAP server or peer from which the EMSK could be computed without
breaking some cryptographic assumption, such as inverting a one-way
function. As noted in [RFC3748] Section 7.10:
The EMSK is reserved for future use and MUST remain on the EAP
peer and EAP server where it is derived; it MUST NOT be
transported to, or shared with, additional parties, or used to
derive any other keys. (This restriction will be relaxed in a
future document that specifies how the EMSK can be used.)
In order to preserve the security of keys derived within EAP methods, In order to preserve the security of keys derived within EAP methods,
lower layers MUST NOT export keys passed down by EAP methods. This lower layers MUST NOT export keys passed down by EAP methods. This
implies that EAP keying material or parameters passed down to a lower implies that EAP keying material or parameters passed down to a lower
layer are for the exclusive use of that lower layer and MUST NOT be layer are for the exclusive use of that lower layer and MUST NOT be
used within another lower layer. This prevents compromise of one used within another lower layer. This prevents compromise of one
lower layer from compromising other applications using EAP keying lower layer from compromising other applications using EAP keying
parameters. parameters.
EAP keying material and parameters provided to a lower layer MUST NOT EAP keying material and parameters provided to a lower layer MUST NOT
be transported to another entity. For example, EAP keying material be transported to another entity. For example, EAP keying material
and parameters passed down to the EAP peer lower layer MUST NOT leave and parameters passed down to the EAP peer lower layer MUST NOT leave
the peer; EAP keying material and parameters passed down or the peer; EAP keying material and parameters passed down or
transported to the EAP authenticator lower layer MUST NOT leave the transported to the EAP authenticator lower layer MUST NOT leave the
authenticator. authenticator.
On the EAP server, keying material requested by and passed down to On the EAP server, keying material requested by and passed down to
the AAA layer may be replicated to the AAA layer on the the AAA layer may be replicated to the AAA layer on the
authenticator. On the authenticator, the AAA layer may provide the authenticator. On the authenticator, the AAA layer provides the
replicated keying material to the lower layer over which the EAP replicated keying material to the lower layer over which the EAP
authentication conversation took place. This enables "mode authentication conversation took place. This enables "mode
independence" to be maintained. However, the EMSK MUST NOT be independence" to be maintained.
transported by the AAA layer.
As illustrated in Figure 4, a AAA client receiving transported EAP The EMSK MUST NOT be provided to an entity outside the EAP server or
keying material and parameters passes them to the EAP authenticator peer, nor is it permitted to pass any quantity to an entity outside
and EAP layers, which then provide them to the authenticator lower the EAP server or peer from which the EMSK could be computed without
layer using the same mechanisms that would be used if the EAP peer breaking some cryptographic assumption, such as inverting a one-way
and authenticator were conducting a stand-alone conversation. The function. The EMSK MUST NOT be transported by the AAA layer. As
resulting key state in the lower layer is indistinguishable between noted in [RFC3748] Section 7.10:
the standalone and pass-through cases, as required by the principle
of mode independence.
2.3. Transient Session Keys The EMSK is reserved for future use and MUST remain on the EAP
peer and EAP server where it is derived; it MUST NOT be
transported to, or shared with, additional parties, or used to
derive any other keys.
The EAP layer as well as the peer and authenticator layers MUST NOT
modify or cache keying material or parameters (including Channel
Bindings) passing in either direction between the EAP method layer
and the lower layer or AAA layer.
2.1. Transient Session Keys
Where explicitly supported by the lower layer, lower layers MAY cache Where explicitly supported by the lower layer, lower layers MAY cache
the exported EAP keying material and parameters and/or TSKs. The the exported EAP keying material and parameters and/or TSKs. The
structure of this key cache is defined by the lower layer. So as to structure of this key cache is defined by the lower layer. So as to
enable interoperability, new lower layer specifications MUST enable interoperability, new lower layer specifications MUST describe
describe EAP key caching behavior. Unless explicitly specified by EAP key caching behavior. Unless explicitly specified by the lower
the lower layer, the EAP peer, server and authenticator MUST assume layer, the EAP peer, server and authenticator MUST assume that peers
that peers and authenticators do not cache exported EAP keying and authenticators do not cache exported EAP keying parameters or
parameters or TSKs. Existing EAP lower layers and AAA layers handle TSKs. Existing EAP lower layers and AAA layers handle the caching of
the caching of EAP keying material and the generation of transient EAP keying material and the generation of transient session keys in
session keys in different ways: different ways:
IEEE 802.1X-2004 IEEE 802.1X-2004
IEEE 802.1X-2004, defined in [IEEE-802.1X-2004] does not support IEEE 802.1X-2004, defined in [IEEE-802.1X] does not support caching
caching of EAP keying material or parameters. Once EAP of EAP keying material or parameters. Once EAP authentication
authentication completes, it is assumed that EAP keying material completes, it is assumed that EAP keying material and parameters
and parameters are discarded. are discarded.
PPP PPP, defined in [RFC1661] does not support caching of EAP keying PPP PPP, defined in [RFC1661] does not support caching of EAP keying
material or parameters. PPP ciphersuites derive their TSKs material or parameters. PPP ciphersuites derive their TSKs
directly from the MSK, as described in [RFC2716]. This method is directly from the MSK, as described in [RFC2716]. This method is
NOT RECOMMENDED, since were PPP to support caching, this could NOT RECOMMENDED, since were PPP to support caching, this could
result in stale TSKs. As a result, once the PPP session is result in stale TSKs. As a result, once the PPP session is
terminated, EAP keying material and parameters MUST be discarded. terminated, EAP keying material and parameters MUST be discarded.
Since caching of EAP keying material is not permitted, within PPP Since caching of EAP keying material is not permitted, within PPP
there is no way to handle TSK rekey without EAP re-authentication. there is no way to handle TSK rekey without EAP re-authentication.
Perfect Forward Secrecy (PFS) is only possible within PPP if the Perfect Forward Secrecy (PFS) is only possible within PPP if the
negotiated EAP method supports this. negotiated EAP method supports this.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| EAP method |
| |
| MSK, EMSK, Peer-ID, Channel |
| Server-ID, Method-ID Bindings |
| IV (deprecated), |
| Key-Lifetime |
| |
| V ^ ^ |
+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+
| ! ! ! |
| EAP ! Peer or Authenticator ! ! |
| ! layer ! ! |
| ! ! ! |
+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+
| ! ! ! |
| EAP ! layer ! ! |
| ! ! ! |
| ! Session-ID = ! ! |
| ! Expanded-Type || ! ! |
| ! Method-ID ! ! |
| ! ! ! |
+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+
| ! ! ! |
| Lower ! layer or AAA ! ! |
| ! ! ! |
| V V ^ |
| MSK, Peer-ID, Channel Result |
| Server-ID, Bindings |
| Session-ID, |
| Key-Lifetime, |
| IV (deprecated) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Flow of EAP parameters
Peer Pass-through Authenticator Authentication
Server
+-+-+-+-+-+-+ +-+-+-+-+-+-+
| | | |
|EAP method | |EAP method |
| V | | V |
+-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+
| ! | |EAP | EAP | | | ! |
| ! | |Peer | Auth.| EAP Auth. | | ! |
|EAP ! peer| | | +-----------+ | |EAP !Auth.|
| ! | | | ! | ! | | ! |
+-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+
| ! | | ! | ! | | ! |
|EAP !layer| | EAP !layer| EAP !layer | |EAP !layer|
| ! | | ! | ! | | ! |
+-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+
| V | | V | ! | | ! |
|Lower layer| | Lower layer| AAA ! /IP | | AAA ! /IP |
| | | | ! | | ! |
+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+
! !
! !
+---------<-------+
Figure 4: Flow of EAP Keying Material and Parameters
IKEv2 IKEv2
IKEv2, defined in [RFC4306] only uses the MSK for authentication IKEv2, defined in [RFC4306] only uses the MSK for authentication
purposes and not key derivation. The EMSK, IV, Peer-ID, Server-ID purposes and not key derivation. The EMSK, IV, Peer-ID, Server-ID
or Session-ID are not used. As a result, the keying material or Session-ID are not used. As a result, the keying material
derived within IKEv2 is independent of the EAP keying material and derived within IKEv2 is independent of the EAP keying material and
rekey of IPsec SAs can be handled without requiring EAP re- rekey of IPsec SAs can be handled without requiring EAP re-
authentication. Since generation of keying material is independent authentication. Since generation of keying material is independent
of EAP, within IKEv2 it is possible to negotiate PFS, regardless of of EAP, within IKEv2 it is possible to negotiate PFS, regardless of
the EAP method that is used. IKEv2 does not cache EAP keying the EAP method that is used. IKEv2 does not cache EAP keying
material or parameters; once IKEv2 authentication completes it is material or parameters; once IKEv2 authentication completes it is
skipping to change at page 19, line 30 skipping to change at page 18, line 28
implementations, exported EAP keying material (MSK, EMSK and IV) as implementations, exported EAP keying material (MSK, EMSK and IV) as
well as parameters and derived keys are not cached and MUST be well as parameters and derived keys are not cached and MUST be
presumed lost after the AAA exchange completes. presumed lost after the AAA exchange completes.
In order to avoid key reuse, the AAA layer MUST delete transported In order to avoid key reuse, the AAA layer MUST delete transported
keys once they are sent. The AAA layer MUST NOT retain keys that keys once they are sent. The AAA layer MUST NOT retain keys that
it has previously sent. For example, a AAA layer that has it has previously sent. For example, a AAA layer that has
transported the MSK MUST delete it, and keys MUST NOT be derived transported the MSK MUST delete it, and keys MUST NOT be derived
from the MSK from that point forward. from the MSK from that point forward.
2.4. Authenticator Architecture 2.2. Authenticator Architecture
This specification does not impose constraints on the architecture of This specification does not impose constraints on the architecture of
the EAP authenticator or peer. Any of the authenticator the EAP authenticator or peer. Any of the authenticator
architectures described in [RFC4118] can be used. For example, it is architectures described in [RFC4118] can be used. For example, it is
possible for multiple base stations and a "controller" (e.g. WLAN possible for multiple base stations and a "controller" (e.g. WLAN
switch) to comprise a single EAP authenticator. In such a situation, switch) to comprise a single EAP authenticator. In such a situation,
the "base station identity" is irrelevant to the EAP method the "base station identity" is irrelevant to the EAP method
conversation, except perhaps as an opaque blob to be used in Channel conversation, except perhaps as an opaque blob to be used in Channel
Bindings. Many base stations can share the same authenticator Bindings. Many base stations can share the same authenticator
identity. As a result, lower layers need to identify EAP peers and identity. As a result, lower layers need to identify EAP peers and
skipping to change at page 20, line 13 skipping to change at page 19, line 10
[d] may support clustering services for load balancing or failover. [d] may support clustering services for load balancing or failover.
Both the EAP peer and authenticator may have more than one physical Both the EAP peer and authenticator may have more than one physical
or logical port. A peer may simultaneously access the network via or logical port. A peer may simultaneously access the network via
multiple authenticators, or via multiple physical or logical ports on multiple authenticators, or via multiple physical or logical ports on
a given authenticator. Similarly, an authenticator may offer network a given authenticator. Similarly, an authenticator may offer network
access to multiple peers, each via a separate physical or logical access to multiple peers, each via a separate physical or logical
port. When a single physical authenticator advertises itself as port. When a single physical authenticator advertises itself as
multiple "virtual authenticators", it is possible for a single multiple "virtual authenticators", it is possible for a single
physical port to belong to multiple "virtual authenticators". The physical port to belong to multiple "virtual authenticators". The
situation is illustrated in Figure 5. situation is illustrated in Figure 3.
+-+-+-+-+ +-+-+-+-+
| EAP | | EAP |
| Peer | | Peer |
+-+-+-+-+ +-+-+-+-+
| | | Peer Ports | | | Peer Ports
/ | \ / | \
/ | \ / | \
/ | \ / | \
/ | \ / | \
skipping to change at page 20, line 47 skipping to change at page 19, line 44
EAP over AAA \ | / EAP over AAA \ | /
(optional) \ | / (optional) \ | /
\ | / \ | /
\ | / \ | /
\ | / \ | /
+-+-+-+-+ +-+-+-+-+
| EAP | | EAP |
|Server | |Server |
+-+-+-+-+ +-+-+-+-+
Figure 5: Relationship between EAP peer, authenticator and server Figure 3: Relationship between EAP peer, authenticator and server
2.4.1. Authenticator Identification 2.2.1. Authenticator Identification
The EAP method conversation is between the EAP peer and server, as The EAP method conversation is between the EAP peer and server, as
identified by the Peer-ID and Server-ID. The authenticator identity, identified by the Peer-ID and Server-ID. The authenticator identity,
if considered at all by the EAP method, is treated as an opaque blob if considered at all by the EAP method, is treated as an opaque blob
for the purposes of Channel bindings. However, the Secure for the purposes of Channel bindings. However, the Secure
Association Protocol conversation is between the peer and the Association Protocol conversation is between the peer and the
authenticator, and therefore the authenticator and peer identities authenticator, and therefore the authenticator and peer identities
are relevant to that exchange, and define the scope of use of the EAP are relevant to that exchange, and define the scope of use of the EAP
keying material passed down to the lower layer. keying material passed down to the lower layer.
Since an authenticator may have multiple ports, the authenticator Where the EAP peer and authenticator cannot unambiguously identify
identifiers used within the Secure Association Protocol exchange each other they may not be able to determine the scope of transported
SHOULD be distinct from any port identifier (e.g. MAC address). EAP keying material. This is particularly problematic for lower
Similarly, where a peer may have multiple ports, and sharing of EAP layers where key caching is supported.
keying material and parameters between peer ports of the same link
type is allowed, the peer identifier used within the Secure
Association Protocol exchange SHOULD also be distinct from any port
identifier.
Where the peer and authenticator identify themselves within the lower For example, if the EAP peer cannot identify the EAP authenticator,
layer using a port identifier such as a link layer address, this it will be unable to determine whether transported EAP keying
creates a number of problems: material has been shared outside of its authorized scope, and
therefore needs to be considered compromised. There is also a
practical problem because the EAP peer will be unable to utilize the
EAP authenticator key cache in an efficient way. Where the peer and
authenticator identify themselves within the lower layer using a port
identifier such as a link layer address, this creates a number of
problems:
[1] It may not be obvious to the peer which authenticator ports are [1] It may not be obvious to the peer which authenticator ports are
associated with which authenticators. associated with which authenticators.
[2] It may not be obvious to the authenticator which peer ports are [2] It may not be obvious to the authenticator which peer ports are
associated with which peers. associated with which peers.
[3] It may not be obvious to the peer which "virtual authenticator" it [3] It may not be obvious to the peer which "virtual authenticator" it
is communicating with. is communicating with.
[4] It may not be obvious to the authenticator which "virtual peer" it [4] It may not be obvious to the authenticator which "virtual peer" it
is communicating with. is communicating with.
Since an authenticator may have multiple ports, the authenticator
identifier used within the Secure Association Protocol exchange
SHOULD be distinct from any port identifier (e.g. MAC address).
Similarly, where a peer may have multiple ports, and sharing of EAP
keying material and parameters between peer ports of the same link
type is allowed, the peer identifier used within the Secure
Association Protocol exchange SHOULD also be distinct from any port
identifier.
AAA protocols such as RADIUS [RFC3579] and Diameter [RFC4072] AAA protocols such as RADIUS [RFC3579] and Diameter [RFC4072]
provide a mechanism for the identification of AAA clients; since provide a mechanism for the identification of AAA clients; since
the EAP authenticator and AAA client are always co-resident, this the EAP authenticator and AAA client are always co-resident, this
mechanism is applicable to the identification of EAP mechanism is applicable to the identification of EAP
authenticators. authenticators.
RADIUS [RFC2865] requires that an Access-Request packet contain one RADIUS [RFC2865] requires that an Access-Request packet contain one
or more of the NAS-Identifier, NAS-IP-Address and NAS-IPv6-Address or more of the NAS-Identifier, NAS-IP-Address and NAS-IPv6-Address
attributes. Since a NAS may have more than one IP address, the attributes. Since a NAS may have more than one IP address, the
NAS-Identifier attribute is RECOMMENDED for the unambiguous NAS-Identifier attribute is RECOMMENDED for the unambiguous
identification of the EAP authenticator. identification of the EAP authenticator.
From the point of view of the AAA server, EAP keying material and From the point of view of the AAA server, EAP keying material and
parameters are transported to the EAP authenticator identified by parameters are transported to the EAP authenticator identified by
the NAS-Identifier attribute. Since an EAP authenticator MUST NOT the NAS-Identifier attribute. Since an EAP authenticator MUST NOT
share EAP keying material or parameters with another party, if the share EAP keying material or parameters with another party, if the
EAP peer or AAA server detects use of EAP keying material and EAP peer or AAA server detects use of EAP keying material and
parameters outside the scope defined by the NAS-Identifier, the parameters outside the scope defined by the NAS-Identifier, the
keying material MUST be considered compromised. keying material MUST be considered compromised.
2.5. Key Scope In order to ensure that lower layer identifies are securely
verified by all parties, it is recommended that lower layers:
Where the EAP peer and authenticator cannot unambiguously identify
each other they may not be able to determine the scope of transported
EAP keying material. This is particularly problematic for lower
layers where key caching is supported.
For example, if the EAP peer cannot identify the EAP authenticator,
it will be unable to determine whether transported EAP keying
material has been shared outside of its authorized scope, and
therefore needs to be considered compromised. There is also a
practical problem because the EAP peer will be unable to utilize the
EAP authenticator key cache in an efficient way.
To avoid these problems, it is recomended that lower layers:
[1] Specify the lower layer parameters used to identify the [a] Specify the lower layer parameters used to identify the
authenticator and peer; authenticator and peer;
[2] Communicate the lower layer identities between the peer and [b] Communicate the lower layer identities between the peer and
authenticator within phase 0; authenticator within phase 0;
[3] Communicate the lower layer authenticator identity between the [c] Communicate the lower layer authenticator identity between the
authenticator and backend server within the NAS-Identifier authenticator and backend server within the NAS-Identifier
attribute; attribute;
[4] Include the lower layer identities within channel bindings (if [d] Include the lower layer identities within channel bindings (if
supported) in phase 1a, ensuring that they are communicated between supported) in phase 1a, ensuring that they are communicated between
the EAP peer and server; the EAP peer and server;
[5] Securely verify the lower layer identities within phase 2a; [e] Securely verify the lower layer identities within phase 2a;
[6] Utilize the advertised lower layer identities to enable the peer [f] Utilize the advertised lower layer identities to enable the peer
and authenticator to verify that keys are maintained within the and authenticator to verify that keys are maintained within the
advertised scope; advertised scope;
Absent explicit specification within the lower layer, after the 2.2.2. Virtual Authenticators
completion of phase 1b, EAP keying material and parameters are
bound to the EAP peer and authenticator, but are not bound to a
specific peer or authenticator port.
While EAP Keying Material passed down to the lower layer is not
intrinsically bound to particular authenticator and peer ports,
Transient Session Keys MAY be bound to particular authenticator and
peer ports by the Secure Association Protocol. However, a lower
layer MAY also permit TSKs to be used on multiple peer and/or
authenticator ports, providing that TSK freshness is guaranteed
(such as by keeping replay counter state within the authenticator).
In order to further limit the key scope the following measures are
suggested:
[a] The lower layer MAY specify additional restrictions on key usage,
such as limiting the use of EAP keying material and parameters on
the EAP peer to the port over which on the EAP conversation was
conducted.
[b] The backend authentication server and authenticator MAY implement
additional attributes in order to further restrict the scope of EAP
keying material. For example, in 802.11, the backend
authentication server may provide the authenticator with a list of
authorized Called or Calling-Station-Ids and/or SSIDs for which EAP
keying material is valid.
[c] Where the backend authentication server provides attributes
restricting the key scope, it is RECOMMENDED that restrictions be
securely communicated by the authenticator to the peer. This can
be accomplished using the Secure Association Protocol, but also
can be accomplished via the EAP method or the lower layer.
2.5.1. Virtual Authenticators
When a single physical authenticator advertises itself as multiple When a single physical authenticator advertises itself as multiple
"virtual authenticators", the EAP peer and authenticator may not be "virtual authenticators", the EAP peer and authenticator may not be
able to agree on the scope of the EAP keying material, creating a able to agree on the scope of the EAP keying material, creating a
security vulnerability. For example, the peer may assume that the security vulnerability. For example, the peer may assume that the
"virtual authenticators" are distinct and do not share a key cache, "virtual authenticators" are distinct and do not share a key cache,
whereas, depending on the architecture of the physical authenticator, whereas, depending on the architecture of the physical authenticator,
a shared key cache may or may not be implemented. a shared key cache may or may not be implemented.
Where EAP keying material is shared between "virtual authenticators" Where EAP keying material is shared between "virtual authenticators"
an attacker acting as a peer could authenticate with the "Guest" an attacker acting as a peer could authenticate with the "Guest"
"virtual authenticator" and derive EAP keying material. If the "virtual authenticator" and derive EAP keying material. If the
virtual authenticators share a key cache, then the peer can utilize virtual authenticators share a key cache, then the peer can utilize
the EAP keying material derived for the "Guest" network to obtain the EAP keying material derived for the "Guest" network to obtain
access to the "Corporate Intranet" virtual authenticator. access to the "Corporate Intranet" virtual authenticator.
Several measures are recommended to address these issues: Several measures are recommended to address these issues:
[d] Authenticators are REQUIRED to cache associated authorizations [g] Authenticators are REQUIRED to cache associated authorizations
along with EAP keying material and parameters and to apply along with EAP keying material and parameters and to apply
authorizations consistently. This ensures that an attacker cannot authorizations consistently. This ensures that an attacker cannot
obtain elevated privileges even where the key cache is shared obtain elevated privileges even where the key cache is shared
between "virtual authenticators". between "virtual authenticators".
[e] It is RECOMMENDED that physical authenticators maintain separate [h] It is RECOMMENDED that physical authenticators maintain separate
key caches for each "virtual authenticator". key caches for each "virtual authenticator".
[f] It is RECOMMENDED that each "virtual authenticator" identify itself [i] It is RECOMMENDED that each "virtual authenticator" identify itself
distinctly to the backend authentication server, such as by distinctly to the backend authentication server, such as by
utilizing a distinct NAS-Identifier attribute. This enables the utilizing a distinct NAS-Identifier attribute. This enables the
backend authentication server to utilize a separate credential to backend authentication server to utilize a separate credential to
authenticate each "virtual authenticator". authenticate each "virtual authenticator".
3. Key Management 3. Key Management
EAP as defined in [RFC3748] supports key derivation, but not key EAP as defined in [RFC3748] supports key derivation, but not key
management. While EAP methods may derive keying material, EAP does management. While EAP methods may derive keying material, EAP does
not provide for the management of exported or derived keys. For not provide for the management of exported or derived keys. Although
example, EAP does not support negotiation of the key lifetime of EAP methods may support "fast reconnect" as defined in [RFC3748]
exported or derived keys, nor does it support re-key. Although EAP Section 7.2.1, EAP does not support re-key of exported keys without
methods may support "fast reconnect" as defined in [RFC3748] Section re-authentication. Existing EAP methods do not export the Key-
7.2.1, re-key of exported keys cannot occur without re- Lifetime parameter; in the interest of method independence, key
authentication. In order to provide method independence, key
management of exported or derived keys SHOULD NOT be provided within management of exported or derived keys SHOULD NOT be provided within
EAP methods. EAP methods.
3.1. Secure Association Protocol 3.1. Secure Association Protocol
Since neither EAP nor EAP methods provide key management support, it Since neither EAP nor EAP methods provide key management support, it
is RECOMMENDED that key management facilities be provided within the is RECOMMENDED that key management facilities be provided within the
Secure Association Protocol. This includes: Secure Association Protocol. This includes:
[a] Entity Naming. A basic feature of a Secure Association Protocol is [a] Entity Naming. A basic feature of a Secure Association Protocol is
the explicit naming of the parties engaged in the exchange. the explicit naming of the parties engaged in the exchange.
Without explicit identification, the parties engaged in the Without explicit identification, the parties engaged in the
exchange are not identified and the scope of the EAP keying exchange are not identified and the scope of the EAP keying
parameters negotiated during the EAP exchange is undefined. As parameters negotiated during the EAP exchange is undefined. As
shown in Figure 5, both the peer and authenticator may have more shown in Figure 3, both the peer and authenticator may have more
than one physical or virtual port, and as a result SHOULD identify than one physical or virtual port, and as a result SHOULD identify
themselves in a manner that is independent of their attached ports. themselves in a manner that is independent of their attached ports.
[b] Mutual proof of possession of EAP keying material. During the [b] Mutual proof of possession of EAP keying material. During the
Secure Association Protocol the EAP peer and authenticator MUST Secure Association Protocol the EAP peer and authenticator MUST
demonstrate possession of the keying material transported between demonstrate possession of the keying material transported between
the backend authentication server and authenticator (e.g. MSK), in the backend authentication server and authenticator (e.g. MSK), in
order to demonstrate that the peer and authenticator have been order to demonstrate that the peer and authenticator have been
authorized. Since mutual proof of possession is not the same as authorized. Since mutual proof of possession is not the same as
mutual authentication, the peer cannot verify authenticator mutual authentication, the peer cannot verify authenticator
skipping to change at page 26, line 12 skipping to change at page 24, line 17
the derivation of fresh unicast and multicast TSKs, even when the the derivation of fresh unicast and multicast TSKs, even when the
keying material provided by the backend authentication server is keying material provided by the backend authentication server is
not fresh. This is typically supported via the exchange of nonces not fresh. This is typically supported via the exchange of nonces
or counters, which are then mixed with the exported keying material or counters, which are then mixed with the exported keying material
in order to generate fresh unicast (phase 2a) and possibly in order to generate fresh unicast (phase 2a) and possibly
multicast (phase 2b) session keys. By not using EAP keying multicast (phase 2b) session keys. By not using EAP keying
material directly to protect data, the Secure Association Protocol material directly to protect data, the Secure Association Protocol
protects it against compromise. protects it against compromise.
[f] Key lifetime management. This includes explicit key lifetime [f] Key lifetime management. This includes explicit key lifetime
negotiation or seamless re-key. EAP does not support negotiation negotiation or seamless re-key. EAP does not support re-key
of key lifetimes, nor does it support re-key without re- without re-authentication and existing EAP methods do not support
authentication. As a result, the Secure Association Protocol may key lifetime negotiation. As a result, the Secure Association
handle re-key and determination of the key lifetime. Where key Protocol may handle re-key and determination of the key lifetime.
caching is supported, secure negotiation of key lifetimes is Where key caching is supported, secure negotiation of key lifetimes
RECOMMENDED. Lower layers that support re-key, but not key is RECOMMENDED. Lower layers that support re-key, but not key
caching, may not require key lifetime negotiation. To take an caching, may not require key lifetime negotiation. For example, a
example from IKE, the difference between IKEv1 and IKEv2 is that in difference between IKEv1 [RFC2409] and IKEv2 [RFC4306] is that in
IKEv1 SA lifetimes were negotiated. In IKEv2, each end of the SA is IKEv1 SA lifetimes were negotiated; in IKEv2, each end of the SA is
responsible for enforcing its own lifetime policy on the SA and re- responsible for enforcing its own lifetime policy on the SA and re-
keying the SA when necessary. keying the SA when necessary.
[g] Key resynchronization. It is possible for the peer or [g] Key resynchronization. It is possible for the peer or
authenticator to reboot or reclaim resources, clearing portions or authenticator to reboot or reclaim resources, clearing portions or
all of the key cache. Therefore, key lifetime negotiation cannot all of the key cache. Therefore, key lifetime negotiation cannot
guarantee that the key cache will remain synchronized, and the peer guarantee that the key cache will remain synchronized, and the peer
may not be able to determine before attempting to use a key whether may not be able to determine before attempting to use a key whether
it exists within the authenticator cache. It is therefore it exists within the authenticator cache. It is therefore
RECOMMENDED for the Secure Association Protocol to provide a RECOMMENDED for the Secure Association Protocol to provide a
mechanism for key state resynchronization. Since in this situation mechanism for key state resynchronization. Since in this situation
one or more of the parties initially do not possess a key with one or more of the parties initially do not possess a key with
which to protect the resynchronization exchange, securing this which to protect the resynchronization exchange, securing this
mechanism may be difficult. mechanism may be difficult.
[h] Key scope synchronization. Since the Discovery phase is handled [h] Key scope synchronization. To support key scope determination, the
out-of-band, EAP does not provide a mechanism by which the peer can Secure Association Protocol SHOULD provide a mechanism by which the
determine the authenticator identity. As a result, where the peer can determine the scope of the key cache on each
authenticator has multiple ports and key caching is supported, the authenticator, and by which the authenticator can determine the
EAP peer may not be able to determine the scope of validity of the scope of the key cache on a peer. This includes negotiation of
exported EAP keying material. Similarly, where the EAP peer has restrictions on key usage.
multiple ports, the authenticator may not be able to determine
whether a peer has authorization to use a particular key. To allow
key scope determination, the Secure Association Protocol SHOULD
provide a mechanism by which the peer can determine the scope of
the key cache on each authenticator, and by which the authenticator
can determine the scope of the key cache on a peer. This includes
negotiation of restrictions on key usage.
[i] Direct operation. Since the phase 2 Secure Association Protocol is [i] Direct operation. Since the phase 2 Secure Association Protocol is
concerned with the establishment of security associations between concerned with the establishment of security associations between
the EAP peer and authenticator, including the derivation of the EAP peer and authenticator, including the derivation of
transient session keys, only those parties have "a need to know" transient session keys, only those parties have "a need to know"
the transient session keys. The Secure Association Protocol MUST the transient session keys. The Secure Association Protocol MUST
operate directly between the peer and authenticator, and MUST NOT operate directly between the peer and authenticator, and MUST NOT
be passed-through to the backend authentication server, or include be passed-through to the backend authentication server, or include
additional parties. additional parties.
[j] Bi-directional operation While some ciphersuites only require a [j] Bi-directional operation. While some ciphersuites only require a
single set of transient session keys to protect traffic in both single set of transient session keys to protect traffic in both
directions, other ciphersuites require a unique set of transient directions, other ciphersuites require a unique set of transient
session keys in each direction. The phase 2 Secure Association session keys in each direction. The phase 2 Secure Association
Protocol SHOULD provide for the derivation of unicast and multicast Protocol SHOULD provide for the derivation of unicast and multicast
keys in each direction, so as not to require two separate phase 2 keys in each direction, so as not to require two separate phase 2
exchanges in order to create a bi-directional phase 2 security exchanges in order to create a bi-directional phase 2 security
association. association.
3.2. Parent-Child Relationships 3.2. Key Scope
Absent explicit specification within the lower layer, after the
completion of phase 1b, EAP keying material and parameters are bound
to the EAP peer and authenticator, but are not bound to a specific
peer or authenticator port.
While EAP Keying Material passed down to the lower layer is not
intrinsically bound to particular authenticator and peer ports,
Transient Session Keys MAY be bound to particular authenticator and
peer ports by the Secure Association Protocol. However, a lower
layer MAY also permit TSKs to be used on multiple peer and/or
authenticator ports, providing that TSK freshness is guaranteed (such
as by keeping replay counter state within the authenticator).
In order to further limit the key scope the following measures are
suggested:
[a] The lower layer MAY specify additional restrictions on key usage,
such as limiting the use of EAP keying material and parameters on
the EAP peer to the port over which on the EAP conversation was
conducted.
[b] The backend authentication server and authenticator MAY implement
additional attributes in order to further restrict the scope of EAP
keying material. For example, in 802.11, the backend
authentication server may provide the authenticator with a list of
authorized Called or Calling-Station-Ids and/or SSIDs for which EAP
keying material is valid.
[c] Where the backend authentication server provides attributes
restricting the key scope, it is RECOMMENDED that restrictions be
securely communicated by the authenticator to the peer. This can
be accomplished using the Secure Association Protocol, but also
can be accomplished via the EAP method or the lower layer.
3.3. Parent-Child Relationships
When keying material exported by EAP methods expires, all keying When keying material exported by EAP methods expires, all keying
material derived from the exported keying material expires, including material derived from the exported keying material expires, including
the TSKs. the TSKs.
When an EAP re-authentication takes place, new keying material is When an EAP re-authentication takes place, new keying material is
derived and exported by the EAP method, which eventually results in derived and exported by the EAP method, which eventually results in
replacement of calculated keys, including the TSKs. replacement of calculated keys, including the TSKs.
As a result, while the lifetime of calculated keys can be less than As a result, while the lifetime of calculated keys can be less than
skipping to change at page 27, line 43 skipping to change at page 26, line 28
key will also occur. However, this does not prohibit TSK re-key from key will also occur. However, this does not prohibit TSK re-key from
occurring prior to expiration of the lifetime of exported keys. For occurring prior to expiration of the lifetime of exported keys. For
example, TSK re-key may occur prior to EAP re-authentication. example, TSK re-key may occur prior to EAP re-authentication.
Failure to mutually prove possession of keying material during the Failure to mutually prove possession of keying material during the
Secure Association Protocol exchange need not be grounds for deletion Secure Association Protocol exchange need not be grounds for deletion
of the keying material by both parties; rate-limiting Secure of the keying material by both parties; rate-limiting Secure
Association Protocol exchanges could be used to prevent a brute force Association Protocol exchanges could be used to prevent a brute force
attack. attack.
3.3. Local Key Lifetimes 3.4. Local Key Lifetimes
The Transient EAP Keys (TEKs) are session keys used to protect the The Transient EAP Keys (TEKs) are session keys used to protect the
EAP conversation. The TEKs are internal to the EAP method and are EAP conversation. The TEKs are internal to the EAP method and are
not exported. TEKs are typically created during an EAP conversation, not exported. TEKs are typically created during an EAP conversation,
used until the end of the conversation and then discarded. However, used until the end of the conversation and then discarded. However,
methods may re-key TEKs during a conversation. methods may re-key TEKs during a conversation.
When using TEKs within an EAP conversation or across conversations, When using TEKs within an EAP conversation or across conversations,
it is necessary to ensure that replay protection and key separation it is necessary to ensure that replay protection and key separation
requirements are fulfilled. For instance, if a replay counter is requirements are fulfilled. For instance, if a replay counter is
skipping to change at page 28, line 24 skipping to change at page 27, line 8
derive and cache the TLS Master Secret, typically for substantial derive and cache the TLS Master Secret, typically for substantial
time periods. The lifetime of other local keying material calculated time periods. The lifetime of other local keying material calculated
within the EAP method is defined by the method. Note that in within the EAP method is defined by the method. Note that in
general, when using fast reconnect, there is no guarantee to that the general, when using fast reconnect, there is no guarantee to that the
original long-term credentials are still in the possession of the original long-term credentials are still in the possession of the
peer. For instance, a card hold holding the private key for EAP-TLS peer. For instance, a card hold holding the private key for EAP-TLS
may have been removed. EAP servers SHOULD also verify that the long- may have been removed. EAP servers SHOULD also verify that the long-
term credentials are still valid, such as by checking that term credentials are still valid, such as by checking that
certificate used in the original authentication has not yet expired. certificate used in the original authentication has not yet expired.
3.4. Exported and Calculated Key Lifetimes 3.5. Exported and Calculated Key Lifetimes
All EAP methods generating keys are required to generate the MSK and All EAP methods generating keys are required to generate the MSK and
EMSK, and may optionally generate the IV. However, EAP, defined in EMSK, and may optionally generate the IV. However, EAP, defined in
[RFC3748], does not support the negotiation of lifetimes for exported [RFC3748], does not itself support the negotiation of lifetimes for
keying material such as the MSK, EMSK and IV. exported keying material such as the MSK, EMSK and IV.
Several mechanisms exist for managing key lifetimes: Several mechanisms exist for managing key lifetimes:
[a] AAA attributes. AAA protocols such as RADIUS [RFC2865] and [a] AAA attributes. AAA protocols such as RADIUS [RFC2865] and
Diameter [RFC4072] support the Session-Timeout attribute. The Diameter [RFC4072] support the Session-Timeout attribute. The
Session-Timeout value represents the maximum lifetime of the Session-Timeout value represents the maximum lifetime of the
exported keys, and all keys calculated from it, on the exported keys, and all keys calculated from it, on the
authenticator. Since existing backend authentication servers do authenticator. Since existing backend authentication servers do
not cache keys exported by EAP methods, or keys calculated from not cache keys exported by EAP methods, or keys calculated from
exported keys, the value of the Session-Timeout attribute has no exported keys, the value of the Session-Timeout attribute has no
bearing on the key lifetime within the backend authentication bearing on the key lifetime within the backend authentication
server. server.
On the authenticator, where EAP is used for authentication, the On the authenticator, where EAP is used for authentication, the
Session-Timeout value represents the maximum session time prior to Session-Timeout value represents the maximum session time prior to
re-authentication, as described in [RFC3580]. Where EAP is used re-authentication, as described in [RFC3580]. Where EAP is used
for pre-authentication, the session may not start until some future for pre-authentication, the session may not start until some future
time, or may never occur. Nevertheless, the Session-Timeout value time, or may never occur. Nevertheless, the Session-Timeout value
represents the time after which transported EAP keying material, represents the maximum time after which transported EAP keying
and all keys calculated from it, will have expired on the material, and all keys calculated from it, will have expired on the
authenticator. If the session subsequently starts, re- authenticator. If the session subsequently starts, re-
authentication will be initiated once the Session-Time has expired. authentication will be initiated once the Session-Time has expired.
If the session never started, or started and ended, by default keys If the session never started, or started and ended, by default keys
transported by AAA and all keys calculated from them will be transported by AAA and all keys calculated from them will be
expired by the authenticator prior to the future time indicated by expired by the authenticator prior to the future time indicated by
Session-Timeout. Session-Timeout. Note that in future additional attributes may be
specified to control the lifetime of cached keys; these attributes
may modify the meaning of the Session-Timeout attribute in specific
circumstances.
Since the TSK lifetime is often determined by authenticator Since the TSK lifetime is often determined by authenticator
resources, the backend authentication server has no insight into resources, the backend authentication server has no insight into
the TSK derivation process, and by the principle of ciphersuite the TSK derivation process, and by the principle of ciphersuite
independence, it is not appropriate for the backend authentication independence, it is not appropriate for the backend authentication
server to manage any aspect of the TSK derivation process, server to manage any aspect of the TSK derivation process,
including the TSK lifetime. including the TSK lifetime.
[b] Lower layer mechanisms. While AAA attributes can communicate the [b] Lower layer mechanisms. While AAA attributes can communicate the
maximum exported key lifetime, this only serves to synchronize the maximum exported key lifetime, this only serves to synchronize the
skipping to change at page 29, line 48 skipping to change at page 28, line 36
lifetime of calculated keys can also be managed as a system lifetime of calculated keys can also be managed as a system
parameter on the authenticator. parameter on the authenticator.
[d] Method specific negotiation within EAP. While EAP itself does not [d] Method specific negotiation within EAP. While EAP itself does not
support lifetime negotiation, it would be possible to specify support lifetime negotiation, it would be possible to specify
methods that do. However, systems that rely on such negotiation methods that do. However, systems that rely on such negotiation
for exported keys would only function with these methods. As a for exported keys would only function with these methods. As a
result, it is NOT RECOMMENDED to use this approach as the sole way result, it is NOT RECOMMENDED to use this approach as the sole way
to determine key lifetimes. to determine key lifetimes.
3.5. Key cache synchronization 3.6. Key cache synchronization
Issues arise when attempting to synchronize the key cache on the peer Issues arise when attempting to synchronize the key cache on the peer
and authenticator. Lifetime negotiation alone cannot guarantee key and authenticator.
cache synchronization.
One problem is that the AAA protocol cannot guarantee synchronization While the AAA protocol can enable the backend authentication server
of key lifetimes between the peer and authenticator. Where the to provide guidance on the lifetime of transported EAP keying
Secure Association Protocol is not run immediately after EAP material to the authenticator, this does not address the problem of
authentication, the exported and calculated key lifetimes will not be key lifetime synchronization between the peer and authenticator.
known by the peer during the hiatus. Where EAP pre-authentication Where the EAP method does not export the Key-Lifetime parameter, the
occurs, this can leave the peer uncertain whether a subsequent lifetime of the EAP keying material may not be defined until
attempt to use the exported keys will prove successful. completion of the Secure Association Protocol, if ever. This can
leave the peer uncertain how long the authenticator will maintain EAP
keying material within the key cache.
However, even where the Secure Association Protocol is run However, key lifetime negotiation alone cannot guarantee key cache
immediately after EAP, it is still possible for the authenticator to synchronization. Even where the Secure Association Protocol is run
reclaim resources if the created key state is not immediately immediately after EAP and determines the lifetime of EAP keying
utilized. material, it is still possible for the authenticator to reclaim
resources.
The lower layer may utilize Discovery mechanisms to assist in this. The lower layer may utilize the Discovery phase 0 to improve key
For example, the authenticator manages the key cache by deleting the cache synchronization. For example, if the authenticator manages the
oldest key first (LIFO), the relative creation time of the last key key cache by deleting the oldest key first (LIFO), the relative
to be deleted could be advertised with the Discovery phase, enabling creation time of the last key to be deleted could be advertised
the peer to determine whether a given key had been expired from the within the Discovery phase, enabling the peer to determine whether
authenticator key cache prematurely. keying material had been prematurely expired from the authenticator
key cache.
3.6. Key Strength 3.7. Key Strength
In order to guard against brute force attacks, EAP methods deriving In order to guard against brute force attacks, EAP methods deriving
keys need to be capable of generating keys with an appropriate keys need to be capable of generating keys with an appropriate
effective symmetric key strength. In order to ensure that key effective symmetric key strength. In order to ensure that key
generation is not the weakest link, it is RECOMMENDED that EAP generation is not the weakest link, it is RECOMMENDED that EAP
methods utilizing public key cryptography choose a public key that methods utilizing public key cryptography choose a public key that
has a cryptographic strength meeting the symmetric key strength has a cryptographic strength meeting the symmetric key strength
requirement. requirement.
As noted in [RFC3766] Section 5, this results in the following As noted in [RFC3766] Section 5, this results in the following
skipping to change at page 31, line 5 skipping to change at page 29, line 41
(bits) size (bits) size (bits) (bits) size (bits) size (bits)
----------------- ----------------- ------------ ----------------- ----------------- ------------
70 947 128 70 947 128
80 1228 145 80 1228 145
90 1553 153 90 1553 153
100 1926 184 100 1926 184
150 4575 279 150 4575 279
200 8719 373 200 8719 373
250 14596 475 250 14596 475
3.7. Key Wrap 3.8. Key Wrap
As described in [RFC3579] Section 4.3, known problems exist in the The key wrap specified in [RFC2548], which is based on an MD5-based
key wrap specified in [RFC2548]. Where the same RADIUS shared secret stream cipher, has known problems, as described in [RFC3579] Section
is used by a PAP authenticator and an EAP authenticator, there is a 4.3. RADIUS uses the shared secret for multiple purposes, including
vulnerability to known plaintext attack. Since RADIUS uses the per-packet authentication and attribute hiding, considerable
shared secret for multiple purposes, including per-packet information is exposed about the shared secret with each packet.
authentication, attribute hiding, considerable information is exposed This exposes the shared secret to dictionary attacks. MD5 is used
about the shared secret with each packet. This exposes the shared both to compute the RADIUS Response Authenticator and the Message-
secret to dictionary attacks. MD5 is used both to compute the RADIUS Authenticator attribute, and concerns exist relating to the security
Response Authenticator and the Message-Authenticator attribute, and of this hash [MD5Collision].
some concerns exist relating to the security of this hash
[MD5Attack].
As discussed in [RFC3579] Section 4.3, the security vulnerabilities As discussed in [RFC3579] Section 4.3, the security vulnerabilities
of RADIUS are extensive, and therefore development of an alternative of RADIUS are extensive, and therefore development of an alternative
key wrap technique based on the RADIUS shared secret would not key wrap technique based on the RADIUS shared secret would not
substantially improve security. As a result, [RFC3759] Section 4.2 substantially improve security. As a result, [RFC3759] Section 4.2
recommends running RADIUS over IPsec. The same approach is taken in recommends running RADIUS over IPsec. The same approach is taken in
Diameter EAP [RFC4072], which defines cleartext key attributes, to be Diameter EAP [RFC4072], which defines cleartext key attributes, to be
protected by IPsec or TLS. protected by IPsec or TLS.
Where an untrusted AAA intermediary is present (such as a RADIUS Where an untrusted AAA intermediary is present (such as a RADIUS
proxy or a Diameter agent), and data object security is not used, proxy or a Diameter agent), and data object security is not used,
transported keying material may be recovered by an attacker in transported keying material may be recovered by an attacker in
control of the untrusted intermediary. Possession of transported control of the untrusted intermediary. Possession of transported
keying material enables decryption of data traffic sent between the keying material enables decryption of data traffic sent between the
peer and a specific authenticator. However, as long as EAP keying peer and a specific authenticator. However, as long as EAP keying
material or keys derived from it is only utilized by a single material or keys derived from it are only utilized by a single
authenticator, compromise of the transported keying material does not authenticator, compromise of the transported keying material does not
enable an attacker to impersonate the peer to another authenticator. enable an attacker to impersonate the peer to another authenticator.
Vulnerability to an untrusted AAA intermediary can be mitigated by Vulnerability to an untrusted AAA intermediary can be mitigated by
implementation of redirect functionality, as described in [RFC3588] implementation of redirect functionality, as described in [RFC3588]
and [RFC4072]. and [RFC4072].
4. Handoff Vulnerabilities 4. Handoff Vulnerabilities
With EAP, a number of mechanisms are be utilized in order to reduce With EAP, several mechanisms are available to reduce the latency in
the latency of handoff between authenticators. One such mechanism is handoff between authenticators:
EAP pre-authentication, in which EAP is utilized to pre-establish EAP
[1] EAP pre-authentication. This utilizes EAP to pre-establish EAP
keying material on an authenticator prior to arrival of the peer. keying material on an authenticator prior to arrival of the peer.
Another such mechanism is key caching, in which an EAP peer can re- Use of pre-authentication within IEEE 802.11 is described in
attach to an authenticator without having to re-authenticate using [8021XHandoff] and [IEEE-802.11i].
EAP. Yet another mechanism is context transfer, such as is defined
in [IEEE-802.11F] (now deprecated) and [CTP]. These mechanisms [2] Key caching. This mechanism enables an EAP peer to re-attach to an
introduce new security vulnerabilities, as discussed in the sections authenticator without requiring EAP re-authentication.
that follow.
[3] Context transfer, such as is defined in [IEEE-802.11F] (now
deprecated) and [RFC4067]. Use of context transfer for handoff
latency improvement is described in [IEEE-02-758].
[4] Proactive key distribution, such as is described in [IEEE-02-758]
and [I-D.irtf-aaaarch-handoff].
The sections that follow discuss the security vulnerabilities
introduced by the above mechanisms.
4.1. Authorization 4.1. Authorization
In a typical network access scenario (dial-in, wireless LAN, etc.) In a typical network access scenario (dial-in, wireless LAN, etc.)
access control mechanisms are typically applied. These mechanisms access control mechanisms are typically applied. These mechanisms
include user authentication as well as authorization for the offered include user authentication as well as authorization for the offered
service. service.
As a part of the authentication process, the backend authentication As a part of the authentication process, the backend authentication
server determines the user's authorization profile. The user server determines the user's authorization profile. The user
authorizations are transmitted by the backend authentication server authorizations are transmitted by the backend authentication server
to the EAP authenticator (also known as the Network Access Server or to the EAP authenticator (also known as the Network Access Server or
authenticator) and with the transported EAP keying material, in Phase authenticator) along with the transported EAP keying material, in
1b of the EAP conversation. Typically, the profile is determined Phase 1b of the EAP conversation. Typically, the profile is
based on the user identity, but a certificate presented by the user determined based on the user identity, but a certificate presented by
may also provide authorization information. the user may also provide authorization information.
The backend authentication server is responsible for making a user The backend authentication server is responsible for making a user
authorization decision, answering the following questions: authorization decision, which requires answering the following
questions:
[a] Is this a legitimate user for this particular network? [a] Is this a legitimate user for this particular network?
[b] Is this user allowed the type of access he or she is requesting? [b] Is the user allowed the type of access he or she is requesting?
[c] Are there any specific parameters (mandatory tunneling, bandwidth, [c] Are there any specific parameters (mandatory tunneling, bandwidth,
filters, and so on) that the access network should be aware of for filters, and so on) that the access network should be aware of for
this user? this user?
[d] Is this user within the subscription rules regarding time of day? [d] Is the user operating within the time of day subscription rules?
[e] Is this user within his limits for concurrent sessions? [e] Is the user within his limits for concurrent sessions?
[f] Are there any fraud, credit limit, or other concerns that indicate [f] Are there any fraud, credit limit, or other concerns that indicate
that access should be denied? that access should be denied?
While the authorization decision is in principle simple, the process While the authorization decision is in principle simple, the process
is complicated by the distributed nature of the decision making. is complicated by the distributed nature of the decision making.
Where brokering entities or proxies are involved, all of the AAA Where brokering entities or proxies are involved, all of the AAA
entities in the chain from the authenticator to the home backend entities in the chain from the authenticator to the home backend
authentication server are involved in the decision. For instance, a authentication server are involved in the decision. For instance, a
broker can disallow access even if the home backend authentication broker can disallow access even if the home backend authentication
skipping to change at page 33, line 16 skipping to change at page 32, line 13
particular authorizations are typically not communicated to the particular authorizations are typically not communicated to the
authenticator, only the final result. As a result, the authenticator 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 has no way to know what the decision was based on. Was a set of
authorization parameters sent because this service is always provided authorization parameters sent because this service is always provided
to the user, or was the decision based on the time/day and the to the user, or was the decision based on the time/day and the
capabilities of the requesting authenticator device? capabilities of the requesting authenticator device?
4.2. Correctness 4.2. Correctness
When the AAA exchange is bypassed via use of techniques such as key When the AAA exchange is bypassed via use of techniques such as key
caching, this creates challenges in ensuring that authorization is caching, it can be challenging to ensure that authorization is
properly handled. These include: properly handled. Challenges include:
[a] Consistent application of session time limits. Bypassing AAA [a] Consistent application of session time limits. Bypassing AAA
should not automatically increase the available session time, should not automatically increase the available session time,
allowing a user to endlessly extend their network access by allowing a user to endlessly extend their network access by
changing the point of attachment. changing the point of attachment.
[b] Avoidance of privilege elevation. Bypassing AAA should not result [b] Avoidance of privilege elevation. Bypassing AAA should not result
in a user being granted access to services which they are not in a user being granted access to services which they are not
entitled to. entitled to.
skipping to change at page 33, line 48 skipping to change at page 32, line 45
allowing access, in order to ensure consistent authorization during allowing access, in order to ensure consistent authorization during
a fast handoff it may be necessary to explicitly encode the a fast handoff it may be necessary to explicitly encode the
restrictions within the authorizations provided by the backend restrictions within the authorizations provided by the backend
authentication server. authentication server.
[e] State validity. The introduction of fast handoff should not render [e] State validity. The introduction of fast handoff should not render
the authentication server incapable of keeping track of network- the authentication server incapable of keeping track of network-
wide state. wide state.
A handoff mechanism capable of addressing these concerns is said to A handoff mechanism capable of addressing these concerns is said to
be "correct". One condition for correctness is as follows: For a be "correct". One condition for correctness is as follows:
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 For a handoff to be "correct" it MUST establish on the new device
conversation with the backend authentication server. the same context as would have been created had the new device
completed a AAA conversation with the backend authentication
server.
A properly designed handoff scheme will only succeed if it is A properly designed handoff scheme will only succeed if it is
"correct" in this way. If a successful handoff would establish "correct" in this way. If a successful handoff would establish
"incorrect" state, it is preferable for it to fail, in order to avoid "incorrect" state, it is preferable for it to fail, in order to avoid
creation of incorrect context. creation of incorrect context.
Some backend authentication server and authenticator configurations Some authenticator and backend authentication server configurations
are incapable of meeting this definition of "correctness". For are incapable of meeting this definition of "correctness". For
example, if the old and new device differ in their capabilities, it example, if the old and new device differ in their capabilities, a
may be difficult to meet this definition of correctness in a handoff handoff mechanism that bypasses AAA may find it difficult to meet
mechanism that bypasses AAA. Backend authentication servers often this definition of correctness. Backend authentication servers often
perform conditional evaluation, in which the authorizations returned perform conditional evaluation, in which the authorizations returned
in an Access-Accept message are contingent on the authenticator or on in an Access-Accept message are contingent on the authenticator or on
dynamic state such as the time of day or number of simultaneous dynamic state such as the time of day or number of simultaneous
sessions. For example, in a heterogeneous deployment, the backend sessions. For example, in a heterogeneous deployment, the backend
authentication server might return different authorizations depending authentication server might return different authorizations depending
on the authenticator making the request, in order to make sure that on the authenticator making the request, in order to make sure that
the requested service is consistent with the authenticator the requested service is consistent with the authenticator
capabilities. capabilities.
If differences between the new and old device would result in the If differences between the new and old device would result in the
backend authentication server sending a different set of messages to backend authentication server sending a different set of messages to
the new device than were sent to the old device, then if the handoff the new device than were sent to the old device, then if the handoff
mechanism bypasses AAA, then the handoff cannot be carried out mechanism bypasses AAA, the handoff cannot be carried out correctly.
correctly.
For example, if some authenticator devices within a deployment For example, if some authenticators support dynamic VLANs while
support dynamic VLANs while others do not, then attributes present in others do not, then attributes present in the Access-Request (such as
the Access-Request (such as the authenticator-IP-Address, the NAS-IP-Address, NAS-IPv6-Address, NAS-Identifier, etc.) could be
authenticator-Identifier, Vendor-Identifier, etc.) could be examined examined to determine when VLAN attributes will be returned, as
to determine when VLAN attributes will be returned, as described in described in [RFC3580]. VLAN support is defined in [IEEE-802.1Q].
[RFC3580]. VLAN support is defined in [IEEE-802.1Q]. If a handoff If a handoff bypassing the backend authentication server were to
bypassing the backend authentication server were to occur between a occur between a authenticator supporting dynamic VLANs and another
authenticator supporting dynamic VLANs and another authenticator authenticator which does not, then a guest user with access
which does not, then a guest user with access restricted to a guest restricted to a guest VLAN could be given unrestricted access to the
VLAN could be given unrestricted access to the network. network.
Similarly, in a network where access is restricted based on the day Similarly, in a network where access is restricted based on the day
and time, Service Set Identifier (SSID), Calling-Station-Id or other and time, Service Set Identifier (SSID), Calling-Station-Id or other
factors, unless the restrictions are encoded within the factors, unless the restrictions are encoded within the
authorizations, or a partial AAA conversation is included, then a authorizations, or a partial AAA conversation is included, then a
handoff could result in the user bypassing the restrictions. handoff could result in the user bypassing the restrictions.
In practice, these considerations limit the situations in which fast In practice, these considerations limit the situations in which fast
handoff mechanisms bypassing AAA can be expected to be successful. handoff mechanisms bypassing AAA can be expected to be successful.
Where the deployed devices implement the same set of services, it may Where the deployed devices implement the same set of services, it may
skipping to change at page 35, line 35 skipping to change at page 34, line 35
be ignored. be ignored.
Although it may seem somewhat counter-intuitive, failure is indeed Although it may seem somewhat counter-intuitive, failure is indeed
the "correct" result where a known but unsupported service is the "correct" result where a known but unsupported service is
requested. Presumably a correctly configured backend authentication requested. Presumably a correctly configured backend authentication
server would not request that a device carry out a service that it 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 does not implement. This implies that if the new device were to
complete a AAA conversation that it would be likely to receive complete a AAA conversation that it would be likely to receive
different service instructions. In such a case, failure of the different service instructions. In such a case, failure of the
handoff is the desired result. This will cause the new device to go 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 back to the backend server in order to receive the appropriate
definition. service definition.
In practice, this implies that handoff mechanisms which bypass AAA In practice, this implies that handoff mechanisms which bypass AAA
are most likely to be successful within a homogeneous device are most likely to be successful within a homogeneous device
deployment within a single administrative domain. For example, it deployment within a single administrative domain. For example, it
would not be advisable to carry out a fast handoff bypassing AAA would not be advisable to carry out a fast handoff bypassing AAA
between a authenticator providing confidentiality and another between a authenticator providing confidentiality and another
authenticator that does not support this service. The correct result authenticator that does not support this service. The correct result
of such a handoff would be a failure, since if the handoff were of such a handoff would be a failure, since if the handoff were
blindly carried out, then the user would be moved from a secure to an blindly carried out, then the user would be moved from a secure to an
insecure channel without permission from the backend authentication insecure channel without permission from the backend authentication
server. Thus the definition of a "known but unsupported service" server. Thus the definition of a "known but unsupported service"
MUST encompass requests for unavailable security services. This MUST encompass requests for unavailable security services. This
includes vendor-specific attributes related to security, such as includes vendor-specific attributes related to security, such as
those described in [RFC2548]. those described in [RFC2548].
5. Security Considerations 5. Security Considerations
In order to analyze whether the EAP conversation achieves its In order to analyze whether the EAP conversation achieves its
security goals, it is first necessary to state those goals as well as security goals, it is first necessary to describe the threat model.
the underlying security assumptions. The terms "Cryptographic binding", "Cryptographic separation", "Key
strength" and "Mutual authentication" are defined in [RFC3748] and
The overall goal of the EAP conversation is to derive fresh session are used with the same meaning here.
keys between the EAP peer and authenticator that are known only to
those parties, and for both the EAP peer and authenticator to
demonstrate that they are authorized to perform their roles either by
each other or by a trusted third party (the backend authentication
server).
The principals of the authentication phase are the EAP peer and
server. Completion of an EAP method exchange supporting key
derivation results in the derivation of EAP keying material (MSK,
EMSK, TEKs) known only to the EAP peer (identified by the Peer-ID)
and server (identified by the Server-ID). Both the EAP peer and EAP
server know the exported keying material to be fresh.
The principals of the AAA Key transport exchange are the EAP
authenticator and the EAP server. Completion of the AAA exchange
results in the transport of EAP keying material from the EAP server
(identified by the Server-ID) to the EAP authenticator (identified by
the NAS-Identifier) without disclosure to any other party. Both the
EAP server and EAP authenticator know this keying material to be
fresh.
The principals of the Secure Association Protocol are the EAP peer
(identified by the Peer-ID) and authenticator (identified by the NAS-
Identifier). Completion of the Secure Association Protocol results
in the derivation of TSKs known only to the EAP peer and
authenticator. Both the EAP peer and authenticator know the TSKs to
be fresh.
5.1. Terminology
"Cryptographic binding", "Cryptographic separation", "Key strength"
and "Mutual authentication" are defined in [RFC3748] and are used
with the same meaning here.
5.2. Threat Model 5.1. Threat Model
The EAP threat model is described in [RFC3748] Section 7.1. The The EAP threat model is described in [RFC3748] Section 7.1. The
security properties of EAP methods (known as "security claims", security properties of EAP methods (known as "security claims",
described in [RFC3784] Section 7.2.1), address these threats. EAP described in [RFC3784] Section 7.2.1), address these threats. EAP
method requirements for applications such as Wireless LAN method requirements for applications such as Wireless LAN
authentication are described in [RFC4017]. The RADIUS threat model authentication are described in [RFC4017]. The RADIUS threat model
is described in [RFC3579] Section 4.1, and responses to these threats is described in [RFC3579] Section 4.1, and responses to these threats
are described in [RFC3579] Sections 4.2 and 4.3. are described in [RFC3579] Sections 4.2 and 4.3.
However, in addition to threats against EAP and AAA, there are other However, in addition to threats against EAP and AAA, there are other
skipping to change at page 37, line 48 skipping to change at page 36, line 16
provide stale keying material to an authenticator, or a poorly provide stale keying material to an authenticator, or a poorly
implemented authenticator may reuse nonces. implemented authenticator may reuse nonces.
[8] An authenticated attacker may attempt to obtain elevated privilege [8] An authenticated attacker may attempt to obtain elevated privilege
in order to access information that it does not have rights to. in order to access information that it does not have rights to.
In order to address these threats, [Housley] provides a description In order to address these threats, [Housley] provides a description
of mandatory system security properties. Issues relating system of mandatory system security properties. Issues relating system
security requirements are discussed in the sections that follow. security requirements are discussed in the sections that follow.
5.3. Authenticator Compromise 5.2. Authenticator Compromise
In the event that an authenticator is compromised or stolen, an In the event that an authenticator is compromised or stolen, an
attacker may gain access to the network via that authenticator, or attacker may gain access to the network via that authenticator, or
may obtain the credentials required for that authenticator/AAA client may obtain the credentials required for that authenticator/AAA client
to communicate with one or more backend authentication servers. to communicate with one or more backend authentication servers.
However, this should not allow the attacker to compromise other However, this should not allow the attacker to compromise other
authenticators or the backend authentication server, or obtain long- authenticators or the backend authentication server, or obtain long-
term user credentials. term user credentials.
The implications of this requirement are many, but some of the more The implications of this requirement are many, but some of the more
skipping to change at page 38, line 36 skipping to change at page 37, line 5
to impersonate other AAA clients to the backend authentication to impersonate other AAA clients to the backend authentication
server, or even to impersonate a backend authentication server to server, or even to impersonate a backend authentication server to
other AAA clients. other AAA clients.
No Compromise of Long-Term Credentials No Compromise of Long-Term Credentials
An attacker obtaining TSKs, TEKs or EAP keying material such as the An attacker obtaining TSKs, TEKs or EAP keying material such as the
MSK MUST NOT be able to obtain long-term user credentials such as MSK MUST NOT be able to obtain long-term user credentials such as
pre-shared keys, passwords or private-keys without breaking a pre-shared keys, passwords or private-keys without breaking a
fundamental cryptographic assumption. fundamental cryptographic assumption.
5.4. Spoofing 5.3. Spoofing
The use of per-packet authentication and integrity protection The use of per-packet authentication and integrity protection
provides protection against spoofing attacks. Diameter [RFC3588] provides protection against spoofing attacks. Diameter [RFC3588]
provides support for per-packet authentication and integrity provides support for per-packet authentication and integrity
protection via use of IPsec or TLS. RADIUS/EAP [RFC3579] provides protection via use of IPsec or TLS. RADIUS/EAP [RFC3579] provides
for per-packet authentication and integrity protection via use of the for per-packet authentication and integrity protection via use of the
Message-Authenticator attribute. Message-Authenticator attribute.
[RFC3748] Section 7.2.1 describes the "integrity protection" security [RFC3748] Section 7.2.1 describes the "integrity protection" security
claim and [RFC4017] requires use of EAP methods supporting this claim and [RFC4017] requires use of EAP methods supporting this
claim. claim.
In order to prevent forgery of Secure Association Protocol frames, In order to prevent forgery of Secure Association Protocol frames,
per-frame authentication and integrity protection is RECOMMENDED on per-frame authentication and integrity protection is RECOMMENDED on
all messages. [IEEE-802.11i] supports per-frame integrity protection all messages. [IEEE-802.11i] supports per-frame integrity protection
and authentication on all messages within the 4-way handshake except and authentication on all messages within the 4-way handshake except
the first message. An attack leveraging this ommission is described the first message. An attack leveraging this ommission is described
in [Analysis]. in [Analysis].
5.5. Downgrade Attacks 5.4. Downgrade Attacks
The ability to negotiate the use of a particular cryptographic The ability to negotiate the use of a particular cryptographic
algorithm provides resilience against compromise of a particular algorithm provides resilience against compromise of a particular
cryptographic algorithm. This is usually accomplished by including cryptographic algorithm. This is usually accomplished by including
an algorithm identifier in the protocol, and by specifying the an algorithm identifier in the protocol, and by specifying the
algorithm requirements in the protocol specification. In order to algorithm requirements in the protocol specification. In order to
prevent downgrade attacks, secure confirmation of the "best" prevent downgrade attacks, secure confirmation of the "best"
ciphersuite is required. ciphersuite is required.
[RFC3748] Section 7.2.1 describes the "protected ciphersuite [RFC3748] Section 7.2.1 describes the "protected ciphersuite
negotiation" security claim that refers to the ability of an EAP negotiation" security claim that refers to the ability of an EAP
method to negotiate the ciphersuite used to protect the EAP method to negotiate the ciphersuite used to protect the EAP
conversation, as well as to integrity protect the negotiation. conversation, as well as to integrity protect the negotiation.
[RFC4017] requires EAP methods satisfying this security claim. [RFC4017] requires EAP methods satisfying this security claim.
Diameter [RFC3588] provides support for cryptographic algorithm Diameter [RFC3588] provides support for cryptographic algorithm
negotiation via use of IPsec or TLS. RADIUS [RFC3579] does not negotiation via use of IPsec or TLS. RADIUS [RFC3579] does not
support the negotiation of cryptographic algorithms, and relies on support the negotiation of cryptographic algorithms, and relies on
MD5 for integrity protection, authentication and confidentiality, MD5 for integrity protection, authentication and confidentiality,
despite known weaknesses in the algorithm [MD5Attack]. This issue despite known weaknesses in the algorithm [MD5Collision]. This issue
can be addressed via use of RADIUS over IPsec, as described in can be addressed via use of RADIUS over IPsec, as described in
[RFC3579] Section 4.2. [RFC3579] Section 4.2.
As a result, EAP methods and AAA protocols are capable of addressing As a result, EAP methods and AAA protocols are capable of addressing
downgrade attacks. To ensure against downgrade attacks within lower downgrade attacks. To ensure against downgrade attacks within lower
layer protocols, algorithm independence is REQUIRED with lower layers layer protocols, algorithm independence is REQUIRED with lower layers
using EAP for key derivation. For interoperability, at least one using EAP for key derivation. For interoperability, at least one
suite of mandatory-to-implement algorithm MUST be selected. Lower suite of mandatory-to-implement algorithm MUST be selected. Lower
layer protocols supporting EAP for key derivation SHOULD also support layer protocols supporting EAP for key derivation SHOULD also support
secure ciphersuite negotiation. As described in [RFC1968], PPP ECP secure ciphersuite negotiation. As described in [RFC1968], PPP ECP
does not provide support for secure ciphersuite negotiation. does not provide support for secure ciphersuite negotiation.
However, [IEEE-802.11i] does support secure ciphersuite negotiation. However, [IEEE-802.11i] does support secure ciphersuite negotiation.
5.6. Unauthorized Disclosure 5.5. Unauthorized Disclosure
While preserving algorithm independence, confidentiality of all While preserving algorithm independence, confidentiality of all
keying material MUST be maintained. To prevent unauthorized disclose keying material MUST be maintained. To prevent unauthorized disclose
of keys, each party in the EAP conversation MUST be authenticated to of keys, each party in the EAP conversation MUST be authenticated to
the other parties with whom it communicates. Keying material MUST be the other parties with whom it communicates. Keying material MUST be
bound to the appropriate context. bound to the appropriate context.
[RFC3748] Section 7.2.1 describes the "mutual authentication" and [RFC3748] Section 7.2.1 describes the "mutual authentication" and
"dictionary attack resistance" claims, and [RFC4017] requires EAP "dictionary attack resistance" claims, and [RFC4017] requires EAP
methods satisfying these claims. EAP methods complying with methods satisfying these claims. EAP methods complying with
[RFC4017] therefore provide for mutual authentication between the EAP [RFC4017] therefore provide for mutual authentication between the EAP
peer and server. Binding of EAP keying material (MSK, EMSK) to the peer and server. Binding of EAP keying material (MSK, EMSK) to the
appropriate context is provided by the Peer-ID and Server-ID which appropriate context is provided by the Peer-ID and Server-ID which
are exported along with the keying material. are exported along with the keying material.
Diameter [RFC3588] provides for per-packet authentication and Diameter [RFC3588] provides for per-packet authentication and
integrity protection via IPsec or TLS, and RADIUS/EAP [RFC3579] also integrity protection via IPsec or TLS, and RADIUS/EAP [RFC3579] also
provides for per-packet authentication and integrity protection. provides for per-packet authentication and integrity protection.
Where the NAS/authenticator and backend authentication server Where the NAS/authenticator and backend authentication server
communicate directly and credible keywrap is used (see Section 3.7), communicate directly and credible keywrap is used (see Section 3.8),
this ensures that the AAA Key Transport phase achieves its security this ensures that the AAA Key Transport phase achieves its security
objectives: mutually authenticating the AAA client/authenticator and objectives: mutually authenticating the AAA client/authenticator and
backend authentication server and providing EAP keying material to backend authentication server and providing EAP keying material to
the EAP authenticator and to no other party. the EAP authenticator and to no other party. [RFC2607] Section 7
describes the security issues ocurring when the authenticator and
backend authentication server do not communicate directly.
As noted in Section 3.1, the Secure Association Protocol does not by As noted in Section 3.1, the Secure Association Protocol does not by
itself provide for mutual authentication between the EAP peer and itself provide for mutual authentication between the EAP peer and
authenticator, even if mutual possession of EAP keying material is authenticator, even if mutual possession of EAP keying material is
proven. However, where the NAS/authenticator and backend proven. Where the NAS/authenticator and backend authentication
authentication server communicate directly, the backend server communicate directly, the backend authentication server can
authentication server can verify the correspondence between NAS verify the correspondence between NAS identification attributes, the
identification attributes, the source address of packets sent by the source address of packets sent by the NAS, and the AAA credentials.
NAS, and the AAA credentials. As long as the NAS has not shared its As long as the NAS has not shared its AAA credentials with another
AAA credentials with another NAS, this allows the backend NAS, this allows the backend authentication server to authenticate
authentication server to authenticate the NAS. Using Channel the NAS. Using Channel Bindings, the EAP peer can then determine
Bindings, the EAP peer can then determine whether the whether the NAS/authenticator has provided the same identifying
NAS/authenticator has provided the same identifying information to information to the EAP peer and backend authentication server.
the EAP peer and backend authentication server.
Peer and authenticator authorization MUST be performed. Peer and authenticator authorization MUST be performed.
Authorization is REQUIRED whenever a peer associates with a new Authorization is REQUIRED whenever a peer associates with a new
authenticator. Authorization checking prevents an elevation of authenticator. Authorization checking prevents an elevation of
privilege attack, and ensures that an unauthorized authenticator is privilege attack, and ensures that an unauthorized authenticator is
detected. Authorizations SHOULD be synchronized between the EAP detected. Authorizations SHOULD be synchronized between the EAP
peer, server, authenticator. Once the EAP conversation exchanges are peer, server, authenticator. Once the EAP conversation exchanges are
complete, all of these parties should hold the same view of the complete, all of these parties should hold the same view of the
authorizations associated the other parties. If peer authorization authorizations associated the other parties. If peer authorization
is restricted, then the peer SHOULD be made aware of the restriction. is restricted, then the peer SHOULD be made aware of the restriction.
The AAA exchange provides the EAP authenticator with authorizations The AAA exchange provides the EAP authenticator with authorizations
skipping to change at page 41, line 5 skipping to change at page 39, line 23
The AAA exchange provides the EAP authenticator with authorizations The AAA exchange provides the EAP authenticator with authorizations
relating to the EAP peer. However, neither the EAP nor AAA exchanges relating to the EAP peer. However, neither the EAP nor AAA exchanges
provides authorizations to the EAP peer. In order to ensure that all provides authorizations to the EAP peer. In order to ensure that all
parties hold the same view of the authorizations it is RECOMMENDED parties hold the same view of the authorizations it is RECOMMENDED
that the Secure Association Protocol enable communication of that the Secure Association Protocol enable communication of
authorizations between the EAP authenticator and peer. authorizations between the EAP authenticator and peer.
In order to enable key binding and authorization of all parties, it In order to enable key binding and authorization of all parties, it
is RECOMMENDED that the parties use a set of identities that are is RECOMMENDED that the parties use a set of identities that are
consistent between the conversation phases. RADIUS [RFC2865] and consistent between the conversation phases. Consistently identifying
Diameter NASREQ [RFC4005] require that the NAS/EAP authenticator the EAP authenticator enables the EAP peer to determine whether EAP
identify itself by including one or more identification attributes keying material has been shared between EAP authenticators as well as
within an Access-Request packet (NAS-Identifier, NAS-IP-Address, NAS- to confirm with the backend authentication server that an EAP
IPv6-Address).
Since the backend authentication server provides EAP keying material
for use by the EAP authenticator as identified by these attributes,
where an EAP authenticator may have multiple ports, it is RECOMMENDED
for the EAP authenticator to identify itself using NAS identification
attributes during the Secure Association Protocol exchange with the
EAP peer. This enables the EAP peer to determine whether EAP keying
material has been shared between EAP authenticators as well as to
confirm with the backend authentication server that an EAP
authenticator proving possession of EAP keying material during the authenticator proving possession of EAP keying material during the
Secure Association Protocol was authorized to obtain it. Typically, Secure Association Protocol was authorized to obtain it.
the NAS-Identifier attribute is most convenient for this purpose, Identification issues are discussed in Section 2.2 and key scope
since a NAS/authenticator may have multiple IP addresses. issues are discussed in Section 3.2.
Similarly, the backend authentication server authorizes the EAP
authenticator to provide access to the EAP peer identified by the
Peer-ID, securely verified during the EAP authentication exchange.
In order to determine whether EAP keying material has been shared
between EAP peers, where the EAP peer has multiple ports it is
RECOMMENDED for the EAP peer to identify itself using the Peer-ID
during the Secure Association Protocol exchange with the EAP
authenticator.
5.7. Replay Protection 5.6. Replay Protection
Replay protection allows a protocol message recipient to discard any Replay protection allows a protocol message recipient to discard any
message that was recorded during a previous legitimate dialogue and message that was recorded during a previous legitimate dialogue and
presented as though it belonged to the current dialogue. presented as though it belonged to the current dialogue.
[RFC3748] Section 7.2.1 describes the "replay protection" security [RFC3748] Section 7.2.1 describes the "replay protection" security
claim and [RFC4017] requires use of EAP methods supporting this claim and [RFC4017] requires use of EAP methods supporting this
claim. claim.
Diameter [RFC3588] provides support for replay protection via use of Diameter [RFC3588] provides support for replay protection via use of
skipping to change at page 42, line 12 skipping to change at page 40, line 10
depend on a Nonce in either the Request or Response packets. depend on a Nonce in either the Request or Response packets.
Therefore unless an Event-Timestamp attribute is included or IPsec is Therefore unless an Event-Timestamp attribute is included or IPsec is
used, the recipient may not be able to determine whether these used, the recipient may not be able to determine whether these
packets have been replayed. packets have been replayed.
In order to prevent replay of Secure Association Protocol frames, In order to prevent replay of Secure Association Protocol frames,
replay protection is REQUIRED on all messages. [IEEE-802.11i] replay protection is REQUIRED on all messages. [IEEE-802.11i]
supports replay protection on all messages within the 4-way supports replay protection on all messages within the 4-way
handshake. handshake.
5.8. Key Freshness 5.7. Key Freshness
A session key should be considered compromised if it remains in use A session key should be considered compromised if it remains in use
too long. As noted in [Housley], session keys MUST be strong and too long. As noted in [Housley], session keys MUST be strong and
fresh, while preserving algorithm independence. A fresh fresh, while preserving algorithm independence. A fresh
cryptographic key is one that is generated specifically for the cryptographic key is one that is generated specifically for the
intended use. Each session deserves an independent session key; intended use. Each session deserves an independent session key;
disclosure of one session key MUST NOT aid the attacker in disclosure of one session key MUST NOT aid the attacker in
discovering any other session keys. discovering any other session keys.
Fresh keys are required even when a long replay counter (that is, one Fresh keys are required even when a long replay counter (that is, one
skipping to change at page 43, line 15 skipping to change at page 41, line 12
peer, authenticator and server to distinguish EAP conversations. peer, authenticator and server to distinguish EAP conversations.
However, unless the authenticator keeps track of EAP Session-IDs, However, unless the authenticator keeps track of EAP Session-IDs,
the authenticator cannot use the Session-ID to guarantee the the authenticator cannot use the Session-ID to guarantee the
freshness of EAP keying material. freshness of EAP keying material.
As described in [RFC3580] Section 3.17, When sent in an Access- As described in [RFC3580] Section 3.17, When sent in an Access-
Accept along with a Termination-Action value of RADIUS-Request, the Accept along with a Termination-Action value of RADIUS-Request, the
Session-Timeout attribute specifies the maximum number of seconds Session-Timeout attribute specifies the maximum number of seconds
of service provided prior to re-authentication. [IEEE-802.11i] of service provided prior to re-authentication. [IEEE-802.11i]
also utilizes the Session-Timeout attribute to limit the maximum also utilizes the Session-Timeout attribute to limit the maximum
time that EAP keying material may be cache. Therefore the use of time that EAP keying material may be cached. Therefore the use of
the Session-Timeout attribute enables the backend authentication the Session-Timeout attribute enables the backend authentication
server to limit the exposure of EAP keying material. server to limit the exposure of EAP keying material.
Lower Layer Lower Layer
The lower layer Secure Association Protocol MUST generate a fresh As described in Section 3.1, the lower layer Secure Association
session key for each session, even if the keying material and Protocol MUST generate a fresh session key for each session, even
parameters provided by EAP methods are cached, or the peer or if the keying material and parameters provided by EAP methods are
authenticator lack a high entropy random number generator. A cached, or either the peer or authenticator lack a high entropy
RECOMMENDED method is for the peer and authenticator to each random number generator. A RECOMMENDED method is for the peer and
provide a nonce or counter used in session key derivation. If a authenticator to each provide a nonce or counter used in session
nonce is used, it is RECOMMENDED that it be at least 128 bits. key derivation. If a nonce is used, it is RECOMMENDED that it be
at least 128 bits.
5.9. Elevation of Privilege 5.8. Elevation of Privilege
Parties MUST NOT have access to keying material that is not needed to Parties MUST NOT have access to keying material that is not needed to
perform their own role. A party has access to a particular key if it perform their own role. A party has access to a particular key if it
has access to all of the secret information needed to derive it. If has access to all of the secret information needed to derive it. If
a post-EAP handshake is used to establish session keys, the post-EAP a Secure Association Protocol is used to establish session keys, it
handshake MUST specify the scope for session keys. MUST specify the scope for session keys.
Transported EAP keying material is permitted to be accessed by the Transported EAP keying material is permitted to be accessed by the
EAP peer, authenticator and server. The EAP peer and server derive EAP peer, authenticator and server. The EAP peer and server derive
the transported keying material during the process of mutually the transported keying material during the process of mutually
authenticating each other using the selected EAP method. During the authenticating each other using the selected EAP method. During the
Secure Association Protocol, the EAP peer utilizes the transported Secure Association Protocol, the EAP peer utilizes the transported
EAP keying material to demonstrate to the authenticator that it is EAP keying material to demonstrate to the authenticator that it is
the same party that authenticated to the EAP server and was the same party that authenticated to the EAP server and was
authorized by it. The EAP authenticator utilizes the transported EAP authorized by it. The EAP authenticator utilizes the transported EAP
keying material to prove to the peer not only that the EAP keying material to prove to the peer not only that the EAP
conversation was transported through it (this could be demonstrated conversation was transported through it (this could be demonstrated
by a man-in-the-middle), but that it was uniquely authorized by the by a man-in-the-middle), but that it was uniquely authorized by the
EAP server to provide the peer with access to the network. Unique EAP server to provide the peer with access to the network. Unique
authorization can only be demonstrated if the EAP authenticator does authorization can only be demonstrated if the EAP authenticator does
not share the transported keying material with a party other than the not share the transported keying material with a party other than the
EAP peer and server. EAP peer and server.
TSKs are permitted to be accessed only by the EAP peer and TSKs are permitted to be accessed only by the EAP peer and
authenticator. Since the TSKs can be determined from the transported authenticator (see Section 1.5). As discussed in Section 2.1, PPP
EAP keying material and the cleartext of the Secure Association and 802.11i derive the TSKs from transported EAP keying material;
Protocol exchange, the backend authentication server will have access 802.16e utilizes transported EAP keying material for TSK keywrap;
to the TSKs unless it deletes the transported EAP keying material IKEv2 utilizes transported EAP keying material only to authenticate
after sending it. the derivation of TSKs.
5.10. Man-in-the-middle Attacks Where demonstration of authorization depends entirely on possession
of transported EAP keying material (such as in PPP, 802.11i and
802.16e), this enables the backend server to masquerade as the
authenticator, and possibly to obtain the TSKs unless the backend
server deletes the transported EAP keying material after sending it.
5.9. Man-in-the-middle Attacks
As described in [I-D.puthenkulam-eap-binding], EAP method sequences As described in [I-D.puthenkulam-eap-binding], EAP method sequences
and compound authentication mechanisms may be subject to man-in-the- and compound authentication mechanisms may be subject to man-in-the-
middle attacks. When such attacks are successfully carried out, the middle attacks. When such attacks are successfully carried out, the
attacker acts as an intermediary between a victim and a legitimate attacker acts as an intermediary between a victim and a legitimate
authenticator. This allows the attacker to authenticate successfully authenticator. This allows the attacker to authenticate successfully
to the authenticator, as well as to obtain access to the network. to the authenticator, as well as to obtain access to the network.
In order to prevent these attacks, [I-D.puthenkulam-eap-binding] In order to prevent these attacks, [I-D.puthenkulam-eap-binding]
recommends derivation of a compound key by which the EAP peer and recommends derivation of a compound key by which the EAP peer and
server can prove that they have participated in the entire EAP server can prove that they have participated in the entire EAP
exchange. Since the compound key must not be known to an attacker exchange. Since the compound key must not be known to an attacker
posing as an authenticator, and yet must be derived from quantities posing as an authenticator, and yet must be derived from quantities
that are exported by EAP methods, it may be desirable to derive the 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 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- key hygiene, it is recommended that the compound key used for man-in-
the-middle protection be cryptographically separate from other keys the-middle protection be cryptographically separate from other keys
derived from the EMSK. derived from the EMSK.
5.11. Denial of Service Attacks 5.10. Denial of Service Attacks
Key caching may result in vulnerability to denial of service attacks. Key caching may result in vulnerability to denial of service attacks.
For example, EAP methods that create persistent state may be For example, EAP methods that create persistent state may be
vulnerable to denial of service attacks on the EAP server by a rogue vulnerable to denial of service attacks on the EAP server by a rogue
EAP peer. EAP peer.
To address this vulnerability, EAP methods creating persistent state To address this vulnerability, EAP methods creating persistent state
may wish to limit the persistent state created by an EAP peer. For may wish to limit the persistent state created by an EAP peer. For
example, for each peer an EAP server may choose to limit persistent example, for each peer an EAP server may choose to limit persistent
state to a few EAP conversations, distinguished by the EAP Session- state to a few EAP conversations, distinguished by the EAP Session-
ID. This prevents a rogue peer from denying access to other peers. ID. This prevents a rogue peer from denying access to other peers.
Similarly, to conserve resources an authenticator may choose to limit Similarly, to conserve resources an authenticator may choose to limit
the persistent state corresponding to each peer. This can be the persistent state corresponding to each peer. This can be
accomplished by limiting each peer to persistent sttate corresponding accomplished by limiting each peer to persistent state corresponding
to a few EAP converations, distinguished by the EAP Session-ID. to a few EAP conversations, distinguished by the EAP Session-ID.
Depending on the media, creation of new TSKs may or may not imply Depending on the media, creation of new TSKs may or may not imply
deletion of previously derived TSKs. Where there is no implied deletion of previously derived TSKs. Where there is no implied
deletion, the authenticator may choose to limit the number of TSKs deletion, the authenticator may choose to limit the number of TSKs
and associated state that can be stored for each peer. and associated state that can be stored for each peer.
5.12. Impersonation 5.11. 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] Both the RADIUS [RFC2865] and Diameter [RFC3588] protocols are
support mutual authentication between the authenticator (known as the potentially vulnerable to impersonation by a rogue authenticator.
AAA client) and the backend authentication server (known as the While both protocols support mutual authentication between the
backend authentication server), the security mechanisms vary authenticator (known as the AAA client) and the backend
according to the AAA protocol. authentication server (known as the backend authentication server),
the security mechanisms vary.
In RADIUS, the shared secret used for authentication is determined by In RADIUS, the shared secret used for authentication is determined by
the source address of the RADIUS packet. As noted in [RFC3579] the source address of the RADIUS packet. As noted in [RFC3579]
Section 4.3.7, it is highly desirable that the source address be Section 4.3.7, it is highly desirable that the source address be
checked against one or more NAS identification attributes so as to checked against one or more NAS identification attributes so as to
detect and prevent impersonation attacks. detect and prevent impersonation attacks.
When RADIUS requests are forwarded by a proxy, the NAS-IP-Address or When RADIUS Access-Requests are forwarded by a proxy, the NAS-IP-
NAS-IPv6-Address attributes may not correspond to the source address. Address or NAS-IPv6-Address attributes may not correspond to the
Since the NAS-Identifier attribute need not contain an FQDN, it also source address. Since the NAS-Identifier attribute need not contain
may not correspond to the source address, even indirectly. [RFC2865] an FQDN, it also may not correspond to the source address, even
Section 3 states: indirectly. [RFC2865] Section 3 states:
A RADIUS server MUST use the source IP address of the RADIUS A RADIUS server MUST use the source IP address of the RADIUS
UDP packet to decide which shared secret to use, so that UDP packet to decide which shared secret to use, so that
RADIUS requests can be proxied. RADIUS requests can be proxied.
This implies that it is possible for a rogue authenticator to forge This implies that it is possible for a rogue authenticator to forge
NAS-IP-Address, NAS-IPv6-Address or NAS-Identifier attributes within NAS-IP-Address, NAS-IPv6-Address or NAS-Identifier attributes within
a RADIUS Access-Request in order to impersonate another a RADIUS Access-Request in order to impersonate another
authenticator. Among other things, this can result in messages (and authenticator. Among other things, this can result in messages (and
transorted keying material) being sent to the wrong authenticator. transported keying material) being sent to the wrong authenticator.
Since the rogue authenticator is authenticated by the RADIUS proxy or Since the rogue authenticator is authenticated by the RADIUS proxy or
server purely based on the source address, other mechanisms are server purely based on the source address, other mechanisms are
required to detect the forgery. In addition, it is possible for required to detect the forgery. In addition, it is possible for
attributes such as the Called-Station-Id and Calling-Station-Id to be attributes such as the Called-Station-Id and Calling-Station-Id to be
forged as well. forged as well.
As recommended in [RFC3579] Section 4.3.7, this vulnerability can be [RFC3579] Section 4.3.7 describes how an EAP pass-through
mitigated by having RADIUS proxies check NAS identification authenticator acting as a AAA client can be detected if it attempts
attributes against the source address. to impersonate another authenticator (such by sending incorrect
Called-Station-ID [RFC2865], NAS-Identifier [RFC2865], NAS-IP-Address
[RFC2865] or NAS-IPv6-Address [RFC3162] attributes via the AAA
protocol). This vulnerabilityh can be mitigated by having RADIUS
proxies check NAS identification attributes against the source
address.
While [RFC3588] requires use of the Route-Record AVP, this utilizes While [RFC3588] requires use of the Route-Record AVP, this utilizes
FQDNs, so that impersonation detection requires DNS A/AAAA and PTR FQDNs, so that impersonation detection requires DNS A, AAAA and PTR
RRs to be properly configured. As a result, it appears that Diameter Resource Records (RRs) to be properly configured. As a result,
is as vulnerable to this attack as RADIUS, if not more so. To Diameter is as vulnerable to this attack as RADIUS, if not more so.
address this vulnerability, it is necessary to allow the backend To address this vulnerability, it is necessary to allow the backend
authentication server to communicate with the authenticator directly, authentication server to communicate with the authenticator directly,
such as via the redirect functionality supported in [RFC3588]. such as via the redirect functionality supported in [RFC3588].
5.13. Channel Binding 5.12. Channel Binding
It is possible for a compromised or poorly implemented EAP It is possible for a compromised or poorly implemented EAP
authenticator to communicate incorrect information to the EAP peer authenticator to communicate incorrect information to the EAP peer
and/or server. This may enable an authenticator to impersonate and/or server. This may enable an authenticator to impersonate
another authenticator or communicate incorrect information via out- another authenticator or communicate incorrect information via out-
of-band mechanisms (such as via AAA or the lower layer). of-band mechanisms (such as via AAA or the lower layer).
Where EAP is used in pass-through mode, the EAP peer does not verify Where EAP is used in pass-through mode, the EAP peer does not verify
the identity of the pass-through authenticator. Within the Secure the identity of the pass-through authenticator. Within the Secure
Association Protocol, the EAP peer and authenticator only demonstrate Association Protocol, the EAP peer and authenticator only demonstrate
mutual possession of the transported EAP keying material. This mutual possession of the transported EAP keying material. This
creates a potential security vulnerability, described in [RFC3748] creates a potential security vulnerability, described in [RFC3748]
Section 7.15. Section 7.15.
[RFC3579] Section 4.3.7 describes how an EAP pass-through As described in the previous section, it is possible for a proxy to
authenticator acting as a AAA client can be detected if it attempts detect a AAA client attempting to impersonate another authenticator
to impersonate another authenticator (such by sending incorrect (such by sending incorrect Called-Station-ID [RFC2865], NAS-
Called-Station-ID [RFC2865], NAS-Identifier [RFC2865], NAS-IP-Address Identifier [RFC2865], NAS-IP-Address [RFC2865] or NAS-IPv6-Address
[RFC2865] or NAS-IPv6-Address [RFC3162] attributes via the AAA [RFC3162] attributes via the AAA protocol). However, it is possible
protocol). However, it is possible for a pass-through authenticator for a pass-through authenticator acting as a AAA client to provide
acting as a AAA client to provide correct information to the backend correct information to the backend authentication server while
authentication server while communicating misleading information to communicating misleading information to the EAP peer via the lower
the EAP peer via the lower layer. layer.
For example, a compromised authenticator can utilize another For example, a compromised authenticator can utilize another
authenticator's Called-Station-Id or NAS-Identifier in communicating authenticator's Called-Station-Id or NAS-Identifier in communicating
with the EAP peer via the lower layer, or for a pass-through with the EAP peer via the lower layer. Also, a pass-through
authenticator acting as a AAA client to provide an incorrect peer authenticator acting as a AAA client can provide an incorrect peer
Calling-Station-Id [RFC2865][RFC3580] to the AAA server via the AAA Calling-Station-Id [RFC2865][RFC3580] to the AAA server via the AAA
protocol. protocol.
As noted in [RFC3748] Section 7.15, this vulnerability can be As noted in [RFC3748] Section 7.15, this vulnerability can be
addressed by EAP methods that support a protected exchange of channel addressed by EAP methods that support a protected exchange of channel
properties such as endpoint identifiers, including (but not limited properties such as endpoint identifiers, including (but not limited
to): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id to): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id
[RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address [RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address
[RFC2865], and NAS-IPv6-Address [RFC3162]. [RFC2865], and NAS-IPv6-Address [RFC3162].
Using such a protected exchange, it is possible to match the channel Using such a protected exchange, it is possible to match the channel
properties provided by the authenticator via out-of-band mechanisms properties provided by the authenticator via out-of-band mechanisms
against those exchanged within the EAP method. For example, see [I- against those exchanged within the EAP method. For example, see [I-
D.arkko-eap-service-identity-auth]. D.arkko-eap-service-identity-auth].
It is also possible to achieve Channel Bindings without transporting It is also possible to achieve Channel Bindings without transporting
data over EAP. For example, see [draft-ohba-eap-aaakey-binding]. In data over EAP. For example, see [I-D.draft-ohba-eap-aaakey-binding].
this approach the authenticator informs the backend server about the In this approach the authenticator informs the backend server about
Channel Binding parameters using AAA, and the backend server the Channel Binding parameters using AAA, and the backend server
calculates transported keying material based on this parameter set, calculates transported keying material based on this parameter set,
making it impossible for the peer and authenticator to complete the making it impossible for the peer and authenticator to complete the
Secure Association Protocol if there was a mismatch in the Secure Association Protocol if there was a mismatch in the
parameters. parameters.
The main difference between these approaches is that Channel Binding The main difference between these approaches is that Channel Binding
support within an EAP method may require upgrading or changing the support within an EAP method may require upgrading or changing the
EAP method, impacting both the peer and the server. Where Channel EAP method, impacting both the peer and the server. Where Channel
Bindings are implemented in AAA, the peer, authenticator and the Bindings are implemented in AAA, the peer, authenticator and the
backend server need to be upgraded, but the EAP method need not be backend server need to be upgraded, but the EAP method need not be
modified. modified.
6. IANA Considerations 6. IANA Considerations
This document does not create any new name spaces nor does it This specification does not request the creation of any new parameter
allocate any protocol parameters. registries, nor does it require any other IANA assignments.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October
1998.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H.
Lefkowetz, "Extensible Authentication Protocol (EAP)", RFC Lefkowetz, "Extensible Authentication Protocol (EAP)", RFC
3748, June 2004. 3748, June 2004.
7.2. Informative References 7.2. Informative References
[Analysis] [Analysis] He, C. and J. Mitchell, "Analysis of the 802.11i 4-Way
He, C. and J. Mitchell, "Analysis of the 802.11i 4-Way Handshake", Proceedings of the 2004 ACM Workshop on
Handshake", Proceedings of the 2004 ACM Workshop on Wireless Wireless Security, pp. 43-50, ISBN: 1-58113-925-X.
Security, pp. 43-50, ISBN: 1-58113-925-X.
[CTP] Loughney, J., Nakhjiri, M., Perkins, C. and R. Koodli,
"Context Transfer Protocol", draft-ietf-seamoby-ctp-11.txt,
Internet draft (work in progress), August 2004.
[DESMODES] [GKDP] Dondeti, L., Xiang, J. and S. Rowles, "GKDP: Group Key
National Institute of Standards and Technology, "DES Modes of Distribution Protocol", Internet draft (work in progress),
Operation", FIPS PUB 81, December 1980, <http:// draft-ietf-msec-gkdp-01, March 2006.
www.itl.nist.gov/fipspubs/fip81.htm>.
[FIPSDES] National Institute of Standards and Technology, "Data [GSAKMP] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP:
Encryption Standard", FIPS PUB 46, January 1977. Group Secure Association Group Management Protocol",
Internet draft (work in progress), draft-ietf-msec-gsakmp-
sec-10, May 2005.
[Housley] Housley, R. and B. Aboba, "AAA Key Management", draft-housley- [He] He, C., Sundararajan, M., Datta, A. Derek, A. and J. C.
aaa-key-mgmt-01.txt, Internet draft (work in progress), Mitchell, "A Modular Correctness Proof of TLS and IEEE
November 2005. 802.11i", ACM Conference on Computer and Communications
Security (CCS '05), November, 2005.
[IEEE-802] [Housley] Housley, R. and B. Aboba, "AAA Key Management", draft-
Institute of Electrical and Electronics Engineers, "IEEE housley-aaa-key-mgmt-01.txt, Internet draft (work in
Standards for Local and Metropolitan Area Networks: Overview progress), November 2005.
and Architecture", ANSI/IEEE Standard 802, 1990.
[IEEE-802.11] [IEEE-802.11]
Institute of Electrical and Electronics Engineers, Institute of Electrical and Electronics Engineers,
"Information technology - Telecommunications and information "Information technology - Telecommunications and
exchange between systems - Local and metropolitan area information exchange between systems - Local and
networks - Specific Requirements Part 11: Wireless LAN Medium metropolitan area networks - Specific Requirements Part 11:
Access Control (MAC) and Physical Layer (PHY) Specifications", Wireless LAN Medium Access Control (MAC) and Physical Layer
IEEE IEEE Standard 802.11-2003, 2003. (PHY) Specifications", IEEE IEEE Standard 802.11-2003,
2003.
[IEEE-802.1X] [IEEE-802.1X]
Institute of Electrical and Electronics Engineers, "Local and Institute of Electrical and Electronics Engineers, "Local
Metropolitan Area Networks: Port-Based Network Access and Metropolitan Area Networks: Port-Based Network Access
Control", IEEE Standard 802.1X-2004, December 2004. Control", IEEE Standard 802.1X-2004, December 2004.
[IEEE-802.1Q] [IEEE-802.1Q]
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. [IEEE802.11i] Institute
of Electrical and Electronics Engineers, "Supplement to
[IEEE-802.11i] Standard for Telecommunications and Information Exchange
Institute of Electrical and Electronics Engineers, "Supplement Between Systems - LAN/MAN Specific Requirements - Part 11:
to STANDARD FOR Telecommunications and Information Exchange Wireless LAN Medium Access Control (MAC) and Physical Layer
between Systems - LAN/MAN Specific Requirements - Part 11: (PHY) Specifications: Specification for Enhanced Security",
Wireless Medium Access Control (MAC) and physical layer (PHY) IEEE 802.11i, July 2004.
specifications: Specification for Enhanced Security", IEEE
802.11i, December 2004.
[IEEE-802.11F] [IEEE-802.11F]
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", IEEE Distribution Systems Supporting IEEE 802.11 Operation",
802.11F, July 2003 (now deprecated). IEEE 802.11F, July 2003 (now deprecated).
[IEEE-802.16e] [IEEE-802.16e]
Institute of Electrical and Electronics Engineers, "IEEE Institute of Electrical and Electronics Engineers, "IEEE
Standard for Local and Metropolitan Area Networks: Part 16: Standard for Local and Metropolitan Area Networks: Part 16:
Air Interface for Fixed and Mobile Broadband Wireless Access Air Interface for Fixed and Mobile Broadband Wireless
Systems: Amendment for Physical and Medium Access Control Access Systems: Amendment for Physical and Medium Access
Layers for Combined Fixed and Mobile Operations in Licensed Control Layers for Combined Fixed and Mobile Operations in
Bands" IEEE 802.16e, August 2005. Licensed Bands" IEEE 802.16e, August 2005.
[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/ 3-084.zip, http://www.ieee802.org/11/Documents/DocumentHolder/
January 2003. 3-084.zip, January 2003.
[IEEE-03-155]
Aboba, B., "Fast Handoff Issues", IEEE 802.11 Working Group,
IEEE-03-155r0-I, http://www.ieee802.org/11/
Documents/DocumentHolder/3-155.zip, March 2003.
[I-D.ietf-roamops-cert]
Aboba, B., "Certificate-Based Roaming", draft-ietf-roamops-
cert-02 (work in progress), April 1999.
[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-04 (work in progress), Problem", draft-puthenkulam-eap-binding-04 (work in
October 2003. progress), October 2003.
[I-D.arkko-pppext-eap-aka]
Arkko, J. and H. Haverinen, "EAP AKA Authentication", draft-
arkko-pppext-eap-aka-15.txt (work in progress), December 2004.
[I-D.arkko-eap-service-identity-auth] [I-D.arkko-eap-service-identity-auth]
Arkko, J. and P. Eronen, "Authenticated Service Information Arkko, J. and P. Eronen, "Authenticated Service Information
for the Extensible Authentication Protocol (EAP)", draft- for the Extensible Authentication Protocol (EAP)", draft-
arkko-eap-service-identity-auth-02.txt (work in progress), May arkko-eap-service-identity-auth-02.txt (work in progress),
2005. May 2005.
[I-D.ohba-eap-aaakey-binding] [I-D.ohba-eap-aaakey-binding]
Ohba, Y., "AAA-Key Derivation with Channel Binding", draft- Ohba, Y., "AAA-Key Derivation with Channel Binding", draft-
ohba-eap-aaakey-binding-00.txt (work in progress), May 2005. ohba-eap-aaakey-binding-00.txt (work in progress), May
2005.
[MD5Attack] [I-D.irtf-aaaarch-handoff]
Dobbertin, H., "The Status of MD5 After a Recent Attack", Arbaugh, W. and B. Aboba, "Handoff Extension to RADIUS",
CryptoBytes, Vol.2 No.2, 1996. draft-irtf-aaaarch-handoff-04.txt (work in progress),
October 2003.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, [MD5Collision]
September 1981. Klima, V., "Tunnels in Hash Functions: MD5 Collisions
Within a Minute", Cryptology ePrint Archive, March 2006,
http://eprint.iacr.org/2006/105.pdf
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
1661, July 1994. RFC 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: Keyed-Hashing [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
for Message Authentication", RFC 2104, February 1997. (IKE)", RFC 2409, November 1998.
[RFC2246] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A.
and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246,
January 1999.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[RFC2419] Sklower, K. and G. Meyer, "The PPP DES Encryption Protocol,
Version 2 (DESE-bis)", RFC 2419, September 1998.
[RFC2420] Kummert, H., "The PPP Triple-DES Encryption Protocol (3DESE)",
RFC 2420, September 1998.
[RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D. and [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D.
R. Wheeler, "A Method for Transmitting PPP Over Ethernet and R. Wheeler, "A Method for Transmitting PPP Over
(PPPoE)", RFC 2516, February 1999. Ethernet (PPPoE)", RFC 2516, February 1999.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999. 2535, March 1999.
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes",
2548, March 1999. 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 Protocol", [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication
RFC 2716, October 1999. Protocol", RFC 2716, October 1999.
[RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for [RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
February 2000. February 2000.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B.
"Secret Key Transaction Authentication for DNS (TSIG)", RFC Wellington, "Secret Key Transaction Authentication for DNS
2845, May 2000. (TSIG)", RFC 2845, May 2000.
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, June Authentication Dial In User Service (RADIUS)", RFC 2865,
2000. June 2000.
[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (SIG(0)s [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
)", RFC 2931, September 2000. (SIG(0)s )", RFC 2931, September 2000.
[RFC3007] Wellington, B., "Simple Secure Domain Name System (DNS) [RFC3007] Wellington, B., "Simple Secure Domain Name System (DNS)
Dynamic Update", RFC 3007, November 2000. Dynamic Update", RFC 3007, November 2000.
[RFC3078] Pall, G. and G. Zorn, "Microsoft Point-To-Point Encryption [RFC3547] Baugher, M., Weis, B., Hardjono, T. and H. Harney, "The
(MPPE) Protocol", RFC 3078, March 2001. Group Domain of Interpretation", RFC 3547, July 2003.
[RFC3079] Zorn, G., "Deriving Keys for use with Microsoft Point-to-Point
Encryption (MPPE)", RFC 3079, March 2001.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
In User Service) Support For Extensible Authentication Dial In User Service) Support For Extensible 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 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public
Keys Used For Exchanging Symmetric Keys", RFC 3766, April Keys Used For Exchanging Symmetric Keys", RFC 3766, April
2004. 2004.
[RFC4005] Calhoun, P., Zorn, G., Spence, D. and D. Mitton, "Diameter [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M. and K.
Network Access Server Application", RFC 4005, August 2005. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004.
[RFC4017] Stanley, D., Walker, J. and B. Aboba, "EAP Method Requirements [RFC4017] Stanley, D., Walker, J. and B. Aboba, "EAP Method
for Wireless LANs", RFC 4017, March 2005. Requirements for Wireless LANs", RFC 4017, March 2005.
[RFC4046] Baugher, M., Canetti, R., Dondeti, L. and F. Lindholm, [RFC4046] Baugher, M., Canetti, R., Dondeti, L. and F. Lindholm,
"Multicast Security (MSEC) Group Key Management Architecture", "Multicast Security (MSEC) Group Key Management
RFC 4046, April 2005. Architecture", RFC 4046, April 2005.
[RFC4067] Loughney, J., Nakhjiri, M., Perkins, C. and R. Koodli,
"Context Transfer Protocol (CXTP)", RFC 4067, July 2005.
[RFC4072] Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible [RFC4072] Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application", RFC 4072, August Authentication Protocol (EAP) Application", RFC 4072,
2005. August 2005.
[RFC4118] Yang, L., Zerfos, P. and E. Sadot, "Architecture Taxonomy for [RFC4118] Yang, L., Zerfos, P. and E. Sadot, "Architecture Taxonomy
Control and Provisioning of Wireless Access Points (CAPWAP)", for Control and Provisioning of Wireless Access Points
RFC 4118, June 2005. (CAPWAP)", RFC 4118, June 2005.
[RFC4186] Haverinen, H. and J. Salowey, "Extensible Authentication
Protocol Method for Global System for Mobile Communications
(GSM) Subscriber Identity Modules (EAP-SIM)", RFC 4186,
January 2006.
[RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication
Protocol Method for 3rd Generation Authentication and Key
Agreement (EAP-AKA)", RFC 4187, January 2006.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
4306, December 2005. 4306, December 2005.
[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 University, Computer Science and Engineering, Seoul National
Seoul, Korea, 2002. University, Seoul, Korea, 2002.
Acknowledgments Acknowledgments
Thanks to Arun Ayyagari, Ashwin Palekar, and Tim Moore of Microsoft, Thanks to Arun Ayyagari, Ashwin Palekar, and Tim Moore of Microsoft,
Dorothy Stanley of Agere, Bob Moskowitz of TruSecure, Jesse Walker of Dorothy Stanley of Agere, Bob Moskowitz of TruSecure, Jesse Walker of
Intel, Joe Salowey of Cisco and Russ Housley of Vigil Security for Intel, Joe Salowey of Cisco and Russ Housley of Vigil Security for
useful feedback. useful feedback.
Author Addresses Authors' Addresses
Bernard Aboba Bernard Aboba
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
EMail: bernarda@microsoft.com EMail: bernarda@microsoft.com
Phone: +1 425 706 6605 Phone: +1 425 706 6605
Fax: +1 425 936 7329 Fax: +1 425 936 7329
skipping to change at page 54, line 16 skipping to change at page 52, line 16
This Appendix specifies Method-ID, Peer-ID, Server-ID and Key- This Appendix specifies Method-ID, Peer-ID, Server-ID and Key-
Lifetime for EAP methods that have been published prior to this Lifetime for EAP methods that have been published prior to this
specification. Future EAP method specifications MUST include a specification. Future EAP method specifications MUST include a
definition of the Method-ID, Peer-ID, and Server-ID (could be the definition of the Method-ID, Peer-ID, and Server-ID (could be the
empty string) and MAY also define the Key-Lifetime (assumed to be empty string) and MAY also define the Key-Lifetime (assumed to be
indeterminate if not described). indeterminate if not described).
EAP-Identity EAP-Identity
The EAP-Identity method does not derive keys, and therefore does The EAP-Identity method is defined in [RC3748]. It does not
not define the Key-Lifetime or Method-ID. The Peer-ID exported by derive keys, and therefore does not define the Key-Lifetime or
the Identity method is determined by the octets included within Method-ID. The Peer-ID exported by the Identity method is
the EAP- Response/Identity. The Server-ID is the empty string determined by the octets included within the EAP-
(zero length). Response/Identity. The Server-ID is the empty string (zero
length).
EAP-Notification EAP-Notification
The EAP-Notification method does not derive keys and therefore The EAP-Notification method is defined in [RFC3748]. It does not
does not define the Key-Lifetime and Method-ID. The Peer-ID and derive keys and therefore does not define the Key-Lifetime and
Server-ID are the empty string (zero length). Method-ID. The Peer-ID and Server-ID are the empty string (zero
length).
EAP-GTC EAP-GTC
The EAP-GTC method does not derive keys and therefore does not The EAP-GTC method is defined in [RFC3748]. It does not derive
define the Key-Lifetime and Method-ID. The Peer-ID and Server-ID keys and therefore does not define the Key-Lifetime and Method-ID.
are the empty string. The Peer-ID and Server-ID are the empty string.
EAP-OTP EAP-OTP
The EAP-OTP method does not derive keys and therefore does not The EAP-OTP method is defined in [RFC3748]. It does not derive
define the Key-Lifetime and Method-ID. The Peer-ID and Server-ID keys and therefore does not define the Key-Lifetime and Method-ID.
are the empty string. The Peer-ID and Server-ID are the empty string.
EAP-TLS EAP-TLS
The EAP-TLS Method-Id is the concatenation of the peer and server EAP-TLS is defined in [RFC2716]. The EAP-TLS Method-Id is the
nonces. concatenation of the peer and server nonces. The Peer-ID and
Server-ID are the contents of the altSubjectName in the peer and
The Peer-ID and Server-ID are the contents of the altSubjectName server certificates. EAP-TLS does not negotiate a Key-Lifetime.
in the peer and server certificates.
EAP-TLS does not negotiate a Key-Lifetime.
EAP-AKA EAP-AKA
The EAP-AKA Method-Id is the contents of the RAND field from the EAP-AKA is defined in [RFC4187]. The EAP-AKA Method-Id is the
AT_RAND attribute, followed by the contents of the AUTN field in contents of the RAND field from the AT_RAND attribute, followed by
the AT_AUTN attribute. the contents of the AUTN field in the AT_AUTN attribute.
The Peer-ID is the contents of the Identity field from the The Peer-ID is the contents of the Identity field from the
AT_IDENTITY attribute, using only the Actual Identity Length AT_IDENTITY attribute, using only the Actual Identity Length
octets from the beginning, however. Note that the contents are octets from the beginning, however. Note that the contents are
used as they are transmitted, regardless of whether the used as they are transmitted, regardless of whether the
transmitted identity was a permanent, pseudonym, or fast re- transmitted identity was a permanent, pseudonym, or fast re-
authentication identity. The Server-ID is an empty string. EAP- authentication identity. The Server-ID is an empty string. EAP-
AKA does not negotiate a key lifetime. AKA does not negotiate a key lifetime.
EAP-SIM EAP-SIM
The Method-Id is the contents of the RAND field from the AT_RAND EAP-SIM is defined in [RFC4186]. The EAP-SIM Method-Id is the
attribute, followed by the contents of the NONCE_MT field in the contents of the RAND field from the AT_RAND attribute, followed by
AT_NONCE_MT attribute. the contents of the NONCE_MT field in the AT_NONCE_MT attribute.
The Peer-ID is the contents of the Identity field from the The Peer-ID is the contents of the Identity field from the
AT_IDENTITY attribute, using only the Actual Identity Length AT_IDENTITY attribute, using only the Actual Identity Length
octets from the beginning, however. Note that the contents are octets from the beginning, however. Note that the contents are
used as they are transmitted, regardless of whether the used as they are transmitted, regardless of whether the
transmitted identity was a permanent, pseudonym, or fast re- transmitted identity was a permanent, pseudonym, or fast re-
authentication identity. The Server-ID is an empty string. EAP- authentication identity. The Server-ID is an empty string. EAP-
SIM does not negotiate a key lifetime. SIM does not negotiate a key lifetime.
Intellectual Property Statement Intellectual Property Statement
 End of changes. 173 change blocks. 
866 lines changed or deleted 762 lines changed or added

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