draft-ietf-eap-keying-22.txt   rfc5247.txt 
EAP Working Group Bernard Aboba Network Working Group B. Aboba
Internet Draft Dan Simon Request for Comments: 5247 D. Simon
Updates: 3748 Microsoft Corporation Updates: 3748 Microsoft Corporation
Category: Standards Track P. Eronen Category: Standards Track P. Eronen
Expires: May 11, 2008 Nokia Nokia
11 November 2007 August 2008
Extensible Authentication Protocol (EAP) Key Management Framework Extensible Authentication Protocol (EAP) Key Management Framework
draft-ietf-eap-keying-22.txt
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Status of This Memo
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 11, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007). All rights reserved. This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract Abstract
The Extensible Authentication Protocol (EAP), defined in RFC 3748, The Extensible Authentication Protocol (EAP), defined in RFC 3748,
enables extensible network access authentication. This document enables extensible network access authentication. This document
specifies the EAP key hierarchy and provides a framework for the specifies the EAP key hierarchy and provides a framework for the
transport and usage of keying material and parameters generated by transport and usage of keying material and parameters generated by
EAP authentication algorithms, known as "methods". It also provides EAP authentication algorithms, known as "methods". It also provides
a detailed system-level security analysis, describing the conditions a detailed system-level security analysis, describing the conditions
under which the key management guidelines described in RFC 4962 can under which the key management guidelines described in RFC 4962 can
be satisfied. be satisfied.
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 ........................................ 7 1.3. Overview ...................................................7
1.4 EAP Key Hierarchy ............................... 9 1.4. EAP Key Hierarchy .........................................10
1.5 Security Goals .................................. 13 1.5. Security Goals ............................................15
1.6 EAP Invariants .................................. 14 1.6. EAP Invariants ............................................16
2. Lower Layer Operation ................................. 18 2. Lower-Layer Operation ..........................................20
2.1 Transient Session Keys .......................... 19 2.1. Transient Session Keys ....................................20
2.2 Authenticator and Peer Architecture ............. 20 2.2. Authenticator and Peer Architecture .......................22
2.3 Authenticator Identification ..................... 21 2.3. Authenticator Identification ..............................23
2.4 Peer Identification ............................. 25 2.4. Peer Identification .......................................27
2.5 Server Identification ........................... 26 2.5. Server Identification .....................................29
3. Security Association Management ....................... 28 3. Security Association Management ................................31
3.1 Secure Association Protocol ..................... 29 3.1. Secure Association Protocol ...............................32
3.2 Key Scope ....................................... 32 3.2. Key Scope .................................................35
3.3 Parent-Child Relationships ...................... 33 3.3. Parent-Child Relationships ................................35
3.4 Local Key Lifetimes ............................. 34 3.4. Local Key Lifetimes .......................................37
3.5 Exported and Calculated Key Lifetimes ........... 34 3.5. Exported and Calculated Key Lifetimes .....................37
3.6 Key Cache Synchronization ....................... 37 3.6. Key Cache Synchronization .................................40
3.7 Key Strength .................................... 37 3.7. Key Strength ..............................................40
3.8 Key Wrap ........................................ 37 3.8. Key Wrap ..................................................41
4. Handoff Vulnerabilities ............................... 38 4. Handoff Vulnerabilities ........................................41
4.1 EAP Pre-authentication .......................... 39 4.1. EAP Pre-Authentication ....................................43
4.2 Proactive Key Distribution ...................... 41 4.2. Proactive Key Distribution ................................44
4.3 AAA Bypass ...................................... 42 4.3. AAA Bypass ................................................46
5. Security Considerations .............................. 46 5. Security Considerations ........................................50
5.1 Peer and Authenticator Compromise ............... 47 5.1. Peer and Authenticator Compromise .........................51
5.2 Cryptographic Negotiation ....................... 49 5.2. Cryptographic Negotiation .................................53
5.3 Confidentiality and Authentication .............. 50 5.3. Confidentiality and Authentication ........................54
5.4 Key Binding ..................................... 56 5.4. Key Binding ...............................................59
5.5 Authorization ................................... 57 5.5. Authorization .............................................60
5.6 Replay Protection ............................... 59 5.6. Replay Protection .........................................63
5.7 Key Freshness ................................... 59 5.7. Key Freshness .............................................64
5.8 Key Scope Limitation ............................ 61 5.8. Key Scope Limitation ......................................66
5.9 Key Naming ...................................... 62 5.9. Key Naming ................................................66
5.10 Denial of Service Attacks ....................... 63 5.10. Denial-of-Service Attacks ................................67
6. IANA Considerations ................................... 63 6. References .....................................................68
7. References ............................................ 63 6.1. Normative References ......................................68
7.1 Normative References ............................ 63 6.2. Informative References ....................................68
7.2 Informative References .......................... 64 Acknowledgments ...................................................74
Acknowledgments .............................................. 69 Appendix A - Exported Parameters in Existing Methods ..............75
Author's Addresses ........................................... 70
Appendix A - Exported Parameters in Existing Methods ......... 71
Full Copyright Statement ..................................... 73
Intellectual Property ........................................ 73
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 Internet Protocol (IP) protocol is not in situations in which the Internet Protocol (IP) protocol is not
available. Originally developed for use with Point-to-Point Protocol available. Originally developed for use with Point-to-Point Protocol
(PPP) [RFC1661], it has subsequently also been applied to IEEE 802 (PPP) [RFC1661], it has subsequently also been applied to IEEE 802
wired networks [IEEE-802.1X], IKEv2 [RFC4306] and wireless networks wired networks [IEEE-802.1X], Internet Key Exchange Protocol version
such as [IEEE-802.11] and [IEEE-802.16e]. 2 (IKEv2) [RFC4306], and wireless networks such as [IEEE-802.11] and
[IEEE-802.16e].
EAP is a two-party protocol spoken between the EAP peer and server. EAP is a two-party protocol spoken between the EAP peer and server.
Within EAP, keying material is generated by EAP authentication Within EAP, keying material is generated by EAP authentication
algorithms, known as "methods". Part of this keying material can be algorithms, known as "methods". Part of this keying material can be
used by EAP methods themselves and part of this material can be used by EAP methods themselves, and part of this material can be
exported. In addition to export of keying material, EAP methods can exported. In addition to the export of keying material, EAP methods
also export associated parameters such as authenticated peer and can also export associated parameters such as authenticated peer and
server identities and a unique EAP conversation identifier, and can server identities and a unique EAP conversation identifier, and can
import and export lower layer parameters known as "channel binding import and export lower-layer parameters known as "channel binding
parameters", or simply "channel bindings". parameters", or simply "channel bindings".
This document specifies the EAP key hierarchy and provides a This document specifies the EAP key hierarchy and provides a
framework for the transport and usage of keying material and framework for the transport and usage of keying material and
parameters generated by EAP methods. It also provides a detailed parameters generated by EAP methods. It also provides a detailed
security analysis, describing the conditions under which the security analysis, describing the conditions under which the
requirements described in "Guidance for Authentication, Authorization requirements described in "Guidance for Authentication,
and Accounting (AAA) Key Management" [RFC4962] can be satisfied. Authorization, and Accounting (AAA) Key Management" [RFC4962] can be
satisfied.
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 [RFC2119]. document are to be interpreted as described in [RFC2119].
1.2. Terminology 1.2. Terminology
The terms "Cryptographic binding", "Cryptographic separation", "Key The terms "Cryptographic binding", "Cryptographic separation", "Key
strength" and "Mutual authentication" are defined in [RFC3748] and strength" and "Mutual authentication" are defined in [RFC3748] and
are used with the same meaning in this document, which also are used with the same meaning in this document, which also
frequently uses the following terms: frequently uses the following terms:
4-Way Handshake 4-Way Handshake
A pairwise Authentication and Key Management Protocol (AKMP) A pairwise Authentication and Key Management Protocol (AKMP)
defined in [IEEE-802.11], which confirms mutual possession of a defined in [IEEE-802.11], which confirms mutual possession of a
Pairwise Master Key by two parties and distributes a Group Key. Pairwise Master Key by two parties and distributes a Group Key.
AAA Authentication, Authorization and Accounting. AAA protocols with AAA Authentication, Authorization, and Accounting
EAP support include RADIUS [RFC3579] and Diameter [RFC4072]. In AAA protocols with EAP support include "RADIUS Support for EAP"
this document, the terms "AAA server" and "backend authentication [RFC3579] and "Diameter EAP Application" [RFC4072]. In this
document, the terms "AAA server" and "backend authentication
server" are used interchangeably. server" are used interchangeably.
AAA-Key AAA-Key
The term AAA-Key is synonymous with Master Session Key (MSK). The term AAA-Key is synonymous with Master Session Key (MSK).
Since multiple keys can be transported by AAA, the term is Since multiple keys can be transported by AAA, the term is
potentially confusing and is not used in this document. potentially confusing and is not used in this document.
authenticator Authenticator
The entity initiating EAP authentication. The entity initiating EAP authentication.
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
typically executes EAP methods for the authenticator. This server typically executes EAP methods for the authenticator. This
terminology is also used in [IEEE-802.1X]. terminology is also used in [IEEE-802.1X].
Channel Binding Channel Binding
A secure mechanism for ensuring that a subset of the parameters A secure mechanism for ensuring that a subset of the parameters
transmitted by the authenticator (such as authenticator identifiers transmitted by the authenticator (such as authenticator
and properties) are agreed upon by the EAP peer and server. It is identifiers and properties) are agreed upon by the EAP peer and
expected that the parameters are also securely agreed upon by the server. It is expected that the parameters are also securely
EAP peer and authenticator via the lower layer if the authenticator agreed upon by the EAP peer and authenticator via the lower layer
advertised the parameters. if the authenticator advertised the parameters.
Derived Keying Material Derived Keying Material
Keys derived from EAP keying material, such as Transient Session Keys derived from EAP keying material, such as Transient Session
Keys (TSKs). Keys (TSKs).
EAP Keying Material EAP Keying Material
Keys derived by an EAP method; this includes exported keying Keys derived by an EAP method; this includes exported keying
material (MSK, EMSK, IV) as well as local keying material such as material (MSK, Extended MSK (EMSK), Initialization Vector (IV)) as
Transient EAP Keys (TEKs). well as local keying material such as Transient EAP Keys (TEKs).
EAP pre-authentication EAP Pre-Authentication
The use of EAP to pre-establish EAP keying material on an The use of EAP to pre-establish EAP keying material on an
authenticator prior to arrival of the peer at the access network authenticator prior to arrival of the peer at the access network
managed by that authenticator. managed by that authenticator.
EAP re-authentication EAP Re-Authentication
EAP authentication between an EAP peer and a server with whom the EAP authentication between an EAP peer and a server with whom the
EAP peer shares valid unexpired EAP keying material. EAP peer shares valid unexpired EAP keying material.
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
authenticator operates in pass-through mode, the EAP server is the authenticator operates in pass-through mode, the EAP server is
located on the backend authentication server. located on the backend authentication server.
Exported keying material Exported Keying Material
The EAP Master Session Key (MSK), Extended Master Session Key The EAP Master Session Key (MSK), Extended Master Session Key
(EMSK), and Initialization Vector (IV). (EMSK), and Initialization Vector (IV).
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
is exported by the EAP method. The EMSK is at least 64 octets in that is exported by the EAP method. The EMSK is at least 64
length, and is never shared with a third party. The EMSK MUST be octets in length and is never shared with a third party. The EMSK
at least as long as the MSK in size. MUST be at least as long as the MSK in size.
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
TLS [I-D.simon-emu-rfc2716bis], it cannot be used by itself for EAP-TLS (Transport Layer Security) [RFC5216], it cannot be used by
computation of any quantity that needs to remain secret. As a itself for computation of any quantity that needs to remain
result, its use has been deprecated and it is OPTIONAL for EAP secret. As a result, its use has been deprecated and it is
methods to generate it. However, when it is generated it MUST be OPTIONAL for EAP methods to generate it. However, when it is
unpredictable. generated, it MUST be unpredictable.
Keying Material Keying Material
Unless otherwise qualified, the term "keying material" refers to Unless otherwise qualified, the term "keying material" refers to
EAP keying material as well as derived keying material. EAP keying material as well as derived keying material.
Key Scope Key Scope
The parties to whom a key is available. The parties to whom a key is available.
Key Wrap Key Wrap
The encryption of one symmetric cryptographic key in another. The The encryption of one symmetric cryptographic key in another. The
algorithm used for the encryption is called a key wrap algorithm or algorithm used for the encryption is called a key wrap algorithm
a key encryption algorithm. The key used in the encryption process or a key encryption algorithm. The key used in the encryption
is called a key-encryption key (KEK). process is called a key-encryption key (KEK).
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
based method, the long term credential is the corresponding private public-key-based method, the long-term credential is the
key. corresponding private key.
Lower Layer Lower Layer
The lower layer is responsible for carrying EAP frames between the The lower layer is responsible for carrying EAP frames between the
peer and authenticator. peer and authenticator.
Lower Layer Identity Lower-Layer Identity
A name used to identify the EAP peer and authenticator within the A name used to identify the EAP peer and authenticator within the
lower layer. lower layer.
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
exported by the EAP method. The MSK is at least 64 octets in and exported by the EAP method. The MSK is at least 64 octets in
length. length.
Network Access Server (NAS) Network Access Server (NAS)
A device that provides an access service for a user to a network. A device that provides an access service for a user to a network.
Pairwise Master Key (PMK) Pairwise Master Key (PMK)
Lower layers use the MSK in lower-layer dependent manner. For Lower layers use the MSK in a lower-layer dependent manner. For
instance, in IEEE 802.11 [IEEE-802.11] Octets 0-31 of the MSK are instance, in IEEE 802.11 [IEEE-802.11], Octets 0-31 of the MSK are
known as the Pairwise Master Key (PMK); the TKIP and AES CCMP known as the Pairwise Master Key (PMK); the Temporal Key Integrity
ciphersuites derive their Transient Session Keys (TSKs) solely from Protocol (TKIP) and Advanced Encryption Standard Counter Mode with
the PMK, whereas the WEP ciphersuite as noted in [RFC3580], derives CBC-MAC Protocol (AES CCMP) ciphersuites derive their Transient
its TSKs from both halves of the MSK. In [802.16e], the MSK is Session Keys (TSKs) solely from the PMK, whereas the Wired
truncated to 20 octets for PMK and 20 octets for PMK2. Equivalent Privacy (WEP) ciphersuite, as noted in "IEEE 802.1X
RADIUS Usage Guidelines" [RFC3580], derives its TSKs from both
halves of the MSK. In [IEEE-802.16e], the MSK is truncated to 20
octets for PMK and 20 octets for PMK2.
peer The entity that responds to the authenticator. In [IEEE-802.1X], Peer
The entity that responds to the authenticator. In [IEEE-802.1X],
this entity is known as the Supplicant. this entity is known as the Supplicant.
security association Security Association
A set of policies and cryptographic state used to protect A set of policies and cryptographic state used to protect
information. Elements of a security association include information. Elements of a security association include
cryptographic keys, negotiated ciphersuites and other parameters, cryptographic keys, negotiated ciphersuites and other parameters,
counters, sequence spaces, authorization attributes, etc. counters, sequence spaces, authorization attributes, etc.
Secure Association Protocol Secure Association Protocol
An exchange that occurs between the EAP peer and authenticator in An exchange that occurs between the EAP peer and authenticator in
order to manage security associations derived from EAP exchanges. order to manage security associations derived from EAP exchanges.
The protocol establishes unicast and (optionally) multicast The protocol establishes unicast and (optionally) multicast
security associations, which include symmetric keys and a context security associations, which include symmetric keys and a context
for the use of the keys. An example of a Secure Association for the use of the keys. An example of a Secure Association
Protocol is the 4-way handshake defined within [IEEE-802.11]. Protocol is the 4-way handshake defined within [IEEE-802.11].
Session-Id Session-Id
The EAP Session-Id uniquely identifies an EAP authentication The EAP Session-Id uniquely identifies an EAP authentication
exchange between an EAP peer (as identified by the Peer-Id(s)) and exchange between an EAP peer (as identified by the Peer-Id(s)) and
server (as identified by the Server-Id(s)). For more information, server (as identified by the Server-Id(s)). For more information,
see Section 1.4. see Section 1.4.
Transient EAP Keys (TEKs) Transient EAP Keys (TEKs)
Session keys which are used to establish a protected channel Session keys that 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
protected channel between the EAP peer and server during EAP the 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
protect data sent between the EAP peer and authenticator. subsequently protect data sent between the EAP peer and
authenticator.
Transient Session Keys (TSKs) Transient Session Keys (TSKs)
Keys used to protect data exchanged after EAP authentication has Keys used to protect data exchanged after EAP authentication has
successfully completed, using the ciphersuite negotiated between successfully completed using the ciphersuite negotiated between
the EAP peer and authenticator. the EAP peer and authenticator.
1.3. Overview 1.3. Overview
Where EAP key derivation is supported, the conversation typically Where EAP key derivation is supported, the conversation typically
takes place in three phases: takes place in three phases:
Phase 0: Discovery Phase 0: Discovery
Phase 1: Authentication Phase 1: Authentication
1a: EAP authentication 1a: EAP authentication
1b: AAA Key Transport (optional) 1b: AAA Key Transport (optional)
Phase 2: Secure Association Protocol Phase 2: Secure Association Protocol
2a: Unicast Secure Association 2a: Unicast Secure Association
2b: Multicast Secure Association (optional) 2b: Multicast Secure Association (optional)
Of these phases, Phase 0, 1b and Phase 2 are handled external to EAP. Of these phases, phase 0, 1b, and 2 are handled external to EAP.
Phases 0 and 2 are handled by the lower layer protocol and phase 1b phases 0 and 2 are handled by the lower-layer protocol, and phase 1b
is typically handled by a AAA protocol. is typically handled by a AAA protocol.
In the discovery phase (phase 0), peers locate authenticators and In the discovery phase (phase 0), peers locate authenticators and
discover their capabilities. A peer can locate an authenticator discover their capabilities. A peer can locate an authenticator
providing access to a particular network, or a peer can locate an providing access to a particular network, or a peer can locate an
authenticator behind a bridge with which it desires to establish a authenticator behind a bridge with which it desires to establish a
Secure Association. Discovery can occur manually or automatically, Secure Association. Discovery can occur manually or automatically,
depending on the lower layer over which EAP runs. depending on the lower layer over which EAP runs.
The authentication phase (phase 1) can begin once the peer and The authentication phase (phase 1) can begin once the peer and
authenticator discover each other. This phase, if it occurs, always authenticator discover each other. This phase, if it occurs, always
includes EAP authentication (phase 1a). Where the chosen EAP method includes EAP authentication (phase 1a). Where the chosen EAP method
supports key derivation, in phase 1a EAP keying material is derived supports key derivation, in phase 1a, EAP keying material is derived
on both the peer and the EAP server. on both the peer and the EAP server.
An additional step (phase 1b) is needed in deployments which include An additional step (phase 1b) is needed in deployments that include a
a backend authentication server, in order to transport keying backend authentication server, in order to transport keying material
material from the backend authentication server to the authenticator. from the backend authentication server to the authenticator. In
In order to obey the principle of mode independence (see Section order to obey the principle of mode independence (see Section 1.6.1),
1.6.1), where a backend server is present, all keying material needed where a backend authentication server is present, all keying material
by the lower layer is transported from the EAP server to the needed by the lower layer is transported from the EAP server to the
authenticator. Since existing TSK derivation and transport authenticator. Since existing TSK derivation and transport
techniques depend solely on the MSK, in existing implementations, techniques depend solely on the MSK, in existing implementations,
this is the only keying material replicated in the AAA key transport this is the only keying material replicated in the AAA key transport
phase 1b. phase 1b.
Successful completion of EAP authentication and key derivation by a Successful completion of EAP authentication and key derivation by a
peer and EAP server does not necessarily imply that the peer is peer and EAP server does not necessarily imply that the peer is
committed to joining the network associated with an EAP server. committed to joining the network associated with an EAP server.
Rather, this commitment is implied by the creation of a security Rather, this commitment is implied by the creation of a security
association between the EAP peer and authenticator, as part of the association between the EAP peer and authenticator, as part of the
skipping to change at page 8, line 35 skipping to change at page 9, line 4
| | AAA Key transport | | | AAA Key transport |
| | (optional; phase 1b) | | | (optional; phase 1b) |
|<----------------------------->| | |<----------------------------->| |
| Unicast Secure association | | | Unicast Secure association | |
| (phase 2a) | | | (phase 2a) | |
| | | | | |
|<----------------------------->| | |<----------------------------->| |
| Multicast Secure association | | | Multicast Secure association | |
| (optional; phase 2b) | | | (optional; phase 2b) | |
| | | | | |
Figure 1: Conversation Overview Figure 1: Conversation Overview
1.3.1. Examples 1.3.1. Examples
Existing EAP lower layers implement phase 0, 2a and 2b in different Existing EAP lower layers implement phase 0, 2a, and 2b in different
ways: ways:
PPP The Point-to-Point Protocol (PPP), defined in [RFC1661] does not PPP
The Point-to-Point Protocol (PPP), defined in [RFC1661], does not
support discovery, nor does it include a Secure Association support discovery, nor does it include a Secure Association
Protocol. Protocol.
PPPoE PPPoE
PPP over Ethernet (PPPoE), defined in [RFC2516], includes support PPP over Ethernet (PPPoE), defined in [RFC2516], includes support
for a Discovery stage (phase 0). In this step, the EAP peer sends for a Discovery stage (phase 0). In this step, the EAP peer sends
a PPPoE Active Discovery Initiation (PADI) packet to the broadcast a PPPoE Active Discovery Initiation (PADI) packet to the broadcast
address, indicating the service it is requesting. The Access address, indicating the service it is requesting. The Access
Concentrator replies with a PPPoE Active Discovery Offer (PADO) Concentrator replies with a PPPoE Active Discovery Offer (PADO)
packet containing its name, the service name and an indication of packet containing its name, the service name, and an indication of
the services offered by the concentrator. The discovery phase is the services offered by the concentrator. The discovery phase is
not secured. PPPoE, like PPP, does not include a Secure not secured. PPPoE, like PPP, does not include a Secure
Association Protocol. Association Protocol.
IKEv2 IKEv2
Internet Key Exchange v2 (IKEv2), defined in [RFC4306], includes Internet Key Exchange v2 (IKEv2), defined in [RFC4306], includes
support for EAP and handles the establishment of unicast security support for EAP and handles the establishment of unicast security
associations (phase 2a). However, the establishment of multicast associations (phase 2a). However, the establishment of multicast
security associations (phase 2b) typically does not involve EAP and security associations (phase 2b) typically does not involve EAP
needs to be handled by a group key management protocol such as GDOI and needs to be handled by a group key management protocol such as
[RFC3547], GSAKMP [RFC4535], MIKEY [RFC3830], or GKDP [GKDP]. Group Domain of Interpretation (GDOI) [RFC3547], Group Secure
Several mechanisms have been proposed for discovery of IPsec Association Key Management Protocol (GSAKMP) [RFC4535], Multimedia
security gateways. [RFC2230] discusses the use of Key eXchange Internet KEYing (MIKEY) [RFC3830], or Group Key Distribution
(KX) Resource Records (RRs) for IPsec gateway discovery; while KX Protocol (GKDP) [GKDP]. Several mechanisms have been proposed for
RRs are supported by many Domain Name Service (DNS) server the discovery of IPsec security gateways. [RFC2230] discusses the
implementations, they have not yet been widely deployed. use of Key eXchange (KX) Resource Records (RRs) for IPsec gateway
Alternatively, DNS SRV RRs [RFC2782] can be used for this purpose. discovery; while KX RRs are supported by many Domain Name Service
Where DNS is used for gateway location, DNS security mechanisms (DNS) server implementations, they have not yet been widely
such as DNSSEC ([RFC4033], [RFC4035]), TSIG [RFC2845], and Simple deployed. Alternatively, DNS SRV RRs [RFC2782] can be used for
Secure Dynamic Update [RFC3007] are available. this purpose. Where DNS is used for gateway location, DNS
security mechanisms such as DNS Security (DNSSEC) ([RFC4033],
[RFC4035]), TSIG [RFC2845], and Simple Secure Dynamic Update
[RFC3007] are available.
IEEE 802.11 IEEE 802.11
IEEE 802.11, defined in [IEEE-802.11], handles discovery via the IEEE 802.11, defined in [IEEE-802.11], handles discovery via the
Beacon and Probe Request/Response mechanisms. IEEE 802.11 access Beacon and Probe Request/Response mechanisms. IEEE 802.11 Access
points periodically announce their Service Set Identifiers (SSIDs) Points (APs) periodically announce their Service Set Identifiers
as well as capabilities using Beacon frames. Stations can query (SSIDs) as well as capabilities using Beacon frames. Stations can
for access points by sending a Probe Request to the broadcast query for APs by sending a Probe Request. Neither Beacon nor
address. Neither Beacon nor Probe Request/Response frames are Probe Request/Response frames are secured. The 4-way handshake
secured. The 4-way handshake defined in [IEEE-802.11] enables the defined in [IEEE-802.11] enables the derivation of unicast (phase
derivation of unicast (phase 2a) and multicast/broadcast (phase 2b) 2a) and multicast/broadcast (phase 2b) secure associations. Since
secure associations. Since the group key exchange transports a the group key exchange transports a group key from the AP to the
group key from the access point to the station, two 4-way station, two 4-way handshakes can be needed in order to support
handshakes can be needed in order to support peer-to-peer peer-to-peer communications. A proof of the security of the IEEE
communications. A proof of the security of the IEEE 802.11 4-way 802.11 4-way handshake, when used with EAP-TLS, is provided in
handshake when used with EAP-TLS is provided in [He]. [He].
IEEE 802.1X IEEE 802.1X
IEEE 802.1X-2004, defined in [IEEE-802.1X] does not support IEEE 802.1X-2004, defined in [IEEE-802.1X], does not support
discovery (phase 0), nor does it provide for derivation of unicast discovery (phase 0), nor does it provide for derivation of unicast
or multicast secure associations. or multicast secure associations.
1.4. EAP Key Hierarchy 1.4. EAP Key Hierarchy
As illustrated in Figure 2, 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 additional information. This stores the peer's identity as well as additional information. This
information is typically used outside of the EAP method to determine information is typically used outside of the EAP method to determine
whether to grant access to a service. The peer stores information whether to grant access to a service. The peer stores information
necessary to choose which secret to use for which service. necessary 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
parties store the EAP method to be used and the trust anchors used to parties store the EAP method to be used and the trust anchors used to
validate the certificates. The EAP server also stores the peer's validate the certificates. The EAP server also stores the peer's
identity and the peer stores information necessary to choose which identity, and the peer stores information necessary to choose which
certificate to use for which service. Based on the long term certificate to use for which service. Based on the long-term
credential established between the peer and the server, methods credential established between the peer and the server, methods
derive two types of EAP keying material: derive two types of EAP keying material:
(a) Keying material calculated locally by the EAP method (a) Keying material calculated locally by the EAP method but not
but not exported, such as the Transient EAP Keys (TEKs). exported, such as the Transient EAP Keys (TEKs).
(b) Keying material exported by the EAP method: Master Session Key (b) Keying material exported by the EAP method: Master Session Key
(MSK), Extended Master Session Key (EMSK), Initialization (MSK), Extended Master Session Key (EMSK), Initialization
Vector (IV). Vector (IV).
As noted in [RFC3748] Section 7.10: As noted in [RFC3748] Section 7.10:
In order to provide keying material for use in a subsequently In order to provide keying material for use in a subsequently
negotiated ciphersuite, an EAP method supporting key derivation negotiated ciphersuite, an EAP method supporting key derivation
MUST export a Master Session Key (MSK) of at least 64 octets, and MUST export a Master Session Key (MSK) of at least 64 octets, and
an Extended Master Session Key (EMSK) of at least 64 octets. an Extended Master Session Key (EMSK) of at least 64 octets.
skipping to change at page 10, line 45 skipping to change at page 11, line 19
computed without breaking some cryptographic assumption, such as computed without breaking some cryptographic assumption, such as
inverting a one-way function. inverting a one-way function.
EAP methods supporting key derivation and mutual authentication EAP methods supporting key derivation and mutual authentication
SHOULD export a method-specific EAP conversation identifier known as SHOULD export a method-specific EAP conversation identifier known as
the Session-Id, as well as one or more method-specific peer the Session-Id, as well as one or more method-specific peer
identifiers (Peer-Id(s)) and MAY export one or more method-specific identifiers (Peer-Id(s)) and MAY export one or more method-specific
server identifiers (Server-Id(s)). EAP methods MAY also support the server identifiers (Server-Id(s)). EAP methods MAY also support the
import and export of channel binding parameters. EAP method import and export of channel binding parameters. EAP method
specifications developed after the publication of this document MUST specifications developed after the publication of this document MUST
define the Peer-Id, Server-Id and Session-Id. The Peer-Id(s) and define the Peer-Id, Server-Id, and Session-Id. The Peer-Id(s) and
Server-Id(s), when provided, identify the entities involved in Server-Id(s), when provided, identify the entities involved in
generating EAP keying material. For existing EAP methods the Peer-Id, generating EAP keying material. For existing EAP methods, the
Server-Id and Session-Id are defined in Appendix A. Peer-Id, Server-Id, and Session-Id are defined in Appendix A.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | ^ | | ^
| EAP Method | | | EAP Method | |
| | | | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | |
| | | | | | | | | | | | | |
| | EAP Method Key |<->| Long-Term | | | | | EAP Method Key |<->| Long-Term | | |
| | Derivation | | Credential | | | | | Derivation | | Credential | | |
| | | | | | | | | | | | | |
skipping to change at page 12, line 22 skipping to change at page 13, line 25
Server-Id, the EAP peer will not authenticate the identity of the Server-Id, the EAP peer will not authenticate the identity of the
EAP server with which it derived EAP keying material. EAP server with which it derived EAP keying material.
Session-Id Session-Id
The Session-Id uniquely identifies an EAP session between an EAP The Session-Id uniquely identifies an EAP session between an EAP
peer (as identified by the Peer-Id) and server (as identified by peer (as identified by the Peer-Id) and server (as identified by
the Server-Id). Where non-expanded EAP Type Codes are used (EAP the Server-Id). Where non-expanded EAP Type Codes are used (EAP
Type Code not equal to 254), the EAP Session-Id is the Type Code not equal to 254), the EAP Session-Id is the
concatenation of the single octet EAP Type Code and a temporally concatenation of the single octet EAP Type Code and a temporally
unique identifier obtained from the method (known as the Method- unique identifier obtained from the method (known as the
Id). Where expanded EAP Type Codes are used, the EAP Session-Id Method-Id):
Session-Id = Type-Code || Method-Id
Where expanded EAP Type Codes are used, the EAP Session-Id
consists of the Expanded Type Code (including the Type, Vendor-Id consists of the Expanded Type Code (including the Type, Vendor-Id
and Vendor-Type fields defined in [RFC3748] Section 5.7) (in network byte order) and Vendor-Type fields (in network byte
concatenated with a temporally unique identifier obtained from the order) defined in [RFC3748] Section 5.7), concatenated with a
method (Method-Id). The Method-Id is typically constructed from temporally unique identifier obtained from the method (Method-Id):
nonces or counters used within the EAP method exchange. The
inclusion of the Type Code or Expanded Type Code in the EAP Session-Id = 0xFE || Vendor-Id || Vendor-Type || Method-Id
Session-Id ensures that each EAP method has a distinct Session-Id
space. Since an EAP session is not bound to a particular The Method-Id is typically constructed from nonces or counters
authenticator or specific ports on the peer and authenticator, the used within the EAP method exchange. The inclusion of the Type
authenticator port or identity are not included in the Session-Id. Code or Expanded Type Code in the EAP Session-Id ensures that each
EAP method has a distinct Session-Id space. Since an EAP session
is not bound to a particular authenticator or specific ports on
the peer and authenticator, the authenticator port or identity are
not included in the Session-Id.
Channel Binding Channel Binding
Channel Binding is the process by which lower layer parameters are Channel binding is the process by which lower-layer parameters are
verified for consistency between the EAP peer and server. In verified for consistency between the EAP peer and server. In
order to avoid introducing media dependencies, EAP methods that order to avoid introducing media dependencies, EAP methods that
transport channel binding parameters MUST treat this data as transport channel binding parameters MUST treat this data as
opaque octets. See Section 5.3.3 for further discussion. opaque octets. See Section 5.3.3 for further discussion.
1.4.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 keying material and TEKs is key is available). The scope of exported keying material and TEKs is
defined by the authenticated method-specific peer identities (Peer- defined by the authenticated method-specific peer identities
Id(s)) and the authenticated server identities (Server-Id(s)), where (Peer-Id(s)) and the authenticated server identities (Server-Id(s)),
available. where available.
MSK and EMSK Names MSK and EMSK Names
The MSK and EMSK are exported by the EAP peer and EAP server, and The MSK and EMSK are exported by the EAP peer and EAP server,
MUST be named using the EAP Session-Id and a binary or textual and MUST be named using the EAP Session-Id and a binary or
indication of the EAP keying material being referred to. textual indication of the EAP keying material being referred to.
PMK Name PMK Name
This document does not specify a naming scheme for the Pairwise This document does not specify a naming scheme for the Pairwise
Master Key (PMK). The PMK is only identified by the name of the Master Key (PMK). The PMK is only identified by the name of the
key from which it is derived. key from which it is derived.
Note: IEEE 802.11 names the PMK for the purposes of being able to Note: IEEE 802.11 names the PMK for the purposes of being able
refer to it in the Secure Association Protocol; the PMK name (known to refer to it in the Secure Association Protocol; the PMK name
as the PMKID) is based on a hash of the PMK itself as well as some (known as the PMKID) is based on a hash of the PMK itself as
other parameters (see [IEEE-802.11] Section 8.5.1.2). well as some other parameters (see [IEEE-802.11] Section
8.5.1.2).
TEK Name TEK Name
Transient EAP Keys (TEKs) MAY be named; their naming is specified Transient EAP Keys (TEKs) MAY be named; their naming is
in the EAP method specification. specified in the EAP method specification.
TSK Name TSK Name
Transient Session Keys (TSKs) are typically named. Their naming is Transient Session Keys (TSKs) are typically named. Their naming
specified in the lower layer so that the correct set of TSKs can be is specified in the lower layer so that the correct set of TSKs
identified for processing a given packet. can be identified for processing a given packet.
1.5. Security Goals 1.5. Security Goals
The goal of the EAP conversation is to derive fresh session keys The goal of the EAP conversation is to derive fresh session keys
between the EAP peer and authenticator that are known only to those between the EAP peer and authenticator that are known only to those
parties, and for both the EAP peer and authenticator to demonstrate parties, and for both the EAP peer and authenticator to demonstrate
that they are authorized to perform their roles either by each other that they are authorized to perform their roles either by each other
or by a trusted third party (the backend authentication server). or by a trusted third party (the backend authentication server).
Completion of an EAP method exchange (Phase 1a) supporting key Completion of an EAP method exchange (phase 1a) supporting key
derivation results in the derivation of EAP keying material (MSK, derivation results in the derivation of EAP keying material (MSK,
EMSK, TEKs) known only to the EAP peer (identified by the Peer-Id(s)) EMSK, TEKs) known only to the EAP peer (identified by the Peer-Id(s))
and EAP server (identified by the Server-Id(s)). Both the EAP peer and EAP server (identified by the Server-Id(s)). Both the EAP peer
and EAP server know this keying material to be fresh. The Peer-Id and EAP server know this keying material to be fresh. The Peer-Id
and Server-Id are discussed in Sections 1.4, 2.4 and 2.5 as well as and Server-Id are discussed in Sections 1.4, 2.4, and 2.5 as well as
in Appendix A. Key freshness is discussed in Sections 3.4, 3.5 and in Appendix A. Key freshness is discussed in Sections 3.4, 3.5, and
5.7. 5.7.
Completion of the AAA exchange (Phase 1b) results in the transport of Completion of the AAA exchange (phase 1b) results in the transport of
keying material from the EAP server (identified by the Server-Id(s)) keying material from the EAP server (identified by the Server-Id(s))
to the EAP authenticator (identified by the NAS-Identifier) without to the EAP authenticator (identified by the NAS-Identifier) without
disclosure to any other party. Both the EAP server and EAP disclosure to any other party. Both the EAP server and EAP
authenticator know this keying material to be fresh. Disclosure authenticator know this keying material to be fresh. Disclosure
issues are discussed in Sections 3.8 and 5.3; security properties of issues are discussed in Sections 3.8 and 5.3; security properties of
AAA protocols are discussed in Sections 5.1-5.9. AAA protocols are discussed in Sections 5.1-5.9.
The backend authentication server is trusted to transport keying The backend authentication server is trusted to transport keying
material only to the authenticator that was established with the material only to the authenticator that was established with the
peer, and it is trusted to transport that keying material to no other peer, and it is trusted to transport that keying material to no other
parties. In many systems, EAP keying material established by the EAP parties. In many systems, EAP keying material established by the EAP
peer and EAP server are combined with publicly available data to peer and EAP server are combined with publicly available data to
derive other keys. The backend authentication server is trusted to derive other keys. The backend authentication server is trusted to
refrain from deriving these same keys or acting as a man-in-the- refrain from deriving these same keys or acting as a
middle even though it has access to the keying material that is man-in-the-middle even though it has access to the keying material
needed to do so. that is needed to do so.
The authenticator is also a trusted party. The authenticator is The authenticator is also a trusted party. The authenticator is
trusted not to distribute keying material provided by the backend trusted not to distribute keying material provided by the backend
authentication server to any other parties. If the authenticator authentication server to any other parties. If the authenticator
uses a key derivation function to derive additional keying material, uses a key derivation function to derive additional keying material,
the authenticator is trusted to distribute the derived keying the authenticator is trusted to distribute the derived keying
material only to the appropriate party that is known to the peer, and material only to the appropriate party that is known to the peer, and
no other party. When this approach is used, care must be taken to no other party. When this approach is used, care must be taken to
ensure that the resulting key management system meets all of the ensure that the resulting key management system meets all of the
principles in [RFC4962], confirming that keys used to protect data principles in [RFC4962], confirming that keys used to protect data
are to be known only by the peer and authenticator. are to be known only by the peer and authenticator.
Completion of the Secure Association Protocol (Phase 2) results in Completion of the Secure Association Protocol (phase 2) results in
the derivation or transport of Transient Session Keys (TSKs) known the derivation or transport of Transient Session Keys (TSKs) known
only to the EAP peer (identified by the Peer-Id(s)) and authenticator only to the EAP peer (identified by the Peer-Id(s)) and authenticator
(identified by the NAS-Identifier). Both the EAP peer and (identified by the NAS-Identifier). Both the EAP peer and
authenticator know the TSKs to be fresh. 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 authenticator demonstrate that they are authorized to perform their
roles. Authorization issues are discussed in Sections 4.3.2 and 5.5; roles. Authorization issues are discussed in Sections 4.3.2 and 5.5;
security properties of Secure Association Protocols are discussed in security properties of Secure Association Protocols are discussed in
Section 3.1. Section 3.1.
1.6. EAP Invariants 1.6. EAP Invariants
skipping to change at page 15, line 5 skipping to change at page 16, line 33
Ciphersuite independence Ciphersuite independence
1.6.1. Mode Independence 1.6.1. Mode Independence
EAP is typically deployed to support extensible network access EAP is typically deployed to support extensible network access
authentication in situations where a peer desires network access via authentication in situations where a peer desires network access via
one or more authenticators. Where authenticators are deployed one or more authenticators. Where authenticators are deployed
standalone, the EAP conversation occurs between the peer and standalone, the EAP conversation occurs between the peer and
authenticator, and the authenticator locally implements one or more authenticator, and the authenticator locally implements one or more
EAP methods. However, when utilized in "pass-through" mode, EAP EAP methods. However, when utilized in "pass-through" mode, EAP
enables deployment of new authentication methods without requiring enables the deployment of new authentication methods without
development of new code on the authenticator. requiring the development of new code on the authenticator.
While the authenticator can implement some EAP methods locally and While the authenticator can implement some EAP methods locally and
use those methods to authenticate local users, it can at the same use those methods to authenticate local users, it can 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 or not the
is operating as a pass-through or not. authenticator is operating as a pass-through.
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 EAP keying material and derivation results in the export of EAP keying material and
parameters on the EAP peer and server. Even though the EAP peer or parameters on the EAP peer and server. Even though the EAP peer or
server can import channel binding parameters that can include the server can import channel binding parameters that can include the
identity of the EAP authenticator, this information is treated as identity of the EAP authenticator, this information is treated as
opaque octets. As a result, within EAP the only relevant identities opaque octets. As a result, within EAP, the only relevant identities
are the Peer-Id(s) and Server-Id(s). Channel binding parameters are are the Peer-Id(s) and Server-Id(s). Channel binding parameters are
only interpreted by the lower layer. 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. As far as the EAP peer is the principle of mode independence. 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.6.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 over PPP [RFC1661], IEEE 802 wired networks [IEEE-802.1X], and
wireless networks such as 802.11 [IEEE-802.11] and 802.16 wireless networks such as 802.11 [IEEE-802.11] and 802.16
[IEEE-802.16e]. [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., Medium Access
Control (MAC) addresses).
Note that media independence can be retained within EAP methods that Note that media independence can be retained within EAP methods that
support Channel Binding or method-specific identification. An EAP support channel binding 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 binding parameters are treated as opaque octets by EAP Channel binding parameters are treated as opaque octets by EAP
methods, so that handling them does not require media-specific methods so that handling them does not require media-specific
knowledge. knowledge.
1.6.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 having to implement methods. This allows the authenticator to avoid having to implement
the EAP methods configured for use by peers. In fact, since a pass- the EAP methods configured for use by peers. In fact, since a
through authenticator need not implement any EAP methods at all, it pass-through authenticator need not implement any EAP methods at all,
cannot be assumed to support any EAP method-specific code. As noted it cannot be assumed to support any EAP method-specific code. As
in [RFC3748] Section 2.3: noted in [RFC3748] Section 2.3:
Compliant pass-through authenticator implementations MUST by Compliant pass-through authenticator implementations MUST by
default forward EAP packets of any Type. default forward EAP packets of any Type.
This is useful where there is no single EAP method that is both This is useful where there is no single EAP method that is both
mandatory-to-implement and offers acceptable security for the media mandatory to implement and offers acceptable security for the media
in use. For example, the [RFC3748] mandatory-to-implement EAP method in use. For example, the [RFC3748] mandatory-to-implement EAP method
(MD5-Challenge) does not provide dictionary attack resistance, mutual (MD5-Challenge) does not provide dictionary attack resistance, mutual
authentication or key derivation, and as a result is not appropriate authentication, or key derivation, and as a result, is not
for use in Wireless Local Area Network (WLAN) authentication appropriate for use in Wireless Local Area Network (WLAN)
[RFC4017]. However, despite this it is possible for the peer and authentication [RFC4017]. However, despite this, it is possible for
authenticator to interoperate as long as a suitable EAP method is the peer and authenticator to interoperate as long as a suitable EAP
supported both on the EAP peer and server. method is supported both on the EAP peer and server.
1.6.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 exported EAP keying material be large enough (with requires that exported EAP keying material be large enough (with
sufficient entropy) to handle any ciphersuite. sufficient entropy) to handle any ciphersuite.
While EAP methods can negotiate the ciphersuite used in protection of While EAP methods can 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
EAP. EAP.
For example, within PPP, the ciphersuite is negotiated within the For example, within PPP, the ciphersuite is negotiated within the
Encryption Control Protocol (ECP) defined in [RFC1968], after EAP Encryption Control Protocol (ECP) defined in [RFC1968], after EAP
authentication is completed. Within [IEEE-802.11], the AP authentication is completed. Within [IEEE-802.11], 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 that EAP methods have knowledge of lower layer layer, requiring that EAP methods have knowledge of lower-layer
ciphersuites would compromise the principle of Media Independence. ciphersuites would compromise the principle of media independence.
As a result, methods export EAP keying material that is ciphersuite- As a result, methods export EAP keying material that is ciphersuite
independent. Since ciphersuite negotiation occurs in the lower independent. Since ciphersuite negotiation occurs in the lower
layer, there is no need for lower layer ciphersuite negotiation layer, there is no need for lower-layer ciphersuite negotiation
within EAP. within EAP.
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, the ciphersuite specification needs to describe how TSKs framework, the ciphersuite specification needs to describe 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 material. To maintain Method Independence, algorithms for keying material. To maintain method independence, algorithms for
deriving TSKs MUST NOT depend on the EAP method, although algorithms deriving TSKs MUST NOT depend on the EAP method, although algorithms
for TEK derivation MAY be specific to the EAP method. 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
Ciphersuite independence enables EAP methods to be used with new Ciphersuite independence enables EAP methods to be used with new
ciphersuites without requiring the methods to be updated. If EAP ciphersuites without requiring the methods to be updated. If
methods were to specify how to derive transient session keys for EAP methods were to specify how to derive transient session keys
each ciphersuite, they would need to be updated each time a new for each ciphersuite, they would need to be updated each time a
ciphersuite is developed. In addition, backend authentication new ciphersuite is developed. In addition, backend
servers might not be usable with all EAP-capable authenticators, authentication servers might not be usable with all EAP-capable
since the backend authentication server would also need to be authenticators, since the backend authentication server would
updated each time support for a new ciphersuite is added to the also need to be updated each time support for a new ciphersuite
authenticator. is added to the authenticator.
Reduced EAP method complexity Reduced EAP method complexity
Ciphersuite independence enables EAP methods to avoid having to Ciphersuite independence enables EAP methods to avoid having to
include ciphersuite-specific code. Requiring each EAP method to include ciphersuite-specific code. Requiring each EAP method to
include ciphersuite-specific code for transient session key include ciphersuite-specific code for transient session key
derivation would increase method complexity and result in derivation would increase method complexity and result in
duplicated effort. duplicated effort.
Simplified configuration Simplified configuration
Ciphersuite independence enables EAP method implementations on the Ciphersuite independence enables EAP method implementations on
peer and server to avoid having to configure ciphersuite-specific the peer and server to avoid having to configure
parameters. The ciphersuite is negotiated between the peer and ciphersuite-specific parameters. The ciphersuite is negotiated
authenticator outside of EAP. Where the authenticator operates in between the peer and authenticator outside of EAP. Where the
"pass-through" mode, the EAP server is not a party to this authenticator operates in "pass-through" mode, the EAP server is
negotiation, nor is it involved in the data flow between the EAP not a party to this negotiation, nor is it involved in the data
peer and authenticator. As a result, the EAP server does not have flow between the EAP peer and authenticator. As a result, the
knowledge of the ciphersuites and negotiation policies implemented EAP server does not have knowledge of the ciphersuites and
by the peer and authenticator, nor is it aware of the ciphersuite negotiation policies implemented by the peer and authenticator,
negotiated between them. For example, since Encryption Control nor is it aware of the ciphersuite negotiated between them. For
Protocol (ECP) negotiation occurs after authentication, when run example, since Encryption Control Protocol (ECP) negotiation
over PPP, the EAP peer and server cannot anticipate the negotiated occurs after authentication, when run over PPP, the EAP peer and
ciphersuite and therefore this information cannot be provided to server cannot anticipate the negotiated ciphersuite, and
the EAP method. therefore, this information cannot be provided to the EAP
method.
2. Lower Layer Operation 2. Lower-Layer Operation
On completion of EAP authentication, EAP keying material and On completion of EAP authentication, EAP keying material and
parameters exported by the EAP method are provided to the lower layer parameters exported by the EAP method are provided to the lower layer
and AAA layer (if present). These include the Master Session Key and AAA layer (if present). These include the Master Session Key
(MSK), Extended Master Session Key (EMSK), Peer-Id(s), Server-Id(s) (MSK), Extended Master Session Key (EMSK), Peer-Id(s), Server-Id(s),
and Session-Id. The Initialization Vector (IV) is deprecated, but and Session-Id. The Initialization Vector (IV) is deprecated, but
might be provided. might be provided.
In order to preserve the security of EAP keying material derived In order to preserve the security of EAP keying material derived
within methods, lower layers MUST NOT export keys passed down by EAP within methods, lower layers MUST NOT export keys passed down by EAP
methods. This implies that EAP keying material passed down to a methods. This implies that EAP keying material passed down to a
lower layer is for the exclusive use of that lower layer and MUST NOT lower layer is for the exclusive use of that lower layer and MUST NOT
be used within another lower layer. This prevents compromise of one be 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
material. material.
skipping to change at page 18, line 45 skipping to change at page 20, line 39
layer MUST NOT leave the authenticator. layer MUST NOT leave the authenticator.
On the EAP server, keying material and parameters requested by and On the EAP server, keying material and parameters requested by and
passed down to the AAA layer MAY be replicated to the AAA layer on passed down to the AAA layer MAY be replicated to the AAA layer on
the authenticator (with the exception of the EMSK). On the the authenticator (with the exception of the EMSK). On the
authenticator, the AAA layer provides the replicated keying material authenticator, the AAA layer provides the replicated keying material
and parameters to the lower layer over which the EAP authentication and parameters to the lower layer over which the EAP authentication
conversation took place. This enables mode independence to be conversation took place. This enables mode independence to be
maintained. maintained.
The EAP layer as well as the peer and authenticator layers MUST NOT The EAP layer, as well as the peer and authenticator layers, MUST NOT
modify or cache keying material or parameters (including Channel modify or cache keying material or parameters (including channel
Bindings) passing in either direction between the EAP method layer bindings) passing in either direction between the EAP method layer
and the lower layer or AAA layer. and the lower layer or AAA layer.
2.1. Transient Session Keys 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
keying material, including exported EAP keying material and/or TSKs; keying material, including exported EAP keying material and/or TSKs;
the structure of this key cache is defined by the lower layer. So as the structure of this key cache is defined by the lower layer. So as
to enable interoperability, new lower layer specifications MUST to enable interoperability, new lower-layer specifications MUST
describe key caching behavior. Unless explicitly specified by the describe key caching behavior. Unless explicitly specified by the
lower layer, the EAP peer, server and authenticator MUST assume that lower layer, the EAP peer, server, and authenticator MUST assume that
peers and authenticators do not cache keying material. Existing EAP peers and authenticators do not cache keying material. Existing EAP
lower layers and AAA layers handle the generation of transient lower layers and AAA layers handle the generation of transient
session keys and caching of EAP keying material in different ways: session keys and caching of EAP keying material in different ways:
IEEE 802.1X-2004 IEEE 802.1X-2004
When used with wired networks, IEEE 802.1X-2004 [IEEE-802.1X] does When used with wired networks, IEEE 802.1X-2004 [IEEE-802.1X]
not support link layer ciphersuites and a result, it does not does not support link-layer ciphersuites, and as a result, it
provide for generation of TSKs, or caching of EAP keying material does not provide for the generation of TSKs or caching of EAP
and parameters. Once EAP authentication completes, it is assumed keying material and parameters. Once EAP authentication
that EAP keying material and parameters are discarded; on IEEE 802 completes, it is assumed that EAP keying material and parameters
wired networks there is no subsequent Secure Association Protocol are discarded; on IEEE 802 wired networks, there is no
exchange. Perfect Forward Secrecy (PFS) is only possible if the subsequent Secure Association Protocol exchange. Perfect
negotiated EAP method supports this. Forward Secrecy (PFS) is only possible if the negotiated EAP
method supports this.
PPP PPP, defined in [RFC1661], does not include support for a Secure PPP
Association Protocol; nor does it support caching of EAP keying PPP, defined in [RFC1661], does not include support for a Secure
Association Protocol, nor does it 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 is NOT directly from the MSK, as described in [RFC2716] Section 3.5.
RECOMMENDED, since if PPP were to support caching of EAP keying This is NOT RECOMMENDED, since if PPP were to support caching of
material, this could result in TSK reuse. As a result, once the EAP keying material, this could result in TSK reuse. As a
PPP session is terminated, EAP keying material and parameters MUST result, once the PPP session is terminated, EAP keying material
be discarded. Since caching of EAP keying material is not and parameters MUST be discarded. Since caching of EAP keying
permitted within PPP, there is no way to handle TSK re-key without material is not permitted within PPP, there is no way to handle
EAP re-authentication. Perfect Forward Secrecy (PFS) is only TSK re-key without EAP re-authentication. Perfect Forward
possible if the negotiated EAP method supports this. Secrecy (PFS) is only possible if the negotiated EAP method
supports this.
IKEv2 IKEv2
IKEv2, defined in [RFC4306], only uses the MSK for authentication IKEv2, defined in [RFC4306], only uses the MSK for
purposes and not key derivation. The EMSK, IV, Peer-Id, Server-Id authentication purposes and not key derivation. The EMSK, IV,
or Session-Id are not used. As a result, the TSKs derived by IKEv2 Peer-Id, Server-Id or Session-Id are not used. As a result, the
are cryptographically independent of the EAP keying material and TSKs derived by IKEv2 are cryptographically independent of the
re-key of IPsec SAs can be handled without requiring EAP re- EAP keying material and re-key of IPsec SAs can be handled
authentication. Within IKEv2 it is possible to negotiate PFS, without requiring EAP re-authentication. Within IKEv2, it is
regardless of which EAP method is negotiated. IKEv2 as specified possible to negotiate PFS, regardless of which EAP method is
in [RFC4306] does not cache EAP keying material or parameters; once negotiated. IKEv2 as specified in [RFC4306] does not cache EAP
IKEv2 authentication completes it is assumed that EAP keying keying material or parameters; once IKEv2 authentication
material and parameters are discarded. The Session-Timeout completes, it is assumed that EAP keying material and parameters
attribute is therefore interpreted as a limit on the VPN session are discarded. The Session-Timeout Attribute is therefore
time, rather than an indication of the MSK key lifetime. interpreted as a limit on the VPN session time, rather than an
indication of the MSK key lifetime.
IEEE 802.11 IEEE 802.11
IEEE 802.11 enables caching of the MSK, but not the EMSK, IV, Peer- IEEE 802.11 enables caching of the MSK, but not the EMSK, IV,
Id, Server-Id, or Session-Id. More details about the structure of Peer-Id, Server-Id, or Session-Id. More details about the
the cache are available in [IEEE-802.11]. In IEEE 802.11, TSKs are structure of the cache are available in [IEEE-802.11]. In IEEE
derived from the MSK using a Secure Association Protocol known as 802.11, TSKs are derived from the MSK using a Secure Association
the 4-way handshake, which includes a nonce exchange. This Protocol known as the 4-way handshake, which includes a nonce
guarantees TSK freshness even if the MSK is reused. The 4-way exchange. This guarantees TSK freshness even if the MSK is
handshake also enables TSK re-key without EAP re-authentication. reused. The 4-way handshake also enables TSK re-key without EAP
PFS is only possible within IEEE 802.11 if caching is not enabled re-authentication. PFS is only possible within IEEE 802.11 if
and the negotiated EAP method supports PFS. caching is not enabled and the negotiated EAP method supports
PFS.
IEEE 802.16e IEEE 802.16e
IEEE 802.16e, defined in [IEEE-802.16e] supports caching of the IEEE 802.16e, defined in [IEEE-802.16e], supports caching of the
MSK, but not the EMSK, IV, Peer-Id, Server-Id or Session-Id. IEEE MSK, but not the EMSK, IV, Peer-Id, Server-Id, or Session-Id.
802.16e support a Secure Association Protocol in which TSKs are IEEE 802.16e supports a Secure Association Protocol in which
chosen by the authenticator without any contribution by the peer. TSKs are chosen by the authenticator without any contribution by
The TSKs are encrypted, authenticated and integrity protected using the peer. The TSKs are encrypted, authenticated, and integrity
the MSK and are transported from the authenticator to the peer. protected using the MSK and are transported from the
TSK re-key is possible without EAP re-authentication. PFS is not authenticator to the peer. TSK re-key is possible without EAP
possible even if the negotiated EAP method supports it. re-authentication. PFS is not possible even if the negotiated
EAP method supports it.
AAA Existing implementations and specifications for RADIUS/EAP AAA
Existing implementations and specifications for RADIUS/EAP
[RFC3579] or Diameter EAP [RFC4072] do not support caching of [RFC3579] or Diameter EAP [RFC4072] do not support caching of
keying material or parameters. In existing AAA client, proxy and keying material or parameters. In existing AAA clients, proxy
server implementations, exported EAP keying material (MSK, EMSK and and server implementations, exported EAP keying material (MSK,
IV) as well as parameters and derived keys are not cached and MUST EMSK, and IV), as well as parameters and derived keys are not
be presumed lost after the AAA exchange completes. cached and MUST be 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
keys once they are sent. The AAA layer MUST NOT retain keys that transported keys once they are sent. The AAA layer MUST NOT
it has previously sent. For example, a AAA layer that has retain keys that it has previously sent. For example, a AAA
transported the MSK MUST delete it, and keys MUST NOT be derived layer that has transported the MSK MUST delete it, and keys MUST
from the MSK from that point forward. NOT be derived from the MSK from that point forward.
2.2. Authenticator and Peer Architecture 2.2. Authenticator and Peer 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. For example, any of the authenticator the EAP authenticator or peer. For example, any of the authenticator
architectures described in [RFC4118] can be used. As a result, lower architectures described in [RFC4118] can be used. As a result, lower
layers need to identify EAP peers and authenticators unambiguously, layers need to identify EAP peers and authenticators unambiguously,
without incorporating implicit assumptions about peer and without incorporating implicit assumptions about peer and
authenticator architectures. authenticator architectures.
For example, it is possible for multiple base stations and a For example, it is possible for multiple base stations and a
"controller" (e.g. WLAN switch) to comprise a single EAP "controller" (e.g., WLAN switch) to comprise a single EAP
authenticator. In such a situation, the "base station identity" is authenticator. In such a situation, the "base station identity" is
irrelevant to the EAP method conversation, except perhaps as an irrelevant to the EAP method conversation, except perhaps as an
opaque blob to be used in Channel Binding. Many base stations can opaque blob to be used in channel binding. Many base stations can
share the same authenticator identity. An EAP authenticator or peer: share the same authenticator identity. An EAP authenticator or peer:
(a) can contain one or more physical or logical ports; (a) can contain one or more physical or logical ports;
(b) can advertise itself as one or more "virtual" (b) can advertise itself as one or more "virtual" authenticators
authenticators or peers; or peers;
(c) can utilize multiple CPUs; (c) can utilize multiple CPUs;
(d) can support clustering services for load balancing or failover. (d) can support clustering services for load balancing or
failover.
Both the EAP peer and authenticator can have more than one physical Both the EAP peer and authenticator can have more than one physical
or logical port. A peer can simultaneously access the network via or logical port. A peer can 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 can offer network a given authenticator. Similarly, an authenticator can 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 physical multiple virtual authenticators, it is possible for a single physical
port to belong to multiple virtual authenticators. port to belong to multiple virtual authenticators.
An authenticator can be configured to communicate with more than one An authenticator can be configured to communicate with more than one
EAP server, each of which is configured to communicate with a subset EAP server, each of which is configured to communicate with a subset
of the authenticators. The situation is illustrated in Figure 3. of the authenticators. The situation is illustrated in Figure 3.
2.3. Authenticator Identification 2.3. Authenticator Identification
The EAP method conversation is between the EAP peer and server. The The EAP method conversation is between the EAP peer and server. The
authenticator identity, if considered at all by the EAP method, is authenticator identity, if considered at all by the EAP method, is
treated as an opaque blob for the purpose of Channel Binding (see treated as an opaque blob for the purpose of channel binding (see
Section 5.3.3). However, the authenticator identity is important in Section 5.3.3). However, the authenticator identity is important in
two other exchanges - the AAA protocol exchange and the Secure two other exchanges - the AAA protocol exchange and the Secure
Association Protocol conversation. Association Protocol conversation.
The AAA conversation is between the EAP authenticator and the backend The AAA conversation is between the EAP authenticator and the backend
authentication server. From the point of view of the backend authentication server. From the point of view of the backend
authentication server, keying material and parameters are transported authentication server, keying material and parameters are transported
to the EAP authenticator identified by the NAS-Identifier attribute. to the EAP authenticator identified by the NAS-Identifier Attribute.
Since an EAP authenticator MUST NOT share EAP keying material or Since an EAP authenticator MUST NOT share EAP keying material or
parameters with another party, if the EAP peer or backend parameters with another party, if the EAP peer or backend
authentication server detects use of EAP keying material and authentication 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.
The Secure Association Protocol conversation is between the peer and The Secure Association Protocol conversation is between the peer and
the authenticator. For lower layers which support key caching it is the authenticator. For lower layers that support key caching, it is
particularly important for the EAP peer, authenticator and backend particularly important for the EAP peer, authenticator, and backend
server to have a consistent view of the usage scope of the server to have a consistent view of the usage scope of the
transported keying material. In order to enable this, it is transported keying material. In order to enable this, it is
RECOMMENDED that the Secure Association Protocol explicitly RECOMMENDED that the Secure Association Protocol explicitly
communicate the usage scope of the EAP keying material passed down to communicate the usage scope of the EAP keying material passed down to
the lower layer, rather than implicitly assuming that this is defined the lower layer, rather than implicitly assuming that this is defined
by the authenticator and peer endpoint addresses. by the authenticator and peer endpoint addresses.
+-+-+-+-+ +-+-+-+-+
| EAP | | EAP |
| Peer | | Peer |
skipping to change at page 22, line 38 skipping to change at page 24, line 47
EAP over AAA \ | \ | EAP over AAA \ | \ |
(optional) \ | \ | (optional) \ | \ |
\ | \ | \ | \ |
\ | \ | \ | \ |
\ | \ | \ | \ |
+-+-+-+-+-+ +-+-+-+-+-+ Backend +-+-+-+-+-+ +-+-+-+-+-+ Backend
| EAP | | EAP | Authentication | EAP | | EAP | Authentication
| Server1 | | Server2 | Servers | Server1 | | Server2 | Servers
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
Figure 3: Relationship between EAP peer, authenticator and server Figure 3: Relationship between EAP Peer, Authenticator, and Server
Since an authenticator can have multiple ports, the scope of the Since an authenticator can have multiple ports, the scope of the
authenticator key cache cannot be described by a single endpoint authenticator key cache cannot be described by a single endpoint
address. Similarly, where a peer can have multiple ports and sharing address. Similarly, where a peer can have multiple ports and sharing
of EAP keying material and parameters between peer ports of the same of EAP keying material and parameters between peer ports of the same
link type is allowed, the extent of the peer key cache cannot be link type is allowed, the extent of the peer key cache cannot be
communicated by using a single endpoint address. Instead, it is communicated by using a single endpoint address. Instead, it is
RECOMMENDED that the EAP peer and authenticator consistently identify RECOMMENDED that the EAP peer and authenticator consistently identify
themselves utilizing explicit identifiers, rather than endpoint themselves utilizing explicit identifiers, rather than endpoint
addresses or port identifiers. addresses or port identifiers.
AAA protocols such as RADIUS [RFC3579] and Diameter [RFC4072] provide AAA protocols such as RADIUS [RFC3579] and Diameter [RFC4072] provide
a mechanism for the identification of AAA clients; since the EAP a mechanism for the identification of AAA clients; since the EAP
authenticator and AAA client MUST be co-resident, this mechanism is authenticator and AAA client MUST be co-resident, this mechanism is
applicable to the identification of EAP authenticators. applicable to the identification of EAP 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 can have more than one IP address, the NAS- attributes. Since a NAS can have more than one IP address, the
Identifier attribute is RECOMMENDED for explicit identification of NAS-Identifier Attribute is RECOMMENDED for explicit identification
the authenticator, both within the AAA protocol exchange and the of the authenticator, both within the AAA protocol exchange and the
Secure Association Protocol conversation. Secure Association Protocol conversation.
Problems which can arise where the peer and authenticator implicitly Problems that can arise where the peer and authenticator implicitly
identify themselves using endpoint addresses include the following: identify themselves using endpoint addresses include the following:
(a) It is possible that the peer will not be able to determine which (a) It is possible that the peer will not be able to determine which
authenticator ports are associated with which authenticators. As a authenticator ports are associated with which authenticators.
result, the EAP peer will be unable to utilize the authenticator As a result, the EAP peer will be unable to utilize the
key cache in an efficient way, and will also be unable to determine authenticator key cache in an efficient way, and will also be
whether EAP keying material has been shared outside its authorized unable to determine whether EAP keying material has been shared
scope, and therefore needs to be considered compromised. outside its authorized scope, and therefore needs to be
considered compromised.
(b) It is possible that the authenticator will not be able to determine (b) It is possible that the authenticator will not be able to
which peer ports are associated with which peers, preventing the determine which peer ports are associated with which peers,
peer from communicating with it utilizing multiple peer ports. preventing the peer from communicating with it utilizing
multiple peer ports.
(c) It is possible that the peer will not be able to determine which (c) It is possible that the peer will not be able to determine with
virtual authenticator it is communicating with. For example, which virtual authenticator it is communicating. For example,
multiple virtual authenticators can share a MAC address, but multiple virtual authenticators can share a MAC address, but
utilize different NAS-Identifiers. utilize different NAS-Identifiers.
(d) It is possible that the authenticator will not be able to determine (d) It is possible that the authenticator will not be able to
which virtual peer it is communicating with. Multiple virtual determine with which virtual peer it is communicating. Multiple
peers can share a MAC address, but utilize different Peer-Ids. virtual peers can share a MAC address, but utilize different
Peer-Ids.
(e) It is possible that the EAP peer and server will not be able to (e) It is possible that the EAP peer and server will not be able to
verify the authenticator identity via Channel Binding. verify the authenticator identity via channel binding.
For example, problems (a), (c) and (e) occur in [IEEE-802.11], which For example, problems (a), (c), and (e) occur in [IEEE-802.11], which
utilizes peer and authenticator MAC addresses within the 4-way utilizes peer and authenticator MAC addresses within the 4-way
handshake. Problems (b) and (d) do not occur since [IEEE-802.11] handshake. Problems (b) and (d) do not occur since [IEEE-802.11]
only allows a virtual peer to utilize a single port. only allows a virtual peer to utilize a single port.
The following steps enable lower layer identities to be securely The following steps enable lower-layer identities to be securely
verified by all parties: verified by all parties:
(f) Specify the lower layer parameters used to identify the (f) Specify the lower-layer parameters used to identify the
authenticator and peer. As noted earlier, endpoint or port authenticator and peer. As noted earlier, endpoint or port
identifiers are not recommended for identification of the identifiers are not recommended for identification of the
authenticator or peer when it is possible for them to have multiple authenticator or peer when it is possible for them to have
ports. multiple ports.
(g) Communicate the lower layer identities between the peer and (g) Communicate the lower-layer identities between the peer and
authenticator within phase 0. This allows the peer and authenticator within phase 0. This allows the peer and
authenticator to determine the key scope if a key cache is authenticator to determine the key scope if a key cache is
utilized. utilized.
(h) Communicate the lower layer authenticator identity between the (h) Communicate the lower-layer authenticator identity between the
authenticator and backend server within the NAS-Identifier authenticator and backend authentication server within the NAS-
attribute. Identifier Attribute.
(i) Include the lower layer identities within Channel Bindings (if (i) 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
the EAP peer and server. between the EAP peer and server.
(j) Support the integrity-protected exchange of identities within phase (j) Support the integrity-protected exchange of identities within
2a. phase 2a.
(k) Utilize the advertised lower layer identities to enable the peer (k) 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.
2.3.1. Virtual Authenticators 2.3.1. Virtual Authenticators
When a single physical authenticator advertises itself as multiple When a single physical authenticator advertises itself as multiple
virtual authenticators, if the virtual authenticators do not maintain virtual authenticators, if the virtual authenticators do not maintain
logically separate key caches, then by authenticating to one virtual logically separate key caches, then by authenticating to one virtual
authenticator, the peer can gain access to the other virtual authenticator, the peer can gain access to the other virtual
authenticators sharing a key cache. authenticators sharing a key cache.
skipping to change at page 24, line 47 skipping to change at page 27, line 18
derive EAP keying material. If the "Guest" and "Corporate Intranet" derive EAP keying material. If the "Guest" and "Corporate Intranet"
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" network. access to the "Corporate Intranet" network.
The following steps can be taken to mitigate this vulnerability: The following steps can be taken to mitigate this vulnerability:
(a) Authenticators are REQUIRED to cache associated authorizations (a) 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 to the peer on each network access, regardless of authorizations to the peer on each network access, regardless of
which virtual authenticator is being accessed. This ensures that which virtual authenticator is being accessed. This ensures
an attacker cannot obtain elevated privileges even where the key that an attacker cannot obtain elevated privileges even where
cache is shared between virtual authenticators, and a peer obtains the key cache is shared between virtual authenticators, and a
access to one virtual authenticator utilizing a key cache entry peer obtains access to one virtual authenticator utilizing a key
created for use with another virtual authenticator. cache entry created for use with another virtual authenticator.
(b) It is RECOMMENDED that physical authenticators maintain separate (b) It is RECOMMENDED that physical authenticators maintain separate
key caches for each virtual authenticator. This ensures that a key caches for each virtual authenticator. This ensures that a
cache entry created for use with one virtual authenticator cannot cache entry created for use with one virtual authenticator
be used for access to another virtual authenticator. Since a key cannot be used for access to another virtual authenticator.
cache entry can no longer be shared between virtual Since a key cache entry can no longer be shared between virtual
authentications, this step provides protection beyond that offered authentications, this step provides protection beyond that
in (a). This is valuable in situations where authorizations are offered in (a). This is valuable in situations where
not used to enforce access limitations. For example, where access authorizations are not used to enforce access limitations. For
is limited using a filter installed on a router rather than using example, where access is limited using a filter installed on a
authorizations provided to the authenticator, a peer can gain router rather than using authorizations provided to the
unauthorized access to resources by exploiting a shared key cache authenticator, a peer can gain unauthorized access to resources
entry. by exploiting a shared key cache entry.
(c) It is RECOMMENDED that each virtual authenticator identify itself (c) It is RECOMMENDED that each virtual authenticator identify
consistently to the peer and to the backend authentication server, itself consistently to the peer and to the backend
so as to enable the peer to verify the authenticator identity via authentication server, so as to enable the peer to verify the
Channel Binding (see Section 5.3.3). authenticator identity via channel binding (see Section 5.3.3).
(d) It is RECOMMENDED that each virtual authenticator identify itself (d) It is RECOMMENDED that each virtual authenticator identify
distinctly, in order to enable the peer and backend server to tell itself distinctly, in order to enable the peer and backend
them apart. For example, this can be accomplished by utilizing a authentication server to tell them apart. For example, this can
distinct value of the NAS-Identifier attribute. be accomplished by utilizing a distinct value of the NAS-
Identifier Attribute.
2.4. Peer Identification 2.4. Peer Identification
As described in [RFC3748] Section 7.3, the peer identity provided in As described in [RFC3748] Section 7.3, the peer identity provided in
the EAP-Response/Identity can be different from the peer identities the EAP-Response/Identity can be different from the peer identities
authenticated by the EAP method. For example, the identity provided authenticated by the EAP method. For example, the identity provided
in the EAP-Response/Identity can be a privacy identifier as described in the EAP-Response/Identity can be a privacy identifier as described
in "The Network Access Identifier" [RFC4282] Section 2. As noted in in "The Network Access Identifier" [RFC4282] Section 2. As noted in
[RFC4284], it is also possible to utilize a Network Access Identifier [RFC4284], it is also possible to utilize a Network Access Identifier
(NAI) for the purposes of source routing; an NAI utilized for source (NAI) for the purposes of source routing; an NAI utilized for source
routing is said to be "decorated" as described in [RFC4282] Section routing is said to be "decorated" as described in [RFC4282] Section
2.7. 2.7.
When EAP peer provides the Network Access Identity (NAI) within the When the EAP peer provides the Network Access Identity (NAI) within
EAP-Response/Identity, as described in [RFC3579], the authenticator the EAP-Response/Identity, as described in [RFC3579], the
copies the NAI included in the EAP-Response/Identity into the User- authenticator copies the NAI included in the EAP-Response/Identity
Name attribute included within the Access-Request. As the Access- into the User-Name Attribute included within the Access-Request. As
Request is forwarded toward the backend authentication server, AAA the Access-Request is forwarded toward the backend authentication
proxies remove decoration from the NAI included in the User-Name server, AAA proxies remove decoration from the NAI included in the
Attribute; the NAI included within the EAP-Response/Identity User-Name Attribute; the NAI included within the
encapsulated in the Access-Request remains unchanged. As a result, EAP-Response/Identity encapsulated in the Access-Request remains
when the Access-Request arrives at the backend authentication server, unchanged. As a result, when the Access-Request arrives at the
the EAP-Response/Identity can differ from the User-Name Attribute backend authentication server, the EAP-Response/Identity can differ
(which can have some or all of the decoration removed). In the from the User-Name Attribute (which can have some or all of the
absence of a Peer-Id, the backend authentication server SHOULD use decoration removed). In the absence of a Peer-Id, the backend
the contents of the User-Name Attribute, rather than the EAP- authentication server SHOULD use the contents of the User-Name
Response/Identity as the peer identity. Attribute, rather than the EAP-Response/Identity, as the peer
identity.
It is possible for more than one Peer-Id to be exported by an EAP It is possible for more than one Peer-Id to be exported by an EAP
method. For example, a peer certificate can contain more than one method. For example, a peer certificate can contain more than one
peer identity; in a tunnel method peer identities can be peer identity; in a tunnel method, peer identities can be
authenticated both within an outer and inner exchange and these authenticated within both an outer and inner exchange, and these
identities could be different in type and contents. For example, an identities could be different in type and contents. For example, an
outer exchange could provide a Peer-Id in the form of an RDN, whereas outer exchange could provide a Peer-Id in the form of a Relative
an inner exchange could identify the peer via its NAI or MAC address. Distinguished Name (RDN), whereas an inner exchange could identify
Where EAP keying material is determined solely from the outer the peer via its NAI or MAC address. Where EAP keying material is
exchange, only the outer Peer-Id(s) are exported; where the EAP determined solely from the outer exchange, only the outer Peer-Id(s)
keying material is determined from both the inner and outer are exported; where the EAP keying material is determined from both
exchanges, then both the inner and outer Peer-Id(s) are exported by the inner and outer exchanges, then both the inner and outer
the tunnel method. Peer-Id(s) are exported by the tunnel method.
2.5. Server Identification 2.5. Server Identification
It is possible for more than one Server-Id to be exported by an EAP It is possible for more than one Server-Id to be exported by an EAP
method. For example, a server certificate can contain more than one method. For example, a server certificate can contain more than one
server identity; in a tunnel method server identities could be server identity; in a tunnel method, server identities could be
authenticated both within an outer and inner exchange and these authenticated within both an outer and inner exchange, and these
identities could be different in type and contents. For example, an identities could be different in type and contents. For example, an
outer exchange could provide a Server-Id in the form of an IP outer exchange could provide a Server-Id in the form of an IP
address, whereas an inner exchange could identify the server via its address, whereas an inner exchange could identify the server via its
FQDN or hostname. Where EAP keying material is determined solely Fully-Qualified Domain Name (FQDN) or hostname. Where EAP keying
from the outer exchange, only the outer Server-Id(s) are exported by material is determined solely from the outer exchange, only the outer
the EAP method; where the EAP keying material is determined from both Server-Id(s) are exported by the EAP method; where the EAP keying
the inner and outer exchanges, then both the inner and outer Server- material is determined from both the inner and outer exchanges, then
Id(s) are exported by the EAP method. both the inner and outer Server-Id(s) are exported by the EAP method.
As shown in Figure 3, an authenticator can be configured to As shown in Figure 3, an authenticator can be configured to
communicate with multiple EAP servers; the EAP server that an communicate with multiple EAP servers; the EAP server that an
authenticator communicates with can vary according to configuration authenticator communicates with can vary according to configuration
and network and server availability. While the EAP peer can assume and network and server availability. While the EAP peer can assume
that all EAP servers within a realm have access to the credentials that all EAP servers within a realm have access to the credentials
necessary to validate an authentication attempt, it cannot assume necessary to validate an authentication attempt, it cannot assume
that all EAP servers share persistent state. that all EAP servers share persistent state.
Authenticators can be configured with different primary or secondary Authenticators can be configured with different primary or secondary
EAP servers, in order to balance the load. Also, the authenticator EAP servers, in order to balance the load. Also, the authenticator
can dynamically determine the EAP server to which requests will be can dynamically determine the EAP server to which requests will be
sent; in event of a communication failure, the authenticator can fail sent; in the event of a communication failure, the authenticator can
over to another EAP server. For example, in Figure 3, Authenticator2 fail over to another EAP server. For example, in Figure 3,
can be initially configured with EAP server1 as its primary backend Authenticator2 can be initially configured with EAP server1 as its
authentication server, and EAP server2 as the backup, but if EAP primary backend authentication server, and EAP server2 as the backup,
server1 becomes unavailable, EAP server2 can become the primary but if EAP server1 becomes unavailable, EAP server2 can become the
server. primary server.
In general, the EAP peer cannot direct an authentication attempt to a In general, the EAP peer cannot direct an authentication attempt to a
particular EAP server within a realm; this decision is made by AAA particular EAP server within a realm, this decision is made by AAA
clients. Nor can the peer determine which EAP server it will be clients, nor can the peer determine with which EAP server it will be
communicating with, prior to the start of the EAP method communicating, prior to the start of the EAP method conversation.
conversation. The Server-Id is not included in the EAP- The Server-Id is not included in the EAP-Request/Identity, and since
Request/Identity, and since the EAP server may be determined the EAP server may be determined dynamically, it typically is not
dynamically, it typically is not possible for the authenticator to possible for the authenticator to advertise the Server-Id during the
advertise the Server-Id during the discovery phase. Some EAP methods discovery phase. Some EAP methods do not export the Server-Id so
do not export the Server-Id so that is is possible that the EAP peer that it is possible that the EAP peer will not learn with which
will not learn which server it was conversing with after the EAP server it was conversing after the EAP conversation completes
conversation completes successfully. successfully.
As a result, an EAP peer, on connecting to a new authenticator or As a result, an EAP peer, on connecting to a new authenticator or
reconnecting to the same authenticator, can find itself communicating reconnecting to the same authenticator, can find itself communicating
with a different EAP server. Fast reconnect, defined in [RFC3748] with a different EAP server. Fast reconnect, defined in [RFC3748]
Section 7.2, can fail if the EAP server that the peer communicates Section 7.2, can fail if the EAP server with which the peer
with is not the same one with which it initially established a communicates is not the same one with which it initially established
security association. For example, an EAP peer attempting an EAP-TLS a security association. For example, an EAP peer attempting an
session resume can find that the new EAP-TLS server will not have EAP-TLS session resume can find that the new EAP-TLS server will not
access to the TLS Master Key identified by the TLS Session-Id, and have access to the TLS Master Key identified by the TLS Session-Id,
therefore the session resumption attempt will fail, requiring and therefore the session resumption attempt will fail, requiring
completion of a full EAP-TLS exchange. completion of a full EAP-TLS exchange.
EAP methods that export the Server-Id MUST authenticate the server. EAP methods that export the Server-Id MUST authenticate the server.
However, not all EAP methods supporting mutual authentication provide However, not all EAP methods supporting mutual authentication provide
a non-null Server-Id; some methods only enable the EAP peer to verify a non-null Server-Id; some methods only enable the EAP peer to verify
that the EAP server possesses a long-term secret, but do not provide that the EAP server possesses a long-term secret, but do not provide
the identity of the EAP server. In this case the EAP peer will know the identity of the EAP server. In this case, the EAP peer will know
that an authenticator has been authorized by an EAP server, but will that an authenticator has been authorized by an EAP server, but will
not confirm the identity of the EAP server. Where the EAP method not confirm the identity of the EAP server. Where the EAP method
does not provide a Server-Id, the peer cannot identify the EAP server does not provide a Server-Id, the peer cannot identify the EAP server
with which it generated keying material. This can make it difficult with which it generated keying material. This can make it difficult
for the EAP peer to identify the location of a key possessed by that for the EAP peer to identify the location of a key possessed by that
EAP server. EAP server.
As noted in [I-D.simon-emu-rfc2716bis] Section 5.2, EAP methods As noted in [RFC5216] Section 5.2, EAP methods supporting
supporting authentication using server certificates can determine the authentication using server certificates can determine the Server-Id
Server-Id from the subject or subjectAltName fields in the server from the subject or subjectAltName fields in the server certificate.
certificate. Validating the EAP server identity can help the EAP Validating the EAP server identity can help the EAP peer to decide
peer to decide whether a specific EAP server is authorized. In some whether a specific EAP server is authorized. In some cases, such as
cases, such as where the certificate extensions defined in [RFC4334] where the certificate extensions defined in [RFC4334] are included in
are included in the server certificate, it can even be possible for the server certificate, it can even be possible for the peer to
the peer to verify some Channel Binding parameters from the server verify some channel binding parameters from the server certificate.
certificate.
It is possible for problems to arise in situations where the EAP It is possible for problems to arise in situations where the EAP
server identifies itself differently to the EAP peer and server identifies itself differently to the EAP peer and
authenticator. For example, it is possible that the Server-Id authenticator. For example, it is possible that the Server-Id
exported by EAP methods will not be identical to the Fully Qualified exported by EAP methods will not be identical to the Fully Qualified
Domain Name (FQDN) of the backend authentication server. Where Domain Name (FQDN) of the backend authentication server. Where
certificate-based authentication is used within RADIUS or Diameter, certificate-based authentication is used within RADIUS or Diameter,
it is possible that the subjectAltName used in the backend it is possible that the subjectAltName used in the backend
authentication server certificate will not be identical to the authentication server certificate will not be identical to the
Server-Id or backend authentication server FQDN. This is not Server-Id or backend authentication server FQDN. This is not
normally an issue in EAP, as the authenticator will be unaware of the normally an issue in EAP, as the authenticator will be unaware of the
identities used between the EAP peer and server. However, this can identities used between the EAP peer and server. However, this can
be an issue for key caching, if the authenticator is expected to be an issue for key caching, if the authenticator is expected to
locate a backend authentication server corresponding to a Server-Id locate a backend authentication server corresponding to a Server-Id
provided by an EAP peer. provided by an EAP peer.
Where the backend authentication server FQDN differs from the Where the backend authentication server FQDN differs from the
subjectAltName in the backend authentication server certificate, it subjectAltName in the backend authentication server certificate, it
is possible that the AAA client will not be able to determine whether is possible that the AAA client will not be able to determine whether
it is talking to the correct backend authentication server. Where it is talking to the correct backend authentication server. Where
the Server-Id and backend server FQDN differ, it is possible that the the Server-Id and backend authentication server FQDN differ, it is
combination of the key scope (Peer-Id(s), Server- Id(s)) and EAP possible that the combination of the key scope (Peer-Id(s), Server-
conversation identifier (Session-Id) will not be sufficient to Id(s)) and EAP conversation identifier (Session-Id) will not be
determine where the key resides. For example, the authenticator can sufficient to determine where the key resides. For example, the
identify backend servers by their IP address (as occurs in RADIUS), authenticator can identify backend authentication servers by their IP
or using a Fully Qualified Domain Name (as in Diameter). If the address (as occurs in RADIUS), or using a Fully Qualified Domain Name
Server-Id does not correspond to the IP address or FQDN of a known (as in Diameter). If the Server-Id does not correspond to the IP
backend authentication server, then it may not be possible to locate address or FQDN of a known backend authentication server, then it may
which backend authentication server possesses the key. not be possible to locate which backend authentication server
possesses the key.
3. Security Association Management 3. Security Association Management
EAP as defined in [RFC3748] supports key derivation, but does not EAP, as defined in [RFC3748], supports key derivation, but does not
provide for the management of lower layer security associations. provide for the management of lower-layer security associations.
Missing functionality includes: Missing functionality includes:
(a) Security Association negotiation. EAP does not negotiate lower (a) Security Association negotiation. EAP does not negotiate
layer unicast or multicast security associations, including lower-layer unicast or multicast security associations,
cryptographic algorithms or traffic profiles. EAP methods only including cryptographic algorithms or traffic profiles. EAP
negotiate cryptographic algorithms for their own use, not for the methods only negotiate cryptographic algorithms for their own
underlying lower layers. EAP also does not negotiate the traffic use, not for the underlying lower layers. EAP also does not
profiles to be protected with the negotiated ciphersuites; in some negotiate the traffic profiles to be protected with the
cases the traffic to be protected can have lower layer source and negotiated ciphersuites; in some cases the traffic to be
destination addresses different from the lower layer peer or protected can have lower-layer source and destination addresses
authenticator addresses. different from the lower-layer peer or authenticator addresses.
(b) Re-key. EAP does not support re-key of exported EAP keying (b) Re-key. EAP does not support the re-keying of exported EAP
material without EAP re-authentication, although EAP methods can keying material without EAP re-authentication, although EAP
support "fast reconnect" as defined in [RFC3748] Section 7.2.1. methods can support "fast reconnect" as defined in [RFC3748]
Section 7.2.1.
(c) Key delete/install semantics. EAP does not synchronize (c) Key delete/install semantics. EAP does not synchronize
installation or deletion of keying material on the EAP peer and installation or deletion of keying material on the EAP peer and
authenticator. authenticator.
(d) Lifetime negotiation. EAP does not support lifetime negotiation (d) Lifetime negotiation. EAP does not support lifetime negotiation
for exported EAP keying material, and existing EAP methods also do for exported EAP keying material, and existing EAP methods also
not support key lifetime negotiation. do not support key lifetime negotiation.
(e) Guaranteed TSK freshness. Without a post-EAP handshake, TSKs can (e) Guaranteed TSK freshness. Without a post-EAP handshake, TSKs
be reused if EAP keying material is cached. can be reused if EAP keying material is cached.
These deficiencies are typically addressed via a post-EAP handshake These deficiencies are typically addressed via a post-EAP handshake
known as the Secure Association Protocol. known as the Secure Association Protocol.
3.1. Secure Association Protocol 3.1. Secure Association Protocol
Since neither EAP nor EAP methods provide for establishment of lower Since neither EAP nor EAP methods provide for establishment of
layer security associations, it is RECOMMENDED that these facilities lower-layer security associations, it is RECOMMENDED that these
be provided within the Secure Association Protocol, including: facilities be provided within the Secure Association Protocol,
including:
(a) Entity Naming. A basic feature of a Secure Association Protocol is (a) Entity Naming. A basic feature of a Secure Association Protocol
the explicit naming of the parties engaged in the exchange. is 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. parameters negotiated during the EAP exchange is undefined.
(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
the backend authentication server and authenticator (e.g. MSK), in between the backend authentication server and authenticator
order to demonstrate that the peer and authenticator have been (e.g., MSK), in order to demonstrate that the peer and
authorized. Since mutual proof of possession is not the same as authenticator have been authorized. Since mutual proof of
mutual authentication, the peer cannot verify authenticator possession is not the same as mutual authentication, the peer
assertions (including the authenticator identity) as a result of cannot verify authenticator assertions (including the
this exchange. Authenticator identity verification is discussed in authenticator identity) as a result of this exchange.
Section 2.3. Authenticator identity verification is discussed in Section 2.3.
(c) Secure capabilities negotiation. In order to protect against (c) Secure capabilities negotiation. In order to protect against
spoofing during the discovery phase, ensure selection of the "best" spoofing during the discovery phase, ensure selection of the
ciphersuite, and protect against forging of negotiated security "best" ciphersuite, and protect against forging of negotiated
parameters, the Secure Association Protocol MUST support secure security parameters, the Secure Association Protocol MUST
capabilities negotiation. This includes the secure negotiation of support secure capabilities negotiation. This includes the
usage modes, session parameters (such as security association secure negotiation of usage modes, session parameters (such as
identifiers (SAIDs) and key lifetimes), ciphersuites and required security association identifiers (SAIDs) and key lifetimes),
filters, including confirmation of security-relevant capabilities ciphersuites and required filters, including confirmation of
discovered during phase 0. The Secure Association Protocol MUST security-relevant capabilities discovered during phase 0. The
support integrity and replay protection of all capability Secure Association Protocol MUST support integrity and replay
negotiation messages. protection of all capability negotiation messages.
(d) Key naming and selection. Where key caching is supported, it is (d) Key naming and selection. Where key caching is supported, it is
possible for the EAP peer and authenticator to share more than one possible for the EAP peer and authenticator to share more than
key of a given type. As a result, the Secure Association Protocol one key of a given type. As a result, the Secure Association
MUST explicitly name the keys used in the proof of possession Protocol MUST explicitly name the keys used in the proof of
exchange, so as to prevent confusion when more than one set of possession exchange, so as to prevent confusion when more than
keying material could potentially be used as the basis for the one set of keying material could potentially be used as the
exchange. Use of the key naming mechanism described in Section basis for the exchange. Use of the key naming mechanism
1.4.1 is RECOMMENDED. described in Section 1.4.1 is RECOMMENDED.
In order to support the correct processing of phase 2 security In order to support the correct processing of phase 2 security
associations, the Secure Association (phase 2) protocol MUST associations, the Secure Association (phase 2) protocol MUST
support the naming of phase 2 security associations and associated support the naming of phase 2 security associations and
transient session keys, so that the correct set of transient associated transient session keys so that the correct set of
session keys can be identified for processing a given packet. The transient session keys can be identified for processing a given
phase 2 Secure Association Protocol also MUST support transient packet. The phase 2 Secure Association Protocol also MUST
session key activation and SHOULD support deletion, so that support transient session key activation and SHOULD support
establishment and re-establishment of transient session keys can be deletion so that establishment and re-establishment of transient
synchronized between the parties. session keys can be synchronized between the parties.
(e) Generation of fresh transient session keys (TSKs). Where the lower (e) Generation of fresh transient session keys (TSKs). Where the
layer supports caching of keying material, the EAP peer lower layer lower layer supports caching of keying material, the EAP peer
can initiate a new session using keying material that was derived lower layer can initiate a new session using keying material
in a previous session. Were the TSKs to be derived solely from a that was derived in a previous session. Were the TSKs to be
portion of the exported EAP keying material, this would result in derived solely from a portion of the exported EAP keying
reuse of the session keys which could expose the underlying material, this would result in reuse of the session keys that
ciphersuite to attack. could expose the underlying ciphersuite to attack.
In lower layers where caching of keying material is supported, the In lower layers where caching of keying material is supported,
Secure Association Protocol phase is REQUIRED, and MUST support the the Secure Association Protocol phase is REQUIRED, and MUST
derivation of fresh unicast and multicast TSKs, even when the support the derivation of fresh unicast and multicast TSKs, even
transported keying material provided by the backend authentication when the transported keying material provided by the backend
server is not fresh. This is typically supported via the exchange authentication server is not fresh. This is typically supported
of nonces or counters, which are then mixed with the keying via the exchange of nonces or counters, which are then mixed
material in order to generate fresh unicast (phase 2a) and possibly with the keying material in order to generate fresh unicast
multicast (phase 2b) session keys. By not using exported EAP (phase 2a) and possibly multicast (phase 2b) session keys. By
keying material directly to protect data, the Secure Association not using exported EAP keying material directly to protect data,
Protocol protects it against compromise. the Secure Association Protocol 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 re-key of EAP negotiation or seamless re-key. EAP does not support the
keying material without re-authentication and existing EAP methods re-keying of EAP keying material without re-authentication, and
do not support key lifetime negotiation. As a result, the Secure existing EAP methods do not support key lifetime negotiation.
Association Protocol MAY handle re-key and determination of the key As a result, the Secure Association Protocol MAY handle the
lifetime. Where key caching is supported, secure negotiation of re-key and determination of the key lifetime. Where key caching
key lifetimes is RECOMMENDED. Lower layers that support re-key, is supported, secure negotiation of key lifetimes is
but not key caching, may not require key lifetime negotiation. For RECOMMENDED. Lower layers that support re-key, but not key
example, a difference between IKEv1 [RFC2409] and IKEv2 [RFC4306] caching, may not require key lifetime negotiation. For example,
is that in IKEv1 SA lifetimes were negotiated; in IKEv2, each end a difference between IKEv1 [RFC2409] and IKEv2 [RFC4306] is that
of the SA is responsible for enforcing its own lifetime policy on in IKEv1 SA lifetimes were negotiated; in IKEv2, each end of the
the SA and re-keying the SA when necessary. SA is responsible for enforcing its own lifetime policy on the
SA and re-keying the SA when necessary.
(g) Key state resynchronization. It is possible for the peer or (g) Key state 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
all of the key cache. Therefore, key lifetime negotiation cannot or all of the key cache. Therefore, key lifetime negotiation
guarantee that the key cache will remain synchronized, and it may cannot guarantee that the key cache will remain synchronized,
not be possible for the peer to determine before attempting to use and it may not be possible for the peer to determine before
a key whether it exists within the authenticator cache. It is attempting to use a key whether it exists within the
therefore RECOMMENDED for the EAP lower layer to provide a authenticator cache. It is therefore RECOMMENDED for the EAP
mechanism for key state resynchronization, either via the SAP or lower layer to provide a mechanism for key state
using a lower layer indication (see [RFC3748] Section 3.4). Where resynchronization, either via the SAP or using a lower layer
the peer and authenticator do not jointly possess a key with which indication (see [RFC3748] Section 3.4). Where the peer and
to protect the resynchronization exchange, secure resynchronization authenticator do not jointly possess a key with which to protect
is not possible and alternatives (such as a initiation of EAP re- the resynchronization exchange, secure resynchronization is not
authentication after expiration of a timer) is needed to ensure possible, and alternatives (such as an initiation of EAP
timely resynchronization. re-authentication after expiration of a timer) are needed to
ensure timely resynchronization.
(h) Key scope synchronization. To support key scope determination, the (h) Key scope synchronization. To support key scope determination,
Secure Association Protocol SHOULD provide a mechanism by which the the Secure Association Protocol SHOULD provide a mechanism by
peer can determine the scope of the key cache on each which the peer can determine the scope of the key cache on each
authenticator, and by which the authenticator can determine the authenticator and by which the authenticator can determine the
scope of the key cache on a peer. This includes negotiation of scope of the key cache on a peer. This includes negotiation of
restrictions on key usage. restrictions on key usage.
(i) Traffic profile negotiation. The traffic to be protected by a (i) Traffic profile negotiation. The traffic to be protected by a
lower layer security association will not necessarily have the same lower-layer security association will not necessarily have the
lower layer source or destination address as the EAP peer and same lower-layer source or destination address as the EAP peer
authenticator, and it is possible for the peer and authenticator to and authenticator, and it is possible for the peer and
negotiate multiple security associations, each with a different authenticator to negotiate multiple security associations, each
traffic profile. Where this is the case, the profile of protected with a different traffic profile. Where this is the case, the
traffic SHOULD be explicitly negotiated. For example, in IKEv2 it profile of protected traffic SHOULD be explicitly negotiated.
is possible for an Initiator and Responder to utilize EAP for For example, in IKEv2 it is possible for an Initiator and
authentication, then negotiate a Tunnel Mode Security Association Responder to utilize EAP for authentication, then negotiate a
(SA) which permits passing of traffic originating from hosts other Tunnel Mode Security Association (SA), which permits passing of
than the Initiator and Responder. Similarly, in IEEE 802.16e a traffic originating from hosts other than the Initiator and
Subscriber Station (SS) can forward traffic to the Base Station Responder. Similarly, in IEEE 802.16e, a Subscriber Station
(BS) which originates from the Local Area Network (LAN) to which it (SS) can forward traffic to the Base Station (BS), which
is attached. To enable this, Security Associations within IEEE originates from the Local Area Network (LAN) to which it is
802.16e are identified by the Connection Identifier (CID), not by attached. To enable this, Security Associations within IEEE
the EAP peer and authenticator MAC addresses. In both IKEv2 and 802.16e are identified by the Connection Identifier (CID), not
IEEE 802.16e, multiple security associations can exist between the by the EAP peer and authenticator MAC addresses. In both IKEv2
EAP peer and authenticator, each with their own traffic profile and and IEEE 802.16e, multiple security associations can exist
quality of service parameters. between the EAP peer and authenticator, each with their own
traffic profile and quality of service parameters.
(j) Direct operation. Since the phase 2 Secure Association Protocol is (j) Direct operation. Since the phase 2 Secure Association Protocol
concerned with the establishment of security associations between is concerned with the establishment of security associations
the EAP peer and authenticator, including the derivation of between the EAP peer and authenticator, including the derivation
transient session keys, only those parties have "a need to know" of transient session keys, only those parties have "a need to
the transient session keys. The Secure Association Protocol MUST know" the transient session keys. The Secure Association
operate directly between the peer and authenticator, and MUST NOT Protocol MUST operate directly between the peer and
be passed-through to the backend authentication server, or include authenticator and MUST NOT be passed-through to the backend
additional parties. authentication server or include additional parties.
(k) Bi-directional operation. While some ciphersuites only require a (k) Bi-directional operation. While some ciphersuites only require
single set of transient session keys to protect traffic in both a single set of transient session keys to protect traffic in
directions, other ciphersuites require a unique set of transient both directions, other ciphersuites require a unique set of
session keys in each direction. The phase 2 Secure Association transient session keys in each direction. The phase 2 Secure
Protocol SHOULD provide for the derivation of unicast and multicast Association Protocol SHOULD provide for the derivation of
keys in each direction, so as not to require two separate phase 2 unicast and multicast keys in each direction, so as not to
exchanges in order to create a bi-directional phase 2 security require two separate phase 2 exchanges in order to create a
association. See [RFC3748] Section 2.4 for more discussion. bi-directional phase 2 security association. See [RFC3748]
Section 2.4 for more discussion.
3.2. Key Scope 3.2. Key Scope
Absent explicit specification within the lower layer, after the Absent explicit specification within the lower layer, after the
completion of phase 1b, transported keying material and parameters completion of phase 1b, transported keying material, and parameters
are bound to the EAP peer and authenticator, but are not bound to a are bound to the EAP peer and authenticator, but are not bound to a
specific peer or authenticator port. specific peer or authenticator port.
While EAP keying material passed down to the lower layer is not While EAP keying material passed down to the lower layer is not
intrinsically bound to particular authenticator and peer ports, TSKs intrinsically bound to particular authenticator and peer ports, TSKs
MAY be bound to particular authenticator and peer ports by the Secure MAY be bound to particular authenticator and peer ports by the Secure
Association Protocol. However, a lower layer MAY also permit TSKs to Association Protocol. However, a lower layer MAY also permit TSKs to
be used on multiple peer and/or authenticator ports, providing that be used on multiple peer and/or authenticator ports, provided that
TSK freshness is guaranteed (such as by keeping replay counter state TSK freshness is guaranteed (such as by keeping replay counter state
within the authenticator). within the authenticator).
In order to further limit the key scope the following measures are In order to further limit the key scope, the following measures are
suggested: suggested:
(a) The lower layer MAY specify additional restrictions on key usage, (a) The lower layer MAY specify additional restrictions on key
such as limiting the use of EAP keying material and parameters on usage, such as limiting the use of EAP keying material and
the EAP peer to the port over which on the EAP conversation was parameters on the EAP peer to the port over which the EAP
conducted. conversation was conducted.
(b) The backend authentication server and authenticator MAY implement (b) The backend authentication server and authenticator MAY
additional attributes in order to further restrict the scope of implement additional attributes in order to further restrict the
keying material. For example, in IEEE 802.11, the backend scope of keying material. For example, in IEEE 802.11, the
authentication server can provide the authenticator with a list of backend authentication server can provide the authenticator with
authorized Called or Calling-Station-Ids and/or SSIDs for which a list of authorized Called or Calling-Station-Ids and/or SSIDs
keying material is valid. for which keying material is valid.
(c) Where the backend authentication server provides attributes (c) Where the backend authentication server provides attributes
restricting the key scope, it is RECOMMENDED that restrictions be restricting the key scope, it is RECOMMENDED that restrictions
securely communicated by the authenticator to the peer. This can be securely communicated by the authenticator to the peer. This
be accomplished using the Secure Association Protocol, but also can be accomplished using the Secure Association Protocol, but
can be accomplished via the EAP method or the lower layer. also can be accomplished via the EAP method or the lower layer.
3.3. Parent-Child Relationships 3.3. Parent-Child Relationships
When an EAP re-authentication takes place, new EAP keying material is When an EAP re-authentication takes place, new EAP keying material is
exported by the EAP method. In EAP lower layers where EAP re- exported by the EAP method. In EAP lower layers where EAP
authentication eventually results in TSK replacement, the maximum re-authentication eventually results in TSK replacement, the maximum
lifetime of derived keying material (including TSKs) can be less than lifetime of derived keying material (including TSKs) can be less than
or equal to that of EAP keying material (MSK/EMSK), but it cannot be or equal to that of EAP keying material (MSK/EMSK), but it cannot be
greater. greater.
Where TSKs are derived from or are wrapped by exported EAP keying Where TSKs are derived from or are wrapped by exported EAP keying
material, compromise of that exported EAP keying material implies material, compromise of that exported EAP keying material implies
compromise of TSKs. Therefore if EAP keying material is considered compromise of TSKs. Therefore, if EAP keying material is considered
stale, not only SHOULD EAP re-authentication be initiated, but also stale, not only SHOULD EAP re-authentication be initiated, but also
replacement of child keys, including TSKs. replacement of child keys, including TSKs.
Where EAP keying material is used only for entity authentication but Where EAP keying material is used only for entity authentication but
not for TSK derivation (as in IKEv2), compromise of exported EAP not for TSK derivation (as in IKEv2), compromise of exported EAP
keying material does not imply compromise of the TSKs. Nevertheless, keying material does not imply compromise of the TSKs. Nevertheless,
the compromise of EAP keying material could enable an attacker to the compromise of EAP keying material could enable an attacker to
impersonate an authenticator, so that EAP re-authentication and TSK impersonate an authenticator, so that EAP re-authentication and TSK
re-key are RECOMMENDED. re-key are RECOMMENDED.
With respect to IKEv2, "IKEv2 Clarifications and Implementation With respect to IKEv2, Section 5.2 of [RFC4718], "IKEv2
Guidelines" [RFC4718] Section 5.2 states: Clarifications and Implementation Guidelines", states:
Rekeying the IKE-SA and reuathentication are different concepts in Rekeying the IKE_SA and reauthentication are different concepts in
IKEv2. Rekeying the IKE_SA establishes new keys for the IKE_SA IKEv2. Rekeying the IKE_SA establishes new keys for the IKE_SA
and resets the Message ID counters, but it does not authenticate and resets the Message ID counters, but it does not authenticate
the parties again (no AUTH or EAP payloads are involved)... This the parties again (no AUTH or EAP payloads are involved)... This
means that reauthentication also establishes new keys for the means that reauthentication also establishes new keys for the
IKE_SA and CHILD_SAs. Therefore while rekeying can be performed IKE_SA and CHILD_SAs. Therefore while rekeying can be performed
more often than reauthentication, the situation where more often than reauthentication, the situation where
"authentication lifetime" is shorter than "key lifetime" does not "authentication lifetime" is shorter than "key lifetime" does not
make sense. make sense.
Child keys that are used frequently (such as TSKs which are used for Child keys that are used frequently (such as TSKs that are used for
traffic protection) can expire sooner than the exported EAP keying traffic protection) can expire sooner than the exported EAP keying
material they are dependent on, so that it is advantageous to support material on which they are dependent, so that it is advantageous to
re-key of child keys prior to EAP re-authentication. Note that support re-key of child keys prior to EAP re-authentication. Note
deletion of the MSK/EMSK does not necessarily imply deletion of TSKs that deletion of the MSK/EMSK does not necessarily imply deletion of
or child keys. TSKs or child keys.
Failure to mutually prove possession of exported EAP keying material Failure to mutually prove possession of exported EAP keying material
during the Secure Association Protocol exchange need not be grounds during the Secure Association Protocol exchange need not be grounds
for deletion of keying material by both parties; rate-limiting Secure for deletion of 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.4. 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
skipping to change at page 34, line 23 skipping to change at page 37, line 21
methods can re-key TEKs during an EAP conversation. methods can re-key TEKs during an EAP 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
used, TEK re-key MUST occur prior to wrapping of the counter. used, TEK re-key MUST occur prior to wrapping of the counter.
Similarly, TSKs MUST remain cryptographically separate from TEKs Similarly, TSKs MUST remain cryptographically separate from TEKs
despite TEK re-keying or caching. This prevents TEK compromise from despite TEK re-keying or caching. This prevents TEK compromise from
leading directly to compromise of the TSKs and vice versa. leading directly to compromise of the TSKs and vice versa.
EAP methods MAY cache local EAP keying material (TEKs) which can EAP methods MAY cache local EAP keying material (TEKs) that can
persist for multiple EAP conversations when fast reconnect is used persist for multiple EAP conversations when fast reconnect is used
[RFC3748]. For example, EAP methods based on TLS (such as EAP-TLS [RFC3748]. For example, EAP methods based on TLS (such as EAP-TLS
[I-D.simon-emu-rfc2716bis]) derive and cache the TLS Master Secret, [RFC5216]) derive and cache the TLS Master Secret, typically for
typically for substantial time periods. The lifetime of other local substantial time periods. The lifetime of other local EAP keying
EAP keying material calculated within the EAP method is defined by material calculated within the EAP method is defined by the method.
the method. Note that in general, when using fast reconnect, there Note that in general, when using fast reconnect, there is no
is no guarantee to that the original long-term credentials are still guarantee that the original long-term credentials are still in the
in the possession of the peer. For instance, a smart-card holding possession of the peer. For instance, a smart-card holding the
the private key for EAP-TLS can have been removed. EAP servers private key for EAP-TLS may have been removed. EAP servers SHOULD
SHOULD also verify that the long-term credentials are still valid, also verify that the long-term credentials are still valid, such as
such as by checking that certificate used in the original by checking that certificate used in the original authentication has
authentication has not yet expired. not yet expired.
3.5. Exported and Calculated Key Lifetimes 3.5. Exported and Calculated Key Lifetimes
The following mechanisms are available for communicating the lifetime The following mechanisms are available for communicating the lifetime
of keying material between the EAP peer, server and authenticator: of keying material between the EAP peer, server, and authenticator:
AAA protocols (backend server and authenticator) AAA protocols (backend authentication server and authenticator)
Lower layer mechanisms (authenticator and peer) Lower-layer mechanisms (authenticator and peer)
EAP method-specific negotiation (peer and server) EAP method-specific negotiation (peer and server)
Where the EAP method does not support the negotiation of the lifetime Where the EAP method does not support the negotiation of the lifetime
of exported EAP keying material, and a key lifetime negotiation of exported EAP keying material, and a key lifetime negotiation
mechanism is not provided by the lower layer, it is possible that mechanism is not provided by the lower layer, it is possible that
there will not be a way for the peer to learn the lifetime of keying there will not be a way for the peer to learn the lifetime of keying
material. This can leave the peer uncertain how long the material. This can leave the peer uncertain of how long the
authenticator will maintain keying material within the key cache. In authenticator will maintain keying material within the key cache. In
this case the lifetime of keying material can be managed as a system this case the lifetime of keying material can be managed as a system
parameter on the peer and authenticator; a default lifetime of 8 parameter on the peer and authenticator; a default lifetime of 8
hours is RECOMMENDED. hours is RECOMMENDED.
3.5.1. AAA Protocols 3.5.1. AAA Protocols
AAA protocols such as RADIUS [RFC2865] and Diameter [RFC4072] can be AAA protocols such as RADIUS [RFC2865] and Diameter [RFC4072] can be
used to communicate the maximum key lifetime from the backend used to communicate the maximum key lifetime from the backend
authentication server to the authenticator. authentication server to the authenticator.
The Session-Timeout attribute is defined for RADIUS in [RFC2865] and The Session-Timeout Attribute is defined for RADIUS in [RFC2865] and
for Diameter in [RFC4005]. Where EAP is used for authentication, for Diameter in [RFC4005]. Where EAP is used for authentication,
[RFC3580] Section 3.17 indicates that a Session-Timeout attribute [RFC3580] Section 3.17, indicates that a Session-Timeout Attribute
sent in an Access-Accept along with a Termination-Action value of sent in an Access-Accept along with a Termination-Action value of
RADIUS-Request specifies the maximum number of seconds of service RADIUS-Request specifies the maximum number of seconds of service
provided prior to EAP re-authentication. provided prior to EAP re-authentication.
However, there is also a need to be able to specify the maximum However, there is also a need to be able to specify the maximum
lifetime of cached keying material. Where EAP pre-authentication is lifetime of cached keying material. Where EAP pre-authentication is
supported, cached keying material can be pre-established on the supported, cached keying material can be pre-established on the
authenticator prior to session start, and will remain there until authenticator prior to session start and will remain there until
expiration. EAP lower layers supporting caching of keying material expiration. EAP lower layers supporting caching of keying material
MAY also persist that material after the end of a session, enabling MAY also persist that material after the end of a session, enabling
the peer to subsequently resume communication utilizing the cached the peer to subsequently resume communication utilizing the cached
keying material. In these situations it can be desirable for the keying material. In these situations it can be desirable for the
backend authentication server to specify the maximum lifetime of backend authentication server to specify the maximum lifetime of
cached keying material. cached keying material.
To accomplish this, [IEEE-802.11] overloads the Session-Timeout To accomplish this, [IEEE-802.11] overloads the Session-Timeout
attribute, assuming that it represents the maximum time after which Attribute, assuming that it represents the maximum time after which
transported keying material will expire on the authenticator, transported keying material will expire on the authenticator,
regardless of whether transported keying material is cached. regardless of whether transported keying material is cached.
An IEEE 802.11 authenticator receiving transported keying material is An IEEE 802.11 authenticator receiving transported keying material is
expected to initialize a timer to the Session-Timeout value, and once expected to initialize a timer to the Session-Timeout value, and once
the timer expires, the transported keying material expires. Whether the timer expires, the transported keying material expires. Whether
this results in session termination or EAP re-authentication is this results in session termination or EAP re-authentication is
controlled by the value of the Termination-Action attribute. Where controlled by the value of the Termination-Action Attribute. Where
EAP re-authentication occurs the transported keying material is EAP re-authentication occurs, the transported keying material is
replaced, and with it, new calculated keys are put in place. Where replaced, and with it, new calculated keys are put in place. Where
session termination occurs, transported and derived keying material session termination occurs, transported and derived keying material
is deleted. is deleted.
Overloading the Session-Timeout attribute is problematic in Overloading the Session-Timeout Attribute is problematic in
situations where it is necessary to control the maximum session time situations where it is necessary to control the maximum session time
and key lifetime independently. For example, it might be desirable and key lifetime independently. For example, it might be desirable
to limit the lifetime of cached keying material to 5 minutes while to limit the lifetime of cached keying material to 5 minutes while
permitting a user once authenticated to remain connected for up to an permitting a user once authenticated to remain connected for up to an
hour without re-authenticating. As a result, in the future hour without re-authenticating. As a result, in the future,
additional attributes can be specified to control the lifetime of additional attributes can be specified to control the lifetime of
cached keys; these attributes MAY modify the meaning of the Session- cached keys; these attributes MAY modify the meaning of the
Timeout attribute in specific circumstances. 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, and the backend authentication server has no insight into resources, and the backend authentication server has no insight into
the TSK derivation process, by the principle of ciphersuite the TSK derivation process 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, including server to manage any aspect of the TSK derivation process, including
the TSK lifetime. the TSK lifetime.
3.5.2. Lower Layer Mechanisms 3.5.2. Lower-Layer Mechanisms
Lower layer mechanisms can be used to enable the lifetime of keying Lower-layer mechanisms can be used to enable the lifetime of keying
material to be negotiated between the peer and authenticator. This material to be negotiated between the peer and authenticator. This
can be accomplished either using the Secure Association Protocol or can be accomplished either using the Secure Association Protocol or
within the lower layer transport. within the lower-layer transport.
Where TSKs are established as the result of a Secure Association Where TSKs are established as the result of a Secure Association
Protocol exchange, it is RECOMMENDED that the Secure Association Protocol exchange, it is RECOMMENDED that the Secure Association
Protocol include support for TSK re-key. Where the TSK is taken Protocol include support for TSK re-key. Where the TSK is taken
directly from the MSK, there is no need to manage the TSK lifetime as directly from the MSK, there is no need to manage the TSK lifetime as
a separate parameter, since the TSK lifetime and MSK lifetime are a separate parameter, since the TSK lifetime and MSK lifetime are
identical. identical.
3.5.3. EAP Method-Specific Negotiation 3.5.3. EAP Method-Specific Negotiation
As noted in [RFC3748] Section 7.10: As noted in [RFC3748] Section 7.10:
In order to provide keying material for use in a subsequently In order to provide keying material for use in a subsequently
negotiated ciphersuite, an EAP method supporting key derivation negotiated ciphersuite, an EAP method supporting key derivation
MUST export a Master Session Key (MSK) of at least 64 octets, and MUST export a Master Session Key (MSK) of at least 64 octets, and
an Extended Master Session Key (EMSK) of at least 64 octets. EAP an Extended Master Session Key (EMSK) of at least 64 octets. EAP
Methods deriving keys MUST provide for mutual authentication Methods deriving keys MUST provide for mutual authentication
between the EAP peer and the EAP Server. between the EAP peer and the EAP Server.
However, EAP does not itself support the negotiation of lifetimes for However, EAP does not itself support the negotiation of lifetimes for
exported EAP keying material such as the MSK, EMSK and IV. exported EAP keying material such as the MSK, EMSK, and IV.
While EAP itself does not support lifetime negotiation, it would be While EAP itself does not support lifetime negotiation, it would be
possible to specify methods that do. However, systems that rely on possible to specify methods that do. However, systems that rely on
key lifetime negotiation within EAP methods would only function with key lifetime negotiation within EAP methods would only function with
these methods. Also, there is no guarantee that the key lifetime these methods. Also, there is no guarantee that the key lifetime
negotiated within the EAP method would be compatible with backend negotiated within the EAP method would be compatible with backend
authentication server policy. In the interest of method independence authentication server policy. In the interest of method independence
and compatibility with backend server implementations, management of and compatibility with backend authentication server implementations,
the lifetime of keying material SHOULD NOT be provided within EAP management of the lifetime of keying material SHOULD NOT be provided
methods. within EAP methods.
3.6. Key Cache Synchronization 3.6. Key Cache Synchronization
Key lifetime negotiation alone cannot guarantee key cache Key lifetime negotiation alone cannot guarantee key cache
synchronization. Even where a lower layer exchange is run synchronization. Even where a lower-layer exchange is run
immediately after EAP in order to determine the lifetime of keying immediately after EAP in order to determine the lifetime of keying
material, it is still possible for the authenticator to purge all or material, it is still possible for the authenticator to purge all or
part of the key cache prematurely (e.g. due to reboot or need to part of the key cache prematurely (e.g., due to reboot or need to
reclaim memory). reclaim memory).
The lower layer can utilize the Discovery phase 0 to improve key The lower layer can utilize the Discovery phase 0 to improve key
cache synchronization. For example, if the authenticator manages the cache synchronization. For example, if the authenticator manages the
key cache by deleting the oldest key first, the relative creation key cache by deleting the oldest key first, the relative creation
time of the last key to be deleted could be advertised within the time of the last key to be deleted could be advertised within the
Discovery phase, enabling the peer to determine whether keying Discovery phase, enabling the peer to determine whether keying
material had been prematurely expired from the authenticator key material had been prematurely expired from the authenticator key
cache. cache.
skipping to change at page 37, line 38 skipping to change at page 40, line 37
EAP key generation to represent the weakest link. EAP key generation to represent the weakest link.
In order to ensure that methods produce EAP keying material of an In order to ensure that methods produce EAP keying material of an
appropriate symmetric key strength, it is RECOMMENDED that EAP appropriate symmetric key strength, 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 providing the required level of attack has a cryptographic strength providing the required level of attack
resistance. This is typically provided by configuring EAP methods, resistance. This is typically provided by configuring EAP methods,
since there is no coordination between the lower layer and EAP method since there is no coordination between the lower layer and EAP method
with respect to minimum required symmetric key strength. with respect to minimum required symmetric key strength.
BCP 86 [RFC3766] Section 5 offers advice on the required RSA or DH Section 5 of BCP 86 [RFC3766] offers advice on the required RSA or DH
module and DSA subgroup size in bits, for a given level of attack module and DSA subgroup size in bits, for a given level of attack
resistance in bits. The National Institute for Standards and resistance in bits. The National Institute for Standards and
Technology (NIST) also offers advice on appropriate key sizes in Technology (NIST) also offers advice on appropriate key sizes in
[SP800-57]. [SP800-57].
3.8. Key Wrap 3.8. Key Wrap
The key wrap specified in [RFC2548], which is based on an MD5-based The key wrap specified in [RFC2548], which is based on an MD5-based
stream cipher, has known problems, as described in [RFC3579] Section stream cipher, has known problems, as described in [RFC3579] Section
4.3. RADIUS uses the shared secret for multiple purposes, including 4.3. RADIUS uses the shared secret for multiple purposes, including
per-packet authentication and attribute hiding, considerable per-packet authentication and attribute hiding, considerable
information is exposed about the shared secret with each packet. information is exposed about the shared secret with each packet.
This exposes the shared secret to dictionary attacks. MD5 is used This exposes the shared secret to dictionary attacks. MD5 is used
both to compute the RADIUS Response Authenticator and the Message- both to compute the RADIUS Response Authenticator and the
Authenticator attribute, and concerns exist relating to the security Message-Authenticator Attribute, and concerns exist relating to the
of this hash [MD5Collision]. security of this hash [MD5Collision].
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, [RFC3579] Section 4.2 substantially improve security. As a result, [RFC3579] 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 clear-text key attributes, to Diameter EAP [RFC4072], which in Section 4.1.3 defines the
EAP-Master-Session-Key Attribute-Value Pair (AVP) in clear-text, to
be protected by IPsec or TLS. be protected by IPsec or TLS.
4. Handoff Vulnerabilities 4. Handoff Vulnerabilities
A handoff occurs when an EAP peer moves to a new authenticator. A handoff occurs when an EAP peer moves to a new authenticator.
Several mechanisms have been proposed for reducing handoff latency Several mechanisms have been proposed for reducing handoff latency
within networks utilizing EAP. These include: within networks utilizing EAP. These include:
EAP pre-authentication EAP pre-authentication
In EAP pre-authentication, an EAP peer pre-establishes EAP keying In EAP pre-authentication, an EAP peer pre-establishes EAP keying
material with an authenticator prior to arrival. EAP pre- material with an authenticator prior to arrival. EAP
authentication only affects the timing of EAP authentication, but pre-authentication only affects the timing of EAP authentication,
does not shorten or eliminate EAP (phase 1a) or AAA (phase 1b) but does not shorten or eliminate EAP (phase 1a) or AAA (phase 1b)
exchanges; Discovery (phase 0) and Secure Association Protocol exchanges; Discovery (phase 0) and Secure Association Protocol
(phase 2) exchanges occur as described in Section 1.3. As a (phase 2) exchanges occur as described in Section 1.3. As a
result, the primary benefit is to enable EAP authentication to be result, the primary benefit is to enable EAP authentication to be
removed from the handoff critical path, thereby reducing latency. removed from the handoff critical path, thereby reducing latency.
Use of EAP pre-authentication within IEEE 802.11 is described in Use of EAP pre-authentication within IEEE 802.11 is described in
[IEEE-802.11] and [8021XPreAuth]. [IEEE-802.11] and [8021XPreAuth].
Proactive key distribution Proactive key distribution
In proactive key distribution, keying material and authorizations In proactive key distribution, keying material and authorizations
are transported from the backend authentication server to a are transported from the backend authentication server to a
candidate authenticator in advance of a handoff. As a result, EAP candidate authenticator in advance of a handoff. As a result, EAP
(phase 1a) is not needed, but the Discovery (phase 0), and Secure (phase 1a) is not needed, but the Discovery (phase 0), and Secure
Association Protocol exchanges (phase 2) are still necessary. Association Protocol exchanges (phase 2) are still necessary.
Within the AAA exchange (phase 1b), authorization and key Within the AAA exchange (phase 1b), authorization and key
distribution functions are typically supported, but not distribution functions are typically supported, but not
authentication. Proactive key distribution is described in authentication. Proactive key distribution is described in
[MishraPro], [IEEE-03-084] and [I-D.irtf-aaaarch-handoff]. [MishraPro], [IEEE-03-084], and [HANDOFF].
Key caching Key caching
Caching of EAP keying material enables an EAP peer to re-attach to Caching of EAP keying material enables an EAP peer to re-attach to
an authenticator without requiring EAP (phase 1a) or AAA (phase 1b) an authenticator without requiring EAP (phase 1a) or AAA (phase
exchanges. However, Discovery (phase 0) and Secure Association 1b) exchanges. However, Discovery (phase 0) and Secure
Protocol (phase 2) exchanges are still needed. Use of key caching Association Protocol (phase 2) exchanges are still needed. Use of
within IEEE 802.11 is described in [IEEE-802.11]. key caching within IEEE 802.11 is described in [IEEE-802.11].
Context transfer Context transfer
In context transfer schemes, keying material and authorizations are In context transfer schemes, keying material and authorizations
transferred between a previous authenticator and a new are transferred between a previous authenticator and a new
authenticator. This can occur in response to a handoff request by authenticator. This can occur in response to a handoff request by
the EAP peer, or in advance, as in proactive key distribution. As the EAP peer, or in advance, as in proactive key distribution. As
a result, EAP (phase 1a) is eliminated, but not the Discovery a result, EAP (phase 1a) is eliminated, but not the Discovery
(phase 0) or Secure Association Protocol exchanges (phase 2). If a (phase 0) or Secure Association Protocol exchanges (phase 2). If
secure channel can be established between the new and previous a secure channel can be established between the new and previous
authenticator without assistance from the backend authentication authenticator without assistance from the backend authentication
server, then the AAA exchange (phase 1b) can be eliminated; server, then the AAA exchange (phase 1b) can be eliminated;
otherwise, it is still needed, although it can be shortened. otherwise, it is still needed, although it can be shortened.
Context transfer protocols are described in [IEEE-802.11F] (now Context transfer protocols are described in [IEEE-802.11F] (now
deprecated) and "Context Transfer Protocol (CXTP)" [RFC4067]. deprecated) and "Context Transfer Protocol (CXTP)" [RFC4067].
"Fast Authentication Methods for Handovers between IEEE 802.11 "Fast Authentication Methods for Handovers between IEEE 802.11
Wireless LANs" [Bargh] analyzes fast handoff techniques, including Wireless LANs" [Bargh] analyzes fast handoff techniques, including
context transfer mechanisms. context transfer mechanisms.
Token distribution Token distribution
In token distribution schemes the EAP peer is provided with a In token distribution schemes, the EAP peer is provided with a
credential, subsequently enabling it to authenticate with one or credential, subsequently enabling it to authenticate with one or
more additional authenticators. During the subsequent more additional authenticators. During the subsequent
authentications, EAP (phase 1a) is eliminated or shortened; the authentications, EAP (phase 1a) is eliminated or shortened; the
Discovery (phase 0) and Secure Association Protocol exchanges Discovery (phase 0) and Secure Association Protocol exchanges
(phase 2) still occur, although the latter can be shortened. If (phase 2) still occur, although the latter can be shortened. If
the token includes authorizations and can be validated by an the token includes authorizations and can be validated by an
authenticator without assistance from the backend authentication authenticator without assistance from the backend authentication
server, then the AAA exchange (phase 1b) can be eliminated; server, then the AAA exchange (phase 1b) can be eliminated;
otherwise it is still needed, although it can be shortened. Token- otherwise, it is still needed, although it can be shortened.
based schemes, initially proposed in early drafts of IEEE 802.11i Token-based schemes, initially proposed in early versions of IEEE
[IEEE-802.11i], are described in [Token], [Tokenk] and 802.11i [IEEE-802.11i], are described in [Token], [Tokenk], and
[I-D.friedman-ike-short-term-certs]. [SHORT-TERM].
The sections that follow discuss the security vulnerabilities The sections that follow discuss the security vulnerabilities
introduced by the above schemes. introduced by the above schemes.
4.1. EAP Pre-authentication 4.1. EAP Pre-Authentication
EAP pre-authentication differs from a normal EAP conversation EAP pre-authentication differs from a normal EAP conversation
primarily with respect to the lower layer encapsulation. For primarily with respect to the lower-layer encapsulation. For
example, in [IEEE-802.11], EAP pre-authentication frames utilize a example, in [IEEE-802.11], EAP pre-authentication frames utilize a
distinct Ethertype, but otherwise conforms to the encapsulation distinct Ethertype, but otherwise conforms to the encapsulation
described in [IEEE-802.1X]. As a result, an EAP pre-authentication described in [IEEE-802.1X]. As a result, an EAP pre-authentication
conversation differs little from the model described in Section 1.3, conversation differs little from the model described in Section 1.3,
other than the introduction of a delay between phase 1 and phase 2. other than the introduction of a delay between phase 1 and phase 2.
EAP pre-authentication relies on lower layer mechanisms for discovery EAP pre-authentication relies on lower-layer mechanisms for discovery
of candidate authenticators. Where discovery can provide information of candidate authenticators. Where discovery can provide information
on candidate authenticators outside the immediate listening range, on candidate authenticators outside the immediate listening range,
and the peer can determine whether it already possesses valid EAP and the peer can determine whether it already possesses valid EAP
keying material with candidate authenticators, the peer can avoid keying material with candidate authenticators, the peer can avoid
unnecessary EAP pre-authentications and can establish EAP keying unnecessary EAP pre-authentications and can establish EAP keying
material well in advance, regardless of the coverage overlap between material well in advance, regardless of the coverage overlap between
authenticators. However, if the peer can only discover candidate authenticators. However, if the peer can only discover candidate
authenticators within listening range and cannot determine whether it authenticators within listening range and cannot determine whether it
can reuse existing EAP keying material, then it is possible that the can reuse existing EAP keying material, then it is possible that the
peer will not be able to complete EAP pre-authentication prior to peer will not be able to complete EAP pre-authentication prior to
connectivity loss or that it can pre-authenticate multiple times with connectivity loss or that it can pre-authenticate multiple times with
the same authenticator, increasing backend authentication server the same authenticator, increasing backend authentication server
load. load.
Since a peer can complete EAP pre-authentication with an Since a peer can complete EAP pre-authentication with an
authenticator without eventually attaching to it, it is possible that authenticator without eventually attaching to it, it is possible that
phase 2 will not occur. In this case an Accounting-Request phase 2 will not occur. In this case, an Accounting-Request
signifying the start of service will not be sent, or will only be signifying the start of service will not be sent, or will only be
sent with a substantial delay after the completion of authentication. sent with a substantial delay after the completion of authentication.
As noted in "IEEE 802.1X RADIUS Usage Guidelines" [RFC3580], the AAA As noted in "IEEE 802.1X RADIUS Usage Guidelines" [RFC3580], the AAA
exchange resulting from EAP pre-authentication differs little from an exchange resulting from EAP pre-authentication differs little from an
ordinary exchange described in "RADIUS Support for EAP" [RFC3579]. ordinary exchange described in "RADIUS Support for EAP" [RFC3579].
For example, since in IEEE 802.11 [IEEE-802.11] an Association For example, since in IEEE 802.11 [IEEE-802.11] an Association
exchange does not occur prior to EAP pre-authentication, the SSID is exchange does not occur prior to EAP pre-authentication, the SSID is
not known by the authenticator at authentication time, so that an not known by the authenticator at authentication time, so that an
Access-Request cannot include the SSID within the Called-Station-Id Access-Request cannot include the SSID within the Called-Station-Id
attribute as described in [RFC3580] Section 3.20. attribute as described in [RFC3580] Section 3.20.
Since only the absence of an SSID in the Called-Station-Id attribute Since only the absence of an SSID in the Called-Station-Id attribute
distinguishes an EAP pre-authentication attempt, if the authenticator distinguishes an EAP pre-authentication attempt, if the authenticator
does not always include the SSID for a normal EAP authentication does not always include the SSID for a normal EAP authentication
attempt, it is possible that the backend authentication server will attempt, it is possible that the backend authentication server will
not be able to determine whether a session constitutes an EAP pre- not be able to determine whether a session constitutes an EAP
authentication attempt, potentially resulting in authorization or pre-authentication attempt, potentially resulting in authorization or
accounting problems. Where the number of simultaneous sessions is accounting problems. Where the number of simultaneous sessions is
limited, the backend authentication server can refuse to authorize a limited, the backend authentication server can refuse to authorize a
valid EAP pre-authentication attempt or can enable the peer to engage valid EAP pre-authentication attempt or can enable the peer to engage
in more simultaneous sessions than they are authorized for. Where in more simultaneous sessions than they are authorized for. Where
EAP pre-authentication occurs with an authenticator which the peer EAP pre-authentication occurs with an authenticator which the peer
never attaches to, it is possible that the backend accounting server never attaches to, it is possible that the backend accounting server
will not be able to determine whether the absence of an Accounting- will not be able to determine whether the absence of an
Request was due to packet loss or a session that never started. Accounting-Request was due to packet loss or a session that never
started.
In order to enable pre-authentication requests to be handled more In order to enable pre-authentication requests to be handled more
reliably, it is RECOMMENDED that AAA protocols explicitly identify reliably, it is RECOMMENDED that AAA protocols explicitly identify
EAP pre-authentication. In order to suppress unnecessary EAP pre- EAP pre-authentication. In order to suppress unnecessary EAP
authentication exchanges, it is RECOMMENDED that authenticators pre-authentication exchanges, it is RECOMMENDED that authenticators
unambiguously identify themselves as described in Section 2.3. unambiguously identify themselves as described in Section 2.3.
4.2. Proactive Key Distribution 4.2. Proactive Key Distribution
In proactive key distribution schemes, the backend authentication In proactive key distribution schemes, the backend authentication
server transports keying material and authorizations to an server transports keying material and authorizations to an
authenticator in advance of the arrival of the peer. The authenticator in advance of the arrival of the peer. The
authenticators selected to receive the transported key material are authenticators selected to receive the transported key material are
selected based on past patterns of peer movement between selected based on past patterns of peer movement between
authenticators known as the "neighbor graph". In order to reduce authenticators known as the "neighbor graph". In order to reduce
skipping to change at page 41, line 26 skipping to change at page 45, line 8
backend authentication server is not provided with proof that the backend authentication server is not provided with proof that the
peer successfully authenticated to an authenticator; instead, the peer successfully authenticated to an authenticator; instead, the
authenticator generates a stream of accounting messages without a authenticator generates a stream of accounting messages without a
corresponding set of authentication exchanges. As described in corresponding set of authentication exchanges. As described in
[MishraPro], knowledge of the neighbor graph can be established via [MishraPro], knowledge of the neighbor graph can be established via
static configuration or analysis of authentication exchanges. In static configuration or analysis of authentication exchanges. In
order to prevent corruption of the neighbor graph, new neighbor graph order to prevent corruption of the neighbor graph, new neighbor graph
entries can only be created as the result of a successful EAP entries can only be created as the result of a successful EAP
exchange, and accounting packets with no corresponding authentication exchange, and accounting packets with no corresponding authentication
exchange need to be verified to correspond to neighbor graph entries exchange need to be verified to correspond to neighbor graph entries
(e.g. corresponding to handoffs between neighbors). (e.g., corresponding to handoffs between neighbors).
In order to prevent compromise of one authenticator from resulting in In order to prevent compromise of one authenticator from resulting in
compromise of other authenticators, cryptographic separation needs compromise of other authenticators, cryptographic separation needs to
to be maintained between the keying material transported to each be maintained between the keying material transported to each
authenticator. However, even where cryptographic separation is authenticator. However, even where cryptographic separation is
maintained, an attacker compromising an authenticator can still maintained, an attacker compromising an authenticator can still
disrupt the operation of other authenticators. As noted in [RFC3579] disrupt the operation of other authenticators. As noted in [RFC3579]
Section 4.3.7, in the absence of spoofing detection within the AAA Section 4.3.7, in the absence of spoofing detection within the AAA
infrastructure, it is possible for EAP authenticators to impersonate infrastructure, it is possible for EAP authenticators to impersonate
each other. By forging NAS identification attributes within each other. By forging NAS identification attributes within
authentication messages, an attacker compromising one authenticator authentication messages, an attacker compromising one authenticator
could corrupt the neighbor graph, tricking the backend authentication could corrupt the neighbor graph, tricking the backend authentication
server into transporting keying material to arbitrary authenticators. server into transporting keying material to arbitrary authenticators.
While this would not enable recovery of EAP keying material without While this would not enable recovery of EAP keying material without
breaking fundamental cryptographic assumptions, it could enable breaking fundamental cryptographic assumptions, it could enable
subsequent fraudulent accounting messages, or allow an attacker to subsequent fraudulent accounting messages, or allow an attacker to
disrupt service by increasing load on the backend authentication disrupt service by increasing load on the backend authentication
server or thrashing the authenticator key cache. server or thrashing the authenticator key cache.
Since proactive key distribution requires the distribution of derived Since proactive key distribution requires the distribution of derived
keying material to candidate authenticators, the effectiveness of keying material to candidate authenticators, the effectiveness of
this scheme depends on the ability of backend authentication server this scheme depends on the ability of backend authentication server
to anticipate the movement of the EAP peer. Since proactive key to anticipate the movement of the EAP peer. Since proactive key
distribution relies on backend authentication server knowledge of the distribution relies on backend authentication server knowledge of the
neighbor graph it is most applicable to intra-domain handoff neighbor graph, it is most applicable to intra-domain handoff
scenarios. However, in inter-domain handoff where there can be many scenarios. However, in inter-domain handoff, where there can be many
authenticators, peers can frequently connect to authenticators that authenticators, peers can frequently connect to authenticators that
have not been previously encountered, making it difficult for the have not been previously encountered, making it difficult for the
backend authentication server to derive a complete neighbor graph. backend authentication server to derive a complete neighbor graph.
Since proactive key distribution schemes typically require Since proactive key distribution schemes typically require
introduction of server-initiated messages as described in introduction of server-initiated messages as described in [RFC5176]
[RFC3576bis] and [I-D.irtf-aaaarch-handoff], security issues and [HANDOFF], security issues described in [RFC5176] Section 6 are
described in [RFC3576bis] Section 6 are applicable, including applicable, including authorization (Section 6.1) and replay
authorization (Section 6.1) and replay detection (Section 6.3) detection (Section 6.3) problems.
problems.
4.3. AAA Bypass 4.3. AAA Bypass
Fast handoff techniques which enable elimination of the AAA exchange Fast handoff techniques that enable elimination of the AAA exchange
(phase 1b) differ fundamentally from typical network access scenarios (phase 1b) differ fundamentally from typical network access scenarios
(dial-up, wired LAN, etc.) which include user authentication as well (dial-up, wired LAN, etc.) that include user authentication as well
as authorization for the offered service. Where the AAA exchange as authorization for the offered service. Where the AAA exchange
(phase 1b) is omitted, authorizations and keying material are not (phase 1b) is omitted, authorizations and keying material are not
provided by the backend authentication server, and as a result they provided by the backend authentication server, and as a result, they
need to be supplied by other means. This section describes some of need to be supplied by other means. This section describes some of
the implications. the implications.
4.3.1. Key Transport 4.3.1. Key Transport
Where transported keying material is not supplied by the backend Where transported keying material is not supplied by the backend
authentication server, it needs to be provided by another party authentication server, it needs to be provided by another party
authorized to access that keying material. As noted in Section 1.5, authorized to access that keying material. As noted in Section 1.5,
only the EAP peer, authenticator and server are authorized to possess only the EAP peer, authenticator, and server are authorized to
transported keying material. Since EAP peers do not trust each possess transported keying material. Since EAP peers do not trust
other, if the backend authentication server does not supply each other, if the backend authentication server does not supply
transported keying material to a new authenticator, it can only be transported keying material to a new authenticator, it can only be
provided by a previous authenticator. provided by a previous authenticator.
As noted in Section 1.5, the goal of the EAP conversation is to As noted in Section 1.5, the goal of the EAP conversation is to
derive session keys known only to the peer and the authenticator. If derive session keys known only to the peer and the authenticator. If
keying material is replicated between a previous authenticator and a keying material is replicated between a previous authenticator and a
new authenticator, then the previous authenticator can possess new authenticator, then the previous authenticator can possess
session keys used between the peer and new authenticator. Also, the session keys used between the peer and new authenticator. Also, the
new authenticator can possess session keys used between the peer and new authenticator can possess session keys used between the peer and
the previous authenticator. the previous authenticator.
skipping to change at page 43, line 34 skipping to change at page 47, line 21
(d) Is the user within the concurrent session limit? (d) Is the user within the concurrent session limit?
(e) Are there any fraud, credit limit, or other concerns that could (e) Are there any fraud, credit limit, or other concerns that could
lead to access denial? lead to access denial?
(f) If access is to be granted, what are the service parameters (f) If access is to be granted, what are the service parameters
(mandatory tunneling, bandwidth, filters, and so on) to be (mandatory tunneling, bandwidth, filters, and so on) to be
provisioned for the user? provisioned for the user?
While the authorization decision is in principle simple, the While the authorization decision is, in principle, simple, the
distributed decision making process can add complexity. Where distributed decision making process can add complexity. Where
brokers or proxies are involved, all of the AAA entities in the chain brokers or proxies are involved, all of the AAA entities in the chain
from the authenticator to the home backend authentication server are from the authenticator to the home backend authentication server are
involved in the decision. For example, a broker can deny access even involved in the decision. For example, a broker can deny access even
if the home backend authentication server would allow it, or a proxy if the home backend authentication server would allow it, or a proxy
can add authorizations (e.g., bandwidth limits). can add authorizations (e.g., bandwidth limits).
Decisions can be based on static policy definitions and profiles as Decisions can be based on static policy definitions and profiles as
well as dynamic state (e.g. time of day or concurrent session well as dynamic state (e.g., time of day or concurrent session
limits). In addition to the Accept/Reject decisions made by AAA limits). In addition to the Accept/Reject decisions made by AAA
entities, service parameters or constraints can be communicated to entities, service parameters or constraints can be communicated to
the authenticator. the authenticator.
The criteria for Accept/Reject decisions or the reasons for choosing The criteria for Accept/Reject decisions or the reasons for choosing
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 is. As a result, the
has no way to know what the decision was based on. Was a set of authenticator has no way to know on what the decision was based. Was
authorization parameters sent because this service is always provided a set of authorization parameters sent because this service is always
to the user, or was the decision based on the time of day and the provided to the user, or was the decision based on the time of day
capabilities of the authenticator? and the capabilities of the authenticator?
4.3.3. Correctness 4.3.3. Correctness
When the AAA exchange (phase 1b) is bypassed, several challenges When the AAA exchange (phase 1b) is bypassed, several challenges
arise in ensuring correct authorization: arise in ensuring correct authorization:
Theft of service Theft of service
Bypassing the AAA exchange (phase 1b) SHOULD NOT enable a user to Bypassing the AAA exchange (phase 1b) SHOULD NOT enable a user to
extend their network access or gain access to services they are not extend their network access or gain access to services they are
entitled to. not entitled to.
Consideration of network-wide state Consideration of network-wide state
Handoff techniques SHOULD NOT render the backend authentication Handoff techniques SHOULD NOT render the backend authentication
server incapable of keeping track of network-wide state. For server incapable of keeping track of network-wide state. For
example, a backend authentication server can need to keep track of example, a backend authentication server can need to keep track of
simultaneous user sessions. simultaneous user sessions.
Elevation of privilege Elevation of privilege
Backend authentication servers often perform conditional Backend authentication servers often perform conditional
evaluation, in which the authorizations returned in an Access- evaluation, in which the authorizations returned in an
Accept message are contingent on the authenticator or on dynamic Access-Accept message are contingent on the authenticator or on
state such as the time of day. In this situation, bypassing the dynamic state such as the time of day. In this situation,
AAA exchange could enable unauthorized access unless the bypassing the AAA exchange could enable unauthorized access unless
restrictions are explicitly encoded within the authorizations the restrictions are explicitly encoded within the authorizations
provided by the backend authentication server. provided by the backend authentication server.
A handoff mechanism that provides proper authorization is said to be A handoff mechanism that provides proper authorization is said to be
"correct". One condition for correctness is as follows: "correct". One condition for correctness is as follows:
For a handoff to be "correct" it MUST establish on the new For a handoff to be "correct" it MUST establish on the new
authenticator the same authorizations as would have been created authenticator the same authorizations as would have been created
had the new authenticator completed a AAA conversation with the had the new authenticator completed a AAA conversation with the
backend authentication server. 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" authorizations, it is preferable for it to fail. Where "incorrect" authorizations, it is preferable for it to fail. Where
the supported services differ between authenticators, a handoff that the supported services differ between authenticators, a handoff that
bypasses the backend authentication server is likely to fail. bypasses the backend authentication server is likely to fail.
[RFC2865] section 1.1 states: Section 1.1 of [RFC2865] states:
A authenticator that does not implement a given service MUST NOT A authenticator that does not implement a given service MUST NOT
implement the RADIUS attributes for that service. For example, a implement the RADIUS attributes for that service. For example, a
authenticator that is unable to offer ARAP service MUST NOT authenticator that is unable to offer ARAP service MUST NOT
implement the RADIUS attributes for ARAP. A authenticator MUST implement the RADIUS attributes for ARAP. A authenticator MUST
treat a RADIUS access-accept authorizing an unavailable service as treat a RADIUS access-accept authorizing an unavailable service as
an access-reject instead. an access-reject instead.
This behavior applies to attributes that are known, but not This behavior applies to attributes that are known, but not
implemented. For attributes that are unknown, [RFC2865] Section 5 implemented. For attributes that are unknown, Section 5 of [RFC2865]
states: states:
A RADIUS server MAY ignore Attributes with an unknown Type. A A RADIUS server MAY ignore Attributes with an unknown Type. A
RADIUS client MAY ignore Attributes with an unknown Type. RADIUS client MAY ignore Attributes with an unknown Type.
In order to perform a correct handoff, if a new authenticator is In order to perform a correct handoff, if a new authenticator is
provided with RADIUS authorizations for a known but unavailable provided with RADIUS authorizations for a known but unavailable
service, then it MUST process these authorizations the same way it service, then it MUST process these authorizations the same way it
would handle a RADIUS Access-Accept requesting an unavailable would handle a RADIUS Access-Accept requesting an unavailable
service; this MUST cause the handoff to fail. However, if a new service; this MUST cause the handoff to fail. However, if a new
authenticator is provided with authorizations including unknown authenticator is provided with authorizations including unknown
attributes, then these attributes MAY be ignored. The definition of attributes, then these attributes MAY be ignored. The definition of
a "known but unsupported service" MUST encompass requests for a "known but unsupported service" MUST encompass requests for
unavailable security services. This includes vendor-specific unavailable security services. This includes vendor-specific
attributes related to security, such as those described in [RFC2548]. attributes related to security, such as those described in [RFC2548].
Although it can seem somewhat counter-intuitive, failure is indeed Although it can 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. requested.
Presumably a correctly configured backend authentication server would Presumably, a correctly configured backend authentication server
not request that an authenticator provide a service that it does not would not request that an authenticator provide a service that it
implement. This implies that if the new authenticator were to does not implement. This implies that if the new authenticator were
complete a AAA conversation, it would be likely to receive different to complete a AAA conversation, it would be likely to receive
service instructions. Failure of the handoff is the desired result different service instructions. Failure of the handoff is the
since it will cause the new authenticator to go back to the backend desired result since it will cause the new authenticator to go back
server in order to receive the appropriate service definition. to the backend server in order to receive the appropriate service
definition.
Handoff mechanisms which bypass the backend authentication server are Handoff mechanisms that bypass the backend authentication server are
most likely to be successful when employed in a homogeneous most likely to be successful when employed in a homogeneous
deployment within a single administrative domain. In a heterogeneous deployment within a single administrative domain. In a heterogeneous
deployment, the backend authentication server can return different deployment, the backend authentication server can return different
authorizations depending on the authenticator making the request, in authorizations depending on the authenticator making the request in
order to make sure that the requested service is consistent with the order to make sure that the requested service is consistent with the
authenticator capabilities. Where a backend authentication server authenticator capabilities. Where a backend authentication server
would send different authorizations to the new authenticator than would send different authorizations to the new authenticator than
were sent to a previous authenticator, transferring authorizations were sent to a previous authenticator, transferring authorizations
between the previous authenticator and the new authenticator will between the previous authenticator and the new authenticator will
result in incorrect authorization. result in incorrect authorization.
Virtual LAN (VLAN) support is defined in [IEEE-802.1Q]; RADIUS Virtual LAN (VLAN) support is defined in [IEEE-802.1Q]; RADIUS
support for dynamic VLANs is described in [RFC3580] and [RFC4675]. support for dynamic VLANs is described in [RFC3580] and [RFC4675].
If some authenticators support dynamic VLANs while others do not, If some authenticators support dynamic VLANs while others do not,
then attributes present in the Access-Request (such as the NAS-Port- then attributes present in the Access-Request (such as the
Type, NAS-IP-Address, NAS-IPv6-Address and NAS-Identifier) could be NAS-Port-Type, NAS-IP-Address, NAS-IPv6-Address, and NAS-Identifier)
examined by the backend authentication server to determine when VLAN could be examined by the backend authentication server to determine
attributes will be returned, and if so, which ones. However, if the when VLAN attributes will be returned, and if so, which ones.
backend authenticator is bypassed, then a handoff occurring between However, if the backend authenticator is bypassed, then a handoff
authenticators supporting different VLAN capabilities could result in occurring between authenticators supporting different VLAN
a user obtaining access to an unauthorized VLAN (e.g. a user with capabilities could result in a user obtaining access to an
access to a guest VLAN being given unrestricted access to the unauthorized VLAN (e.g., a user with access to a guest VLAN being
network). given unrestricted access to the network).
Similarly, it is preferable for a handoff between an authenticator Similarly, it is preferable for a handoff between an authenticator
providing confidentiality and another that does not to fail, since if providing confidentiality and another that does not to fail, since if
the handoff were successful, the user would be moved from a secure to the handoff were successful, the user would be moved from a secure to
an insecure channel without permission from the backend an insecure channel without permission from the backend
authentication server. authentication server.
5. Security Considerations 5. Security Considerations
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") are security properties of EAP methods (known as "security claims") are
described in [RFC3748] Section 7.2.1. EAP method requirements for described in [RFC3748] Section 7.2.1. EAP method requirements for
applications such as Wireless LAN authentication are described in applications such as Wireless LAN authentication are described in
[RFC4017]. The RADIUS threat model is described in [RFC3579] Section [RFC4017]. The RADIUS threat model is described in [RFC3579] Section
4.1, and responses to these threats are described in [RFC3579] 4.1, and responses to these threats are described in [RFC3579],
Sections 4.2 and 4.3. 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
system level threats. In developing the threat model, it is assumed system level threats. In developing the threat model, it is assumed
that: that:
All traffic is visible to the attacker. All traffic is visible to the attacker.
The attacker can alter, forge or replay messages. The attacker can alter, forge, or replay messages.
The attacker can reroute messages to another principal. The attacker can reroute messages to another principal.
The attacker can be a principal or an outsider. The attacker can be a principal or an outsider.
The attacker can compromise any key that is sufficiently old. The attacker can compromise any key that is sufficiently old.
Threats arising from these assumptions include: Threats arising from these assumptions include:
(a) An attacker can compromise or steal an EAP peer or authenticator, (a) An attacker can compromise or steal an EAP peer or
in an attempt to gain access to other EAP peers or authenticators authenticator, in an attempt to gain access to other EAP peers
or to obtain long-term secrets. or authenticators or to obtain long-term secrets.
(b) An attacker can attempt a downgrade attack in order to exploit (b) An attacker can attempt a downgrade attack in order to exploit
known weaknesses in an authentication method or cryptographic known weaknesses in an authentication method or cryptographic
algorithm. algorithm.
(c) An attacker can try to modify or spoof packets, including Discovery (c) An attacker can try to modify or spoof packets, including
or Secure Association Protocol frames, EAP or AAA packets. Discovery or Secure Association Protocol frames, EAP or AAA
packets.
(d) An attacker can attempt to induce an EAP peer, authenticator or (d) An attacker can attempt to induce an EAP peer, authenticator, or
server to disclose keying material to an unauthorized party, or server to disclose keying material to an unauthorized party, or
utilize keying material outside the context that it was intended utilize keying material outside the context that it was intended
for. for.
(e) An attacker can alter, forge or replay packets. (e) An attacker can alter, forge, or replay packets.
(f) An attacker can cause an EAP peer, authenticator or server to reuse (f) An attacker can cause an EAP peer, authenticator, or server to
a stale key. Use of stale keys can also occur unintentionally. reuse a stale key. Use of stale keys can also occur
For example, a poorly implemented backend authentication server can unintentionally. For example, a poorly implemented backend
provide stale keying material to an authenticator, or a poorly authentication server can provide stale keying material to an
implemented authenticator can reuse nonces. authenticator, or a poorly implemented authenticator can reuse
nonces.
(g) An authenticated attacker can attempt to obtain elevated privilege (g) An authenticated attacker can attempt to obtain elevated
in order to access information that it does not have rights to. privilege in order to access information that it does not have
rights to.
(h) An attacker can attempt a man-in-the-middle attack in order to gain (h) An attacker can attempt a man-in-the-middle attack in order to
access to the network. gain access to the network.
(i) An attacker can compromise an EAP authenticator in an effort to (i) An attacker can compromise an EAP authenticator in an effort to
commit fraud. For example, a compromised authenticator can provide commit fraud. For example, a compromised authenticator can
incorrect information to the EAP peer and/or server via out-of-band provide incorrect information to the EAP peer and/or server via
mechanisms (such as via a AAA or lower layer protocol). This out-of-band mechanisms (such as via a AAA or lower-layer
includes impersonating another authenticator, or providing protocol). This includes impersonating another authenticator,
inconsistent information to the peer and EAP server. or providing inconsistent information to the peer and EAP
server.
(j) An attacker can launch a denial of service attack against the EAP (j) An attacker can launch a denial-of-service attack against the
peer, authenticator or backend authentication server. EAP peer, authenticator, or backend authentication server.
In order to address these threats, [RFC4962] Section 3 describes In order to address these threats, [RFC4962] Section 3 describes
required and recommended security properties. The sections that required and recommended security properties. The sections that
follow analyze the compliance of EAP methods, AAA protocols and follow analyze the compliance of EAP methods, AAA protocols, and
Secure Association Protocols with those guidelines. Secure Association Protocols with those guidelines.
5.1. Peer and Authenticator Compromise 5.1. Peer and Authenticator Compromise
Requirement: In the event that an authenticator is compromised or Requirement: In the event that an authenticator is compromised or
stolen, an attacker can gain access to the network through that stolen, an attacker can gain access to the network through that
authenticator, or can obtain the credentials needed for the authenticator, or can obtain the credentials needed for the
authenticator/AAA client to communicate with one or more backend authenticator/AAA client to communicate with one or more backend
authentication servers. Similarly, if a peer is compromised or authentication servers. Similarly, if a peer is compromised or
stolen, an attacker can obtain credentials needed to communicate with stolen, an attacker can obtain credentials needed to communicate with
one or more authenticators. Mandatory requirement from [RFC4962] one or more authenticators. A mandatory requirement from [RFC4962]
Section 3: Section 3:
Prevent the Domino effect Prevent the Domino effect
Compromise of a single peer MUST NOT compromise keying material Compromise of a single peer MUST NOT compromise keying material
held by any other peer within the system, including session keys held by any other peer within the system, including session keys
and long-term keys. Likewise, compromise of a single and long-term keys. Likewise, compromise of a single
authenticator MUST NOT compromise keying material held by any authenticator MUST NOT compromise keying material held by any
other authenticator within the system. In the context of a key other authenticator within the system. In the context of a key
hierarchy, this means that the compromise of one node in the key hierarchy, this means that the compromise of one node in the key
skipping to change at page 48, line 29 skipping to change at page 52, line 25
parties that are associated with other branches in the key parties that are associated with other branches in the key
hierarchy. hierarchy.
Group keys are an obvious exception. Since all members of the Group keys are an obvious exception. Since all members of the
group have a copy of the same key, compromise of any one of the group have a copy of the same key, compromise of any one of the
group members will result in the disclosure of the group key. group members will result in the disclosure of the group key.
Some of the implications of the requirement are as follows: Some of the implications of the requirement are as follows:
Key Sharing Key Sharing
In order to be able to determine whether keying material has been In order to be able to determine whether keying material has
shared, it is necessary for the identity of the EAP authenticator been shared, it is necessary for the identity of the EAP
(NAS-Identifier) to be defined and understood by all parties that authenticator (NAS-Identifier) to be defined and understood by
communicate with it. EAP lower layer specifications such as all parties that communicate with it. EAP lower-layer
[IEEE-802.11], [IEEE-802.16e], [IEEE-802.1X], IKEv2 [RFC4306] and specifications such as [IEEE-802.11], [IEEE-802.16e],
PPP [RFC1661] do not involve key sharing. [IEEE-802.1X], IKEv2 [RFC4306], and PPP [RFC1661] do not involve
key sharing.
AAA Credential Sharing AAA Credential Sharing
AAA credentials (such as RADIUS shared secrets, IPsec pre-shared AAA credentials (such as RADIUS shared secrets, IPsec pre-shared
keys or certificates) MUST NOT be shared between AAA clients, since keys or certificates) MUST NOT be shared between AAA clients,
if one AAA client were compromised, this would enable an attacker since if one AAA client were compromised, this would enable an
to impersonate other AAA clients to the backend authentication attacker to impersonate other AAA clients to the backend
server, or even to impersonate a backend authentication server to authentication server, or even to impersonate a backend
other AAA clients. authentication server to other AAA clients.
Compromise of Long-Term Credentials Compromise of Long-Term Credentials
An attacker obtaining keying material (such as TSKs, TEKs or the An attacker obtaining keying material (such as TSKs, TEKs, or
MSK) MUST NOT be able to obtain long-term user credentials such as the MSK) MUST NOT be able to obtain long-term user credentials
pre-shared keys, passwords or private-keys without breaking a such as pre-shared keys, passwords, or private-keys without
fundamental cryptographic assumption. The mandatory requirements breaking a fundamental cryptographic assumption. The mandatory
of [RFC4017] Section 2.2 include generation of EAP keying material, requirements of [RFC4017] Section 2.2 include generation of EAP
capability to generate EAP keying material with 128-bits of keying material, capability to generate EAP keying material with
effective strength, resistance to dictionary attacks, shared state 128 bits of effective strength, resistance to dictionary
equivalence and protection against man-in-the-middle attacks. attacks, shared state equivalence, and protection against
man-in-the-middle attacks.
5.2. Cryptographic Negotiation 5.2. Cryptographic Negotiation
Mandatory requirements from [RFC4962] Section 3: Mandatory requirements from [RFC4962] Section 3:
Cryptographic algorithm independent Cryptographic algorithm independent
The AAA key management protocol MUST be cryptographic algorithm The AAA key management protocol MUST be cryptographic algorithm
independent. However, an EAP method MAY depend on a specific independent. However, an EAP method MAY depend on a specific
cryptographic algorithm. The ability to negotiate the use of a cryptographic algorithm. The ability to negotiate the use of a
skipping to change at page 49, line 45 skipping to change at page 53, line 44
algorithms can be used whenever a symmetric-key algorithm is algorithms can be used whenever a symmetric-key algorithm is
employed. employed.
Confirm ciphersuite selection Confirm ciphersuite selection
The selection of the "best" ciphersuite SHOULD be securely The selection of the "best" ciphersuite SHOULD be securely
confirmed. The mechanism SHOULD detect attempted roll-back confirmed. The mechanism SHOULD detect attempted roll-back
attacks. attacks.
EAP methods satisfying [RFC4017] Section 2.2 mandatory requirements EAP methods satisfying [RFC4017] Section 2.2 mandatory requirements
and AAA protocols utilizing transmission layer security are capable and AAA protocols utilizing transmission-layer security are capable
of addressing downgrade attacks. [RFC3748] Section 7.2.1 describes of addressing downgrade attacks. [RFC3748] Section 7.2.1 describes
the "protected ciphersuite negotiation" security claim that refers to the "protected ciphersuite negotiation" security claim that refers to
the ability of an EAP method to negotiate the ciphersuite used to the ability of an EAP method to negotiate the ciphersuite used to
protect the EAP method conversation, as well as to integrity protect protect the EAP method conversation, as well as to integrity protect
the ciphersuite negotiation. [RFC4017] Section 2.2 requires EAP the ciphersuite negotiation. [RFC4017] Section 2.2 requires EAP
methods satisfying this security claim. Since TLS v1.2 methods satisfying this security claim. Since TLS v1.2 [RFC5246] and
[I-D.ietf-tls-rfc4346-bis] supports negotiation of Key Distribution IKEv2 [RFC4306] support negotiation of Key Derivation Functions
Functions (KDFs), EAP methods based on TLS will, if properly (KDFs), EAP methods based on TLS or IKEv2 will, if properly designed,
designed, inherit this capability. However, negotiation of KDFs is inherit this capability. However, negotiation of KDFs is not
not required by RFC 4962 [RFC4962], and EAP methods not based on TLS required by RFC 4962 [RFC4962], and EAP methods based on neither TLS
typically do not support KDF negotiation. nor IKEv2 typically do not support KDF negotiation.
Diameter [RFC3588] provides support for cryptographic algorithm When AAA protocols utilize TLS [RFC5246] or IPsec [RFC4301] for
negotiation via use of IPsec [RFC4301] or TLS [RFC4346]. Since IKEv2 transmission layer security, they can leverage the cryptographic
[RFC4306] does not support KDF negotiation, support for KDF algorithm negotiation support provided by IKEv2 [RFC4306] or TLS
negotiation is only available when Diameter runs over TLS v1.2. [RFC5246]. RADIUS [RFC3579] by itself does not support cryptographic
RADIUS [RFC3579] does not support cryptographic algorithm negotiation algorithm negotiation and relies on MD5 for integrity protection,
and relies on MD5 for integrity protection, authentication and authentication, and confidentiality. Given the known weaknesses in
confidentiality. Given the known weaknesses in MD5 [MD5Collision] MD5 [MD5Collision], this is undesirable, and can be addressed via use
this is undesirable, and can be addressed via use of RADIUS over of RADIUS over IPsec, as described in [RFC3579] Section 4.2.
IPsec, as described in [RFC3579] Section 4.2.
To ensure against downgrade attacks within lower layer protocols, To ensure against downgrade attacks within lower-layer protocols,
algorithm independence is REQUIRED with lower layers using EAP for algorithm independence is REQUIRED with lower layers using EAP for
key derivation. For interoperability, at least one suite of key derivation. For interoperability, at least one suite of
mandatory-to-implement algorithm MUST be selected. Lower layer mandatory-to-implement algorithms MUST be selected. Lower-layer
protocols supporting EAP for key derivation SHOULD also support protocols supporting EAP for key derivation SHOULD also support
secure ciphersuite negotiation as well as KDF negotiation. secure ciphersuite negotiation as well as KDF negotiation.
As described in [RFC1968], PPP ECP does not support secure As described in [RFC1968], PPP ECP does not support secure
ciphersuite negotiation. While [IEEE 802.16e] and [IEEE-802.11] ciphersuite negotiation. While [IEEE-802.16e] and [IEEE-802.11]
support ciphersuite negotiation for protection of data, they do not support ciphersuite negotiation for protection of data, they do not
support negotiation of the cryptographic primitives used within the support negotiation of the cryptographic primitives used within the
Secure Association Protocol, such as message integrity checks (MICs) Secure Association Protocol, such as message integrity checks (MICs)
and KDFs. and KDFs.
5.3. Confidentiality and Authentication 5.3. Confidentiality and Authentication
Mandatory requirements from [RFC4962] Section 3: Mandatory requirements from [RFC4962] Section 3:
Authenticate all parties Authenticate all parties
skipping to change at page 51, line 31 skipping to change at page 55, line 31
Authentication mechanisms MUST NOT employ plaintext passwords. Authentication mechanisms MUST NOT employ plaintext passwords.
Passwords may be used provided that they are not sent to another Passwords may be used provided that they are not sent to another
party without confidentiality protection. party without confidentiality protection.
Keying material confidentiality and integrity Keying material confidentiality and integrity
While preserving algorithm independence, confidentiality and While preserving algorithm independence, confidentiality and
integrity of all keying material MUST be maintained. integrity of all keying material MUST be maintained.
Conformance to these requirements are analyzed in the sections that Conformance to these requirements is analyzed in the sections that
follow. follow.
5.3.1. Spoofing 5.3.1. Spoofing
Per-packet authentication and integrity protection provides Per-packet authentication and integrity protection provides
protection against spoofing attacks. protection against spoofing attacks.
Diameter [RFC3588] provides support for per-packet authentication and Diameter [RFC3588] provides support for per-packet authentication and
integrity protection via use of IPsec or TLS. RADIUS/EAP [RFC3579] integrity protection via use of IPsec or TLS. RADIUS/EAP [RFC3579]
provides for per-packet authentication and integrity protection via provides for per-packet authentication and integrity protection via
use of the Message-Authenticator attribute. use of the 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] Section 2.2 requires EAP methods supporting this claim and [RFC4017] Section 2.2 requires 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. IKEv2 [RFC4306] supports per-frame integrity all messages. IKEv2 [RFC4306] supports per-frame integrity
protection and authentication, as does the Secure Association protection and authentication, as does the Secure Association
Protocol defined in [IEEE-802.16e]. [IEEE-802.11] supports per-frame Protocol defined in [IEEE-802.16e]. [IEEE-802.11] supports per-frame
skipping to change at page 52, line 19 skipping to change at page 56, line 20
5.3.2. Impersonation 5.3.2. Impersonation
Both RADIUS [RFC2865] and Diameter [RFC3588] implementations are Both RADIUS [RFC2865] and Diameter [RFC3588] implementations are
potentially vulnerable to a rogue authenticator impersonating another potentially vulnerable to a rogue authenticator impersonating another
authenticator. While both protocols support mutual authentication authenticator. While both protocols support mutual authentication
between the AAA client/authenticator and the backend authentication between the AAA client/authenticator and the backend authentication
server, the security mechanisms vary. 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. However, when RADIUS the source address of the RADIUS packet. However, when RADIUS
Access-Requests are forwarded by a proxy, the NAS-IP-Address, NAS- Access-Requests are forwarded by a proxy, the NAS-IP-Address,
Identifier or NAS-IPv6-Address attributes received by the RADIUS NAS-Identifier, or NAS-IPv6-Address attributes received by the RADIUS
server will not correspond to the source address. As noted in server will not correspond to the source address. As noted in
[RFC3579] Section 4.3.7, if the first-hop proxy does not check the [RFC3579] Section 4.3.7, if the first-hop proxy does not check the
NAS identification attributes against the source address in the NAS identification attributes against the source address in the
Access-Request packet, it is possible for a rogue authenticator to Access-Request packet, it is possible for a rogue authenticator to
forge NAS-IP-Address [RFC2865], NAS-IPv6-Address [RFC3162] or NAS- forge NAS-IP-Address [RFC2865], NAS-IPv6-Address [RFC3162], or
Identifier [RFC2865] attributes in order to impersonate another NAS-Identifier [RFC2865] attributes in order to impersonate another
authenticator; attributes such as the Called-Station-Id [RFC2865] and authenticator; attributes such as the Called-Station-Id [RFC2865] and
Calling-Station-Id [RFC2865] can be forged as well. Among other Calling-Station-Id [RFC2865] can be forged as well. Among other
things, this can result in messages (and transported keying material) things, this can result in messages (and transported keying material)
being sent to the wrong authenticator. being sent to the wrong authenticator.
While [RFC3588] requires use of the Route-Record AVP, this utilizes While [RFC3588] requires use of the Route-Record AVP, this utilizes
Fully Qualified Domain Names (FQDNs), so that impersonation detection Fully Qualified Domain Names (FQDNs), so that impersonation detection
requires DNS A, AAAA and PTR Resource Records (RRs) to be properly requires DNS A, AAAA, and PTR Resource Records (RRs) to be properly
configured. As a result, Diameter is as vulnerable to this attack as configured. As a result, Diameter is as vulnerable to this attack as
RADIUS, if not more so. [RFC3579] Section 4.3.7 recommends RADIUS, if not more so. [RFC3579] Section 4.3.7 recommends
mechanisms for impersonation detection; to prevent access to keying mechanisms for impersonation detection; to prevent access to keying
material by proxies without a "need to know", it is necessary to material by proxies without a "need to know", it is necessary to
allow the backend authentication server to communicate with the allow the backend authentication server to communicate with the
authenticator directly, such as via the redirect functionality authenticator directly, such as via the redirect functionality
supported in [RFC3588]. supported in [RFC3588].
5.3.3. Channel Binding 5.3.3. 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 can enable an authenticator to impersonate and/or server. This can enable an authenticator to impersonate
another authenticator or communicate incorrect information via out- another authenticator or communicate incorrect information via
of-band mechanisms (such as via AAA or the lower layer). out-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 EAP the identity of the pass-through authenticator within the EAP
conversation. Within the Secure Association Protocol, the EAP peer conversation. Within the Secure Association Protocol, the EAP peer
and authenticator only demonstrate mutual possession of the and authenticator only demonstrate mutual possession of the
transported keying material; they do not mutually authenticate. This transported keying material; they do not mutually authenticate. This
creates a potential security vulnerability, described in [RFC3748] creates a potential security vulnerability, described in [RFC3748]
Section 7.15. Section 7.15.
As described in [RFC3579] Section 4.3.7, it is possible for a first- As described in [RFC3579] Section 4.3.7, it is possible for a
hop AAA proxy to detect a AAA client attempting to impersonate first-hop AAA proxy to detect a AAA client attempting to impersonate
another authenticator. However, it is possible for a pass-through another authenticator. However, it is possible for a pass-through
authenticator acting as a AAA client to provide correct information authenticator acting as a AAA client to provide correct information
to the backend authentication server while communicating misleading to the backend authentication server while communicating misleading
information to the EAP peer via the lower layer. information to the EAP peer via the lower 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. Also, a pass-through with the EAP peer via the lower layer. Also, a pass-through
authenticator acting as a AAA client can provide an incorrect peer authenticator acting as a AAA client can provide an incorrect peer
Calling-Station-Id [RFC2865][RFC3580] to the backend authentication Calling-Station-Id [RFC2865][RFC3580] to the backend authentication
skipping to change at page 53, line 34 skipping to change at page 57, line 36
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. Typically the EAP against those exchanged within the EAP method. Typically, the EAP
method imports channel binding parameters from the lower layer on the method imports channel binding parameters from the lower layer on the
peer, and transmits them securely to the EAP server, which exports peer, and transmits them securely to the EAP server, which exports
them to the lower layer or AAA layer. However, transport can occur them to the lower layer or AAA layer. However, transport can occur
from EAP server to peer, or can be bi-directional. On the side of from EAP server to peer, or can be bi-directional. On the side of
the exchange (peer or server) where Channel Binding is verified, the the exchange (peer or server) where channel binding is verified, the
lower layer or AAA layer passes the result of the verification (TRUE 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 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 either by the peer or the server, typically only the server has the
knowledge to determine the correctness of the values, as opposed to knowledge to determine the correctness of the values, as opposed to
merely verifying their equality. For further discussion, see merely verifying their equality. For further discussion, see
[I-D.arkko-eap-service-identity-auth]. [EAP-SERVICE].
It is also possible to perform Channel Binding without transporting It is also possible to perform channel binding without transporting
data over EAP, as described in [I-D.ohba-eap-channel-binding]. In data over EAP, as described in [EAP-CHANNEL]. In this approach the
this approach the EAP method includes channel binding parameters in EAP method includes channel binding parameters in the calculation of
the calculation of exported EAP keying material, making it impossible exported EAP keying material, making it impossible for the peer and
for the peer and authenticator to complete the Secure Association authenticator to complete the Secure Association Protocol if there is
Protocol if there is a mismatch in the channel binding parameters. a mismatch in the channel binding parameters. However, this approach
However, this approach can only be applied where methods generating can only be applied where methods generating EAP keying material are
EAP keying material are used along with lower layers that utilize EAP used along with lower layers that utilize EAP keying material. For
keying material. For example, this mechanism would not enable example, this mechanism would not enable verification of channel
verification of Channel Binding on wired IEEE 802 networks using binding on wired IEEE 802 networks using [IEEE-802.1X].
[IEEE-802.1X].
5.3.4. Mutual Authentication 5.3.4. Mutual Authentication
[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. peer and server.
[RFC3748] Section 7.2.1 also describes the "Cryptographic binding" [RFC3748] Section 7.2.1 also describes the "Cryptographic binding"
security claim, and [RFC4017] Section 2.2 requires support for this security claim, and [RFC4017] Section 2.2 requires support for this
claim. As described in [I-D.puthenkulam-eap-binding], EAP method claim. As described in [EAP-BINDING], EAP method sequences and
sequences and compound authentication mechanisms can be subject to compound authentication mechanisms can be subject to
man-in-the-middle attacks. When such attacks are successfully man-in-the-middle attacks. When such attacks are successfully
carried out, the attacker acts as an intermediary between a victim carried out, the attacker acts as an intermediary between a victim
and a legitimate authenticator. This allows the attacker to and a legitimate authenticator. This allows the attacker to
authenticate successfully to the authenticator, as well as to obtain authenticate successfully to the authenticator, as well as to obtain
access to the network. access to the network.
In order to prevent these attacks, [I-D.puthenkulam-eap-binding] In order to prevent these attacks, [EAP-BINDING] recommends
recommends derivation of a compound key by which the EAP peer and derivation of a compound key by which the EAP peer and server can
server can prove that they have participated in the entire EAP prove that they have participated in the entire EAP exchange. Since
exchange. Since the compound key MUST NOT be known to an attacker the compound key MUST NOT be known to an attacker posing as an
posing as an authenticator, and yet must be derived from EAP keying authenticator, and yet must be derived from EAP keying material, it
material, it MAY be desirable to derive the compound key from a MAY be desirable to derive the compound key from a portion of the
portion of the EMSK. Where this is done, in order to provide proper EMSK. Where this is done, in order to provide proper key hygiene, it
key hygiene, it is RECOMMENDED that the compound key used for man-in- is RECOMMENDED that the compound key used for man-in-the-middle
the-middle protection be cryptographically separate from other keys protection be cryptographically separate from other keys derived from
derived from the EMSK. the EMSK.
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 authenticator/AAA client and backend authentication server Where the authenticator/AAA client and backend authentication server
communicate directly and credible key wrap is used (see Section 3.8), communicate directly and credible key wrap is used (see Section 3.8),
this ensures that the AAA Key Transport (phase 1b) achieves its this ensures that the AAA Key Transport (phase 1b) achieves its
security objectives: mutually authenticating the AAA security objectives: mutually authenticating the AAA
client/authenticator and backend authentication server and providing client/authenticator and backend authentication server and providing
transported keying material to the EAP authenticator and to no other transported keying material to the EAP authenticator and to no other
skipping to change at page 55, line 14 skipping to change at page 59, line 16
authenticator/AAA client and backend authentication server do not authenticator/AAA client and backend authentication server do not
communicate directly. Where a AAA intermediary is present (such as a communicate directly. Where a AAA intermediary is present (such as a
RADIUS proxy or a Diameter agent), and data object security is not RADIUS proxy or a Diameter agent), and data object security is not
used, transported keying material can be recovered by an attacker in used, transported keying material can be recovered by an attacker in
control of the intermediary. As discussed in Section 2.1, unless the control of the intermediary. As discussed in Section 2.1, unless the
TSKs are derived independently from EAP keying material (as in TSKs are derived independently from EAP keying material (as in
IKEv2), possession of transported keying material enables decryption IKEv2), possession of transported keying material enables decryption
of data traffic sent between the peer and the authenticator to whom of data traffic sent between the peer and the authenticator to whom
the keying material was transported. It also allows the AAA the keying material was transported. It also allows the AAA
intermediary to impersonate the authenticator or the peer. Since the intermediary to impersonate the authenticator or the peer. Since the
peer does not authenticate to a AAA intermediary it has no ability to peer does not authenticate to a AAA intermediary, it has no ability
determine whether it is authentic or authorized to obtain keying to determine whether it is authentic or authorized to obtain keying
material. material.
However, as long as transported keying material or keys derived from However, as long as transported keying material or keys derived from
it are only utilized by a single authenticator, compromise of the it are only utilized by a single authenticator, compromise of the
transported keying material does not enable an attacker to transported keying material does not enable an attacker to
impersonate the peer to another authenticator. Vulnerability to impersonate the peer to another authenticator. Vulnerability to
compromise of a AAA intermediary can be mitigated by implementation compromise of a AAA intermediary can be mitigated by implementation
of redirect functionality, as described in [RFC3588] and [RFC4072]. of redirect functionality, as described in [RFC3588] and [RFC4072].
The Secure Association Protocol does not provide for mutual The Secure Association Protocol does not provide for mutual
authentication between the EAP peer and authenticator, only mutual authentication between the EAP peer and authenticator, only mutual
proof of possession of transported keying material. In order for the proof of possession of transported keying material. In order for the
peer to verify the identity of the authenticator, mutual proof of peer to verify the identity of the authenticator, mutual proof of
possession needs to be combined with impersonation prevention and possession needs to be combined with impersonation prevention and
Channel Binding. Impersonation prevention (described in Section channel binding. Impersonation prevention (described in Section
5.3.2) enables the backend authentication server to determine that 5.3.2) enables the backend authentication server to determine that
the transported keying material has been provided to the correct the transported keying material has been provided to the correct
authenticator. When utilized along with impersonation prevention, authenticator. When utilized along with impersonation prevention,
Channel Binding (described in Section 5.3.3) enables the EAP peer to channel binding (described in Section 5.3.3) enables the EAP peer to
verify that the EAP server has authorized the authenticator to verify that the EAP server has authorized the authenticator to
possess the transported keying material. Completion of the Secure possess the transported keying material. Completion of the Secure
Association Protocol exchange demonstrates that the EAP peer and the Association Protocol exchange demonstrates that the EAP peer and the
authenticator possess the transported keying material. authenticator possess the transported keying material.
5.4. Key Binding 5.4. Key Binding
Mandatory requirement from [RFC4962] Section 3: Mandatory requirement from [RFC4962] Section 3:
Bind key to its context Bind key to its context
Keying material MUST be bound to the appropriate context. The Keying material MUST be bound to the appropriate context. The
context includes the following: context includes the following:
o The manner in which the keying material is expected to o The manner in which the keying material is expected to be used.
be used.
o The other parties that are expected to have access to o The other parties that are expected to have access to the
the keying material. keying material.
o The expected lifetime of the keying material. Lifetime o The expected lifetime of the keying material. Lifetime of a
of a child key SHOULD NOT be greater than the lifetime of child key SHOULD NOT be greater than the lifetime of its parent
its parent in the key hierarchy. in the key hierarchy.
Any party with legitimate access to keying material can determine Any party with legitimate access to keying material can determine
its context. In addition, the protocol MUST ensure that all its context. In addition, the protocol MUST ensure that all
parties with legitimate access to keying material have the same parties with legitimate access to keying material have the same
context for the keying material. This requires that the parties context for the keying material. This requires that the parties
are properly identified and authenticated, so that all of the are properly identified and authenticated, so that all of the
parties that have access to the keying material can be determined. parties that have access to the keying material can be determined.
The context will include the peer and NAS identities in more than The context will include the peer and NAS identities in more than
one form. One (or more) name form is needed to identify these one form. One (or more) name form is needed to identify these
parties in the authentication exchange and the AAA protocol. parties in the authentication exchange and the AAA protocol.
Another name form may be needed to identify these parties within Another name form may be needed to identify these parties within
the lower layer that will employ the session key. the lower layer that will employ the session key.
Within EAP, exported keying material (MSK, EMSK,IV) is bound to the Within EAP, exported keying material (MSK, EMSK,IV) is bound to the
Peer-Id(s) and Server-Id(s) which are exported along with the keying Peer-Id(s) and Server-Id(s), which are exported along with the keying
material. However, not all EAP methods support authenticated server material. However, not all EAP methods support authenticated server
identities (see Appendix A). identities (see Appendix A).
Within the AAA protocol, transported keying material is destined for Within the AAA protocol, transported keying material is destined for
the EAP authenticator identified by the NAS-Identifier Attribute the EAP authenticator identified by the NAS-Identifier Attribute
within the request, and is for use by the EAP peer identified by the within the request, and is for use by the EAP peer identified by the
Peer-Id(s), User-Name [RFC2865] or Chargeable User Identity (CUI) Peer-Id(s), User-Name [RFC2865], or Chargeable User Identity (CUI)
[RFC4372] attributes. The maximum lifetime of the transported keying [RFC4372] attributes. The maximum lifetime of the transported keying
material can be provided, as discussed in Section 3.5.1. Key usage material can be provided, as discussed in Section 3.5.1. Key usage
restrictions can also be included as described in Section 3.2. Key restrictions can also be included as described in Section 3.2. Key
lifetime issues are discussed in Sections 3.3, 3.4 and 3.5. lifetime issues are discussed in Sections 3.3, 3.4, and 3.5.
5.5. Authorization 5.5. Authorization
Requirement: The Secure Association Protocol (phase 2) conversation Requirement: The Secure Association Protocol (phase 2) conversation
may utilize different identifiers from the EAP conversation (phase may utilize different identifiers from the EAP conversation (phase
1a), so that binding between the EAP and Secure Association Protocol 1a), so that binding between the EAP and Secure Association Protocol
identities is REQUIRED. identities is REQUIRED.
Mandatory requirement from [RFC4962] Section 3: Mandatory requirement from [RFC4962] Section 3:
skipping to change at page 57, line 42 skipping to change at page 61, line 42
Recommendation from [RFC4962] Section 3: Recommendation from [RFC4962] Section 3:
Authorization restriction Authorization restriction
If peer authorization is restricted, then the peer SHOULD be made If peer authorization is restricted, then the peer SHOULD be made
aware of the restriction. Otherwise, the peer may inadvertently aware of the restriction. Otherwise, the peer may inadvertently
attempt to circumvent the restriction. For example, authorization attempt to circumvent the restriction. For example, authorization
restrictions in an IEEE 802.11 environment include: restrictions in an IEEE 802.11 environment include:
o Key lifetimes, where the keying material can only be used o Key lifetimes, where the keying material can only be used for a
for a certain period of time; certain period of time;
o SSID restrictions, where the keying material can only be
used with a specific IEEE 802.11 SSID;
o Called-Station-ID restrictions, where the keying material o SSID restrictions, where the keying material can only be used
can only be used with a single IEEE 802.11 BSSID; and with a specific IEEE 802.11 SSID;
o Calling-Station-ID restrictions, where the keying o Called-Station-ID restrictions, where the keying material can
material can only be used with a single peer IEEE 802 MAC only be used with a single IEEE 802.11 BSSID; and
address. o Calling-Station-ID restrictions, where the keying material can
only be used with a single peer IEEE 802 MAC address.
As described in Section 2.3, consistent identification of the EAP As described in Section 2.3, consistent identification of the EAP
authenticator enables the EAP peer to determine the scope of keying authenticator enables the EAP peer to determine the scope of keying
material provided to an authenticator, as well as to confirm with the material provided to an authenticator, as well as to confirm with the
backend authentication server that an EAP authenticator proving backend authentication server that an EAP authenticator proving
possession of EAP keying material during the Secure Association possession of EAP keying material during the Secure Association
Protocol was authorized to obtain it. Protocol was authorized to obtain it.
Within the AAA protocol, the authorization attributes are bound to Within the AAA protocol, the authorization attributes are bound to
the transported keying material. While the AAA exchange provides the the transported keying material. While the AAA exchange provides the
AAA client/authenticator with authorizations relating to the EAP AAA client/authenticator with authorizations relating to the EAP
peer, neither the EAP nor AAA exchanges provide authorizations to the peer, neither the EAP nor AAA exchanges provide authorizations to the
EAP peer. In order to ensure that all parties hold the same view of EAP peer. In order to ensure that all parties hold the same view of
the authorizations it is RECOMMENDED that the Secure Association the authorizations, it is RECOMMENDED that the Secure Association
Protocol enable communication of authorizations between the EAP Protocol enable communication of authorizations between the EAP
authenticator and peer. authenticator and peer.
In lower layers where the authenticator consistently identifies In lower layers where the authenticator consistently identifies
itself to the peer and backend authentication server and the EAP peer itself to the peer and backend authentication server and the EAP peer
completes the Secure Association Protocol exchange with the same completes the Secure Association Protocol exchange with the same
authenticator through which it completed the EAP conversation, authenticator through which it completed the EAP conversation,
authorization of the authenticator is demonstrated to the peer by authorization of the authenticator is demonstrated to the peer by
mutual authentication between the peer and authenticator as discussed mutual authentication between the peer and authenticator as discussed
in the previous section. Identification issues are discussed in in the previous section. Identification issues are discussed in
Sections 2.3, 2.4 and 2.5 and key scope issues are discussed in Sections 2.3, 2.4, and 2.5 and key scope issues are discussed in
Section 3.2. Section 3.2.
Where the EAP peer utilizes different identifiers within the EAP Where the EAP peer utilizes different identifiers within the EAP
method and Secure Association Protocol conversations, peer method and Secure Association Protocol conversations, peer
authorization can be difficult to demonstrate to the authenticator authorization can be difficult to demonstrate to the authenticator
without additional restrictions. This problem does not exist in without additional restrictions. This problem does not exist in
IKEv2 where the Identity Payload is used for peer identification both IKEv2 where the Identity Payload is used for peer identification both
within IKEv2 and EAP, and where the EAP conversation is within IKEv2 and EAP, and where the EAP conversation is
cryptographically protected within IKEv2 binding the EAP and IKEv2 cryptographically protected within IKEv2 binding the EAP and IKEv2
exchanges. However within [IEEE-802.11] the EAP peer identity is not exchanges. However, within [IEEE-802.11], the EAP peer identity is
used within the 4-way handshake, so that it is necessary for the not used within the 4-way handshake, so that it is necessary for the
authenticator to require that the EAP peer utilize the same MAC authenticator to require that the EAP peer utilize the same MAC
address for EAP authentication as for the 4-way handshake. address for EAP authentication as for the 4-way handshake.
5.6. Replay Protection 5.6. Replay Protection
Mandatory requirement from [RFC4962] Section 3: Mandatory requirement from [RFC4962] Section 3:
Replay detection mechanism Replay detection mechanism
The AAA key management protocol exchanges MUST be replay The AAA key management protocol exchanges MUST be replay
protected, including AAA, EAP and Secure Association Protocol protected, including AAA, EAP and Secure Association Protocol
exchanges. Replay protection allows a protocol message recipient exchanges. Replay protection allows a protocol message recipient
to discard any message that was recorded during a previous to discard any message that was recorded during a previous
legitimate dialogue and presented as though it belonged to the legitimate dialogue and presented as though it belonged to the
current dialogue. 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] Section 2.2 requires use of EAP methods claim, and [RFC4017] Section 2.2 requires use of EAP methods
supporting this claim. supporting this claim.
Diameter [RFC3588] provides support for replay protection via use of Diameter [RFC3588] provides support for replay protection via use of
IPsec or TLS. RADIUS/EAP [RFC3579] protects against replay of keying IPsec or TLS. "RADIUS Support for EAP" [RFC3579] protects against
material via the Request Authenticator. However, some RADIUS packets replay of keying material via the Request Authenticator. According
are not replay protected. In Accounting, Disconnect and CoA-Request to [RFC2865] Section 3:
packets the Request Authenticator contains a keyed MAC rather than a
Nonce. The Response Authenticator in Accounting, Disconnect and CoA In Access-Request Packets, the Authenticator value is a 16 octet
Response packets also contains a keyed MAC whose calculation does not random number, called the Request Authenticator.
depend on a Nonce in either the Request or Response packets.
Therefore unless an Event-Timestamp attribute is included or IPsec is However, some RADIUS packets are not replay protected. In
used, it is possible that the recipient will not be able to determine Accounting, Disconnect, and Care-of Address (CoA)-Request packets,
whether these packets have been replayed. the Request Authenticator contains a keyed Message Integrity Code
(MIC) rather than a nonce. The Response Authenticator in Accounting,
Disconnect, and CoA-Response packets also contains a keyed MIC whose
calculation does not depend on a nonce in either the Request or
Response packets. Therefore, unless an Event-Timestamp attribute is
included or IPsec is used, it is possible that the recipient will not
be able to determine whether these packets have been replayed. This
issue is discussed further in [RFC5176] Section 6.3.
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.11] replay protection is REQUIRED on all messages. [IEEE-802.11]
supports replay protection on all messages within the 4-way supports replay protection on all messages within the 4-way
handshake; IKEv2 [RFC4306] also supports this. handshake; IKEv2 [RFC4306] also supports this.
5.7. Key Freshness 5.7. Key Freshness
Requirement: A session key SHOULD be considered compromised if it Requirement: A session key SHOULD be considered compromised if it
remains in use beyond its authorized lifetime. Mandatory requirement remains in use beyond its authorized lifetime. Mandatory requirement
skipping to change at page 60, line 26 skipping to change at page 64, line 48
immediately following the derivation of session keys. immediately following the derivation of session keys.
Session keys MUST NOT be dependent on one another. Multiple Session keys MUST NOT be dependent on one another. Multiple
session keys may be derived from a higher-level shared secret as session keys may be derived from a higher-level shared secret as
long as a one-time value, usually called a nonce, is used to long as a one-time value, usually called a nonce, is used to
ensure that each session key is fresh. The mechanism used to ensure that each session key is fresh. The mechanism used to
generate session keys MUST ensure that the disclosure of one generate session keys MUST ensure that the disclosure of one
session key does not aid the attacker in discovering any other session key does not aid the attacker in discovering any other
session keys. session keys.
EAP, AAA and the lower layer each bear responsibility for ensuring EAP, AAA, and the lower layer each bear responsibility for ensuring
the use of fresh, strong session keys. EAP methods need to ensure the use of fresh, strong session keys. EAP methods need to ensure
the freshness and strength of EAP keying material provided as an the freshness and strength of EAP keying material provided as an
input to session key derivation. [RFC3748] Section 7.10 states: input to session key derivation. [RFC3748] Section 7.10 states:
EAP methods SHOULD ensure the freshness of the MSK and EMSK, even EAP methods SHOULD ensure the freshness of the MSK and EMSK, even
in cases where one party may not have a high quality random number in cases where one party may not have a high quality random number
generator. A RECOMMENDED method is for each party to provide a generator. A RECOMMENDED method is for each party to provide a
nonce of at least 128 bits, used in the derivation of the MSK and nonce of at least 128 bits, used in the derivation of the MSK and
EMSK. EMSK.
skipping to change at page 60, line 51 skipping to change at page 65, line 25
independence" security claims, and [RFC4017] requires EAP methods independence" security claims, and [RFC4017] requires EAP methods
supporting these claims as well as methods capable of providing supporting these claims as well as methods capable of providing
equivalent key strength of 128 bits or greater. See Section 3.7 for equivalent key strength of 128 bits or greater. See Section 3.7 for
more information on key strength. more information on key strength.
The AAA protocol needs to ensure that transported keying material is The AAA protocol needs to ensure that transported keying material is
fresh and is not utilized outside its recommended lifetime. Replay fresh and is not utilized outside its recommended lifetime. Replay
protection is necessary for key freshness, but an attacker can protection is necessary for key freshness, but an attacker can
deliver a stale (and therefore potentially compromised) key in a deliver a stale (and therefore potentially compromised) key in a
replay-protected message, so replay protection is not sufficient. As replay-protected message, so replay protection is not sufficient. As
discussed in Section 3.5, the Session-Timeout attribute enables the discussed in Section 3.5, the Session-Timeout Attribute enables the
backend authentication server to limit the exposure of transported backend authentication server to limit the exposure of transported
keying material. keying material.
The EAP Session-Id, described in Section 1.4, enables the EAP peer, The EAP Session-Id, described in Section 1.4, enables the EAP peer,
authenticator and server to distinguish EAP conversations. However, authenticator, and server to distinguish EAP conversations. However,
unless the authenticator keeps track of EAP Session-Ids, the unless the authenticator keeps track of EAP Session-Ids, the
authenticator cannot use the Session-Id to guarantee the freshness of authenticator cannot use the Session-Id to guarantee the freshness of
keying material. keying material.
The Secure Association Protocol, described in Section 3.1, MUST The Secure Association Protocol, described in Section 3.1, MUST
generate a fresh session key for each session, even if the EAP keying generate a fresh session key for each session, even if the EAP keying
material and parameters provided by methods are cached, or either the material and parameters provided by methods are cached, or either the
peer or authenticator lack a high entropy random number generator. A peer or authenticator lack a high entropy random number generator. A
RECOMMENDED method is for the peer and authenticator to each provide RECOMMENDED method is for the peer and authenticator to each provide
a nonce or counter used in session key derivation. If a nonce is a nonce or counter used in session key derivation. If a nonce is
skipping to change at page 61, line 51 skipping to change at page 66, line 33
other using the selected EAP method. During the Secure Association other using the selected EAP method. During the Secure Association
Protocol exchange, the EAP peer utilizes keying material to Protocol exchange, the EAP peer utilizes keying material to
demonstrate to the authenticator that it is the same party that demonstrate to the authenticator that it is the same party that
authenticated to the EAP server and was authorized by it. The EAP authenticated to the EAP server and was authorized by it. The EAP
authenticator utilizes the transported keying material to prove to authenticator utilizes the transported keying material to prove to
the peer not only that the EAP conversation was transported through the peer not only that the EAP conversation was transported through
it (this could be demonstrated by a man-in-the-middle), but that it it (this could be demonstrated by a man-in-the-middle), but that it
was uniquely authorized by the EAP server to provide the peer with was uniquely authorized by the EAP server to provide the peer with
access to the network. Unique authorization can only be demonstrated access to the network. Unique authorization can only be demonstrated
if the EAP authenticator does not share the transported keying if the EAP authenticator does not share the transported keying
material with a party other than the EAP peer and server. material with a party other than the EAP peer and server. TSKs are
permitted to be accessed only by the EAP peer and authenticator (see
TSKs are permitted to be accessed only by the EAP peer and Section 1.5); TSK derivation is discussed in Section 2.1. Since
authenticator (see Section 1.5); TSK derivation is discussed in demonstration of authorization within the Secure Association Protocol
Section 2.1. Since demonstration of authorization within the Secure exchange depends on possession of transported keying material, the
Association Protocol exchange depends on possession of transported backend authentication server can obtain TSKs unless it deletes the
keying material, the backend authentication server can obtain TSKs transported keying material after sending it.
unless it deletes the transported keying material after sending it.
5.9. Key Naming 5.9. Key Naming
Mandatory requirement from [RFC4962] Section 3: Mandatory requirement from [RFC4962] Section 3:
Uniquely named keys Uniquely named keys
AAA key management proposals require a robust key naming scheme, AAA key management proposals require a robust key naming scheme,
particularly where key caching is supported. The key name particularly where key caching is supported. The key name
provides a way to refer to a key in a protocol so that it is clear provides a way to refer to a key in a protocol so that it is clear
skipping to change at page 62, line 33 skipping to change at page 67, line 13
the key name MUST NOT directly or indirectly disclose the keying the key name MUST NOT directly or indirectly disclose the keying
material. If the key name is not based on the keying material, material. If the key name is not based on the keying material,
then one can be sure that it cannot be used to assist in a search then one can be sure that it cannot be used to assist in a search
for the key value. for the key value.
EAP key names (defined in Section 1.4.1), along with the Peer-Id(s) EAP key names (defined in Section 1.4.1), along with the Peer-Id(s)
and Server-Id(s), uniquely identify EAP keying material, and do not and Server-Id(s), uniquely identify EAP keying material, and do not
directly or indirectly expose EAP keying material. directly or indirectly expose EAP keying material.
Existing AAA server implementations do not distribute key names along Existing AAA server implementations do not distribute key names along
with the transported keying material, although Diameter EAP with the transported keying material. However, Diameter EAP
[RFC4072], provides the EAP-Key-Name AVP for this purpose. Since the [RFC4072] Section 4.1.4 defines the EAP-Key-Name AVP for the purpose
EAP-Key-Name AVP is defined within the RADIUS attribute space, it can of transporting the EAP Session-Id. Since the EAP-Key-Name AVP is
be used either with RADIUS or Diameter. defined within the RADIUS attribute space, it can be used either with
RADIUS or Diameter.
Since the authenticator is not provided with the name of the Since the authenticator is not provided with the name of the
transported keying material by existing backend authentication server transported keying material by existing backend authentication server
implementations, existing Secure Association Protocols do not utilize implementations, existing Secure Association Protocols do not utilize
EAP key names. For example, [IEEE-802.11] supports PMK caching; to EAP key names. For example, [IEEE-802.11] supports PMK caching; to
enable the peer and authenticator to determine the cached PMK to enable the peer and authenticator to determine the cached PMK to
utilize within the 4-way handshake the PMK needs to be named. For utilize within the 4-way handshake, the PMK needs to be named. For
this purpose [IEEE-802.11] utilizes a PMK naming scheme which is this purpose, [IEEE-802.11] utilizes a PMK naming scheme that is
based on the key. Since IKEv2 [RFC4306] does not cache transported based on the key. Since IKEv2 [RFC4306] does not cache transported
keying material, it does not need to refer to transported keying keying material, it does not need to refer to transported keying
material. material.
5.10. Denial of Service Attacks 5.10. Denial-of-Service Attacks
Key caching can result in vulnerability to denial of service attacks. Key caching can result in vulnerability to denial-of-service attacks.
For example, EAP methods that create persistent state can be For example, EAP methods that create persistent state can 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
can limit the persistent state created by an EAP peer. For example, can limit the persistent state created by an EAP peer. For example,
for each peer an EAP server can choose to limit persistent state to a for each peer an EAP server can choose to limit persistent state to a
few EAP conversations, distinguished by the EAP Session-Id. This few EAP conversations, distinguished by the EAP Session-Id. This
prevents a rogue peer from denying access to other peers. prevents a rogue peer from denying access to other peers.
Similarly, to conserve resources an authenticator can choose to limit Similarly, to conserve resources an authenticator can 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 state corresponding accomplished by limiting each peer to persistent state corresponding
to a few EAP conversations, distinguished by the EAP Session-Id. to a few EAP conversations, distinguished by the EAP Session-Id.
Whether creation of new TSKs implies deletion of previously derived Whether creation of new TSKs implies deletion of previously derived
TSKs depends on the EAP lower layer. Where there is no implied TSKs depends on the EAP lower layer. Where there is no implied
deletion, the authenticator can choose to limit the number of TSKs deletion, the authenticator can 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.
6. IANA Considerations 6. References
This specification does not request the creation of any new parameter
registries, nor does it require any other IANA assignments.
7. References
7.1. Normative References 6.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.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and
Levkowetz, "Extensible Authentication Protocol (EAP)", H. Levkowetz, Ed., "Extensible Authentication Protocol
RFC 3748, June 2004. (EAP)", RFC 3748, June 2004.
[RFC4962] Housley, R. and B. Aboba, "Guidance for AAA Key [RFC4962] Housley, R. and B. Aboba, "Guidance for
Management", RFC 4962, July 2007. Authentication, Authorization, and Accounting (AAA)
Key Management", BCP 132, RFC 4962, July 2007.
7.2. Informative References 6.2. Informative References
[8021XPreAuth] Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff in [8021XPreAuth] Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff
a Public Wireless LAN Based on IEEE 802.1x Model", in a Public Wireless LAN Based on IEEE 802.1x Model",
Proceedings of the IFIP TC6/WG6.8 Working Conference on Proceedings of the IFIP TC6/WG6.8 Working Conference
Personal Wireless Communications, p.175-182, October on Personal Wireless Communications, p.175-182,
23-25, 2002. October 23-25, 2002.
[Analysis] He, C. and J. Mitchell, "Analysis of the 802.11i 4-Way [Analysis] 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 Security, pp. 43-50, ISBN: 1-58113-925-X. Wireless Security, pp. 43-50, ISBN: 1-58113-925-X.
[Bargh] Bargh, M., Hulsebosch, R., Eertink, E., Prasad, A., Wang, [Bargh] Bargh, M., Hulsebosch, R., Eertink, E., Prasad, A.,
H. and P. Schoo, "Fast Authentication Methods for Wang, H. and P. Schoo, "Fast Authentication Methods
Handovers between IEEE 802.11 Wireless LANs", Proceedings for Handovers between IEEE 802.11 Wireless LANs",
of the 2nd ACM international workshop on Wireless mobile Proceedings of the 2nd ACM international workshop on
applications and services on WLAN hotspots, October, Wireless mobile applications and services on WLAN
2004. hotspots, October, 2004.
[GKDP] Dondeti, L., Xiang, J. and S. Rowles, "GKDP: Group Key [GKDP] Dondeti, L., Xiang, J., and S. Rowles, "GKDP: Group
Distribution Protocol", Internet draft (work in Key Distribution Protocol", Work in Progress, March
progress), draft-ietf-msec-gkdp-01, March 2006. 2006.
[He] He, C., Sundararajan, M., Datta, A. Derek, A. and J. C. [He] He, C., Sundararajan, M., Datta, A. Derek, A. and J.
Mitchell, "A Modular Correctness Proof of TLS and IEEE C. Mitchell, "A Modular Correctness Proof of TLS and
802.11i", ACM Conference on Computer and Communications IEEE 802.11i", ACM Conference on Computer and
Security (CCS '05), November, 2005. Communications Security (CCS '05), November, 2005.
[IEEE-802.11] Institute of Electrical and Electronics Engineers, [IEEE-802.11] Institute of Electrical and Electronics Engineers,
"Information technology - Telecommunications and "Information technology - Telecommunications and
information exchange between systems - Local and information exchange between systems - Local and
metropolitan area networks - Specific Requirements Part metropolitan area networks - Specific Requirements
11: Wireless LAN Medium Access Control (MAC) and Part 11: Wireless LAN Medium Access Control (MAC) and
Physical Layer (PHY) Specifications", IEEE IEEE Standard Physical Layer (PHY) Specifications", IEEE Standard
802.11-2007, 2007. 802.11-2007, 2007.
[IEEE-802.1X] Institute of Electrical and Electronics Engineers, "Local [IEEE-802.1X] Institute of Electrical and Electronics Engineers,
and Metropolitan Area Networks: Port-Based Network Access "Local and Metropolitan Area Networks: Port-Based
Control", IEEE Standard 802.1X-2004, December 2004. Network Access Control", IEEE Standard 802.1X-2004,
December 2004.
[IEEE-802.1Q] IEEE Standards for Local and Metropolitan Area Networks: [IEEE-802.1Q] IEEE Standards for Local and Metropolitan Area
Draft Standard for Virtual Bridged Local Area Networks, Networks: Draft Standard for Virtual Bridged Local
P802.1Q-2003, January 2003. Area Networks, P802.1Q-2003, January 2003.
[IEEE-802.11i] Institute of Electrical and Electronics Engineers, [IEEE-802.11i] Institute of Electrical and Electronics Engineers,
"Supplement to Standard for Telecommunications and "Supplement to Standard for Telecommunications and
Information Exchange Between Systems - LAN/MAN Specific Information Exchange Between Systems - LAN/MAN
Requirements - Part 11: Wireless LAN Medium Access Specific Requirements - Part 11: Wireless LAN Medium
Control (MAC) and Physical Layer (PHY) Specifications: Access Control (MAC) and Physical Layer (PHY)
Specification for Enhanced Security", IEEE 802.11i/D1, Specifications: Specification for Enhanced Security",
2001. IEEE 802.11i/D1, 2001.
[IEEE-802.11F] Institute of Electrical and Electronics Engineers, [IEEE-802.11F] 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 Interoperability via an Inter-Access Point Protocol
Across Distribution Systems Supporting IEEE 802.11 Across Distribution Systems Supporting IEEE 802.11
Operation", IEEE 802.11F, July 2003 (now deprecated). Operation", IEEE 802.11F, July 2003 (now deprecated).
[IEEE-802.16e] Institute of Electrical and Electronics Engineers, "IEEE [IEEE-802.16e] Institute of Electrical and Electronics Engineers,
Standard for Local and Metropolitan Area Networks: Part "IEEE Standard for Local and Metropolitan Area
16: Air Interface for Fixed and Mobile Broadband Wireless Networks: Part 16: Air Interface for Fixed and Mobile
Access Systems: Amendment for Physical and Medium Access Broadband Wireless Access Systems: Amendment for
Control Layers for Combined Fixed and Mobile Operations Physical and Medium Access Control Layers for Combined
in Licensed Bands" IEEE 802.16e, August 2005. Fixed and Mobile Operations in Licensed Bands" IEEE
802.16e, August 2005.
[IEEE-03-084] Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, [IEEE-03-084] Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K.
"Proactive Key Distribution to support fast and secure Jang, "Proactive Key Distribution to support fast and
roaming", IEEE 802.11 Working Group, IEEE-03-084r1-I, secure roaming", IEEE 802.11 Working Group, IEEE-03-
http://www.ieee802.org/11/Documents/DocumentHolder/ 084r1-I, http://www.ieee802.org/11/Documents/
3-084.zip, January 2003. DocumentHolder/3-084.zip, January 2003.
[I-D.arkko-eap-service-identity-auth] [EAP-SERVICE] Arkko, J. and P. Eronen, "Authenticated Service
Arkko, J. and P. Eronen, "Authenticated Service
Information for the Extensible Authentication Protocol Information for the Extensible Authentication Protocol
(EAP)", draft-arkko-eap-service-identity-auth-04.txt (EAP)", Work in Progress, October 2005.
Internet draft (work in progress), October 2005.
[I-D.friedman-ike-short-term-certs] [SHORT-TERM] Friedman, A., Sheffer, Y., and A. Shaqed, "Short-Term
Friedman, A., Sheffer, Y. and A. Shaqed, "Short-Term Certificates", Work in Progress, June 2007.
Certificates", draft-friedman-ike-short-term-certs-02,
Internet draft (work in progress), June 2007.
[I-D.irtf-aaaarch-handoff] [HANDOFF] Arbaugh, W. and B. Aboba, "Handoff Extension to
Arbaugh, W. and B. Aboba, "Handoff Extension to RADIUS", RADIUS", Work in Progress, October 2003.
draft-irtf-aaaarch-handoff-04.txt, Internet Draft (work
in progress), October 2003.
[I-D.ohba-eap-channel-binding] [EAP-CHANNEL] Ohba, Y., Parthasrathy, M., and M. Yanagiya, "Channel
Ohba, Y., Parthasrathy, M. and M. Yanagiya, "Channel
Binding Mechanism Based on Parameter Binding in Key Binding Mechanism Based on Parameter Binding in Key
Derivation", draft-ohba-eap-channel-binding-02.txt, Derivation", Work in Progress, June 2007.
Internet draft (work in progress), December 2006.
[I-D.puthenkulam-eap-binding]
Puthenkulam, J., Lortz, V., Palekar, A. and D. Simon,
"The Compound Authentication Binding Problem", draft-
puthenkulam-eap-binding-04, Internet draft (work in
progress), October 2003.
[I-D.simon-emu-rfc2716bis]
Simon, D., Aboba, B. and R. Hurst, "The EAP TLS
Authentication Protocol", draft-simon-emu-
rfc2716bis-11.txt, Internet Draft (work in progress),
July 2007.
[I-D.ietf-tls-rfc4346-bis] [EAP-BINDING] Puthenkulam, J., Lortz, V., Palekar, A., and D. Simon,
Dierks, T. and E. Rescorla, "The Transport Layer Security "The Compound Authentication Binding Problem", Work in
(TLS) Protocol Version 1.2", draft-ietf-tls- Progress, October 2003.
rfc4346-bis-05.txt, Internet draft (work in progress),
September 2007.
[MD5Collision] Klima, V., "Tunnels in Hash Functions: MD5 Collisions [MD5Collision] Klima, V., "Tunnels in Hash Functions: MD5 Collisions
Within a Minute", Cryptology ePrint Archive, March 2006, Within a Minute", Cryptology ePrint Archive, March
http://eprint.iacr.org/2006/105.pdf 2006, http://eprint.iacr.org/2006/105.pdf
[MishraPro] Mishra, A., Shin, M. and W. Arbaugh, "Pro-active Key [MishraPro] Mishra, A., Shin, M. and W. Arbaugh, "Pro-active Key
Distribution using Neighbor Graphs", IEEE Wireless Distribution using Neighbor Graphs", IEEE Wireless
Communications, vol. 11, February 2004. Communications, vol. 11, February 2004.
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)",
RFC 1661, July 1994. STD 51, RFC 1661, July 1994.
[RFC1968] Meyer, G. and K. Fox, "The PPP Encryption Control [RFC1968] Meyer, G., "The PPP Encryption Control Protocol
Protocol (ECP)", RFC 1968, June 1996. (ECP)", RFC 1968, June 1996.
[RFC2230] Atkinson, R., "Key Exchange Delegation Record for the [RFC2230] Atkinson, R., "Key Exchange Delegation Record for the
DNS", RFC 2230, November 1997. DNS", RFC 2230, November 1997.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998. (IKE)", RFC 2409, November 1998.
[RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D. [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone,
and R. Wheeler, "A Method for Transmitting PPP Over D., and R. Wheeler, "A Method for Transmitting PPP
Ethernet (PPPoE)", RFC 2516, February 1999. Over Ethernet (PPPoE)", RFC 2516, February 1999.
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS
RFC 2548, March 1999. Attributes", RFC 2548, March 1999.
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and
Implementation in Roaming", RFC 2607, June 1999. Policy Implementation in Roaming", RFC 2607, June
1999.
[RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication
Protocol", 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
specifying the location of services (DNS SRV)", RFC 2782, for specifying the location of services (DNS SRV)",
February 2000. RFC 2782, February 2000.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
Wellington, "Secret Key Transaction Authentication for Wellington, "Secret Key Transaction Authentication for
DNS (TSIG)", RFC 2845, May 2000. DNS (TSIG)", RFC 2845, May 2000.
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", "Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000. RFC 2865, June 2000.
[RFC3007] Wellington, B., "Simple Secure Domain Name System (DNS) [RFC3007] Wellington, B., "Secure Domain Name System (DNS)
Dynamic Update", RFC 3007, November 2000. Dynamic Update", RFC 3007, November 2000.
[RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
3162, August 2001. RFC 3162, August 2001.
[RFC3547] Baugher, M., Weis, B., Hardjono, T. and H. Harney, "The [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney,
Group Domain of Interpretation", RFC 3547, July 2003. "The Group Domain of Interpretation", RFC 3547, July
2003.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote
Dial In User Service) Support For Extensible Authentication Dial In User Service) Support For
Authentication Protocol (EAP)", RFC 3579, September 2003. Extensible Authentication 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.
"IEEE 802.1X Remote Authentication Dial In User Service Roese, "IEEE 802.1X Remote Authentication Dial In User
(RADIUS) Usage Guidelines", RFC 3580, September 2003. Service (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
Arkko, "Diameter Base Protocol", RFC 3588, September J. Arkko, "Diameter Base Protocol", RFC 3588,
2003. September 2003.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
Public Keys Used For Exchanging Symmetric Keys", RFC Public Keys Used For Exchanging Symmetric Keys", BCP
3766, April 2004. 86, RFC 3766, April 2004.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M. and K. [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC
August 2004. 3830, August 2004.
[RFC4005] Calhoun, P., Zorn, G., Spence, D. and D. Mitton, [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
"Diameter Network Access Server Application", RFC 4005, "Diameter Network Access Server Application", RFC
August 2005 4005, August 2005.
[RFC4017] Stanley, D., Walker, J. and B. Aboba, "EAP Method [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible
Requirements for Wireless LANs", RFC 4017, March 2005. Authentication Protocol (EAP) Method Requirements for
Wireless LANs", RFC 4017, March 2005.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D. and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and
Rose, "DNS Security Introduction and Requirements", RFC S. Rose, "DNS Security Introduction and Requirements",
4033, March 2005. RFC 4033, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D. and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and
Rose, "Protocol Modifications for the DNS Security S. Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005. Extensions", RFC 4035, March 2005.
[RFC4067] Loughney, J., Nakhjiri, M., Perkins, C. and R. Koodli, [RFC4067] Loughney, J., Ed., Nakhjiri, M., Perkins, C., and R.
"Context Transfer Protocol (CXTP)", RFC 4067, July 2005. Koodli, "Context Transfer Protocol (CXTP)", RFC 4067,
July 2005.
[RFC4072] Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible [RFC4072] Eronen, P., Ed., Hiller, T., and G. Zorn, "Diameter
Authentication Protocol (EAP) Application", RFC 4072, Extensible Authentication Protocol (EAP) Application",
August 2005. RFC 4072, August 2005.
[RFC4118] Yang, L., Zerfos, P. and E. Sadot, "Architecture Taxonomy [RFC4118] Yang, L., Zerfos, P., and E. Sadot, "Architecture
for Control and Provisioning of Wireless Access Points Taxonomy for Control and Provisioning of Wireless
(CAPWAP)", RFC 4118, June 2005. Access Points (CAPWAP)", RFC 4118, June 2005.
[RFC4186] Haverinen, H. and J. Salowey, "Extensible Authentication [RFC4186] Haverinen, H., Ed., and J. Salowey, Ed., "Extensible
Protocol Method for Global System for Mobile Authentication Protocol Method for Global System for
Communications (GSM) Subscriber Identity Modules (EAP- Mobile Communications (GSM) Subscriber Identity
SIM)", RFC 4186, January 2006. Modules (EAP-SIM)", RFC 4186, January 2006.
[RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication
Protocol Method for 3rd Generation Authentication and Key Protocol Method for 3rd Generation Authentication and
Agreement (EAP-AKA)", RFC 4187, January 2006. Key Agreement (EAP-AKA)", RFC 4187, January 2006.
[RFC4282] Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005. Network Access Identifier", RFC 4282, December 2005.
[RFC4284] Adrangi, F., Lortz, V., Bari, F. and P. Eronen, "Identity [RFC4284] Adrangi, F., Lortz, V., Bari, F., and P. Eronen,
Selection Hints for the Extensible Authentication "Identity Selection Hints for the Extensible
Protocol", RFC 4284, January 2006. Authentication Protocol (EAP)", RFC 4284, January
2006.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
RFC 4306, December 2005. Protocol", RFC 4306, December 2005.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4372] Adrangi, F., Lior, A., Korhonen, J. and J. Loughney, [RFC4372] Adrangi, F., Lior, A., Korhonen, J., and J. Loughney,
"Chargeable User Identity", RFC 4372, January 2006. "Chargeable User Identity", RFC 4372, January 2006.
[RFC4334] Housley, R. and T. Moore, "Certificate Extensions and [RFC4334] Housley, R. and T. Moore, "Certificate Extensions and
Attributes Supporting Authentication in Point-to-Point Attributes Supporting Authentication in Point-to-Point
Protocol (PPP) and Wireless Local Area Networks (WLAN)", Protocol (PPP) and Wireless Local Area Networks
RFC 4334, February 2006. (WLAN)", RFC 4334, February 2006.
[RFC4535] Harney, H., Meth, U., Colegrove, A. and G. Gross, [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross,
"GSAKMP: Group Secure Association Group Management "GSAKMP: Group Secure Association Key Management
Protocol", RFC 4535, June 2006. Protocol", RFC 4535, June 2006.
[RFC4763] Vanderveen, M. and H. Soliman, "Extensible Authentication [RFC4763] Vanderveen, M. and H. Soliman, "Extensible
Protocol Method for Shared-secret Authentication and Key Authentication Protocol Method for Shared-secret
Establishment (EAP-SAKE)", RFC 4763, November 2006. Authentication and Key Establishment (EAP-SAKE)", RFC
4763, November 2006.
[RFC4675] Congdon, P., Sanchez, M. and B. Aboba, "RADIUS Attributes [RFC4675] Congdon, P., Sanchez, M., and B. Aboba, "RADIUS
for Virtual LAN and Priority Support", RFC 4675, Attributes for Virtual LAN and Priority Support", RFC
September 2006. 4675, September 2006.
[RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and [RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and
Implementation Guidelines", RFC 4718, October 2006. Implementation Guidelines", RFC 4718, October 2006.
[RFC4764] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: a [RFC4764] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol:
Pre-Shared Key Extensible Authentication Protocol (EAP) A Pre-Shared Key Extensible Authentication Protocol
Method", RFC 4764, January 2007. (EAP) Method", RFC 4764, January 2007.
[RFC3576bis] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
Aboba, "Dynamic Authorization Extensions to Remote Aboba, "Dynamic Authorization Extensions to Remote
Authentication Dial In User Service (RADIUS)", draft- Authentication Dial In User Service (RADIUS)", RFC
ietf-radext-rfc3576bis-13.txt, Internet draft (work in 5176, January 2008.
progress), October 2007.
[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
Authentication Protocol", RFC 5216, March 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer
Security (TLS) Protocol Version 1.2", RFC 5246, August
2008.
[SP800-57] National Institute of Standards and Technology, [SP800-57] National Institute of Standards and Technology,
"Recommendation for Key Management", Special Publication "Recommendation for Key Management", Special
800-57, May 2006. Publication 800-57, May 2006.
[Token] Fantacci, R., Maccari, L., Pecorella, T. and F. Frosali, [Token] Fantacci, R., Maccari, L., Pecorella, T., and F.
"A secure and performant token-based authentication for Frosali, "A secure and performant token-based
infrastructure and mesh 802.1X networks", IEEE authentication for infrastructure and mesh 802.1X
Conference on Computer Communications, June 2006. networks", IEEE Conference on Computer Communications,
June 2006.
[Tokenk] Ohba, Y., Das, S. and A. Duttak, "Kerberized Handover [Tokenk] Ohba, Y., Das, S., and A. Duttak, "Kerberized Handover
Keying: A Media-Independent Handover Key Management Keying: A Media-Independent Handover Key Management
Architecture", Mobiarch 2007. Architecture", Mobiarch 2007.
Acknowledgments Acknowledgments
Thanks to Ashwin Palekar, Charlie Kaufman and Tim Moore of Microsoft, Thanks to Ashwin Palekar, Charlie Kaufman, and Tim Moore of
Jari Arkko of Ericsson, Dorothy Stanley of Aruba Networks, Bob Microsoft, Jari Arkko of Ericsson, Dorothy Stanley of Aruba Networks,
Moskowitz of TruSecure, Jesse Walker of Intel, Joe Salowey of Cisco Bob Moskowitz of TruSecure, Jesse Walker of Intel, Joe Salowey of
and Russ Housley of Vigil Security for useful feedback. Cisco, and Russ Housley of Vigil Security for useful feedback.
Authors' Addresses
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
EMail: bernarda@microsoft.com
Phone: +1 425 706 6605
Fax: +1 425 936 7329
Dan Simon
Microsoft Research
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
EMail: dansimon@microsoft.com
Phone: +1 425 706 6711
Fax: +1 425 936 7329
Pasi Eronen
Nokia Research Center
P.O. Box 407
FIN-00045 Nokia Group
Finland
EMail: pasi.eronen@nokia.com
Appendix A - Exported Parameters in Existing Methods Appendix A - Exported Parameters in Existing Methods
This Appendix specifies Session-Id, Peer-Id, Server-Id and Key- This Appendix specifies Session-Id, Peer-Id, Server-Id and
Lifetime for EAP methods that have been published prior to this Key-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 Session-Id, Peer-Id and Server-Id (could be the definition of the Session-Id, Peer-Id and Server-Id (could be the
null string). null string). In the descriptions that follow, all fields comprising
the Session-Id are assumed to be in network byte order.
EAP-Identity EAP-Identity
The EAP-Identity method is defined in [RFC3748]. It does not derive The EAP-Identity method is defined in [RFC3748]. It does not
keys, and therefore does not define the Session-Id. The Peer-Id and derive keys, and therefore does not define the Session-Id. The
Server-Id are the null string (zero length). Peer-Id and Server-Id are the null string (zero length).
EAP-Notification EAP-Notification
The EAP-Notification method is defined in [RFC3748]. It does not The EAP-Notification method is defined in [RFC3748]. It does not
derive keys and therefore does not define the Session-Id. The Peer- derive keys and therefore does not define the Session-Id. The
Id and Server-Id are the null string (zero length). Peer-Id and Server-Id are the null string (zero length).
EAP-MD5-Challenge EAP-MD5-Challenge
The EAP-MD5-Challenge method is defined in [RFC3748]. It does not The EAP-MD5-Challenge method is defined in [RFC3748]. It does not
derive keys and therefore does not define the Session-Id. The Peer- derive keys and therefore does not define the Session-Id. The
Id and Server-Id are the null string (zero length). Peer-Id and Server-Id are the null string (zero length).
EAP-GTC EAP-GTC
The EAP-GTC method is defined in [RFC3748]. It does not derive keys The EAP-GTC method is defined in [RFC3748]. It does not derive
and therefore does not define the Session-Id. The Peer-Id and keys and therefore does not define the Session-Id. The Peer-Id
Server-Id are the null string (zero length). and Server-Id are the null string (zero length).
EAP-OTP EAP-OTP
The EAP-OTP method is defined in [RFC3748]. It does not derive keys The EAP-OTP method is defined in [RFC3748]. It does not derive
and therefore does not define the Session-Id. The Peer-Id and keys and therefore does not define the Session-Id. The Peer-Id
Server-Id are the null string (zero length). and Server-Id are the null string (zero length).
EAP-AKA EAP-AKA
EAP-AKA is defined in [RFC4187]. The EAP-AKA Session-Id is the EAP-AKA is defined in [RFC4187]. The EAP-AKA Session-Id is the
concatenation of the EAP Type Code (0x17) with the contents of the concatenation of the EAP Type Code (0x17) with the contents of the
RAND field from the AT_RAND attribute, followed by the contents of RAND field from the AT_RAND attribute, followed by the contents of
the AUTN field in the AT_AUTN attribute. the AUTN field in the AT_AUTN attribute:
Session-Id = 0x17 || RAND || AUTN
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 octets AT_IDENTITY attribute, using only the Actual Identity Length
from the beginning, however. Note that the contents are used as they octets from the beginning, however. Note that the contents are
are transmitted, regardless of whether the transmitted identity was a used as they are transmitted, regardless of whether the
permanent, pseudonym, or fast EAP re-authentication identity. The transmitted identity was a permanent, pseudonym, or fast EAP
Server-Id is the null string (zero length). re-authentication identity. The Server-Id is the null string
(zero length).
EAP-SIM EAP-SIM
EAP-SIM is defined in [RFC4186]. The EAP-SIM Session-Id is the EAP-SIM is defined in [RFC4186]. The EAP-SIM Session-Id is the
concatenation of the EAP Type Code (0x12) with the contents of the concatenation of the EAP Type Code (0x12) with the contents of the
RAND field from the AT_RAND attribute, followed by the contents of RAND field from the AT_RAND attribute, followed by the contents of
the NONCE_MT field in the AT_NONCE_MT attribute. the NONCE_MT field in the AT_NONCE_MT attribute:
Session-Id = 0x12 || RAND || NONCE_MT
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 octets AT_IDENTITY attribute, using only the Actual Identity Length
from the beginning, however. Note that the contents are used as they octets from the beginning, however. Note that the contents are
are transmitted, regardless of whether the transmitted identity was a used as they are transmitted, regardless of whether the
permanent, pseudonym, or fast EAP re-authentication identity. The transmitted identity was a permanent, pseudonym, or fast EAP
Server-Id is the null string (zero length). re-authentication identity. The Server-Id is the null string
(zero length).
EAP-PSK EAP-PSK
EAP-PSK is defined in [RFC4764]. The EAP-PSK Session-Id is the EAP-PSK is defined in [RFC4764]. The EAP-PSK Session-Id is the
concatenation of the EAP Type Code (0x2F) with the peer (RAND_P) and concatenation of the EAP Type Code (0x2F) with the peer (RAND_P)
server (RAND_S) nonces. The Peer-Id is the contents of the ID_P and server (RAND_S) nonces:
field and the Server-Id is the contents of the ID_S field.
Session-Id = 0x2F || RAND_P || RAND_S
The Peer-Id is the contents of the ID_P field and the Server-Id is
the contents of the ID_S field.
EAP-SAKE EAP-SAKE
EAP-SAKE is defined in [RFC4763]. The EAP-SAKE Session-Id is the EAP-SAKE is defined in [RFC4763]. The EAP-SAKE Session-Id is the
concatenation of the EAP Type Code (0x30) with the contents of the concatenation of the EAP Type Code (0x30) with the contents of the
RAND_S field from the AT_RAND_S attribute, followed by the contents RAND_S field from the AT_RAND_S attribute, followed by the
of the RAND_P field in the AT_RAND_P attribute. Note that the EAP- contents of the RAND_P field in the AT_RAND_P attribute:
SAKE Session-Id is not the same as the "Session ID" parameter chosen
by the Server, which is sent in the first message, and replicated in Session-Id = 0x30 || RAND_S || RAND_P
subsequent messages. The Peer-Id is contained within the value field
of the AT_PEERID attribute and the Server-Id, if available, is Note that the EAP-SAKE Session-Id is not the same as the "Session
contained in the value field of the AT_SERVERID attribute. ID" parameter chosen by the Server, which is sent in the first
message, and replicated in subsequent messages. The Peer-Id is
contained within the value field of the AT_PEERID attribute and
the Server-Id, if available, is contained in the value field of
the AT_SERVERID attribute.
EAP-TLS EAP-TLS
For EAP-TLS, the Peer-Id, Server-Id and Session-Id are defined in [I- For EAP-TLS, the Peer-Id, Server-Id and Session-Id are defined in
D.simon-emu-rfc2716bis]. [RFC5216].
Authors' Addresses
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
EMail: bernarda@microsoft.com
Phone: +1 425 706 6605
Fax: +1 425 936 7329
Dan Simon
Microsoft Research
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
EMail: dansimon@microsoft.com
Phone: +1 425 706 6711
Fax: +1 425 936 7329
Pasi Eronen
Nokia Research Center
P.O. Box 407
FIN-00045 Nokia Group
Finland
EMail: pasi.eronen@nokia.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
skipping to change at page 73, line 44 skipping to change at line 3495
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Open Issues
Open issues relating to this specification are tracked on the
following web site:
http://www.drizzle.com/~aboba/EAP/
 End of changes. 361 change blocks. 
1175 lines changed or deleted 1207 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/