draft-ietf-eap-keying-16.txt   draft-ietf-eap-keying-17.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-16.txt> P. Eronen <draft-ietf-eap-keying-17.txt> P. Eronen
2 January 2007 Nokia 19 January 2007 Nokia
H. Levkowetz H. Levkowetz
Ericsson Research Ericsson Research
Extensible Authentication Protocol (EAP) Key Management Framework Extensible Authentication Protocol (EAP) Key Management Framework
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 10, 2007. This Internet-Draft will expire on July 18, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). All rights reserved. Copyright (C) The IETF Trust (2007). All rights reserved.
Abstract Abstract
The Extensible Authentication Protocol (EAP), defined in [RFC3748], The Extensible Authentication Protocol (EAP), defined in [RFC3748],
enables extensible network access authentication. This document enables extensible network access authentication. This document
provides a framework for the transport and usage of keying material provides a framework for the transport and usage of keying material
skipping to change at page 2, line 18 skipping to change at page 2, line 18
1.1 Requirements Language ........................... 3 1.1 Requirements Language ........................... 3
1.2 Terminology ..................................... 3 1.2 Terminology ..................................... 3
1.3 Overview ........................................ 6 1.3 Overview ........................................ 6
1.4 EAP Key Hierarchy ............................... 9 1.4 EAP Key Hierarchy ............................... 9
1.5 Security Goals .................................. 13 1.5 Security Goals .................................. 13
1.6 EAP Invariants .................................. 14 1.6 EAP Invariants .................................. 14
2. Lower Layer Operation ................................. 17 2. Lower Layer Operation ................................. 17
2.1 Transient Session Keys .......................... 18 2.1 Transient Session Keys .......................... 18
2.2 Authenticator and Peer Architecture ............. 19 2.2 Authenticator and Peer Architecture ............. 19
2.3 Server Identification ........................... 24 2.3 Server Identification ........................... 24
3. Key Management ........................................ 26 3. Security Association Management ....................... 26
3.1 Secure Association Protocol ..................... 26 3.1 Secure Association Protocol ..................... 26
3.2 Key Scope ....................................... 29 3.2 Key Scope ....................................... 29
3.3 Parent-Child Relationships ...................... 30 3.3 Parent-Child Relationships ...................... 30
3.4 Local Key Lifetimes ............................. 30 3.4 Local Key Lifetimes ............................. 31
3.5 Exported and Calculated Key Lifetimes ........... 31 3.5 Exported and Calculated Key Lifetimes ........... 31
3.6 Key Cache Synchronization ....................... 33 3.6 Key Cache Synchronization ....................... 33
3.7 Key Strength .................................... 33 3.7 Key Strength .................................... 34
3.8 Key Wrap ........................................ 34 3.8 Key Wrap ........................................ 34
4. Handoff Vulnerabilities ............................... 34 4. Handoff Vulnerabilities ............................... 35
4.1 EAP Pre-authentication .......................... 35 4.1 EAP Pre-authentication .......................... 36
4.2 Authorization ................................... 36 4.2 Proactive Key Distribution ...................... 37
4.3 Correctness ..................................... 37 4.3 AAA Bypass ...................................... 39
5. Security Considerations .............................. 40 5. Security Considerations .............................. 43
5.1 Authenticator Compromise ........................ 41 5.1 Authenticator Compromise ........................ 44
5.2 Spoofing ........................................ 42 5.2 Spoofing ........................................ 45
5.3 Downgrade Attacks ............................... 43 5.3 Downgrade Attacks ............................... 45
5.4 Unauthorized Disclosure ......................... 43 5.4 Unauthorized Disclosure ......................... 46
5.5 Replay Protection ............................... 45 5.5 Replay Protection ............................... 48
5.6 Key Freshness ................................... 46 5.6 Key Freshness ................................... 48
5.7 Elevation of Privilege .......................... 47 5.7 Elevation of Privilege .......................... 49
5.8 Man-in-the-Middle Attacks ....................... 48 5.8 Man-in-the-Middle Attacks ....................... 50
5.9 Denial of Service Attacks ....................... 48 5.9 Denial of Service Attacks ....................... 51
5.10 Impersonation ................................... 49 5.10 Impersonation ................................... 51
5.11 Channel Binding ................................. 50 5.11 Channel Binding ................................. 52
6. IANA Considerations ................................... 51 6. IANA Considerations ................................... 54
7. References ............................................ 51 7. References ............................................ 54
7.1 Normative References ............................ 51 7.1 Normative References ............................ 54
7.2 Informative References .......................... 51 7.2 Informative References .......................... 54
Acknowledgments .............................................. 56 Acknowledgments .............................................. 60
Author's Addresses ........................................... 57 Author's Addresses ........................................... 60
Appendix A - Exported Parameters in Existing Methods ......... 58 Appendix A - Exported Parameters in Existing Methods ......... 61
Intellectual Property Statement .............................. 60 Intellectual Property Statement .............................. 63
Disclaimer of Validity ....................................... 60 Disclaimer of Validity ....................................... 63
Copyright Statement .......................................... 60 Copyright Statement .......................................... 63
1. Introduction 1. Introduction
The Extensible Authentication Protocol (EAP), defined in [RFC3748], The Extensible Authentication Protocol (EAP), defined in [RFC3748],
was designed to enable extensible authentication for network access was designed to enable extensible authentication for network access
in situations in which the Internet Protocol (IP) protocol is not in situations in which the Internet Protocol (IP) protocol is not
available. Originally developed for use with Point-to-Point Protocol available. Originally developed for use with Point-to-Point Protocol
(PPP) [RFC1661], it has subsequently also been applied to IEEE 802 (PPP) [RFC1661], it has subsequently also been applied to IEEE 802
wired networks [IEEE-802.1X], wireless networks such as wired networks [IEEE-802.1X], IKEv2 [RFC4306] and wireless networks
[IEEE-802.11i], [IEEE-802.16e], and IKEv2 [RFC4306]. such as [IEEE-802.11i] and [IEEE-802.16e].
EAP is a two-party protocol spoken between the EAP peer and server.
Within EAP, keying material is generated by EAP authentication
algorithms, known as "methods". Part of this keying material may be
used by EAP methods themselves and part of this material may be
exported. In addition to export of keying material, EAP methods may
also export associated parameters such as authenticated peer and
server identities and a unique EAP conversation identifier, and may
import and export lower layer parameters known as "Channel Bindings".
This document provides a framework for the transport and usage of This document provides a framework for the transport and usage of
keying material generated by EAP authentication algorithms, known as keying material and parameters generated by EAP methods, as well as
"methods". In EAP, keying material is generated by EAP methods. specifying the EAP key hierarchy. It also provides a system-level
Part of this keying material may be used by EAP methods themselves security analysis.
and part of this material may be exported. The exported keying
material may be transported by Authentication, Authorization and
Accounting (AAA) protocols and used by Secure Association Protocols
in the generation or transport of session keys which are used by
lower layer ciphersuites. This document describes each of these
elements and provides a system-level security analysis. It also
specifies the EAP key hierarchy.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.2. Terminology 1.2. Terminology
The terms "Cryptographic binding", "Cryptographic separation", "Key The terms "Cryptographic binding", "Cryptographic separation", "Key
skipping to change at page 4, line 44 skipping to change at page 4, line 48
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.
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. The EMSK MUST be
at least as long as the MSK in size.
Initialization Vector (IV) Initialization Vector (IV)
A quantity of at least 64 octets, suitable for use in an A quantity of at least 64 octets, suitable for use in an
initialization vector field, that is derived between the peer and initialization vector field, that is derived between the peer and
EAP server. Since the IV is a known value in methods such as EAP- EAP server. Since the IV is a known value in methods such as EAP-
TLS [RFC2716], it cannot be used by itself for computation of any TLS [I-D.simon-emu-rfc2716bis], it cannot be used by itself for
quantity that needs to remain secret. As a result, its use has computation of any quantity that needs to remain secret. As a
been deprecated and EAP methods are not required to generate it. result, its use has been deprecated and EAP methods are not
However, when it is generated it MUST be unpredictable. required to generate it. However, when it is generated it MUST be
unpredictable.
Key Scope Key Scope
The parties to whom a key is available. The parties to whom a key is available.
Key Wrap Key Wrap
The encryption of one symmetric cryptographic key in another. The The encryption of one symmetric cryptographic key in another. The
algorithm used for the encryption is called a key wrap algorithm or algorithm used for the encryption is called a key wrap algorithm or
a key encryption algorithm. The key used in the encryption process a key encryption algorithm. The key used in the encryption process
is called a key-encryption key (KEK). is called a key-encryption key (KEK).
skipping to change at page 7, line 24 skipping to change at page 7, line 29
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 (see Section In order to obey the principle of mode independence (see Section
1.6.1), where a backend server is present, all keying material which 1.6.1), where a backend server is present, all keying material which
is required by the lower layer needs to be transported from the EAP is required by the lower layer needs to be transported from the EAP
server to the authenticator. Since existing TSK derivation and server to the authenticator. Since existing TSK derivation and
transport techniques depend solely on the MSK, in existing transport techniques depend solely on the MSK, in existing
implementations, this is the only keying material replicated in the implementations, this is the only keying material replicated in the
AAA key transport phase 1b. AAA key transport phase 1b.
Successful completion of EAP authentication and key derivation by a
peer and EAP server does not necessarily imply that the peer is
committed to joining the network associated with an EAP server.
Rather, this commitment is implied by the creation of a security
association between the EAP peer and authenticator, as part of the
Secure Association Protocol (phase 2). The Secure Association
Protocol exchange (phase 2) occurs between the peer and authenticator
in order to manage the creation and deletion of unicast (phase 2a)
and multicast (phase 2b) security associations between the peer and
authenticator. The conversation between the parties is shown in
Figure 1.
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) |
|<----------------------------->| | |<----------------------------->| |
| Unicast Secure association | | | Unicast Secure association | |
| (phase 2a) | | | (phase 2a) | |
| | | | | |
|<----------------------------->| | |<----------------------------->| |
| Multicast Secure association | | | Multicast Secure association | |
| (optional; phase 2b) | | | (optional; phase 2b) | |
| | | | | |
Figure 1: Conversation Overview Figure 1: Conversation Overview
Successful completion of EAP authentication and key derivation by a
peer and EAP server does not necessarily imply that the peer is
committed to joining the network associated with an EAP server.
Rather, this commitment is implied by the creation of a security
association between the EAP peer and authenticator, as part of the
Secure Association Protocol (phase 2). The Secure Association
Protocol exchange (phase 2) occurs between the peer and authenticator
in order to manage the creation and deletion of unicast (phase 2a)
and multicast (phase 2b) security associations between the peer and
authenticator. The conversation between the parties is shown in
Figure 1.
1.3.1. Examples 1.3.1. Examples
Existing EAP lower layers implement phase 0, 2a and 2b in different Existing EAP lower layers implement phase 0, 2a and 2b in different
ways: ways:
PPP Point-to-Point Protocol (PPP), defined in [RFC1661] does not PPP Point-to-Point Protocol (PPP), defined in [RFC1661] does not
support discovery, nor does it include a Secure Association support discovery, nor does it include a Secure Association
Protocol. Protocol.
skipping to change at page 9, line 18 skipping to change at page 9, line 26
points periodically announce their Service Set Identifiers (SSIDs) points periodically announce their Service Set Identifiers (SSIDs)
as well as capabilities using Beacon frames. Stations can query as well as capabilities using Beacon frames. Stations can query
for access points by sending a Probe Request to the broadcast for access points by sending a Probe Request to the broadcast
address. Neither Beacon nor Probe Request/Response frames are address. Neither Beacon nor Probe Request/Response frames are
secured. The 4-way handshake defined in [IEEE-802.11i] enables the secured. The 4-way handshake defined in [IEEE-802.11i] enables the
derivation of unicast (phase 2a) and multicast/broadcast (phase 2b) derivation of unicast (phase 2a) and multicast/broadcast (phase 2b)
secure associations. Since the group key exchange transports a secure associations. Since the group key exchange transports a
group key from the access point to the station, two 4-way group key from the access point to the station, two 4-way
handshakes may be required in order to support peer-to-peer handshakes may be required in order to support peer-to-peer
communications. A proof of the security of the IEEE 802.11i 4-way communications. A proof of the security of the IEEE 802.11i 4-way
handshake when used with EAP-TLS [RFC2716], is provided in [He]. handshake when used with EAP-TLS is provided in [He].
IEEE 802.1X IEEE 802.1X
IEEE 802.1X-2004, defined in [IEEE-802.1X] does not support IEEE 802.1X-2004, defined in [IEEE-802.1X] does not support
discovery (phase 0), nor does it provide for derivation of unicast discovery (phase 0), nor does it provide for derivation of unicast
or multicast secure associations. or multicast secure associations.
1.4. EAP Key Hierarchy 1.4. EAP Key Hierarchy
EAP, defined in [RFC3748], is a two-party protocol spoken between the
EAP peer and server. Within EAP, keying material is generated by EAP
methods. Part of this keying material may be used by EAP methods
themselves and part of this material may be exported. In addition to
export of keying material, EAP methods may also export associated
parameters, and may import and export Channel Bindings from the lower
layer.
As illustrated in Figure 2, the EAP method key derivation has at the As illustrated in Figure 2, the EAP method key derivation has at the
root the long term credential utilized by the selected EAP method. root the long term credential utilized by the selected EAP method.
If authentication is based on a pre-shared key, the parties store the If authentication is based on a pre-shared key, the parties store the
EAP method to be used and the pre-shared key. The EAP server also EAP method to be used and the pre-shared key. The EAP server also
stores the peer's identity as well as additional information. This stores the peer's identity as well as additional information. This
information is typically used outside of the EAP method to determine information is typically used outside of the EAP method to determine
if access to some service should be granted. The peer stores if access to some service should be granted. The peer stores
information necessary to choose which secret to use for which information necessary to choose which secret to use for which
service. service.
skipping to change at page 12, line 36 skipping to change at page 12, line 36
Server-Id (also only if securely exchanged). Where a peer or server Server-Id (also only if securely exchanged). Where a peer or server
name is missing the null string is used. name is missing the null string is used.
MSK and EMSK Names MSK and EMSK Names
These parameters are exported by the EAP peer and EAP server, and These parameters are exported by the EAP peer and EAP server, and
can be referred to using the EAP Session-Id and a binary or textual can be referred to using the EAP Session-Id and a binary or textual
indication of the parameter being referred to. indication of the 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 name of the key from which it is
derived.
Note: IEEE 802.11i names the PMKID for the purposes of being able Note: IEEE 802.11i names the PMKID for the purposes of being able
to refer to it in the Secure Association protocol; this naming is to refer to it in the Secure Association protocol; this naming is
based on a hash of the PMK itself as well as some other parameters based on a hash of the PMK itself as well as some other parameters
(see Section 8.5.1.2 [IEEE-802.11i]). (see Section 8.5.1.2 [IEEE-802.11i]).
TEK Name TEK Name
The TEKs may or may not be named. Their naming is specified in the The TEKs may or may not be named. Their naming is specified in the
EAP method. EAP method.
skipping to change at page 14, line 52 skipping to change at page 14, line 52
The successful completion of an EAP method that supports key The successful completion of an EAP method that supports key
derivation results in the export of keying material and parameters on derivation results in the export of keying material and parameters on
the EAP peer and server. Even though the EAP peer or server may the EAP peer and server. Even though the EAP peer or server may
import Channel Bindings that may include the identity of the EAP import Channel Bindings that may include the identity of the EAP
authenticator, this information is treated as opaque octets. As a authenticator, this information is treated as opaque octets. As a
result, within EAP the only relevant identities are the Peer-Id and result, within EAP the only relevant identities are the Peer-Id and
Server-Id. Channel Bindings are only interpreted by the lower layer. Server-Id. Channel Bindings are only interpreted by the lower layer.
Within EAP, the primary function of the AAA protocol is to maintain Within EAP, the primary function of the AAA protocol is to maintain
the principle of Mode Independence, so that as far as the EAP peer is the principle of mode independence, so that as far as the EAP peer is
concerned, its conversation with the EAP authenticator, and all concerned, its conversation with the EAP authenticator, and all
consequences of that conversation, are identical, regardless of the consequences of that conversation, are identical, regardless of the
authenticator mode of operation. authenticator mode of operation.
1.6.2. Media Independence 1.6.2. Media Independence
One of the goals of EAP is to allow EAP methods to function on any One of the goals of EAP is to allow EAP methods to function on any
lower layer meeting the criteria outlined in [RFC3748], Section 3.1. lower layer meeting the criteria outlined in [RFC3748], Section 3.1.
For example, as described in [RFC3748], EAP authentication can be run For example, as described in [RFC3748], EAP authentication can be run
over PPP [RFC1661], IEEE 802 wired networks [IEEE-802.1X], and over PPP [RFC1661], IEEE 802 wired networks [IEEE-802.1X], and
skipping to change at page 17, line 45 skipping to change at page 17, line 45
to another entity. For example, EAP keying material passed down to to another entity. For example, EAP keying material passed down to
the EAP peer lower layer MUST NOT leave the peer; EAP keying the EAP peer lower layer MUST NOT leave the peer; EAP keying
material passed down or transported to the EAP authenticator lower material passed down or transported to the EAP authenticator lower
layer MUST NOT leave the authenticator. layer MUST NOT leave the authenticator.
On the EAP server, keying material and parameters requested by and On the EAP server, keying material and parameters requested by and
passed down to the AAA layer may be replicated to the AAA layer on passed down to the AAA layer may be replicated to the AAA layer on
the authenticator (with the exception of the EMSK). On the the authenticator (with the exception of the EMSK). On the
authenticator, the AAA layer provides the replicated keying material authenticator, the AAA layer provides the replicated keying material
and parameters to the lower layer over which the EAP authentication and parameters to the lower layer over which the EAP authentication
conversation took place. This enables "mode independence" to be conversation took place. This enables mode independence to be
maintained. maintained.
The EAP layer as well as the peer and authenticator layers MUST NOT The EAP layer as well as the peer and authenticator layers MUST NOT
modify or cache keying material or parameters (including Channel modify or cache keying material or parameters (including Channel
Bindings) passing in either direction between the EAP method layer Bindings) passing in either direction between the EAP method layer
and the lower layer or AAA layer. and the lower layer or AAA layer.
2.1. Transient Session Keys 2.1. Transient Session Keys
Where explicitly supported by the lower layer, lower layers MAY cache Where explicitly supported by the lower layer, lower layers MAY cache
skipping to change at page 18, line 26 skipping to change at page 18, line 26
different ways: different ways:
IEEE 802.1X-2004 IEEE 802.1X-2004
IEEE 802.1X-2004, defined in [IEEE-802.1X] does not support caching IEEE 802.1X-2004, defined in [IEEE-802.1X] does not support caching
of EAP keying material or parameters. Once EAP authentication of EAP keying material or parameters. Once EAP authentication
completes, it is assumed that EAP keying material and parameters completes, it is assumed that EAP keying material and parameters
are discarded. are discarded.
PPP PPP, defined in [RFC1661] does not support caching of EAP keying PPP PPP, defined in [RFC1661] does not support caching of EAP keying
material or parameters. PPP ciphersuites derive their TSKs material or parameters. PPP ciphersuites derive their TSKs
directly from the MSK, as described in [RFC2716]. This method is directly from the MSK, as described in [I-D.simon-emu-rfc2716bis].
NOT RECOMMENDED, since if PPP were to support caching, this could This method is NOT RECOMMENDED, since if PPP were to support
result in TSK reuse. As a result, once the PPP session is caching, this could result in TSK reuse. As a result, once the PPP
terminated, EAP keying material and parameters MUST be discarded. session is terminated, EAP keying material and parameters MUST be
Since caching of EAP keying material is not permitted, within PPP discarded. Since caching of EAP keying material is not permitted,
there is no way to handle TSK re-key without EAP re-authentication. within PPP there is no way to handle TSK re-key without EAP re-
Perfect Forward Secrecy (PFS) is only possible if the negotiated authentication. Perfect Forward Secrecy (PFS) is only possible if
EAP method supports this. the negotiated EAP method supports this.
IKEv2 IKEv2
IKEv2, defined in [RFC4306] only uses the MSK for authentication IKEv2, defined in [RFC4306] only uses the MSK for authentication
purposes and not key derivation. The EMSK, IV, Peer-Id, Server-Id purposes and not key derivation. The EMSK, IV, Peer-Id, Server-Id
or Session-Id are not used. As a result, the keying material or Session-Id are not used. As a result, the keying material
derived within IKEv2 is independent of the EAP keying material and derived within IKEv2 is independent of the EAP keying material and
re-key of IPsec SAs can be handled without requiring EAP re- re-key of IPsec SAs can be handled without requiring EAP re-
authentication. Since generation of keying material is independent authentication. Since generation of keying material is independent
of EAP, within IKEv2 it is possible to negotiate PFS, regardless of of EAP, within IKEv2 it is possible to negotiate PFS, regardless of
the EAP method that is used. IKEv2 as specified in [RFC4306] does the EAP method that is used. IKEv2 as specified in [RFC4306] does
skipping to change at page 19, line 37 skipping to change at page 19, line 37
In order to avoid key reuse, the AAA layer MUST delete transported In order to avoid key reuse, the AAA layer MUST delete transported
keys once they are sent. The AAA layer MUST NOT retain keys that keys once they are sent. The AAA layer MUST NOT retain keys that
it has previously sent. For example, a AAA layer that has it has previously sent. For example, a AAA layer that has
transported the MSK MUST delete it, and keys MUST NOT be derived transported the MSK MUST delete it, and keys MUST NOT be derived
from the MSK from that point forward. from the MSK from that point forward.
2.2. Authenticator and Peer Architecture 2.2. Authenticator and Peer Architecture
This specification does not impose constraints on the architecture of This specification does not impose constraints on the architecture of
the EAP authenticator or peer. Any of the authenticator architectures the EAP authenticator or peer. Any of the authenticator
described in [RFC4118] can be used. As a result, lower layers need to architectures described in [RFC4118] can be used. As a result, lower
identify EAP peers and authenticators unambiguously, without layers need to identify EAP peers and authenticators unambiguously,
incorporating implicit assumptions about peer and authenticator without incorporating implicit assumptions about peer and
architectures. authenticator architectures.
For example, it is possible for multiple base stations and a For example, it is possible for multiple base stations and a
"controller" (e.g. WLAN switch) to comprise a single EAP "controller" (e.g. WLAN switch) to comprise a single EAP
authenticator. In such a situation, the "base station identity" is authenticator. In such a situation, the "base station identity" is
irrelevant to the EAP method conversation, except perhaps as an irrelevant to the EAP method conversation, except perhaps as an
opaque blob to be used in Channel Bindings. Many base stations can opaque blob to be used in Channel Bindings. Many base stations can
share the same authenticator identity. It should be understood that share the same authenticator identity. It should be understood that
an EAP authenticator or peer: an EAP authenticator or peer:
[a] may contain one or more physical or logical ports; [a] may contain one or more physical or logical ports;
skipping to change at page 24, line 13 skipping to change at page 24, line 13
key caches for each "virtual authenticator". key caches for each "virtual authenticator".
[c] It is RECOMMENDED that each "virtual authenticator" identify itself [c] It is RECOMMENDED that each "virtual authenticator" identify itself
consistently to the peer and to the backend authentication server, consistently to the peer and to the backend authentication server,
so as to enable the peer to verify the authenticator identity via so as to enable the peer to verify the authenticator identity via
Channel Bindings (see Section 5.11). Channel Bindings (see Section 5.11).
[d] It is RECOMMENDED that each "virtual authenticator" identify itself [d] It is RECOMMENDED that each "virtual authenticator" identify itself
distinctly, in order to enable the peer and backend server to tell distinctly, in order to enable the peer and backend server to tell
them apart. For example, this can be accomplished by utilizing a them apart. For example, this can be accomplished by utilizing a
distinct NAS-Identifier attribute or BSSID. distinct NAS-Identifier attribute.
2.3. Server Identification 2.3. Server Identification
The EAP method conversation is between the EAP peer and server, as The EAP method conversation is between the EAP peer and server, as
identified by the Peer-Id and Server-Id. As shown in Figure 3, an identified by the Peer-Id and Server-Id. As shown in Figure 3, an
authenticator may be configured to communicate with multiple EAP authenticator may be configured to communicate with multiple EAP
servers; the EAP server that an authenticator communicates with may servers; the EAP server that an authenticator communicates with may
vary according to configuration and network and server availability. vary according to configuration and network and server availability.
While the EAP peer can assume that all EAP servers within a realm While the EAP peer can assume that all EAP servers within a realm
have access to the credentials necessary to validate an have access to the credentials necessary to validate an
skipping to change at page 25, line 20 skipping to change at page 25, line 20
EAP methods that support mutual authentication may not allow the EAP EAP methods that support mutual authentication may not allow the EAP
peer to verify the EAP server identity. For example, the EAP peer peer to verify the EAP server identity. For example, the EAP peer
may only verify that the EAP server possesses a long-term secret; in may only verify that the EAP server possesses a long-term secret; in
this case the EAP peer will only know that an authenticator has been this case the EAP peer will only know that an authenticator has been
authorized by an EAP server, but will not confirm the identity of the authorized by an EAP server, but will not confirm the identity of the
EAP server. EAP server.
EAP methods that export the Server-Id MUST verify the server EAP methods that export the Server-Id MUST verify the server
identity. As noted in Appendix A, existing EAP methods exporting the identity. As noted in Appendix A, existing EAP methods exporting the
Server-Id determine this from the altSubjectName in the server Server-Id determine this from the subjectAltName in the server
certificate, and as a result, the peer determines the identity of the certificate, and as a result, the peer determines the identity of the
server (expressed as a Fully Qualified Domain Name (FQDN)) by server (expressed as a Fully Qualified Domain Name (FQDN)) by
validating the server certificate. validating the server certificate.
Validating the EAP server identity may help the EAP peer to decide Validating the EAP server identity may help the EAP peer to decide
whether a specific EAP server is authorized, and to determine whether whether a specific EAP server is authorized, and to determine whether
the EAP server is sharing keying material outside the intended scope. the EAP server is sharing keying material outside the intended scope.
In some cases, such as where the certificate extensions defined in In some cases, such as where the certificate extensions defined in
[RFC4334] are included in the server certificate, it may even be [RFC4334] are included in the server certificate, it may even be
possible for the peer to verify some Channel Binding parameters from possible for the peer to verify some Channel Binding parameters from
the server certificate. Where the EAP peer does not verify the EAP the server certificate. Where the EAP peer does not verify the EAP
server identity, it is not possible for the peer to determine whether server identity, it is not possible for the peer to determine whether
the EAP server has shared keying material outside its authorized the EAP server has shared keying material outside its authorized
scope. scope.
It is possible for problems to arise in situations where the EAP It is possible for problems to arise in situations where the EAP
server identifies itself differently to the EAP peer and server identifies itself differently to the EAP peer and
authenticator. For example, the Server-Id exported by EAP methods authenticator. For example, the Server-Id exported by EAP methods
may not be identical to the Fully Qualified Domain Name (FQDN) of the may not be identical to the Fully Qualified Domain Name (FQDN) of the
backend authentication server. Where certificate-based backend authentication server. Where certificate-based
authentication is used within RADIUS or Diameter, the altSubjectName authentication is used within RADIUS or Diameter, the subjectAltName
used in the backend server certificate may not be identical to the used in the backend server certificate may not be identical to the
Server-Id or backend server FQDN. Server-Id or backend server FQDN.
Where the backend server FQDN differs from the altSubjectName in the Where the backend server FQDN differs from the subjectAltName in the
certificate, the AAA client may not be able to successfully determine certificate, the AAA client may not be able to successfully determine
whether it is talking to the correct backend authentication server. whether it is talking to the correct backend authentication server.
Where the Server-Id and backend server FQDN differ, the combination Where the Server-Id and backend server FQDN differ, the combination
of the key scope (Peer-Id, Server-Id) and EAP conversation identifier of the key scope (Peer-Id, Server-Id) and EAP conversation identifier
(Session-Id) may not be sufficient for the authenticator to determine (Session-Id) may not be sufficient for the authenticator to determine
where the key resides. For example, the authenticator may identify where the key resides. For example, the authenticator may identify
backend servers by their IP address (as occurs in RADIUS), or using a backend servers by their IP address (as occurs in RADIUS), or using a
Fully Qualified Domain Name (as in Diameter). If the Server-Id does Fully Qualified Domain Name (as in Diameter). If the Server-Id does
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. Security Association Management
EAP as defined in [RFC3748] supports key derivation, but does not EAP as defined in [RFC3748] supports key derivation, but does not
provide for the management of exported or derived keys. Missing provide for the management of lower layer security associations.
functionality includes: Missing functionality includes:
[a] Re-key. EAP does not support re-key of exported keys without EAP [a] Security Association negotiation. EAP does not negotiate lower
layer unicast or multicast security associations, including
cryptographic algorithms or traffic profiles. EAP methods only
negotiate cryptographic algorithms for their own use, not for the
underlying lower layers. EAP also does not negotiate the traffic
profiles to be protected with the negotiated ciphersuites; in some
cases the traffic to be protected may have lower layer source and
destination addresses different from the lower layer peer or
authenticator addresses.
[b] Re-key. EAP does not support re-key of exported keys without EAP
re-authentication, although EAP methods may support "fast re-authentication, although EAP methods may support "fast
reconnect" as defined in [RFC3748] Section 7.2.1. reconnect" as defined in [RFC3748] Section 7.2.1.
[b] Key delete/install semantics. EAP does not synchronize [c] Key delete/install semantics. EAP does not synchronize
installation or deletion of keying material on the EAP peer and installation or deletion of keying material on the EAP peer and
authenticator. authenticator.
[c] Lifetime negotiation. EAP does not support lifetime negotiation [d] Lifetime negotiation. EAP does not support lifetime negotiation
for exported keys, and existing EAP methods also do not support key for exported keys, and existing EAP methods also do not support key
lifetime negotiation. lifetime negotiation.
[d] Cryptographic algorithm negotiation. EAP methods only negotiate
cryptographic algorithms for their own use, not for the underlying
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
known as the Secure Association Protocol. known as the Secure Association Protocol.
3.1. Secure Association Protocol 3.1. Secure Association Protocol
Since neither EAP nor EAP methods provide key management support, it Since neither EAP nor EAP methods provide for establishment of lower
is RECOMMENDED that key management facilities be provided within the layer security associations, it is RECOMMENDED that these facilities
Secure Association Protocol. This includes: be provided within the Secure Association Protocol. This includes:
[a] Entity Naming. A basic feature of a Secure Association Protocol is [a] Entity Naming. A basic feature of a Secure Association Protocol is
the explicit naming of the parties engaged in the exchange. the explicit naming of the parties engaged in the exchange.
Without explicit identification, the parties engaged in the Without explicit identification, the parties engaged in the
exchange are not identified and the scope of the EAP keying exchange are not identified and the scope of the EAP keying
parameters negotiated during the EAP exchange is undefined. parameters negotiated during the EAP exchange is undefined.
[b] Mutual proof of possession of EAP keying material. During the [b] Mutual proof of possession of EAP keying material. During the
Secure Association Protocol the EAP peer and authenticator MUST Secure Association Protocol the EAP peer and authenticator MUST
demonstrate possession of the keying material transported between demonstrate possession of the keying material transported between
the backend authentication server and authenticator (e.g. MSK), in the backend authentication server and authenticator (e.g. MSK), in
order to demonstrate that the peer and authenticator have been order to demonstrate that the peer and authenticator have been
authorized. Since mutual proof of possession is not the same as authorized. Since mutual proof of possession is not the same as
skipping to change at page 28, line 48 skipping to change at page 29, line 5
which to protect the resynchronization exchange, securing this which to protect the resynchronization exchange, securing this
mechanism may be difficult. mechanism may be difficult.
[h] Key scope synchronization. To support key scope determination, the [h] Key scope synchronization. To support key scope determination, the
Secure Association Protocol SHOULD provide a mechanism by which the Secure Association Protocol SHOULD provide a mechanism by which the
peer can determine the scope of the key cache on each peer can determine the scope of the key cache on each
authenticator, and by which the authenticator can determine the authenticator, and by which the authenticator can determine the
scope of the key cache on a peer. This includes negotiation of scope of the key cache on a peer. This includes negotiation of
restrictions on key usage. restrictions on key usage.
[i] Direct operation. Since the phase 2 Secure Association Protocol is [i] Traffic profile negotiation. The traffic to be protected by a
lower layer security association may not necessarily have the same
lower layer source or destination address as the EAP peer and
authenticator, and it is possible for the peer and authenticator to
negotiate multiple security associations, each with a different
traffic profile. Where this is the case, the profile of protected
traffic SHOULD be explicitly negotiated. For example, in IKEv2 it
is possible for an Initiator and Responder to utilize EAP for
authentication, then negotiate a Tunnel Mode Security Association
(SA) which permits passing of traffic originating from hosts other
than the Initiator and Responder. Similarly, in IEEE 802.16e a
Subscriber Station (SS) may forward traffic to the Base Station
(BS) which originates from the Local Area Network (LAN) to which it
is attached. To enable this, Security Associations within IEEE
802.16e are identified by the Connection Identifier (CID), not by
the EAP peer and authenticator MAC addresses. In both IKEv2 and
IEEE 802.16e, multiple security associations may exist between the
EAP peer and authenticator, each with their own traffic profile and
quality of service parameters.
[j] Direct operation. Since the phase 2 Secure Association Protocol is
concerned with the establishment of security associations between concerned with the establishment of security associations between
the EAP peer and authenticator, including the derivation of the EAP peer and authenticator, including the derivation of
transient session keys, only those parties have "a need to know" transient session keys, only those parties have "a need to know"
the transient session keys. The Secure Association Protocol MUST the transient session keys. The Secure Association Protocol MUST
operate directly between the peer and authenticator, and MUST NOT operate directly between the peer and authenticator, and MUST NOT
be passed-through to the backend authentication server, or include be passed-through to the backend authentication server, or include
additional parties. additional parties.
[j] Bi-directional operation. While some ciphersuites only require a [k] Bi-directional operation. While some ciphersuites only require a
single set of transient session keys to protect traffic in both single set of transient session keys to protect traffic in both
directions, other ciphersuites require a unique set of transient directions, other ciphersuites require a unique set of transient
session keys in each direction. The phase 2 Secure Association session keys in each direction. The phase 2 Secure Association
Protocol SHOULD provide for the derivation of unicast and multicast Protocol SHOULD provide for the derivation of unicast and multicast
keys in each direction, so as not to require two separate phase 2 keys in each direction, so as not to require two separate phase 2
exchanges in order to create a bi-directional phase 2 security exchanges in order to create a bi-directional phase 2 security
association. See [RFC3748] Section 2.4 for more discussion. association. See [RFC3748] Section 2.4 for more discussion.
3.2. Key Scope 3.2. Key Scope
skipping to change at page 30, line 50 skipping to change at page 31, line 27
When using TEKs within an EAP conversation or across conversations, When using TEKs within an EAP conversation or across conversations,
it is necessary to ensure that replay protection and key separation it is necessary to ensure that replay protection and key separation
requirements are fulfilled. For instance, if a replay counter is requirements are fulfilled. For instance, if a replay counter is
used, TEK re-key MUST occur prior to wrapping of the counter. used, TEK re-key MUST occur prior to wrapping of the counter.
Similarly, TSKs MUST remain cryptographically separate from TEKs Similarly, TSKs MUST remain cryptographically separate from TEKs
despite TEK re-keying or caching. This prevents TEK compromise from despite TEK re-keying or caching. This prevents TEK compromise from
leading directly to compromise of the TSKs and vice versa. leading directly to compromise of the TSKs and vice versa.
EAP methods may cache local keying material which may persist for EAP methods may cache local keying material which may persist for
multiple EAP conversations when fast reconnect is used [RFC3748]. multiple EAP conversations when fast reconnect is used [RFC3748].
For example, EAP methods based on TLS (such as EAP-TLS [RFC2716]) For example, EAP methods based on TLS (such as EAP-TLS [I-D.simon-
derive and cache the TLS Master Secret, typically for substantial emu-rfc2716bis]) derive and cache the TLS Master Secret, typically
time periods. The lifetime of other local keying material calculated for substantial time periods. The lifetime of other local keying
within the EAP method is defined by the method. Note that in material calculated within the EAP method is defined by the method.
general, when using fast reconnect, there is no guarantee to that the Note that in general, when using fast reconnect, there is no
original long-term credentials are still in the possession of the guarantee to that the original long-term credentials are still in the
peer. For instance, a card hold holding the private key for EAP-TLS possession of the peer. For instance, a card hold holding the
may have been removed. EAP servers SHOULD also verify that the long- private key for EAP-TLS may have been removed. EAP servers SHOULD
term credentials are still valid, such as by checking that also verify that the long-term credentials are still valid, such as
certificate used in the original authentication has not yet expired. by checking that certificate used in the original authentication has
not yet expired.
3.5. Exported and Calculated Key Lifetimes 3.5. Exported and Calculated Key Lifetimes
The following mechanisms are available for communicating the lifetime The following mechanisms are available for communicating the lifetime
of exported and calculated keying material between the EAP peer, of exported and calculated keying material between the EAP peer,
server and authenticator: server and authenticator:
AAA protocols (backend server and authenticator) AAA protocols (backend server and authenticator)
Lower layer mechanisms (authenticator and peer) Lower layer mechanisms (authenticator and peer)
EAP method-specific negotiation (peer and server) EAP method-specific negotiation (peer and server)
skipping to change at page 34, line 5 skipping to change at page 34, line 32
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.
BCP 86 [RFC3766] offers advice on appropriate key sizes. The BCP 86 [RFC3766] Section 5 offers advice on the required RSA or DH
National Institute for Standards and Technology (NIST) also offers
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 module and DSA subgroup size in bits, for a given level of attack
resistance in bits: resistance in bits. The National Institute for Standards and
Technology (NIST) also offers advice on appropriate key sizes in
Attack Resistance RSA or DH Modulus DSA subgroup [SP800-57].
(bits) size (bits) size (bits)
----------------- ----------------- ------------
70 947 129
80 1228 148
90 1553 167
100 1926 186
150 4575 284
200 8719 383
250 14596 482
3.8. Key Wrap 3.8. Key Wrap
The key wrap specified in [RFC2548], which is based on an MD5-based The key wrap specified in [RFC2548], which is based on an MD5-based
stream cipher, has known problems, as described in [RFC3579] Section stream cipher, has known problems, as described in [RFC3579] Section
4.3. RADIUS uses the shared secret for multiple purposes, including 4.3. RADIUS uses the shared secret for multiple purposes, including
per-packet authentication and attribute hiding, considerable per-packet authentication and attribute hiding, considerable
information is exposed about the shared secret with each packet. information is exposed about the shared secret with each packet.
This exposes the shared secret to dictionary attacks. MD5 is used This exposes the shared secret to dictionary attacks. MD5 is used
both to compute the RADIUS Response Authenticator and the Message- both to compute the RADIUS Response Authenticator and the Message-
skipping to change at page 34, line 46 skipping to change at page 35, line 12
As discussed in [RFC3579] Section 4.3, the security vulnerabilities As discussed in [RFC3579] Section 4.3, the security vulnerabilities
of RADIUS are extensive, and therefore development of an alternative of RADIUS are extensive, and therefore development of an alternative
key wrap technique based on the RADIUS shared secret would not key wrap technique based on the RADIUS shared secret would not
substantially improve security. As a result, [RFC3579] Section 4.2 substantially improve security. As a result, [RFC3579] Section 4.2
recommends running RADIUS over IPsec. The same approach is taken in recommends running RADIUS over IPsec. The same approach is taken in
Diameter EAP [RFC4072], which defines clear-text key attributes, to Diameter EAP [RFC4072], which 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 Several mechanisms have been proposed for reducing handoff latency
handoff between authenticators: within networks utilizing EAP. These include:
[a] EAP pre-authentication. This utilizes EAP to pre-establish EAP EAP pre-authentication
keying material on an authenticator prior to arrival of the peer. In EAP pre-authentication, an EAP peer pre-establishes EAP keying
material with an authenticator prior to arrival. EAP pre-
authentication only affects the timing of EAP authentication, but
does not shorten or eliminate EAP (phase 1a) or AAA (phase 1b)
exchanges; Discovery (phase 0) and Secure Association Protocol
(phase 2) exchanges occur as described in Section 1.3. As a
result, the primary benefit is to enable EAP authentication to be
removed from the handoff critical path, thereby reducing latency.
Use of EAP pre-authentication within IEEE 802.11 is described in Use of EAP pre-authentication within IEEE 802.11 is described in
[8021XHandoff] and [IEEE-802.11i]. [8021XPreAuth] and [IEEE-802.11i].
[b] Key caching. This mechanism enables an EAP peer to re-attach to an Proactive key distribution
authenticator without requiring EAP re-authentication. In proactive key distribution, derived keying material and
authorizations are transported from the backend authentication
server to a candidate authenticator in advance of a handoff. As a
result, EAP (phase 1a) is not required, but the Discovery (phase
0), and Secure Association Protocol exchanges (phase 2) are still
necessary. Within the AAA exchange (phase 1b), authorization and
key distribution functions are typically supported, but not
authentication. Proactive key distribution is described in
[MishraPro], [IEEE-03-084] and [I-D.irtf-aaaarch-handoff].
[c] Context transfer, such as is defined in [IEEE-802.11F] (now Key caching
deprecated) and [RFC4067]. Use of context transfer for handoff Caching of EAP keying material enables an EAP peer to re-attach to
latency improvement is described in [IEEE-02-758]. an authenticator without requiring EAP (phase 1a) or AAA (phase 1b)
exchanges. However, Discovery (phase 0) and Secure Association
Protocol (phase 2) exchanges are still required. Use of key
caching within IEEE 802.11 is described in [IEEE-802.11i].
[d] Proactive key distribution, such as is described in Context transfer
[IEEE-02-758][IEEE-03-084] and [I-D.irtf-aaaarch-handoff]. In context transfer schemes, keying material and authorizations are
transferred between a previous authenticator and a new
authenticator. This can occur in response to a handoff request by
the EAP peer, or in advance, as in proactive key distribution. As
a result, EAP (phase 1a) is eliminated, but not the Discovery
(phase 0) or Secure Association Protocol exchanges (phase 2). If a
secure channel can be established between the new and previous
authenticator without assistance from the backend authentication
server, then the AAA exchange (phase 1b) can be eliminated;
otherwise, it is still required, although it may be shortened.
Context transfer protocols are described in [IEEE-802.11F] (now
deprecated) and "Context Transfer Protocol (CXTP)" [RFC4067].
"Fast Authentication Methods for Handovers between IEEE 802.11
Wireless LANs" [Bargh] analyzes fast handoff techniques, including
context transfer mechanisms.
Token distribution
In token distribution schemes the EAP peer is provided with a
credential, subsequently enabling it to authenticate with one or
more additional authenticators. During the subsequent
authentications, EAP (phase 1a) is eliminated or shortened; the
Discovery (phase 0) and Secure Association Protocol exchanges
(phase 2) still occur, although the latter may be shortened. If
the token includes authorizations and can be validated by an
authenticator without assistance from the backend authentication
server, then the AAA exchange (phase 1b) can be eliminated;
otherwise it is still required, although it may be shortened.
Token-based schemes are described in [Token] and [I-D.friedman-ike-
short-term-certs].
The sections that follow discuss the security vulnerabilities The sections that follow discuss the security vulnerabilities
introduced by the above mechanisms. introduced by the above schemes.
4.1. EAP Pre-authentication 4.1. EAP Pre-authentication
EAP pre-authentication enables an EAP peer to pre-establish EAP EAP pre-authentication differs from a normal EAP conversation
keying material with an authenticator prior to attaching to it. Where primarily with respect to the lower layer encapsulation. For
there is sufficient time to pre-establish keying material prior to example, in [IEEE-802.11i], EAP pre-authentication frames utilize a
changing the point of attachment, this may enable the peer to remove distinct Ethertype, but otherwise conform to the encapsulation
EAP authentication from the critical path for handoff, reducing described in [IEEE-802.1X]. As a result, an EAP pre-authentication
latency. conversation differs little from the model described in Section 1.3,
other than the introduction of a delay between phase 1 and phase 2.
EAP pre-authentication exchanges typically differ from a normal EAP EAP pre-authentication relies on lower layer mechanisms for discovery
conversation only with respect to the lower layer encapsulation. For of candidate authenticators. Where discovery can provide information
example, in [IEEE-802.11i], EAP pre-authentication frames are on candidate authenticators outside the immediate listening range,
encapsulated within a distinct Ethertype, but otherwise conform to and the peer can determine whether it already possesses valid keying
the encapsulation described in [IEEE-802.1X]. As a result, an EAP material with candidate authenticators, the peer can avoid
pre-authentication conversation that eventually results in unnecessary EAP pre-authentications and can establish keying material
establishment of security associations differs little from the model well in advance, regardless of the coverage overlap between
described in Section 1.3, other than the potential introduction of a authenticators. However, if the peer can only discover candidate
delay between Phase 1 and Phase 2. However, since a peer may complete authenticators within listening range and cannot determine whether it
EAP pre-authentication with an authenticator without eventually can reuse existing key material, then peer may not be able to
attaching to it, it is possible that Phase 2 will not occur. complete EAP pre-authentication prior to connectivity loss or may
pre-authenticate multiple times with the same authenticator,
increasing backend authentication server load.
[RFC3580] describes only minor differences in the AAA exchange Since a peer may complete EAP pre-authentication with an
occurring as a result of EAP pre-authentication as compared with an authenticator without eventually attaching to it, phase 2 may never
ordinary EAP authentication exchange. For example, since in 802.11i occur. As a result, an Accounting-Request signifying the start of
an Association exchange does not occur prior to EAP pre- service may never be sent, or may only be sent with a substantial
authentication, the SSID is not yet known. As a result, an Access- delay after the completion of authentication.
Request generated as the result of EAP pre-authentication cannot
include the SSID within the Called-Station-Id attribute as described
in [RFC3580] Section 3.20. Since a peer may never associate with an
authenticator to which it pre-authenticated, an Accounting-Request
signifying the start of service may never be sent, or may only be
sent with a substantial delay after the completion of authentication.
Since an EAP pre-authentication exchange differs from an EAP As noted in "IEEE 802.1X RADIUS Usage Guidelines" [RFC3580], the AAA
authentication exchange only in subtle ways, the backend exchange resulting from EAP pre-authentication differs little from an
authentication server may not be aware of whether it is engaging in ordinary exchange described in "RADIUS Support for EAP" [RFC3579].
an EAP pre-authentication exchange, resulting in operational or For example, since in IEEE 802.11i an Association exchange does not
security problems. For example, where the authenticator does not occur prior to EAP pre-authentication, the SSID is not known by the
include the SSID within the Called-Station-Id attribute in ordinary authenticator at authentication time, so that an Access-Request
requests, EAP pre-authentication requests may appear cannot include the SSID within the Called-Station-Id attribute as
indistinguishable. As a result, the backend authentication server may described in [RFC3580] Section 3.20.
not be able to correctly calculate the simultaneous sessions in
progress, either preventing successful completion of EAP pre-
authentication or enabling the peer to engage in more simultaneous
sessions than they are authorized for.
In order to allow backend authentication servers to handle EAP pre- Since only the absence of an SSID in the Called-Station-Id attribute
authentication requests more reliably, it is recommended that EAP distinguishes an EAP pre-authentication attempt, if the authenticator
pre-authentication requests be explicitly identified within AAA does not always include the SSID for a normal EAP authentication
protocols. Also, in order to suppress unnecessary EAP pre- attempt, the backend authentication server may not be able to
authentication exchanges, it is recommended that authenticators determine whether a session constitutes an EAP pre-authentication
unambiguously identify themselves as described in Section 2.2.1, attempt, potentially resulting in authorization or accounting
allowing the peer to determine whether it has previously established problems. Where the number of simultaneous sessions is limited, the
EAP keying material with that authenticator. backend authentication server may refuse to authorize a valid EAP
pre-authentication attempt or may enable the peer to engage in more
simultaneous sessions than they are authorized for. Where EAP pre-
authentication occurs with an authenticator which the peer never
attaches to, the backend accounting server may not be able to
determine whether the absence of an Accounting-Request was due to
packet loss or a session that never started.
4.2. Authorization In order to enable pre-authentication requests to be handled more
reliably, it is RECOMMENDED that AAA protocols explicitly identify
EAP pre-authentication. In order to suppress unnecessary EAP pre-
authentication exchanges, it is RECOMMENDED that authenticators
unambiguously identify themselves as described in Section 2.2.1.
In a typical network access scenario (dial-in, wireless LAN, etc.) 4.2. Proactive Key Distribution
access control mechanisms are typically applied. These mechanisms
include user authentication as well as authorization for the offered In proactive key distribution schemes, the backend authentication
service. server transports keying material and authorizations to an
authenticator in advance of the arrival of the peer. The
authenticators selected to receive the transported key material are
selected based on past patterns of peer movement between
authenticators known as the "neighbor graph". Since proactive key
distribution schemes typically only demonstrate proof of possession
of transported keying material between the EAP peer and
authenticator, the backend authentication server may not be provided
with proof that the peer successfully authenticated to an
authenticator. To compute the "neighbor graph" the backend
authentication server therefore may need to rely on a stream of
accounting messages without a corresponding set of authentication
exchanges.
In order to prevent compromise of one authenticator from resulting in
compromise of other authenticators, cryptographic separation needs
to be maintained between the keying material transported to each
authenticator. However, even where cryptographic separation is
maintained, an attacker compromising an authenticator may still
disrupt the operation of other authenticators. Since proactive key
distribution schemes typically only demonstrate proof of possession
of transported keying material between the EAP peer and
authenticator, the backend authentication server is typically not
provided with proof that the peer actually connected to an
authenticator. To compute the "neighbor graph" it therefore may be
necessary to rely on a stream of accounting messages without a
corresponding set of authentication exchanges to verify against.
As noted in [RFC3579] Section 4.3.7, in the absence of spoofing
detection within the AAA infrastructure, it is possible for EAP
authenticators to impersonate each other. By forging NAS
identification attributes within accounting messages, an attacker
compromising one authenticator could corrupt the neighbor graph,
tricking the backend authentication server into transporting keying
material to arbitrary authenticators. While this would not enable
recovery of EAP keying material without breaking fundamental
cryptographic assumptions, it could enable fraudulent charges or
allow an attacker to disrupt service by increasing load on the
backend authentication server or thrashing the authenticator key
cache.
Since proactive key distribution requires the distribution of derived
keying material to candidate authenticators, the effectiveness of
this scheme depends on the ability of backend authentication server
to anticipate the movement of the EAP peer. As described in [Mishra-
Pro], knowledge of the "neighbor graph" can be established via static
configuration or analysis of accounting messages. Since proactive
key distribution relies on backend authentication server knowledge of
the "neighbor graph" it is most applicable to intra-domain handoff
scenarios. However, in inter-domain handoff where there may be many
authenticators, the "neighbor graph" may not be readily derived on
the backend authentication server, since peers may frequently connect
to authenticators that have not previously been encountered.
Since proactive key distribution schemes typically require
introduction of server-initiated messages as described in [RFC3576]
and [I-D.irtf-aaaarch-handoff], security issues described in
[RFC3576] Section 5 are applicable, including authorization (Section
5.1) and replay detection (Section 5.4) problems.
4.3. AAA Bypass
Fast handoff techniques which enable elimination of the AAA exchange
(phase 1b) differ fundamentally from typical network access scenarios
(dial-up, wired LAN, etc.) which include user authentication as well
as authorization for the offered service. Where the AAA exchange
(phase 1b) is omitted, authorizations and keying material are not
provided by the backend authentication server, and as a result they
need to be supplied by other means. This section describes some of
the implications.
4.3.1. Key Transport
Where transported keying material is not supplied by the backend
authentication server, it needs to be provided by another party
authorized to access that keying material. As noted in Section 1.5,
only the EAP peer, authenticator and server are authorized to possess
transported EAP keying material. Since EAP peers do not trust each
other, if the backend authentication server does not supply
transported keying material to a new authenticator, it can only be
provided by a previous authenticator.
As noted in Section 1.5, the goal of the EAP conversation is to
derive session keys known only to the peer and the authenticator. If
EAP keying material is replicated between a previous authenticator
and a new authenticator, then the previous authenticator may
potentially know the session keys used between the peer and new
authenticator. Also, the new authenticator may potentially know the
session keys used between the peer and the previous authenticator.
If a one-way function is used to derive the keying material to be
transported to the new authenticator, then the new authenticator is
not longer able to know previous session keys without breaking a
fundamental cryptographic assumption.
4.3.2. Authorization
As a part of the authentication process, the backend authentication As a part of the authentication process, the backend authentication
server determines the user's authorization profile. The user server determines the user's authorization profile and transmits the
authorizations are transmitted by the backend authentication server authorizations to the authenticator along with the transported EAP
to the EAP authenticator (also known as the Network Access Server or key material. Typically, the profile is determined based on the user
authenticator) along with the transported EAP keying material, in identity, but a certificate presented by the user may also provide
Phase 1b of the EAP conversation. Typically, the profile is authorization information.
determined based on the user identity, but a certificate presented by
the user may also provide authorization information.
The backend authentication server is responsible for making a user The backend authentication server is responsible for making a user
authorization decision, which requires answering the following authorization decision, which requires answering the following
questions: questions:
[a] Is this a legitimate user for this particular network? [a] Is this a legitimate user of this network?
[b] Is the user allowed the type of access he or she is requesting?
[c] Are there any specific parameters (mandatory tunneling, bandwidth, [b] Is the user allowed to access this network?
filters, and so on) that the access network should be aware of for
this user?
[d] Is the user operating within the time of day subscription rules? [c] Is the user permitted to access this network on this day and at
this time?
[e] Is the user within his limits for concurrent sessions? [d] Is the user within the concurrent session limit?
[f] Are there any fraud, credit limit, or other concerns that indicate [e] Are there any fraud, credit limit, or other concerns indicating
that access should be denied? that access should be denied?
While the authorization decision is in principle simple, the process [f] If access is to be granted, what are the service parameters
is complicated by the distributed nature of the decision making. (mandatory tunneling, bandwidth, filters, and so on) to be
Where brokering entities or proxies are involved, all of the AAA provisioned for the user?
entities in the chain from the authenticator to the home backend
authentication server are involved in the decision. For instance, a While the authorization decision is in principle simple, the
broker can disallow access even if the home backend authentication distributed decision making process may add complexity. Where
server would allow it, or a proxy can add authorizations (e.g., brokers or proxies are involved, all of the AAA entities in the chain
bandwidth limits). from the authenticator to the home backend authentication server are
involved in the decision. For example, a broker can deny access even
if the home backend authentication 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 concurrent session
concurrent sessions). In addition to the Accept/Reject decision made limits). In addition to the Accept/Reject decisions made by AAA
by the AAA chain, parameters or constraints can be communicated to entities, service parameters or constraints may 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
has no way to know what the decision was based on. Was a set of has no way to know what the decision was based on. Was a set of
authorization parameters sent because this service is always provided authorization parameters sent because this service is always provided
to the user, or was the decision based on the time/day and the to the user, or was the decision based on the time of day and the
capabilities of the requesting authenticator device? capabilities of the authenticator?
4.3. Correctness
When the AAA exchange is bypassed via use of techniques such as key
caching, it can be challenging to ensure that authorization is
properly handled. Challenges include:
[a] Consistent application of session time limits. Bypassing AAA 4.3.3. Correctness
should not automatically increase the available session time,
allowing a user to endlessly extend their network access by
changing the point of attachment.
[b] Avoidance of privilege elevation. Bypassing AAA should not result When the AAA exchange (phase 1b) is bypassed, several challenges
in a user being granted access to services which they are not arise in ensuring correct authorization:
entitled to.
[c] Consideration of dynamic state. In situations in which dynamic [a] Theft of service. Bypassing the AAA exchange (phase 1b) should not
state is involved in the access decision (day/time, simultaneous enable a user to extend their network access or gain access to
session limit) it should be possible to take this state into services they are not entitled to.
account either before or after access is granted. Note that
consideration of network-wide state such as simultaneous session
limits can typically only be taken into account by the backend
authentication server.
[d] Encoding of restrictions. Since a authenticator may not be aware [b] Consideration of network-wide state. Handoff techniques should not
of the criteria considered by a backend authentication server when render the backend authentication server incapable of keeping track
allowing access, in order to ensure consistent authorization during of network-wide state. For example, a backend authentication
a fast handoff it may be necessary to explicitly encode the server may need to keep track of simultaneous user sessions.
restrictions within the authorizations provided by the backend
authentication server.
[e] State validity. The introduction of fast handoff should not render [c] Elevation of privilege. Backend authentication servers often
the authentication server incapable of keeping track of network- perform conditional evaluation, in which the authorizations
wide state. returned in an Access-Accept message are contingent on the
authenticator or on dynamic state such as the time of day. In this
situation, bypassing the AAA exchange could enable unauthorized
access unless the restrictions are explicitly encoded within the
authorizations provided by the backend authentication server.
A handoff mechanism capable of addressing these concerns is said to A handoff mechanism that provides proper authorization is said to be
be "correct". One condition for correctness is as follows: "correct". One condition for correctness is as follows:
For a handoff to be "correct" it MUST establish on the new device For a handoff to be "correct" it MUST establish on the new
the same context as would have been created had the new device authenticator the same authorizations as would have been created
completed a AAA conversation with the backend authentication had the new authenticator completed a AAA conversation with the
server. backend authentication server.
A properly designed handoff scheme will only succeed if it is A properly designed handoff scheme will only succeed if it is
"correct" in this way. If a successful handoff would establish "correct" in this way. If a successful handoff would establish
"incorrect" state, it is preferable for it to fail, in order to avoid "incorrect" authorizations, it is preferable for it to fail. Where
creation of incorrect context. the supported services differ between authenticators, a handoff that
bypasses the backend authentication server is likely to fail.
Some authenticator and backend authentication server configurations [RFC2865] section 1.1 states:
are incapable of meeting this definition of "correctness". For
example, if the old and new device differ in their capabilities, a
handoff mechanism that bypasses AAA may find it difficult to meet
this definition of correctness. Backend authentication servers often
perform conditional evaluation, in which the authorizations returned
in an Access-Accept message are contingent on the authenticator or on
dynamic state such as the time of day or number of simultaneous
sessions. For example, in a heterogeneous deployment, the backend
authentication server might return different authorizations depending
on the authenticator making the request, in order to make sure that
the requested service is consistent with the authenticator
capabilities.
If differences between the new and old device would result in the
backend authentication server sending a different set of messages to
the new device than were sent to the old device, then if the handoff
mechanism bypasses AAA, the handoff cannot be carried out correctly.
For example, if some authenticators support dynamic Virtual LANs
(VLANs) while others do not, then attributes present in the Access-
Request (such as the NAS-IP-Address, NAS-IPv6-Address, NAS-
Identifier, etc.) could be examined to determine when VLAN attributes
will be returned, as described in [RFC3580]. VLAN support is
defined in [IEEE-802.1Q]. If a handoff bypassing the backend
authentication server were to occur between a authenticator
supporting dynamic VLANs and another authenticator which does not,
then a guest user with access restricted to a guest VLAN could be
given unrestricted access to the network.
Similarly, in a network where access is restricted based on the day
and time, Service Set Identifier (SSID), Calling-Station-Id or other
factors, unless the restrictions are encoded within the
authorizations, or a partial AAA conversation is included, then a
handoff could result in the user bypassing the restrictions.
In practice, these considerations limit the situations in which fast
handoff mechanisms bypassing AAA can be expected to be successful.
Where the deployed devices implement the same set of services, it may
be possible to do successful handoffs within such mechanisms.
However, where the supported services differ between devices, the
handoff may not succeed. For example, [RFC2865] section 1.1 states:
"A authenticator that does not implement a given service MUST NOT A authenticator that does not implement a given service MUST NOT
implement the RADIUS attributes for that service. For example, a implement the RADIUS attributes for that service. For example, a
authenticator that is unable to offer ARAP service MUST NOT authenticator that is unable to offer ARAP service MUST NOT
implement the RADIUS attributes for ARAP. A authenticator MUST implement the RADIUS attributes for ARAP. A authenticator MUST
treat a RADIUS access-accept authorizing an unavailable service as treat a RADIUS access-accept authorizing an unavailable service as
an access-reject instead." an access-reject instead.
Note that this behavior only applies to attributes that are known,
but not implemented. For attributes that are unknown, [RFC2865]
Section 5 states:
"A RADIUS server MAY ignore Attributes with an unknown Type. A This behavior applies to attributes that are known, but not
RADIUS client MAY ignore Attributes with an unknown Type." implemented. For attributes that are unknown, [RFC2865] Section 5
states:
In order to perform a correct handoff, if a new device is provided A RADIUS server MAY ignore Attributes with an unknown Type. A
with RADIUS context for a known but unavailable service, then it MUST RADIUS client MAY ignore Attributes with an unknown Type.
process this context the same way it would handle a RADIUS Access-
Accept requesting an unavailable service. This MUST cause the
handoff to fail. However, if a new device is provided with RADIUS
context that indicates an unknown attribute, then this attribute MAY
be ignored.
In order to perform a correct handoff, if a new authenticator is
provided with RADIUS authorizations for a known but unavailable
service, then it MUST process these authorizations the same way it
would handle a RADIUS Access-Accept requesting an unavailable
service; this MUST cause the handoff to fail. However, if a new
authenticator is provided with authorizations including unknown
attributes, then these attributes MAY be ignored. The definition of
a "known but unsupported service" MUST encompass requests for
unavailable security services. This includes vendor-specific
attributes related to security, such as those described in [RFC2548].
Although it may seem somewhat counter-intuitive, failure is indeed Although it may seem somewhat counter-intuitive, failure is indeed
the "correct" result where a known but unsupported service is the "correct" result where a known but unsupported service is
requested. Presumably a correctly configured backend authentication requested.
server would not request that a device carry out a service that it
does not implement. This implies that if the new device were to
complete a AAA conversation that it would be likely to receive
different service instructions. In such a case, failure of the
handoff is the desired result. This will cause the new device to go
back to the backend server in order to receive the appropriate
service definition.
In practice, this implies that handoff mechanisms which bypass AAA Presumably a correctly configured backend authentication server would
are most likely to be successful within a homogeneous device not request that an authenticator provide a service that it does not
deployment within a single administrative domain. For example, it implement. This implies that if the new authenticator were to
would not be advisable to carry out a fast handoff bypassing AAA complete a AAA conversation, it would be likely to receive different
between a authenticator providing confidentiality and another service instructions. Failure of the handoff is the desired result
authenticator that does not support this service. The correct result since it will cause the new authenticator to go back to the backend
of such a handoff would be a failure, since if the handoff were server in order to receive the appropriate service definition.
blindly carried out, then the user would be moved from a secure to an
Handoff mechanisms which bypass the backend authentication server are
most likely to be successful when employed in a homogeneous
deployment within a single administrative domain. In a heterogeneous
deployment, the backend authentication server may return different
authorizations depending on the authenticator making the request, in
order to make sure that the requested service is consistent with the
authenticator capabilities. Where a backend authentication server
would send different authorizations to the new authenticator than
were sent to a previous authenticator, transferring authorizations
between the previous authenticator and the new authenticator will
result in incorrect authorization.
Virtual LAN (VLAN) support is defined in [IEEE-802.1Q]; RADIUS
support for dynamic VLANs is described in [RFC3580] and [RFC4675].
If some authenticators support dynamic VLANs while others do not,
then attributes present in the Access-Request (such as the NAS-Port-
Type, NAS-IP-Address, NAS-IPv6-Address and NAS-Identifier) could be
examined by the backend authentication server to determine when VLAN
attributes will be returned, and if so, which ones. However, if the
backend authenticator is bypassed, then a handoff occurring between
authenticators supporting different VLAN capabilities could result in
a user obtaining access to an unauthorized VLAN (e.g. a user with
access to a guest VLAN being given unrestricted access to the
network).
Similarly, a handoff between an authenticator providing
confidentiality and another that does not should fail, since if the
handoff were successful, 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.
MUST encompass requests for unavailable security services. This
includes vendor-specific attributes related to security, such as
those described in [RFC2548].
5. Security Considerations 5. Security Considerations
The EAP threat model is described in [RFC3748] Section 7.1. The The EAP threat model is described in [RFC3748] Section 7.1. The
security properties of EAP methods (known as "security claims") are security properties of EAP methods (known as "security claims") are
described in [RFC3748] Section 7.2.1. EAP method requirements for described in [RFC3748] Section 7.2.1. EAP method requirements for
applications such as Wireless LAN authentication are described in applications such as Wireless LAN authentication are described in
[RFC4017]. The RADIUS threat model is described in [RFC3579] Section [RFC4017]. The RADIUS threat model is described in [RFC3579] Section
4.1, and responses to these threats are described in [RFC3579] 4.1, and responses to these threats are described in [RFC3579]
Sections 4.2 and 4.3. Sections 4.2 and 4.3.
skipping to change at page 51, line 40 skipping to change at page 54, line 19
registries, nor does it require any other IANA assignments. registries, nor does it require any other IANA assignments.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H.
Lefkowetz, "Extensible Authentication Protocol (EAP)", RFC Lefkowetz, "Extensible Authentication Protocol (EAP)",
3748, June 2004. RFC 3748, June 2004.
7.2. Informative References 7.2. Informative References
[Analysis] He, C. and J. Mitchell, "Analysis of the 802.11i 4-Way [Analysis] He, C. and J. Mitchell, "Analysis of the 802.11i 4-Way
Handshake", Proceedings of the 2004 ACM Workshop on Handshake", Proceedings of the 2004 ACM Workshop on
Wireless Security, pp. 43-50, ISBN: 1-58113-925-X. Wireless Security, pp. 43-50, ISBN: 1-58113-925-X.
[Bargh] Bargh, M., Hulsebosch, R., Eertink, E., Prasad, A., Wang,
H. and P. Schoo, "Fast Authentication Methods for
Handovers between IEEE 802.11 Wireless LANs", Proceedings
of the 2nd ACM international workshop on Wireless mobile
applications and services on WLAN hotspots, October,
2004.
[GKDP] Dondeti, L., Xiang, J. and S. Rowles, "GKDP: Group Key [GKDP] Dondeti, L., Xiang, J. and S. Rowles, "GKDP: Group Key
Distribution Protocol", Internet draft (work in progress), Distribution Protocol", Internet draft (work in
draft-ietf-msec-gkdp-01, March 2006. progress), draft-ietf-msec-gkdp-01, March 2006.
[GSAKMP] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP: [GSAKMP] Harney, H., Meth, U., Colegrove, A., and G. Gross,
Group Secure Association Group Management Protocol", "GSAKMP: Group Secure Association Group Management
Internet draft (work in progress), draft-ietf-msec-gsakmp- Protocol", Internet draft (work in progress), draft-ietf-
sec-10, May 2005. msec-gsakmp-sec-10, May 2005.
[He] He, C., Sundararajan, M., Datta, A. Derek, A. and J. C. [He] He, C., Sundararajan, M., Datta, A. Derek, A. and J. C.
Mitchell, "A Modular Correctness Proof of TLS and IEEE Mitchell, "A Modular Correctness Proof of TLS and IEEE
802.11i", ACM Conference on Computer and Communications 802.11i", ACM Conference on Computer and Communications
Security (CCS '05), November, 2005. Security (CCS '05), November, 2005.
[IEEE-802.11] [IEEE-802.11] Institute of Electrical and Electronics Engineers,
Institute of Electrical and Electronics Engineers,
"Information technology - Telecommunications and "Information technology - Telecommunications and
information exchange between systems - Local and information exchange between systems - Local and
metropolitan area networks - Specific Requirements Part 11: metropolitan area networks - Specific Requirements Part
Wireless LAN Medium Access Control (MAC) and Physical Layer 11: Wireless LAN Medium Access Control (MAC) and
(PHY) Specifications", IEEE IEEE Standard 802.11-2003, Physical Layer (PHY) Specifications", IEEE IEEE Standard
2003. 802.11-2003, 2003.
[IEEE-802.1X] [IEEE-802.1X] Institute of Electrical and Electronics Engineers, "Local
Institute of Electrical and Electronics Engineers, "Local
and Metropolitan Area Networks: Port-Based Network Access and Metropolitan Area Networks: Port-Based Network Access
Control", IEEE Standard 802.1X-2004, December 2004. Control", IEEE Standard 802.1X-2004, December 2004.
[IEEE-802.1Q] [IEEE-802.1Q] Institute of Electrical and Electronics Engineers, "IEEE
Institute of Electrical and Electronics Engineers, "IEEE
Standards for Local and Metropolitan Area Networks: Draft Standards for Local and Metropolitan Area Networks: Draft
Standard for Virtual Bridged Local Area Networks", IEEE Standard for Virtual Bridged Local Area Networks", IEEE
Standard 802.1Q/D8, January 1998. [IEEE802.11i] Institute Standard 802.1Q/D8, January 1998. [IEEE802.11i]
of Electrical and Electronics Engineers, "Supplement to
Standard for Telecommunications and Information Exchange
Between Systems - LAN/MAN Specific Requirements - Part 11:
Wireless LAN Medium Access Control (MAC) and Physical Layer
(PHY) Specifications: Specification for Enhanced Security",
IEEE 802.11i, July 2004.
[IEEE-802.11F]
Institute of Electrical and Electronics Engineers, Institute of Electrical and Electronics Engineers,
"Supplement to Standard for Telecommunications and
Information Exchange Between Systems - LAN/MAN Specific
Requirements - Part 11: Wireless LAN Medium Access
Control (MAC) and Physical Layer (PHY) Specifications:
Specification for Enhanced Security", IEEE 802.11i, July
2004.
[IEEE-802.11F] Institute of Electrical and Electronics Engineers,
"Recommended Practice for Multi-Vendor Access Point "Recommended Practice for Multi-Vendor Access Point
Interoperability via an Inter-Access Point Protocol Across Interoperability via an Inter-Access Point Protocol
Distribution Systems Supporting IEEE 802.11 Operation", Across Distribution Systems Supporting IEEE 802.11
IEEE 802.11F, July 2003 (now deprecated). Operation", IEEE 802.11F, July 2003 (now deprecated).
[IEEE-802.16e] [IEEE-802.16e] Institute of Electrical and Electronics Engineers, "IEEE
Institute of Electrical and Electronics Engineers, "IEEE Standard for Local and Metropolitan Area Networks: Part
Standard for Local and Metropolitan Area Networks: Part 16: 16: Air Interface for Fixed and Mobile Broadband Wireless
Air Interface for Fixed and Mobile Broadband Wireless
Access Systems: Amendment for Physical and Medium Access Access Systems: Amendment for Physical and Medium Access
Control Layers for Combined Fixed and Mobile Operations in Control Layers for Combined Fixed and Mobile Operations
Licensed Bands" IEEE 802.16e, August 2005. in Licensed Bands" IEEE 802.16e, August 2005.
[IEEE-02-758]
Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang,
"Proactive Caching Strategies for IAPP Latency Improvement
during 802.11 Handoff", IEEE 802.11 Working Group,
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, "Guidance for AAA Key Housley, R. and B. Aboba, "Guidance for AAA Key
Management", draft-housley-aaa-key-mgmt-06.txt, Internet Management", draft-housley-aaa-key-mgmt-06.txt, Internet
draft (work in progress), November 2006. draft (work in progress), November 2006.
[I-D.puthenkulam-eap-binding] [I-D.puthenkulam-eap-binding]
Puthenkulam, J., "The Compound Authentication Binding Puthenkulam, J., "The Compound Authentication Binding
Problem", draft-puthenkulam-eap-binding-04, Internet draft Problem", draft-puthenkulam-eap-binding-04, Internet
(work in progress), October 2003. draft (work in progress), October 2003.
[I-D.arkko-eap-service-identity-auth] [I-D.arkko-eap-service-identity-auth]
Arkko, J. and P. Eronen, "Authenticated Service Information Arkko, J. and P. Eronen, "Authenticated Service
for the Extensible Authentication Protocol (EAP)", draft- Information for the Extensible Authentication Protocol
arkko-eap-service-identity-auth-02.txt Internet draft (work (EAP)", draft-arkko-eap-service-identity-auth-02.txt
in progress), May 2005. Internet draft (work in progress), May 2005.
[I-D.friedman-ike-short-term-certs]
Friedman, A., Sheffer, Y. and A. Shaqed, "Short Term
Certificates", draft-friedman-ike-short-term-certs-01,
Internet draft (work in progress), December 2006.
[I-D.irtf-aaaarch-handoff]
Arbaugh, W. and B. Aboba, "Handoff Extension to RADIUS",
draft-irtf-aaaarch-handoff-04.txt, Internet Draft (work
in progress), October 2003.
[I-D.ohba-eap-channel-binding] [I-D.ohba-eap-channel-binding]
Ohba, Y., Parthasrathy, M. and M. Yanagiya, "Channel Ohba, Y., Parthasrathy, M. and M. Yanagiya, "Channel
Binding Mechanism Based on Parameter Binding in Key Binding Mechanism Based on Parameter Binding in Key
Derivation", draft-ohba-eap-channel-binding-00.txt, Derivation", draft-ohba-eap-channel-binding-00.txt,
Internet draft (work in progress), January 2006. Internet draft (work in progress), January 2006.
[I-D.irtf-aaaarch-handoff] [I-D.simon-emu-rfc2716bis]
Arbaugh, W. and B. Aboba, "Handoff Extension to RADIUS", Simon, D. and B. Aboba, "EAP TLS Authentication
draft-irtf-aaaarch-handoff-04.txt, Internet draft (work in Protocol", draft-simon-emu-rfc2716bis-07.txt, Internet
progress), October 2003. Draft (work in progress), January 2007.
[MD5Collision] [MD5Collision] Klima, V., "Tunnels in Hash Functions: MD5 Collisions
Klima, V., "Tunnels in Hash Functions: MD5 Collisions
Within a Minute", Cryptology ePrint Archive, March 2006, Within a Minute", Cryptology ePrint Archive, March 2006,
http://eprint.iacr.org/2006/105.pdf http://eprint.iacr.org/2006/105.pdf
[MishraPro] Mishra, A., Shin, M. and W. Arbaugh, "Pro-active Key
Distribution using Neighbor Graphs", IEEE Wireless
Communications, vol. 11, February 2004.
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994. RFC 1661, July 1994.
[RFC1968] Meyer, G. and K. Fox, "The PPP Encryption Control Protocol [RFC1968] Meyer, G. and K. Fox, "The PPP Encryption Control
(ECP)", RFC 1968, June 1996. Protocol (ECP)", RFC 1968, June 1996.
[RFC2230] Atkinson, R., "Key Exchange Delegation Record for the DNS", [RFC2230] Atkinson, R., "Key Exchange Delegation Record for the
RFC 2230, November 1997. DNS", RFC 2230, November 1997.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998. (IKE)", RFC 2409, November 1998.
[RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D. [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D.
and R. Wheeler, "A Method for Transmitting PPP Over and R. Wheeler, "A Method for Transmitting PPP Over
Ethernet (PPPoE)", RFC 2516, February 1999. Ethernet (PPPoE)", RFC 2516, February 1999.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
2535, March 1999. RFC 2535, March 1999.
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes",
RFC 2548, March 1999. RFC 2548, March 1999.
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
Implementation in Roaming", RFC 2607, June 1999. Implementation in Roaming", RFC 2607, June 1999.
[RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication
Protocol", RFC 2716, October 1999.
[RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for [RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
February 2000. February 2000.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B.
Wellington, "Secret Key Transaction Authentication for DNS Wellington, "Secret Key Transaction Authentication for
(TSIG)", RFC 2845, May 2000. DNS (TSIG)", RFC 2845, May 2000.
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson,
Authentication Dial In User Service (RADIUS)", RFC 2865, "Remote Authentication Dial In User Service (RADIUS)",
June 2000. RFC 2865, June 2000.
[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
(SIG(0)s )", RFC 2931, September 2000. (SIG(0)s )", RFC 2931, September 2000.
[RFC3007] Wellington, B., "Simple Secure Domain Name System (DNS) [RFC3007] Wellington, B., "Simple Secure Domain Name System (DNS)
Dynamic Update", RFC 3007, November 2000. Dynamic Update", RFC 3007, November 2000.
[RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC
3162, August 2001. 3162, August 2001.
[RFC3547] Baugher, M., Weis, B., Hardjono, T. and H. Harney, "The [RFC3547] Baugher, M., Weis, B., Hardjono, T. and H. Harney, "The
Group Domain of Interpretation", RFC 3547, July 2003. Group Domain of Interpretation", RFC 3547, July 2003.
[RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B.
Aboba, "Dynamic Authorization Extensions to Remote
Authentication Dial In User Service (RADIUS)", RFC 3576,
July 2003.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
Dial In User Service) Support For Extensible Authentication Dial In User Service) Support For Extensible
Protocol (EAP)", RFC 3579, September 2003. Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese,
"IEEE 802.1X Remote Authentication Dial In User Service "IEEE 802.1X Remote Authentication Dial In User Service
(RADIUS) Usage Guidelines", RFC 3580, September 2003. (RADIUS) Usage Guidelines", RFC 3580, September 2003.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003. Arkko, "Diameter Base Protocol", RFC 3588, September
2003.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
Keys Used For Exchanging Symmetric Keys", RFC 3766, April Public Keys Used For Exchanging Symmetric Keys", RFC
2004. 3766, April 2004.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M. and K. [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M. and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004. August 2004.
[RFC4005] Calhoun, P., Zorn, G., Spence, D. and D. Mitton, "Diameter [RFC4005] Calhoun, P., Zorn, G., Spence, D. and D. Mitton,
Network Access Server Application", RFC 4005, August 2005 "Diameter Network Access Server Application", RFC 4005,
August 2005
[RFC4017] Stanley, D., Walker, J. and B. Aboba, "EAP Method [RFC4017] Stanley, D., Walker, J. and B. Aboba, "EAP Method
Requirements for Wireless LANs", RFC 4017, March 2005. Requirements for Wireless LANs", RFC 4017, March 2005.
[RFC4067] Loughney, J., Nakhjiri, M., Perkins, C. and R. Koodli, [RFC4067] Loughney, J., Nakhjiri, M., Perkins, C. and R. Koodli,
"Context Transfer Protocol (CXTP)", RFC 4067, July 2005. "Context Transfer Protocol (CXTP)", RFC 4067, July 2005.
[RFC4072] Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible [RFC4072] Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application", RFC 4072, Authentication Protocol (EAP) Application", RFC 4072,
August 2005. August 2005.
[RFC4118] Yang, L., Zerfos, P. and E. Sadot, "Architecture Taxonomy [RFC4118] Yang, L., Zerfos, P. and E. Sadot, "Architecture Taxonomy
for Control and Provisioning of Wireless Access Points for Control and Provisioning of Wireless Access Points
(CAPWAP)", RFC 4118, June 2005. (CAPWAP)", RFC 4118, June 2005.
[RFC4186] Haverinen, H. and J. Salowey, "Extensible Authentication [RFC4186] Haverinen, H. and J. Salowey, "Extensible Authentication
Protocol Method for Global System for Mobile Communications Protocol Method for Global System for Mobile
(GSM) Subscriber Identity Modules (EAP-SIM)", RFC 4186, Communications (GSM) Subscriber Identity Modules (EAP-
January 2006. SIM)", RFC 4186, January 2006.
[RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication
Protocol Method for 3rd Generation Authentication and Key Protocol Method for 3rd Generation Authentication and Key
Agreement (EAP-AKA)", RFC 4187, January 2006. Agreement (EAP-AKA)", RFC 4187, January 2006.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
4306, December 2005. RFC 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 Authentication 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)",
4334, February 2006. RFC 4334, February 2006.
[RFC4763] Vanderveen, M. and H. Soliman, "Extensible Authentication [RFC4763] Vanderveen, M. and H. Soliman, "Extensible Authentication
Protocol Method for Shared-secret Authentication and Key Protocol Method for Shared-secret Authentication and Key
Establishment (EAP-SAKE)", RFC 4763, November 2006. Establishment (EAP-SAKE)", RFC 4763, November 2006.
[RFC4675] Congdon, P., Sanchez, M. and B. Aboba, "RADIUS Attributes
for Virtual LAN and Priority Support", RFC 4675,
September 2006.
[RFCPSK] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: a [RFCPSK] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: a
Pre-Shared Key EAP Method", Internet draft (work in Pre-Shared Key EAP Method", Internet draft (work in
progress), draft-bersani-eap-psk-11.txt, June 2006. progress), draft-bersani-eap-psk-11.txt, June 2006.
[SP800-57] National Institute of Standards and Technology, [SP800-57] National Institute of Standards and Technology,
"Recommendation for Key Management", Special Publication "Recommendation for Key Management", Special Publication
800-57, May 2006. 800-57, May 2006.
[8021XHandoff] [Token] Fantacci, R., Maccari, L., Pecorella, T. and F. Frosali,
Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff in a "A secure and performant token-based authentication for
Public Wireless LAN Based on IEEE 802.1X Model", School of infrastructure and mesh 802.1X networks", IEEE
Computer Science and Engineering, Seoul National Conference on Computer Communications, June 2006.
University, Seoul, Korea, 2002.
[8021XPreAuth] Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff in
a Public Wireless LAN Based on IEEE 802.1x Model",
Proceedings of the IFIP TC6/WG6.8 Working Conference on
Personal Wireless Communications, p.175-182, October
23-25, 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
TruSecure, Jesse Walker of Intel, Joe Salowey of Cisco and Russ TruSecure, Jesse Walker of Intel, Joe Salowey of Cisco and Russ
Housley of Vigil Security for useful feedback. Housley of Vigil Security for useful feedback.
Authors' Addresses Authors' Addresses
skipping to change at page 58, line 39 skipping to change at page 61, line 39
The EAP-GTC method is defined in [RFC3748]. It does not derive keys The EAP-GTC method is defined in [RFC3748]. It does not derive keys
and therefore does not define the Session-Id. The Peer-Id and and therefore does not define the Session-Id. The Peer-Id and
Server-Id are the empty string. Server-Id are the empty string.
EAP-OTP EAP-OTP
The EAP-OTP method is defined in [RFC3748]. It does not derive keys The EAP-OTP method is defined in [RFC3748]. It does not derive keys
and therefore does not define the Session-Id. The Peer-Id and and therefore does not define the Session-Id. The Peer-Id and
Server-Id are the empty string. Server-Id are the empty string.
EAP-TLS
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
nonces. The Peer-Id and Server-Id are the contents of the
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 octets AT_IDENTITY attribute, using only the Actual Identity Length octets
from the beginning, however. Note that the contents are used as they from the beginning, however. Note that the contents are used as they
 End of changes. 112 change blocks. 
439 lines changed or deleted 576 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/