draft-ietf-eap-keying-11.txt   draft-ietf-eap-keying-12.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-11.txt> J. Arkko <draft-ietf-eap-keying-12.txt> J. Arkko
3 April 2006 Ericsson 13 April 2006 Ericsson
P. Eronen P. Eronen
Nokia Nokia
H. Levkowetz, Ed. H. Levkowetz, Ed.
ipUnplugged ipUnplugged
Extensible Authentication Protocol (EAP) Key Management Framework Extensible Authentication Protocol (EAP) Key Management Framework
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
skipping to change at page 2, line 12 skipping to change at page 2, line 12
generated by EAP authentication algorithms, known as "methods". It generated by EAP authentication algorithms, known as "methods". It
also specifies the EAP key hierarchy. also specifies the EAP key hierarchy.
Table of Contents Table of Contents
1. Introduction .......................................... 3 1. Introduction .......................................... 3
1.1 Requirements Language ........................... 3 1.1 Requirements Language ........................... 3
1.2 Terminology ..................................... 3 1.2 Terminology ..................................... 3
1.3 Overview ........................................ 5 1.3 Overview ........................................ 5
1.4 EAP Key Hierarchy ............................... 8 1.4 EAP Key Hierarchy ............................... 8
1.5 Security Goals .................................. 11 1.5 Security Goals .................................. 12
1.6 EAP Invariants .................................. 12 1.6 EAP Invariants .................................. 12
2. Lower Layer Operation ................................. 15 2. Lower Layer Operation ................................. 16
2.1 Transient Session Keys .......................... 16 2.1 Transient Session Keys .......................... 17
2.2 Authenticator Architecture ...................... 18 2.2 Authenticator Architecture ...................... 18
3. Key Management ........................................ 22 3. Key Management ........................................ 22
3.1 Secure Association Protocol ..................... 22 3.1 Secure Association Protocol ..................... 23
3.2 Key Scope ....................................... 25 3.2 Key Scope ....................................... 25
3.3 Parent-Child Relationships ...................... 26 3.3 Parent-Child Relationships ...................... 26
3.4 Local Key Lifetimes ............................. 26 3.4 Local Key Lifetimes ............................. 26
3.5 Exported and Calculated Key Lifetimes ........... 27 3.5 Exported and Calculated Key Lifetimes ........... 27
3.6 Key Cache Synchronization ....................... 28 3.6 Key Cache Synchronization ....................... 29
3.7 Key Strength .................................... 29 3.7 Key Strength .................................... 29
3.8 Key Wrap ........................................ 29 3.8 Key Wrap ........................................ 30
4. Handoff Vulnerabilities ............................... 30 4. Handoff Vulnerabilities ............................... 30
4.1 Authorization ................................... 30 4.1 Authorization ................................... 31
4.2 Correctness ..................................... 32 4.2 Correctness ..................................... 32
5. Security Considerations .............................. 34 5. Security Considerations .............................. 35
5.1 Threat Model .................................... 35 5.1 Authenticator Compromise ........................ 36
5.2 Authenticator Compromise ........................ 36 5.2 Spoofing ........................................ 37
5.3 Spoofing ........................................ 36 5.3 Downgrade Attacks ............................... 37
5.4 Downgrade Attacks ............................... 37 5.4 Unauthorized Disclosure ......................... 38
5.5 Unauthorized Disclosure ......................... 38 5.5 Replay Protection ............................... 40
5.6 Replay Protection ............................... 39 5.6 Key Freshness ................................... 40
5.7 Key Freshness ................................... 40 5.7 Elevation of Privilege .......................... 41
5.8 Elevation of Privilege .......................... 41 5.8 Man-in-the-Middle Attacks ....................... 42
5.9 Man-in-the-Middle Attacks ....................... 42 5.9 Denial of Service Attacks ....................... 43
5.10 Denial of Service Attacks ....................... 42 5.10 Impersonation ................................... 43
5.11 Impersonation ................................... 43 5.11 Channel Binding ................................. 44
5.12 Channel Binding ................................. 44
6. IANA Considerations ................................... 45 6. IANA Considerations ................................... 45
7. References ............................................ 45 7. References ............................................ 46
7.1 Normative References ............................ 45 7.1 Normative References ............................ 46
7.2 Informative References .......................... 46 7.2 Informative References .......................... 46
Acknowledgments .............................................. 50 Acknowledgments .............................................. 50
Author's Addresses ........................................... 50 Author's Addresses ........................................... 50
Appendix A - Exported Parameters in Existing Methods ......... 52 Appendix A - Exported Parameters in Existing Methods ......... 52
Intellectual Property Statement .............................. 53 Intellectual Property Statement .............................. 53
Disclaimer of Validity ....................................... 54 Disclaimer of Validity ....................................... 54
Copyright Statement .......................................... 54 Copyright Statement .......................................... 54
1. Introduction 1. Introduction
skipping to change at page 3, line 33 skipping to change at page 3, line 33
It also specifies the EAP key hierarchy. It also specifies the EAP key hierarchy.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.2. Terminology 1.2. Terminology
This document frequently uses the following terms: The terms "Cryptographic binding", "Cryptographic separation", "Key
strength" and "Mutual authentication" are defined in [RFC3748] and
are used with the same meaning in this document, which also
frequently uses the following terms:
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.
authenticator authenticator
The end of the link initiating EAP authentication. The term The end of the link initiating EAP authentication. The term
Authenticator is used in [IEEE-802.1X], and authenticator has the Authenticator is used in [IEEE-802.1X], and authenticator has the
same meaning in this document. same meaning in this document.
skipping to change at page 4, line 18 skipping to change at page 4, line 20
compared to values communicated via out of band mechanisms (such as compared to values communicated via out of band mechanisms (such as
via a AAA or lower layer protocol). via a AAA or lower layer protocol).
EAP server EAP server
The entity that terminates the EAP authentication method with the The entity that terminates the EAP authentication method with the
peer. In the case where no backend authentication server is used, peer. In the case where no backend authentication server is used,
the EAP server is part of the authenticator. In the case where the the EAP server is part of the authenticator. In the case where the
authenticator operates in pass-through mode, the EAP server is authenticator operates in pass-through mode, the EAP server is
located on the backend authentication server. located on the backend authentication server.
Lower Layer
The lower layer is responsible for carrying EAP frames between the
peer and authenticator.
Long Term Credential Long Term Credential
EAP methods frequently make use of long term secrets in order to EAP methods frequently make use of long term secrets in order to
enable authentication between the peer and server. In the case of enable authentication between the peer and server. In the case of
a method based on pre-shared key authentication, the long term a method based on pre-shared key authentication, the long term
credential is the pre-shared key. In the case of a public-key credential is the pre-shared key. In the case of a public-key
based method, the long term credential is the corresponding private based method, the long term credential is the corresponding private
key. key.
Master Session Key (MSK) Master Session Key (MSK)
Keying material that is derived between the EAP peer and server and Keying material that is derived between the EAP peer and server and
skipping to change at page 5, line 14 skipping to change at page 5, line 22
the PMK, whereas the WEP ciphersuite as noted in [RFC3580], derives the PMK, whereas the WEP ciphersuite as noted in [RFC3580], derives
its TSKs from both halves of the MSK. In [802.16e], the MSK is its TSKs from both halves of the MSK. In [802.16e], the MSK is
truncated to 20 octets for PMK and 20 octets for PMK2. truncated to 20 octets for PMK and 20 octets for PMK2.
security association security association
A set of policies and cryptographic state used to protect A set of policies and cryptographic state used to protect
information. Elements of a security association may include information. Elements of a security association may include
cryptographic keys, negotiated ciphersuites and other parameters, cryptographic keys, negotiated ciphersuites and other parameters,
counters, sequence spaces, authorization attributes, etc. counters, sequence spaces, authorization attributes, etc.
Secure Association Protocol
An exchange that occurs between the EAP peer and authenticator in
order to manage the creation and deletion of unicast and multicast
security associations.
Transient EAP Keys (TEKs) Transient EAP Keys (TEKs)
Session keys which are used to establish a protected channel Session keys which are used to establish a protected channel
between the EAP peer and server during the EAP authentication between the EAP peer and server during the EAP authentication
exchange. The TEKs are appropriate for use with the ciphersuite exchange. The TEKs are appropriate for use with the ciphersuite
negotiated between EAP peer and server for use in protecting the negotiated between EAP peer and server for use in protecting the
EAP conversation. The TEKs are stored locally by the EAP method EAP conversation. The TEKs are stored locally by the EAP method
and are not exported. Note that the ciphersuite used to set up the and are not exported. Note that the ciphersuite used to set up the
protected channel between the EAP peer and server during EAP protected channel between the EAP peer and server during EAP
authentication is unrelated to the ciphersuite used to subsequently authentication is unrelated to the ciphersuite used to subsequently
protect data sent between the EAP peer and authenticator. protect data sent between the EAP peer and authenticator.
skipping to change at page 7, line 16 skipping to change at page 7, line 28
Figure 1. Figure 1.
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 PPP, defined in [RFC1661] does not support discovery, nor does it PPP PPP, defined in [RFC1661] does not support discovery, nor does it
include a Secure Association Protocol. include a Secure Association Protocol.
PPPOE PPPoE
PPPOE, defined in [RFC2516], includes support for a Discovery stage PPPoE, defined in [RFC2516], includes support for a Discovery stage
(phase 0). In this step, the EAP peer sends a PPPoE Active (phase 0). In this step, the EAP peer sends a PPPoE Active
Discovery Initiation (PADI) packet to the broadcast address, Discovery Initiation (PADI) packet to the broadcast address,
indicating the service it is requesting. The Access Concentrator indicating the service it is requesting. The Access Concentrator
replies with a PPPOE Active Discovery Offer (PADO) packet replies with a PPPoE Active Discovery Offer (PADO) packet
containing its name, the service name and an indication of the containing its name, the service name and an indication of the
services offered by the concentrator. The discovery phase is not services offered by the concentrator. The discovery phase is not
secured. PPPOE, like PPP, does not include a Secure Association secured. PPPoE, like PPP, does not include a Secure Association
Protocol. Protocol.
IKEv2 IKEv2
IKEv2, defined in [RFC4306], handles the establishment of unicast IKEv2, defined in [RFC4306], includes support for EAP and handles
security associations (phase 2a), while the establishment of the establishment of unicast security associations (phase 2a).
multicast security associations (phase 2b) may be handled by a However, the establishment of multicast security associations
group key management protocol such as GDOI [RFC3547], GSAKMP (phase 2b) typically does not involve EAP and needs to be handled
by a group key management protocol such as GDOI [RFC3547], GSAKMP
[GSAKMP], MIKEY [RFC3830], or GKDP [GKDP]. Several mechanisms have [GSAKMP], MIKEY [RFC3830], or GKDP [GKDP]. Several mechanisms have
been proposed for discovery of IPsec security gateways. [RFC2230] been proposed for discovery of IPsec security gateways. [RFC2230]
discusses the use of KX Resource Records (RRs) for IPsec gateway discusses the use of KX Resource Records (RRs) for IPsec gateway
discovery; while KX RRs are supported by many DNS server discovery; while KX RRs are supported by many 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 ([RFC2535], [RFC2931]), TSIG [RFC2845], and Simple
Secure Dynamic Update [RFC3007] are available. Secure Dynamic Update [RFC3007] are available.
skipping to change at page 9, line 30 skipping to change at page 9, line 42
| | | | | | | | | | | |
| | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | | | | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | |
| | | 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 |
| Key-Lifetime | & Result | | Method | | Key-Lifetime | & 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
EAP methods also MAY export method-specific peer and server EAP methods also MAY export method-specific peer and server
identifiers (peer-ID and server-ID), a method-specific EAP identifiers (Peer-Id and Server-Id), a method-specific EAP
conversation identifier known as the Session-ID, and the lifetime of conversation identifier known as the Session-Id, and the lifetime of
the exported keys, known as the Key-Lifetime. EAP methods MAY also the exported keys, known as the Key-Lifetime. EAP methods MAY also
support the import and export of Channel Bindings. New EAP method support the import and export of Channel Bindings. New EAP method
specifications MUST define the Peer-ID, Server-ID and Method-ID. The specifications MUST define the Peer-Id, Server-Id and Method-Id. The
combination of the Peer-ID and Server-ID uniquely specifies the combination of the Peer-Id and Server-Id uniquely specifies the
endpoints of the EAP method exchange when they are provided. The endpoints of the EAP method exchange when they are provided. The
Peer-ID, Server-ID, and Method-ID for existing EAP methods is defined Peer-Id, Server-Id, and Method-Id for existing EAP methods is defined
in Appendix A. in Appendix A.
Peer-ID Peer-Id
As described in [RFC3748] Section 7.3, the identity provided in the As described in [RFC3748] Section 7.3, the identity provided in the
EAP-Response/Identity, may be different from the peer identity EAP-Response/Identity, may be different from the peer identity
authenticated by the EAP method. Where the EAP method authenticates authenticated by the EAP method. Where the EAP method authenticates
the peer identity, that identity is exported by the method as the the peer identity, that identity is exported by the method as the
Peer-ID. A suitable EAP peer name may not always be available. Peer-Id. A suitable EAP peer name may not always be available.
Where an EAP method does not define a method-specific peer identity, Where an EAP method does not define a method-specific peer identity,
the Peer-ID is the null string. the Peer-Id is the null string.
Server-ID Server-Id
Where the EAP method authenticates the server identity, that identity Where the EAP method authenticates the server identity, that identity
is exported by the method as the Server-ID. A suitable EAP server is exported by the method as the Server-Id. A suitable EAP server
name may not always be available. Where an EAP method does not name may not always be available. Where an EAP method does not
define a method-specific peer identity, the Server-ID is the null define a method-specific peer identity, the Server-Id is the null
string. string.
Method-ID Method-Id
EAP method specifications deriving keys MUST specify a temporally EAP method specifications deriving keys MUST specify a temporally
unique method identifier known as the Method-ID. The EAP Method-ID unique method identifier known as the Method-Id. The EAP Method-Id
uniquely identifies an EAP session of a given Type between an EAP uniquely identifies an EAP session of a given Type between an EAP
peer and server. The Method-ID is typically constructed from nonces peer and server. The Method-Id is typically constructed from nonces
or counters used within the EAP method exchange. or counters used within the EAP method exchange.
Session-ID Session-Id
The Session-ID uniquely identifies an EAP session between an EAP peer The Session-Id uniquely identifies an EAP session between an EAP peer
(as identified by the Peer-ID) and server (as identified by the (as identified by the Peer-Id) and server (as identified by the
Server-ID). The EAP Session-ID consists of the concatenation of the Server-Id). The EAP Session-Id consists of the concatenation of the
Expanded EAP Type Code (including the Type, Vendor-ID and Vendor-Type Expanded EAP Type Code (including the Type, Vendor-Id and Vendor-Type
fields defined in [RFC3748] Section 5.7) and the Method-ID. The fields defined in [RFC3748] Section 5.7) and the Method-Id. The
inclusion of the Expanded Type Code in the EAP Session-ID ensures inclusion of the Expanded Type Code in the EAP Session-Id ensures
that each EAP method has a distinct Session-ID space. Since an EAP that each EAP method has a distinct Session-Id space. Since an EAP
session is not bound to a particular authenticator or specific ports session is not bound to a particular authenticator or specific ports
on the peer and authenticator, the authenticator port or identity are on the peer and authenticator, the authenticator port or identity are
not included in the Session-ID. not included in the Session-Id.
Key-Lifetime Key-Lifetime
While EAP itself does not support key lifetime negotiation, it is While EAP itself does not support key lifetime negotiation, it is
possible to specify methods that do. However, systems that rely on possible to specify methods that do. However, systems that rely on
such negotiation for exported keys would only function with these such negotiation for exported keys would only function with these
methods. As a result, it is NOT RECOMMENDED to use this approach as methods. As a result, it is NOT RECOMMENDED to use this approach as
the sole way to determine key lifetimes. the sole way to determine key lifetimes.
Channel Bindings Channel Bindings
Channel Bindings include lower layer parameters that are verified for Channel Bindings include lower layer parameters that are verified for
consistency between the EAP peer and server. In order to avoid consistency between the EAP peer and server. In order to avoid
skipping to change at page 11, line 4 skipping to change at page 11, line 15
possible to specify methods that do. However, systems that rely on possible to specify methods that do. However, systems that rely on
such negotiation for exported keys would only function with these such negotiation for exported keys would only function with these
methods. As a result, it is NOT RECOMMENDED to use this approach as methods. As a result, it is NOT RECOMMENDED to use this approach as
the sole way to determine key lifetimes. the sole way to determine key lifetimes.
Channel Bindings Channel Bindings
Channel Bindings include lower layer parameters that are verified for Channel Bindings include lower layer parameters that are verified for
consistency between the EAP peer and server. In order to avoid consistency between the EAP peer and server. In order to avoid
introducing media dependencies, EAP methods that transport Channel introducing media dependencies, EAP methods that transport Channel
Binding data MUST treat this data as opaque octets. Typically the Binding data MUST treat this data as opaque octets.
EAP method imports Channel Bindings from the lower layer on the peer,
and transmits them securely to the EAP server, which exports them to Typically the EAP method imports Channel Bindings from the lower
the lower layer or AAA layer. However, transport may occur from EAP layer on the peer, and transmits them securely to the EAP server,
server to peer, or may be bi-directional. On the side of the which exports them to the lower layer or AAA layer. However,
exchange (peer or server) where Channel Bindings are verified, the transport may occur from EAP server to peer, or may be bi-
lower layer or AAA layer passes the result of the verification (TRUE directional. On the side of the exchange (peer or server) where
or FALSE) up to the EAP method. While the verification can be done Channel Bindings are verified, the lower layer or AAA layer passes
either by the peer or the server, typically only the server has the the result of the verification (TRUE or FALSE) up to the EAP method.
knowledge to determine the correctness of the values, as opposed to
merely verifying their equality. 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. See Section 5.11 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 name (if securely exchanged within the method) and the the EAP peer name (if securely exchanged within the method) and the
EAP server name (also only if securely exchanged). Where a peer or EAP server name (also only if securely exchanged). Where a peer or
server name is missing the null string is used. server name is missing the null string is used.
MSK and EMSK Names MSK and EMSK Names
These parameters are exported by the EAP peer and EAP server, and These parameters are exported by the EAP peer and EAP server, and
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 parameter 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 PMK. The
PMK is only identified by the key from which it is derived. PMK is only identified by the 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 PMKID for the purposes of being able
to refer to it in the Secure Association protocol; this naming is to refer to it in the Secure Association protocol; this naming is
based on a hash of the PMK itself as well as some other parameters based on a hash of the PMK itself as well as some other parameters
(see Section 8.5.1.2 [IEEE-802.11i]). (see Section 8.5.1.2 [IEEE-802.11i]).
skipping to change at page 12, line 10 skipping to change at page 12, line 24
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. Key freshness
is discussed in Sections 3.4, 3.5 and 5.7. is discussed in Sections 3.4, 3.5 and 5.6.
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.6; security properties of AAA issues are discussed in Section 5.4; security properties of AAA
protocols are discussed in Sections 5.2-5.8, and 5.11. protocols are discussed in Sections 5.1-5.7, and 5.10.
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.8 and 5.9; roles. Authorization issues are discussed in Section 5.7 and 5.8;
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 13, line 28 skipping to change at page 13, line 41
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-Bindings that may include the identity of the EAP
authenticator, this information is treated as opaque octets. As a authenticator, this information is treated as opaque octets. As a
result, within EAP the only relevant identities are the Peer-ID and result, within EAP the only relevant identities are the Peer-Id and
Server-ID. Channel Bindings are only interpreted by the lower layer. Server-Id. Channel Bindings are only interpreted by the lower layer.
Within EAP, the primary function of the AAA protocol is to maintain Within EAP, the primary function of the AAA protocol is to maintain
the principle of Mode Independence, so that as far as the EAP peer is the principle of Mode Independence, so that as far as the EAP peer is
concerned, its conversation with the EAP authenticator, and all concerned, its conversation with the EAP authenticator, and all
consequences of that conversation, are identical, regardless of the consequences of that conversation, are identical, regardless of the
authenticator mode of operation. authenticator mode of operation.
1.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 16, line 4 skipping to change at page 16, line 19
them. For example, since ECP negotiation occurs after them. For example, since ECP negotiation occurs after
authentication, when run over PPP, the EAP peer and server may not authentication, when run over PPP, the EAP peer and server may not
anticipate the negotiated ciphersuite and therefore this anticipate the negotiated ciphersuite and therefore this
information cannot be provided to the EAP method. information cannot be provided to the EAP method.
2. Lower Layer Operation 2. Lower Layer Operation
On completion of EAP authentication, keying material and material and On completion of EAP authentication, keying material and material and
parameters exported by the EAP method are provided to the lower layer parameters exported by the EAP method are provided to the lower layer
and AAA layer (if present). These include the Master Session Key and AAA layer (if present). These include the Master Session Key
(MSK), Extended Master Session Key (EMSK), Peer-ID, Server-ID, (MSK), Extended Master Session Key (EMSK), Peer-Id, Server-Id,
Session-ID and Key-Lifetime. The Initialization Vector (IV) is Session-Id and Key-Lifetime. The Initialization Vector (IV) is
deprecated. deprecated.
In order to preserve the security of keys derived within EAP methods, In order to preserve the security of keys derived within EAP methods,
lower layers MUST NOT export keys passed down by EAP methods. This lower layers MUST NOT export keys passed down by EAP methods. This
implies that EAP keying material or parameters passed down to a lower implies that EAP keying material or parameters passed down to a lower
layer are for the exclusive use of that lower layer and MUST NOT be layer are for the exclusive use of that lower layer and MUST NOT be
used within another lower layer. This prevents compromise of one used within another lower layer. This prevents compromise of one
lower layer from compromising other applications using EAP keying lower layer from compromising other applications using EAP keying
parameters. parameters.
skipping to change at page 17, line 21 skipping to change at page 17, line 37
IEEE 802.1X-2004 IEEE 802.1X-2004
IEEE 802.1X-2004, defined in [IEEE-802.1X] does not support caching IEEE 802.1X-2004, defined in [IEEE-802.1X] does not support caching
of EAP keying material or parameters. Once EAP authentication of EAP keying material or parameters. Once EAP authentication
completes, it is assumed that EAP keying material and parameters completes, it is assumed that EAP keying material and parameters
are discarded. are discarded.
PPP PPP, defined in [RFC1661] does not support caching of EAP keying PPP PPP, defined in [RFC1661] does not support caching of EAP keying
material or parameters. PPP ciphersuites derive their TSKs material or parameters. PPP ciphersuites derive their TSKs
directly from the MSK, as described in [RFC2716]. This method is directly from the MSK, as described in [RFC2716]. This method is
NOT RECOMMENDED, since were PPP to support caching, this could NOT RECOMMENDED, since if PPP were to support caching, this could
result in stale TSKs. As a result, once the PPP session is result in TSK reuse. As a result, once the PPP session is
terminated, EAP keying material and parameters MUST be discarded. terminated, EAP keying material and parameters MUST be discarded.
Since caching of EAP keying material is not permitted, within PPP Since caching of EAP keying material is not permitted, within PPP
there is no way to handle TSK rekey without EAP re-authentication. there is no way to handle TSK rekey without EAP re-authentication.
Perfect Forward Secrecy (PFS) is only possible within PPP if the Perfect Forward Secrecy (PFS) is only possible if the negotiated
negotiated EAP method supports this. EAP method supports this.
IKEv2 IKEv2
IKEv2, defined in [RFC4306] only uses the MSK for authentication IKEv2, defined in [RFC4306] only uses the MSK for authentication
purposes and not key derivation. The EMSK, IV, Peer-ID, Server-ID purposes and not key derivation. The EMSK, IV, Peer-Id, Server-Id
or Session-ID are not used. As a result, the keying material or Session-Id are not used. As a result, the keying material
derived within IKEv2 is independent of the EAP keying material and derived within IKEv2 is independent of the EAP keying material and
rekey of IPsec SAs can be handled without requiring EAP re- rekey of IPsec SAs can be handled without requiring EAP re-
authentication. Since generation of keying material is independent authentication. Since generation of keying material is independent
of EAP, within IKEv2 it is possible to negotiate PFS, regardless of of EAP, within IKEv2 it is possible to negotiate PFS, regardless of
the EAP method that is used. IKEv2 does not cache EAP keying the EAP method that is used. IKEv2 does not cache EAP keying
material or parameters; once IKEv2 authentication completes it is material or parameters; once IKEv2 authentication completes it is
assumed that EAP keying material and parameters are discarded. The assumed that EAP keying material and parameters are discarded. The
Session-Timeout attribute is therefore interpreted as a limit on Session-Timeout attribute is therefore interpreted as a limit on
the VPN session time, rather than an indication of the MSK key the VPN session time, rather than an indication of the MSK key
lifetime. lifetime.
IEEE 802.11i IEEE 802.11i
IEEE 802.11i enables caching of the MSK, but not the EMSK, IV, IEEE 802.11i enables caching of the MSK, but not the EMSK, IV,
Peer-ID, Server-ID, or Session-ID. More details about the Peer-Id, Server-Id, or Session-Id. More details about the
structure of the cache are available in [IEEE-802.11i]. In IEEE structure of the cache are available in [IEEE-802.11i]. In IEEE
802.11i, TSKs are derived from the MSK using the 4-way handshake, 802.11i, TSKs are derived from the MSK using the 4-way handshake,
which includes a nonce exchange. This guarantees TSK freshness which includes a nonce exchange. This guarantees TSK freshness
even if the MSK is reused. The 4-way handshake also enables TSK even if the MSK is reused. The 4-way handshake also enables TSK
rekey without EAP re-authentication. PFS is only possible within rekey without EAP re-authentication. PFS is only possible within
IEEE 802.11i if the negotiated EAP method supports this. IEEE 802.11i if caching is not enabled and the negotiated EAP
method supports PFS.
IEEE 802.16e IEEE 802.16e
IEEE 802.16e, defined in [IEEE-802.16e] supports caching of the IEEE 802.16e, defined in [IEEE-802.16e] supports caching of the
MSK, but not the EMSK, IV, Peer-ID, Server-ID or Session-ID. In MSK, but not the EMSK, IV, Peer-Id, Server-Id or Session-Id. In
IEEE 802.16e, TSKs are generated by the authenticator without any IEEE 802.16e, TSKs are generated by the authenticator without any
contribution by the peer. The TSKs are encrypted, authenticated contribution by the peer. The TSKs are encrypted, authenticated
and integrity protected using the MSK. As a result, TSK rekey is and integrity protected using the MSK. As a result, TSK rekey is
possible without EAP re-authentication. PFS is not possible even possible without EAP re-authentication. PFS is not possible even
if the negotiated EAP method supports it. if the negotiated EAP method supports it.
AAA Existing implementations of RADIUS/EAP [RFC3579] or Diameter EAP AAA Existing implementations of RADIUS/EAP [RFC3579] or Diameter EAP
[RFC4072] do not support caching of EAP keying material or [RFC4072] do not support caching of EAP keying material or
parameters. In existing AAA client, proxy and server parameters. In existing AAA client, proxy and server
implementations, exported EAP keying material (MSK, EMSK and IV) as implementations, exported EAP keying material (MSK, EMSK and IV) as
skipping to change at page 18, line 32 skipping to change at page 18, line 48
In order to avoid key reuse, the AAA layer MUST delete transported In order to avoid key reuse, the AAA layer MUST delete transported
keys once they are sent. The AAA layer MUST NOT retain keys that keys once they are sent. The AAA layer MUST NOT retain keys that
it has previously sent. For example, a AAA layer that has it has previously sent. For example, a AAA layer that has
transported the MSK MUST delete it, and keys MUST NOT be derived transported the MSK MUST delete it, and keys MUST NOT be derived
from the MSK from that point forward. from the MSK from that point forward.
2.2. Authenticator Architecture 2.2. Authenticator Architecture
This specification does not impose constraints on the architecture of This specification does not impose constraints on the architecture of
the EAP authenticator or peer. Any of the authenticator the EAP authenticator or peer. Any of the authenticator
architectures described in [RFC4118] can be used. For example, it is architectures described in [RFC4118] can be used. As a result, lower
possible for multiple base stations and a "controller" (e.g. WLAN layers need to identify EAP peers and authenticators unambiguously,
switch) to comprise a single EAP authenticator. In such a situation, without incorporating implicit assumptions about peer and
the "base station identity" is irrelevant to the EAP method authenticator architectures.
conversation, except perhaps as an opaque blob to be used in Channel
Bindings. Many base stations can share the same authenticator
identity. As a result, lower layers need to identify EAP peers and
authenticators unambiguously, without incorporating implicit
assumptions about peer and authenticator architectures.
It should be understood that an EAP authenticator or peer: For example, it is possible for multiple base stations and a
"controller" (e.g. WLAN switch) to comprise a single EAP
authenticator. In such a situation, the "base station identity" is
irrelevant to the EAP method conversation, except perhaps as an
opaque blob to be used in Channel Bindings. Many base stations can
share the same authenticator identity. It should be understood that
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". The physical port to belong to multiple "virtual authenticators". The
situation is illustrated in Figure 3. situation is illustrated in Figure 3.
2.2.1. Authenticator Identification
The EAP method conversation is between the EAP peer and server, as
identified by the Peer-Id and Server-Id. The authenticator identity,
if considered at all by the EAP method, is treated as an opaque blob
for the purposes of Channel Bindings (see Section 5.12). However,
the Secure Association Protocol conversation is between the peer and
the authenticator, and therefore the authenticator and peer
identities are relevant to that exchange, and define the scope of use
of the EAP keying material passed down to the lower layer.
Where the EAP peer and authenticator cannot unambiguously identify
each other they may not be able to determine the scope of transported
EAP keying material. This is particularly problematic for lower
layers where key caching is supported.
For example, if the EAP peer cannot identify the EAP authenticator,
it will be unable to determine whether transported EAP keying
material has been shared outside of its authorized scope, and
therefore needs to be considered compromised. There is also a
practical problem because the EAP peer will be unable to utilize the
EAP authenticator key cache in an efficient way.
Where the peer and authenticator identify themselves within the lower
layer using a port identifier such as a link layer address, this
creates a number of problems:
[1] It may not be obvious to the peer which authenticator ports are
associated with which authenticators.
[2] It may not be obvious to the authenticator which peer ports are
associated with which peers.
[3] It may not be obvious to the peer which "virtual authenticator" it
is communicating with.
[4] It may not be obvious to the authenticator which "virtual peer" it
is communicating with.
+-+-+-+-+ +-+-+-+-+
| EAP | | EAP |
| Peer | | Peer |
+-+-+-+-+ +-+-+-+-+
| | | Peer Ports | | | Peer Ports
/ | \ / | \
/ | \ / | \
/ | \ / | \
/ | \ / | \
/ | \ / | \
skipping to change at page 19, line 45 skipping to change at page 21, line 4
(optional) \ | / (optional) \ | /
\ | / \ | /
\ | / \ | /
\ | / \ | /
+-+-+-+-+ +-+-+-+-+
| EAP | | EAP |
|Server | |Server |
+-+-+-+-+ +-+-+-+-+
Figure 3: Relationship between EAP peer, authenticator and server Figure 3: Relationship between EAP peer, authenticator and server
2.2.1. Authenticator Identification
The EAP method conversation is between the EAP peer and server, as
identified by the Peer-ID and Server-ID. The authenticator identity,
if considered at all by the EAP method, is treated as an opaque blob
for the purposes of Channel bindings. However, the Secure
Association Protocol conversation is between the peer and the
authenticator, and therefore the authenticator and peer identities
are relevant to that exchange, and define the scope of use of the EAP
keying material passed down to the lower layer.
Where the EAP peer and authenticator cannot unambiguously identify
each other they may not be able to determine the scope of transported
EAP keying material. This is particularly problematic for lower
layers where key caching is supported.
For example, if the EAP peer cannot identify the EAP authenticator,
it will be unable to determine whether transported EAP keying
material has been shared outside of its authorized scope, and
therefore needs to be considered compromised. There is also a
practical problem because the EAP peer will be unable to utilize the
EAP authenticator key cache in an efficient way. Where the peer and
authenticator identify themselves within the lower layer using a port
identifier such as a link layer address, this creates a number of
problems:
[1] It may not be obvious to the peer which authenticator ports are
associated with which authenticators.
[2] It may not be obvious to the authenticator which peer ports are
associated with which peers.
[3] It may not be obvious to the peer which "virtual authenticator" it
is communicating with.
[4] It may not be obvious to the authenticator which "virtual peer" it
is communicating with.
Since an authenticator may have multiple ports, the authenticator Since an authenticator may have multiple ports, the authenticator
identifier used within the Secure Association Protocol exchange identifier used within the Secure Association Protocol exchange
SHOULD be distinct from any port identifier (e.g. MAC address). SHOULD be distinct from any port identifier (e.g. MAC address).
Similarly, where a peer may have multiple ports, and sharing of EAP Similarly, where a peer may have multiple ports, and sharing of EAP
keying material and parameters between peer ports of the same link keying material and parameters between peer ports of the same link
type is allowed, the peer identifier used within the Secure type is allowed, the peer identifier used within the Secure
Association Protocol exchange SHOULD also be distinct from any port Association Protocol exchange SHOULD also be distinct from any port
identifier. identifier.
AAA protocols such as RADIUS [RFC3579] and Diameter [RFC4072] AAA protocols such as RADIUS [RFC3579] and Diameter [RFC4072] provide
provide a mechanism for the identification of AAA clients; since a mechanism for the identification of AAA clients; since the EAP
the EAP authenticator and AAA client are always co-resident, this authenticator and AAA client are always co-resident, this mechanism
mechanism is applicable to the identification of EAP is applicable to the identification of EAP authenticators.
authenticators.
RADIUS [RFC2865] requires that an Access-Request packet contain one RADIUS [RFC2865] requires that an Access-Request packet contain one
or more of the NAS-Identifier, NAS-IP-Address and NAS-IPv6-Address or more of the NAS-Identifier, NAS-IP-Address and NAS-IPv6-Address
attributes. Since a NAS may have more than one IP address, the attributes. Since a NAS may have more than one IP address, the NAS-
NAS-Identifier attribute is RECOMMENDED for the unambiguous Identifier attribute is RECOMMENDED for the unambiguous
identification of the EAP authenticator. identification of the EAP authenticator.
From the point of view of the AAA server, EAP keying material and From the point of view of the backend authentication server, EAP
parameters are transported to the EAP authenticator identified by keying material and parameters are transported to the EAP
the NAS-Identifier attribute. Since an EAP authenticator MUST NOT authenticator identified by the NAS-Identifier attribute. Since an
share EAP keying material or parameters with another party, if the EAP authenticator MUST NOT share EAP keying material or parameters
EAP peer or AAA server detects use of EAP keying material and with another party, if the EAP peer or backend authentication server
parameters outside the scope defined by the NAS-Identifier, the detects use of EAP keying material and parameters outside the scope
keying material MUST be considered compromised. defined by the NAS-Identifier, the keying material MUST be considered
compromised.
In order to ensure that lower layer identifies are securely In order to ensure that lower layer identities are securely verified
verified by all parties, it is recommended that lower layers: by all parties, it is RECOMMENDED that the parties use a set of
identities that are consistent between the conversation phases. This
can be achieved by:
[a] Specify the lower layer parameters used to identify the [a] Specifying the lower layer parameters used to identify the
authenticator and peer; authenticator and peer;
[b] Communicate the lower layer identities between the peer and [b] Communicating the lower layer identities between the peer and
authenticator within phase 0; authenticator within phase 0;
[c] Communicate the lower layer authenticator identity between the [c] 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;
[d] Include the lower layer identities within channel bindings (if [d] 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;
[e] Securely verify the lower layer identities within phase 2a; [e] Supporting the integrity-protected exchange of identities within
phase 2a;
[f] Utilize the advertised lower layer identities to enable the peer [f] 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", the EAP peer and authenticator may not be "virtual authenticators", a number of security vulnerabilities may
able to agree on the scope of the EAP keying material, creating a arise if the peer and authenticator are not correctly identified.
security vulnerability. For example, the peer may assume that the For example, the peer may assume that the "virtual authenticators"
"virtual authenticators" are distinct and do not share a key cache, are distinct and do not share a key cache, whereas, depending on the
whereas, depending on the architecture of the physical authenticator, architecture of the physical authenticator, a shared key cache may or
a shared key cache may or may not be implemented. may not be implemented.
Where EAP keying material is shared between "virtual authenticators" Where EAP keying material is shared between "virtual authenticators"
an attacker acting as a peer could authenticate with the "Guest" an attacker acting as a peer could authenticate with the "Guest"
"virtual authenticator" and derive EAP keying material. If the "virtual authenticator" and derive EAP keying material. If the
virtual authenticators share a key cache, then the peer can utilize virtual authenticators share a key cache, then the peer can utilize
the EAP keying material derived for the "Guest" network to obtain the EAP keying material derived for the "Guest" network to obtain
access to the "Corporate Intranet" virtual authenticator. access to the "Corporate Intranet" virtual authenticator.
Several measures are recommended to address these issues: In order to address these issues:
[g] Authenticators are REQUIRED to cache associated authorizations [g] Authenticators are REQUIRED to cache associated authorizations
along with EAP keying material and parameters and to apply along with EAP keying material and parameters and to apply
authorizations consistently. This ensures that an attacker cannot authorizations consistently. This ensures that an attacker cannot
obtain elevated privileges even where the key cache is shared obtain elevated privileges even where the key cache is shared
between "virtual authenticators". between "virtual authenticators".
[h] It is RECOMMENDED that physical authenticators maintain separate [h] It is RECOMMENDED that physical authenticators maintain separate
key caches for each "virtual authenticator". key caches for each "virtual authenticator".
[i] It is RECOMMENDED that each "virtual authenticator" identify itself [i] It is RECOMMENDED that each "virtual authenticator" identify itself
distinctly to the backend authentication server, such as by distinctly to the backend authentication server, such as by
utilizing a distinct NAS-Identifier attribute. This enables the utilizing a distinct NAS-Identifier attribute. This enables the
backend authentication server to utilize a separate credential to backend authentication server to utilize a separate credential to
authenticate each "virtual authenticator". authenticate each "virtual authenticator".
3. Key Management 3. Key Management
EAP as defined in [RFC3748] supports key derivation, but not key EAP as defined in [RFC3748] supports key derivation, but does not
management. While EAP methods may derive keying material, EAP does provide for the management of exported or derived keys. Although EAP
not provide for the management of exported or derived keys. Although methods may support "fast reconnect" as defined in [RFC3748] Section
EAP methods may support "fast reconnect" as defined in [RFC3748] 7.2.1, EAP does not support re-key of exported keys without re-
Section 7.2.1, EAP does not support re-key of exported keys without authentication. Existing EAP methods do not export the Key-Lifetime
re-authentication. Existing EAP methods do not export the Key- parameter; in the interest of method independence, key management of
Lifetime parameter; in the interest of method independence, key exported or derived keys SHOULD NOT be provided within EAP methods.
management of exported or derived keys SHOULD NOT be provided within
EAP methods.
3.1. Secure Association Protocol 3.1. Secure Association Protocol
Since neither EAP nor EAP methods provide key management support, it Since neither EAP nor EAP methods provide key management support, it
is RECOMMENDED that key management facilities be provided within the is RECOMMENDED that key management facilities be provided within the
Secure Association Protocol. This includes: Secure Association Protocol. This includes:
[a] Entity Naming. A basic feature of a Secure Association Protocol is [a] Entity Naming. A basic feature of a Secure Association Protocol is
the explicit naming of the parties engaged in the exchange. the explicit naming of the parties engaged in the exchange.
Without explicit identification, the parties engaged in the Without explicit identification, the parties engaged in the
exchange are not identified and the scope of the EAP keying exchange are not identified and the scope of the EAP keying
parameters negotiated during the EAP exchange is undefined. As parameters negotiated during the EAP exchange is undefined.
shown in Figure 3, both the peer and authenticator may have more
than one physical or virtual port, and as a result SHOULD identify
themselves in a manner that is independent of their attached ports.
[b] Mutual proof of possession of EAP keying material. During the [b] Mutual proof of possession of EAP keying material. During the
Secure Association Protocol the EAP peer and authenticator MUST Secure Association Protocol the EAP peer and authenticator MUST
demonstrate possession of the keying material transported between demonstrate possession of the keying material transported between
the backend authentication server and authenticator (e.g. MSK), in the backend authentication server and authenticator (e.g. MSK), in
order to demonstrate that the peer and authenticator have been order to demonstrate that the peer and authenticator have been
authorized. Since mutual proof of possession is not the same as authorized. Since mutual proof of possession is not the same as
mutual authentication, the peer cannot verify authenticator mutual authentication, the peer cannot verify authenticator
assertions (including the authenticator identity) as a result of assertions (including the authenticator identity) as a result of
this exchange. this exchange. Identity verification is discussed in Section
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. As part of secure capabilities discovered during phase 0. The Secure Association Protocol MUST
negotiation, the Secure Association Protocol MUST support integrity support integrity and replay protection of all capability
and replay protection of all 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 this the exchange. Use of the key naming mechanism described in Section
document 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.
skipping to change at page 24, line 29 skipping to change at page 24, line 45
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 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.
skipping to change at page 25, line 15 skipping to change at page 25, line 32
be passed-through to the backend authentication server, or include be passed-through to the backend authentication server, or include
additional parties. additional parties.
[j] Bi-directional operation. While some ciphersuites only require a [j] Bi-directional operation. While some ciphersuites only require a
single set of transient session keys to protect traffic in both single set of transient session keys to protect traffic in both
directions, other ciphersuites require a unique set of transient directions, other ciphersuites require a unique set of transient
session keys in each direction. The phase 2 Secure Association session keys in each direction. The phase 2 Secure Association
Protocol SHOULD provide for the derivation of unicast and multicast Protocol SHOULD provide for the derivation of unicast and multicast
keys in each direction, so as not to require two separate phase 2 keys in each direction, so as not to require two separate phase 2
exchanges in order to create a bi-directional phase 2 security exchanges in order to create a bi-directional phase 2 security
association. association. See [RFC3748] Section 2.4 for more discussion.
3.2. Key Scope 3.2. Key Scope
Absent explicit specification within the lower layer, after the Absent explicit specification within the lower layer, after the
completion of phase 1b, EAP keying material and parameters are bound completion of phase 1b, EAP keying material and parameters are bound
to the EAP peer and authenticator, but are not bound to a specific to the EAP peer and authenticator, but are not bound to a specific
peer or authenticator port. peer or authenticator port.
While EAP Keying Material passed down to the lower layer is not While EAP Keying Material passed down to the lower layer is not
intrinsically bound to particular authenticator and peer ports, intrinsically bound to particular authenticator and peer ports,
skipping to change at page 26, line 34 skipping to change at page 26, line 52
of the keying material by both parties; rate-limiting Secure of the keying material by both parties; rate-limiting Secure
Association Protocol exchanges could be used to prevent a brute force Association Protocol exchanges could be used to prevent a brute force
attack. attack.
3.4. Local Key Lifetimes 3.4. Local Key Lifetimes
The Transient EAP Keys (TEKs) are session keys used to protect the The Transient EAP Keys (TEKs) are session keys used to protect the
EAP conversation. The TEKs are internal to the EAP method and are EAP conversation. The TEKs are internal to the EAP method and are
not exported. TEKs are typically created during an EAP conversation, not exported. TEKs are typically created during an EAP conversation,
used until the end of the conversation and then discarded. However, used until the end of the conversation and then discarded. However,
methods may re-key TEKs during a conversation. methods may re-key TEKs during an EAP conversation.
When using TEKs within an EAP conversation or across conversations, When using TEKs within an EAP conversation or across conversations,
it is necessary to ensure that replay protection and key separation it is necessary to ensure that replay protection and key separation
requirements are fulfilled. For instance, if a replay counter is requirements are fulfilled. For instance, if a replay counter is
used, TEK re-key MUST occur prior to wrapping of the counter. used, TEK re-key MUST occur prior to wrapping of the counter.
Similarly, TSKs MUST remain cryptographically separate from TEKs Similarly, TSKs MUST remain cryptographically separate from TEKs
despite TEK re-keying or caching. This prevents TEK compromise from despite TEK re-keying or caching. This prevents TEK compromise from
leading directly to compromise of the TSKs and vice versa. leading directly to compromise of the TSKs and vice versa.
EAP methods may cache local keying material which may persist for EAP methods may cache local keying material which may persist for
skipping to change at page 27, line 19 skipping to change at page 27, line 37
All EAP methods generating keys are required to generate the MSK and All EAP methods generating keys are required to generate the MSK and
EMSK, and may optionally generate the IV. However, EAP, defined in EMSK, and may optionally generate the IV. However, EAP, defined in
[RFC3748], does not itself support the negotiation of lifetimes for [RFC3748], does not itself support the negotiation of lifetimes for
exported keying material such as the MSK, EMSK and IV. exported keying material such as the MSK, EMSK and IV.
Several mechanisms exist for managing key lifetimes: Several mechanisms exist for managing key lifetimes:
[a] AAA attributes. AAA protocols such as RADIUS [RFC2865] and [a] AAA attributes. AAA protocols such as RADIUS [RFC2865] and
Diameter [RFC4072] support the Session-Timeout attribute. The Diameter [RFC4072] support the Session-Timeout attribute. The
Session-Timeout value represents the maximum lifetime of the Session-Timeout attribute represents the maximum lifetime of the
exported keys, and all keys calculated from it, on the exported keys, and all keys calculated from it, on the
authenticator. Since existing backend authentication servers do authenticator. Since existing backend authentication servers do
not cache keys exported by EAP methods, or keys calculated from not cache keys exported by EAP methods, or keys calculated from
exported keys, the value of the Session-Timeout attribute has no exported keys, the value of the Session-Timeout attribute has no
bearing on the key lifetime within the backend authentication bearing on the key lifetime within the backend authentication
server. server.
On the authenticator, where EAP is used for authentication, the On the authenticator, where EAP is used for authentication, the
Session-Timeout value represents the maximum session time prior to Session-Timeout attribute represents the maximum session time prior
re-authentication, as described in [RFC3580]. Where EAP is used to re-authentication. As described in [RFC3580] Section 3.17, when
for pre-authentication, the session may not start until some future sent in an Access-Accept along with a Termination-Action value of
time, or may never occur. Nevertheless, the Session-Timeout value RADIUS-Request, the Session-Timeout attribute specifies the maximum
represents the maximum time after which transported EAP keying number of seconds of service provided prior to re-authentication.
material, and all keys calculated from it, will have expired on the
authenticator. If the session subsequently starts, re- Where EAP is used for pre-authentication, the session may not start
authentication will be initiated once the Session-Time has expired. until some future time, or may never occur. Nevertheless, the
If the session never started, or started and ended, by default keys Session-Timeout value represents the maximum time after which
transported by AAA and all keys calculated from them will be transported EAP keying material, and all keys calculated from it,
expired by the authenticator prior to the future time indicated by will have expired on the authenticator. If the session
Session-Timeout. Note that in future additional attributes may be subsequently starts, re-authentication will be initiated once the
specified to control the lifetime of cached keys; these attributes Session-Time has expired. If the session never started, or started
may modify the meaning of the Session-Timeout attribute in specific and ended, by default keys transported by AAA and all keys
circumstances. calculated from them will be expired by the authenticator prior to
the future time indicated by Session-Timeout; this feature is
utilized by [IEEE-802.11i]. Note that in future additional
attributes may be specified to control the lifetime of cached keys;
these attributes may modify the meaning of the Session-Timeout
attribute in specific circumstances.
Since the TSK lifetime is often determined by authenticator Since the TSK lifetime is often determined by authenticator
resources, the backend authentication server has no insight into resources, the backend authentication server has no insight into
the TSK derivation process, and by the principle of ciphersuite the TSK derivation process, and by the principle of ciphersuite
independence, it is not appropriate for the backend authentication independence, it is not appropriate for the backend authentication
server to manage any aspect of the TSK derivation process, server to manage any aspect of the TSK derivation process,
including the TSK lifetime. including the TSK lifetime.
[b] Lower layer mechanisms. While AAA attributes can communicate the [b] Lower layer mechanisms. While AAA attributes can communicate the
maximum exported key lifetime, this only serves to synchronize the maximum exported key lifetime, this only serves to synchronize the
key lifetime between the backend authentication server and the key lifetime between the backend authentication server and the
authenticator. Lower layer mechanisms such as the Secure authenticator. Lower layer mechanisms such as the Secure
Association Protocol can then be used to enable the lifetime of Association Protocol can then be used to enable the lifetime of
exported and calculated keys to be negotiated between the peer and exported and calculated keys to be negotiated between the peer and
authenticator. authenticator.
Where TSKs are established as the result of a Secure Association Where TSKs are established as the result of a Secure Association
Protocol exchange, it is RECOMMENDED that the Secure Association Protocol exchange, it is RECOMMENDED that the Secure Association
Protocol include support for TSK resynchronization. Where the TSK Protocol include support for TSK rekey. Where the TSK is taken
is taken from the MSK, there is no need to manage the TSK lifetime directly from the MSK, there is no need to manage the TSK lifetime
as a separate parameter, since the TSK lifetime and MSK lifetime as a separate parameter, since the TSK lifetime and MSK lifetime
are identical. are identical.
[c] System defaults. Where the EAP method does not support the [c] System defaults. Where the EAP method does not support the
negotiation of the exported key lifetime, and a key lifetime negotiation of the exported key lifetime, and a key lifetime
negotiation mechanism is not provided by the lower lower, there may negotiation mechanism is not provided by the lower lower, there may
be no way for the peer to learn the exported key lifetime. In this be no way for the peer to learn the exported key lifetime. In this
case it is RECOMMENDED that the peer assume a default value of the case it is RECOMMENDED that the peer assume a default value of the
exported key lifetime; 8 hours is recommended. Similarly, the exported key lifetime; 8 hours is recommended. Similarly, the
lifetime of calculated keys can also be managed as a system lifetime of calculated keys can also be managed as a system
skipping to change at page 30, line 13 skipping to change at page 30, line 36
of this hash [MD5Collision]. of this hash [MD5Collision].
As discussed in [RFC3579] Section 4.3, the security vulnerabilities As discussed in [RFC3579] Section 4.3, the security vulnerabilities
of RADIUS are extensive, and therefore development of an alternative of RADIUS are extensive, and therefore development of an alternative
key wrap technique based on the RADIUS shared secret would not key wrap technique based on the RADIUS shared secret would not
substantially improve security. As a result, [RFC3759] Section 4.2 substantially improve security. As a result, [RFC3759] Section 4.2
recommends running RADIUS over IPsec. The same approach is taken in recommends running RADIUS over IPsec. The same approach is taken in
Diameter EAP [RFC4072], which defines cleartext key attributes, to be Diameter EAP [RFC4072], which defines cleartext key attributes, to be
protected by IPsec or TLS. protected by IPsec or TLS.
Where an untrusted AAA intermediary is present (such as a RADIUS
proxy or a Diameter agent), and data object security is not used,
transported keying material may be recovered by an attacker in
control of the untrusted intermediary. Possession of transported
keying material enables decryption of data traffic sent between the
peer and a specific authenticator. However, as long as EAP keying
material or keys derived from it are only utilized by a single
authenticator, compromise of the transported keying material does not
enable an attacker to impersonate the peer to another authenticator.
Vulnerability to an untrusted AAA intermediary can be mitigated by
implementation of redirect functionality, as described in [RFC3588]
and [RFC4072].
4. Handoff Vulnerabilities 4. Handoff Vulnerabilities
With EAP, several mechanisms are available to reduce the latency in With EAP, several mechanisms are available to reduce the latency in
handoff between authenticators: handoff between authenticators:
[1] EAP pre-authentication. This utilizes EAP to pre-establish EAP [1] EAP pre-authentication. This utilizes EAP to pre-establish EAP
keying material on an authenticator prior to arrival of the peer. keying material on an authenticator prior to arrival of the peer.
Use of pre-authentication within IEEE 802.11 is described in Use of pre-authentication within IEEE 802.11 is described in
[8021XHandoff] and [IEEE-802.11i]. [8021XHandoff] and [IEEE-802.11i].
skipping to change at page 33, line 29 skipping to change at page 33, line 38
authentication server might return different authorizations depending authentication server might return different authorizations depending
on the authenticator making the request, in order to make sure that on the authenticator making the request, in order to make sure that
the requested service is consistent with the authenticator the requested service is consistent with the authenticator
capabilities. capabilities.
If differences between the new and old device would result in the If differences between the new and old device would result in the
backend authentication server sending a different set of messages to backend authentication server sending a different set of messages to
the new device than were sent to the old device, then if the handoff the new device than were sent to the old device, then if the handoff
mechanism bypasses AAA, the handoff cannot be carried out correctly. mechanism bypasses AAA, the handoff cannot be carried out correctly.
For example, if some authenticators support dynamic VLANs while For example, if some authenticators support dynamic Virtual LANs
others do not, then attributes present in the Access-Request (such as (VLANs) while others do not, then attributes present in the Access-
the NAS-IP-Address, NAS-IPv6-Address, NAS-Identifier, etc.) could be Request (such as the NAS-IP-Address, NAS-IPv6-Address, NAS-
examined to determine when VLAN attributes will be returned, as Identifier, etc.) could be examined to determine when VLAN attributes
described in [RFC3580]. VLAN support is defined in [IEEE-802.1Q]. will be returned, as described in [RFC3580]. VLAN support is
If a handoff bypassing the backend authentication server were to defined in [IEEE-802.1Q]. If a handoff bypassing the backend
occur between a authenticator supporting dynamic VLANs and another authentication server were to occur between a authenticator
authenticator which does not, then a guest user with access supporting dynamic VLANs and another authenticator which does not,
restricted to a guest VLAN could be given unrestricted access to the then a guest user with access restricted to a guest VLAN could be
network. given unrestricted access to the network.
Similarly, in a network where access is restricted based on the day Similarly, in a network where access is restricted based on the day
and time, Service Set Identifier (SSID), Calling-Station-Id or other and time, Service Set Identifier (SSID), Calling-Station-Id or other
factors, unless the restrictions are encoded within the factors, unless the restrictions are encoded within the
authorizations, or a partial AAA conversation is included, then a authorizations, or a partial AAA conversation is included, then a
handoff could result in the user bypassing the restrictions. handoff could result in the user bypassing the restrictions.
In practice, these considerations limit the situations in which fast In practice, these considerations limit the situations in which fast
handoff mechanisms bypassing AAA can be expected to be successful. handoff mechanisms bypassing AAA can be expected to be successful.
Where the deployed devices implement the same set of services, it may Where the deployed devices implement the same set of services, it may
skipping to change at page 35, line 7 skipping to change at page 35, line 15
of such a handoff would be a failure, since if the handoff were of such a handoff would be a failure, since if the handoff were
blindly carried out, then the user would be moved from a secure to an blindly carried out, then the user would be moved from a secure to an
insecure channel without permission from the backend authentication insecure channel without permission from the backend authentication
server. Thus the definition of a "known but unsupported service" server. Thus the definition of a "known but unsupported service"
MUST encompass requests for unavailable security services. This MUST encompass requests for unavailable security services. This
includes vendor-specific attributes related to security, such as includes vendor-specific attributes related to security, such as
those described in [RFC2548]. those described in [RFC2548].
5. Security Considerations 5. Security Considerations
In order to analyze whether the EAP conversation achieves its
security goals, it is first necessary to describe the threat model.
The terms "Cryptographic binding", "Cryptographic separation", "Key
strength" and "Mutual authentication" are defined in [RFC3748] and
are used with the same meaning here.
5.1. Threat Model
The EAP threat model is described in [RFC3748] Section 7.1. The The EAP threat model is described in [RFC3748] Section 7.1. The
security properties of EAP methods (known as "security claims", security properties of EAP methods (known as "security claims") are
described in [RFC3784] Section 7.2.1), address these threats. EAP described in [RFC3784] Section 7.2.1. EAP method requirements for
method requirements for applications such as Wireless LAN applications such as Wireless LAN authentication are described in
authentication are described in [RFC4017]. The RADIUS threat model [RFC4017]. The RADIUS threat model is described in [RFC3579] Section
is described in [RFC3579] Section 4.1, and responses to these threats 4.1, and responses to these threats are described in [RFC3579]
are described in [RFC3579] Sections 4.2 and 4.3. Sections 4.2 and 4.3.
However, in addition to threats against EAP and AAA, there are other However, in addition to threats against EAP and AAA, there are other
system-level threats worth discussing. These include: system-level threats:
[1] An attacker may compromise or steal an EAP authenticator, in an [1] An attacker may compromise or steal an EAP authenticator, in an
attempt to gain access to other EAP authenticators or obtain long- attempt to gain access to other EAP authenticators or obtain long-
term secrets. term secrets.
[2] An attacker may compromise an EAP authenticator in an effort to [2] An attacker may try to modify or spoof packets, including Discovery
commit fraud. For example, a compromised authenticator may provide
incorrect information to the EAP peer and/or server via out-of-band
mechanisms (such as via a AAA or lower layer protocol). This
includes impersonating another authenticator, or providing
inconsistent information to the peer and EAP server.
[3] An attacker may try to modify or spoof packets, including Discovery
or Secure Association Protocol frames, EAP or AAA packets. or Secure Association Protocol frames, EAP or AAA packets.
[4] An attacker may attempt a downgrade attack in order to exploit [3] 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. transform.
[5] An attacker may attempt to induce an EAP peer, authenticator or [4] 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.
[6] An attacker may replay packets. [5] An attacker may replay packets.
[7] An attacker may cause an EAP peer, authenticator or server to reuse [6] An attacker may cause an EAP peer, authenticator or server to reuse
an stale key. Use of stale keys may also occur unintentionally. an 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.
[8] An authenticated attacker may attempt to obtain elevated privilege [7] 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.
[8] An attacker may attempt a man-in-the-middle attack in order to gain
access to the network.
[9] An attacker may launch a denial of service attack against the EAP
peer, authenticator or backend authentication server.
[10] An attacker may compromise an EAP authenticator in an effort to
commit fraud. For example, a compromised authenticator may provide
incorrect information to the EAP peer and/or server via out-of-band
mechanisms (such as via a AAA or lower layer protocol). This
includes impersonating another authenticator, or providing
inconsistent information to the peer and EAP server.
In order to address these threats, [Housley] provides a description In order to address these threats, [Housley] provides a description
of mandatory system security properties. Issues relating system of mandatory system security properties. Issues relating to system
security requirements are discussed in the sections that follow. security requirements are discussed in the sections that follow.
5.2. Authenticator Compromise 5.1. Authenticator Compromise
In the event that an authenticator is compromised or stolen, an In the event that an authenticator is compromised or stolen, an
attacker may gain access to the network via that authenticator, or attacker may gain access to the network via that authenticator, or
may obtain the credentials required for that authenticator/AAA client may obtain the credentials required for that authenticator/AAA client
to communicate with one or more backend authentication servers. to communicate with one or more backend authentication servers.
However, this should not allow the attacker to compromise other However, this should not allow the attacker to compromise other
authenticators or the backend authentication server, or obtain long- authenticators or the backend authentication server, or obtain long-
term user credentials. term user credentials.
The implications of this requirement are many, but some of the more The implications of this requirement are many, but some of the more
skipping to change at page 37, line 5 skipping to change at page 37, line 11
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.3. Spoofing 5.2. Spoofing
The use of per-packet authentication and integrity protection The use of per-packet authentication and integrity protection
provides protection against spoofing attacks. Diameter [RFC3588] provides protection against spoofing attacks. Diameter [RFC3588]
provides support for per-packet authentication and integrity provides support for per-packet authentication and integrity
protection via use of IPsec or TLS. RADIUS/EAP [RFC3579] provides protection via use of IPsec or TLS. RADIUS/EAP [RFC3579] provides
for per-packet authentication and integrity protection via use of the for per-packet authentication and integrity protection via use of the
Message-Authenticator attribute. Message-Authenticator attribute.
[RFC3748] Section 7.2.1 describes the "integrity protection" security [RFC3748] Section 7.2.1 describes the "integrity protection" security
claim and [RFC4017] requires use of EAP methods supporting this claim and [RFC4017] requires use of EAP methods supporting this
claim. claim.
In order to prevent forgery of Secure Association Protocol frames, In order to prevent forgery of Secure Association Protocol frames,
per-frame authentication and integrity protection is RECOMMENDED on per-frame authentication and integrity protection is RECOMMENDED on
all messages. [IEEE-802.11i] supports per-frame integrity protection all messages. [IEEE-802.11i] supports per-frame integrity protection
and authentication on all messages within the 4-way handshake except and authentication on all messages within the 4-way handshake except
the first message. An attack leveraging this ommission is described the first message. An attack leveraging this ommission is described
in [Analysis]. in [Analysis].
5.4. Downgrade Attacks 5.3. Downgrade Attacks
The ability to negotiate the use of a particular cryptographic The ability to negotiate the use of a particular cryptographic
algorithm provides resilience against compromise of a particular algorithm provides resilience against compromise of a particular
cryptographic algorithm. This is usually accomplished by including cryptographic algorithm. This is usually accomplished by including
an algorithm identifier in the protocol, and by specifying the an algorithm identifier in the protocol, and by specifying the
algorithm requirements in the protocol specification. In order to algorithm requirements in the protocol specification. In order to
prevent downgrade attacks, secure confirmation of the "best" prevent downgrade attacks, secure confirmation of the "best"
ciphersuite is required. ciphersuite is required.
[RFC3748] Section 7.2.1 describes the "protected ciphersuite [RFC3748] Section 7.2.1 describes the "protected ciphersuite
skipping to change at page 38, line 10 skipping to change at page 38, line 16
As a result, EAP methods and AAA protocols are capable of addressing As a result, EAP methods and AAA protocols are capable of addressing
downgrade attacks. To ensure against downgrade attacks within lower downgrade attacks. To ensure against downgrade attacks within lower
layer protocols, algorithm independence is REQUIRED with lower layers layer protocols, algorithm independence is REQUIRED with lower layers
using EAP for key derivation. For interoperability, at least one using EAP for key derivation. For interoperability, at least one
suite of mandatory-to-implement algorithm MUST be selected. Lower suite of mandatory-to-implement algorithm MUST be selected. Lower
layer protocols supporting EAP for key derivation SHOULD also support layer protocols supporting EAP for key derivation SHOULD also support
secure ciphersuite negotiation. As described in [RFC1968], PPP ECP secure ciphersuite negotiation. As described in [RFC1968], PPP ECP
does not provide support for secure ciphersuite negotiation. does not provide support for secure ciphersuite negotiation.
However, [IEEE-802.11i] does support secure ciphersuite negotiation. However, [IEEE-802.11i] does support secure ciphersuite negotiation.
5.5. Unauthorized Disclosure 5.4. Unauthorized Disclosure
While preserving algorithm independence, confidentiality of all While preserving algorithm independence, confidentiality of all
keying material MUST be maintained. To prevent unauthorized disclose keying material MUST be maintained. To prevent unauthorized disclose
of keys, each party in the EAP conversation MUST be authenticated to of keys, each party in the EAP conversation MUST be authenticated to
the other parties with whom it communicates. Keying material MUST be the other parties with whom it communicates. Keying material MUST be
bound to the appropriate context. bound to the appropriate context.
[RFC3748] Section 7.2.1 describes the "mutual authentication" and [RFC3748] Section 7.2.1 describes the "mutual authentication" and
"dictionary attack resistance" claims, and [RFC4017] requires EAP "dictionary attack resistance" claims, and [RFC4017] requires EAP
methods satisfying these claims. EAP methods complying with methods satisfying these claims. EAP methods complying with
[RFC4017] therefore provide for mutual authentication between the EAP [RFC4017] therefore provide for mutual authentication between the EAP
peer and server. Binding of EAP keying material (MSK, EMSK) to the peer and server. Within EAP, binding of EAP keying material (MSK,
appropriate context is provided by the Peer-ID and Server-ID which EMSK) to the appropriate context is provided by the Peer-Id and
are exported along with the keying material. Server-Id which are exported along with the keying material.
Diameter [RFC3588] provides for per-packet authentication and Diameter [RFC3588] provides for per-packet authentication and
integrity protection via IPsec or TLS, and RADIUS/EAP [RFC3579] also integrity protection via IPsec or TLS, and RADIUS/EAP [RFC3579] also
provides for per-packet authentication and integrity protection. provides for per-packet authentication and integrity protection.
Where the NAS/authenticator and backend authentication server Where the NAS/authenticator and backend authentication server
communicate directly and credible keywrap is used (see Section 3.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 achieves its security
objectives: mutually authenticating the AAA client/authenticator and objectives: mutually authenticating the AAA client/authenticator and
backend authentication server and providing EAP keying material to backend authentication server and providing EAP keying material to
the EAP authenticator and to no other party. [RFC2607] Section 7 the EAP authenticator and to no other party. Within the AAA
describes the security issues ocurring when the authenticator and protocol, the authorization attributes provide the information
backend authentication server do not communicate directly. 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
authenticator and backend authentication server do not communicate
directly. Where an untrusted AAA intermediary is present (such as a
RADIUS proxy or a Diameter agent), and data object security is not
used, transported keying material may be recovered by an attacker in
control of the untrusted intermediary. As discussed in Section 2.1,
unless the TSKs are derived independently from EAP keying material
(as in IKEv2), possession of transported keying material enables
decryption of data traffic sent between the peer and a specific
authenticator. However, as long as EAP keying material or keys
derived from it are only utilized by a single authenticator,
compromise of the transported keying material does not enable an
attacker to impersonate the peer to another authenticator.
Vulnerability to an untrusted AAA intermediary can be mitigated by
implementation of redirect functionality, as described in [RFC3588]
and [RFC4072].
As noted in Section 3.1, the Secure Association Protocol does not by As noted in Section 3.1, the Secure Association Protocol does not by
itself provide for mutual authentication between the EAP peer and itself provide for mutual authentication between the EAP peer and
authenticator, even if mutual possession of EAP keying material is authenticator, even if mutual possession of EAP keying material is
proven. Where the NAS/authenticator and backend authentication proven. Where the NAS/authenticator and backend authentication
server communicate directly, the backend authentication server can server communicate directly, the backend authentication server can
verify the correspondence between NAS identification attributes, the verify the correspondence between NAS identification attributes, the
source address of packets sent by the NAS, and the AAA credentials. 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 As long as the NAS has not shared its AAA credentials with another
NAS, this allows the backend authentication server to authenticate NAS, this allows the backend authentication server to authenticate
skipping to change at page 39, line 21 skipping to change at page 39, line 47
authorizations associated the other parties. If peer authorization authorizations associated the other parties. If peer authorization
is restricted, then the peer SHOULD be made aware of the restriction. is restricted, then the peer SHOULD be made aware of the restriction.
The AAA exchange provides the EAP authenticator with authorizations The AAA exchange provides the EAP authenticator with authorizations
relating to the EAP peer. However, neither the EAP nor AAA exchanges relating to the EAP peer. However, neither the EAP nor AAA exchanges
provides authorizations to the EAP peer. In order to ensure that all provides authorizations to the EAP peer. In order to ensure that all
parties hold the same view of the authorizations it is RECOMMENDED parties hold the same view of the authorizations it is RECOMMENDED
that the Secure Association Protocol enable communication of that the Secure Association Protocol enable communication of
authorizations between the EAP authenticator and peer. authorizations between the EAP authenticator and peer.
In order to enable key binding and authorization of all parties, it Consistently identifying the EAP authenticator enables the EAP peer
is RECOMMENDED that the parties use a set of identities that are to determine whether EAP keying material has been shared between EAP
consistent between the conversation phases. Consistently identifying authenticators as well as to confirm with the backend authentication
the EAP authenticator enables the EAP peer to determine whether EAP server that an EAP authenticator proving possession of EAP keying
keying material has been shared between EAP authenticators as well as material during the Secure Association Protocol was authorized to
to confirm with the backend authentication server that an EAP obtain it. Identification issues are discussed in Section 2.2 and
authenticator proving possession of EAP keying material during the key scope issues are discussed in Section 3.2.
Secure Association Protocol was authorized to obtain it.
Identification issues are discussed in Section 2.2 and key scope
issues are discussed in Section 3.2.
5.6. Replay Protection 5.5. Replay Protection
Replay protection allows a protocol message recipient to discard any Replay protection allows a protocol message recipient to discard any
message that was recorded during a previous legitimate dialogue and message that was recorded during a previous legitimate dialogue and
presented as though it belonged to the current dialogue. presented as though it belonged to the current dialogue.
[RFC3748] Section 7.2.1 describes the "replay protection" security [RFC3748] Section 7.2.1 describes the "replay protection" security
claim and [RFC4017] requires use of EAP methods supporting this claim and [RFC4017] requires use of EAP methods supporting this
claim. claim.
Diameter [RFC3588] provides support for replay protection via use of Diameter [RFC3588] provides support for replay protection via use of
skipping to change at page 40, line 10 skipping to change at page 40, line 34
depend on a Nonce in either the Request or Response packets. depend on a Nonce in either the Request or Response packets.
Therefore unless an Event-Timestamp attribute is included or IPsec is Therefore unless an Event-Timestamp attribute is included or IPsec is
used, the recipient may not be able to determine whether these used, the recipient may not be able to determine whether these
packets have been replayed. packets have been replayed.
In order to prevent replay of Secure Association Protocol frames, In order to prevent replay of Secure Association Protocol frames,
replay protection is REQUIRED on all messages. [IEEE-802.11i] replay protection is REQUIRED on all messages. [IEEE-802.11i]
supports replay protection on all messages within the 4-way supports replay protection on all messages within the 4-way
handshake. handshake.
5.7. Key Freshness 5.6. Key Freshness
A session key should be considered compromised if it remains in use A session key should be considered compromised if it remains in use
too long. As noted in [Housley], session keys MUST be strong and too long. As noted in [Housley], session keys MUST be strong and
fresh, while preserving algorithm independence. A fresh fresh, while preserving algorithm independence. A fresh
cryptographic key is one that is generated specifically for the cryptographic key is one that is generated specifically for the
intended use. Each session deserves an independent session key; intended use. Each session deserves an independent session key;
disclosure of one session key MUST NOT aid the attacker in disclosure of one session key MUST NOT aid the attacker in
discovering any other session keys. discovering any other session keys.
Fresh keys are required even when a long replay counter (that is, one Fresh keys are required even when a long replay counter (that is, one
skipping to change at page 40, line 48 skipping to change at page 41, line 25
[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 and [RFC4017] requires use of
EAP methods supporting these claims as well as being capable of EAP methods supporting these claims as well as being capable of
providing an equivalent key strength of 128 bits or greater. providing an equivalent key strength of 128 bits or greater.
AAA The AAA protocol needs to ensure that transported keying material AAA The AAA protocol needs to ensure that transported keying material
is fresh and is not utilized outside its recommended lifetime. is fresh and is not utilized outside its recommended lifetime.
Replay protection is necessary for key freshness, but an attacker Replay protection is necessary for key freshness, but an attacker
can deliver a stale (and therefore potentially compromised) key in can deliver a stale (and therefore potentially compromised) key in
a replay-protected message, so replay protection is not sufficient. a replay-protected message, so replay protection is not sufficient.
As discussed in Section 3.5, the Session-Timeout attribute enables
the backend authentication server to limit the exposure of
transported EAP keying material.
The EAP Session-ID, derived from the EAP Type and Method-ID (based The EAP Session-Id, derived from the EAP Type and Method-Id (based
on the nonces contributed by the peer and server) enables the EAP on the nonces contributed by the peer and server) enables the EAP
peer, authenticator and server to distinguish EAP conversations. peer, authenticator and server to distinguish EAP conversations.
However, unless the authenticator keeps track of EAP Session-IDs, However, unless the authenticator keeps track of EAP Session-Ids,
the authenticator cannot use the Session-ID to guarantee the the authenticator cannot use the Session-Id to guarantee the
freshness of EAP keying material. freshness of EAP keying material.
As described in [RFC3580] Section 3.17, When sent in an Access-
Accept along with a Termination-Action value of RADIUS-Request, the
Session-Timeout attribute specifies the maximum number of seconds
of service provided prior to re-authentication. [IEEE-802.11i]
also utilizes the Session-Timeout attribute to limit the maximum
time that EAP keying material may be cached. Therefore the use of
the Session-Timeout attribute enables the backend authentication
server to limit the exposure of EAP keying material.
Lower Layer Lower Layer
As described in Section 3.1, the lower layer Secure Association As described in Section 3.1, the lower layer Secure Association
Protocol MUST generate a fresh session key for each session, even Protocol MUST generate a fresh session key for each session, even
if the keying material and parameters provided by EAP methods are if the keying material and parameters provided by EAP methods are
cached, or either the peer or authenticator lack a high entropy cached, or either the peer or authenticator lack a high entropy
random number generator. A RECOMMENDED method is for the peer and random number generator. A RECOMMENDED method is for the peer and
authenticator to each provide a nonce or counter used in session authenticator to each provide a nonce or counter used in session
key derivation. If a nonce is used, it is RECOMMENDED that it be key derivation. If a nonce is used, it is RECOMMENDED that it be
at least 128 bits. at least 128 bits.
5.8. Elevation of Privilege 5.7. Elevation of Privilege
Parties MUST NOT have access to keying material that is not needed to Parties MUST NOT have access to keying material that is not needed to
perform their own role. A party has access to a particular key if it perform their own role. A party has access to a particular key if it
has access to all of the secret information needed to derive it. If has access to all of the secret information needed to derive it. If
a Secure Association Protocol is used to establish session keys, it a Secure Association Protocol is used to establish session keys, it
MUST specify the scope for session keys. MUST specify the scope for session keys.
Transported EAP keying material is permitted to be accessed by the Transported EAP keying material is permitted to be accessed by the
EAP peer, authenticator and server. The EAP peer and server derive EAP peer, authenticator and server. The EAP peer and server derive
the transported keying material during the process of mutually the transported keying material during the process of mutually
skipping to change at page 42, line 15 skipping to change at page 42, line 34
802.16e utilizes transported EAP keying material for TSK keywrap; 802.16e utilizes transported EAP keying material for TSK keywrap;
IKEv2 utilizes transported EAP keying material only to authenticate IKEv2 utilizes transported EAP keying material only to authenticate
the derivation of TSKs. the derivation of TSKs.
Where demonstration of authorization depends entirely on possession Where demonstration of authorization depends entirely on possession
of transported EAP keying material (such as in PPP, 802.11i and of transported EAP keying material (such as in PPP, 802.11i and
802.16e), this enables the backend server to masquerade as the 802.16e), this enables the backend server to masquerade as the
authenticator, and possibly to obtain the TSKs unless the backend authenticator, and possibly to obtain the TSKs unless the backend
server deletes the transported EAP keying material after sending it. server deletes the transported EAP keying material after sending it.
5.9. Man-in-the-middle Attacks 5.8. Man-in-the-middle Attacks
As described in [I-D.puthenkulam-eap-binding], EAP method sequences As described in [I-D.puthenkulam-eap-binding], EAP method sequences
and compound authentication mechanisms may be subject to man-in-the- and compound authentication mechanisms may be subject to man-in-the-
middle attacks. When such attacks are successfully carried out, the middle attacks. When such attacks are successfully carried out, the
attacker acts as an intermediary between a victim and a legitimate attacker acts as an intermediary between a victim and a legitimate
authenticator. This allows the attacker to authenticate successfully authenticator. This allows the attacker to authenticate successfully
to the authenticator, as well as to obtain access to the network. to the authenticator, as well as to obtain access to the network.
In order to prevent these attacks, [I-D.puthenkulam-eap-binding] In order to prevent these attacks, [I-D.puthenkulam-eap-binding]
recommends derivation of a compound key by which the EAP peer and recommends derivation of a compound key by which the EAP peer and
server can prove that they have participated in the entire EAP server can prove that they have participated in the entire EAP
exchange. Since the compound key must not be known to an attacker exchange. Since the compound key must not be known to an attacker
posing as an authenticator, and yet must be derived from quantities posing as an authenticator, and yet must be derived from quantities
that are exported by EAP methods, it may be desirable to derive the that are exported by EAP methods, it may be desirable to derive the
compound key from a portion of the EMSK. In order to provide proper compound key from a portion of the EMSK. In order to provide proper
key hygiene, it is recommended that the compound key used for man-in- key hygiene, it is recommended that the compound key used for man-in-
the-middle protection be cryptographically separate from other keys the-middle protection be cryptographically separate from other keys
derived from the EMSK. derived from the EMSK.
5.10. Denial of Service Attacks 5.9. Denial of Service Attacks
Key caching may result in vulnerability to denial of service attacks. Key caching may result in vulnerability to denial of service attacks.
For example, EAP methods that create persistent state may be For example, EAP methods that create persistent state may be
vulnerable to denial of service attacks on the EAP server by a rogue vulnerable to denial of service attacks on the EAP server by a rogue
EAP peer. EAP peer.
To address this vulnerability, EAP methods creating persistent state To address this vulnerability, EAP methods creating persistent state
may wish to limit the persistent state created by an EAP peer. For may wish to limit the persistent state created by an EAP peer. For
example, for each peer an EAP server may choose to limit persistent example, for each peer an EAP server may choose to limit persistent
state to a few EAP conversations, distinguished by the EAP Session- state to a few EAP conversations, distinguished by the EAP Session-
ID. This prevents a rogue peer from denying access to other peers. Id. This prevents a rogue peer from denying access to other peers.
Similarly, to conserve resources an authenticator may choose to limit Similarly, to conserve resources an authenticator may choose to limit
the persistent state corresponding to each peer. This can be the persistent state corresponding to each peer. This can be
accomplished by limiting each peer to persistent 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.11. Impersonation 5.10. Impersonation
Both the RADIUS [RFC2865] and Diameter [RFC3588] protocols are Both the RADIUS [RFC2865] and Diameter [RFC3588] protocols are
potentially vulnerable to impersonation by a rogue authenticator. potentially vulnerable to impersonation by a rogue authenticator.
While both protocols support mutual authentication between the While both protocols support mutual authentication between the
authenticator (known as the AAA client) and the backend authenticator/AAA client and the backend authentication server, the
authentication server (known as the backend authentication server), security mechanisms vary.
the security mechanisms vary.
In RADIUS, the shared secret used for authentication is determined by In RADIUS, the shared secret used for authentication is determined by
the source address of the RADIUS packet. As noted in [RFC3579] the source address of the RADIUS packet. As noted in [RFC3579]
Section 4.3.7, it is highly desirable that the source address be Section 4.3.7, it is highly desirable that the source address be
checked against one or more NAS identification attributes so as to checked against one or more NAS identification attributes so as to
detect and prevent impersonation attacks. detect and prevent impersonation attacks.
When RADIUS Access-Requests are forwarded by a proxy, the NAS-IP- When RADIUS Access-Requests are forwarded by a proxy, the NAS-IP-
Address or NAS-IPv6-Address attributes may not correspond to the Address or NAS-IPv6-Address attributes may not correspond to the
source address. Since the NAS-Identifier attribute need not contain source address. Since the NAS-Identifier attribute need not contain
skipping to change at page 43, line 49 skipping to change at page 44, line 17
transported keying material) being sent to the wrong authenticator. transported keying material) being sent to the wrong authenticator.
Since the rogue authenticator is authenticated by the RADIUS proxy or Since the rogue authenticator is authenticated by the RADIUS proxy or
server purely based on the source address, other mechanisms are server purely based on the source address, other mechanisms are
required to detect the forgery. In addition, it is possible for required to detect the forgery. In addition, it is possible for
attributes such as the Called-Station-Id and Calling-Station-Id to be attributes such as the Called-Station-Id and Calling-Station-Id to be
forged as well. forged as well.
[RFC3579] Section 4.3.7 describes how an EAP pass-through [RFC3579] Section 4.3.7 describes how an EAP pass-through
authenticator acting as a AAA client can be detected if it attempts authenticator acting as a AAA client can be detected if it attempts
to impersonate another authenticator (such by sending incorrect to impersonate another authenticator (such by sending incorrect
Called-Station-ID [RFC2865], NAS-Identifier [RFC2865], NAS-IP-Address Called-Station-Id [RFC2865], NAS-Identifier [RFC2865], NAS-IP-Address
[RFC2865] or NAS-IPv6-Address [RFC3162] attributes via the AAA [RFC2865] or NAS-IPv6-Address [RFC3162] attributes via the AAA
protocol). This vulnerabilityh can be mitigated by having RADIUS protocol). This vulnerability can be mitigated by having RADIUS
proxies check NAS identification attributes against the source proxies check NAS identification attributes against the source
address. address.
While [RFC3588] requires use of the Route-Record AVP, this utilizes While [RFC3588] requires use of the Route-Record AVP, this utilizes
FQDNs, so that impersonation detection requires DNS A, AAAA and PTR FQDNs, so that impersonation detection requires DNS A, AAAA and PTR
Resource Records (RRs) to be properly configured. As a result, Resource Records (RRs) to be properly configured. As a result,
Diameter is as vulnerable to this attack as RADIUS, if not more so. Diameter is as vulnerable to this attack as RADIUS, if not more so.
To address this vulnerability, it is necessary to allow the backend To address this vulnerability, it is necessary to allow the backend
authentication server to communicate with the authenticator directly, authentication server to communicate with the authenticator directly,
such as via the redirect functionality supported in [RFC3588]. such as via the redirect functionality supported in [RFC3588].
5.12. Channel Binding 5.11. Channel Binding
It is possible for a compromised or poorly implemented EAP It is possible for a compromised or poorly implemented EAP
authenticator to communicate incorrect information to the EAP peer authenticator to communicate incorrect information to the EAP peer
and/or server. This may enable an authenticator to impersonate and/or server. This may enable an authenticator to impersonate
another authenticator or communicate incorrect information via out- another authenticator or communicate incorrect information via out-
of-band mechanisms (such as via AAA or the lower layer). of-band mechanisms (such as via AAA or the lower layer).
Where EAP is used in pass-through mode, the EAP peer does not verify Where EAP is used in pass-through mode, the EAP peer does not verify
the identity of the pass-through authenticator. Within the Secure the identity of the pass-through authenticator. Within the Secure
Association Protocol, the EAP peer and authenticator only demonstrate Association Protocol, the EAP peer and authenticator only demonstrate
mutual possession of the transported EAP keying material. This mutual possession of the transported EAP keying material. This
creates a potential security vulnerability, described in [RFC3748] creates a potential security vulnerability, described in [RFC3748]
Section 7.15. Section 7.15.
As described in the previous section, it is possible for a proxy to As described in the previous section, it is possible for a proxy to
detect a AAA client attempting to impersonate another authenticator detect a AAA client attempting to impersonate another authenticator
(such by sending incorrect Called-Station-ID [RFC2865], NAS- (such by sending incorrect Called-Station-Id [RFC2865], NAS-
Identifier [RFC2865], NAS-IP-Address [RFC2865] or NAS-IPv6-Address Identifier [RFC2865], NAS-IP-Address [RFC2865] or NAS-IPv6-Address
[RFC3162] attributes via the AAA protocol). However, it is possible [RFC3162] attributes via the AAA protocol). However, it is possible
for a pass-through authenticator acting as a AAA client to provide for a pass-through authenticator acting as a AAA client to provide
correct information to the backend authentication server while correct information to the backend authentication server while
communicating misleading information to the EAP peer via the lower communicating misleading information to the EAP peer via the lower
layer. layer.
For example, a compromised authenticator can utilize another For example, a compromised authenticator can utilize another
authenticator's Called-Station-Id or NAS-Identifier in communicating authenticator's Called-Station-Id or NAS-Identifier in communicating
with the EAP peer via the lower layer. Also, a pass-through with the EAP peer via the lower layer. Also, a pass-through
authenticator acting as a AAA client can provide an incorrect peer authenticator acting as a AAA client can provide an incorrect peer
Calling-Station-Id [RFC2865][RFC3580] to the AAA server via the AAA Calling-Station-Id [RFC2865][RFC3580] to the backend authentication
protocol. server via the AAA protocol.
As noted in [RFC3748] Section 7.15, this vulnerability can be As noted in [RFC3748] Section 7.15, this vulnerability can be
addressed by EAP methods that support a protected exchange of channel addressed by EAP methods that support a protected exchange of channel
properties such as endpoint identifiers, including (but not limited properties such as endpoint identifiers, including (but not limited
to): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id to): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id
[RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address [RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address
[RFC2865], and NAS-IPv6-Address [RFC3162]. [RFC2865], and NAS-IPv6-Address [RFC3162].
Using such a protected exchange, it is possible to match the channel Using such a protected exchange, it is possible to match the channel
properties provided by the authenticator via out-of-band mechanisms properties provided by the authenticator via out-of-band mechanisms
against those exchanged within the EAP method. For example, see [I- against those exchanged within the EAP method. For example, see the
D.arkko-eap-service-identity-auth]. discussion in Section 1.4 as well as [I-D.arkko-eap-service-identity-
auth].
It is also possible to achieve Channel Bindings without transporting It is also possible to achieve Channel Bindings without transporting
data over EAP. For example, see [I-D.draft-ohba-eap-aaakey-binding]. data over EAP. For example, see [I-D.draft-ohba-eap-aaakey-binding].
In this approach the authenticator informs the backend server about In this approach the authenticator informs the backend server about
the Channel Binding parameters using AAA, and the backend server the Channel Binding parameters using AAA, and the backend server
calculates transported keying material based on this parameter set, calculates transported keying material based on this parameter set,
making it impossible for the peer and authenticator to complete the making it impossible for the peer and authenticator to complete the
Secure Association Protocol if there was a mismatch in the Secure Association Protocol if there was a mismatch in the
parameters. parameters.
skipping to change at page 50, line 5 skipping to change at page 50, line 22
(GSM) Subscriber Identity Modules (EAP-SIM)", RFC 4186, (GSM) Subscriber Identity Modules (EAP-SIM)", RFC 4186,
January 2006. 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.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
4306, December 2005. 4306, December 2005.
[RFC4372] Adrangi, F., Lior, A., Korhonen, J. and J. Loughney,
"Chargeable User Identity", RFC 4372, January 2006.
[8021XHandoff] [8021XHandoff]
Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff in a Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff in a
Public Wireless LAN Based on IEEE 802.1X Model", School of Public Wireless LAN Based on IEEE 802.1X Model", School of
Computer Science and Engineering, Seoul National Computer Science and Engineering, Seoul National
University, Seoul, Korea, 2002. University, Seoul, Korea, 2002.
Acknowledgments Acknowledgments
Thanks to Arun Ayyagari, Ashwin Palekar, and Tim Moore of Microsoft, Thanks to Arun Ayyagari, Ashwin Palekar, and Tim Moore of Microsoft,
Dorothy Stanley of Agere, Bob Moskowitz of TruSecure, Jesse Walker of Dorothy Stanley of Agere, Bob Moskowitz of TruSecure, Jesse Walker of
skipping to change at page 52, line 7 skipping to change at page 52, line 7
ipUnplugged AB ipUnplugged AB
Arenavagen 27 Arenavagen 27
Stockholm S-121 28 Stockholm S-121 28
SWEDEN SWEDEN
Phone: +46 708 32 16 08 Phone: +46 708 32 16 08
EMail: henrik@levkowetz.com EMail: henrik@levkowetz.com
Appendix A - Exported Parameters in Existing Methods Appendix A - Exported Parameters in Existing Methods
This Appendix specifies Method-ID, Peer-ID, Server-ID and Key- This Appendix specifies Method-Id, Peer-Id, Server-Id and Key-
Lifetime for EAP methods that have been published prior to this Lifetime for EAP methods that have been published prior to this
specification. Future EAP method specifications MUST include a specification. Future EAP method specifications MUST include a
definition of the Method-ID, Peer-ID, and Server-ID (could be the definition of the Method-Id, Peer-Id, and Server-Id (could be the
empty string) and MAY also define the Key-Lifetime (assumed to be empty string) and MAY also define the Key-Lifetime (assumed to be
indeterminate if not described). indeterminate if not described).
EAP-Identity EAP-Identity
The EAP-Identity method is defined in [RC3748]. It does not The EAP-Identity method is defined in [RC3748]. It does not
derive keys, and therefore does not define the Key-Lifetime or derive keys, and therefore does not define the Key-Lifetime or
Method-ID. The Peer-ID exported by the Identity method is Method-Id. The Peer-Id exported by the Identity method is
determined by the octets included within the EAP- determined by the octets included within the EAP-
Response/Identity. The Server-ID is the empty string (zero Response/Identity. The Server-Id is the empty string (zero
length). 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 Key-Lifetime and derive keys and therefore does not define the Key-Lifetime and
Method-ID. The Peer-ID and Server-ID are the empty string (zero Method-Id. The Peer-Id and Server-Id are the empty string (zero
length). length).
EAP-GTC EAP-GTC
The EAP-GTC method is defined in [RFC3748]. It does not derive The EAP-GTC method is defined in [RFC3748]. It does not derive
keys and therefore does not define the Key-Lifetime and Method-ID. keys and therefore does not define the Key-Lifetime and Method-Id.
The Peer-ID and Server-ID are the empty string. The Peer-Id and Server-Id are the empty string.
EAP-OTP EAP-OTP
The EAP-OTP method is defined in [RFC3748]. It does not derive The EAP-OTP method is defined in [RFC3748]. It does not derive
keys and therefore does not define the Key-Lifetime and Method-ID. keys and therefore does not define the Key-Lifetime and Method-Id.
The Peer-ID and Server-ID are the empty string. The Peer-Id and Server-Id are the empty string.
EAP-TLS EAP-TLS
EAP-TLS is defined in [RFC2716]. The EAP-TLS Method-Id is the EAP-TLS is defined in [RFC2716]. The EAP-TLS Method-Id is the
concatenation of the peer and server nonces. The Peer-ID and concatenation of the peer and server nonces. The Peer-Id and
Server-ID are the contents of the altSubjectName in the peer and Server-Id are the contents of the altSubjectName in the peer and
server certificates. EAP-TLS does not negotiate a Key-Lifetime. server certificates. EAP-TLS does not negotiate a Key-Lifetime.
EAP-AKA EAP-AKA
EAP-AKA is defined in [RFC4187]. The EAP-AKA Method-Id is the EAP-AKA is defined in [RFC4187]. The EAP-AKA Method-Id is the
contents of the RAND field from the AT_RAND attribute, followed by contents of the RAND field from the AT_RAND attribute, followed by
the contents of the AUTN field in the AT_AUTN attribute. the contents of the AUTN field in the AT_AUTN attribute.
The Peer-ID is the contents of the Identity field from the The Peer-Id is the contents of the Identity field from the
AT_IDENTITY attribute, using only the Actual Identity Length AT_IDENTITY attribute, using only the Actual Identity Length
octets from the beginning, however. Note that the contents are octets from the beginning, however. Note that the contents are
used as they are transmitted, regardless of whether the used as they are transmitted, regardless of whether the
transmitted identity was a permanent, pseudonym, or fast re- transmitted identity was a permanent, pseudonym, or fast re-
authentication identity. The Server-ID is an empty string. EAP- authentication identity. The Server-Id is an empty string. EAP-
AKA does not negotiate a key lifetime. AKA does not negotiate a key lifetime.
EAP-SIM EAP-SIM
EAP-SIM is defined in [RFC4186]. The EAP-SIM Method-Id is the EAP-SIM is defined in [RFC4186]. The EAP-SIM Method-Id is the
contents of the RAND field from the AT_RAND attribute, followed by contents of the RAND field from the AT_RAND attribute, followed by
the contents of the NONCE_MT field in the AT_NONCE_MT attribute. the contents of the NONCE_MT field in the AT_NONCE_MT attribute.
The Peer-ID is the contents of the Identity field from the The Peer-Id is the contents of the Identity field from the
AT_IDENTITY attribute, using only the Actual Identity Length AT_IDENTITY attribute, using only the Actual Identity Length
octets from the beginning, however. Note that the contents are octets from the beginning, however. Note that the contents are
used as they are transmitted, regardless of whether the used as they are transmitted, regardless of whether the
transmitted identity was a permanent, pseudonym, or fast re- transmitted identity was a permanent, pseudonym, or fast re-
authentication identity. The Server-ID is an empty string. EAP- authentication identity. The Server-Id is an empty string. EAP-
SIM does not negotiate a key lifetime. SIM does not negotiate a key lifetime.
Intellectual Property Statement Intellectual Property Statement
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
 End of changes. 129 change blocks. 
330 lines changed or deleted 349 lines changed or added

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