< draft-ietf-eap-keying-17.txt   draft-ietf-eap-keying-18.txt >
EAP Working Group Bernard Aboba EAP Working Group Bernard Aboba
INTERNET-DRAFT Dan Simon INTERNET-DRAFT Dan Simon
Category: Standards Track Microsoft Category: Standards Track Microsoft
<draft-ietf-eap-keying-17.txt> P. Eronen <draft-ietf-eap-keying-18.txt> P. Eronen
19 January 2007 Nokia 7 February 2007 Nokia
H. Levkowetz H. Levkowetz
Ericsson Research Ericsson Research
Extensible Authentication Protocol (EAP) Key Management Framework Extensible Authentication Protocol (EAP) Key Management Framework
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 18, 2007. This Internet-Draft will expire on August 8, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). All rights reserved. Copyright (C) The IETF Trust (2007). All rights reserved.
Abstract Abstract
The Extensible Authentication Protocol (EAP), defined in [RFC3748], The Extensible Authentication Protocol (EAP), defined in [RFC3748],
enables extensible network access authentication. This document enables extensible network access authentication. This document
provides a framework for the transport and usage of keying material specifies the EAP key hierarchy and provides a framework for the
generated by EAP authentication algorithms, known as "methods". It transport and usage of keying material generated by EAP
also specifies the EAP key hierarchy. authentication algorithms, known as "methods". It also provides a
system-level security analysis.
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 ........................................ 6 1.3 Overview ........................................ 6
1.4 EAP Key Hierarchy ............................... 9 1.4 EAP Key Hierarchy ............................... 9
1.5 Security Goals .................................. 13 1.5 Security Goals .................................. 13
1.6 EAP Invariants .................................. 14 1.6 EAP Invariants .................................. 14
2. Lower Layer Operation ................................. 17 2. Lower Layer Operation ................................. 17
2.1 Transient Session Keys .......................... 18 2.1 Transient Session Keys .......................... 18
2.2 Authenticator and Peer Architecture ............. 19 2.2 Authenticator and Peer Architecture ............. 19
2.3 Server Identification ........................... 24 2.3 Server Identification ........................... 24
3. Security Association Management ....................... 26 3. Security Association Management ....................... 26
3.1 Secure Association Protocol ..................... 26 3.1 Secure Association Protocol ..................... 27
3.2 Key Scope ....................................... 29 3.2 Key Scope ....................................... 30
3.3 Parent-Child Relationships ...................... 30 3.3 Parent-Child Relationships ...................... 30
3.4 Local Key Lifetimes ............................. 31 3.4 Local Key Lifetimes ............................. 31
3.5 Exported and Calculated Key Lifetimes ........... 31 3.5 Exported and Calculated Key Lifetimes ........... 32
3.6 Key Cache Synchronization ....................... 33 3.6 Key Cache Synchronization ....................... 34
3.7 Key Strength .................................... 34 3.7 Key Strength .................................... 34
3.8 Key Wrap ........................................ 34 3.8 Key Wrap ........................................ 35
4. Handoff Vulnerabilities ............................... 35 4. Handoff Vulnerabilities ............................... 35
4.1 EAP Pre-authentication .......................... 36 4.1 EAP Pre-authentication .......................... 36
4.2 Proactive Key Distribution ...................... 37 4.2 Proactive Key Distribution ...................... 38
4.3 AAA Bypass ...................................... 39 4.3 AAA Bypass ...................................... 39
5. Security Considerations .............................. 43 5. Security Considerations .............................. 43
5.1 Authenticator Compromise ........................ 44 5.1 Peer and Authenticator Compromise ............... 44
5.2 Spoofing ........................................ 45 5.2 Cryptographic Negotiation ....................... 45
5.3 Downgrade Attacks ............................... 45 5.3 Confidentiality and Authentication .............. 46
5.4 Unauthorized Disclosure ......................... 46 5.4 Key Binding ...................................... 51
5.5 Replay Protection ............................... 48 5.5 Authorization ................................... 52
5.6 Key Freshness ................................... 48 5.6 Replay Protection ............................... 53
5.7 Elevation of Privilege .......................... 49 5.7 Key Freshness ................................... 54
5.8 Man-in-the-Middle Attacks ....................... 50 5.8 Key Scope Limitation ............................ 55
5.9 Denial of Service Attacks ....................... 51 5.9 Key Naming ...................................... 56
5.10 Impersonation ................................... 51 5.10 Denial of Service Attacks ....................... 56
5.11 Channel Binding ................................. 52 6. IANA Considerations ................................... 57
6. IANA Considerations ................................... 54 7. References ............................................ 57
7. References ............................................ 54 7.1 Normative References ............................ 57
7.1 Normative References ............................ 54 7.2 Informative References .......................... 57
7.2 Informative References .......................... 54 Acknowledgments .............................................. 63
Acknowledgments .............................................. 60 Author's Addresses ........................................... 63
Author's Addresses ........................................... 60 Appendix A - Exported Parameters in Existing Methods ......... 64
Appendix A - Exported Parameters in Existing Methods ......... 61 Full Copyright Statement ..................................... 66
Intellectual Property Statement .............................. 63 Intellectual Property ........................................ 66
Disclaimer of Validity ....................................... 63
Copyright Statement .......................................... 63
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], IKEv2 [RFC4306] and wireless networks
such as [IEEE-802.11i] and [IEEE-802.16e]. such as [IEEE-802.11i] 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 may be algorithms, known as "methods". Part of this keying material may be
used by EAP methods themselves and part of this material may be used by EAP methods themselves and part of this material may be
exported. In addition to export of keying material, EAP methods may exported. In addition to export of keying material, EAP methods may
also export associated parameters such as authenticated peer and also export associated parameters such as authenticated peer and
server identities and a unique EAP conversation identifier, and may server identities and a unique EAP conversation identifier, and may
import and export lower layer parameters known as "Channel Bindings". import and export lower layer parameters known as "Channel Binding
parameters", or simply "channel bindings".
This document provides a framework for the transport and usage of This document specifies the EAP key hierarchy and provides a
keying material and parameters generated by EAP methods, as well as framework for the transport and usage of keying material and
specifying the EAP key hierarchy. It also provides a system-level parameters generated by EAP methods. It also provides a system-level
security analysis. security analysis.
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 [IEE-802.11i], which confirms mutual possession of a defined in [IEEE-802.11i], 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. AAA protocols with
EAP support include RADIUS [RFC3579] and Diameter [RFC4072]. In EAP support include RADIUS [RFC3579] and Diameter [RFC4072]. In
this document, the terms "AAA server" and "backend authentication 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 MSK. Since multiple keys may The term AAA-Key is synonymous with MSK. Since multiple keys may
be transported by AAA, the term is potentially confusing and is not be transported by AAA, the term is potentially confusing and is not
skipping to change at page 5, line 15 skipping to change at page 5, line 15
EAP server. Since the IV is a known value in methods such as EAP- EAP server. Since the IV is a known value in methods such as EAP-
TLS [I-D.simon-emu-rfc2716bis], it cannot be used by itself for TLS [I-D.simon-emu-rfc2716bis], it cannot be used by itself for
computation of any quantity that needs to remain secret. As a computation of any quantity that needs to remain secret. As a
result, its use has been deprecated and EAP methods are not result, its use has been deprecated and EAP methods are not
required to generate it. However, when it is generated it MUST be required to generate it. However, when it is generated it MUST be
unpredictable. unpredictable.
Key Scope Key Scope
The parties to whom a key is available. The parties to whom a key is available.
Key Wrap Keywrap
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 or
a key encryption algorithm. The key used in the encryption process a key encryption algorithm. The key used in the encryption process
is called a key-encryption key (KEK). 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 public-key
skipping to change at page 8, line 31 skipping to change at page 8, line 31
| (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 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
IKEv2, defined in [RFC4306], includes support for EAP and handles Internet Key Exchange v2 (IKEv2), defined in [RFC4306], includes
the establishment of unicast security associations (phase 2a). support for EAP and handles the establishment of unicast security
However, the establishment of multicast security associations associations (phase 2a). However, the establishment of multicast
(phase 2b) typically does not involve EAP and needs to be handled security associations (phase 2b) typically does not involve EAP and
by a group key management protocol such as GDOI [RFC3547], GSAKMP needs to be handled by a group key management protocol such as GDOI
[GSAKMP], MIKEY [RFC3830], or GKDP [GKDP]. Several mechanisms have [RFC3547], GSAKMP [GSAKMP], MIKEY [RFC3830], or GKDP [GKDP].
been proposed for discovery of IPsec security gateways. [RFC2230]
discusses the use of KX Resource Records (RRs) for IPsec gateway Several mechanisms have been proposed for discovery of IPsec
discovery; while KX RRs are supported by many DNS server security gateways. [RFC2230] discusses the use of Key eXchange
(KX) Resource Records (RRs) for IPsec gateway discovery; while KX
RRs are supported by many Domain Name Service (DNS) server
implementations, they have not yet been widely deployed. implementations, they have not yet been widely deployed.
Alternatively, DNS SRV [RFC2782] can be used for this purpose. Alternatively, DNS SRV [RFC2782] can be used for this purpose.
Where DNS is used for gateway location, DNS security mechanisms Where DNS is used for gateway location, DNS security mechanisms
such as DNSSEC ([RFC2535], [RFC2931]), TSIG [RFC2845], and Simple such as DNSSEC ([RFC4033], [RFC4035]), TSIG [RFC2845], and Simple
Secure Dynamic Update [RFC3007] are available. Secure Dynamic Update [RFC3007] are available.
IEEE 802.11i IEEE 802.11i
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 periodically announce their Service Set Identifiers (SSIDs)
as well as capabilities using Beacon frames. Stations can query as well as capabilities using Beacon frames. Stations can query
for access points by sending a Probe Request to the broadcast for access points by sending a Probe Request to the broadcast
address. Neither Beacon nor Probe Request/Response frames are address. Neither Beacon nor Probe Request/Response frames are
secured. The 4-way handshake defined in [IEEE-802.11i] enables the secured. The 4-way handshake defined in [IEEE-802.11i] enables the
skipping to change at page 10, line 14 skipping to change at page 10, line 15
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, EAP methods credential established between the peer and the server, EAP methods
derive two types of keys: derive two types of keys:
[a] Keys calculated locally by the EAP method but not exported (a) Keys calculated locally by the EAP method but not exported
by the EAP method, such as the TEKs. by the EAP method, such as the Transient EAP Keys (TEKs).
[b] Keying material exported by the EAP method: MSK, EMSK, IV. (b) Keying material exported by the EAP method: Master Session Key
(MSK), Extended Master Session Key (EMSK), Initiatlization
Vector (IV).
As noted in [RFC3748] Section 7.10, EAP methods generating keys are As noted in [RFC3748] Section 7.10, EAP methods generating keys are
required to calculate and export the MSK and EMSK, which must be at required to calculate and export the MSK and EMSK, which must be at
least 64 octets in length. EAP methods also may export the IV; least 64 octets in length. EAP methods also may export the IV;
however, the use of the IV is deprecated. however, the use of the IV is deprecated.
The EMSK MUST NOT be provided to an entity outside the EAP server or The EMSK MUST NOT be provided to an entity outside the EAP server or
peer, nor is it permitted to pass any quantity to an entity outside peer, nor is it permitted to pass any quantity to an entity outside
the EAP server or peer from which the EMSK could be computed without the EAP server or peer from which the EMSK could be computed without
breaking some cryptographic assumption, such as inverting a one-way breaking some cryptographic assumption, such as inverting a one-way
function. function.
EAP methods also MAY export method-specific peer and server EAP methods also MAY export method-specific peer (Peer-Id) and server
identifiers (Peer-Id and Server-Id) and a method-specific EAP (Server-Id) identifiers and a method-specific EAP conversation
conversation identifier known as the Session-Id. EAP methods MAY identifier known as the Session-Id. EAP methods MAY also support the
also support the import and export of Channel Bindings. New EAP import and export of channel binding parameters. New EAP method
method specifications MUST define the Peer-Id, Server-Id and Session- specifications MUST define the Peer-Id, Server-Id and Session-Id.
Id. The combination of the Peer-Id and Server-Id uniquely specifies The combination of the Peer-Id and Server-Id uniquely specifies the
the endpoints of the EAP method exchange when they are provided. The endpoints of the EAP method exchange when they are provided. For
Peer-Id, Server-Id, and Session-Id for existing EAP methods is existing EAP methods the Peer-Id, Server-Id, and Session-Id are
defined in Appendix A. defined in Appendix A.
Peer-Id Peer-Id
As described in [RFC3748] Section 7.3, the identity provided in As described in [RFC3748] Section 7.3, the identity provided in
the EAP-Response/Identity, may be different from the peer identity the EAP-Response/Identity may be different from the peer identity
authenticated by the EAP method. Where the EAP method authenticated by the EAP method. For example, the identity
authenticates the peer identity, that identity is exported by the provided in the EAP-Response/Identity may be a privacy identifier
method as the Peer-Id. A suitable EAP peer name may not always be as described in "The Network Access Identifier" [RFC4282] Section
available. Where an EAP method does not define a method-specific 2.3, or may be decorated as described in [RFC4282] Section 2.7.
peer identity, the Peer-Id is the null string. Where the EAP method authenticates the peer identity, that
identity is exported by the method as the Peer-Id. A suitable EAP
peer name may not always be available. Where an EAP method does
not define a method-specific peer identity, the Peer-Id is the
null string.
Server-Id Server-Id
Where the EAP method authenticates the server identity, that Where the EAP method authenticates the server identity, that
identity is exported by the method as the Server-Id. A suitable identity is exported by the method as the Server-Id. A suitable
EAP server name may not always be available. Where an EAP method EAP server name may not always be available. Where an EAP method
does not define a method-specific server identity, the Server-Id does not define a method-specific server identity, the Server-Id
is the null string. is the null string.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
skipping to change at page 11, line 29 skipping to change at page 11, line 37
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Method | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Method |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | | | | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | |
| | | TEK | |MSK, EMSK | |IV | | | | | | TEK | |MSK, EMSK | |IV | | |
| | |Derivation | |Derivation | |Derivation | | | | | |Derivation | |Derivation | |Derivation | | |
| | | | | | |(Deprecated) | | | | | | | | | |(Deprecated) | | |
| | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | | | | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | |
| | ^ | | | | | | ^ | | | |
| | | | | | V | | | | | | V
+-+-|-+-+-+-+-+-+-+-+-|-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+ ---+ +-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+ ---+
| | | | ^ | | | | ^
| Peer-Id, | | | Exported | | Peer-Id, | | | Exported |
| Server-Id, | Channel | MSK (64+B) | IV (64B) by | | Server-Id, | channel | MSK (64+B) | IV (64B) by |
| Session-Id | Bindings | EMSK (64+B) | (Optional) EAP | | Session-Id | bindings | EMSK (64+B) | (Optional) EAP |
| | & Result | | Method | | | & Result | | Method |
V V V V V V V V V V
Figure 2: EAP Method Parameter Import/Export Figure 2: EAP Method Parameter Import/Export
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 the EAP Type Code is less than 255, the EAP the Server-Id). Where the EAP Type Code is less than 255, the EAP
Session-Id consists of the concatenation of the EAP Type Code and Session-Id consists of the concatenation of the EAP Type Code and
a temporally unique identifier obtained from the method (known as a temporally unique identifier obtained from the method (known as
skipping to change at page 12, line 12 skipping to change at page 12, line 20
Vendor-Id and Vendor-Type fields defined in [RFC3748] Section 5.7) Vendor-Id and Vendor-Type fields defined in [RFC3748] Section 5.7)
concatenated with a temporally unique identifier obtained from the concatenated with a temporally unique identifier obtained from the
method (Method-Id). This unique identifier is typically method (Method-Id). This unique identifier is typically
constructed from nonces or counters used within the EAP method constructed from nonces or counters used within the EAP method
exchange. The inclusion of the Type Code in the EAP Session-Id exchange. The inclusion of the Type Code in the EAP Session-Id
ensures that each EAP method has a distinct Session-Id space. ensures that each EAP method has a distinct Session-Id space.
Since an EAP session is not bound to a particular authenticator or Since an EAP session is not bound to a particular authenticator or
specific ports on the peer and authenticator, the authenticator specific ports on the peer and authenticator, the authenticator
port or identity are not included in the Session-Id. port or identity are not included in the Session-Id.
Channel Bindings Channel Binding
Channel Bindings include lower layer parameters that are verified Channel Binding is the process by which lower layer parameters are
for consistency between the EAP peer and server. In order to verified for consistency between the EAP peer and server. In
avoid introducing media dependencies, EAP methods that transport order to avoid introducing media dependencies, EAP methods that
Channel Binding data MUST treat this data as opaque octets. See transport channel binding parameters MUST treat this data as
Section 5.11 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 parameters is defined by key is available). The scope of exported parameters is defined by
the EAP Peer-Id (if securely exchanged within the method) and the EAP the EAP Peer-Id (if securely exchanged within the method) and the EAP
Server-Id (also only if securely exchanged). Where a peer or server Server-Id (also only if securely exchanged). Where a peer or server
name is missing the null string is used. name is missing the null string is used.
MSK and EMSK Names MSK and EMSK Names
These parameters are exported by the EAP peer and EAP server, and These parameters are exported by the EAP peer and EAP server, and
can be referred to using the EAP Session-Id and a binary or textual can be referred to using the EAP Session-Id and a binary or textual
indication of the parameter being referred to. indication of the EAP keying material being referred to.
PMK Name PMK Name
This document does not specify a naming scheme for the PMK. The This document does not specify a naming scheme for the Pairwise
PMK is only identified by the name of the key from which it is Master Key (PMK). The PMK is only identified by the name of the
derived. key from which it is derived.
Note: IEEE 802.11i names the PMKID for the purposes of being able Note: IEEE 802.11i names the PMK for the purposes of being able to
to refer to it in the Secure Association protocol; this naming is refer to it in the Secure Association protocol; the PMK name (known
based on a hash of the PMK itself as well as some other parameters as the PMKID) is based on a hash of the PMK itself as well as some
(see Section 8.5.1.2 [IEEE-802.11i]). other parameters (see [IEEE-802.11i] Section 8.5.1.2).
TEK Name TEK Name
The TEKs may or may not be named. Their naming is specified in the The TEKs may or may not be named. Their naming is specified in the
EAP method. EAP method.
TSK Name TSK Name
The TSKs are typically named. Their naming is specified in the The Transient Session Keys (TSKs) are typically named. Their
lower layer so that the correct set of transient session keys can naming is specified in the lower layer so that the correct set of
be identified for processing a given packet. transient session keys 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) EMSK, TEKs) known only to the EAP peer (identified by the Peer-Id)
and server (identified by the Server-Id). Both the EAP peer and EAP and server (identified by the Server-Id). Both the EAP peer and EAP
server know the exported keying material to be fresh. Key freshness server know the exported keying material to be fresh. The Peer-Id
is discussed in Sections 3.4, 3.5 and 5.6. and Server-Id are discussed in Section 1.4 and Appendix A. Key
freshness is discussed in Sections 3.4, 3.5 and 5.7.
Completion of the AAA exchange (Phase 1b) results in the transport of Completion of the AAA exchange (Phase 1b) results in the transport of
EAP keying material from the EAP server (identified by the Server-Id) EAP keying material from the EAP server (identified by the Server-Id)
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 Section 5.4; security properties of AAA issues are discussed in Sections 3.8 and 5.3; security properties of
protocols are discussed in Sections 5.1-5.7, and 5.10. AAA protocols are discussed in Sections 5.1-5.9.
The backend authentication server is trusted to only transport EAP The backend authentication server is trusted to only transport EAP
keying material to the authenticator that was established with the keying material to the authenticator that was established with the
peer, and it is trusted to transport that EAP keying material to no peer, and it is trusted to transport that EAP keying material to no
other parties. In many systems, EAP keying material established by other parties. In many systems, EAP keying material established by
the EAP peer and EAP server are combined with publicly available data the EAP 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- to refrain from deriving these same keys or acting as a man-in-the-
middle even though it has access to the EAP keying material that is middle even though it has access to the EAP keying material that is
needed to do so. The authenticator is also a trusted party. It is needed to do so. The authenticator is also a trusted party. It is
trusted not to provide EAP keying material it obtains from the trusted not to provide EAP keying material it obtains from the
backend authentication server to any other parties. backend authentication server to any other parties.
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) and authenticator only to the EAP peer (identified by the Peer-Id) 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 Section 5.7 and 5.8; 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
Certain basic characteristics, known as "EAP Invariants", hold true Certain basic characteristics, known as "EAP Invariants", hold true
for EAP implementations on all media: for EAP implementations on all media:
Mode independence Mode independence
Media independence Media independence
skipping to change at page 14, line 46 skipping to change at page 15, line 5
It is a fundamental property of EAP that at the EAP method layer, the It is a fundamental property of EAP that at the EAP method layer, the
conversation between the EAP peer and server is unaffected by whether conversation between the EAP peer and server is unaffected by whether
the EAP authenticator is operating in "pass-through" mode. EAP the EAP authenticator is operating in "pass-through" mode. EAP
methods operate identically in all aspects, including key derivation methods operate identically in all aspects, including key derivation
and parameter import/export, regardless of whether the authenticator and parameter import/export, regardless of whether the authenticator
is operating as a pass-through or not. is operating as a pass-through or not.
The successful completion of an EAP method that supports key The successful completion of an EAP method that supports key
derivation results in the export of keying material and parameters on derivation results in the export of keying material and parameters on
the EAP peer and server. Even though the EAP peer or server may the EAP peer and server. Even though the EAP peer or server may
import Channel Bindings that may include the identity of the EAP import channel binding parameters that may include the identity of
authenticator, this information is treated as opaque octets. As a the EAP authenticator, this information is treated as opaque octets.
result, within EAP the only relevant identities are the Peer-Id and As a result, within EAP the only relevant identities are the Peer-Id
Server-Id. Channel Bindings are only interpreted by the lower layer. and Server-Id. Channel Binding parameters are only interpreted by
the lower layer.
Within EAP, the primary function of the AAA protocol is to maintain Within EAP, the primary function of the AAA protocol is to maintain
the principle of mode independence, so that as far as the EAP peer is the principle of mode independence, so that as far as the EAP peer is
concerned, its conversation with the EAP authenticator, and all concerned, its conversation with the EAP authenticator, and all
consequences of that conversation, are identical, regardless of the consequences of that conversation, are identical, regardless of the
authenticator mode of operation. authenticator mode of operation.
1.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
skipping to change at page 15, line 24 skipping to change at page 15, line 33
wireless networks such as 802.11 [IEEE-802.11i] and 802.16 wireless networks such as 802.11 [IEEE-802.11i] 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. MAC addresses).
Note that media independence may be retained within EAP methods that Note that media independence may be retained within EAP methods that
support Channel Bindings or method-specific identification. An EAP support Channel 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 Bindings are treated as opaque octets by EAP methods, so that Channel Binding parameters are treated as opaque octets by EAP
handling them does not require media-specific knowledge. methods, so that handling them does not require media-specific
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 implementing code methods. This allows the authenticator to avoid implementing code
for each EAP method required by peers. In fact, since a pass-through for each EAP method required by peers. In fact, since a pass-through
authenticator is not required to implement any EAP methods at all, it authenticator is not required to implement any EAP methods at all, it
cannot be assumed to support any EAP method-specific code. cannot be assumed to support any EAP method-specific code.
skipping to change at page 19, line 47 skipping to change at page 20, line 9
the EAP authenticator or peer. Any of the authenticator the EAP authenticator or peer. Any of the authenticator
architectures described in [RFC4118] can be used. 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 Bindings. Many base stations can opaque blob to be used in Channel Binding. Many base stations can
share the same authenticator identity. It should be understood that share the same authenticator identity. It should be understood that
an EAP authenticator or peer: an EAP authenticator or peer:
[a] may contain one or more physical or logical ports; (a) may contain one or more physical or logical ports;
(b) may advertise itself as one or more "virtual"
[b] may advertise itself as one or more "virtual"
authenticators or peers; authenticators or peers;
[c] may utilize multiple CPUs; (c) may utilize multiple CPUs;
[d] may support clustering services for load balancing or failover. (d) may support clustering services for load balancing or failover.
Both the EAP peer and authenticator may have more than one physical Both the EAP peer and authenticator may have more than one physical
or logical port. A peer may simultaneously access the network via or logical port. A peer may simultaneously access the network via
multiple authenticators, or via multiple physical or logical ports on multiple authenticators, or via multiple physical or logical ports on
a given authenticator. Similarly, an authenticator may offer network a given authenticator. Similarly, an authenticator may offer network
access to multiple peers, each via a separate physical or logical access to multiple peers, each via a separate physical or logical
port. When a single physical authenticator advertises itself as port. When a single physical authenticator advertises itself as
multiple "virtual authenticators", it is possible for a single multiple "virtual authenticators", it is possible for a single
physical port to belong to multiple "virtual authenticators". physical port to belong to multiple "virtual authenticators".
An authenticator may be configured to communicate with more than one An authenticator may 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.2.1. Authenticator and Peer Identification 2.2.1. Authenticator and Peer 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 purposes of Channel Bindings (see treated as an opaque blob for the purpose of Channel Binding (see
Section 5.12). 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, EAP keying material and parameters are authentication server, EAP keying material and parameters are
transported to the EAP authenticator identified by the NAS-Identifier transported to the EAP authenticator identified by the NAS-Identifier
attribute. Since an EAP authenticator MUST NOT share EAP keying attribute. Since an EAP authenticator MUST NOT share EAP keying
material or parameters with another party, if the EAP peer or backend material or 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 authenticator. For lower layers which support key caching it is
particularly important for the EAP peer, authenticator and backend
server to have a consistent view of the usage scope of the
transported EAP keying material. In order to enable this, it is
RECOMMENDED that the Secure Association Protocol explicitly
communicate the usage scope of the EAP keying material passed down to
the lower layer, rather than implicitly assuming that this is defined
by the authenticator and peer endpoint addresses.
Since an authenticator may have multiple ports, the scope of the
authenticator key cache may not be described by a single endpoint
address. Similarly, where a peer may have multiple ports and sharing
of EAP keying material and parameters between peer ports of the same
link type is allowed, the extent of the peer key cache cannot be
communicated by using a single endpoint address. Instead, it is
RECOMMENDED that the EAP peer and authenticator consistently identify
themselves utilizing explicit identifiers, rather than endpoint
addresses or port identifiers.
AAA protocols such as RADIUS [RFC3579] and Diameter [RFC4072] provide
a mechanism for the identification of AAA clients; since the EAP
authenticator and AAA client are always co-resident, this mechanism
is applicable to the identification of EAP authenticators.
+-+-+-+-+ +-+-+-+-+
| EAP | | EAP |
| Peer | | Peer |
+-+-+-+-+ +-+-+-+-+
| | | Peer Ports | | | Peer Ports
/ | \ / | \
/ | \ / | \
/ | \ / | \
/ | \ / | \
/ | \ / | \
skipping to change at page 22, line 4 skipping to change at page 21, line 38
(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
The Secure Association Protocol conversation is between the peer and
the authenticator. For lower layers which support key caching it is
particularly important for the EAP peer, authenticator and backend
server to have a consistent view of the usage scope of the
transported EAP keying material. In order to enable this, it is
RECOMMENDED that the Secure Association Protocol explicitly
communicate the usage scope of the EAP keying material passed down to
the lower layer, rather than implicitly assuming that this is defined
by the authenticator and peer endpoint addresses.
Since an authenticator may have multiple ports, the scope of the
authenticator key cache may not be described by a single endpoint
address. Similarly, where a peer may have multiple ports and sharing
of EAP keying material and parameters between peer ports of the same
link type is allowed, the extent of the peer key cache cannot be
communicated by using a single endpoint address. Instead, it is
RECOMMENDED that the EAP peer and authenticator consistently identify
themselves utilizing explicit identifiers, rather than endpoint
addresses or port identifiers.
AAA protocols such as RADIUS [RFC3579] and Diameter [RFC4072] provide
a mechanism for the identification of AAA clients; since the EAP
authenticator and AAA client are always co-resident, this mechanism
is 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 may have more than one IP address, the NAS- attributes. Since a NAS may have more than one IP address, the NAS-
Identifier attribute is RECOMMENDED for explicit identification of Identifier attribute is RECOMMENDED for explicit identification of
the authenticator, both within the AAA protocol exchange and the the authenticator, both within the AAA protocol exchange and the
Secure Association Protocol conversation. Secure Association Protocol conversation.
Problems which may arise where the peer and authenticator implicitly Problems which may 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 may not be obvious to the peer which authenticator ports are (a) It may not be obvious to the peer which authenticator ports are
associated with which authenticators. The EAP peer will be unable associated with which authenticators. The EAP peer will be unable
to determine whether EAP keying material has been shared outside to determine whether EAP keying material has been shared outside
its authorized scope, and needs to be considered compromised. The its authorized scope, and needs to be considered compromised. The
EAP peer may also be unable to utilize the authenticator key cache EAP peer may also be unable to utilize the authenticator key cache
in an efficient way. in an efficient way.
[b] It may not be obvious to the authenticator which peer ports are (b) It may not be obvious to the authenticator which peer ports are
associated with which peers. As a result, the authenticator may associated with which peers. As a result, the authenticator may
not be able to enable a peer to communicate with it utilizing not be able to enable a peer to communicate with it utilizing
multiple peer ports. multiple peer ports.
[c] It may not be obvious to the peer which "virtual authenticator" it (c) It may not be obvious to the peer which "virtual authenticator" it
is communicating with. For example, multiple "virtual is communicating with. For example, multiple "virtual
authenticators" may share a MAC address, but utilize different NAS- authenticators" may share a MAC address, but utilize different NAS-
Identifiers. Identifiers.
[d] It may not be obvious to the authenticator which "virtual peer" it (d) It may not be obvious to the authenticator which "virtual peer" it
is communicating with. Multiple "virtual peers" may share a MAC is communicating with. Multiple "virtual peers" may share a MAC
address, but utilize different Peer-Ids. address, but utilize different Peer-Ids.
[e] It may not be possible for the EAP peer and server to verify the (e) It may not be possible for the EAP peer and server to verify the
authenticator identity via channel bindings. authenticator identity via Channel Binding.
For example, problems [a], [c] and [e] occur in [IEEE-802.11i], which For example, problems (a), (c) and (e) occur in [IEEE-802.11i], 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.11i] handshake. Problems (b) and (d) do not occur since [IEEE-802.11i]
only allows a peer to utilize a single port. only allows a 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] Specifying the lower layer parameters used to identify the (f) Specifying 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 multiple
ports. ports.
[g] Communicating the lower layer identities between the peer and (g) Communicating 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] Communicating the lower layer authenticator identity between the (h) Communicating the lower layer authenticator identity between the
authenticator and backend server within the NAS-Identifier authenticator and backend server within the NAS-Identifier
attribute. attribute.
[i] Including the lower layer identities within Channel Bindings (if (i) Including the lower layer identities within Channel Bindings (if
supported) in phase 1a, ensuring that they are communicated between supported) in phase 1a, ensuring that they are communicated between
the EAP peer and server. the EAP peer and server.
[j] Supporting the integrity-protected exchange of identities within (j) Supporting the integrity-protected exchange of identities within
phase 2a. phase 2a.
[k] Utilizing the advertised lower layer identities to enable the peer (k) Utilizing 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.2.2. Virtual Authenticators 2.2.2. 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 "virtual authenticators", if the virtual authenticators do not
maintain logically separate key caches, then by authenticating to one maintain logically separate key caches, then by authenticating to one
virtual authenticator, the peer can gain access to the other virtual 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 23, line 43 skipping to change at page 24, line 5
For example, where a physical authenticator implements "Guest" and For example, where a physical authenticator implements "Guest" and
"Corporate Intranet" virtual authenticators, an attacker acting as a "Corporate Intranet" virtual authenticators, an attacker acting as a
peer could authenticate with the "Guest" "virtual authenticator" and peer could authenticate with the "Guest" "virtual authenticator" and
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.
In order to address this vulnerability: In order to address 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 consistently. This ensures that an attacker cannot authorizations consistently. This ensures that an attacker cannot
obtain elevated privileges even where the key cache is shared obtain elevated privileges even where the key cache is shared
between "virtual authenticators". between "virtual authenticators".
[b] It is RECOMMENDED that physical authenticators maintain separate (b) It is RECOMMENDED that physical authenticators maintain separate
key caches for each "virtual authenticator". key caches for each "virtual authenticator".
[c] It is RECOMMENDED that each "virtual authenticator" identify itself (c) It is RECOMMENDED that each "virtual authenticator" identify itself
consistently to the peer and to the backend authentication server, consistently to the peer and to the backend authentication server,
so as to enable the peer to verify the authenticator identity via so as to enable the peer to verify the authenticator identity via
Channel Bindings (see Section 5.11). 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 itself
distinctly, in order to enable the peer and backend server to tell distinctly, in order to enable the peer and backend server to tell
them apart. For example, this can be accomplished by utilizing a them apart. For example, this can be accomplished by utilizing a
distinct NAS-Identifier attribute. distinct NAS-Identifier attribute.
2.3. Server Identification 2.3. Server Identification
The EAP method conversation is between the EAP peer and server, as The EAP method conversation is between the EAP peer and server, as
identified by the Peer-Id and Server-Id. As shown in Figure 3, an identified by the Peer-Id and Server-Id. As shown in Figure 3, an
authenticator may be configured to communicate with multiple EAP authenticator may be configured to communicate with multiple EAP
servers; the EAP server that an authenticator communicates with may servers; the EAP server that an authenticator communicates with may
skipping to change at page 26, line 16 skipping to change at page 26, line 25
not correspond to the IP address or FQDN of a known backend not correspond to the IP address or FQDN of a known backend
authentication server, then the authenticator will not know which authentication server, then the authenticator will not know which
backend authentication server possesses the key. 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 lower
layer unicast or multicast security associations, including layer unicast or multicast security associations, including
cryptographic algorithms or traffic profiles. EAP methods only cryptographic algorithms or traffic profiles. EAP methods only
negotiate cryptographic algorithms for their own use, not for the negotiate cryptographic algorithms for their own use, not for the
underlying lower layers. EAP also does not negotiate the traffic underlying lower layers. EAP also does not negotiate the traffic
profiles to be protected with the negotiated ciphersuites; in some profiles to be protected with the negotiated ciphersuites; in some
cases the traffic to be protected may have lower layer source and cases the traffic to be protected may have lower layer source and
destination addresses different from the lower layer peer or destination addresses different from the lower layer peer or
authenticator addresses. authenticator addresses.
[b] Re-key. EAP does not support re-key of exported keys without EAP (b) Re-key. EAP does not support re-key of exported keys without EAP
re-authentication, although EAP methods may support "fast re-authentication, although EAP methods may support "fast
reconnect" as defined in [RFC3748] Section 7.2.1. 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 keys, and existing EAP methods also do not support key for exported keys, and existing EAP methods also do not support key
lifetime negotiation. lifetime negotiation.
[e] Guaranteed TSK freshness. Without a post-EAP handshake, TSKs can (e) Guaranteed TSK freshness. Without a post-EAP handshake, TSKs can
be reused if EAP keying material is cached. 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 lower
layer security associations, it is RECOMMENDED that these facilities layer security associations, it is RECOMMENDED that these facilities
be provided within the Secure Association Protocol. This includes: be provided within the Secure Association Protocol. This includes:
[a] Entity Naming. A basic feature of a Secure Association Protocol is (a) Entity Naming. A basic feature of a Secure Association Protocol is
the explicit naming of the parties engaged in the exchange. the explicit naming of the parties engaged in the exchange.
Without explicit identification, the parties engaged in the Without explicit identification, the parties engaged in the
exchange are not identified and the scope of the EAP keying exchange are not identified and the scope of the EAP keying
parameters negotiated during the EAP exchange is undefined. 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 between
the backend authentication server and authenticator (e.g. MSK), in the backend authentication server and authenticator (e.g. MSK), in
order to demonstrate that the peer and authenticator have been order to demonstrate that the peer and authenticator have been
authorized. Since mutual proof of possession is not the same as authorized. Since mutual proof of possession is not the same as
mutual authentication, the peer cannot verify authenticator mutual authentication, the peer cannot verify authenticator
assertions (including the authenticator identity) as a result of assertions (including the authenticator identity) as a result of
this exchange. Identity verification is discussed in Section this exchange. Identity verification is discussed in Section
2.2.1. 2.2.1.
[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 "best"
ciphersuite, and protect against forging of negotiated security ciphersuite, and protect against forging of negotiated security
parameters, the Secure Association Protocol MUST support secure parameters, the Secure Association Protocol MUST support secure
capabilities negotiation. This includes the secure negotiation of capabilities negotiation. This includes the secure negotiation of
usage modes, session parameters (such as security association usage modes, session parameters (such as security association
identifiers (SAIDs) and key lifetimes), ciphersuites and required identifiers (SAIDs) and key lifetimes), ciphersuites and required
filters, including confirmation of security-relevant capabilities filters, including confirmation of security-relevant capabilities
discovered during phase 0. The Secure Association Protocol MUST discovered during phase 0. The Secure Association Protocol MUST
support integrity and replay protection of all capability support integrity and replay protection of all capability
negotiation messages. negotiation messages.
[d] Key naming and selection. Where key caching is supported, it may (d) Key naming and selection. Where key caching is supported, it may
be possible for the EAP peer and authenticator to share more than be possible for the EAP peer and authenticator to share more than
one key of a given type. As a result, the Secure Association one key of a given type. As a result, the Secure Association
Protocol MUST explicitly name the keys used in the proof of Protocol MUST explicitly name the keys used in the proof of
possession exchange, so as to prevent confusion when more than one possession exchange, so as to prevent confusion when more than one
set of keying material could potentially be used as the basis for set of keying material could potentially be used as the basis for
the exchange. Use of the key naming mechanism described in Section the exchange. Use of the key naming mechanism described in Section
1.4.1 is RECOMMENDED. 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 associated
transient session keys, so that the correct set of transient transient session keys, so that the correct set of transient
session keys can be identified for processing a given packet. The session keys can be identified for processing a given packet. The
phase 2 Secure Association Protocol also MUST support transient phase 2 Secure Association Protocol also MUST support transient
session key activation and SHOULD support deletion, so that session key activation and SHOULD support deletion, so that
establishment and re-establishment of transient session keys can be establishment and re-establishment of transient session keys can be
synchronized between the parties. 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 lower
layer supports caching of exported EAP keying material, the EAP layer supports caching of exported EAP keying material, the EAP
peer lower layer may initiate a new session using keying material peer lower layer may initiate a new session using keying material
that was derived in a previous session. Were the TSKs to be that was derived in a previous session. Were the TSKs to be
derived from a portion of the exported EAP keying material, this derived from a portion of the exported EAP keying material, this
would result in reuse of the session keys which could expose the would result in reuse of the session keys which could expose the
underlying ciphersuite to attack. underlying ciphersuite to attack.
In lower layers where caching of EAP keying material is supported, In lower layers where caching of EAP keying material is supported,
the Secure Association Protocol phase is REQUIRED, and MUST support the Secure Association Protocol phase is REQUIRED, and MUST support
the derivation of fresh unicast and multicast TSKs, even when the the derivation of fresh unicast and multicast TSKs, even when the
keying material provided by the backend authentication server is keying material provided by the backend authentication server is
not fresh. This is typically supported via the exchange of nonces not fresh. This is typically supported via the exchange of nonces
or counters, which are then mixed with the exported keying material or counters, which are then mixed with the exported keying material
in order to generate fresh unicast (phase 2a) and possibly in order to generate fresh unicast (phase 2a) and possibly
multicast (phase 2b) session keys. By not using EAP keying multicast (phase 2b) session keys. By not using EAP keying
material directly to protect data, the Secure Association Protocol material directly to protect data, the Secure Association Protocol
protects it against compromise. protects it against compromise.
[f] Key lifetime management. This includes explicit key lifetime (f) Key lifetime management. This includes explicit key lifetime
negotiation or seamless re-key. EAP does not support re-key negotiation or seamless re-key. EAP does not support re-key
without re-authentication and existing EAP methods do not support without re-authentication and existing EAP methods do not support
key lifetime negotiation. As a result, the Secure Association key lifetime negotiation. As a result, the Secure Association
Protocol may handle re-key and determination of the key lifetime. Protocol may handle re-key and determination of the key lifetime.
Where key caching is supported, secure negotiation of key lifetimes Where key caching is supported, secure negotiation of key lifetimes
is RECOMMENDED. Lower layers that support re-key, but not key is RECOMMENDED. Lower layers that support re-key, but not key
caching, may not require key lifetime negotiation. For example, a caching, may not require key lifetime negotiation. For example, a
difference between IKEv1 [RFC2409] and IKEv2 [RFC4306] is that in difference between IKEv1 [RFC2409] and IKEv2 [RFC4306] is that in
IKEv1 SA lifetimes were negotiated; in IKEv2, each end of the SA is IKEv1 SA lifetimes were negotiated; in IKEv2, each end of the SA is
responsible for enforcing its own lifetime policy on the SA and re- responsible for enforcing its own lifetime policy on the SA and re-
keying the SA when necessary. keying the SA when necessary.
[g] Key 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 or
all of the key cache. Therefore, key lifetime negotiation cannot all of the key cache. Therefore, key lifetime negotiation cannot
guarantee that the key cache will remain synchronized, and the peer guarantee that the key cache will remain synchronized, and the peer
may not be able to determine before attempting to use a key whether may not be able to determine before attempting to use a key whether
it exists within the authenticator cache. It is therefore it exists within the authenticator cache. It is therefore
RECOMMENDED for the Secure Association Protocol to provide a RECOMMENDED for the Secure Association Protocol to provide a
mechanism for key state resynchronization. Since in this situation mechanism for key state resynchronization. Since in this situation
one or more of the parties initially do not possess a key with one or more of the parties initially do not possess a key with
which to protect the resynchronization exchange, securing this which to protect the resynchronization exchange, securing this
mechanism may be difficult. mechanism may be difficult.
[h] Key scope synchronization. To support key scope determination, the (h) Key scope synchronization. To support key scope determination, the
Secure Association Protocol SHOULD provide a mechanism by which the Secure Association Protocol SHOULD provide a mechanism by which the
peer can determine the scope of the key cache on each 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 may not necessarily have the same lower layer security association may not necessarily have the same
lower layer source or destination address as the EAP peer and lower layer source or destination address as the EAP peer and
authenticator, and it is possible for the peer and authenticator to authenticator, and it is possible for the peer and authenticator to
negotiate multiple security associations, each with a different negotiate multiple security associations, each with a different
traffic profile. Where this is the case, the profile of protected traffic profile. Where this is the case, the profile of protected
traffic SHOULD be explicitly negotiated. For example, in IKEv2 it traffic SHOULD be explicitly negotiated. For example, in IKEv2 it
is possible for an Initiator and Responder to utilize EAP for is possible for an Initiator and Responder to utilize EAP for
authentication, then negotiate a Tunnel Mode Security Association authentication, then negotiate a Tunnel Mode Security Association
(SA) which permits passing of traffic originating from hosts other (SA) which permits passing of traffic originating from hosts other
than the Initiator and Responder. Similarly, in IEEE 802.16e a than the Initiator and Responder. Similarly, in IEEE 802.16e a
Subscriber Station (SS) may forward traffic to the Base Station Subscriber Station (SS) may forward traffic to the Base Station
(BS) which originates from the Local Area Network (LAN) to which it (BS) which originates from the Local Area Network (LAN) to which it
is attached. To enable this, Security Associations within IEEE is attached. To enable this, Security Associations within IEEE
802.16e are identified by the Connection Identifier (CID), not by 802.16e are identified by the Connection Identifier (CID), not by
the EAP peer and authenticator MAC addresses. In both IKEv2 and the EAP peer and authenticator MAC addresses. In both IKEv2 and
IEEE 802.16e, multiple security associations may exist between the IEEE 802.16e, multiple security associations may exist between the
EAP peer and authenticator, each with their own traffic profile and EAP peer and authenticator, each with their own traffic profile and
quality of service parameters. 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 is
concerned with the establishment of security associations between concerned with the establishment of security associations between
the EAP peer and authenticator, including the derivation of the EAP peer and authenticator, including the derivation of
transient session keys, only those parties have "a need to know" transient session keys, only those parties have "a need to know"
the transient session keys. The Secure Association Protocol MUST the transient session keys. The Secure Association Protocol MUST
operate directly between the peer and authenticator, and MUST NOT operate directly between the peer and authenticator, and MUST NOT
be passed-through to the backend authentication server, or include be passed-through to the backend authentication server, or include
additional parties. additional parties.
[k] Bi-directional operation. While some ciphersuites only require a (k) Bi-directional operation. While some ciphersuites only require a
single set of transient session keys to protect traffic in both single set of transient session keys to protect traffic in both
directions, other ciphersuites require a unique set of transient directions, other ciphersuites require a unique set of transient
session keys in each direction. The phase 2 Secure Association session keys in each direction. The phase 2 Secure Association
Protocol SHOULD provide for the derivation of unicast and multicast Protocol SHOULD provide for the derivation of unicast and multicast
keys in each direction, so as not to require two separate phase 2 keys in each direction, so as not to require two separate phase 2
exchanges in order to create a bi-directional phase 2 security exchanges in order to create a bi-directional phase 2 security
association. See [RFC3748] Section 2.4 for more discussion. association. See [RFC3748] Section 2.4 for more discussion.
3.2. Key Scope 3.2. Key Scope
skipping to change at page 30, line 12 skipping to change at page 30, line 23
intrinsically bound to particular authenticator and peer ports, intrinsically bound to particular authenticator and peer ports,
Transient Session Keys MAY be bound to particular authenticator and Transient Session Keys MAY be bound to particular authenticator and
peer ports by the Secure Association Protocol. However, a lower peer ports by the Secure Association Protocol. However, a lower
layer MAY also permit TSKs to be used on multiple peer and/or layer MAY also permit TSKs to be used on multiple peer and/or
authenticator ports, providing that TSK freshness is guaranteed (such authenticator ports, providing that TSK freshness is guaranteed (such
as by keeping replay counter state within the authenticator). as by keeping replay counter state 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 usage,
such as limiting the use of EAP keying material and parameters on such as limiting the use of EAP keying material and parameters on
the EAP peer to the port over which on the EAP conversation was the EAP peer to the port over which on the EAP conversation was
conducted. conducted.
[b] The backend authentication server and authenticator MAY implement (b) The backend authentication server and authenticator MAY implement
additional attributes in order to further restrict the scope of EAP additional attributes in order to further restrict the scope of EAP
keying material. For example, in 802.11, the backend keying material. For example, in 802.11, the backend
authentication server may provide the authenticator with a list of authentication server may provide the authenticator with a list of
authorized Called or Calling-Station-Ids and/or SSIDs for which EAP authorized Called or Calling-Station-Ids and/or SSIDs for which EAP
keying material is valid. 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 be
securely communicated by the authenticator to the peer. This can securely communicated by the authenticator to the peer. This can
be accomplished using the Secure Association Protocol, but also be accomplished using the Secure Association Protocol, but also
can be accomplished via the EAP method or the lower layer. 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 keying material is When an EAP re-authentication takes place, new keying material is
derived and exported by the EAP method, which eventually results in derived and exported by the EAP method, which eventually results in
replacement of TSKs, regardless of the way they are derived (see replacement of TSKs, regardless of the way they are derived (see
skipping to change at page 40, line 10 skipping to change at page 40, line 23
server determines the user's authorization profile and transmits the server determines the user's authorization profile and transmits the
authorizations to the authenticator along with the transported EAP authorizations to the authenticator along with the transported EAP
key material. Typically, the profile is determined based on the user key material. Typically, the profile is determined based on the user
identity, but a certificate presented by the user may also provide identity, but a certificate presented by the user may also provide
authorization information. authorization information.
The backend authentication server is responsible for making a user The backend authentication server is responsible for making a user
authorization decision, which requires answering the following authorization decision, which requires answering the following
questions: questions:
[a] Is this a legitimate user of this network? (a) Is this a legitimate user of this network?
[b] Is the user allowed to access this network? (b) Is the user allowed to access this network?
[c] Is the user permitted to access this network on this day and at (c) Is the user permitted to access this network on this day and at
this time? this time?
[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 indicating (e) Are there any fraud, credit limit, or other concerns indicating
that access should be denied? that access should be denied?
[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 may add complexity. Where distributed decision making process may 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).
skipping to change at page 41, line 5 skipping to change at page 41, line 18
has no way to know what the decision was based on. Was a set of has no way to know what the decision was based on. Was a set of
authorization parameters sent because this service is always provided authorization parameters sent because this service is always provided
to the user, or was the decision based on the time of day and the to the user, or was the decision based on the time of day and the
capabilities of the authenticator? 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:
[a] Theft of service. Bypassing the AAA exchange (phase 1b) should not Theft of service
enable a user to extend their network access or gain access to Bypassing the AAA exchange (phase 1b) should not enable a user to
services they are not entitled to. extend their network access or gain access to services they are not
entitled to.
[b] Consideration of network-wide state. Handoff techniques should not Consideration of network-wide state
render the backend authentication server incapable of keeping track Handoff techniques should not render the backend authentication
of network-wide state. For example, a backend authentication server incapable of keeping track of network-wide state. For
server may need to keep track of simultaneous user sessions. example, a backend authentication server may need to keep track of
simultaneous user sessions.
[c] Elevation of privilege. Backend authentication servers often Elevation of privilege
perform conditional evaluation, in which the authorizations Backend authentication servers often perform conditional
returned in an Access-Accept message are contingent on the evaluation, in which the authorizations returned in an Access-
authenticator or on dynamic state such as the time of day. In this Accept message are contingent on the authenticator or on dynamic
situation, bypassing the AAA exchange could enable unauthorized state such as the time of day. In this situation, bypassing the
access unless the restrictions are explicitly encoded within the AAA exchange could enable unauthorized access unless the
authorizations provided by the backend authentication server. restrictions are explicitly encoded within the authorizations
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
skipping to change at page 43, line 29 skipping to change at page 43, line 46
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 may be a principal or an outsider. The attacker may 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 may compromise or steal an EAP authenticator, in an (a) An attacker may compromise or steal an EAP peer or authenticator,
attempt to gain access to other EAP authenticators or obtain long- in an attempt to gain access to other EAP peers or authenticators
term secrets. or to obtain long-term secrets.
[b] An attacker may try to modify or spoof packets, including Discovery
or Secure Association Protocol frames, EAP or AAA packets.
[c] An attacker may attempt a downgrade attack in order to exploit (b) An attacker may attempt a downgrade attack in order to exploit
known weaknesses in an authentication method or cryptographic known weaknesses in an authentication method or cryptographic
transform. algorithm.
[d] An attacker may attempt to induce an EAP peer, authenticator or (c) An attacker may try to modify or spoof packets, including Discovery
or Secure Association Protocol frames, EAP or AAA packets.
(d) An attacker may 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 may alter, forge or replay packets. (e) An attacker may alter, forge or replay packets.
[f] An attacker may cause an EAP peer, authenticator or server to reuse (f) An attacker may cause an EAP peer, authenticator or server to reuse
an stale key. Use of stale keys may also occur unintentionally. a stale key. Use of stale keys may also occur unintentionally.
For example, a poorly implemented backend authentication server may For example, a poorly implemented backend authentication server may
provide stale keying material to an authenticator, or a poorly provide stale keying material to an authenticator, or a poorly
implemented authenticator may reuse nonces. implemented authenticator may reuse nonces.
[g] An authenticated attacker may attempt to obtain elevated privilege (g) An authenticated attacker may attempt to obtain elevated privilege
in order to access information that it does not have rights to. in order to access information that it does not have rights to.
[h] An attacker may attempt a man-in-the-middle attack in order to gain (h) An attacker may attempt a man-in-the-middle attack in order to gain
access to the network. access to the network.
[i] An attacker may launch a denial of service attack against the EAP (i) An attacker may compromise an EAP authenticator in an effort to
peer, authenticator or backend authentication server.
[j] An attacker may compromise an EAP authenticator in an effort to
commit fraud. For example, a compromised authenticator may provide commit fraud. For example, a compromised authenticator may provide
incorrect information to the EAP peer and/or server via out-of-band incorrect information to the EAP peer and/or server via out-of-band
mechanisms (such as via a AAA or lower layer protocol). This mechanisms (such as via a AAA or lower layer protocol). This
includes impersonating another authenticator, or providing includes impersonating another authenticator, or providing
inconsistent information to the peer and EAP server. inconsistent information to the peer and EAP server.
In order to address these threats, [I-D.housley-aaa-key-mgmt] (j) An attacker may launch a denial of service attack against the EAP
provides a description of mandatory system security properties. peer, authenticator or backend authentication server.
Issues relating to system security requirements are discussed in the
sections that follow.
5.1. Authenticator Compromise In order to address these threats, [I-D.housley-aaa-key-mgmt] Section
3 provides a description of mandatory system security properties.
These requirements are discussed in the sections that follow.
In the event that an authenticator is compromised or stolen, an 5.1. Peer and Authenticator Compromise
attacker may gain access to the network via that authenticator, or
may obtain the credentials required for that authenticator/AAA client
to communicate with one or more backend authentication servers.
However, this should not allow the attacker to compromise other
authenticators or the backend authentication server, or obtain long-
term user credentials.
The implications of this requirement are many, but some of the more Requirement: In the event that an authenticator is compromised or
important are as follows: stolen, an attacker may gain access to the network through that
authenticator, or may obtain the credentials required for the
authenticator/AAA client to communicate with one or more backend
authentication servers. Similarly, if a peer is compromised or
stolen, an attacker may obtain credentials required to communicate
with one or more authenticators. Compromise of a single peer MUST
NOT compromise keying material held by any other peer within the
system, including session keys and long-term keys, with the possible
exception of group keys. Likewise, compromise of a single
authenticator MUST NOT compromise keying material held by any other
authenticator within the system. In the context of a key hierarchy,
this means that the compromise of one node in the key hierarchy must
not disclose the information necessary to compromise other branches
in the key hierarchy. Obviously, the compromise of the root of the
key hierarchy will compromise all of the keys; however, a compromise
in one branch MUST NOT result in the compromise of other branches.
There are many implications of this requirement; however, two
implications deserve highlighting. First, the scope of the keying
material must be defined and understood by all parties that
communicate with a party that holds that keying material. Second, a
party that holds keying material in a key hierarchy must not share
that keying material with parties that are associated with other
branches in the key hierarchy.
Some of the implications of the requirement are as follows:
No Key Sharing No Key Sharing
An EAP authenticator MUST NOT share any keying material with An EAP authenticator MUST NOT share any keying material with
another EAP authenticator, since if one EAP authenticator were another EAP authenticator, since if one EAP authenticator were
compromised, this would enable the compromise of keying material on compromised, this would enable the compromise of keying material on
another authenticator. In order to be able to determine whether another authenticator. In order to be able to determine whether
keying material has been shared, it is necessary for the identity keying material has been shared, it is necessary for the identity
of the EAP authenticator to be defined and understood by all of the EAP authenticator to be defined and understood by all
parties that communicate with it. parties that communicate with it. Similarly, an EAP peer MUST NOT
share any keying material with another EAP peer.
No AAA Credential Sharing No 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, since
if one AAA client were compromised, this would enable an attacker if one AAA client were compromised, this would enable an attacker
to impersonate other AAA clients to the backend authentication to impersonate other AAA clients to the backend authentication
server, or even to impersonate a backend authentication server to server, or even to impersonate a backend authentication server to
other AAA clients. other AAA clients.
No Compromise of Long-Term Credentials No Compromise of Long-Term Credentials
An attacker obtaining TSKs, TEKs or EAP keying material such as the An attacker obtaining TSKs, TEKs or EAP keying material such as the
MSK MUST NOT be able to obtain long-term user credentials such as MSK MUST NOT be able to obtain long-term user credentials such as
pre-shared keys, passwords or private-keys without breaking a pre-shared keys, passwords or private-keys without breaking a
fundamental cryptographic assumption. fundamental cryptographic assumption.
5.2. Spoofing 5.2. Cryptographic Negotiation
The use of per-packet authentication and integrity protection Requirement: The ability to negotiate cryptographic algorithms
provides protection against spoofing attacks. Diameter [RFC3588] resilience against compromise of a particular algorithm. This is
provides support for per-packet authentication and integrity usually accomplished by including an algorithm identifier and
protection via use of IPsec or TLS. RADIUS/EAP [RFC3579] provides parameters in the protocol, and by specifying the algorithm
for per-packet authentication and integrity protection via use of the requirements in the protocol specification. While highly desirable,
Message-Authenticator attribute. the ability to negotiate key derivation functions (KDFs) is not
required. For interoperability, at least one suite of mandatory-to-
implement algorithms MUST be selected. The selection of the "best"
cryptographic algorithm SHOULD be securely confirmed. The mechanism
SHOULD detect attempted roll back attacks.
EAP methods satisfying [RFC4017] requirements and AAA protocols
utilizing transmission layer security are capable of addressing
downgrade attacks. [RFC3748] Section 7.2.1 describes the "protected
ciphersuite negotiation" security claim that refers to the ability of
an EAP method to negotiate the ciphersuite used to protect the EAP
method conversation, as well as to integrity protect the ciphersuite
negotiation. [RFC4017] requires EAP methods satisfying this security
claim. However, EAP methods may not enable the negotiation of all
cryptographic algorithms, such as Key Distribution Functions (KDFs).
Diameter [RFC3588] provides support for cryptographic algorithm
negotiation via use of IPsec [RFC4301] or TLS [RFC4346]. RADIUS
[RFC3579] does not support the negotiation of cryptographic
algorithms, and relies on MD5 for integrity protection,
authentication and confidentiality, despite known weaknesses in the
algorithm [MD5Collision]. This issue can be addressed via use of
RADIUS over IPsec, as described in [RFC3579] Section 4.2. However,
TLS and IKEv2 currently do not enable negotiation of the Key
Distribution Function (KDF).
To ensure against downgrade attacks within lower layer protocols,
algorithm independence is REQUIRED with lower layers using EAP for
key derivation. For interoperability, at least one suite of
mandatory-to-implement algorithm MUST be selected. Lower layer
protocols supporting EAP for key derivation SHOULD also support
secure ciphersuite negotiation. As described in [RFC1968], PPP ECP
does not provide support for secure ciphersuite negotiation. While
[IEEE-802.16e] and [IEEE-802.11i] support selection of ciphersuites
for protection of data, they do not support negotiation of the
cryptographic primitives used within the Secure Association Protocol,
such as message integrity checks (MICs) and KDFs.
5.3. Confidentiality and Authentication
Requirement: Each party in the EAP, AAA and Secure Association
Protocol conversations MUST be authenticated to the other parties
with whom they communicate. Authentication mechanisms MUST maintain
the confidentiality of any secret values used in the authentication
process. When a Secure Association Protocol is used to establish
session keys, the parties involved in the secure association protocol
MUST identify themselves using identities that are meaningful in the
lower layer protocol environment that will employ the session keys.
While preserving algorithm independence, confidentiality and
integrity of all keying material MUST be maintained.
5.3.1. Spoofing
Per-packet authentication and integrity protection provides
protection against spoofing attacks.
Diameter [RFC3588] provides support for per-packet authentication and
integrity protection via use of IPsec or TLS. RADIUS/EAP [RFC3579]
provides for per-packet authentication and integrity protection via
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] requires use of EAP methods supporting this claim and [RFC4017] requires use of EAP methods supporting this
claim. claim.
In order to prevent forgery of Secure Association Protocol frames, In order to prevent forgery of Secure Association Protocol frames,
per-frame authentication and integrity protection is RECOMMENDED on per-frame authentication and integrity protection is RECOMMENDED on
all messages. [IEEE-802.11i] supports per-frame integrity protection all messages. IKEv2 [RFC4306] supports per-frame integrity
and authentication on all messages within the 4-way handshake except protection and authentication, as does [IEEE-802.16e].
the first message. An attack leveraging this ommission is described [IEEE-802.11i] supports per-frame integrity protection and
in [Analysis]. authentication on all messages within the 4-way handshake except the
first message. An attack leveraging this omission is described in
[Analysis].
5.3. Downgrade Attacks 5.3.2. Impersonation
The ability to negotiate the use of a particular cryptographic Both the RADIUS [RFC2865] and Diameter [RFC3588] protocols are
algorithm provides resilience against compromise of a particular potentially vulnerable to a rogue authenticator impersonating another
cryptographic algorithm. This is usually accomplished by including authenticator. While both protocols support mutual authentication
an algorithm identifier in the protocol, and by specifying the between the AAA client/authenticator and the backend authentication
algorithm requirements in the protocol specification. In order to server, the security mechanisms vary.
prevent downgrade attacks, secure confirmation of the "best"
ciphersuite is required.
[RFC3748] Section 7.2.1 describes the "protected ciphersuite In RADIUS, the shared secret used for authentication is determined by
negotiation" security claim that refers to the ability of an EAP the source address of the RADIUS packet. As noted in [RFC3579]
method to negotiate the ciphersuite used to protect the EAP Section 4.3.7, it is highly desirable that the source address be
conversation, as well as to integrity protect the negotiation. checked against one or more Network Access Server (NAS) client
[RFC4017] requires EAP methods satisfying this security claim. identification attributes so as to detect and prevent impersonation
attacks.
Diameter [RFC3588] provides support for cryptographic algorithm When RADIUS Access-Requests are forwarded by a proxy, the NAS-IP-
negotiation via use of IPsec or TLS. RADIUS [RFC3579] does not Address or NAS-IPv6-Address attributes may not correspond to the
support the negotiation of cryptographic algorithms, and relies on source address. Since the NAS-Identifier attribute need not contain
MD5 for integrity protection, authentication and confidentiality, an FQDN, it also may not correspond to the source address, even
despite known weaknesses in the algorithm [MD5Collision]. This issue indirectly. [RFC2865] Section 3 states:
can be addressed via use of RADIUS over IPsec, as described in
[RFC3579] Section 4.2.
As a result, EAP methods and AAA protocols are capable of addressing A RADIUS server MUST use the source IP address of the RADIUS UDP
downgrade attacks. To ensure against downgrade attacks within lower packet to decide which shared secret to use, so that RADIUS
layer protocols, algorithm independence is REQUIRED with lower layers requests can be proxied.
using EAP for key derivation. For interoperability, at least one
suite of mandatory-to-implement algorithm MUST be selected. Lower
layer protocols supporting EAP for key derivation SHOULD also support
secure ciphersuite negotiation. As described in [RFC1968], PPP ECP
does not provide support for secure ciphersuite negotiation.
However, [IEEE-802.11i] does support secure ciphersuite negotiation.
5.4. Unauthorized Disclosure This implies that it is possible for a rogue authenticator to forge
NAS-IP-Address, NAS-IPv6-Address or NAS-Identifier attributes within
a RADIUS Access-Request in order to impersonate another
authenticator. Among other things, this can result in messages (and
transported keying material) being sent to the wrong authenticator.
Since the rogue authenticator is authenticated by the RADIUS proxy or
server purely based on the source address, other mechanisms are
required to detect the forgery. In addition, it is possible for
attributes such as the Called-Station-Id and Calling-Station-Id to be
forged as well.
While preserving algorithm independence, confidentiality of all [RFC3579] Section 4.3.7 describes how an EAP pass-through
keying material MUST be maintained. To prevent unauthorized disclose authenticator acting as a AAA client can be detected if it attempts
of keys, each party in the EAP conversation MUST be authenticated to to impersonate another authenticator (such by sending incorrect
the other parties with whom it communicates. Keying material MUST be Called-Station-Id [RFC2865], NAS-Identifier [RFC2865], NAS-IP-Address
bound to the appropriate context. [RFC2865] or NAS-IPv6-Address [RFC3162] attributes via the AAA
protocol). This vulnerability can be mitigated by having RADIUS
proxies check NAS identification attributes against the source
address.
While [RFC3588] requires use of the Route-Record AVP, this utilizes
Fully Qualified Domain Names (FQDNs), so that impersonation detection
requires DNS A, AAAA and PTR Resource Records (RRs) to be properly
configured. As a result, Diameter is as vulnerable to this attack as
RADIUS, if not more so. To address this vulnerability, it is
necessary to allow the backend authentication server to communicate
with the authenticator directly, such as via the redirect
functionality supported in [RFC3588].
5.3.3. Channel Binding
It is possible for a compromised or poorly implemented EAP
authenticator to communicate incorrect information to the EAP peer
and/or server. This may enable an authenticator to impersonate
another authenticator or communicate incorrect information via out-
of-band mechanisms (such as via AAA or the lower layer).
Where EAP is used in pass-through mode, the EAP peer does not verify
the identity of the pass-through authenticator within the EAP
conversation. Within the Secure Association Protocol, the EAP peer
and authenticator only demonstrate mutual possession of the
transported EAP keying material; they do not mutually authenticate.
This creates a potential security vulnerability, described in
[RFC3748] Section 7.15.
As described in the previous section, it is possible for a AAA proxy
to detect a AAA client attempting to impersonate another
authenticator (such by sending incorrect Called-Station-Id [RFC2865],
NAS-Identifier [RFC2865], NAS-IP-Address [RFC2865] or NAS-
IPv6-Address [RFC3162] attributes via the AAA protocol). However, it
is possible for a pass-through authenticator acting as a AAA client
to provide correct information to the backend authentication server
while communicating misleading information to the EAP peer via the
lower layer.
For example, a compromised authenticator can utilize another
authenticator's Called-Station-Id or NAS-Identifier in communicating
with the EAP peer via the lower layer. Also, a pass-through
authenticator acting as a AAA client can provide an incorrect peer
Calling-Station-Id [RFC2865][RFC3580] to the backend authentication
server via the AAA protocol.
As noted in [RFC3748] Section 7.15, this vulnerability can be
addressed by EAP methods that support a protected exchange of channel
properties such as endpoint identifiers, including (but not limited
to): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id
[RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address
[RFC2865], and NAS-IPv6-Address [RFC3162].
Using such a protected exchange, it is possible to match the channel
properties provided by the authenticator via out-of-band mechanisms
against those exchanged within the EAP method. Typically the EAP
method imports Channel Binding parameters from the lower layer on the
peer, and transmits them securely to the EAP server, which exports
them to the lower layer or AAA layer. However, transport may occur
from EAP server to peer, or may be bi-directional. On the side of
the exchange (peer or server) where Channel Binding is verified, the
lower layer or AAA layer passes the result of the verification (TRUE
or FALSE) up to the EAP method. While the verification can be done
either by the peer or the server, typically only the server has the
knowledge to determine the correctness of the values, as opposed to
merely verifying their equality. For further discussion, see [I-
D.arkko-eap-service-identity-auth].
It is also possible to perform Channel Binding without transporting
data over EAP. For example, see [I-D.draft-ohba-eap-channel-
binding]. In this approach the EAP method includes Channel Binding
parameters in the calculation of exported EAP keying material, making
it impossible for the peer and authenticator to complete the Secure
Association Protocol if there is a mismatch in the Channel Binding
parameters. However, this approach can only be applied where EAP
methods generating key material are used along with lower layers that
utilize the keying material. For example, this mechanism would not
enable verification of Channel Binding on wired IEEE 802 networks
using [IEEE 802.1X].
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. Within EAP, binding of EAP keying material (MSK, peer and server.
EMSK) to the appropriate context is provided by the Peer-Id and
Server-Id which are exported along with the keying material. [RFC3748] Section 7.2.1 also describes the "Cryptographic binding"
security claim, and [RFC4017] requires support for this claim. As
described in [I-D.puthenkulam-eap-binding], EAP method sequences and
compound authentication mechanisms may be subject to man-in-the-
middle attacks. When such attacks are successfully carried out, the
attacker acts as an intermediary between a victim and a legitimate
authenticator. This allows the attacker to authenticate successfully
to the authenticator, as well as to obtain access to the network.
In order to prevent these attacks, [I-D.puthenkulam-eap-binding]
recommends derivation of a compound key by which the EAP peer and
server can prove that they have participated in the entire EAP
exchange. Since the compound key must not be known to an attacker
posing as an authenticator, and yet must be derived from quantities
that are exported by EAP methods, it may be desirable to derive the
compound key from a portion of the EMSK. In order to provide proper
key hygiene, it is recommended that the compound key used for man-in-
the-middle protection be cryptographically separate from other keys
derived from the EMSK.
Diameter [RFC3588] provides for per-packet authentication and Diameter [RFC3588] provides for per-packet authentication and
integrity protection via IPsec or TLS, and RADIUS/EAP [RFC3579] also integrity protection via IPsec or TLS, and RADIUS/EAP [RFC3579] also
provides for per-packet authentication and integrity protection. provides for per-packet authentication and integrity protection.
Where the NAS/authenticator and backend authentication server Where the authenticator/AAA client and backend authentication server
communicate directly and credible keywrap is used (see Section 3.8), communicate directly and credible keywrap is used (see Section 3.8),
this ensures that the AAA Key Transport phase achieves its security this ensures that the AAA Key Transport (phase 1b) achieves its
objectives: mutually authenticating the AAA client/authenticator and security objectives: mutually authenticating the AAA
backend authentication server and providing EAP keying material to client/authenticator and backend authentication server and providing
the EAP authenticator and to no other party. Within the AAA EAP keying material to the EAP authenticator and to no other party.
protocol, the authorization attributes provide the information
binding the transported keying material to the appropriate context.
For example, transported keying material is destined for the EAP
authenticator identified by the NAS-Identifier attribute within the
request, and relates to the EAP peer identified by the Peer-Id, User-
Name [RFC2865] or CUI [RFC4372] attributes.
[RFC2607] Section 7 describes the security issues occurring when the [RFC2607] Section 7 describes the security issues occurring when the
authenticator and backend authentication server do not communicate authenticator/AAA client and backend authentication server do not
directly. Where an untrusted 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 may be recovered by an attacker in used, transported keying material may be recovered by an attacker in
control of the untrusted intermediary. As discussed in Section 2.1, control of the intermediary. As discussed in Section 2.1, unless the
unless the TSKs are derived independently from EAP keying material TSKs are derived independently from EAP keying material (as in
(as in IKEv2), possession of transported keying material enables IKEv2), possession of transported keying material enables decryption
decryption of data traffic sent between the peer and a specific of data traffic sent between the peer and the authenticator to whom
authenticator. However, as long as EAP keying material or keys the keying material was transported. It also allows the AAA
derived from it are only utilized by a single authenticator, intermediary to impersonate the authenticator or the peer. Since the
compromise of the transported keying material does not enable an peer does not authenticate to a AAA intermediary it has no ability to
attacker to impersonate the peer to another authenticator. determine whether it is authentic or authorized to obtain keying
Vulnerability to an untrusted AAA intermediary can be mitigated by material.
implementation of redirect functionality, as described in [RFC3588]
and [RFC4072].
As noted in Section 3.1, the Secure Association Protocol does not by However, as long as EAP keying material or keys derived from it are
itself provide for mutual authentication between the EAP peer and only utilized by a single authenticator, compromise of the
authenticator, even if mutual possession of EAP keying material is transported keying material does not enable an attacker to
proven. Where the NAS/authenticator and backend authentication impersonate the peer to another authenticator. Vulnerability to
server communicate directly, the backend authentication server can compromise of a AAA intermediary can be mitigated by implementation
verify the correspondence between NAS identification attributes, the of redirect functionality, as described in [RFC3588] and [RFC4072].
source address of packets sent by the NAS, and the AAA credentials.
As long as the NAS has not shared its AAA credentials with another
NAS, this allows the backend authentication server to authenticate
the NAS. Using Channel Bindings, the EAP peer can then determine
whether the NAS/authenticator has provided the same identifying
information to the EAP peer and backend authentication server.
Peer and authenticator authorization MUST be performed. The Secure Association Protocol does not provide for mutual
Authorization is REQUIRED whenever a peer associates with a new authentication between the EAP peer and authenticator, only mutual
authenticator. Authorization checking prevents an elevation of proof of possession of transported EAP keying material. In order for
privilege attack, and ensures that an unauthorized authenticator is the peer to verify the identity of the authenticator, mutual proof
detected. Authorizations SHOULD be synchronized between the EAP of possession needs to be combined with impersonation prevention and
peer, server, authenticator. Once the EAP conversation exchanges are Channel Binding. Impersonation prevention (described in Section
complete, all of these parties should hold the same view of the 5.3.2) enables the backend authentication server to determine that
authorizations associated the other parties. If peer authorization the transported EAP keying material has been provided to the correct
is restricted, then the peer SHOULD be made aware of the restriction. authenticator. When utilized along with impersonation prevention,
Channel Binding (described in Section 5.3.3) enables the EAP peer to
verify that the EAP server has authorized the authenticator to
possess the transported EAP keying material. Completion of the
Secure Association Protocol exchange demonstrates that the EAP peer
and the authenticator possess the transported EAP keying material.
The AAA exchange provides the EAP authenticator with authorizations 5.4. Key Binding
relating to the EAP peer. However, neither the EAP nor AAA exchanges
provides authorizations to the EAP peer. In order to ensure that all
parties hold the same view of the authorizations it is RECOMMENDED
that the Secure Association Protocol enable communication of
authorizations between the EAP authenticator and peer.
Consistently identifying the EAP authenticator enables the EAP peer Requirement: Keying material MUST be bound to the appropriate
to determine whether EAP keying material has been shared between EAP context. Any party with legitimate access to keying material can
authenticators as well as to confirm with the backend authentication determine its context. In addition, the protocol MUST ensure that
server that an EAP authenticator proving possession of EAP keying all parties with legitimate access to keying material have the same
material during the Secure Association Protocol was authorized to context for the keying material. This requires that the parties are
obtain it. Identification issues are discussed in Section 2.2 and properly identified and authenticated, so that all of the parties
key scope issues are discussed in Section 3.2. that have access to the keying material can be determined. The
context includes the following:
5.5. Replay Protection o The manner in which the keying material is expected to be used.
Replay protection allows a protocol message recipient to discard any o The other parties that are expected to have access to the keying
message that was recorded during a previous legitimate dialogue and material.
presented as though it belonged to the current dialogue.
o The maximum lifetime of the keying material. The maximum
lifetime of a child key SHOULD NOT be greater than the maximum
lifetime of its parent in the key hierarchy.
Within EAP, keying material (MSK, EMSK) is bound to the Peer-Id and
Server-Id which are exported along with the keying material.
However, not all EAP methods support authenticated server identities
(see Appendix A).
Within the AAA protocol, transported keying material is destined for
the EAP authenticator identified by the NAS-Identifier attribute
within the request, and is for use by the EAP peer identified by the
Peer-Id, User-Name [RFC2865] or Chargeable User Identity (CUI)
[RFC4372] attributes. The maximum lifetime of the transported keying
material may be provided, as discussed in Section 3.5.1. Key usage
restrictions may also be included as described in Section 3.2. Key
lifetime issues are discussed in Sections 3.3, 3.4 and 3.5.
5.5. Authorization
Requirement: Peer and authenticator authorization MUST be performed.
These entities MUST demonstrate possession of the appropriate keying
material, without disclosing it. Authorization is REQUIRED whenever
a peer associates with a new authenticator. The authorization
checking prevents an elevation of privilege attack, and it ensures
that an unauthorized authenticator is detected. Authorizations
SHOULD be synchronized between the EAP peer, server, and
authenticator. Once all protocol exchanges are complete, all of
these parties should hold a common view of the authorizations
associated the other parties. The Secure Association Protocol (phase
2) conversation may utilize different identifiers from the EAP
conversation (phase 1a), so that binding between the EAP and Secure
Association Protocol identities is REQUIRED.
As described in Section 2.2.1, consistent identification of the EAP
authenticator enables the EAP peer to determine whether EAP keying
material has been shared between EAP authenticators as well as to
confirm with the backend authentication server that an EAP
authenticator proving possession of EAP keying material during the
Secure Association Protocol was authorized to obtain it.
Within the AAA protocol, the authorization attributes are bound to
the transported keying material. While the AAA exchange provides the
AAA client/authenticator with authorizations relating to the EAP
peer, neither the EAP nor AAA exchanges provides authorizations to
the EAP peer. In order to ensure that all parties hold the same view
of the authorizations it is RECOMMENDED that the Secure Association
Protocol enable communication of authorizations between the EAP
authenticator and peer.
In lower layers where the authenticator consistently identifies
itself to the peer and backend authentication server and the EAP peer
completes the Secure Association Protocol exchange with the same
authenticator through which it completed the EAP conversation,
authorization of the authenticator is demonstrated to the peer by
mutual authentication between the peer and authenticator as discussed
in the previous section. Identification issues are discussed in
Section 2.2 and key scope issues are discussed in Section 3.2.
Where the EAP peer utilizes different identifiers within the EAP
method and Secure Association Protocol conversations, peer
authorization may be difficult to demonstrate to the authenticator
without additional restrictions. This problem does not exist in
IKEv2 where the Identity Payload is used for peer identification both
within IKEv2 and EAP, and where the EAP conversation is
cryptographically protected within IKEv2 packets, binding the EAP and
Secure Association Protocol/IKEv2 exchanges. However within
[IEEE-802.11i] the EAP peer identity is 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 address for EAP authentication
as for the 4-way handshake.
5.6. Replay Protection
Requirement: Exchanges MUST be replay protected, including AAA, EAP
and Secure Association Protocol exchanges. Replay protection allows
a protocol message recipient to discard any message that was recorded
during a previous legitimate dialogue and presented as though it
belonged to the current dialogue.
[RFC3748] Section 7.2.1 describes the "replay protection" security [RFC3748] Section 7.2.1 describes the "replay protection" security
claim and [RFC4017] requires use of EAP methods supporting this claim and [RFC4017] requires use of EAP methods supporting this
claim. claim.
Diameter [RFC3588] provides support for replay protection via use of Diameter [RFC3588] provides support for replay protection via use of
IPsec or TLS. RADIUS/EAP [RFC3579] protects against replay of keying IPsec or TLS. RADIUS/EAP [RFC3579] protects against replay of keying
material via the Request Authenticator. However, some RADIUS packets material via the Request Authenticator. However, some RADIUS packets
are not replay protected. In Accounting, Disconnect and CoA-Request are not replay protected. In Accounting, Disconnect and CoA-Request
packets the Request Authenticator contains a keyed MAC rather than a packets the Request Authenticator contains a keyed MAC rather than a
Nonce. The Response Authenticator in Accounting, Disconnect and CoA Nonce. The Response Authenticator in Accounting, Disconnect and CoA
Response packets also contains a keyed MAC whose calculation does not Response packets also contains a keyed MAC whose calculation does not
depend on a Nonce in either the Request or Response packets. depend on a Nonce in either the Request or Response packets.
Therefore unless an Event-Timestamp attribute is included or IPsec is Therefore unless an Event-Timestamp attribute is included or IPsec is
used, the recipient may not be able to determine whether these used, the recipient may not be able to determine whether these
packets have been replayed. packets have been replayed.
In order to prevent replay of Secure Association Protocol frames, In order to prevent replay of Secure Association Protocol frames,
replay protection is REQUIRED on all messages. [IEEE-802.11i] replay protection is REQUIRED on all messages. [IEEE-802.11i]
supports replay protection on all messages within the 4-way supports replay protection on all messages within the 4-way
handshake. handshake; IKEv2 [RFC4306] also supports this.
5.6. Key Freshness
A session key should be considered compromised if it remains in use 5.7. Key Freshness
too long. As noted in [I-D.housley-aaa-key-mgmt]], session keys MUST
be strong and fresh, while preserving algorithm independence. A
fresh cryptographic key is one that is generated specifically for the
intended use. Each session deserves an independent session key;
disclosure of one session key MUST NOT aid the attacker in
discovering any other session keys.
Fresh keys are required even when a long replay counter (that is, one Requirement: While preserving algorithm independence, session keys
that "will never wrap") is used to ensure that loss of state does not MUST be strong and fresh. A session key SHOULD be considered
cause the same counter value to be used more than once with the same compromised if it remains in use beyond its authorized lifetime.
session key. Each session deserves an independent session key; disclosure of one
session key MUST NOT aid the attacker in discovering any other
session keys. Fresh keys are required even when a long replay
counter (that is, one that "will never wrap") is used to ensure that
loss of state does not cause the same counter value to be used more
than once with the same session key. A fresh cryptographic key is
one that is generated specifically for the intended use. In this
situation, a secure association protocol is used to establish session
keys. The AAA protocol and EAP method MUST ensure that the keying
material supplied as an input to session key derivation is fresh, and
the secure association protocol MUST generate a separate session key
for each session, even if the keying material provided by EAP is
cached.
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: the use of fresh, strong session keys. EAP methods need to ensure
the freshness and strength of EAP keying material provided as an
EAP EAP methods need to ensure the freshness and strength of EAP keying input to session key derivation. [RFC3748] Section 7.10 states that
material provided as an input to session key derivation. [RFC3748] "EAP methods SHOULD ensure the freshness of the MSK and EMSK, even in
Section 7.10 states that "EAP methods SHOULD ensure the freshness cases where one party may not have a high quality random number
of the MSK and EMSK, even in cases where one party may not have a generator. A RECOMMENDED method is for each party to provide a nonce
high quality random number generator. A RECOMMENDED method is for of at least 128 bits, used in the derivation of the MSK and EMSK."
each party to provide a nonce of at least 128 bits, used in the The contribution of nonces enables the EAP peer and server to ensure
derivation of the MSK and EMSK." The contribution of nonces that exported EAP keying material is fresh.
enables the EAP peer and server to ensure that exported EAP keying
material is fresh.
[RFC3748] Section 7.2.1 describes the "key strength" and "session [RFC3748] Section 7.2.1 describes the "key strength" and "session
independence" security claims, and and [RFC4017] requires use of independence" security claims, and [RFC4017] requires EAP methods
EAP methods supporting these claims as well as being capable of supporting these claims as well as methods capable of providing
providing an equivalent key strength of 128 bits or greater. equivalent key strength of 128 bits or greater. See Section 3.7 for
more information on key strength.
AAA The AAA protocol needs to ensure that transported keying material The AAA protocol needs to ensure that transported keying material is
is fresh and is not utilized outside its recommended lifetime. fresh and is not utilized outside its recommended lifetime. Replay
Replay protection is necessary for key freshness, but an attacker protection is necessary for key freshness, but an attacker can
can deliver a stale (and therefore potentially compromised) key in deliver a stale (and therefore potentially compromised) key in a
a replay-protected message, so replay protection is not sufficient. replay-protected message, so replay protection is not sufficient. As
As discussed in Section 3.5, the Session-Timeout attribute enables discussed in Section 3.5, the Session-Timeout attribute enables the
the backend authentication server to limit the exposure of backend authentication server to limit the exposure of transported
transported EAP keying material. EAP keying material.
The EAP Session-Id, derived as described in Section 1.4, enables The EAP Session-Id, described in Section 1.4, enables the EAP peer,
the EAP peer, authenticator and server to distinguish EAP authenticator and server to distinguish EAP conversations. However,
conversations. However, unless the authenticator keeps track of unless the authenticator keeps track of EAP Session-Ids, the
EAP Session-Ids, the authenticator cannot use the Session-Id to authenticator cannot use the Session-Id to guarantee the freshness of
guarantee the freshness of EAP keying material. EAP keying material.
Lower Layer The Secure Association Protocol, described in Section 3.1, MUST
As described in Section 3.1, the lower layer Secure Association generate a fresh session key for each session, even if the keying
Protocol MUST generate a fresh session key for each session, even material and parameters provided by EAP methods are cached, or either
if the keying material and parameters provided by EAP methods are the peer or authenticator lack a high entropy random number
cached, or either the peer or authenticator lack a high entropy generator. A RECOMMENDED method is for the peer and authenticator to
random number generator. A RECOMMENDED method is for the peer and each provide a nonce or counter used in session key derivation. If a
authenticator to each provide a nonce or counter used in session nonce is used, it is RECOMMENDED that it be at least 128 bits. While
key derivation. If a nonce is used, it is RECOMMENDED that it be [IEEE-802.11i] and IKEv2 [RFC4306] satisfy this requirement,
at least 128 bits. [IEEE-802.16e] does not, since randomness is only contributed from
the Base Station.
5.7. Elevation of Privilege 5.8. Key Scope Limitation
Parties MUST NOT have access to keying material that is not needed to Requirement: Following the principle of least privilege, parties MUST
perform their own role. A party has access to a particular key if it NOT have access to keying material that is not needed to perform
has access to all of the secret information needed to derive it. If their role. A party has access to a particular key if it has access
a Secure Association Protocol is used to establish session keys, it to all of the secret information needed to derive it. Any protocol
MUST specify the scope for session keys. that is used to establish session keys, MUST specify the scope for
session keys, clearly identifying the parties to whom the session key
is available.
Transported EAP keying material is permitted to be accessed by the Transported EAP keying material is permitted to be accessed by the
EAP peer, authenticator and server. The EAP peer and server derive EAP peer, authenticator and server. The EAP peer and server derive
the transported keying material during the process of mutually EAP keying material during the process of mutually authenticating
authenticating each other using the selected EAP method. During the each other using the selected EAP method. During the Secure
Secure Association Protocol, the EAP peer utilizes the transported Association Protocol exchange, the EAP peer utilizes derived EAP
EAP keying material to demonstrate to the authenticator that it is keying material to demonstrate to the authenticator that it is the
the same party that authenticated to the EAP server and was same party that authenticated to the EAP server and was authorized by
authorized by it. The EAP authenticator utilizes the transported EAP it. The EAP authenticator utilizes the transported EAP keying
keying material to prove to the peer not only that the EAP material to prove to the peer not only that the EAP conversation was
conversation was transported through it (this could be demonstrated transported through it (this could be demonstrated by a man-in-the-
by a man-in-the-middle), but that it was uniquely authorized by the middle), but that it was uniquely authorized by the EAP server to
EAP server to provide the peer with access to the network. Unique provide the peer with access to the network. Unique authorization
authorization can only be demonstrated if the EAP authenticator does can only be demonstrated if the EAP authenticator does not share the
not share the transported keying material with a party other than the transported keying material with a party other than the EAP peer and
EAP peer and server. server.
TSKs are permitted to be accessed only by the EAP peer and TSKs are permitted to be accessed only by the EAP peer and
authenticator (see Section 1.5). As discussed in Section 2.1, PPP authenticator (see Section 1.5); TSK derivation is discussed in
and 802.11i derive the TSKs from transported EAP keying material; Section 2.1. Since demonstration of authorization within the Secure
802.16e utilizes transported EAP keying material for TSK keywrap; Association Protocol exchange depends on possession of transported
IKEv2 utilizes transported EAP keying material only to authenticate EAP keying material, the backend authentication server can possibly
the derivation of TSKs. to obtain the TSKs unless the backend server deletes the transported
EAP keying material after sending it.
Where demonstration of authorization depends entirely on possession 5.9. Key Naming
of transported EAP keying material (such as in PPP, 802.11i and
802.16e), this enables the backend server to masquerade as the
authenticator, and possibly to obtain the TSKs unless the backend
server deletes the transported EAP keying material after sending it.
5.8. Man-in-the-middle Attacks Requirement: A robust key naming scheme is REQUIRED, 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 to all parties which key
is being referenced. Objects that cannot be named cannot be managed.
All keys MUST be uniquely named, and the key name MUST NOT directly
or indirectly disclose the keying 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 for the key value.
As described in [I-D.puthenkulam-eap-binding], EAP method sequences EAP key names (defined in Section 1.4.1), along with the Peer-Id and
and compound authentication mechanisms may be subject to man-in-the- Server-Id, uniquely identify EAP keying material, and do not directly
middle attacks. When such attacks are successfully carried out, the or indirectly expose the keying material.
attacker acts as an intermediary between a victim and a legitimate
authenticator. This allows the attacker to authenticate successfully
to the authenticator, as well as to obtain access to the network.
In order to prevent these attacks, [I-D.puthenkulam-eap-binding] Existing AAA server implementations do not distribute key names along
recommends derivation of a compound key by which the EAP peer and with the transported EAP keying material, although Diameter EAP
server can prove that they have participated in the entire EAP [RFC4072], provides the EAP-Key-Name AVP for this purpose. Since the
exchange. Since the compound key must not be known to an attacker EAP-Key-Name AVP is defined within the RADIUS attribute space, it may
posing as an authenticator, and yet must be derived from quantities be used either with RADIUS or Diameter.
that are exported by EAP methods, it may be desirable to derive the
compound key from a portion of the EMSK. In order to provide proper
key hygiene, it is recommended that the compound key used for man-in-
the-middle protection be cryptographically separate from other keys
derived from the EMSK.
5.9. Denial of Service Attacks Since the authenticator is not provided with the name of the
transported keying material by existing backend authentication server
implementations, existing Secure Association Protocols do not utilize
EAP key names. For example, [IEEE-802.11i] supports PMK caching; 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
this purpose [IEEE-802.11i] utilizes a PMK naming scheme which is
based on the key. Since IKEv2 [RFC4306] does not cache transported
EAP keying material, it does not need to refer to transported keying
material.
5.10. Denial of Service Attacks
Key caching may result in vulnerability to denial of service attacks. Key caching may result in vulnerability to denial of service attacks.
For example, EAP methods that create persistent state may be For example, EAP methods that create persistent state may be
vulnerable to denial of service attacks on the EAP server by a rogue vulnerable to denial of service attacks on the EAP server by a rogue
EAP peer. EAP peer.
To address this vulnerability, EAP methods creating persistent state To address this vulnerability, EAP methods creating persistent state
may wish to limit the persistent state created by an EAP peer. For may wish to limit the persistent state created by an EAP peer. For
example, for each peer an EAP server may choose to limit persistent example, for each peer an EAP server may choose to limit persistent
state to a few EAP conversations, distinguished by the EAP Session- state to a few EAP conversations, distinguished by the EAP Session-
skipping to change at page 51, line 31 skipping to change at page 57, line 15
Similarly, to conserve resources an authenticator may choose to limit Similarly, to conserve resources an authenticator may choose to limit
the persistent state corresponding to each peer. This can be the persistent state corresponding to each peer. This can be
accomplished by limiting each peer to persistent 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.
Depending on the media, creation of new TSKs may or may not imply Depending on the media, creation of new TSKs may or may not imply
deletion of previously derived TSKs. Where there is no implied deletion of previously derived TSKs. Where there is no implied
deletion, the authenticator may choose to limit the number of TSKs deletion, the authenticator may choose to limit the number of TSKs
and associated state that can be stored for each peer. and associated state that can be stored for each peer.
5.10. Impersonation
Both the RADIUS [RFC2865] and Diameter [RFC3588] protocols are
potentially vulnerable to impersonation by a rogue authenticator.
While both protocols support mutual authentication between the
authenticator/AAA client and the backend authentication server, the
security mechanisms vary.
In RADIUS, the shared secret used for authentication is determined by
the source address of the RADIUS packet. As noted in [RFC3579]
Section 4.3.7, it is highly desirable that the source address be
checked against one or more NAS identification attributes so as to
detect and prevent impersonation attacks.
When RADIUS Access-Requests are forwarded by a proxy, the NAS-IP-
Address or NAS-IPv6-Address attributes may not correspond to the
source address. Since the NAS-Identifier attribute need not contain
an FQDN, it also may not correspond to the source address, even
indirectly. [RFC2865] Section 3 states:
A RADIUS server MUST use the source IP address of the RADIUS
UDP packet to decide which shared secret to use, so that
RADIUS requests can be proxied.
This implies that it is possible for a rogue authenticator to forge
NAS-IP-Address, NAS-IPv6-Address or NAS-Identifier attributes within
a RADIUS Access-Request in order to impersonate another
authenticator. Among other things, this can result in messages (and
transported keying material) being sent to the wrong authenticator.
Since the rogue authenticator is authenticated by the RADIUS proxy or
server purely based on the source address, other mechanisms are
required to detect the forgery. In addition, it is possible for
attributes such as the Called-Station-Id and Calling-Station-Id to be
forged as well.
[RFC3579] Section 4.3.7 describes how an EAP pass-through
authenticator acting as a AAA client can be detected if it attempts
to impersonate another authenticator (such by sending incorrect
Called-Station-Id [RFC2865], NAS-Identifier [RFC2865], NAS-IP-Address
[RFC2865] or NAS-IPv6-Address [RFC3162] attributes via the AAA
protocol). This vulnerability can be mitigated by having RADIUS
proxies check NAS identification attributes against the source
address.
While [RFC3588] requires use of the Route-Record AVP, this utilizes
Fully Qualified Domain Names (FQDNs), so that impersonation detection
requires DNS A, AAAA and PTR Resource Records (RRs) to be properly
configured. As a result, Diameter is as vulnerable to this attack as
RADIUS, if not more so. To address this vulnerability, it is
necessary to allow the backend authentication server to communicate
with the authenticator directly, such as via the redirect
functionality supported in [RFC3588].
5.11. Channel Binding
It is possible for a compromised or poorly implemented EAP
authenticator to communicate incorrect information to the EAP peer
and/or server. This may enable an authenticator to impersonate
another authenticator or communicate incorrect information via out-
of-band mechanisms (such as via AAA or the lower layer).
Where EAP is used in pass-through mode, the EAP peer does not verify
the identity of the pass-through authenticator. Within the Secure
Association Protocol, the EAP peer and authenticator only demonstrate
mutual possession of the transported EAP keying material. This
creates a potential security vulnerability, described in [RFC3748]
Section 7.15.
As described in the previous section, it is possible for a proxy to
detect a AAA client attempting to impersonate another authenticator
(such by sending incorrect Called-Station-Id [RFC2865], NAS-
Identifier [RFC2865], NAS-IP-Address [RFC2865] or NAS-IPv6-Address
[RFC3162] attributes via the AAA protocol). However, it is possible
for a pass-through authenticator acting as a AAA client to provide
correct information to the backend authentication server while
communicating misleading information to the EAP peer via the lower
layer.
For example, a compromised authenticator can utilize another
authenticator's Called-Station-Id or NAS-Identifier in communicating
with the EAP peer via the lower layer. Also, a pass-through
authenticator acting as a AAA client can provide an incorrect peer
Calling-Station-Id [RFC2865][RFC3580] to the backend authentication
server via the AAA protocol.
As noted in [RFC3748] Section 7.15, this vulnerability can be
addressed by EAP methods that support a protected exchange of channel
properties such as endpoint identifiers, including (but not limited
to): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id
[RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address
[RFC2865], and NAS-IPv6-Address [RFC3162].
Using such a protected exchange, it is possible to match the channel
properties provided by the authenticator via out-of-band mechanisms
against those exchanged within the EAP method. Typically the EAP
method imports Channel Bindings from the lower layer on the peer, and
transmits them securely to the EAP server, which exports them to the
lower layer or AAA layer. However, transport may occur from EAP
server to peer, or may be bi-directional. On the side of the
exchange (peer or server) where Channel Bindings are verified, the
lower layer or AAA layer passes the result of the verification (TRUE
or FALSE) up to the EAP method. While the verification can be done
either by the peer or the server, typically only the server has the
knowledge to determine the correctness of the values, as opposed to
merely verifying their equality. For further discussion, see [I-
D.arkko-eap-service-identity-auth].
It is also possible to achieve Channel Bindings without transporting
data over EAP. For example, see [I-D.draft-ohba-eap-channel-
binding]. In this approach the EAP method includes Channel Bindings
in the calculation of exported EAP keying material, making it
impossible for the peer and authenticator to complete the Secure
Association Protocol if there is a mismatch in the Channel Bindings.
However, this approach can only be applied where EAP methods
generating key material are used along with lower layers that utilize
the keying material. For example, this mechanism would not enable
verification of Channel Bindings on wired IEEE 802 networks using
IEEE 802.1X.
6. IANA Considerations 6. IANA Considerations
This specification does not request the creation of any new parameter This specification does not request the creation of any new parameter
registries, nor does it require any other IANA assignments. registries, nor does it require any other IANA assignments.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 55, line 44 skipping to change at page 59, line 5
Access Systems: Amendment for Physical and Medium Access Access Systems: Amendment for Physical and Medium Access
Control Layers for Combined Fixed and Mobile Operations Control Layers for Combined Fixed and Mobile Operations
in Licensed Bands" IEEE 802.16e, August 2005. 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. Jang,
"Proactive Key Distribution to support fast and secure "Proactive Key Distribution to support fast and secure
roaming", IEEE 802.11 Working Group, IEEE-03-084r1-I, roaming", IEEE 802.11 Working Group, IEEE-03-084r1-I,
http://www.ieee802.org/11/Documents/DocumentHolder/ http://www.ieee802.org/11/Documents/DocumentHolder/
3-084.zip, January 2003. 3-084.zip, January 2003.
[I-D.housley-aaa-key-mgmt]
Housley, R. and B. Aboba, "Guidance for AAA Key
Management", draft-housley-aaa-key-mgmt-06.txt, Internet
draft (work in progress), November 2006.
[I-D.puthenkulam-eap-binding] [I-D.puthenkulam-eap-binding]
Puthenkulam, J., "The Compound Authentication Binding Puthenkulam, J., "The Compound Authentication Binding
Problem", draft-puthenkulam-eap-binding-04, Internet Problem", draft-puthenkulam-eap-binding-04, Internet
draft (work in progress), October 2003. draft (work in progress), October 2003.
[I-D.arkko-eap-service-identity-auth] [I-D.arkko-eap-service-identity-auth]
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-02.txt (EAP)", draft-arkko-eap-service-identity-auth-02.txt
Internet draft (work in progress), May 2005. Internet draft (work in progress), May 2005.
[I-D.friedman-ike-short-term-certs] [I-D.friedman-ike-short-term-certs]
Friedman, A., Sheffer, Y. and A. Shaqed, "Short Term Friedman, A., Sheffer, Y. and A. Shaqed, "Short Term
Certificates", draft-friedman-ike-short-term-certs-01, Certificates", draft-friedman-ike-short-term-certs-01,
Internet draft (work in progress), December 2006. Internet draft (work in progress), December 2006.
[I-D.housley-aaa-key-mgmt]
Housley, R. and B. Aboba, "Guidance for AAA Key
Management", draft-housley-aaa-key-mgmt-06.txt, Internet
draft (work in progress), November 2006.
[I-D.irtf-aaaarch-handoff] [I-D.irtf-aaaarch-handoff]
Arbaugh, W. and B. Aboba, "Handoff Extension to RADIUS", Arbaugh, W. and B. Aboba, "Handoff Extension to RADIUS",
draft-irtf-aaaarch-handoff-04.txt, Internet Draft (work draft-irtf-aaaarch-handoff-04.txt, Internet Draft (work
in progress), October 2003. in progress), October 2003.
[I-D.ohba-eap-channel-binding] [I-D.ohba-eap-channel-binding]
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-00.txt, Derivation", draft-ohba-eap-channel-binding-00.txt,
Internet draft (work in progress), January 2006. Internet draft (work in progress), January 2006.
skipping to change at page 57, line 9 skipping to change at page 60, line 18
[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, D.
and R. Wheeler, "A Method for Transmitting PPP Over and R. Wheeler, "A Method for Transmitting PPP Over
Ethernet (PPPoE)", RFC 2516, February 1999. Ethernet (PPPoE)", RFC 2516, February 1999.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999.
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes",
RFC 2548, March 1999. RFC 2548, March 1999.
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
Implementation in Roaming", RFC 2607, June 1999. Implementation in Roaming", RFC 2607, June 1999.
[RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for [RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
February 2000. February 2000.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, 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.
[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
(SIG(0)s )", RFC 2931, September 2000.
[RFC3007] Wellington, B., "Simple Secure Domain Name System (DNS) [RFC3007] Wellington, B., "Simple Secure Domain Name System (DNS)
Dynamic Update", RFC 3007, November 2000. Dynamic Update", RFC 3007, November 2000.
[RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC
3162, August 2001. 3162, August 2001.
[RFC3547] Baugher, M., Weis, B., Hardjono, T. and H. Harney, "The [RFC3547] Baugher, M., Weis, B., Hardjono, T. and H. Harney, "The
Group Domain of Interpretation", RFC 3547, July 2003. Group Domain of Interpretation", RFC 3547, July 2003.
[RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B.
skipping to change at page 58, line 25 skipping to change at page 61, line 28
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004. 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 4005,
August 2005 August 2005
[RFC4017] Stanley, D., Walker, J. and B. Aboba, "EAP Method [RFC4017] Stanley, D., Walker, J. and B. Aboba, "EAP Method
Requirements for Wireless LANs", RFC 4017, March 2005. Requirements for Wireless LANs", RFC 4017, March 2005.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D. and S.
Rose, "DNS Security Introduction and Requirements", RFC
4033, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D. and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
[RFC4067] Loughney, J., Nakhjiri, M., Perkins, C. and R. Koodli, [RFC4067] Loughney, J., Nakhjiri, M., Perkins, C. and R. Koodli,
"Context Transfer Protocol (CXTP)", RFC 4067, July 2005. "Context Transfer Protocol (CXTP)", RFC 4067, July 2005.
[RFC4072] Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible [RFC4072] Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application", RFC 4072, Authentication Protocol (EAP) Application", RFC 4072,
August 2005. August 2005.
[RFC4118] Yang, L., Zerfos, P. and E. Sadot, "Architecture Taxonomy [RFC4118] Yang, L., Zerfos, P. and E. Sadot, "Architecture Taxonomy
for Control and Provisioning of Wireless Access Points for Control and Provisioning of Wireless Access Points
(CAPWAP)", RFC 4118, June 2005. (CAPWAP)", RFC 4118, June 2005.
[RFC4186] Haverinen, H. and J. Salowey, "Extensible Authentication [RFC4186] Haverinen, H. and J. Salowey, "Extensible Authentication
Protocol Method for Global System for Mobile Protocol Method for Global System for Mobile
Communications (GSM) Subscriber Identity Modules (EAP- Communications (GSM) Subscriber Identity Modules (EAP-
SIM)", RFC 4186, January 2006. 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 Key
Agreement (EAP-AKA)", RFC 4187, January 2006. Agreement (EAP-AKA)", RFC 4187, January 2006.
[RFC4282] Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005. 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 Suporting Authentication in Point-to-Point Attributes Suporting Authentication in Point-to-Point
Protocol (PPP) and Wireless Local Area Neworks (WLAN)", Protocol (PPP) and Wireless Local Area Neworks (WLAN)",
RFC 4334, February 2006. RFC 4334, February 2006.
[RFC4763] Vanderveen, M. and H. Soliman, "Extensible Authentication [RFC4763] Vanderveen, M. and H. Soliman, "Extensible Authentication
Protocol Method for Shared-secret Authentication and Key Protocol Method for Shared-secret Authentication and Key
Establishment (EAP-SAKE)", RFC 4763, November 2006. 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 Attributes
for Virtual LAN and Priority Support", RFC 4675, for Virtual LAN and Priority Support", RFC 4675,
September 2006. September 2006.
[RFCPSK] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: a [RFC4764] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: a
Pre-Shared Key EAP Method", Internet draft (work in Pre-Shared Key Extensible Authentication Protocol (EAP)
progress), draft-bersani-eap-psk-11.txt, June 2006. Method", RFC 4764, January 2007.
[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 Publication
800-57, May 2006. 800-57, May 2006.
[Token] Fantacci, R., Maccari, L., Pecorella, T. and F. Frosali, [Token] Fantacci, R., Maccari, L., Pecorella, T. and F. Frosali,
"A secure and performant token-based authentication for "A secure and performant token-based authentication for
infrastructure and mesh 802.1X networks", IEEE infrastructure and mesh 802.1X networks", IEEE
Conference on Computer Communications, June 2006. Conference on Computer Communications, June 2006.
skipping to change at page 61, line 10 skipping to change at page 64, line 10
SWEDEN SWEDEN
Phone: +46 7 08 32 16 08 Phone: +46 7 08 32 16 08
EMail: henrik@levkowetz.com EMail: henrik@levkowetz.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 Key-
Lifetime for EAP methods that have been published prior to this Lifetime for EAP methods that have been published prior to this
specification. Future EAP method specifications MUST include a specification. Future EAP method specifications MUST include a
definition of the Session-Id, Peer-Id, and Server-Id (could be the definition of the Session-Id, Peer-Id and Server-Id (could be the
empty string). empty string).
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 derive
keys, and therefore does not define the Session-Id. The Peer-Id keys, and therefore does not define the Session-Id. The Peer-Id and
exported by the Identity method is determined by the octets included Server-Id are the empty string (zero length).
within the EAP- Response/Identity. The Server-Id is the empty 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 Peer-
Id and Server-Id are the empty string (zero length). Id and Server-Id are the empty string (zero length).
EAP-MD5-Challenge
The EAP-MD5-Challenge method is defined in [RFC3748]. It does not
derive keys and therefore does not define the Session-Id. The Peer-
Id and Server-Id are the empty 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 keys
and therefore does not define the Session-Id. The Peer-Id and and therefore does not define the Session-Id. The Peer-Id and
Server-Id are the empty string. Server-Id are the empty 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 keys
and therefore does not define the Session-Id. The Peer-Id and and therefore does not define the Session-Id. The Peer-Id and
Server-Id are the empty string. Server-Id are the empty 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.
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 octets
from the beginning, however. Note that the contents are used as they from the beginning, however. Note that the contents are used as they
are transmitted, regardless of whether the transmitted identity was a are transmitted, regardless of whether the transmitted identity was a
permanent, pseudonym, or fast EAP re-authentication identity. The permanent, pseudonym, or fast EAP re-authentication identity. The
Server-Id is an empty string. Server-Id is the empty 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.
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 octets
from the beginning, however. Note that the contents are used as they from the beginning, however. Note that the contents are used as they
are transmitted, regardless of whether the transmitted identity was a are transmitted, regardless of whether the transmitted identity was a
permanent, pseudonym, or fast EAP re-authentication identity. The permanent, pseudonym, or fast EAP re-authentication identity. The
Server-Id is an empty string. Server-Id is the empty string (zero length).
EAP-PSK EAP-PSK
EAP-PSK is defined in [RFCPSK]. 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) and
server (RAND_S) nonces. The Peer-Id is the contents of the ID_P server (RAND_S) nonces. The Peer-Id is the contents of the ID_P
field and the Server-Id is the contents of the ID_S field. 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 contents
of the RAND_P field in the AT_RAND_P attribute. Note that the EAP- of the RAND_P field in the AT_RAND_P attribute. Note that the EAP-
SAKE Session-Id is not the same as the "Session ID" parameter chosen 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 by the Server, which is sent in the first message, and replicated in
subsequent messages. The Peer-Id is contained within the value field subsequent messages. The Peer-Id is contained within the value field
of the AT_PEERID attibute and the Server-Id, if available, is of the AT_PEERID attibute and the Server-Id, if available, is
contained in the value field of the AT_SERVERID attribute. contained in the value field of the AT_SERVERID attribute.
Intellectual Property Statement EAP-TLS
For EAP-TLS, the Peer-Id, Server-Id and Session-Id are defined in [I-
D.simon-emu-rfc2716bis].
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 63, line 29 skipping to change at page 66, line 45
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 ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2007). This document is subject to the
rights, licenses and restrictions contained in BCP 78, and except as
set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
Open Issues Open Issues
Open issues relating to this specification are tracked on the Open issues relating to this specification are tracked on the
following web site: following web site:
 End of changes. 155 change blocks. 
599 lines changed or deleted 770 lines changed or added

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