draft-ietf-eap-keying-14.txt   draft-ietf-eap-keying-15.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-14.txt> P. Eronen <draft-ietf-eap-keying-15.txt> P. Eronen
25 June 2006 Nokia 22 October 2006 Nokia
H. Levkowetz H. Levkowetz
Ericsson Research Ericsson Research
Extensible Authentication Protocol (EAP) Key Management Framework Extensible Authentication Protocol (EAP) Key Management Framework
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 10, 2006. This Internet-Draft will expire on March 10, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society 2006. Copyright (C) The Internet Society 2006.
Abstract Abstract
The Extensible Authentication Protocol (EAP), defined in [RFC3748], The Extensible Authentication Protocol (EAP), defined in [RFC3748],
enables extensible network access authentication. This document enables extensible network access authentication. This document
provides a framework for the transport and usage of keying material provides a framework for the transport and usage of keying material
generated by EAP authentication algorithms, known as "methods". It generated by EAP authentication algorithms, known as "methods". It
also specifies the EAP key hierarchy. also specifies the EAP key hierarchy.
Table of Contents Table of Contents
1. Introduction .......................................... 3 1. Introduction .......................................... 3
1.1 Requirements Language ........................... 3 1.1 Requirements Language ........................... 3
1.2 Terminology ..................................... 3 1.2 Terminology ..................................... 3
1.3 Overview ........................................ 6 1.3 Overview ........................................ 6
1.4 EAP Key Hierarchy ............................... 8 1.4 EAP Key Hierarchy ............................... 9
1.5 Security Goals .................................. 12 1.5 Security Goals .................................. 13
1.6 EAP Invariants .................................. 13 1.6 EAP Invariants .................................. 13
2. Lower Layer Operation ................................. 16 2. Lower Layer Operation ................................. 17
2.1 Transient Session Keys .......................... 17 2.1 Transient Session Keys .......................... 17
2.2 Authenticator and Peer Architecture ............. 18 2.2 Authenticator and Peer Architecture ............. 19
2.3 Server Identification ........................... 23 2.3 Server Identification ........................... 23
3. Key Management ........................................ 25 3. Key Management ........................................ 25
3.1 Secure Association Protocol ..................... 25 3.1 Secure Association Protocol ..................... 26
3.2 Key Scope ....................................... 28 3.2 Key Scope ....................................... 29
3.3 Parent-Child Relationships ...................... 29 3.3 Parent-Child Relationships ...................... 29
3.4 Local Key Lifetimes ............................. 29 3.4 Local Key Lifetimes ............................. 30
3.5 Exported and Calculated Key Lifetimes ........... 30 3.5 Exported and Calculated Key Lifetimes ........... 30
3.6 Key Cache Synchronization ....................... 31 3.6 Key Cache Synchronization ....................... 33
3.7 Key Strength .................................... 32 3.7 Key Strength .................................... 33
3.8 Key Wrap ........................................ 33 3.8 Key Wrap ........................................ 34
4. Handoff Vulnerabilities ............................... 33 4. Handoff Vulnerabilities ............................... 34
4.1 EAP Pre-authentication .......................... 34 4.1 EAP Pre-authentication .......................... 35
4.2 Authorization ................................... 35 4.2 Authorization ................................... 36
4.3 Correctness ..................................... 36 4.3 Correctness ..................................... 37
5. Security Considerations .............................. 39 5. Security Considerations .............................. 40
5.1 Authenticator Compromise ........................ 40 5.1 Authenticator Compromise ........................ 41
5.2 Spoofing ........................................ 41 5.2 Spoofing ........................................ 42
5.3 Downgrade Attacks ............................... 41 5.3 Downgrade Attacks ............................... 42
5.4 Unauthorized Disclosure ......................... 42 5.4 Unauthorized Disclosure ......................... 43
5.5 Replay Protection ............................... 44 5.5 Replay Protection ............................... 45
5.6 Key Freshness ................................... 45 5.6 Key Freshness ................................... 46
5.7 Elevation of Privilege .......................... 46 5.7 Elevation of Privilege .......................... 47
5.8 Man-in-the-Middle Attacks ....................... 47 5.8 Man-in-the-Middle Attacks ....................... 48
5.9 Denial of Service Attacks ....................... 47 5.9 Denial of Service Attacks ....................... 48
5.10 Impersonation ................................... 47 5.10 Impersonation ................................... 48
5.11 Channel Binding ................................. 49 5.11 Channel Binding ................................. 50
6. IANA Considerations ................................... 50 6. IANA Considerations ................................... 51
7. References ............................................ 50 7. References ............................................ 51
7.1 Normative References ............................ 50 7.1 Normative References ............................ 51
7.2 Informative References .......................... 50 7.2 Informative References .......................... 51
Acknowledgments .............................................. 55 Acknowledgments .............................................. 56
Author's Addresses ........................................... 56 Author's Addresses ........................................... 57
Appendix A - Exported Parameters in Existing Methods ......... 57 Appendix A - Exported Parameters in Existing Methods ......... 58
Intellectual Property Statement .............................. 58 Intellectual Property Statement .............................. 59
Disclaimer of Validity ....................................... 59 Disclaimer of Validity ....................................... 60
Copyright Statement .......................................... 59 Copyright Statement .......................................... 60
1. Introduction 1. Introduction
The Extensible Authentication Protocol (EAP), defined in [RFC3748], The Extensible Authentication Protocol (EAP), defined in [RFC3748],
was designed to enable extensible authentication for network access was designed to enable extensible authentication for network access
in situations in which the Internet Protocol (IP) protocol is not in situations in which the Internet Protocol (IP) protocol is not
available. Originally developed for use with Point-to-Point Protocol available. Originally developed for use with Point-to-Point Protocol
(PPP) [RFC1661], it has subsequently also been applied to IEEE 802 (PPP) [RFC1661], it has subsequently also been applied to IEEE 802
wired networks [IEEE-802.1X], wireless networks such as wired networks [IEEE-802.1X], wireless networks such as
[IEEE-802.11i] d [IEEE-802.16e], and IKEv2 [RFC4306]. [IEEE-802.11i] d [IEEE-802.16e], and IKEv2 [RFC4306].
skipping to change at page 3, line 40 skipping to change at page 3, line 40
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.2. Terminology 1.2. Terminology
The terms "Cryptographic binding", "Cryptographic separation", "Key The terms "Cryptographic binding", "Cryptographic separation", "Key
strength" and "Mutual authentication" are defined in [RFC3748] and strength" and "Mutual authentication" are defined in [RFC3748] and
are used with the same meaning in this document, which also are used with the same meaning in this document, which also
frequently uses the following terms: frequently uses the following terms:
4-Way Handshake
A pairwise Authentication and Key Management Protocol (AKMP)
defined in [IEE-802.11i], which confirms mutual possession of a
Pairwise Master Key by two parties and distributes a Group Key.
AAA Authentication, Authorization and Accounting. AAA protocols with AAA Authentication, Authorization and Accounting. AAA protocols with
EAP support include RADIUS [RFC3579] and Diameter [RFC4072]. In EAP support include RADIUS [RFC3579] and Diameter [RFC4072]. In
this document, the terms "AAA server" and "backend authentication this document, the terms "AAA server" and "backend authentication
server" are used interchangeably. server" are used interchangeably.
AAA-Key
The term AAA-Key is synonymous with MSK. Since multiple keys may
be transported by AAA, the term is potentially confusing and is not
used in this document.
authenticator authenticator
The end of the link initiating EAP authentication. The term The end of the link initiating EAP authentication. The term
Authenticator is used in [IEEE-802.1X], and authenticator has the Authenticator is used in [IEEE-802.1X], and authenticator has the
same meaning in this document. same meaning in this document.
peer The end of the link that responds to the authenticator.
backend authentication server backend authentication server
A backend authentication server is an entity that provides an A backend authentication server is an entity that provides an
authentication service to an authenticator. When used, this server authentication service to an authenticator. When used, this server
typically executes EAP methods for the authenticator. This typically executes EAP methods for the authenticator. This
terminology is also used in [IEEE-802.1X]. terminology is also used in [IEEE-802.1X].
Channel Binding Channel Binding
A secure mechanism for ensuring that a subset of the parameters A secure mechanism for ensuring that a subset of the parameters
transmitted by the authenticator (such as authenticator identifiers transmitted by the authenticator (such as authenticator identifiers
and properties) are agreed upon by the EAP peer and server. It is and properties) are agreed upon by the EAP peer and server. It is
expected that the parameters are also securely agreed upon by the expected that the parameters are also securely agreed upon by the
EAP peer and authenticator via the lower layer if the authenticator EAP peer and authenticator via the lower layer if the authenticator
advertised the parameters. advertised the parameters.
EAP pre-authentication
The use of EAP to pre-establish EAP keying material on an
authenticator prior to arrival of the peer at the access network
managed by that authenticator.
EAP re-authentication
EAP authentication between an EAP peer and a server with whom the
EAP peer shares valid unexpired keying material.
EAP server EAP server
The entity that terminates the EAP authentication method with the The entity that terminates the EAP authentication method with the
peer. In the case where no backend authentication server is used, peer. In the case where no backend authentication server is used,
the EAP server is part of the authenticator. In the case where the the EAP server is part of the authenticator. In the case where the
authenticator operates in pass-through mode, the EAP server is authenticator operates in pass-through mode, the EAP server is
located on the backend authentication server. located on the backend authentication server.
Lower Layer
The lower layer is responsible for carrying EAP frames between the
peer and authenticator.
Long Term Credential
EAP methods frequently make use of long term secrets in order to
enable authentication between the peer and server. In the case of
a method based on pre-shared key authentication, the long term
credential is the pre-shared key. In the case of a public-key
based method, the long term credential is the corresponding private
key.
Master Session Key (MSK)
Keying material that is derived between the EAP peer and server and
exported by the EAP method. The MSK is at least 64 octets in
length.
AAA-Key
The term AAA-Key is synonymous with MSK. Since multiple keys may
be transported by AAA, the term is potentially confusing and is not
used in this document.
Extended Master Session Key (EMSK) Extended Master Session Key (EMSK)
Additional keying material derived between the peer and server that Additional keying material derived between the peer and server that
is exported by the EAP method. The EMSK is at least 64 octets in is exported by the EAP method. The EMSK is at least 64 octets in
length, and is never shared with a third party. length, and is never shared with a third party.
Initialization Vector (IV) Initialization Vector (IV)
A quantity of at least 64 octets, suitable for use in an A quantity of at least 64 octets, suitable for use in an
initialization vector field, that is derived between the peer and initialization vector field, that is derived between the peer and
EAP server. Since the IV is a known value in methods such as EAP- EAP server. Since the IV is a known value in methods such as EAP-
TLS [RFC2716], it cannot be used by itself for computation of any TLS [RFC2716], it cannot be used by itself for computation of any
quantity that needs to remain secret. As a result, its use has quantity that needs to remain secret. As a result, its use has
been deprecated and EAP methods are not required to generate it. been deprecated and EAP methods are not required to generate it.
However, when it is generated it MUST be unpredictable. However, when it is generated it MUST be unpredictable.
Key Scope
The parties to whom a key is available.
Key Wrap
The encryption of one symmetric cryptographic key in another. The
algorithm used for the encryption is called a key wrap algorithm or
a key encryption algorithm. The key used in the encryption process
is called a key-encryption key (KEK).
Long Term Credential
EAP methods frequently make use of long term secrets in order to
enable authentication between the peer and server. In the case of
a method based on pre-shared key authentication, the long term
credential is the pre-shared key. In the case of a public-key
based method, the long term credential is the corresponding private
key.
Lower Layer
The lower layer is responsible for carrying EAP frames between the
peer and authenticator.
Lower Layer Identity
A name used to identify the EAP peer and authenticator within the
lower layer.
Master Session Key (MSK)
Keying material that is derived between the EAP peer and server and
exported by the EAP method. The MSK is at least 64 octets in
length.
Network Access Server (NAS) Network Access Server (NAS)
A device that provides an access service for a user to a network. A device that provides an access service for a user to a network.
Pairwise Master Key (PMK) Pairwise Master Key (PMK)
Lower layers use the MSK in lower-layer dependent manner. For Lower layers use the MSK in lower-layer dependent manner. For
instance, in [IEEE-802.11i] Octets 0-31 of the MSK are known as the instance, in [IEEE-802.11i] Octets 0-31 of the MSK are known as the
Pairwise Master Key (PMK). In [IEEE-802.11i] the TKIP and AES CCMP Pairwise Master Key (PMK). In [IEEE-802.11i] the TKIP and AES CCMP
ciphersuites derive their Transient Session Keys (TSKs) solely from ciphersuites derive their Transient Session Keys (TSKs) solely from
the PMK, whereas the WEP ciphersuite as noted in [RFC3580], derives the PMK, whereas the WEP ciphersuite as noted in [RFC3580], derives
its TSKs from both halves of the MSK. In [802.16e], the MSK is its TSKs from both halves of the MSK. In [802.16e], the MSK is
truncated to 20 octets for PMK and 20 octets for PMK2. truncated to 20 octets for PMK and 20 octets for PMK2.
peer The end of the link that responds to the authenticator.
security association security association
A set of policies and cryptographic state used to protect A set of policies and cryptographic state used to protect
information. Elements of a security association may include information. Elements of a security association may include
cryptographic keys, negotiated ciphersuites and other parameters, cryptographic keys, negotiated ciphersuites and other parameters,
counters, sequence spaces, authorization attributes, etc. counters, sequence spaces, authorization attributes, etc.
Secure Association Protocol Secure Association Protocol
An exchange that occurs between the EAP peer and authenticator in An exchange that occurs between the EAP peer and authenticator in
order to manage the creation and deletion of unicast and multicast order to manage security associations derived from EAP exchanges.
security associations. The protocol establishes unicast and (optionally) multicast
security associations, which include symmetric keys and a context
for the use of the keys. An example of a Secure Association
Protocol is the 4-way handshake defined within [IEEE-802.11i].
Session-Id Session-Id
The EAP Session-Id uniquely identifies an EAP session between an The EAP Session-Id uniquely identifies an EAP authentication
EAP peer (as identified by the Peer-Id) and server (as identified exchange between an EAP peer (as identified by the Peer-Id) and
by the Server-Id). For more information, see Section 1.4. server (as identified by the Server-Id). For more information, see
Section 1.4.
Transient EAP Keys (TEKs) Transient EAP Keys (TEKs)
Session keys which are used to establish a protected channel Session keys which are used to establish a protected channel
between the EAP peer and server during the EAP authentication between the EAP peer and server during the EAP authentication
exchange. The TEKs are appropriate for use with the ciphersuite exchange. The TEKs are appropriate for use with the ciphersuite
negotiated between EAP peer and server for use in protecting the negotiated between EAP peer and server for use in protecting the
EAP conversation. The TEKs are stored locally by the EAP method EAP conversation. The TEKs are stored locally by the EAP method
and are not exported. Note that the ciphersuite used to set up the and are not exported. Note that the ciphersuite used to set up the
protected channel between the EAP peer and server during EAP protected channel between the EAP peer and server during EAP
authentication is unrelated to the ciphersuite used to subsequently authentication is unrelated to the ciphersuite used to subsequently
protect data sent between the EAP peer and authenticator. protect data sent between the EAP peer and authenticator.
Transient Session Keys (TSKs) Transient Session Keys (TSKs)
Session keys used to protect data exchanged after EAP Keys used to protect data exchanged after EAP authentication has
authentication has successfully completed, using the ciphersuite successfully completed, using the ciphersuite negotiated between
negotiated between the EAP peer and authenticator. the EAP peer and authenticator.
1.3. Overview 1.3. Overview
Where EAP key derivation is supported, the conversation typically Where EAP key derivation is supported, the conversation typically
takes place in three phases: takes place in three phases:
Phase 0: Discovery Phase 0: Discovery
Phase 1: Authentication Phase 1: Authentication
1a: EAP authentication 1a: EAP authentication
1b: AAA Key Transport (optional) 1b: AAA Key Transport (optional)
skipping to change at page 10, line 29 skipping to change at page 11, line 8
peer identity, the Peer-Id is the null string. peer identity, the Peer-Id is the null string.
Server-Id Server-Id
Where the EAP method authenticates the server identity, that Where the EAP method authenticates the server identity, that
identity is exported by the method as the Server-Id. A suitable identity is exported by the method as the Server-Id. A suitable
EAP server name may not always be available. Where an EAP method EAP server name may not always be available. Where an EAP method
does not define a method-specific server identity, the Server-Id does not define a method-specific server identity, the Server-Id
is the null string. is the null string.
Session-Id
The Session-Id uniquely identifies an EAP session between an EAP
peer (as identified by the Peer-Id) and server (as identified by
the Server-Id). Where the EAP Type Code is less than 255, the EAP
Session-Id consists of the concatenation of the EAP Type Code and
a temporally unique identifier obtained from the method. Where
expanded EAP Type Codes are used, the EAP Session-Id consists of
the Expanded Type Code (including the Type, Vendor-Id and Vendor-
Type fields defined in [RFC3748] Section 5.7) concatenated with a
temporally unique identifier obtained from the method. This
unique identifier is typically constructed from nonces or
counters used within the EAP method exchange. The inclusion of
the Type Code in the EAP Session-Id ensures that each EAP method
has a distinct Session-Id space. Since an EAP session is not
bound to a particular authenticator or specific ports on the peer
and authenticator, the authenticator port or identity are not
included in the Session-Id.
Channel Bindings
Channel Bindings include lower layer parameters that are verified
for consistency between the EAP peer and server. In order to
avoid introducing media dependencies, EAP methods that transport
Channel Binding data MUST treat this data as opaque octets. See
Section 5.11 for further discussion.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | ^ | | ^
| EAP Method | | | EAP Method | |
| | | | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | |
| | | | | | | | | | | | | |
| | EAP Method Key |<->| Long-Term | | | | | EAP Method Key |<->| Long-Term | | |
| | Derivation | | Credential | | | | | Derivation | | Credential | | |
| | | | | | | | | | | | | |
| | | +-+-+-+-+-+-+-+ | Local to | | | | +-+-+-+-+-+-+-+ | Local to |
skipping to change at page 11, line 41 skipping to change at page 11, line 41
+-+-|-+-+-+-+-+-+-+-+-|-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+ ---+ +-+-|-+-+-+-+-+-+-+-+-|-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+ ---+
| | | | ^ | | | | ^
| Peer-Id, | | | Exported | | Peer-Id, | | | Exported |
| Server-Id, | Channel | MSK (64+B) | IV (64B) by | | Server-Id, | Channel | MSK (64+B) | IV (64B) by |
| Session-Id | Bindings | EMSK (64+B) | (Optional) EAP | | Session-Id | Bindings | EMSK (64+B) | (Optional) EAP |
| | & Result | | Method | | | & Result | | Method |
V V V V V V V V V V
Figure 2: EAP Method Parameter Import/Export Figure 2: EAP Method Parameter Import/Export
Session-Id
The Session-Id uniquely identifies an EAP session between an EAP
peer (as identified by the Peer-Id) and server (as identified by
the Server-Id). Where the EAP Type Code is less than 255, the EAP
Session-Id consists of the concatenation of the EAP Type Code and
a temporally unique identifier obtained from the method. Where
expanded EAP Type Codes are used, the EAP Session-Id consists of
the Expanded Type Code (including the Type, Vendor-Id and Vendor-
Type fields defined in [RFC3748] Section 5.7) concatenated with a
temporally unique identifier obtained from the method. This
unique identifier is typically constructed from nonces or
counters used within the EAP method exchange. The inclusion of
the Type Code in the EAP Session-Id ensures that each EAP method
has a distinct Session-Id space. Since an EAP session is not
bound to a particular authenticator or specific ports on the peer
and authenticator, the authenticator port or identity are not
included in the Session-Id.
Channel Bindings
Channel Bindings include lower layer parameters that are verified
for consistency between the EAP peer and server. In order to
avoid introducing media dependencies, EAP methods that transport
Channel Binding data MUST treat this data as opaque octets. See
Section 5.11 for further discussion.
1.4.1. Key Naming 1.4.1. Key Naming
Each key created within the EAP key management framework has a name Each key created within the EAP key management framework has a name
(a unique identifier), as well as a scope (the parties to whom the (a unique identifier), as well as a scope (the parties to whom the
key is available). The scope of exported parameters is defined by key is available). The scope of exported parameters is defined by
the EAP Peer-Id (if securely exchanged within the method) and the EAP the EAP Peer-Id (if securely exchanged within the method) and the EAP
Server-Id (also only if securely exchanged). Where a peer or server Server-Id (also only if securely exchanged). Where a peer or server
name is missing the null string is used. name is missing the null string is used.
MSK and EMSK Names MSK and EMSK Names
skipping to change at page 13, line 51 skipping to change at page 14, line 30
It is a fundamental property of EAP that at the EAP method layer, the It is a fundamental property of EAP that at the EAP method layer, the
conversation between the EAP peer and server is unaffected by whether conversation between the EAP peer and server is unaffected by whether
the EAP authenticator is operating in "pass-through" mode. EAP the EAP authenticator is operating in "pass-through" mode. EAP
methods operate identically in all aspects, including key derivation methods operate identically in all aspects, including key derivation
and parameter import/export, regardless of whether the authenticator and parameter import/export, regardless of whether the authenticator
is operating as a pass-through or not. is operating as a pass-through or not.
The successful completion of an EAP method that supports key The successful completion of an EAP method that supports key
derivation results in the export of keying material and parameters on derivation results in the export of keying material and parameters on
the EAP peer and server. Even though the EAP peer or server may the EAP peer and server. Even though the EAP peer or server may
import Channel-Bindings that may include the identity of the EAP import Channel Bindings that may include the identity of the EAP
authenticator, this information is treated as opaque octets. As a authenticator, this information is treated as opaque octets. As a
result, within EAP the only relevant identities are the Peer-Id and result, within EAP the only relevant identities are the Peer-Id and
Server-Id. Channel Bindings are only interpreted by the lower layer. Server-Id. Channel Bindings are only interpreted by the lower layer.
Within EAP, the primary function of the AAA protocol is to maintain Within EAP, the primary function of the AAA protocol is to maintain
the principle of Mode Independence, so that as far as the EAP peer is the principle of Mode Independence, so that as far as the EAP peer is
concerned, its conversation with the EAP authenticator, and all concerned, its conversation with the EAP authenticator, and all
consequences of that conversation, are identical, regardless of the consequences of that conversation, are identical, regardless of the
authenticator mode of operation. authenticator mode of operation.
skipping to change at page 14, line 30 skipping to change at page 15, line 9
wireless networks such as 802.11 [IEEE-802.11i] and 802.16 wireless networks such as 802.11 [IEEE-802.11i] and 802.16
[IEEE-802.16e]. [IEEE-802.16e].
In order to maintain media independence, it is necessary for EAP to In order to maintain media independence, it is necessary for EAP to
avoid consideration of media-specific elements. For example, EAP avoid consideration of media-specific elements. For example, EAP
methods cannot be assumed to have knowledge of the lower layer over methods cannot be assumed to have knowledge of the lower layer over
which they are transported, and cannot be restricted to identifiers which they are transported, and cannot be restricted to identifiers
associated with a particular usage environment (e.g. MAC addresses). associated with a particular usage environment (e.g. MAC addresses).
Note that media independence may be retained within EAP methods that Note that media independence may be retained within EAP methods that
support Channel-Bindings or method-specific identification. An EAP support Channel Bindings or method-specific identification. An EAP
method need not be aware of the content of an identifier in order to method need not be aware of the content of an identifier in order to
use it. This enables an EAP method to use media-specific identifiers use it. This enables an EAP method to use media-specific identifiers
such as MAC addresses without compromising media independence. such as MAC addresses without compromising media independence.
Channel-Bindings are treated as opaque octets by EAP methods, so that Channel Bindings are treated as opaque octets by EAP methods, so that
handling them does not require media-specific knowledge. handling them does not require media-specific knowledge.
1.6.3. Method Independence 1.6.3. Method Independence
By enabling pass-through, authenticators can support any method By enabling pass-through, authenticators can support any method
implemented on the peer and server, not just locally implemented implemented on the peer and server, not just locally implemented
methods. This allows the authenticator to avoid implementing code methods. This allows the authenticator to avoid implementing code
for each EAP method required by peers. In fact, since a pass-through for each EAP method required by peers. In fact, since a pass-through
authenticator is not required to implement any EAP methods at all, it authenticator is not required to implement any EAP methods at all, it
cannot be assumed to support any EAP method-specific code. cannot be assumed to support any EAP method-specific code.
skipping to change at page 20, line 8 skipping to change at page 20, line 38
The Secure Association Protocol conversation is between the peer and The Secure Association Protocol conversation is between the peer and
the authenticator. For lower layers which support key caching it is the authenticator. For lower layers which support key caching it is
particularly important for the EAP peer, authenticator and backend particularly important for the EAP peer, authenticator and backend
server to have a consistent view of the usage scope of the server to have a consistent view of the usage scope of the
transported EAP keying material. In order to enable this, it is transported EAP keying material. In order to enable this, it is
RECOMMENDED that the Secure Association Protocol explicitly RECOMMENDED that the Secure Association Protocol explicitly
communicate the usage scope of the EAP keying material passed down to communicate the usage scope of the EAP keying material passed down to
the lower layer, rather than implicitly assuming that this is defined the lower layer, rather than implicitly assuming that this is defined
by the authenticator and peer endpoint addresses. by the authenticator and peer endpoint addresses.
Since an authenticator may have multiple ports, the scope of the
authenticator key cache may not be described by a single endpoint
address. Similarly, where a peer may have multiple ports and sharing
of EAP keying material and parameters between peer ports of the same
link type is allowed, the extent of the peer key cache cannot be
communicated by using a single endpoint address. Instead, it is
RECOMMENDED that the EAP peer and authenticator consistently identify
themselves utilizing explicit identifiers, rather than endpoint
addresses or port identifiers.
AAA protocols such as RADIUS [RFC3579] and Diameter [RFC4072] provide
a mechanism for the identification of AAA clients; since the EAP
authenticator and AAA client are always co-resident, this mechanism
is applicable to the identification of EAP authenticators.
RADIUS [RFC2865] requires that an Access-Request packet contain one
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 explicit identification of
the authenticator, both within the AAA protocol exchange and the
Secure Association Protocol conversation.
+-+-+-+-+ +-+-+-+-+
| EAP | | EAP |
| Peer | | Peer |
+-+-+-+-+ +-+-+-+-+
| | | Peer Ports | | | Peer Ports
/ | \ / | \
/ | \ / | \
/ | \ / | \
/ | \ / | \
/ | \ / | \
skipping to change at page 20, line 42 skipping to change at page 21, line 46
\ | \ | \ | \ |
\ | \ | \ | \ |
\ | \ | \ | \ |
+-+-+-+-+-+ +-+-+-+-+-+ Backend +-+-+-+-+-+ +-+-+-+-+-+ Backend
| EAP | | EAP | Authentication | EAP | | EAP | Authentication
| Server1 | | Server2 | Servers | Server1 | | Server2 | Servers
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
Figure 3: Relationship between EAP peer, authenticator and server Figure 3: Relationship between EAP peer, authenticator and server
Since an authenticator may have multiple ports, the scope of the
authenticator key cache may not be described by a single endpoint
address. Similarly, where a peer may have multiple ports and sharing
of EAP keying material and parameters between peer ports of the same
link type is allowed, the extent of the peer key cache cannot be
communicated by using a single endpoint address. Instead, it is
RECOMMENDED that the EAP peer and authenticator consistently identify
themselves utilizing explicit identifiers, rather than endpoint
addresses or port identifiers.
AAA protocols such as RADIUS [RFC3579] and Diameter [RFC4072] provide
a mechanism for the identification of AAA clients; since the EAP
authenticator and AAA client are always co-resident, this mechanism
is applicable to the identification of EAP authenticators.
RADIUS [RFC2865] requires that an Access-Request packet contain one
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 explicit identification of
the authenticator, both within the AAA protocol exchange and the
Secure Association Protocol conversation.
Problems which may arise where the peer and authenticator implicitly Problems which may arise where the peer and authenticator implicitly
identify themselves using endpoint addresses include the following: identify themselves using endpoint addresses include the following:
[a] It may not be obvious to the peer which authenticator ports are [a] It may not be obvious to the peer which authenticator ports are
associated with which authenticators. The EAP peer will be unable associated with which authenticators. The EAP peer will be unable
to determine whether EAP keying material has been shared outside to determine whether EAP keying material has been shared outside
its authorized scope, and needs to be considered compromised. The its authorized scope, and needs to be considered compromised. The
EAP peer may also be unable to utilize the authenticator key cache EAP peer may also be unable to utilize the authenticator key cache
in an efficient way. in an efficient way.
skipping to change at page 25, line 21 skipping to change at page 25, line 51
not correspond to the IP address or FQDN of a known backend not correspond to the IP address or FQDN of a known backend
authentication server, then the authenticator will not know which authentication server, then the authenticator will not know which
backend authentication server possesses the key. backend authentication server possesses the key.
3. Key Management 3. Key Management
EAP as defined in [RFC3748] supports key derivation, but does not EAP as defined in [RFC3748] supports key derivation, but does not
provide for the management of exported or derived keys. Missing provide for the management of exported or derived keys. Missing
functionality includes: functionality includes:
[a] Re-key. EAP does not support re-key of exported keys without re- [a] Re-key. EAP does not support re-key of exported keys without EAP
authentication, although EAP methods may support "fast reconnect" re-authentication, although EAP methods may support "fast
as defined in [RFC3748] Section 7.2.1. reconnect" as defined in [RFC3748] Section 7.2.1.
[b] Key delete/install semantics. EAP does not synchronize [b] Key delete/install semantics. EAP does not synchronize
installation or deletion of keying material on the EAP peer and installation or deletion of keying material on the EAP peer and
authenticator. authenticator.
[c] Lifetime negotiation. EAP does not support lifetime negotiation for [c] Lifetime negotiation. EAP does not support lifetime negotiation
exported keys, and existing EAP methods also do not support key for exported keys, and existing EAP methods also do not support key
lifetime negotiation. lifetime negotiation.
[d] Cryptographic algorithm negotiation. EAP methods only negotiate [d] Cryptographic algorithm negotiation. EAP methods only negotiate
cryptographic algorithms for their own use, not for the underlying cryptographic algorithms for their own use, not for the underlying
lower layers. lower layers.
[e] Guaranteed TSK freshness. Without a post-EAP handshake, TSKs can [e] Guaranteed TSK freshness. Without a post-EAP handshake, TSKs can
be reused if EAP keying material is cached. be reused if EAP keying material is cached.
These deficiencies are typically addressed via a post-EAP handshake These deficiencies are typically addressed via a post-EAP handshake
skipping to change at page 30, line 20 skipping to change at page 30, line 50
within the EAP method is defined by the method. Note that in within the EAP method is defined by the method. Note that in
general, when using fast reconnect, there is no guarantee to that the general, when using fast reconnect, there is no guarantee to that the
original long-term credentials are still in the possession of the original long-term credentials are still in the possession of the
peer. For instance, a card hold holding the private key for EAP-TLS peer. For instance, a card hold holding the private key for EAP-TLS
may have been removed. EAP servers SHOULD also verify that the long- may have been removed. EAP servers SHOULD also verify that the long-
term credentials are still valid, such as by checking that term credentials are still valid, such as by checking that
certificate used in the original authentication has not yet expired. certificate used in the original authentication has not yet expired.
3.5. Exported and Calculated Key Lifetimes 3.5. Exported and Calculated Key Lifetimes
All EAP methods generating keys are required to generate the MSK and The following mechanisms are available for communicating the lifetime
EMSK, and may optionally generate the IV. However, EAP, defined in of exported and calculated keying material between the EAP peer,
[RFC3748], does not itself support the negotiation of lifetimes for server and authenticator:
exported keying material such as the MSK, EMSK and IV.
Several mechanisms exist for managing key lifetimes: AAA protocols (backend server and authenticator)
Lower layer mechanisms (authenticator and peer)
EAP method-specific negotiation (peer and server)
[a] AAA attributes. AAA protocols such as RADIUS [RFC2865] and Where the EAP method does not support the negotiation of the lifetime
Diameter [RFC4072] support the Session-Timeout attribute. The of exported keys, and a key lifetime negotiation mechanism is not
Session-Timeout attribute represents the maximum lifetime of the provided by the lower layer, there may be no way for the peer to
exported keying material, and all keys depending on it, on the learn the lifetime of exported and calculated keys. This can leave
authenticator. Since existing backend authentication servers do the peer uncertain how long the authenticator will maintain EAP
not cache keys exported by EAP methods, or keys calculated from keying material within the key cache. In this case the lifetime of
exported keys, the value of the Session-Timeout attribute has no exported keys can be managed as a system parameter on the peer and
bearing on the key lifetime within the backend authentication authenticator; a default lifetime of 8 hours is RECOMMENDED.
server.
On the authenticator, where EAP is used for authentication the 3.5.1. AAA Protocols
Session-Timeout attribute represents the maximum session time prior
to re-authentication. As described in [RFC3580] Section 3.17, when AAA protocols such as RADIUS [RFC2865] and Diameter [RFC4072] can be
used to communicate the maximum exported key lifetime from the
backend authentication server to the authenticator.
The Session-Timeout attribue is defined for RADIUS in [RFC2865] and
for Diameter in [RFC4005]. Where EAP is used for authentication,
[RFC3580] Section 3.17 indicates that a Session-Timeout attribute
sent in an Access-Accept along with a Termination-Action value of sent in an Access-Accept along with a Termination-Action value of
RADIUS-Request, the Session-Timeout attribute specifies the maximum RADIUS-Request specifies the maximum number of seconds of service
number of seconds of service provided prior to re-authentication. provided prior to EAP re-authentication.
Where EAP is used for pre-authentication, the session may not start However, there is also a need to be able to specify the maximum
until some future time, or may never occur. Nevertheless, the lifetime of cached keying material. Where EAP pre-authentication is
Session-Timeout value represents the maximum time after which supported, cached keys can be pre-established on the authenticator
transported EAP keying material, and all keys dependent on it, will prior to session start, and will remain there until they expire. EAP
have expired on the authenticator. If the session subsequently lower layers supporting caching of exported keying material may also
starts, re-authentication will be initiated once the Session-Time persist that material after the end of a session, enabling the peer
has expired. If the session never started, or started and ended, by to subsequently resume communication utilizing the cached keying
default keys transported by AAA and all keys dependent on them be material. In these situations it may be desirable for the backend
expired by the authenticator prior to the future time indicated by authentication server to specify the maximum lifetime of cached
Session-Timeout; this feature is utilized by [IEEE-802.11i]. Note keying material.
that in future additional attributes may be specified to control
the lifetime of cached keys; these attributes may modify the To accomplish this, [IEEE-802.11i] overloaded the Session-Timeout
meaning of the Session-Timeout attribute in specific circumstances. attribute, assuming that it represents the maximum time after which
transported EAP keying material will expire on the authenticator,
regardless of whether transported keying material is cached.
An IEEE 802.11 authenticator receiving keying material is expected to
initialize a timer to the Session-Timeout value, and once the timer
expires, the exported keying material expires. Whether this results
in session termination or EAP re-authentication is controlled by the
value of the Termination-Action attribute. Where EAP re-
authentication occurs the exported keying material is replaced, and
with it, new calculated keys are put in place. Where session
termination occurs, exported and calculated keying material is
deleted.
Overloading the Session-Timeout attribute is problematic in
situations where it is necessary to control the maximum session time
and key lifetime independently. For example, it might be desirable
to limit the lifetime of cached keys to 5 minutes while permitting a
user once authenticated to remain connected for up to an hour without
re-authenticating. As a result, in the future additional attributes
may be specified to control the lifetime of cached keys; these
attributes may modify the meaning of the Session-Timeout attribute in
specific circumstances.
Since the TSK lifetime is often determined by authenticator Since the TSK lifetime is often determined by authenticator
resources, and the backend authentication server has no insight resources, and the backend authentication server has no insight into
into the TSK derivation process, by the principle of ciphersuite the TSK derivation process, by the principle of ciphersuite
independence, it is not appropriate for the backend authentication independence, it is not appropriate for the backend authentication
server to manage any aspect of the TSK derivation process, server to manage any aspect of the TSK derivation process, including
including the TSK lifetime. the TSK lifetime.
[b] Lower layer mechanisms. While AAA attributes can communicate the 3.5.2. Lower Layer Mechanisms
maximum exported key lifetime, this only serves to synchronize the
key lifetime between the backend authentication server and the Lower layer mechanisms can be used to enable the lifetime of exported
authenticator. Lower layer mechanisms such as the Secure and calculated keys to be negotiated between the peer and
Association Protocol can then be used to enable the lifetime of authenticator. This can be accomplished either using the Secure
exported and calculated keys to be negotiated between the peer and Association Protocol or within the lower layer transport.
authenticator.
Where TSKs are established as the result of a Secure Association Where TSKs are established as the result of a Secure Association
Protocol exchange, it is RECOMMENDED that the Secure Association Protocol exchange, it is RECOMMENDED that the Secure Association
Protocol include support for TSK re-key. Where the TSK is taken Protocol include support for TSK re-key. Where the TSK is taken
directly from the MSK, there is no need to manage the TSK lifetime directly from the MSK, there is no need to manage the TSK lifetime as
as a separate parameter, since the TSK lifetime and MSK lifetime a separate parameter, since the TSK lifetime and MSK lifetime are
are identical. identical.
[c] System defaults. Where the EAP method does not support the
negotiation of the lifetime of exported keys, and a key lifetime
negotiation mechanism is not provided by the lower lower, there may
be no way for the peer to learn the lifetime of exported keys. In
this case it is RECOMMENDED that the peer assume a default value; 8
hours is recommended. Similarly, the lifetime of calculated keys
can also be managed as a system parameter on the authenticator.
[d] Method specific negotiation within EAP. While EAP itself does not 3.5.3. EAP Method-Specific Negotiation
support lifetime negotiation, it would be possible to specify
methods that do. However, systems that rely on such negotiation
for exported keys would only function with these methods. In the
interest of method independence, key management of exported or
derived keys SHOULD NOT be provided within EAP methods.
3.6. Key cache synchronization All EAP methods generating keys are required to generate the MSK and
EMSK, and may optionally generate the IV. However, EAP, defined in
[RFC3748], does not itself support the negotiation of lifetimes for
exported keying material such as the MSK, EMSK and IV.
Issues arise when attempting to synchronize the key cache on the peer While EAP itself does not support lifetime negotiation, it would be
and authenticator. possible to specify methods that do. However, systems that rely on
such negotiation for exported keys would only function with these
methods. Also, there is no guarantee that the lifetime negotiated
within the EAP method would be compatible with backend authentication
server policy. In the interest of method independence and
compatibility with backend server implemenations, key management of
exported or derived keys SHOULD NOT be provided within EAP methods.
While the AAA protocol can enable the backend authentication server 3.6. Key Cache Synchronization
to provide guidance on the lifetime of transported EAP keying
material to the authenticator, this does not address the problem of
key lifetime synchronization between the peer and authenticator.
Where the EAP method does not negotiate the lifetime of exported
keys, the lifetime of the EAP keying material may not be defined
until completion of the Secure Association Protocol, if ever. This
can leave the peer uncertain how long the authenticator will maintain
EAP keying material within the key cache.
However, key lifetime negotiation alone cannot guarantee key cache Key lifetime negotiation alone cannot guarantee key cache
synchronization. Even where the Secure Association Protocol is run synchronization. Even where a lower layer exchange is run
immediately after EAP and determines the lifetime of EAP keying immediately after EAP in order to determine the lifetime of EAP
material, it is still possible for the authenticator to reclaim keying material, it is still possible for the authenticator to purge
resources. all or part of the key cache prematurely (e.g. due to reboot or need
to reclaim memory).
The lower layer may utilize the Discovery phase 0 to improve key The lower layer may utilize the Discovery phase 0 to improve key
cache synchronization. For example, if the authenticator manages the cache synchronization. For example, if the authenticator manages the
key cache by deleting the oldest key first (LIFO), the relative key cache by deleting the oldest key first, the relative creation
creation time of the last key to be deleted could be advertised time of the last key to be deleted could be advertised within the
within the Discovery phase, enabling the peer to determine whether Discovery phase, enabling the peer to determine whether keying
keying material had been prematurely expired from the authenticator material had been prematurely expired from the authenticator key
key cache. cache.
3.7. Key Strength 3.7. Key Strength
As noted in Section 2.1, EAP lower layers determine TSKs in different As noted in Section 2.1, EAP lower layers determine TSKs in different
ways. Where EAP keying material is utilized in the derivation, ways. Where EAP keying material is utilized in the derivation,
encryption or authentication of TSKs, it is possible for EAP key encryption or authentication of TSKs, it is possible for EAP key
generation to represent the weakest link. generation to represent the weakest link.
In order to ensure that EAP methods produce keying material of an In order to ensure that EAP methods produce keying material of an
appropriate symmetric key strength, it is RECOMMENDED that EAP appropriate symmetric key strength, it is RECOMMENDED that EAP
methods utilizing public key cryptography choose a public key that methods utilizing public key cryptography choose a public key that
has a cryptographic strength providing the required level of attack has a cryptographic strength providing the required level of attack
resistance. This is typically provided by configuring EAP methods, resistance. This is typically provided by configuring EAP methods,
since there is no coordination between the lower layer and EAP method since there is no coordination between the lower layer and EAP method
with respect to minimum required symmetric key strength. with respect to minimum required symmetric key strength.
As noted in [RFC3766] Section 5, this results in the following BCP 86 [RFC3766] offers advice on appropriate key sizes. The
required RSA or DH module and DSA subgroup size in bits, for a given National Institute for Standards and Technology (NIST) also offers
level of attack resistance in bits: advice on appropriate key sizes in [SP800-57].
[RFC3766] Section 5 advises use of the following required RSA or DH
module and DSA subgroup size in bits, for a given level of attack
resistance in bits:
Attack Resistance RSA or DH Modulus DSA subgroup Attack Resistance RSA or DH Modulus DSA subgroup
(bits) size (bits) size (bits) (bits) size (bits) size (bits)
----------------- ----------------- ------------ ----------------- ----------------- ------------
70 947 128 70 947 128
80 1228 145 80 1228 145
90 1553 153 90 1553 153
100 1926 184 100 1926 184
150 4575 279 150 4575 279
200 8719 373 200 8719 373
skipping to change at page 33, line 43 skipping to change at page 34, line 43
Diameter EAP [RFC4072], which defines clear-text key attributes, to Diameter EAP [RFC4072], which defines clear-text key attributes, to
be protected by IPsec or TLS. be protected by IPsec or TLS.
4. Handoff Vulnerabilities 4. Handoff Vulnerabilities
With EAP, several mechanisms are available to reduce the latency in With EAP, several mechanisms are available to reduce the latency in
handoff between authenticators: handoff between authenticators:
[a] EAP pre-authentication. This utilizes EAP to pre-establish EAP [a] EAP pre-authentication. This utilizes EAP to pre-establish EAP
keying material on an authenticator prior to arrival of the peer. keying material on an authenticator prior to arrival of the peer.
Use of pre-authentication within IEEE 802.11 is described in Use of EAP pre-authentication within IEEE 802.11 is described in
[8021XHandoff] and [IEEE-802.11i]. [8021XHandoff] and [IEEE-802.11i].
[b] Key caching. This mechanism enables an EAP peer to re-attach to an [b] Key caching. This mechanism enables an EAP peer to re-attach to an
authenticator without requiring EAP re-authentication. authenticator without requiring EAP re-authentication.
[c] Context transfer, such as is defined in [IEEE-802.11F] (now [c] Context transfer, such as is defined in [IEEE-802.11F] (now
deprecated) and [RFC4067]. Use of context transfer for handoff deprecated) and [RFC4067]. Use of context transfer for handoff
latency improvement is described in [IEEE-02-758]. latency improvement is described in [IEEE-02-758].
[d] Proactive key distribution, such as is described in [d] Proactive key distribution, such as is described in
skipping to change at page 34, line 37 skipping to change at page 35, line 37
described in Section 1.3, other than the potential introduction of a described in Section 1.3, other than the potential introduction of a
delay between Phase 1 and Phase 2. However, since a peer may complete delay between Phase 1 and Phase 2. However, since a peer may complete
EAP pre-authentication with an authenticator without eventually EAP pre-authentication with an authenticator without eventually
attaching to it, it is possible that Phase 2 will not occur. attaching to it, it is possible that Phase 2 will not occur.
[RFC3580] describes only minor differences in the AAA exchange [RFC3580] describes only minor differences in the AAA exchange
occurring as a result of EAP pre-authentication as compared with an occurring as a result of EAP pre-authentication as compared with an
ordinary EAP authentication exchange. For example, since in 802.11i ordinary EAP authentication exchange. For example, since in 802.11i
an Association exchange does not occur prior to EAP pre- an Association exchange does not occur prior to EAP pre-
authentication, the SSID is not yet known. As a result, an Access- authentication, the SSID is not yet known. As a result, an Access-
Request generated as the result of pre-authentication cannot include Request generated as the result of EAP pre-authentication cannot
the SSID within the Called-Station-Id attribute as described in include the SSID within the Called-Station-Id attribute as described
[RFC3580] Section 3.20. Since a peer may never associate with an in [RFC3580] Section 3.20. Since a peer may never associate with an
authenticator to which it pre-authenticated, an Accounting-Request authenticator to which it pre-authenticated, an Accounting-Request
signifying the start of service may never be sent, or may only be signifying the start of service may never be sent, or may only be
sent with a substantial delay after the completion of authentication. sent with a substantial delay after the completion of authentication.
Since an EAP pre-authentication exchange differs from an EAP Since an EAP pre-authentication exchange differs from an EAP
authentication exchange only in subtle ways, the backend authentication exchange only in subtle ways, the backend
authentication server may not be aware of whether it is engaging in a authentication server may not be aware of whether it is engaging in
pre-authentication exchange, resulting in operational or security an EAP pre-authentication exchange, resulting in operational or
problems. For example, where the authenticator does not include the security problems. For example, where the authenticator does not
SSID within the Called-Station-Id attribute in ordinary requests, include the SSID within the Called-Station-Id attribute in ordinary
pre-authentication requests may appear indistinguishable. As a requests, EAP pre-authentication requests may appear
result, the backend authentication server may not be able to indistinguishable. As a result, the backend authentication server may
correctly calculate the simultaneous sessions in progress, either not be able to correctly calculate the simultaneous sessions in
preventing successful completion of pre-authentication or enabling progress, either preventing successful completion of EAP pre-
the peer to engage in more simultaneous sessions than they are authentication or enabling the peer to engage in more simultaneous
authorized for. sessions than they are authorized for.
In order to allow backend authentication servers to handle pre- In order to allow backend authentication servers to handle EAP pre-
authentication requests more reliably, it is recommended that EAP authentication requests more reliably, it is recommended that EAP
pre-authentication requests be explicitly identified within AAA pre-authentication requests be explicitly identified within AAA
protocols. Also, in order to suppress unnecessary EAP pre- protocols. Also, in order to suppress unnecessary EAP pre-
authentication exchanges, it is recommended that authenticators authentication exchanges, it is recommended that authenticators
unambiguously identify themselves as described in Section 2.2.1, unambiguously identify themselves as described in Section 2.2.1,
allowing the peer to determine whether it has previously established allowing the peer to determine whether it has previously established
EAP keying material with that authenticator. EAP keying material with that authenticator.
4.2. Authorization 4.2. Authorization
skipping to change at page 52, line 16 skipping to change at page 53, line 16
IEEE-02-758r1-F Draft 802.11I/D5.0, November 2002. IEEE-02-758r1-F Draft 802.11I/D5.0, November 2002.
[IEEE-03-084] [IEEE-03-084]
Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang,
"Proactive Key Distribution to support fast and secure "Proactive Key Distribution to support fast and secure
roaming", IEEE 802.11 Working Group, IEEE-03-084r1-I, roaming", IEEE 802.11 Working Group, IEEE-03-084r1-I,
http://www.ieee802.org/11/Documents/DocumentHolder/ http://www.ieee802.org/11/Documents/DocumentHolder/
3-084.zip, January 2003. 3-084.zip, January 2003.
[I-D.housley-aaa-key-mgmt] [I-D.housley-aaa-key-mgmt]
Housley, R. and B. Aboba, "AAA Key Management", draft- Housley, R. and B. Aboba, "Guidance for AAA Key
housley-aaa-key-mgmt-02.txt, Internet draft (work in Management", draft-housley-aaa-key-mgmt-04.txt, Internet
progress), March 2006. draft (work in progress), October 2006.
[I-D.puthenkulam-eap-binding] [I-D.puthenkulam-eap-binding]
Puthenkulam, J., "The Compound Authentication Binding Puthenkulam, J., "The Compound Authentication Binding
Problem", draft-puthenkulam-eap-binding-04 (work in Problem", draft-puthenkulam-eap-binding-04 (work in
progress), October 2003. progress), October 2003.
[I-D.arkko-eap-service-identity-auth] [I-D.arkko-eap-service-identity-auth]
Arkko, J. and P. Eronen, "Authenticated Service Information Arkko, J. and P. Eronen, "Authenticated Service Information
for the Extensible Authentication Protocol (EAP)", draft- for the Extensible Authentication Protocol (EAP)", draft-
arkko-eap-service-identity-auth-02.txt (work in progress), arkko-eap-service-identity-auth-02.txt (work in progress),
skipping to change at page 54, line 51 skipping to change at page 55, line 51
Protocol Method for 3rd Generation Authentication and Key Protocol Method for 3rd Generation Authentication and Key
Agreement (EAP-AKA)", RFC 4187, January 2006. Agreement (EAP-AKA)", RFC 4187, January 2006.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
4306, December 2005. 4306, December 2005.
[RFC4372] Adrangi, F., Lior, A., Korhonen, J. and J. Loughney, [RFC4372] Adrangi, F., Lior, A., Korhonen, J. and J. Loughney,
"Chargeable User Identity", RFC 4372, January 2006. "Chargeable User Identity", RFC 4372, January 2006.
[RFC4334] Housley, R. and T. Moore, "Certificate Extensions and [RFC4334] Housley, R. and T. Moore, "Certificate Extensions and
Attributes Suporting Authenticatoin in Point-to-Point Attributes Suporting Authentication in Point-to-Point
Protocol (PPP) and Wireless Local Area Neworks (WLAN)", RFC Protocol (PPP) and Wireless Local Area Neworks (WLAN)", RFC
4334, February 2006. 4334, February 2006.
[SP800-57] National Institute of Standards and Technology,
"Recommendation for Key Management", Special Publication
800-57, May 2006.
[8021XHandoff] [8021XHandoff]
Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff in a Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff in a
Public Wireless LAN Based on IEEE 802.1X Model", School of Public Wireless LAN Based on IEEE 802.1X Model", School of
Computer Science and Engineering, Seoul National Computer Science and Engineering, Seoul National
University, Seoul, Korea, 2002. University, Seoul, Korea, 2002.
Acknowledgments Acknowledgments
Thanks to Ashwin Palekar, and Tim Moore of Microsoft, Jari Arkko of Thanks to Ashwin Palekar, and Tim Moore of Microsoft, Jari Arkko of
Ericsson, Dorothy Stanley of Aruba Networks, Bob Moskowitz of Ericsson, Dorothy Stanley of Aruba Networks, Bob Moskowitz of
skipping to change at page 57, line 15 skipping to change at page 58, line 15
Appendix A - Exported Parameters in Existing Methods Appendix A - Exported Parameters in Existing Methods
This Appendix specifies Session-Id, Peer-Id, Server-Id and Key- This Appendix specifies Session-Id, Peer-Id, Server-Id and Key-
Lifetime for EAP methods that have been published prior to this Lifetime for EAP methods that have been published prior to this
specification. Future EAP method specifications MUST include a specification. Future EAP method specifications MUST include a
definition of the Session-Id, Peer-Id, and Server-Id (could be the definition of the Session-Id, Peer-Id, and Server-Id (could be the
empty string). empty string).
EAP-Identity EAP-Identity
The EAP-Identity method is defined in [RC3748]. It does not The EAP-Identity method is defined in [RC3748]. It does not derive
derive keys, and therefore does not define the Session-Id. The keys, and therefore does not define the Session-Id. The Peer-Id
Peer-Id exported by the Identity method is determined by the exported by the Identity method is determined by the octets included
octets included within the EAP- Response/Identity. The Server-Id within the EAP- Response/Identity. The Server-Id is the empty string
is the empty string (zero length). (zero length).
EAP-Notification EAP-Notification
The EAP-Notification method is defined in [RFC3748]. It does not The EAP-Notification method is defined in [RFC3748]. It does not
derive keys and therefore does not define the Session-Id. The derive keys and therefore does not define the Session-Id. The Peer-
Peer-Id and Server-Id are the empty string (zero length). Id and Server-Id are the empty string (zero length).
EAP-GTC EAP-GTC
The EAP-GTC method is defined in [RFC3748]. It does not derive The EAP-GTC method is defined in [RFC3748]. It does not derive keys
keys and therefore does not define the Session-Id. The Peer-Id and therefore does not define the Session-Id. The Peer-Id and
and Server-Id are the empty string. Server-Id are the empty string.
EAP-OTP EAP-OTP
The EAP-OTP method is defined in [RFC3748]. It does not derive The EAP-OTP method is defined in [RFC3748]. It does not derive keys
keys and therefore does not define the Session-Id. The Peer-Id and therefore does not define the Session-Id. The Peer-Id and
and Server-Id are the empty string. Server-Id are the empty string.
EAP-TLS EAP-TLS
EAP-TLS is defined in [RFC2716]. The EAP-TLS Session-Id is the EAP-TLS is defined in [RFC2716]. The EAP-TLS Session-Id is the
concatenation of the EAP Type Code (0x0D) with the peer and server concatenation of the EAP Type Code (0x0D) with the peer and server
nonces. The Peer-Id and Server-Id are the contents of the nonces. The Peer-Id and Server-Id are the contents of the
altSubjectName in the peer and server certificates. altSubjectName in the peer and server certificates.
EAP-AKA EAP-AKA
EAP-AKA is defined in [RFC4187]. The EAP-AKA Session-Id is the EAP-AKA is defined in [RFC4187]. The EAP-AKA Session-Id is the
concatenation of the EAP Type Code (0x17) with the contents of the concatenation of the EAP Type Code (0x17) with the contents of the
RAND field from the AT_RAND attribute, followed by the contents of RAND field from the AT_RAND attribute, followed by the contents of
the AUTN field in the AT_AUTN attribute. the AUTN field in the AT_AUTN attribute.
The Peer-Id is the contents of the Identity field from the The Peer-Id is the contents of the Identity field from the
AT_IDENTITY attribute, using only the Actual Identity Length AT_IDENTITY attribute, using only the Actual Identity Length octets
octets from the beginning, however. Note that the contents are from the beginning, however. Note that the contents are used as they
used as they are transmitted, regardless of whether the are transmitted, regardless of whether the transmitted identity was a
transmitted identity was a permanent, pseudonym, or fast re- permanent, pseudonym, or fast EAP re-authentication identity. The
authentication identity. The Server-Id is an empty string. Server-Id is an empty string.
EAP-SIM EAP-SIM
EAP-SIM is defined in [RFC4186]. The EAP-SIM Session-Id is the EAP-SIM is defined in [RFC4186]. The EAP-SIM Session-Id is the
concatenation of the EAP Type Code (0x12) with the contents of the concatenation of the EAP Type Code (0x12) with the contents of the
RAND field from the AT_RAND attribute, followed by the contents of RAND field from the AT_RAND attribute, followed by the contents of
the NONCE_MT field in the AT_NONCE_MT attribute. the NONCE_MT field in the AT_NONCE_MT attribute.
The Peer-Id is the contents of the Identity field from the The Peer-Id is the contents of the Identity field from the
AT_IDENTITY attribute, using only the Actual Identity Length AT_IDENTITY attribute, using only the Actual Identity Length octets
octets from the beginning, however. Note that the contents are from the beginning, however. Note that the contents are used as they
used as they are transmitted, regardless of whether the are transmitted, regardless of whether the transmitted identity was a
transmitted identity was a permanent, pseudonym, or fast re- permanent, pseudonym, or fast EAP re-authentication identity. The
authentication identity. The Server-Id is an empty string. Server-Id is an empty string.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed to
to pertain to the implementation or use of the technology pertain to the implementation or use of the technology described in
described in this document or the extent to which any license this document or the extent to which any license under such rights
under such rights might or might not be available; nor does it might or might not be available; nor does it represent that it has
represent that it has made any independent effort to identify any made any independent effort to identify any such rights. Information
such rights. Information on the procedures with respect to rights on the procedures with respect to rights in RFC documents can be
in RFC documents can be found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use attempt made to obtain a general license or permission for the use of
of such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository specification can be obtained from the IETF on-line IPR repository at
at http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention The IETF invites any interested party to bring to its attention any
any copyrights, patents or patent applications, or other copyrights, patents or patent applications, or other proprietary
proprietary rights that may cover technology that may be required rights that may cover technology that may be required to implement
to implement this standard. Please address the information to the this standard. Please address the information to the IETF at ietf-
IETF at ietf-ipr@ietf.org. ipr@ietf.org.
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on This document and the information contained herein are provided on an
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2006). This document is Copyright (C) The Internet Society (2006). This document is subject
subject to the rights, licenses and restrictions contained in BCP to the rights, licenses and restrictions contained in BCP 78, and
78, and except as set forth therein, the authors retain all their except as set forth therein, the authors retain all their rights.
rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
Open Issues Open Issues
Open issues relating to this specification are tracked on the Open issues relating to this specification are tracked on the
following web site: following web site:
 End of changes. 62 change blocks. 
283 lines changed or deleted 336 lines changed or added

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