draft-ietf-eap-keying-08.txt   draft-ietf-eap-keying-09.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-08.txt> J. Arkko <draft-ietf-eap-keying-09.txt> J. Arkko
23 October 2005 Ericsson 8 January 2006 Ericsson
P. Eronen P. Eronen
Nokia Nokia
H. Levkowetz, Ed. H. Levkowetz, Ed.
ipUnplugged ipUnplugged
Extensible Authentication Protocol (EAP) Key Management Framework Extensible Authentication Protocol (EAP) Key Management Framework
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 22, 2006. This Internet-Draft will expire on August 22, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society 2005. Copyright (C) The Internet Society 2006.
Abstract Abstract
The Extensible Authentication Protocol (EAP), defined in [RFC3748], The Extensible Authentication Protocol (EAP), defined in [RFC3748],
enables extensible network access authentication. This document enables extensible network access authentication. This document
provides a framework for the generation, transport and usage of provides a framework for the transport and usage of keying material
keying material generated by EAP authentication algorithms, known as generated by EAP authentication algorithms, known as "methods". It
"methods". It also specifies the EAP key hierarchy. also specifies the EAP key hierarchy.
Table of Contents Table of Contents
1. Introduction .......................................... 3 1. Introduction .......................................... 3
1.1 Requirements Language ........................... 3 1.1 Requirements Language ........................... 3
1.2 Terminology ..................................... 3 1.2 Terminology ..................................... 3
1.3 Overview ........................................ 5 1.3 Overview ........................................ 5
1.4 EAP Invariants .................................. 9 1.4 EAP Invariants .................................. 9
2. Lower Layer Operation ................................. 13 2. Lower Layer Operation ................................. 12
2.1 Overview ........................................ 13 2.1 Overview ........................................ 12
2.2 Layering ........................................ 14 2.2 Layering ........................................ 13
2.3 Caching ......................................... 17 2.3 Transient Session Keys .......................... 15
2.4 Key Scope ....................................... 18 2.4 Key Scope ....................................... 18
3. Key Management ........................................ 21 3. Key Management ........................................ 22
3.1 Secure Association Protocol ..................... 22 3.1 Secure Association Protocol ..................... 22
3.2 Parent-Child Relationships ...................... 24 3.2 Parent-Child Relationships ...................... 25
3.3 Local Key Lifetimes ............................. 25 3.3 Local Key Lifetimes ............................. 26
3.4 Exported and Calculated Key Lifetimes ........... 25 3.4 Exported and Calculated Key Lifetimes ........... 26
3.5 Key Cache Synchronization ....................... 27 3.5 Key Cache Synchronization ....................... 28
3.6 Key Strength .................................... 27 3.6 Key Strength .................................... 28
3.7 Key Wrap ........................................ 28 3.7 Key Wrap ........................................ 29
4. Handoff Vulnerabilities ............................... 29 4. Handoff Vulnerabilities ............................... 30
4.1 Authorization ................................... 29 4.1 Authorization ................................... 30
4.2 Correctness ..................................... 30 4.2 Correctness ..................................... 31
5. Security Considerations .............................. 33 5. Security Considerations .............................. 34
5.1 Security Terminology ............................ 34 5.1 Security Terminology ............................ 35
5.2 Threat Model .................................... 34 5.2 Threat Model .................................... 35
5.3 Authenticator Compromise ........................ 35 5.3 Authenticator Compromise ........................ 36
5.4 Spoofing ........................................ 36 5.4 Spoofing ........................................ 37
5.5 Downgrade Attacks ............................... 36 5.5 Downgrade Attacks ............................... 37
5.6 Unauthorized Disclosure ......................... 37 5.6 Unauthorized Disclosure ......................... 38
5.7 Replay Protection ............................... 38 5.7 Replay Protection ............................... 40
5.8 Key Freshness ................................... 39 5.8 Key Freshness ................................... 40
5.9 Elevation of Privilege .......................... 40 5.9 Elevation of Privilege .......................... 41
5.10 Man-in-the-Middle Attacks ....................... 41 5.10 Man-in-the-Middle Attacks ....................... 42
5.11 Denial of Service Attacks ....................... 41 5.11 Denial of Service Attacks ....................... 43
5.12 Impersonation ................................... 42 5.12 Impersonation ................................... 43
5.13 Channel Binding ................................. 43 5.13 Channel Binding ................................. 44
6. IANA Considerations ................................... 44 6. IANA Considerations ................................... 45
7. References ............................................ 44 7. References ............................................ 45
7.1 Normative References ............................ 44 7.1 Normative References ............................ 45
7.2 Informative References .......................... 45 7.2 Informative References .......................... 46
Acknowledgments .............................................. 49 Acknowledgments .............................................. 50
Author's Addresses ........................................... 49 Author's Addresses ........................................... 50
Appendix A - EAP-TLS Key Hierarchy ........................... 51 Appendix A - EAP-TLS Key Hierarchy ........................... 52
Appendix B - Exported Parameters in Existing Methods ......... 53 Appendix B - Exported Parameters in Existing Methods ......... 53
Intellectual Property Statement .............................. 54 Intellectual Property Statement .............................. 55
Disclaimer of Validity ....................................... 55 Disclaimer of Validity ....................................... 56
Copyright Statement .......................................... 55 Copyright Statement .......................................... 56
1. Introduction 1. Introduction
The Extensible Authentication Protocol (EAP), defined in [RFC3748], The Extensible Authentication Protocol (EAP), defined in [RFC3748],
was designed to enable extensible authentication for network access was designed to enable extensible authentication for network access
in situations in which the IP protocol is not available. Originally in situations in which the IP protocol is not available. Originally
developed for use with PPP [RFC1661], it has subsequently also been developed for use with PPP [RFC1661], it has subsequently also been
applied to IEEE 802 wired networks [IEEE-802.1X]. applied to IEEE 802 wired networks [IEEE-802.1X].
This document provides a framework for the generation, transport and This document provides a framework for the transport and usage of
usage of keying material generated by EAP authentication algorithms, keying material generated by EAP authentication algorithms, known as
known as "methods". In EAP keying material is generated by EAP "methods". In EAP, keying material is generated by EAP methods.
methods. Part of this keying material may be used by EAP methods Part of this keying material may be used by EAP methods themselves
themselves and part of this material may be exported. The exported and part of this material may be exported. The exported keying
keying material may be transported by AAA protocols or transformed by material may be transported by AAA protocols or used by Secure
Secure Association Protocols into session keys which are used by Association Protocols in the generation or transport of session keys
lower layer ciphersuites. This document describes each of these which are used by lower layer ciphersuites. This document describes
elements and provides a system-level security analysis. It also each of these elements and provides a system-level security analysis.
specifies the EAP key hierarchy. It also specifies the EAP key hierarchy.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119]. document are to be interpreted as described in BCP 14 [RFC2119].
1.2. Terminology 1.2. Terminology
This document frequently uses the following terms: This document frequently uses the following terms:
skipping to change at page 4, line 51 skipping to change at page 4, line 51
Initialization Vector (IV) Initialization Vector (IV)
A quantity of at least 64 octets, suitable for use in an A quantity of at least 64 octets, suitable for use in an
initialization vector field, that is derived between the peer and initialization vector field, that is derived between the peer and
EAP server. Since the IV is a known value in methods such as EAP- EAP server. Since the IV is a known value in methods such as EAP-
TLS [RFC2716], it cannot be used by itself for computation of any TLS [RFC2716], it cannot be used by itself for computation of any
quantity that needs to remain secret. As a result, its use has quantity that needs to remain secret. As a result, its use has
been deprecated and EAP methods are not required to generate it. been deprecated and EAP methods are not required to generate it.
However, when it is generated it MUST be unpredictable. However, when it is generated it MUST be unpredictable.
Pairwise Master Key (PMK) Pairwise Master Key (PMK)
The MSK is divided into two halves, the "Peer to Authenticator Lower layers use MSK in lower-layer dependent manner. For
Encryption Key" (Enc-RECV-Key) and "Authenticator to Peer instance, in [IEEE-802.11i] Octets 0-31 of the MSK are known as the
Encryption Key" (Enc-SEND-Key) (reception is defined from the point Pairwise Master Key (PMK). In [IEEE-802.11i] the TKIP and AES CCMP
of view of the authenticator). Within [IEEE-802.11i] Octets 0-31 ciphersuites derive their Transient Session Keys (TSKs) solely from
of the MSK (Enc-RECV-Key) are known as the Pairwise Master Key the PMK, whereas the WEP ciphersuite as noted in [RFC3580], derives
(PMK). In [IEEE-802.11i] the TKIP and AES CCMP ciphersuites derive its TSKs from both halves of the MSK. In [802.16e], the MSK is
their Transient Session Keys (TSKs) solely from the PMK, whereas truncated to 40 octets for PMK and 20 octets for PMK2.
the WEP ciphersuite as noted in [RFC3580], derives its TSKs from
both halves of the MSK.
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. An protect data sent between the EAP peer and authenticator. An
example TEK key hierarchy is described in Appendix A. example TEK key hierarchy is described in Appendix A.
Transient Session Keys (TSKs) Transient Session Keys (TSKs)
Session keys used to protect data exchanged in a session between Session keys used to protect data exchanged after EAP
the peer and authenticator after the EAP authentication has authentication has successfully completed, using the ciphersuite
successfully completed. TSKs are appropriate for the lower layer negotiated between the EAP peer and authenticator.
ciphersuite negotiated between the ports of the EAP peer and
authenticator. Examples of TSK derivation are provided in Appendix
B.
AAA-Key AAA-Key
A key derived by the peer and EAP server, used by the peer and The term AAA-Key is synonymous with MSK.
authenticator in the derivation of Transient Session Keys (TSKs).
Where a backend authentication server is present, the AAA-Key is
transported from the backend authentication server to the
authenticator. In existing usage, the AAA-Key is always derived
from the MSK and so can be referred to using the MSK name. AAA-Key
= MSK(0,63).
1.3. Overview 1.3. Overview
EAP, defined in [RFC3748], is a two-party protocol spoken between the EAP, defined in [RFC3748], is a two-party protocol spoken between the
EAP peer and server. Within EAP, keying material is generated by EAP EAP peer and server. Within EAP, keying material is generated by EAP
methods. Part of this keying material may be used by EAP methods methods. Part of this keying material may be used by EAP methods
themselves and part of this material may be exported. In addition to themselves and part of this material may be exported. In addition to
export of keying material, EAP methods may also export associated export of keying material, EAP methods may also export associated
parameters, and may import and export Channel Bindings from the lower parameters, and may import and export Channel Bindings from the lower
layer. layer.
As illustrated in Figure 1, the EAP method key derivation has at the As illustrated in Figure 1, the EAP method key derivation has at the
root the long term credential utilized by the selected EAP method. root the long term credential utilized by the selected EAP method.
If authentication is based on a pre-shared key, the parties store the If authentication is based on a pre-shared key, the parties store the
EAP method to be used and the pre-shared key. The EAP server also EAP method to be used and the pre-shared key. The EAP server also
stores the peer's identity and/or other information necessary to stores the peer's identity as well as other information associated
decide whether access to some service should be granted. The peer with it. This information may be used to determine whether access to
stores information necessary to choose which secret to use for which some service should be granted. The peer stores information necessary
service. to choose which secret to use for which service.
If authentication is based on proof of possession of the private key If authentication is based on proof of possession of the private key
corresponding to the public key contained within a certificate, the corresponding to the public key contained within a certificate, the
parties store the EAP method to be used and the trust anchors used to parties store the EAP method to be used and the trust anchors used to
validate the certificates. The EAP server also stores the peer's validate the certificates. The EAP server also stores the peer's
identity and/or other information necessary to decide whether access identity and the peer stores information necessary to choose which
to some service should be granted. The peer stores information certificate to use for which service.
necessary to choose which certificate to use for which service.
Based on the long term credential established between the peer and Based on the long term credential established between the peer and
the server, EAP methods derive two types of keys: the server, EAP methods derive two types of keys:
[1] Keys calculated locally by the EAP method but not exported [1] Keys calculated locally by the EAP method but not exported
by the EAP method, such as the TEKs. by the EAP method, such as the TEKs.
[2] Keying material exported by the EAP method: MSK, EMSK, IV. [2] Keying material exported by the EAP method: MSK, EMSK, IV.
As noted in [RFC3748] Section 7.10, EAP methods generating keys are As noted in [RFC3748] Section 7.10, EAP methods generating keys are
required to calculate and export the MSK and EMSK, which must be at required to calculate and export the MSK and EMSK, which must be at
least 64 octets in length. EAP methods also may export the IV; least 64 octets in length. EAP methods also may export the IV;
however, the use of the IV is deprecated. however, the use of the IV is deprecated.
EAP methods also MAY export method-specific peer and server 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 Method-ID, and the lifetime of conversation identifier known as the Method-ID, and the lifetime of
the exported keys, known 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. endpoints of the EAP method exchange.
Peer-ID
As described in [RFC3748] Section 7.3, the identity provided in the
EAP-Response/Identity, may be different from the peer identity
authenticated by the EAP method. Where the EAP method authenticates
the peer identity, that identity is exported by the method as the
Peer-ID. A suitable EAP peer name may not always be available.
Where an EAP method does not define a method-specific peer identity,
the Peer-ID is the null string. The Peer-ID for existing EAP
methods is defined in Appendix B.
Server-ID
Where the EAP method authenticates the server identity, that identity
is exported by the method as the Server-ID. A suitable EAP server
name may not always be available. Where an EAP method does not
define a method-specific peer identity, the Server-ID is the null
string. The Server-ID for existing EAP methods is defined in
Appendix B.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | ^ | | ^
| EAP Method | | | EAP Method | |
| | | | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | |
| | | | | | | | | | | | | |
| | EAP Method Key |<->| Long-Term | | | | | EAP Method Key |<->| Long-Term | | |
| | Derivation | | Credential | | | | | Derivation | | Credential | | |
| | | | | | | | | | | | | |
| | | +-+-+-+-+-+-+-+ | Local to | | | | +-+-+-+-+-+-+-+ | Local to |
| | | | EAP | | | | | EAP |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Method | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Method |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | | | | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | |
| | | TEK | |MSK, EMSK | |IV | | | | | | TEK | |MSK, EMSK | |IV | | |
| | |Derivation | |Derivation | |Derivation | | | | | |Derivation | |Derivation | |Derivation | | |
| | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | | | | | | | | |(Deprecated) | | |
| | | | | | | | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | |
| | ^ | | | V | | ^ | | | |
+-+-|-+-+-+-+-+-+-+-+-|-+-+-+-+-+-|-+-+-+-+-+-+-+-+-|-+-+-+ ---+ | | | | | | V
+-+-|-+-+-+-+-+-+-+-+-|-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+ ---+
| | | | ^ | | | | ^
| Peer-ID, | | | Exported| | Peer-ID, | | | Exported|
| Server-ID, | Channel | MSK (64+B) | IV (64B) by | | Server-ID, | Channel | MSK (64+B) | IV (64B) by |
| Method-ID, | Bindings | EMSK (64+B) | EAP | | Method-ID, | Bindings | EMSK (64+B) | (Optional) EAP |
| Key-Lifetime | & Result | | Method | | Key-Lifetime | & Result | | Method |
V V V V V V V V V V
Figure 1: EAP Method Parameter Import/Export Figure 1: EAP Method Parameter Import/Export
Peer-ID
As described in [RFC3748] Section 7.3, the identity provided in the
EAP-Response/Identity, may be different from the peer identity
authenticated by the EAP method. Where the EAP method authenticates
the peer identity, that identity is exported by the method as the
Peer-ID. A suitable EAP peer name may not always be available.
Where an EAP method does not define a method-specific peer identity,
the Peer-ID is the null string. The Peer-ID for existing EAP
methods is defined in Appendix B.
Server-ID
Where the EAP method authenticates the server identity, that identity
is exported by the method as the Server-ID. A suitable EAP server
name may not always be available. Where an EAP method does not
define a method-specific peer identity, the Server-ID is the null
string. The Server-ID for existing EAP methods is defined in
Appendix B.
Method-ID Method-ID
EAP method specifications deriving keys MUST specify a temporally EAP method specifications deriving keys MUST specify a temporally
unique method identifier known as the Method-ID. The EAP Method-ID unique method identifier known as the Method-ID. The EAP Method-ID
uniquely identifies an EAP session of a given Type between an EAP uniquely identifies an EAP session of a given Type between an EAP
peer and server. The Method-ID is typically constructed from nonces peer and server. The Method-ID is typically constructed from nonces
or counters used within the EAP method exchange. The Method-ID for or counters used within the EAP method exchange. The Method-ID for
existing EAP methods is defined in Appendix B. existing EAP methods is defined in Appendix B.
Session-ID Session-ID
skipping to change at page 9, line 14 skipping to change at page 8, line 42
1.3.1. Key Naming 1.3.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, EMSK and IV 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
skipping to change at page 11, line 36 skipping to change at page 11, line 18
acceptable security for the media in use. For example, the [RFC3748] acceptable security for the media in use. For example, the [RFC3748]
mandatory-to-implement EAP method (MD5-Challenge) does not provide mandatory-to-implement EAP method (MD5-Challenge) does not provide
dictionary attack resistance, mutual authentication or key dictionary attack resistance, mutual authentication or key
derivation, and as a result is not appropriate for use in wireless derivation, and as a result is not appropriate for use in wireless
LAN authentication [RFC4017]. However, despite this it is possible LAN authentication [RFC4017]. However, despite this it is possible
for the peer and authenticator to interoperate as long as a suitable for the peer and authenticator to interoperate as long as a suitable
EAP method is supported on the EAP server. EAP method is supported on the EAP server.
1.4.4. Ciphersuite Independence 1.4.4. Ciphersuite Independence
Ciphersuite Independence is a consequence of the principles of Mode Ciphersuite Independence is a requirement for Media Independence.
Independence and Media Independence. Since lower layer ciphersuites vary between media, media independence
requires that EAP keying material needs to be large enough (with
sufficient entropy) to handle any ciphersuite.
While EAP methods may negotiate the ciphersuite used in protection of While EAP methods may negotiate the ciphersuite used in protection of
the EAP conversation, the ciphersuite used for the protection of the the EAP conversation, the ciphersuite used for the protection of the
data exchanged after EAP authentication has completed is negotiated data exchanged after EAP authentication has completed is negotiated
between the peer and authenticator within the lower layer, outside of between the peer and authenticator within the lower layer, outside of
EAP. EAP.
For example, within PPP, the ciphersuite is negotiated within the For example, within PPP, the ciphersuite is negotiated within the
Encryption Control Protocol (ECP) defined in [RFC1968], after EAP Encryption Control Protocol (ECP) defined in [RFC1968], after EAP
authentication is completed. Within [IEEE-802.11i], the AP authentication is completed. Within [IEEE-802.11i], the AP
skipping to change at page 13, line 38 skipping to change at page 13, line 16
The authentication phase (phase 1) may begin once the peer and The authentication phase (phase 1) may begin once the peer and
authenticator discover each other. This phase, if it occurs, always authenticator discover each other. This phase, if it occurs, always
includes EAP authentication (phase 1a). Where the chosen EAP method includes EAP authentication (phase 1a). Where the chosen EAP method
supports key derivation, in phase 1a EAP keying material is derived supports key derivation, in phase 1a EAP keying material is derived
on both the peer and the EAP server. on both the peer and the EAP server.
An additional step (phase 1b) is required in deployments which An additional step (phase 1b) is required in deployments which
include a backend authentication server, in order to transport keying include a backend authentication server, in order to transport keying
material from the backend authentication server to the authenticator. material from the backend authentication server to the authenticator.
In order to obey the principle of Mode Independence, where a backend In order to obey the principle of Mode Independence, where a backend
server is present AAA Key transport needs to provide the exported EAP server is present, all keying material which us required by the lower
keying material and/or derived keys required for derivation of the layer needs to be transported from the EAP server to the
TSKs. Since existing TSK derivation techniques depend solely on the authenticator. Since existing TSK derivation techniques depend
MSK, in existing AAA implementations, this is the only keying solely on the MSK, in existing implementations, this is the only
material replicated in the AAA key transport phase 1b. keying material replicated in the AAA key transport phase 1b.
Successful completion of EAP authentication and key derivation by a Successful completion of EAP authentication and key derivation by a
peer and EAP server does not necessarily imply that the peer is peer and EAP server does not necessarily imply that the peer is
committed to joining the network associated with an EAP server. committed to joining the network associated with an EAP server.
Rather, this commitment is implied by the creation of a security Rather, this commitment is implied by the creation of a security
association between the EAP peer and authenticator, as part of the association between the EAP peer and authenticator, as part of the
Secure Association Protocol (phase 2). Secure Association Protocol (phase 2).
The Secure Association exchange (phase 2) occurs between the peer and The Secure Association exchange (phase 2) occurs between the peer and
authenticator in order to manage the creation and deletion of unicast authenticator in order to manage the creation and deletion of unicast
(phase 2a) and multicast (phase 2b) security associations between the (phase 2a) and multicast (phase 2b) security associations between the
peer and authenticator. The conversation between the parties is peer and authenticator. The conversation between the parties is
shown in Figure 2. shown in Figure 2.
2.2. Layering
In completion of EAP authentication, EAP methods on the peer and EAP
server export the Master Session Key (MSK), Extended Master Session
Key (EMSK), Initialization Vector (IV), Peer-ID, Server-ID, Session-
ID and Key-Lifetime. As illustrated in Figure 3, EAP methods export
keying material and parameters to the EAP peer or authenticator
layers.
The EAP peer and authenticator layers MUST NOT modify or cache keying
material or parameters (including Channel Bindings) passing in either
direction between the EAP method layer and the EAP layer. The EAP
layer also MUST NOT cache keying material or parameters (including
Channel Bindings) passed to it by the EAP peer/authenticator layer or
the lower layer.
EAP peer Authenticator Auth. Server EAP peer Authenticator Auth. Server
-------- ------------- ------------ -------- ------------- ------------
|<----------------------------->| | |<----------------------------->| |
| Discovery (phase 0) | | | Discovery (phase 0) | |
|<----------------------------->|<----------------------------->| |<----------------------------->|<----------------------------->|
| EAP auth (phase 1a) | AAA pass-through (optional) | | EAP auth (phase 1a) | AAA pass-through (optional) |
| | | | | |
| |<----------------------------->| | |<----------------------------->|
| | AAA Key transport | | | AAA Key transport |
| | (optional; phase 1b) | | | (optional; phase 1b) |
skipping to change at page 14, line 29 skipping to change at page 14, line 26
| Unicast Secure association | | | Unicast Secure association | |
| (phase 2a) | | | (phase 2a) | |
| | | | | |
|<----------------------------->| | |<----------------------------->| |
| Multicast Secure association | | | Multicast Secure association | |
| (optional; phase 2b) | | | (optional; phase 2b) | |
| | | | | |
Figure 2: Conversation Overview Figure 2: Conversation Overview
2.2. Layering
In completion of EAP authentication, EAP methods on the peer and EAP
server export the Master Session Key (MSK), Extended Master Session
Key (EMSK), Initialization Vector (IV), Peer-ID, Server-ID, Session-
ID and Key-Lifetime. As illustrated in Figure 3, EAP methods export
keying material and parameters to the EAP peer or authenticator
layers.
The EAP peer and authenticator layers MUST NOT modify or cache keying
material or parameters (including Channel Bindings) passing in either
direction between the EAP method layer and the EAP layer. The EAP
layer also MUST NOT cache keying material or parameters (including
Channel Bindings) passed to it by the EAP peer/authenticator layer or
the lower layer.
Based on the Method-ID exported by the EAP method, the EAP layer Based on the Method-ID exported by the EAP method, the EAP layer
forms the EAP Session-ID by concatenating the EAP Expanded Type with forms the EAP Session-ID by concatenating the EAP Expanded Type with
the Method-ID. Together with the MSK, IV (deprecated), Peer-ID, the Method-ID. Together with the MSK, IV (deprecated), Peer-ID,
Server-ID, and Key-Lifetime, the EAP layer passes the Session-ID down Server-ID, and Key-Lifetime, the EAP layer passes the Session-ID down
to the lower layer. to the lower layer. The Method-ID is exported by EAP methods rather
than the Session-ID so as to prevent EAP methods from writing into
each other's Session- ID space.
The EMSK MUST NOT be provided to the lower layer, nor is it permitted The EMSK MUST NOT be provided to the lower layer, nor is it permitted
to pass any quantity to the lower layer from which the EMSK could be to pass any quantity to the lower layer from which the EMSK could be
computed without breaking some cryptographic assumption, such as computed without breaking some cryptographic assumption, such as
inverting a one-way function. As noted in [RFC3748] Section 7.10: inverting a one-way function. As noted in [RFC3748] Section 7.10:
The EMSK is reserved for future use and MUST remain on the EAP The EMSK is reserved for future use and MUST remain on the EAP
peer and EAP server where it is derived; it MUST NOT be peer and EAP server where it is derived; it MUST NOT be
transported to, or shared with, additional parties, or used to transported to, or shared with, additional parties, or used to
derive any other keys. (This restriction will be relaxed in a derive any other keys. (This restriction will be relaxed in a
future document that specifies how the EMSK can be used.) future document that specifies how the EMSK can be used.)
The Method-ID is exported by EAP methods rather than the Session-ID
so as to prevent EAP methods from writing into each other's Session-
ID space.
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 other than AAA MUST NOT export keys passed down by EAP lower layers other than AAA MUST NOT export keys passed down by EAP
methods. This implies that EAP keying material or parameters passed methods. This implies that EAP keying material or parameters passed
down to a lower layer are for the exclusive use of that lower layer down to a lower layer are for the exclusive use of that lower layer
and MUST NOT be used within another lower layer. This prevents and MUST NOT be used within another lower layer. This prevents
compromise of one lower layer from compromising other applications compromise of one lower layer from compromising other applications
using EAP keying parameters. using EAP keying parameters.
EAP keying material and parameters provided to a lower layer other EAP keying material and parameters provided to a lower layer other
than AAA MUST NOT be transported to another entity. For example, EAP than AAA MUST NOT be transported to another entity. For example, EAP
skipping to change at page 15, line 48 skipping to change at page 15, line 27
conversation took place. This enables "mode independence" to be conversation took place. This enables "mode independence" to be
maintained. maintained.
As illustrated in Figure 4, a AAA client receiving transported EAP As illustrated in Figure 4, a AAA client receiving transported EAP
keying material and parameters passes them to the EAP authenticator keying material and parameters passes them to the EAP authenticator
and EAP layers, which then provide them to the authenticator lower and EAP layers, which then provide them to the authenticator lower
layer using the same mechanisms that would be used if the EAP peer layer using the same mechanisms that would be used if the EAP peer
and authenticator were conducting a stand-alone conversation. The and authenticator were conducting a stand-alone conversation. The
resulting key state in the lower layer is indistinguishable between resulting key state in the lower layer is indistinguishable between
the standalone and pass-through cases, as required by the principle the standalone and pass-through cases, as required by the principle
of mode independence. In order to prevent the compromise of of mode independence.
transported EAP keying material and parameters, the AAA client and
EAP authenticator MUST be co-resident. 2.3. Transient Session Keys
Where explicitly supported by the lower layer, lower layers MAY cache
the exported EAP keying material and parameters and/or TSKs. The
structure of this key cache is defined by the lower layer. So as to
enable interoperability, new lower layer specifications MUST
describe EAP key caching behavior. Unless explicitly specified by
the lower layer, the EAP peer, server and authenticator MUST assume
that peers and authenticators do not cache exported EAP keying
parameters or TSKs. Existing EAP lower layers handle the caching of
EAP keying material and the generation of transient session keys in
different ways:
PPP PPP, defined in [RFC1661] does not support caching of EAP keying
material or parameters. PPP ciphersuites derive their TSKs
directly from the MSK, as described in [RFC2716]. This method is
NOT RECOMMENDED, since were PPP to support caching, this could
result in stale TSKs. As a result, once the PPP session is
terminated, EAP keying material and parameters MUST be discarded.
Since caching of EAP keying material is not permitted, within PPP
there is no way to handle TSK rekey without EAP re-authentication.
Perfect Forward Secrecy (PFS) is only possible within PPP if the
negotiated EAP method supports this.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
| EAP method | | EAP method |
| | | |
| MSK, EMSK, IV, Channel | | MSK, EMSK, Peer-ID, Channel |
| Peer-ID, Server-ID, Bindings | | Server-ID, Method-ID Bindings |
| Method-ID, | | IV (deprecated), |
| Key-Lifetime | | Key-Lifetime |
| | | |
| V ^ ^ | | V ^ ^ |
+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+
| ! ! ! | | ! ! ! |
| EAP ! Peer or Authenticator ! ! | | EAP ! Peer or Authenticator ! ! |
| ! layer ! ! | | ! layer ! ! |
| ! ! ! | | ! ! ! |
+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+
| ! ! ! | | ! ! ! |
skipping to change at page 16, line 34 skipping to change at page 16, line 34
| ! ! ! | | ! ! ! |
| ! Session-ID = ! ! | | ! Session-ID = ! ! |
| ! Expanded-Type || ! ! | | ! Expanded-Type || ! ! |
| ! Method-ID ! ! | | ! Method-ID ! ! |
| ! ! ! | | ! ! ! |
+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+
| ! ! ! | | ! ! ! |
| Lower ! layer ! ! | | Lower ! layer ! ! |
| ! ! ! | | ! ! ! |
| V V ^ | | V V ^ |
| MSK, IV, Peer-ID, Channel Result | | MSK, Peer-ID, Channel Result |
| Server-ID, Bindings | | Server-ID, Bindings |
| Session-ID, | | Session-ID, |
| Key-Lifetime | | Key-Lifetime, |
| IV (deprecated) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Flow of EAP parameters Figure 3: Flow of EAP parameters
Peer Pass-through Authenticator Authentication Peer Pass-through Authenticator Authentication
Server Server
+-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+
| | | | | | | |
|EAP method | |EAP method | |EAP method | |EAP method |
| V | | V | | V | | V |
skipping to change at page 17, line 31 skipping to change at page 17, line 31
| V | | V | ! | | ! | | V | | V | ! | | ! |
|Lower layer| | Lower layer| AAA ! /IP | | AAA ! /IP | |Lower layer| | Lower layer| AAA ! /IP | | AAA ! /IP |
| | | | ! | | ! | | | | | ! | | ! |
+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+
! ! ! !
! ! ! !
+---------<-------+ +---------<-------+
Figure 4: Flow of EAP Keying Material and Parameters Figure 4: Flow of EAP Keying Material and Parameters
2.3. Caching
Where explicitly supported by the lower layer, lower layers MAY cache
the exported EAP keying material and parameters and/or TSKs. The
structure of this key cache is defined by the lower layer. So as to
enable interoperability, new lower layer specifications MUST
describe EAP key caching behavior. Unless explicitly specified by
the lower layer, the EAP peer, server and authenticator MUST assume
that peers and authenticators do not cache exported EAP keying
parameters or TSKs.
The caching behavior of existing EAP lower layers is as follows:
PPP PPP, defined in [RFC1661] does not support caching of EAP keying
material or parameters. Since PPP ciphersuites derive their TSKs
directly from the MSK as described in [RFC2716], were PPP to
support caching, this could result in stale TSKs. Therefore once
the PPP session is terminated, it is assumed that EAP keying
material and parameters are discarded.
IKEv2 IKEv2
IKEv2, defined in [IKEv2] only uses EAP keying material for IKEv2, defined in [IKEv2] only uses EAP keying material for
authentication purposes and not key derivation. As a result, IKEv2 authentication purposes and not key derivation. As a result, the
keying material derived within IKEv2 is independent of the EAP
keying material and rekey of IPsec SAs can be handled without
requiring EAP re-authentiation. Since generation of keying
material is independent of EAP, within IKEv2 it is possible to
negotiate PFS, regardless of the EAP method that is used. IKEv2
does not cache EAP keying material or parameters, nor does it does not cache EAP keying material or parameters, nor does it
utilize the Key-Lifetime to determine the lifetime of IPsec SAs. utilize the EAP Key-Lifetime parameter to determine the lifetime of
As result, once IKEv2 authentication completes it is assumed that IPsec SAs. As a result, once IKEv2 authentication completes it is
EAP keying material and parameters are discarded. assumed that EAP keying material and parameters are discarded.
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, Session-ID, or Key-Lifetime. More details are Peer-ID, Server-ID, or Session-ID. More details about the
about the structure of the cache are available in [IEEE-802.11i]. 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,
which includes a nonce exchange. This guarantees TSK freshness
even if the MSK is reused. The 4-way handshake also enables TSK
rekey without EAP re-authentication. PFS is only possible within
IEEE 802.11i if the negotiated EAP method supports this.
IEEE 802.1X-2004 IEEE 802.1X-2004
IEEE 802.1X-2004, defined in [IEEE-802.1X-2004] does not support IEEE 802.1X-2004, defined in [IEEE-802.1X-2004] does not support
caching of EAP keying material or parameters. Therefore once EAP caching of EAP keying material or parameters. Once EAP
authentication completes, it is assumed that EAP keying material authentication completes, it is assumed that EAP keying material
and parameters are discarded. and parameters are discarded.
AAA Existing AAA servers supporting RADIUS/EAP [RFC3579] or Diameter IEEE 802.16e
EAP [RFC4207] do not support caching of EAP keying material or IEEE 802.16e, defined in [IEEE-802.16e] supports caching of the
parameters. In existing AAA server implementations, exported EAP MSK, but not the EMSK, IV, Peer-ID, Server-ID or Session-ID. In
keying material (MSK, EMSK and IV) as well as parameters and IEEE 802.16e, TSKs are generated by the authenticator without any
derived keys are not cached and MUST be presumed lost after the AAA contribution by the peer. The TSKs are encrypted, authenticated
exchange completes. and integrity protected using the MSK. As a result, TSK rekey is
possible without EAP re-authentication. PFS is not possible even
if the negotiated EAP method supports it.
AAA Existing AAA implementations supporting RADIUS/EAP [RFC3579] or
Diameter EAP [RFC4072] do not support caching of EAP keying
material or parameters. In existing AAA client, proxy and server
implementations, exported EAP keying material (MSK, EMSK and IV) as
well as parameters and derived keys are not cached and MUST be
presumed lost after the AAA exchange completes.
In order to avoid key reuse, the AAA layer MUST delete transported In order to avoid key reuse, the AAA layer MUST delete 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 to the authenticator. For example, a AAA it has previously sent. For example, a AAA layer that has
layer that has transported the MSK MUST delete it, and keys MUST transported the MSK MUST delete it, and keys MUST NOT be derived
NOT be derived from the MSK from that point forward. from the MSK from that point forward.
2.4. Key Scope 2.4. Key Scope
It should be understood that an EAP authenticator or peer: 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.
skipping to change at page 20, line 20 skipping to change at page 20, line 18
therefore needs to be considered compromised. There is also a therefore needs to be considered compromised. There is also a
practical problem because the EAP peer will be unable to utilize the practical problem because the EAP peer will be unable to utilize the
EAP authenticator key cache in an efficient way. EAP authenticator key cache in an efficient way.
The solution to this problem is for lower layers to identify EAP The solution to this problem is for lower layers to identify EAP
peers and authenticators unambiguously, without incorporating peers and authenticators unambiguously, without incorporating
implicit assumptions about peer and authenticator architectures. Use implicit assumptions about peer and authenticator architectures. Use
of port identifiers is NOT RECOMMENDED where peers and authenticators of port identifiers is NOT RECOMMENDED where peers and authenticators
may support multiple ports. may support multiple ports.
AAA protocols such as RADIUS [RFC3579] and Diameter [RFC4072] provide
a mechanism for the identification of AAA clients; since the EAP
authenticator and AAA client are always co-resident, this mechanism
can be applied to the identification of EAP authenticators.
RADIUS requires that an Access-Request packet contain one or more of
the NAS-Identifier, NAS-IP-Address and NAS-IPv6-Address attributes.
Since a NAS may have more than one IP address associated with it, the
NAS-Identifier attribute is RECOMMENDED for the unambiguous
identification of the EAP authenticator.
From the point of view of the AAA server, EAP keying material and
parameters are transported to the NAS identified by the NAS-
Identifier attribute. Since the NAS/ EAP authenticator MUST NOT
share EAP keying material or parameters with another party, if the
EAP peer or AAA server detects use of EAP keying material and
parameters outside the scope defined by the NAS-Identifier, the
keying material MUST be considered compromised.
In order to further limit the key scope the following measures are In order to further limit the key scope the following measures are
suggested: suggested:
[a] The lower layer MAY specify additional restrictions on key usage, [a] The lower layer MAY specify additional restrictions on key usage,
such as limiting the use of EAP keying material and parameters on such as limiting the use of EAP keying material and parameters on
the EAP peer to the port over which on the EAP conversation was the EAP peer to the port over which on the EAP conversation was
conducted. conducted.
[b] The AAA server and client/authenticator MAY implement additional [b] The backend authentication server and authenticator MAY implement
attributes in order to further restrict the scope of EAP keying additional attributes in order to further restrict the scope of EAP
material. For example, in 802.11, the AAA server may provide the keying material. For example, in 802.11, the backend
authenticator with a list of authorized Called or Calling-Station- authentication server may provide the authenticator with a list of
Ids and/or SSIDs for which EAP keying material is valid. authorized Called or Calling-Station-Ids and/or SSIDs for which EAP
keying material is valid.
[c] Where the AAA server provides attributes restricting the key scope, [c] Where the backend authentication server provides attributes
it is RECOMMENDED that restrictions be securely communicated by the restricting the key scope, it is RECOMMENDED that restrictions be
authenticator to the peer. This can be accomplished using the securely communicated by the authenticator to the peer. This can
Secure Association Protocol, but also can be accomplished via the be accomplished using the Secure Association Protocol, but also
EAP method or the lower layer. can be accomplished via the EAP method or the lower layer.
2.4.2. Virtual Authenticators 2.4.2. Authenticator Architecture
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.
Since an authenticator may have many ports, the authenticator
identifier used within the Secure Association Protocol exchange
SHOULD be distinct from any port identifier (e.g. MAC address).
Similarly, where a peer may have multiple ports, and sharing of EAP
keying material and parameters between peer ports of the same link
type is allowed, the peer identifier used within the Secure
Association Protocol exchange SHOULD also be distinct from any port
identifier.
While EAP Keying Material passed down to the lower layer is not
intrinsically bound to particular authenticator and peer ports,
Transient Session Keys MAY be bound to particular authenticator and
peer ports by the Secure Association Protocol. However, a lower
layer MAY also permit TSKs to be used on multiple peer and/or
authenticator ports, providing that TSK freshness is guaranteed (such
as by keeping replay counter state within the authenticator).
This specification does not impose constraints on the architecture of
the EAP authenticator or peer. Any of the authenticator
architectures described in [RFC4118] can be used. 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.
AAA protocols such as RADIUS [RFC3579] and Diameter [RFC4072] provide
a mechanism for the identification of AAA clients; since the EAP
authenticator and AAA client are always co-resident, this mechanism
is applicable to the identification of EAP authenticators.
RADIUS [RFC2865] requires that an Access-Request packet contain one
or more of the NAS-Identifier, NAS-IP-Address and NAS-IPv6-Address
attributes. Since a NAS may have more than one IP address, the NAS-
Identifier attribute is RECOMMENDED for the unambiguous
identification of the EAP authenticator.
From the point of view of the AAA server, EAP keying material and
parameters are transported to the EAP authenticator identified by the
NAS-Identifier attribute. Since an EAP authenticator MUST NOT share
EAP keying material or parameters with another party, if the EAP peer
or AAA server detects use of EAP keying material and parameters
outside the scope defined by the NAS-Identifier, the keying material
MUST be considered compromised.
2.4.3. 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 also may not "virtual authenticators", the EAP peer and authenticator also may not
be able to agree on the scope of the EAP keying material, creating a be able to agree on the scope of the EAP keying material, creating a
security vulnerability. For example, the peer may assume that the security vulnerability. For example, the peer may assume that the
"virtual authenticators" are distinct and do not share a key cache, "virtual authenticators" are distinct and do not share a key cache,
whereas, depending on the architecture of the physical authenticator, whereas, depending on the architecture of the physical authenticator,
a shared key cache may or may not be implemented. a shared key cache may or may not be implemented.
Where EAP keying material is shared between "virtual authenticators" Where EAP keying material is shared between "virtual authenticators"
skipping to change at page 21, line 40 skipping to change at page 22, line 28
[d] Authenticators are REQUIRED to cache associated authorizations [d] Authenticators are REQUIRED to cache associated authorizations
along with EAP keying material and parameters and to apply along with EAP keying material and parameters and to apply
authorizations consistently. This ensures that an attacker cannot authorizations consistently. This ensures that an attacker cannot
obtain elevated privileges even where the key cache is shared obtain elevated privileges even where the key cache is shared
between "virtual authenticators". between "virtual authenticators".
[e] It is RECOMMENDED that physical authenticators maintain separate [e] It is RECOMMENDED that physical authenticators maintain separate
key caches for each "virtual authenticator". key caches for each "virtual authenticator".
[f] It is RECOMMENDED that each "virtual authenticator" identify itself [f] It is RECOMMENDED that each "virtual authenticator" identify itself
distinctly to the AAA server, such as by utilizing a distinct NAS- distinctly to the backend authentication server, such as by
Identifier attribute. This enables the AAA server to utilize a utilizing a distinct NAS-Identifier attribute. This enables the
separate credential to authenticate each "virtual authenticator". backend authentication server to utilize a separate credential to
authenticate each "virtual authenticator".
3. Key Management 3. Key Management
EAP as defined in [RFC3748] supports key derivation, but not key EAP as defined in [RFC3748] supports key derivation, but not key
management. While EAP methods may derive keying material, EAP does management. While EAP methods may derive keying material, EAP does
not provide for the management of exported or derived keys. For not provide for the management of exported or derived keys. For
example, EAP does not support negotiation of the key lifetime of example, EAP does not support negotiation of the key lifetime of
exported or derived keys, nor does it support re-key. Although EAP exported or derived keys, nor does it support re-key. Although EAP
methods may support "fast reconnect" as defined in [RFC3748] Section methods may support "fast reconnect" as defined in [RFC3748] Section
7.2.1, re-key of exported keys cannot occur without re- 7.2.1, re-key of exported keys cannot occur without re-
skipping to change at page 22, line 27 skipping to change at page 23, line 18
exchange are not identified and the scope of the EAP keying exchange are not identified and the scope of the EAP keying
parameters negotiated during the EAP exchange is undefined. As parameters negotiated during the EAP exchange is undefined. As
shown in Figure 5, both the peer and authenticator may have more shown in Figure 5, both the peer and authenticator may have more
than one physical or virtual port, and as a result SHOULD identify than one physical or virtual port, and as a result SHOULD identify
themselves in a manner that is independent of their attached ports. themselves in a manner that is independent of their attached ports.
[b] Mutual proof of possession of EAP keying material. During the [b] Mutual proof of possession of EAP keying material. During the
Secure Association Protocol the EAP peer and authenticator MUST Secure Association Protocol the EAP peer and authenticator MUST
demonstrate possession of the keying material transported between demonstrate possession of the keying material transported between
the backend authentication server and authenticator (e.g. MSK), in the backend authentication server and authenticator (e.g. MSK), in
order to demonstrate that the peer and authenticator have been and 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.
[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
skipping to change at page 26, line 11 skipping to change at page 26, line 49
EMSK, and may optionally generate the IV. However, EAP, defined in EMSK, and may optionally generate the IV. However, EAP, defined in
[RFC3748], does not support the negotiation of lifetimes for exported [RFC3748], does not support the negotiation of lifetimes for exported
keying material such as the MSK, EMSK and IV. keying material such as the MSK, EMSK and IV.
Several mechanisms exist for managing key lifetimes: Several mechanisms exist for managing key lifetimes:
[a] AAA attributes. AAA protocols such as RADIUS [RFC2865] and [a] AAA attributes. AAA protocols such as RADIUS [RFC2865] and
Diameter [RFC4072] support the Session-Timeout attribute. The Diameter [RFC4072] support the Session-Timeout attribute. The
Session-Timeout value represents the maximum lifetime of the Session-Timeout value represents the maximum lifetime of the
exported keys, and all keys calculated from it, on the exported keys, and all keys calculated from it, on the
authenticator. Since existing AAA servers do not cache keys authenticator. Since existing backend authentication servers do
exported by EAP methods, or keys calculated from exported keys, the not cache keys exported by EAP methods, or keys calculated from
value of the Session-Timeout attribute has no bearing on the key exported keys, the value of the Session-Timeout attribute has no
lifetime within the AAA server. bearing on the key lifetime within the backend authentication
server.
On the authenticator, where EAP is used for authentication, the On the authenticator, where EAP is used for authentication, the
Session-Timeout value represents the maximum session time prior to Session-Timeout value represents the maximum session time prior to
re-authentication, as described in [RFC3580]. Where EAP is used re-authentication, as described in [RFC3580]. Where EAP is used
for pre-authentication, the session may not start until some future for pre-authentication, the session may not start until some future
time, or may never occur. Nevertheless, the Session-Timeout value time, or may never occur. Nevertheless, the Session-Timeout value
represents the time after which transported EAP keying material, represents the time after which transported EAP keying material,
and all keys calculated from it, will have expired on the and all keys calculated from it, will have expired on the
authenticator. If the session subsequently starts, re- authenticator. If the session subsequently starts, re-
authentication will be initiated once the Session-Time has expired. authentication will be initiated once the Session-Time has expired.
If the session never started, or started and ended, by default keys If the session never started, or started and ended, by default keys
transported by AAA and all keys calculated from them will be transported by AAA and all keys calculated from them will be
expired by the authenticator prior to the future time indicated by expired by the authenticator prior to the future time indicated by
Session-Timeout. Session-Timeout.
Since the TSK lifetime is often determined by authenticator Since the TSK lifetime is often determined by authenticator
resources, the AAA server has no insight into the TSK derivation resources, the backend authentication server has no insight into
process, and by the principle of ciphersuite independence, it is the TSK derivation process, and by the principle of ciphersuite
not appropriate for the AAA server to manage any aspect of the TSK independence, it is not appropriate for the backend authentication
derivation process, including the TSK lifetime. server to manage any aspect of the TSK derivation process,
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
skipping to change at page 29, line 18 skipping to change at page 30, line 14
4. Handoff Vulnerabilities 4. Handoff Vulnerabilities
With EAP, a number of mechanisms are be utilized in order to reduce With EAP, a number of mechanisms are be utilized in order to reduce
the latency of handoff between authenticators. One such mechanism is the latency of handoff between authenticators. One such mechanism is
EAP pre-authentication, in which EAP is utilized to pre-establish EAP EAP pre-authentication, in which EAP is utilized to pre-establish EAP
keying material on an authenticator prior to arrival of the peer. keying material on an authenticator prior to arrival of the peer.
Another such mechanism is key caching, in which an EAP peer can re- Another such mechanism is key caching, in which an EAP peer can re-
attach to an authenticator without having to re-authenticate using attach to an authenticator without having to re-authenticate using
EAP. Yet another mechanism is context transfer, such as is defined EAP. Yet another mechanism is context transfer, such as is defined
in [IEEE-802.11F] and [CTP]. These mechanisms introduce new security in [IEEE-802.11F] (now deprecated) and [CTP]. These mechanisms
vulnerabilities, as discussed in the sections that follow. introduce new security vulnerabilities, as discussed in the sections
that follow.
4.1. Authorization 4.1. Authorization
In a typical network access scenario (dial-in, wireless LAN, etc.) In a typical network access scenario (dial-in, wireless LAN, etc.)
access control mechanisms are typically applied. These mechanisms access control mechanisms are typically applied. These mechanisms
include user authentication as well as authorization for the offered include user authentication as well as authorization for the offered
service. service.
As a part of the authentication process, the AAA network determines As a part of the authentication process, the backend authentication
the user's authorization profile. The user authorizations are server determines the user's authorization profile. The user
transmitted by the backend authentication server to the EAP authorizations are transmitted by the backend authentication server
authenticator (also known as the Network Access Server or to the EAP authenticator (also known as the Network Access Server or
authenticator) included with the AAA-Token, which also contains the authenticator) and with the transported EAP keying material, in Phase
transported EAP keying material, in Phase 1b of the EAP conversation. 1b of the EAP conversation. Typically, the profile is determined
Typically, the profile is determined based on the user identity, but based on the user identity, but a certificate presented by the user
a certificate presented by the user may also provide authorization may also provide authorization information.
information.
The backend authentication server is responsible for making a user The backend authentication server is responsible for making a user
authorization decision, answering the following questions: authorization decision, answering the following questions:
[a] Is this a legitimate user for this particular network? [a] Is this a legitimate user for this particular network?
[b] Is this user allowed the type of access he or she is requesting? [b] Is this user allowed the type of access he or she is requesting?
[c] Are there any specific parameters (mandatory tunneling, bandwidth, [c] Are there any specific parameters (mandatory tunneling, bandwidth,
filters, and so on) that the access network should be aware of for filters, and so on) that the access network should be aware of for
skipping to change at page 30, line 7 skipping to change at page 31, line 4
[c] Are there any specific parameters (mandatory tunneling, bandwidth, [c] Are there any specific parameters (mandatory tunneling, bandwidth,
filters, and so on) that the access network should be aware of for filters, and so on) that the access network should be aware of for
this user? this user?
[d] Is this user within the subscription rules regarding time of day? [d] Is this user within the subscription rules regarding time of day?
[e] Is this user within his limits for concurrent sessions? [e] Is this user within his limits for concurrent sessions?
[f] Are there any fraud, credit limit, or other concerns that indicate [f] Are there any fraud, credit limit, or other concerns that indicate
that access should be denied? that access should be denied?
While the authorization decision is in principle simple, the process While the authorization decision is in principle simple, the process
is complicated by the distributed nature of AAA decision making. is complicated by the distributed nature of the decision making.
Where brokering entities or proxies are involved, all of the AAA Where brokering entities or proxies are involved, all of the AAA
devices in the chain from the authenticator to the home AAA server entities in the chain from the authenticator to the home backend
are involved in the decision. For instance, a broker can disallow authentication server are involved in the decision. For instance, a
access even if the home AAA server would allow it, or a proxy can add broker can disallow access even if the home backend authentication
authorizations (e.g., bandwidth limits). server would allow it, or a proxy can add authorizations (e.g.,
bandwidth limits).
Decisions can be based on static policy definitions and profiles as Decisions can be based on static policy definitions and profiles as
well as dynamic state (e.g. time of day or limits on the number of well as dynamic state (e.g. time of day or limits on the number of
concurrent sessions). In addition to the Accept/Reject decision made concurrent sessions). In addition to the Accept/Reject decision made
by the AAA chain, parameters or constraints can be communicated to by the AAA chain, parameters or constraints can be communicated to
the authenticator. the authenticator.
The criteria for Accept/Reject decisions or the reasons for choosing The criteria for Accept/Reject decisions or the reasons for choosing
particular authorizations are typically not communicated to the particular authorizations are typically not communicated to the
authenticator, only the final result. As a result, the authenticator authenticator, only the final result. As a result, the authenticator
skipping to change at page 31, line 9 skipping to change at page 32, line 6
session limit) it should be possible to take this state into session limit) it should be possible to take this state into
account either before or after access is granted. Note that account either before or after access is granted. Note that
consideration of network-wide state such as simultaneous session consideration of network-wide state such as simultaneous session
limits can typically only be taken into account by the backend limits can typically only be taken into account by the backend
authentication server. authentication server.
[d] Encoding of restrictions. Since a authenticator may not be aware [d] Encoding of restrictions. Since a authenticator may not be aware
of the criteria considered by a backend authentication server when of the criteria considered by a backend authentication server when
allowing access, in order to ensure consistent authorization during allowing access, in order to ensure consistent authorization during
a fast handoff it may be necessary to explicitly encode the a fast handoff it may be necessary to explicitly encode the
restrictions within the authorizations provided in the AAA-Token. restrictions within the authorizations provided by the backend
authentication server.
[e] State validity. The introduction of fast handoff should not render [e] State validity. The introduction of fast handoff should not render
the authentication server incapable of keeping track of network- the authentication server incapable of keeping track of network-
wide state. wide state.
A handoff mechanism capable of addressing these concerns is said to A handoff mechanism capable of addressing these concerns is said to
be "correct". One condition for correctness is as follows: For a be "correct". One condition for correctness is as follows: For a
handoff to be "correct" it MUST establish on the new device the same handoff to be "correct" it MUST establish on the new device the same
context as would have been created had the new device completed a AAA context as would have been created had the new device completed a AAA
conversation with the authentication server. conversation with the backend authentication server.
A properly designed handoff scheme will only succeed if it is A properly designed handoff scheme will only succeed if it is
"correct" in this way. If a successful handoff would establish "correct" in this way. If a successful handoff would establish
"incorrect" state, it is preferable for it to fail, in order to avoid "incorrect" state, it is preferable for it to fail, in order to avoid
creation of incorrect context. creation of incorrect context.
Some backend authentication server and authenticator configurations Some backend authentication server and authenticator configurations
are incapable of meeting this definition of "correctness". For are incapable of meeting this definition of "correctness". For
example, if the old and new device differ in their capabilities, it example, if the old and new device differ in their capabilities, it
may be difficult to meet this definition of correctness in a handoff may be difficult to meet this definition of correctness in a handoff
skipping to change at page 33, line 22 skipping to change at page 34, line 21
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 it security In order to analyze whether the EAP conversation achieves its
goals, it is first necessary to state those goals as well as the security goals, it is first necessary to state those goals as well as
underlying security assumptions. the underlying security assumptions.
The overall goal of the EAP conversation is to derive fresh session The overall goal of the EAP conversation is to derive fresh session
keys between the EAP peer and authenticator that are known only to keys between the EAP peer and authenticator that are known only to
those parties, and for both the EAP peer and authenticator to those parties, and for both the EAP peer and authenticator to
demonstrate that they are authorized to perform their roles either by demonstrate that they are authorized to perform their roles either by
each other or by a trusted third party (the AAA server). each other or by a trusted third party (the backend authentication
server).
The principals of the authentication phase are the EAP peer and The principals of the authentication phase are the EAP peer and
server. Completion of an EAP method exchange supporting key server. Completion of an EAP method exchange 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. server know the exported keying material to be fresh.
The principals of the AAA Key transport exchange are the EAP The principals of the AAA Key transport exchange are the EAP
authenticator and the EAP server. Completion of the AAA exchange authenticator and the EAP server. Completion of the AAA exchange
skipping to change at page 35, line 4 skipping to change at page 35, line 51
[5] An attacker may attempt to induce an EAP peer, authenticator or [5] 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. [6] An attacker may replay packets.
[7] An attacker may cause an EAP peer, authenticator or server to reuse [7] 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 AAA server may provide stale provide stale keying material to an authenticator, or a poorly
keying material to an authenticator, or a poorly implemented implemented authenticator may reuse nonces.
authenticator may reuse nonces.
[8] An authenticated attacker may attempt to obtain elevated privilege [8] An authenticated attacker may attempt to obtain elevated privilege
in order to access information that it does not have rights to. in order to access information that it does not have rights to.
In order to address these threats, [Housley] provides a description In order to address these threats, [Housley] provides a description
of mandatory system security properties. Issues relating system of mandatory system security properties. Issues relating system
security requirements are discussed in the sections that follow. security requirements are discussed in the sections that follow.
5.3. Authenticator Compromise 5.3. 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 AAA servers. However, this should to communicate with one or more backend authentication servers.
not allow the attacker to compromise other authenticators or the AAA However, this should not allow the attacker to compromise other
server, or obtain long-term user credentials. authenticators or the backend authentication server, or obtain long-
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
important are as follows: important are as follows:
No Key Sharing No Key Sharing
An EAP authenticator MUST NOT share any keying material with An EAP authenticator MUST NOT share any keying material with
another EAP authenticator, since if one EAP authenticator were another EAP authenticator, since if one EAP authenticator were
compromised, this would enable the compromise of keying material on compromised, this would enable the compromise of keying material on
another authenticator. In order to be able to determine whether another authenticator. In order to be able to determine whether
keying material has been shared, it is necessary for the identity keying material has been shared, it is necessary for the identity
of the EAP authenticator to be defined and understood by all of the EAP authenticator to be defined and understood by all
parties that communicate with it. parties that communicate with it.
No AAA Credential Sharing No AAA Credential Sharing
AAA credentials (such as RADIUS shared secrets, IPsec pre-shared AAA credentials (such as RADIUS shared secrets, IPsec pre-shared
keys or certificates) MUST NOT be shared between AAA clients, since keys or certificates) MUST NOT be shared between AAA clients, since
if one AAA client were compromised, this would enable an attacker if one AAA client were compromised, this would enable an attacker
to impersonate other AAA clients to the AAA server, or even to to impersonate other AAA clients to the backend authentication
impersonate a AAA server to other AAA clients. server, or even to impersonate a backend authentication server to
other AAA clients.
No Compromise of Long-Term Credentials No Compromise of Long-Term Credentials
An attacker obtaining TSKs, TEKs or EAP keying material such as the An attacker obtaining TSKs, TEKs or EAP keying material such as the
MSK MUST NOT be able to obtain long-term user credentials such as MSK MUST NOT be able to obtain long-term user credentials such as
pre-shared keys, passwords or private-keys without breaking a pre-shared keys, passwords or private-keys without breaking a
fundamental cryptographic assumption. fundamental cryptographic assumption.
5.4. Spoofing 5.4. Spoofing
The use of per-packet authentication and integrity protection The use of per-packet authentication and integrity protection
skipping to change at page 37, line 29 skipping to change at page 38, line 29
"dictionary attack resistance" claims, and [RFC4017] requires EAP "dictionary attack resistance" claims, and [RFC4017] requires EAP
methods satisfying these claims. EAP methods complying with methods satisfying these claims. EAP methods complying with
[RFC4017] therefore provide for mutual authentication between the EAP [RFC4017] therefore provide for mutual authentication between the EAP
peer and server. Binding of EAP keying material (MSK, EMSK) to the peer and server. Binding of EAP keying material (MSK, EMSK) to the
appropriate context is provided by the Peer-ID and Server-ID which appropriate context is provided by the Peer-ID and Server-ID which
are exported along with the keying material. are exported along with the keying material.
Diameter [RFC3588] provides for per-packet authentication and Diameter [RFC3588] provides for per-packet authentication and
integrity protection via IPsec or TLS, and RADIUS/EAP [RFC3579] also integrity protection via IPsec or TLS, and RADIUS/EAP [RFC3579] also
provides for per-packet authentication and integrity protection. provides for per-packet authentication and integrity protection.
Where the NAS/authenticator and AAA server communicate directly and Where the NAS/authenticator and backend authentication server
credible keywrap is used (see Section 3.7), this ensures that the AAA communicate directly and credible keywrap is used (see Section 3.7),
Key Transport phase achieves its security objectives: mutually this ensures that the AAA Key Transport phase achieves its security
authenticating the AAA client/authenticator and AAA server and objectives: mutually authenticating the AAA client/authenticator and
providing EAP keying material to the EAP authenticator and to no backend authentication server and providing EAP keying material to
other party. the EAP authenticator and to no other party.
As noted in Section 3.1, the Secure Association Protocol does not by As noted in Section 3.1, the Secure Association Protocol does not by
itself provide for mutual authentication between the EAP peer and itself provide for mutual authentication between the EAP peer and
authenticator, even if mutual possession of EAP keying material is authenticator, even if mutual possession of EAP keying material is
proven. However, where the NAS/authenticator and AAA server proven. However, where the NAS/authenticator and backend
communicate directly, the AAA server can verify the correspondence authentication server communicate directly, the backend
between NAS identification attributes, the source address of packets authentication server can verify the correspondence between NAS
sent by the NAS, and the AAA credentials. As long as the NAS has not identification attributes, the source address of packets sent by the
shared its AAA credentials with another NAS, this allows the AAA NAS, and the AAA credentials. As long as the NAS has not shared its
server to authenticate the NAS. Using Channel Bindings, the EAP peer AAA credentials with another NAS, this allows the backend
can then determine whether the NAS/authenticator has provided the authentication server to authenticate the NAS. Using Channel
same identifying information to the EAP peer and AAA server. Bindings, the EAP peer can then determine whether the
NAS/authenticator has provided the same identifying information to
the EAP peer and backend authentication server.
Peer and authenticator authorization MUST be performed. Peer and authenticator authorization MUST be performed.
Authorization is REQUIRED whenever a peer associates with a new Authorization is REQUIRED whenever a peer associates with a new
authenticator. Authorization checking prevents an elevation of authenticator. Authorization checking prevents an elevation of
privilege attack, and ensures that an unauthorized authenticator is privilege attack, and ensures that an unauthorized authenticator is
detected. Authorizations SHOULD be synchronized between the EAP detected. Authorizations SHOULD be synchronized between the EAP
peer, server, authenticator. Once the EAP conversation exchanges are peer, server, authenticator. Once the EAP conversation exchanges are
complete, all of these parties should hold the same view of the complete, all of these parties should hold the same view of the
authorizations associated the other parties. If peer authorization authorizations associated the other parties. If peer authorization
is restricted, then the peer SHOULD be made aware of the restriction. is restricted, then the peer SHOULD be made aware of the restriction.
skipping to change at page 38, line 25 skipping to change at page 39, line 27
authorizations between the EAP authenticator and peer. authorizations between the EAP authenticator and peer.
In order to enable key binding and authorization of all parties, it In order to enable key binding and authorization of all parties, it
is RECOMMENDED that the parties use a set of identities that are is RECOMMENDED that the parties use a set of identities that are
consistent between the conversation phases. RADIUS [RFC2865] and consistent between the conversation phases. RADIUS [RFC2865] and
Diameter NASREQ [RFC4005] require that the NAS/EAP authenticator Diameter NASREQ [RFC4005] require that the NAS/EAP authenticator
identify itself by including one or more identification attributes identify itself by including one or more identification attributes
within an Access-Request packet (NAS-Identifier, NAS-IP-Address, NAS- within an Access-Request packet (NAS-Identifier, NAS-IP-Address, NAS-
IPv6-Address). IPv6-Address).
Since the AAA server provides EAP keying material for use by the EAP Since the backend authentication server provides EAP keying material
authenticator as identified by these attributes, where an EAP for use by the EAP authenticator as identified by these attributes,
authenticator may have multiple ports, it is RECOMMENDED for the EAP where an EAP authenticator may have multiple ports, it is RECOMMENDED
authenticator to identify itself using NAS identification attributes for the EAP authenticator to identify itself using NAS identification
during the Secure Association Protocol exchange with the EAP peer. attributes during the Secure Association Protocol exchange with the
This enables the EAP peer to determine whether EAP keying material EAP peer. This enables the EAP peer to determine whether EAP keying
has been shared between EAP authenticators as well as to confirm with material has been shared between EAP authenticators as well as to
the AAA server that an EAP authenticator proving possession of EAP confirm with the backend authentication server that an EAP
keying material during the Secure Association Protocol was authorized authenticator proving possession of EAP keying material during the
to obtain it. Typically, the NAS-Identifier attribute is most Secure Association Protocol was authorized to obtain it. Typically,
convenient for this purpose, since a NAS/authenticator may have the NAS-Identifier attribute is most convenient for this purpose,
multiple IP addresses. since a NAS/authenticator may have multiple IP addresses.
Similarly, the AAA server authorizes the EAP authenticator to provide Similarly, the backend authentication server authorizes the EAP
access to the EAP peer identified by the Peer-ID, securely verified authenticator to provide access to the EAP peer identified by the
during the EAP authentication exchange. In order to determine Peer-ID, securely verified during the EAP authentication exchange.
whether EAP keying material has been shared between EAP peers, where In order to determine whether EAP keying material has been shared
the EAP peer has multiple ports it is RECOMMENDED for the EAP peer to between EAP peers, where the EAP peer has multiple ports it is
identify itself using the Peer-ID during the Secure Association RECOMMENDED for the EAP peer to identify itself using the Peer-ID
Protocol exchange with the EAP authenticator. during the Secure Association Protocol exchange with the EAP
authenticator.
5.7. Replay Protection 5.7. 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.
skipping to change at page 40, line 29 skipping to change at page 41, line 35
However, unless the authenticator keeps track of EAP Session-IDs, However, unless the authenticator keeps track of EAP Session-IDs,
the authenticator cannot use the Session-ID to guarantee the the authenticator cannot use the Session-ID to guarantee the
freshness of EAP keying material. freshness of EAP keying material.
As described in [RFC3580] Section 3.17, When sent in an Access- As described in [RFC3580] Section 3.17, When sent in an Access-
Accept along with a Termination-Action value of RADIUS-Request, the Accept along with a Termination-Action value of RADIUS-Request, the
Session-Timeout attribute specifies the maximum number of seconds Session-Timeout attribute specifies the maximum number of seconds
of service provided prior to re-authentication. [IEEE-802.11i] of service provided prior to re-authentication. [IEEE-802.11i]
also utilizes the Session-Timeout attribute to limit the maximum also utilizes the Session-Timeout attribute to limit the maximum
time that EAP keying material may be cache. Therefore the use of time that EAP keying material may be cache. Therefore the use of
the Session-Timeout attribute enables the AAA server to limit the the Session-Timeout attribute enables the backend authentication
exposure of EAP keying material. server to limit the exposure of EAP keying material.
Lower Layer Lower Layer
The lower layer Secure Association Protocol MUST generate a fresh The lower layer Secure Association Protocol MUST generate a fresh
session key for each session, even if the keying material and session key for each session, even if the keying material and
parameters provided by EAP methods are cached, or the peer or parameters provided by EAP methods are cached, or the peer or
authenticator lacks a high entropy random number generator. A authenticator lack a high entropy random number generator. A
RECOMMENDED method is for the peer and authenticator to each RECOMMENDED method is for the peer and authenticator to each
provide a nonce or counter of at least 128 bits, used in session provide a nonce or counter used in session key derivation. If a
key derivation. nonce is used, it is RECOMMENDED that it be at least 128 bits.
5.9. Elevation of Privilege 5.9. Elevation of Privilege
Parties MUST NOT have access to keying material that is not needed to Parties MUST NOT have access to keying material that is not needed to
perform their own role. A party has access to a particular key if it perform their own role. A party has access to a particular key if it
has access to all of the secret information needed to derive it. If has access to all of the secret information needed to derive it. If
a post-EAP handshake is used to establish session keys, the post-EAP a post-EAP handshake is used to establish session keys, the post-EAP
handshake MUST specify the scope for session keys. handshake 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
skipping to change at page 41, line 19 skipping to change at page 42, line 26
conversation was transported through it (this could be demonstrated conversation was transported through it (this could be demonstrated
by a man-in-the-middle), but that it was uniquely authorized by the by a man-in-the-middle), but that it was uniquely authorized by the
EAP server to provide the peer with access to the network. Unique EAP server to provide the peer with access to the network. Unique
authorization can only be demonstrated if the EAP authenticator does authorization can only be demonstrated if the EAP authenticator does
not share the transported keying material with a party other than the not share the transported keying material with a party other than the
EAP peer and server. EAP peer and server.
TSKs are permitted to be accessed only by the EAP peer and TSKs are permitted to be accessed only by the EAP peer and
authenticator. Since the TSKs can be determined from the transported authenticator. Since the TSKs can be determined from the transported
EAP keying material and the cleartext of the Secure Association EAP keying material and the cleartext of the Secure Association
Protocol exchange, the AAA server will have access to the TSKs unless Protocol exchange, the backend authentication server will have access
it deletes the transported EAP keying material after sending it. to the TSKs unless it deletes the transported EAP keying material
after sending it.
5.10. Man-in-the-middle Attacks 5.10. 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.
skipping to change at page 42, line 24 skipping to change at page 43, line 35
deletion, the authenticator may choose to limit the number of TSKs deletion, the authenticator may choose to limit the number of TSKs
and associated state that can be stored for each peer. and associated state that can be stored for each peer.
5.12. Impersonation 5.12. Impersonation
Both the RADIUS and Diameter protocols are potentially vulnerable to Both the RADIUS and Diameter protocols are potentially vulnerable to
impersonation by a rogue authenticator. impersonation by a rogue authenticator.
While AAA protocols such as RADIUS [RFC2865] or Diameter [RFC3588] While AAA protocols such as RADIUS [RFC2865] or Diameter [RFC3588]
support mutual authentication between the authenticator (known as the support mutual authentication between the authenticator (known as the
AAA client) and the backend authentication server (known as the AAA AAA client) and the backend authentication server (known as the
server), the security mechanisms vary according to the AAA protocol. backend authentication server), the security mechanisms vary
according to the AAA protocol.
In RADIUS, the shared secret used for authentication is determined by In RADIUS, the shared secret used for authentication is determined by
the source address of the RADIUS packet. As noted in [RFC3579] the source address of the RADIUS packet. As noted in [RFC3579]
Section 4.3.7, it is highly desirable that the source address be Section 4.3.7, it is highly desirable that the source address be
checked against one or more NAS identification attributes so as to checked against one or more NAS identification attributes so as to
detect and prevent impersonation attacks. detect and prevent impersonation attacks.
When RADIUS requests are forwarded by a proxy, the NAS-IP-Address or When RADIUS requests are forwarded by a proxy, the NAS-IP-Address or
NAS-IPv6-Address attributes may not correspond to the source address. NAS-IPv6-Address attributes may not correspond to the source address.
Since the NAS-Identifier attribute need not contain an FQDN, it also Since the NAS-Identifier attribute need not contain an FQDN, it also
skipping to change at page 43, line 39 skipping to change at page 44, line 50
mutual possession of the transported EAP keying material. This mutual possession of the transported EAP keying material. This
creates a potential security vulnerability, described in [RFC3748] creates a potential security vulnerability, described in [RFC3748]
Section 7.15. Section 7.15.
[RFC3579] Section 4.3.7 describes how an EAP pass-through [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). However, it is possible for a pass-through authenticator protocol). However, it is possible for a pass-through authenticator
acting as a AAA client to provide correct information to the AAA acting as a AAA client to provide correct information to the backend
server while communicating misleading information to the EAP peer via authentication server while communicating misleading information to
the lower layer. the EAP peer via the lower layer.
For example, a compromised authenticator can utilize another For example, a compromised authenticator can utilize another
authenticator's Called-Station-Id or NAS-Identifier in communicating authenticator's Called-Station-Id or NAS-Identifier in communicating
with the EAP peer via the lower layer, or for a pass-through with the EAP peer via the lower layer, or for a pass-through
authenticator acting as a AAA client to provide an incorrect peer authenticator acting as a AAA client to provide an incorrect peer
Calling-Station-Id [RFC2865][RFC3580] to the AAA server via the AAA Calling-Station-Id [RFC2865][RFC3580] to the AAA server via the AAA
protocol. protocol.
As noted in [RFC3748] Section 7.15, this vulnerability can be As noted in [RFC3748] Section 7.15, this vulnerability can be
addressed by EAP methods that support a protected exchange of channel addressed by EAP methods that support a protected exchange of channel
skipping to change at page 45, line 25 skipping to change at page 46, line 33
[DESMODES] [DESMODES]
National Institute of Standards and Technology, "DES Modes of National Institute of Standards and Technology, "DES Modes of
Operation", FIPS PUB 81, December 1980, <http:// Operation", FIPS PUB 81, December 1980, <http://
www.itl.nist.gov/fipspubs/fip81.htm>. www.itl.nist.gov/fipspubs/fip81.htm>.
[FIPSDES] National Institute of Standards and Technology, "Data [FIPSDES] National Institute of Standards and Technology, "Data
Encryption Standard", FIPS PUB 46, January 1977. Encryption Standard", FIPS PUB 46, January 1977.
[Housley] Housley, R. and B. Aboba, "AAA Key Management", draft-housley- [Housley] Housley, R. and B. Aboba, "AAA Key Management", draft-housley-
aaa-key-mgmt-00.txt, Internet draft (work in progress), June aaa-key-mgmt-01.txt, Internet draft (work in progress),
2005. November 2005.
[IEEE-802] [IEEE-802]
Institute of Electrical and Electronics Engineers, "IEEE Institute of Electrical and Electronics Engineers, "IEEE
Standards for Local and Metropolitan Area Networks: Overview Standards for Local and Metropolitan Area Networks: Overview
and Architecture", ANSI/IEEE Standard 802, 1990. and Architecture", ANSI/IEEE Standard 802, 1990.
[IEEE-802.11] [IEEE-802.11]
Institute of Electrical and Electronics Engineers, Institute of Electrical and Electronics Engineers,
"Information technology - Telecommunications and information "Information technology - Telecommunications and information
exchange between systems - Local and metropolitan area exchange between systems - Local and metropolitan area
skipping to change at page 46, line 18 skipping to change at page 47, line 24
between Systems - LAN/MAN Specific Requirements - Part 11: between Systems - LAN/MAN Specific Requirements - Part 11:
Wireless Medium Access Control (MAC) and physical layer (PHY) Wireless Medium Access Control (MAC) and physical layer (PHY)
specifications: Specification for Enhanced Security", IEEE specifications: Specification for Enhanced Security", IEEE
802.11i, December 2004. 802.11i, December 2004.
[IEEE-802.11F] [IEEE-802.11F]
Institute of Electrical and Electronics Engineers, Institute of Electrical and Electronics Engineers,
"Recommended Practice for Multi-Vendor Access Point "Recommended Practice for Multi-Vendor Access Point
Interoperability via an Inter-Access Point Protocol Across Interoperability via an Inter-Access Point Protocol Across
Distribution Systems Supporting IEEE 802.11 Operation", IEEE Distribution Systems Supporting IEEE 802.11 Operation", IEEE
802.11F, July 2003. 802.11F, July 2003 (now deprecated).
[IEEE-02-758] [IEEE-02-758]
Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang,
"Proactive Caching Strategies for IAPP Latency Improvement "Proactive Caching Strategies for IAPP Latency Improvement
during 802.11 Handoff", IEEE 802.11 Working Group, during 802.11 Handoff", IEEE 802.11 Working Group,
IEEE-02-758r1-F Draft 802.11I/D5.0, November 2002. IEEE-02-758r1-F Draft 802.11I/D5.0, November 2002.
[IEEE-03-084] [IEEE-03-084]
Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang,
"Proactive Key Distribution to support fast and secure "Proactive Key Distribution to support fast and secure
skipping to change at page 48, line 49 skipping to change at page 50, line 5
[RFC4005] Calhoun, P., Zorn, G., Spence, D. and D. Mitton, "Diameter [RFC4005] Calhoun, P., Zorn, G., Spence, D. and D. Mitton, "Diameter
Network Access Server Application", RFC 4005, August 2005. Network Access Server Application", RFC 4005, August 2005.
[RFC4017] Stanley, D., Walker, J. and B. Aboba, "EAP Method Requirements [RFC4017] Stanley, D., Walker, J. and B. Aboba, "EAP Method Requirements
for Wireless LANs", RFC 4017, March 2005. for Wireless LANs", RFC 4017, March 2005.
[RFC4072] Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible [RFC4072] Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application", RFC 4072, August Authentication Protocol (EAP) Application", RFC 4072, August
2005. 2005.
[RFC4118] Yang, L., Zerfos, P. and E. Sadot, "Architecture Taxonomy for
Control and Provisioning of Wireless Access Points (CAPWAP)",
RFC 4118, June 2005.
[8021XHandoff] [8021XHandoff]
Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff in a Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff in a
Public Wireless LAN Based on IEEE 802.1X Model", School of Public Wireless LAN Based on IEEE 802.1X Model", School of
Computer Science and Engineering, Seoul National University, Computer Science and Engineering, Seoul National University,
Seoul, Korea, 2002. 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 51, line 20 skipping to change at page 52, line 20
In EAP-TLS, the MSK, EMSK and IV are derived from the TLS master In EAP-TLS, the MSK, EMSK and IV are derived from the TLS master
secret via a one-way function. This ensures that the TLS master secret via a one-way function. This ensures that the TLS master
secret cannot be derived from the MSK, EMSK or IV unless the one-way secret cannot be derived from the MSK, EMSK or IV unless the one-way
function (TLS PRF) is broken. Since the MSK is derived from the the function (TLS PRF) is broken. Since the MSK is derived from the the
TLS master secret, if the TLS master secret is compromised then the TLS master secret, if the TLS master secret is compromised then the
MSK is also compromised. MSK is also compromised.
[RFC2716] specifies that the MSK is divided into two halves, [RFC2716] specifies that the MSK is divided into two halves,
corresponding to the "Peer to Authenticator Encryption Key" (Enc- corresponding to the "Peer to Authenticator Encryption Key" (Enc-
RECV-Key, 32 octets, also known as the PMK) and "Authenticator to RECV-Key, 32 octets) and "Authenticator to Peer Encryption Key" (Enc-
Peer Encryption Key" (Enc-SEND-Key, 32 octets). In [RFC2548], the SEND-Key, 32 octets). In [RFC2548], the Enc-RECV-Key is transported
Enc-RECV-Key (the PMK) is transported in the MS-MPPE-Recv-Key in the MS-MPPE-Recv-Key attribute, and the Enc-SEND-Key is
attribute, and the Enc-SEND-Key is transported in the MS-MPPE-Send- transported in the MS-MPPE-Send- Key attribute.
Key attribute.
The EMSK is also divided into two halves, corresponding to the "Peer The EMSK is also divided into two halves, corresponding to the "Peer
to Authenticator Authentication Key" (Auth-RECV-Key, 32 octets) and to Authenticator Authentication Key" (Auth-RECV-Key, 32 octets) and
"Authenticator to Peer Authentication Key" (Auth-SEND-Key, 32 "Authenticator to Peer Authentication Key" (Auth-SEND-Key, 32
octets). The IV is a 64 octet quantity that is a known value; octets octets). The IV is a 64 octet quantity that is a known value; octets
0-31 are known as the "Peer to Authenticator IV" or RECV-IV, and 0-31 are known as the "Peer to Authenticator IV" or RECV-IV, and
Octets 32-63 are known as the "Authenticator to Peer IV", or SEND-IV. Octets 32-63 are known as the "Authenticator to Peer IV", or SEND-IV.
The key derivation scheme MUST be interpreted as follows: The key derivation scheme MUST be interpreted as follows:
skipping to change at page 55, line 17 skipping to change at page 56, line 17
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
Open Issues Open Issues
 End of changes. 73 change blocks. 
312 lines changed or deleted 377 lines changed or added

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