draft-ietf-eap-keying-12.txt   draft-ietf-eap-keying-13.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-12.txt> J. Arkko <draft-ietf-eap-keying-13.txt> P. Eronen
13 April 2006 Ericsson 1 May 2006 Nokia
P. Eronen
Nokia
H. Levkowetz, Ed. H. Levkowetz, Ed.
ipUnplugged ipUnplugged
Extensible Authentication Protocol (EAP) Key Management Framework Extensible Authentication Protocol (EAP) Key Management Framework
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
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 36 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 October 10, 2006. This Internet-Draft will expire on November 10, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society 2006. Copyright (C) The Internet Society 2006.
Abstract Abstract
The Extensible Authentication Protocol (EAP), defined in [RFC3748], The Extensible Authentication Protocol (EAP), defined in [RFC3748],
enables extensible network access authentication. This document enables extensible network access authentication. This document
provides a framework for the transport and usage of keying material provides a framework for the transport and usage of keying material
generated by EAP authentication algorithms, known as "methods". It generated by EAP authentication algorithms, known as "methods". It
also specifies the EAP key hierarchy. also specifies the EAP key hierarchy.
Table of Contents Table of Contents
1. Introduction .......................................... 3 1. Introduction .......................................... 3
1.1 Requirements Language ........................... 3 1.1 Requirements Language ........................... 3
1.2 Terminology ..................................... 3 1.2 Terminology ..................................... 3
1.3 Overview ........................................ 5 1.3 Overview ........................................ 6
1.4 EAP Key Hierarchy ............................... 8 1.4 EAP Key Hierarchy ............................... 8
1.5 Security Goals .................................. 12 1.5 Security Goals .................................. 12
1.6 EAP Invariants .................................. 12 1.6 EAP Invariants .................................. 13
2. Lower Layer Operation ................................. 16 2. Lower Layer Operation ................................. 16
2.1 Transient Session Keys .......................... 17 2.1 Transient Session Keys .......................... 17
2.2 Authenticator Architecture ...................... 18 2.2 Authenticator Architecture ...................... 19
3. Key Management ........................................ 22 3. Key Management ........................................ 23
3.1 Secure Association Protocol ..................... 23 3.1 Secure Association Protocol ..................... 23
3.2 Key Scope ....................................... 25 3.2 Key Scope ....................................... 26
3.3 Parent-Child Relationships ...................... 26 3.3 Parent-Child Relationships ...................... 27
3.4 Local Key Lifetimes ............................. 26 3.4 Local Key Lifetimes ............................. 27
3.5 Exported and Calculated Key Lifetimes ........... 27 3.5 Exported and Calculated Key Lifetimes ........... 28
3.6 Key Cache Synchronization ....................... 29 3.6 Key Cache Synchronization ....................... 29
3.7 Key Strength .................................... 29 3.7 Key Strength .................................... 30
3.8 Key Wrap ........................................ 30 3.8 Key Wrap ........................................ 30
4. Handoff Vulnerabilities ............................... 30 4. Handoff Vulnerabilities ............................... 31
4.1 Authorization ................................... 31 4.1 EAP Pre-authentication .......................... 31
4.2 Correctness ..................................... 32 4.2 Authorization ................................... 32
5. Security Considerations .............................. 35 4.3 Correctness ..................................... 34
5.1 Authenticator Compromise ........................ 36 5. Security Considerations .............................. 37
5.2 Spoofing ........................................ 37 5.1 Authenticator Compromise ........................ 38
5.3 Downgrade Attacks ............................... 37 5.2 Spoofing ........................................ 39
5.4 Unauthorized Disclosure ......................... 38 5.3 Downgrade Attacks ............................... 39
5.5 Replay Protection ............................... 40 5.4 Unauthorized Disclosure ......................... 40
5.6 Key Freshness ................................... 40 5.5 Replay Protection ............................... 42
5.7 Elevation of Privilege .......................... 41 5.6 Key Freshness ................................... 42
5.8 Man-in-the-Middle Attacks ....................... 42 5.7 Elevation of Privilege .......................... 43
5.9 Denial of Service Attacks ....................... 43 5.8 Man-in-the-Middle Attacks ....................... 44
5.10 Impersonation ................................... 43 5.9 Denial of Service Attacks ....................... 45
5.11 Channel Binding ................................. 44 5.10 Impersonation ................................... 45
6. IANA Considerations ................................... 45 5.11 Channel Binding ................................. 46
7. References ............................................ 46 6. IANA Considerations ................................... 47
7.1 Normative References ............................ 46 7. References ............................................ 48
7.2 Informative References .......................... 46 7.1 Normative References ............................ 48
Acknowledgments .............................................. 50 7.2 Informative References .......................... 48
Author's Addresses ........................................... 50 Acknowledgments .............................................. 52
Appendix A - Exported Parameters in Existing Methods ......... 52 Author's Addresses ........................................... 52
Intellectual Property Statement .............................. 53 Appendix A - Exported Parameters in Existing Methods ......... 54
Disclaimer of Validity ....................................... 54 Intellectual Property Statement .............................. 55
Copyright Statement .......................................... 54 Disclaimer of Validity ....................................... 56
Copyright Statement .......................................... 56
1. Introduction 1. Introduction
The Extensible Authentication Protocol (EAP), defined in [RFC3748], The Extensible Authentication Protocol (EAP), defined in [RFC3748],
was designed to enable extensible authentication for network access was designed to enable extensible authentication for network access
in situations in which the IP protocol is not available. Originally in situations in which the Internet Protocol (IP) protocol is not
developed for use with PPP [RFC1661], it has subsequently also been available. Originally developed for use with Point-to-Point Protocol
applied to IEEE 802 wired networks [IEEE-802.1X], wireless networks (PPP) [RFC1661], it has subsequently also been applied to IEEE 802
such as [IEEE-802.11i] and [IEEE-802.16e], and IKEv2 [RFC4306]. wired networks [IEEE-802.1X], wireless networks such as
[IEEE-802.11i] d [IEEE-802.16e], and IKEv2 [RFC4306].
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 generated by EAP authentication algorithms, known as
"methods". In EAP, keying material is generated by EAP methods. "methods". In EAP, keying material is generated by EAP methods.
Part of this keying material may be used by EAP methods themselves Part of this keying material may be used by EAP methods themselves
and part of this material may be exported. The exported keying and part of this material may be exported. The exported keying
material may be transported by AAA protocols and used by Secure material may be transported by Authentication, Authorization and
Association Protocols in the generation or transport of session keys Accounting (AAA) protocols and used by Secure Association Protocols
which are used by lower layer ciphersuites. This document describes in the generation or transport of session keys which are used by
each of these elements and provides a system-level security analysis. lower layer ciphersuites. This document describes each of these
It also specifies the EAP key hierarchy. 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 5, line 27 skipping to change at page 5, line 29
A set of policies and cryptographic state used to protect A set of policies and cryptographic state used to protect
information. Elements of a security association may include information. Elements of a security association may include
cryptographic keys, negotiated ciphersuites and other parameters, cryptographic keys, negotiated ciphersuites and other parameters,
counters, sequence spaces, authorization attributes, etc. counters, sequence spaces, authorization attributes, etc.
Secure Association Protocol Secure Association Protocol
An exchange that occurs between the EAP peer and authenticator in An exchange that occurs between the EAP peer and authenticator in
order to manage the creation and deletion of unicast and multicast order to manage the creation and deletion of unicast and multicast
security associations. security associations.
Session-Id
The EAP Session-Id uniquely identifies an EAP session between an
EAP peer (as identified by the Peer-Id) and server (as identified
by the Server-Id). The EAP Session-Id consists of the
concatenation of the Expanded EAP Type Code (including the Type,
Vendor-Id and Vendor-Type fields defined in [RFC3748] Section 5.7)
and the temporally unique identifier obtained from the method. This
unique identifier is typically constructed from nonces or counters
used within the EAP method exchange. The inclusion of the Expanded
Type Code in the EAP Session-Id ensures that each EAP method has a
distinct Session-Id space. Since an EAP session is not bound to a
particular authenticator or specific ports on the peer and
authenticator, the authenticator port or identity are not included
in the Session-Id.
Transient EAP Keys (TEKs) Transient EAP Keys (TEKs)
Session keys which are used to establish a protected channel Session keys which are used to establish a protected channel
between the EAP peer and server during the EAP authentication between the EAP peer and server during the EAP authentication
exchange. The TEKs are appropriate for use with the ciphersuite exchange. The TEKs are appropriate for use with the ciphersuite
negotiated between EAP peer and server for use in protecting the negotiated between EAP peer and server for use in protecting the
EAP conversation. The TEKs are stored locally by the EAP method EAP conversation. The TEKs are stored locally by the EAP method
and are not exported. Note that the ciphersuite used to set up the and are not exported. Note that the ciphersuite used to set up the
protected channel between the EAP peer and server during EAP protected channel between the EAP peer and server during EAP
authentication is unrelated to the ciphersuite used to subsequently authentication is unrelated to the ciphersuite used to subsequently
protect data sent between the EAP peer and authenticator. protect data sent between the EAP peer and authenticator.
skipping to change at page 6, line 18 skipping to change at page 6, line 36
Phases 0 and 2 are handled by the lower layer protocol and phase 1b Phases 0 and 2 are handled by the lower layer protocol and phase 1b
is typically handled by a AAA protocol. is typically handled by a AAA protocol.
In the discovery phase (phase 0), peers locate authenticators and In the discovery phase (phase 0), peers locate authenticators and
discover their capabilities. A peer may locate an authenticator discover their capabilities. A peer may locate an authenticator
providing access to a particular network, or a peer may locate an providing access to a particular network, or a peer may locate an
authenticator behind a bridge with which it desires to establish a authenticator behind a bridge with which it desires to establish a
Secure Association. Discovery can occur manually or automatically, Secure Association. Discovery can occur manually or automatically,
depending on the lower layer over which EAP runs. depending on the lower layer over which EAP runs.
The authentication phase (phase 1) may begin once the peer and
authenticator discover each other. This phase, if it occurs, always
includes EAP authentication (phase 1a). Where the chosen EAP method
supports key derivation, in phase 1a EAP keying material is derived
on both the peer and the EAP server.
An additional step (phase 1b) is required in deployments which
include a backend authentication server, in order to transport keying
material from the backend authentication server to the authenticator.
In order to obey the principle of Mode Independence (see Section
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
server to the authenticator. Since existing TSK derivation and
transport techniques depend solely on the MSK, in existing
implementations, this is the only keying material replicated in the
AAA key transport phase 1b.
EAP peer Authenticator Auth. Server EAP peer Authenticator Auth. Server
-------- ------------- ------------ -------- ------------- ------------
|<----------------------------->| | |<----------------------------->| |
| Discovery (phase 0) | | | Discovery (phase 0) | |
|<----------------------------->|<----------------------------->| |<----------------------------->|<----------------------------->|
| EAP auth (phase 1a) | AAA pass-through (optional) | | EAP auth (phase 1a) | AAA pass-through (optional) |
| | | | | |
| |<----------------------------->| | |<----------------------------->|
| | AAA Key transport | | | AAA Key transport |
| | (optional; phase 1b) | | | (optional; phase 1b) |
skipping to change at page 6, line 39 skipping to change at page 7, line 26
| Unicast Secure association | | | Unicast Secure association | |
| (phase 2a) | | | (phase 2a) | |
| | | | | |
|<----------------------------->| | |<----------------------------->| |
| Multicast Secure association | | | Multicast Secure association | |
| (optional; phase 2b) | | | (optional; phase 2b) | |
| | | | | |
Figure 1: Conversation Overview Figure 1: Conversation Overview
The authentication phase (phase 1) may begin once the peer and
authenticator discover each other. This phase, if it occurs, always
includes EAP authentication (phase 1a). Where the chosen EAP method
supports key derivation, in phase 1a EAP keying material is derived
on both the peer and the EAP server.
An additional step (phase 1b) is required in deployments which
include a backend authentication server, in order to transport keying
material from the backend authentication server to the authenticator.
In order to obey the principle of Mode Independence (see Section
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
server to the authenticator. Since existing TSK derivation and
transport techniques depend solely on the MSK, in existing
implementations, this is the only keying material replicated in the
AAA key transport phase 1b.
Successful completion of EAP authentication and key derivation by a Successful completion of EAP authentication and key derivation by a
peer and EAP server does not necessarily imply that the peer is peer and EAP server does not necessarily imply that the peer is
committed to joining the network associated with an EAP server. committed to joining the network associated with an EAP server.
Rather, this commitment is implied by the creation of a security Rather, this commitment is implied by the creation of a security
association between the EAP peer and authenticator, as part of the association between the EAP peer and authenticator, as part of the
Secure Association Protocol (phase 2). The Secure Association Secure Association Protocol (phase 2). The Secure Association
Protocol exchange (phase 2) occurs between the peer and authenticator Protocol exchange (phase 2) occurs between the peer and authenticator
in order to manage the creation and deletion of unicast (phase 2a) in order to manage the creation and deletion of unicast (phase 2a)
and multicast (phase 2b) security associations between the peer and and multicast (phase 2b) security associations between the peer and
authenticator. The conversation between the parties is shown in authenticator. The conversation between the parties is shown in
skipping to change at page 8, line 41 skipping to change at page 9, line 10
methods. Part of this keying material may be used by EAP methods methods. Part of this keying material may be used by EAP methods
themselves and part of this material may be exported. In addition to themselves and part of this material may be exported. In addition to
export of keying material, EAP methods may also export associated export of keying material, EAP methods may also export associated
parameters, and may import and export Channel Bindings from the lower parameters, and may import and export Channel Bindings from the lower
layer. layer.
As illustrated in Figure 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 other information associated stores the peer's identity as well as additional information. This
with it. This information may be used to determine whether access to information is typically used outside of the EAP method to determine
some service should be granted. The peer stores information necessary if access to some service should be granted. The peer stores
to choose which secret to use for which service. information necessary to choose which secret to use for which
service.
If authentication is based on proof of possession of the private key
corresponding to the public key contained within a certificate, the
parties store the EAP method to be used and the trust anchors used to
validate the certificates. The EAP server may also store additional
information associated with the peer's identity and the peer stores
information necessary to choose which certificate to use for which
service.
If authentication is based on proof of possession of the private key If authentication is based on proof of possession of the private key
corresponding to the public key contained within a certificate, the corresponding to the public key contained within a certificate, the
parties store the EAP method to be used and the trust anchors used to parties store the EAP method to be used and the trust anchors used to
validate the certificates. The EAP server also stores the peer's validate the certificates. The EAP server also stores the peer's
identity and the peer stores information necessary to choose which identity and the peer stores information necessary to choose which
certificate to use for which service. certificate to use for which service.
Based on the long term credential established between the peer and Based on the long term credential established between the peer and
the server, EAP methods derive two types of keys: the server, EAP methods derive two types of keys:
[1] Keys calculated locally by the EAP method but not exported [a] Keys calculated locally by the EAP method but not exported
by the EAP method, such as the TEKs. by the EAP method, such as the TEKs.
[2] Keying material exported by the EAP method: MSK, EMSK, IV. [b] Keying material exported by the EAP method: MSK, EMSK, IV.
As noted in [RFC3748] Section 7.10, EAP methods generating keys are As noted in [RFC3748] Section 7.10, EAP methods generating keys are
required to calculate and export the MSK and EMSK, which must be at required to calculate and export the MSK and EMSK, which must be at
least 64 octets in length. EAP methods also may export the IV; least 64 octets in length. EAP methods also may export the IV;
however, the use of the IV is deprecated. however, the use of the IV is deprecated.
EAP methods also MAY export method-specific peer and server
identifiers (Peer-Id and Server-Id), a method-specific EAP
conversation identifier known as the Session-Id, and the lifetime of
the exported keys, known as the Key-Lifetime. EAP methods MAY also
support the import and export of Channel Bindings. New EAP method
specifications MUST define the Peer-Id, Server-Id and Session-Id.
The combination of the Peer-Id and Server-Id uniquely specifies the
endpoints of the EAP method exchange when they are provided. The
Peer-Id, Server-Id, and Session-Id for existing EAP methods is
defined in Appendix A.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | ^ | | ^
| EAP Method | | | EAP Method | |
| | | | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | |
| | | | | | | | | | | | | |
| | EAP Method Key |<->| Long-Term | | | | | EAP Method Key |<->| Long-Term | | |
| | Derivation | | Credential | | | | | Derivation | | Credential | | |
| | | | | | | | | | | | | |
| | | +-+-+-+-+-+-+-+ | Local to | | | | +-+-+-+-+-+-+-+ | Local to |
skipping to change at page 9, line 50 skipping to change at page 10, line 39
+-+-|-+-+-+-+-+-+-+-+-|-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+ ---+ +-+-|-+-+-+-+-+-+-+-+-|-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+ ---+
| | | | ^ | | | | ^
| Peer-Id, | | | Exported | | Peer-Id, | | | Exported |
| Server-Id, | Channel | MSK (64+B) | IV (64B) by | | Server-Id, | Channel | MSK (64+B) | IV (64B) by |
| Session-Id, | Bindings | EMSK (64+B) | (Optional) EAP | | Session-Id, | Bindings | EMSK (64+B) | (Optional) EAP |
| Key-Lifetime | & Result | | Method | | Key-Lifetime | & Result | | Method |
V V V V V V V V V V
Figure 2: EAP Method Parameter Import/Export Figure 2: EAP Method Parameter Import/Export
EAP methods also MAY export method-specific peer and server
identifiers (Peer-Id and Server-Id), a method-specific EAP
conversation identifier known as the Session-Id, and the lifetime of
the exported keys, known as the Key-Lifetime. EAP methods MAY also
support the import and export of Channel Bindings. New EAP method
specifications MUST define the Peer-Id, Server-Id and Method-Id. The
combination of the Peer-Id and Server-Id uniquely specifies the
endpoints of the EAP method exchange when they are provided. The
Peer-Id, Server-Id, and Method-Id for existing EAP methods is defined
in Appendix A.
Peer-Id Peer-Id
As described in [RFC3748] Section 7.3, the identity provided in the As described in [RFC3748] Section 7.3, the identity provided in
EAP-Response/Identity, may be different from the peer identity the EAP-Response/Identity, may be different from the peer identity
authenticated by the EAP method. Where the EAP method authenticates authenticated by the EAP method. Where the EAP method
the peer identity, that identity is exported by the method as the authenticates the peer identity, that identity is exported by the
Peer-Id. A suitable EAP peer name may not always be available. method as the Peer-Id. A suitable EAP peer name may not always be
Where an EAP method does not define a method-specific peer identity, available. Where an EAP method does not define a method-specific
the Peer-Id is the null string. peer identity, the Peer-Id is the null string.
Server-Id Server-Id
Where the EAP method authenticates the server identity, that identity Where the EAP method authenticates the server identity, that
is exported by the method as the Server-Id. A suitable EAP server identity is exported by the method as the Server-Id. A suitable
name may not always be available. Where an EAP method does not EAP server name may not always be available. Where an EAP method
define a method-specific peer identity, the Server-Id is the null does not define a method-specific peer identity, the Server-Id is
string. the null string.
Method-Id
EAP method specifications deriving keys MUST specify a temporally
unique method identifier known as the Method-Id. The EAP Method-Id
uniquely identifies an EAP session of a given Type between an EAP
peer and server. The Method-Id is typically constructed from nonces
or counters used within the EAP method exchange.
Session-Id Session-Id
The Session-Id uniquely identifies an EAP session between an EAP peer The Session-Id uniquely identifies an EAP session between an EAP
(as identified by the Peer-Id) and server (as identified by the peer (as identified by the Peer-Id) and server (as identified by
Server-Id). The EAP Session-Id consists of the concatenation of the the Server-Id). The EAP Session-Id consists of the concatenation
Expanded EAP Type Code (including the Type, Vendor-Id and Vendor-Type of the Expanded EAP Type Code (including the Type, Vendor-Id and
fields defined in [RFC3748] Section 5.7) and the Method-Id. The Vendor-Type fields defined in [RFC3748] Section 5.7) and a
inclusion of the Expanded Type Code in the EAP Session-Id ensures temporally unique identifier obtained from the method. This
that each EAP method has a distinct Session-Id space. Since an EAP unique identifier is ty pically constructed from nonces or
session is not bound to a particular authenticator or specific ports counters used within the EAP method exchange. The inclusion of
on the peer and authenticator, the authenticator port or identity are the Expanded Type Code in the EAP Session-Id ensures that each EAP
not included in the Session-Id. method has a distinct Session-Id space. Since an EAP session is
not bound to a particular authenticator or specific ports on the
peer and authenticator, the authenticator port or identity are not
included in the Session-Id.
Key-Lifetime Key-Lifetime
While EAP itself does not support key lifetime negotiation, it is While EAP itself does not support key lifetime negotiation, it is
possible to specify methods that do. However, systems that rely on possible to specify methods that do. However, systems that rely
such negotiation for exported keys would only function with these on such negotiation for exported keys would only function with
methods. As a result, it is NOT RECOMMENDED to use this approach as these methods. As a result, it is NOT RECOMMENDED to use this
the sole way to determine key lifetimes. approach as the sole way to determine key lifetimes.
Channel Bindings Channel Bindings
Channel Bindings include lower layer parameters that are verified for Channel Bindings include lower layer parameters that are verified
consistency between the EAP peer and server. In order to avoid for consistency between the EAP peer and server. In order to
introducing media dependencies, EAP methods that transport Channel avoid introducing media dependencies, EAP methods that transport
Binding data MUST treat this data as opaque octets. Channel Binding data MUST treat this data as opaque octets.
Typically the EAP method imports Channel Bindings from the lower Typically the EAP method imports Channel Bindings from the lower
layer on the peer, and transmits them securely to the EAP server, layer on the peer, and transmits them securely to the EAP server,
which exports them to the lower layer or AAA layer. However, which exports them to the lower layer or AAA layer. However,
transport may occur from EAP server to peer, or may be bi- transport may occur from EAP server to peer, or may be bi-
directional. On the side of the exchange (peer or server) where directional. On the side of the exchange (peer or server) where
Channel Bindings are verified, the lower layer or AAA layer passes Channel Bindings are verified, the lower layer or AAA layer passes
the result of the verification (TRUE or FALSE) up to the EAP method. the result of the verification (TRUE or FALSE) up to the EAP
method.
While the verification can be done either by the peer or the server, While the verification can be done either by the peer or the
typically only the server has the knowledge to determine the server, typically only the server has the knowledge to determine
correctness of the values, as opposed to merely verifying their the correctness of the values, as opposed to merely verifying
equality. See Section 5.11 for further discussion. their equality. See Section 5.11 for further discussion.
1.4.1. Key Naming 1.4.1. Key Naming
Each key created within the EAP key management framework has a name Each key created within the EAP key management framework has a name
(a unique identifier), as well as a scope (the parties to whom the (a unique identifier), as well as a scope (the parties to whom the
key is available). The scope of exported parameters is defined by key is available). The scope of exported parameters is defined by
the EAP peer name (if securely exchanged within the method) and the the EAP peer name (if securely exchanged within the method) and the
EAP server name (also only if securely exchanged). Where a peer or EAP server name (also only if securely exchanged). Where a peer or
server name is missing the null string is used. server name is missing the null string is used.
skipping to change at page 19, line 29 skipping to change at page 20, line 5
Both the EAP peer and authenticator may have more than one physical Both the EAP peer and authenticator may have more than one physical
or logical port. A peer may simultaneously access the network via or logical port. A peer may simultaneously access the network via
multiple authenticators, or via multiple physical or logical ports on multiple authenticators, or via multiple physical or logical ports on
a given authenticator. Similarly, an authenticator may offer network a given authenticator. Similarly, an authenticator may offer network
access to multiple peers, each via a separate physical or logical access to multiple peers, each via a separate physical or logical
port. When a single physical authenticator advertises itself as port. When a single physical authenticator advertises itself as
multiple "virtual authenticators", it is possible for a single multiple "virtual authenticators", it is possible for a single
physical port to belong to multiple "virtual authenticators". The physical port to belong to multiple "virtual authenticators". The
situation is illustrated in Figure 3. situation is illustrated in Figure 3.
+-+-+-+-+
| EAP |
| Peer |
+-+-+-+-+
| | | Peer Ports
/ | \
/ | \
/ | \
/ | \
/ | \
/ | \
/ | \
/ | \
| | | | | | | | | Authenticator Ports
+-+-+-+-+ +-+-+-+-+ +-+-+-+-+
| | | | | |
| Auth. | | Auth. | | Auth. |
| | | | | |
+-+-+-+-+ +-+-+-+-+ +-+-+-+-+
\ | /
\ | /
\ | /
EAP over AAA \ | /
(optional) \ | /
\ | /
\ | /
\ | /
+-+-+-+-+
| EAP |
|Server |
+-+-+-+-+
Figure 3: Relationship between EAP peer, authenticator and server
2.2.1. Authenticator Identification 2.2.1. Authenticator 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. The authenticator identity, identified by the Peer-Id and Server-Id. The authenticator identity,
if considered at all by the EAP method, is treated as an opaque blob if considered at all by the EAP method, is treated as an opaque blob
for the purposes of Channel Bindings (see Section 5.12). However, for the purposes of Channel Bindings (see Section 5.12). However,
the Secure Association Protocol conversation is between the peer and the Secure Association Protocol conversation is between the peer and
the authenticator, and therefore the authenticator and peer the authenticator, and therefore the authenticator and peer
identities are relevant to that exchange, and define the scope of use identities are relevant to that exchange, and define the scope of use
of the EAP keying material passed down to the lower layer. of the EAP keying material passed down to the lower layer.
skipping to change at page 20, line 7 skipping to change at page 21, line 17
it will be unable to determine whether transported EAP keying it will be unable to determine whether transported EAP keying
material has been shared outside of its authorized scope, and material has been shared outside of its authorized scope, and
therefore needs to be considered compromised. There is also a therefore needs to be considered compromised. There is also a
practical problem because the EAP peer will be unable to utilize the practical problem because the EAP peer will be unable to utilize the
EAP authenticator key cache in an efficient way. EAP authenticator key cache in an efficient way.
Where the peer and authenticator identify themselves within the lower Where the peer and authenticator identify themselves within the lower
layer using a port identifier such as a link layer address, this layer using a port identifier such as a link layer address, this
creates a number of problems: creates a number of problems:
[1] It may not be obvious to the peer which authenticator ports are [a] It may not be obvious to the peer which authenticator ports are
associated with which authenticators. associated with which authenticators.
[2] It may not be obvious to the authenticator which peer ports are [b] It may not be obvious to the authenticator which peer ports are
associated with which peers. associated with which peers.
[3] It may not be obvious to the peer which "virtual authenticator" it [c] It may not be obvious to the peer which "virtual authenticator" it
is communicating with. is communicating with.
[4] It may not be obvious to the authenticator which "virtual peer" it [d] It may not be obvious to the authenticator which "virtual peer" it
is communicating with. is communicating with.
+-+-+-+-+
| EAP |
| Peer |
+-+-+-+-+
| | | Peer Ports
/ | \
/ | \
/ | \
/ | \
/ | \
/ | \
/ | \
/ | \
| | | | | | | | | Authenticator Ports
+-+-+-+-+ +-+-+-+-+ +-+-+-+-+
| | | | | |
| Auth. | | Auth. | | Auth. |
| | | | | |
+-+-+-+-+ +-+-+-+-+ +-+-+-+-+
\ | /
\ | /
\ | /
EAP over AAA \ | /
(optional) \ | /
\ | /
\ | /
\ | /
+-+-+-+-+
| EAP |
|Server |
+-+-+-+-+
Figure 3: Relationship between EAP peer, authenticator and server
Since an authenticator may have multiple ports, the authenticator Since an authenticator may have multiple ports, the authenticator
identifier used within the Secure Association Protocol exchange identifier used within the Secure Association Protocol exchange
SHOULD be distinct from any port identifier (e.g. MAC address). SHOULD be distinct from any port identifier (e.g. MAC address).
Similarly, where a peer may have multiple ports, and sharing of EAP Similarly, where a peer may have multiple ports, and sharing of EAP
keying material and parameters between peer ports of the same link keying material and parameters between peer ports of the same link
type is allowed, the peer identifier used within the Secure type is allowed, the peer identifier used within the Secure
Association Protocol exchange SHOULD also be distinct from any port Association Protocol exchange SHOULD also be distinct from any port
identifier. identifier.
AAA protocols such as RADIUS [RFC3579] and Diameter [RFC4072] provide AAA protocols such as RADIUS [RFC3579] and Diameter [RFC4072]
a mechanism for the identification of AAA clients; since the EAP provide a mechanism for the identification of AAA clients; since
authenticator and AAA client are always co-resident, this mechanism the EAP authenticator and AAA client are always co-resident, this
is applicable to the identification of EAP authenticators. mechanism is applicable to the identification of EAP
authenticators.
RADIUS [RFC2865] requires that an Access-Request packet contain one RADIUS [RFC2865] requires that an Access-Request packet contain one
or more of the NAS-Identifier, NAS-IP-Address and NAS-IPv6-Address or more of the NAS-Identifier, NAS-IP-Address and NAS-IPv6-Address
attributes. Since a NAS may have more than one IP address, the NAS- attributes. Since a NAS may have more than one IP address, the
Identifier attribute is RECOMMENDED for the unambiguous NAS-Identifier attribute is RECOMMENDED for the unambiguous
identification of the EAP authenticator. identification of the EAP authenticator.
From the point of view of the backend authentication server, EAP From the point of view of the backend authentication server, EAP
keying material and parameters are transported to the EAP keying material and parameters are transported to the EAP
authenticator identified by the NAS-Identifier attribute. Since an authenticator identified by the NAS-Identifier attribute. Since an
EAP authenticator MUST NOT share EAP keying material or parameters EAP authenticator MUST NOT share EAP keying material or parameters
with another party, if the EAP peer or backend authentication server with another party, if the EAP peer or backend authentication
detects use of EAP keying material and parameters outside the scope server detects use of EAP keying material and parameters outside
defined by the NAS-Identifier, the keying material MUST be considered the scope defined by the NAS-Identifier, the keying material MUST
compromised. be considered compromised.
In order to ensure that lower layer identities are securely verified In order to ensure that lower layer identities are securely
by all parties, it is RECOMMENDED that the parties use a set of verified by all parties, it is RECOMMENDED that the parties use a
identities that are consistent between the conversation phases. This set of identities that are consistent between the conversation
can be achieved by: phases. This can be achieved by:
[a] Specifying the lower layer parameters used to identify the [a] Specifying the lower layer parameters used to identify the
authenticator and peer; authenticator and peer;
[b] Communicating the lower layer identities between the peer and [b] Communicating the lower layer identities between the peer and
authenticator within phase 0; authenticator within phase 0;
[c] Communicating the lower layer authenticator identity between the [c] Communicating the lower layer authenticator identity between the
authenticator and backend server within the NAS-Identifier authenticator and backend server within the NAS-Identifier
attribute; attribute;
skipping to change at page 22, line 16 skipping to change at page 22, line 41
phase 2a; phase 2a;
[f] Utilizing the advertised lower layer identities to enable the peer [f] Utilizing the advertised lower layer identities to enable the peer
and authenticator to verify that keys are maintained within the and authenticator to verify that keys are maintained within the
advertised scope; advertised scope;
2.2.2. Virtual Authenticators 2.2.2. Virtual Authenticators
When a single physical authenticator advertises itself as multiple When a single physical authenticator advertises itself as multiple
"virtual authenticators", a number of security vulnerabilities may "virtual authenticators", a number of security vulnerabilities may
arise if the peer and authenticator are not correctly identified. arise. For example, the peer may assume that the "virtual
For example, the peer may assume that the "virtual authenticators" authenticators" are distinct and do not share a key cache, whereas,
are distinct and do not share a key cache, whereas, depending on the depending on the architecture of the physical authenticator, a shared
architecture of the physical authenticator, a shared key cache may or key cache may or may not be implemented.
may not be implemented.
Where EAP keying material is shared between "virtual authenticators" Where EAP keying material is shared between "virtual authenticators"
an attacker acting as a peer could authenticate with the "Guest" an attacker acting as a peer could authenticate with the "Guest"
"virtual authenticator" and derive EAP keying material. If the "virtual authenticator" and derive EAP keying material. If the
virtual authenticators share a key cache, then the peer can utilize virtual authenticators share a key cache, then the peer can utilize
the EAP keying material derived for the "Guest" network to obtain the EAP keying material derived for the "Guest" network to obtain
access to the "Corporate Intranet" virtual authenticator. access to the "Corporate Intranet" virtual authenticator.
In order to address these issues: In order to address these issues:
skipping to change at page 22, line 44 skipping to change at page 23, line 20
obtain elevated privileges even where the key cache is shared obtain elevated privileges even where the key cache is shared
between "virtual authenticators". between "virtual authenticators".
[h] It is RECOMMENDED that physical authenticators maintain separate [h] It is RECOMMENDED that physical authenticators maintain separate
key caches for each "virtual authenticator". key caches for each "virtual authenticator".
[i] It is RECOMMENDED that each "virtual authenticator" identify itself [i] It is RECOMMENDED that each "virtual authenticator" identify itself
distinctly to the backend authentication server, such as by distinctly to the backend authentication server, such as by
utilizing a distinct NAS-Identifier attribute. This enables the utilizing a distinct NAS-Identifier attribute. This enables the
backend authentication server to utilize a separate credential to backend authentication server to utilize a separate credential to
authenticate each "virtual authenticator". authenticate each "virtual authenticator", and for the peer and
backend authentication server to verify the authenticator identity
via Channel Bindings (see Section 5.11).
3. Key Management 3. Key Management
EAP as defined in [RFC3748] supports key derivation, but does not EAP as defined in [RFC3748] supports key derivation, but does not
provide for the management of exported or derived keys. Although EAP provide for the management of exported or derived keys. Although EAP
methods may support "fast reconnect" as defined in [RFC3748] Section methods may support "fast reconnect" as defined in [RFC3748] Section
7.2.1, EAP does not support re-key of exported keys without re- 7.2.1, EAP does not support re-key of exported keys without re-
authentication. Existing EAP methods do not export the Key-Lifetime authentication. Existing EAP methods do not export the Key-Lifetime
parameter; in the interest of method independence, key management of parameter; in the interest of method independence, key management of
exported or derived keys SHOULD NOT be provided within EAP methods. exported or derived keys SHOULD NOT be provided within EAP methods.
skipping to change at page 29, line 39 skipping to change at page 30, line 22
The lower layer may utilize the Discovery phase 0 to improve key The lower layer may utilize the Discovery phase 0 to improve key
cache synchronization. For example, if the authenticator manages the cache synchronization. For example, if the authenticator manages the
key cache by deleting the oldest key first (LIFO), the relative key cache by deleting the oldest key first (LIFO), the relative
creation time of the last key to be deleted could be advertised creation time of the last key to be deleted could be advertised
within the Discovery phase, enabling the peer to determine whether within the Discovery phase, enabling the peer to determine whether
keying material had been prematurely expired from the authenticator keying material had been prematurely expired from the authenticator
key cache. key cache.
3.7. Key Strength 3.7. Key Strength
In order to guard against brute force attacks, EAP methods deriving In order to guard against brute force attacks, EAP methods supporting
keys need to be capable of generating keys with an appropriate key derivation need to be capable of generating keying material with
effective symmetric key strength. In order to ensure that key an appropriate effective symmetric key strength. In order to ensure
generation is not the weakest link, it is RECOMMENDED that EAP that EAP key generation is not the weakest link, it is RECOMMENDED
methods utilizing public key cryptography choose a public key that that EAP methods utilizing public key cryptography choose a public
has a cryptographic strength meeting the symmetric key strength key that has a cryptographic strength meeting the symmetric key
requirement. strength requirement.
As noted in [RFC3766] Section 5, this results in the following As noted in [RFC3766] Section 5, this results in the following
required RSA or DH module and DSA subgroup size in bits, for a given required RSA or DH module and DSA subgroup size in bits, for a given
level of attack resistance in bits: level of attack resistance in bits:
Attack Resistance RSA or DH Modulus DSA subgroup Attack Resistance RSA or DH Modulus DSA subgroup
(bits) size (bits) size (bits) (bits) size (bits) size (bits)
----------------- ----------------- ------------ ----------------- ----------------- ------------
70 947 128 70 947 128
80 1228 145 80 1228 145
skipping to change at page 30, line 23 skipping to change at page 31, line 4
200 8719 373 200 8719 373
250 14596 475 250 14596 475
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-
Authenticator attribute, and concerns exist relating to the security Authenticator attribute, and concerns exist relating to the security
of this hash [MD5Collision]. of this hash [MD5Collision].
As discussed in [RFC3579] Section 4.3, the security vulnerabilities As discussed in [RFC3579] Section 4.3, the security vulnerabilities
of RADIUS are extensive, and therefore development of an alternative of RADIUS are extensive, and therefore development of an alternative
key wrap technique based on the RADIUS shared secret would not key wrap technique based on the RADIUS shared secret would not
substantially improve security. As a result, [RFC3759] Section 4.2 substantially improve security. As a result, [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 cleartext key attributes, to be Diameter EAP [RFC4072], which defines cleartext key attributes, to be
protected by IPsec or TLS. protected by IPsec or TLS.
4. Handoff Vulnerabilities 4. Handoff Vulnerabilities
With EAP, several mechanisms are available to reduce the latency in With EAP, several mechanisms are available to reduce the latency in
handoff between authenticators: handoff between authenticators:
[1] EAP pre-authentication. This utilizes EAP to pre-establish EAP [a] EAP pre-authentication. This utilizes EAP to pre-establish EAP
keying material on an authenticator prior to arrival of the peer. keying material on an authenticator prior to arrival of the peer.
Use of pre-authentication within IEEE 802.11 is described in Use of pre-authentication within IEEE 802.11 is described in
[8021XHandoff] and [IEEE-802.11i]. [8021XHandoff] and [IEEE-802.11i].
[2] Key caching. This mechanism enables an EAP peer to re-attach to an [b] Key caching. This mechanism enables an EAP peer to re-attach to an
authenticator without requiring EAP re-authentication. authenticator without requiring EAP re-authentication.
[3] Context transfer, such as is defined in [IEEE-802.11F] (now [c] Context transfer, such as is defined in [IEEE-802.11F] (now
deprecated) and [RFC4067]. Use of context transfer for handoff deprecated) and [RFC4067]. Use of context transfer for handoff
latency improvement is described in [IEEE-02-758]. latency improvement is described in [IEEE-02-758].
[4] Proactive key distribution, such as is described in [IEEE-02-758] [d] Proactive key distribution, such as is described in
and [I-D.irtf-aaaarch-handoff]. [IEEE-02-758][IEEE-03-084] and [I-D.irtf-aaaarch-handoff].
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 mechanisms.
4.1. Authorization 4.1. EAP Pre-authentication
EAP pre-authentication enables an EAP peer to pre-establish EAP
keying material with an authenticator prior to attaching to it. Where
there is sufficient time to pre-establish keying material prior to
changing the point of attachment, this may enable the peer to remove
EAP authentication from the critical path for handoff, reducing
latency.
EAP pre-authentication exchanges typically differ from a normal EAP
conversation only with respect to the lower layer encapsulation. For
example, in [IEEE-802.11i], EAP pre-authentication frames are
encapsulated within a distinct Ethertype, but otherwise conform to
the encapsulation described in [IEEE-802.1X]. As a result, an EAP
pre-authentication conversation that eventually results in
establishment of security associations differs little from the model
described in Section 1.3, other than the potential introduction of a
delay between Phase 1 and Phase 2. However, since a peer may complete
EAP pre-authentication with an authenticator without eventually
attaching to it, it is possible that Phase 2 will not occur.
[RFC3580] describes only minor differences in the AAA exchange
occurring as a result of EAP pre-authentication as compared with an
ordinary EAP authentication exchange. For example, since in 802.11i
an Association exchange does not occur prior to EAP pre-
authentication, the SSID is not yet known. As a result, an Access-
Request generated as the result of 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
authentication exchange only in subtle ways, the backend
authentication server may not be aware of whether it is engaging in a
pre-authentication exchange, resulting in operational or security
problems. For example, where the authenticator does not include the
SSID within the Called-Station-Id attribute in ordinary requests,
pre-authentication requests may appear indistinguishable. As a
result, the backend authentication server may not be able to
correctly calculate the simultaneous sessions in progress, either
preventing successful completion of 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 pre-
authentication requests more reliably, it is recommended that EAP
pre-authentication requests be explicitly identified within AAA
protocols. Also, in order to supress unnecessary EAP pre-
authentication exchanges, it is recommended that authenticators
unambiguously identify themselves as described in Section 2.2.1,
allowing the peer to determine whether it has previously established
EAP keying material with that authenticator.
4.2. Authorization
In a typical network access scenario (dial-in, wireless LAN, etc.) In a typical network access scenario (dial-in, wireless LAN, etc.)
access control mechanisms are typically applied. These mechanisms access control mechanisms are typically applied. These mechanisms
include user authentication as well as authorization for the offered include user authentication as well as authorization for the offered
service. service.
As a part of the authentication process, the 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. The user
authorizations are transmitted by the backend authentication server authorizations are transmitted by the backend authentication server
to the EAP authenticator (also known as the Network Access Server or to the EAP authenticator (also known as the Network Access Server or
skipping to change at page 32, line 20 skipping to change at page 34, line 9
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/day and the
capabilities of the requesting authenticator device? capabilities of the requesting authenticator device?
4.2. Correctness 4.3. Correctness
When the AAA exchange is bypassed via use of techniques such as key When the AAA exchange is bypassed via use of techniques such as key
caching, it can be challenging to ensure that authorization is caching, it can be challenging to ensure that authorization is
properly handled. Challenges include: properly handled. Challenges include:
[a] Consistent application of session time limits. Bypassing AAA [a] Consistent application of session time limits. Bypassing AAA
should not automatically increase the available session time, should not automatically increase the available session time,
allowing a user to endlessly extend their network access by allowing a user to endlessly extend their network access by
changing the point of attachment. changing the point of attachment.
skipping to change at page 35, line 17 skipping to change at page 37, line 9
insecure channel without permission from the backend authentication insecure channel without permission from the backend authentication
server. Thus the definition of a "known but unsupported service" server. Thus the definition of a "known but unsupported service"
MUST encompass requests for unavailable security services. This MUST encompass requests for unavailable security services. This
includes vendor-specific attributes related to security, such as includes vendor-specific attributes related to security, such as
those described in [RFC2548]. those described in [RFC2548].
5. Security Considerations 5. Security Considerations
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 [RFC3784] 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.
However, in addition to threats against EAP and AAA, there are other However, in addition to threats against EAP and AAA, there are other
system-level threats: system-level threats:
[1] An attacker may compromise or steal an EAP authenticator, in an [a] An attacker may compromise or steal an EAP authenticator, in an
attempt to gain access to other EAP authenticators or obtain long- attempt to gain access to other EAP authenticators or obtain long-
term secrets. term secrets.
[2] An attacker may try to modify or spoof packets, including Discovery [b] An attacker may try to modify or spoof packets, including Discovery
or Secure Association Protocol frames, EAP or AAA packets. or Secure Association Protocol frames, EAP or AAA packets.
[3] An attacker may attempt a downgrade attack in order to exploit [c] An attacker may attempt a downgrade attack in order to exploit
known weaknesses in an authentication method or cryptographic known weaknesses in an authentication method or cryptographic
transform. transform.
[4] An attacker may attempt to induce an EAP peer, authenticator or [d] An attacker may attempt to induce an EAP peer, authenticator or
server to disclose keying material to an unauthorized party, or server to disclose keying material to an unauthorized party, or
utilize keying material outside the context that it was intended utilize keying material outside the context that it was intended
for. for.
[5] An attacker may replay packets. [e] An attacker may replay packets.
[6] An attacker may cause an EAP peer, authenticator or server to reuse [f] An attacker may cause an EAP peer, authenticator or server to reuse
an stale key. Use of stale keys may also occur unintentionally. an stale key. Use of stale keys may also occur unintentionally.
For example, a poorly implemented backend authentication server may For example, a poorly implemented backend authentication server may
provide stale keying material to an authenticator, or a poorly provide stale keying material to an authenticator, or a poorly
implemented authenticator may reuse nonces. implemented authenticator may reuse nonces.
[7] An authenticated attacker may attempt to obtain elevated privilege [g] An authenticated attacker may attempt to obtain elevated privilege
in order to access information that it does not have rights to. in order to access information that it does not have rights to.
[8] An attacker may attempt a man-in-the-middle attack in order to gain [h] An attacker may attempt a man-in-the-middle attack in order to gain
access to the network. access to the network.
[9] An attacker may launch a denial of service attack against the EAP [i] An attacker may launch a denial of service attack against the EAP
peer, authenticator or backend authentication server. peer, authenticator or backend authentication server.
[10] An attacker may compromise an EAP authenticator in an effort to [j] An attacker may compromise an EAP authenticator in an effort to
commit fraud. For example, a compromised authenticator may provide commit fraud. For example, a compromised authenticator may provide
incorrect information to the EAP peer and/or server via out-of-band incorrect information to the EAP peer and/or server via out-of-band
mechanisms (such as via a AAA or lower layer protocol). This mechanisms (such as via a AAA or lower layer protocol). This
includes impersonating another authenticator, or providing includes impersonating another authenticator, or providing
inconsistent information to the peer and EAP server. inconsistent information to the peer and EAP server.
In order to address these threats, [Housley] provides a description In order to address these threats, [Housley] provides a description
of mandatory system security properties. Issues relating to system of mandatory system security properties. Issues relating to system
security requirements are discussed in the sections that follow. security requirements are discussed in the sections that follow.
skipping to change at page 41, line 29 skipping to change at page 43, line 25
AAA The AAA protocol needs to ensure that transported keying material AAA The AAA protocol needs to ensure that transported keying material
is fresh and is not utilized outside its recommended lifetime. is fresh and is not utilized outside its recommended lifetime.
Replay protection is necessary for key freshness, but an attacker Replay protection is necessary for key freshness, but an attacker
can deliver a stale (and therefore potentially compromised) key in can deliver a stale (and therefore potentially compromised) key in
a replay-protected message, so replay protection is not sufficient. a replay-protected message, so replay protection is not sufficient.
As discussed in Section 3.5, the Session-Timeout attribute enables As discussed in Section 3.5, the Session-Timeout attribute enables
the backend authentication server to limit the exposure of the backend authentication server to limit the exposure of
transported EAP keying material. transported EAP keying material.
The EAP Session-Id, derived from the EAP Type and Method-Id (based The EAP Session-Id, derived from the Expanded EAP Type and the
on the nonces contributed by the peer and server) enables the EAP temporally unique identifier obtained from the method, enables the
peer, authenticator and server to distinguish EAP conversations. EAP peer, authenticator and server to distinguish EAP
However, unless the authenticator keeps track of EAP Session-Ids, conversations. However, unless the authenticator keeps track of
the authenticator cannot use the Session-Id to guarantee the EAP Session-Ids, the authenticator cannot use the Session-Id to
freshness of EAP keying material. guarantee the freshness of EAP keying material.
Lower Layer Lower Layer
As described in Section 3.1, the lower layer Secure Association As described in Section 3.1, the lower layer Secure Association
Protocol MUST generate a fresh session key for each session, even Protocol MUST generate a fresh session key for each session, even
if the keying material and parameters provided by EAP methods are if the keying material and parameters provided by EAP methods are
cached, or either the peer or authenticator lack a high entropy cached, or either the peer or authenticator lack a high entropy
random number generator. A RECOMMENDED method is for the peer and random number generator. A RECOMMENDED method is for the peer and
authenticator to each provide a nonce or counter used in session authenticator to each provide a nonce or counter used in session
key derivation. If a nonce is used, it is RECOMMENDED that it be key derivation. If a nonce is used, it is RECOMMENDED that it be
at least 128 bits. at least 128 bits.
skipping to change at page 45, line 29 skipping to change at page 47, line 29
[RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address [RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address
[RFC2865], and NAS-IPv6-Address [RFC3162]. [RFC2865], and NAS-IPv6-Address [RFC3162].
Using such a protected exchange, it is possible to match the channel Using such a protected exchange, it is possible to match the channel
properties provided by the authenticator via out-of-band mechanisms properties provided by the authenticator via out-of-band mechanisms
against those exchanged within the EAP method. For example, see the against those exchanged within the EAP method. For example, see the
discussion in Section 1.4 as well as [I-D.arkko-eap-service-identity- discussion in Section 1.4 as well as [I-D.arkko-eap-service-identity-
auth]. auth].
It is also possible to achieve Channel Bindings without transporting It is also possible to achieve Channel Bindings without transporting
data over EAP. For example, see [I-D.draft-ohba-eap-aaakey-binding]. data over EAP. For example, see [I-D.draft-ohba-eap-channel-
In this approach the authenticator informs the backend server about binding]. In this approach the backend server calculates transported
the Channel Binding parameters using AAA, and the backend server keying material based on the parameter set pre-configured for the
calculates transported keying material based on this parameter set, authenticator, making it impossible for the peer and authenticator to
making it impossible for the peer and authenticator to complete the complete the Secure Association Protocol if there was a mismatch in
Secure Association Protocol if there was a mismatch in the the parameters.
parameters.
The main difference between these approaches is that Channel Binding The main difference between these approaches is that Channel Binding
support within an EAP method may require upgrading or changing the support within an EAP method may require upgrading or changing the
EAP method, impacting both the peer and the server. Where Channel EAP method, impacting both the peer and the server. Where Channel
Bindings are implemented in AAA, the peer, authenticator and the Bindings are implemented in AAA, the peer, authenticator and the
backend server need to be upgraded, but the EAP method need not be backend server need to be upgraded, but the EAP method need not be
modified. modified.
6. IANA Considerations 6. IANA Considerations
skipping to change at page 48, line 7 skipping to change at page 50, line 7
Puthenkulam, J., "The Compound Authentication Binding Puthenkulam, J., "The Compound Authentication Binding
Problem", draft-puthenkulam-eap-binding-04 (work in Problem", draft-puthenkulam-eap-binding-04 (work in
progress), October 2003. progress), October 2003.
[I-D.arkko-eap-service-identity-auth] [I-D.arkko-eap-service-identity-auth]
Arkko, J. and P. Eronen, "Authenticated Service Information Arkko, J. and P. Eronen, "Authenticated Service Information
for the Extensible Authentication Protocol (EAP)", draft- for the Extensible Authentication Protocol (EAP)", draft-
arkko-eap-service-identity-auth-02.txt (work in progress), arkko-eap-service-identity-auth-02.txt (work in progress),
May 2005. May 2005.
[I-D.ohba-eap-aaakey-binding] [I-D.ohba-eap-channel-binding]
Ohba, Y., "AAA-Key Derivation with Channel Binding", draft- Ohba, Y., Parthasrathy, M. and M. Yanagiya, "Channel
ohba-eap-aaakey-binding-00.txt (work in progress), May Binding Mechanism Based on Parameter Binding in Key
2005. Derivation", draft-ohba-eap-channel-binding-00.txt (work in
progress), January 2006.
[I-D.irtf-aaaarch-handoff] [I-D.irtf-aaaarch-handoff]
Arbaugh, W. and B. Aboba, "Handoff Extension to RADIUS", Arbaugh, W. and B. Aboba, "Handoff Extension to RADIUS",
draft-irtf-aaaarch-handoff-04.txt (work in progress), draft-irtf-aaaarch-handoff-04.txt (work in progress),
October 2003. October 2003.
[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
[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 Protocol
(ECP)", RFC 1968, June 1996. (ECP)", RFC 1968, June 1996.
[RFC2230] Atkinson, R., "Key Exchange Delegation Record for the 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", RFC
2535, March 1999. 2535, March 1999.
skipping to change at page 49, line 19 skipping to change at page 51, line 23
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, Authentication Dial In User Service (RADIUS)", RFC 2865,
June 2000. 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]
[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.
[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 Authentication
Protocol (EAP)", RFC 3579, September 2003. 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.
skipping to change at page 49, line 44 skipping to change at page 51, line 50
Keys Used For Exchanging Symmetric Keys", RFC 3766, April Keys Used For Exchanging Symmetric Keys", RFC 3766, April
2004. 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.
[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.
[RFC4046] Baugher, M., Canetti, R., Dondeti, L. and F. Lindholm,
"Multicast Security (MSEC) Group Key Management
Architecture", RFC 4046, April 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.
skipping to change at page 52, line 7 skipping to change at page 54, line 7
ipUnplugged AB ipUnplugged AB
Arenavagen 27 Arenavagen 27
Stockholm S-121 28 Stockholm S-121 28
SWEDEN SWEDEN
Phone: +46 708 32 16 08 Phone: +46 708 32 16 08
EMail: henrik@levkowetz.com EMail: henrik@levkowetz.com
Appendix A - Exported Parameters in Existing Methods Appendix A - Exported Parameters in Existing Methods
This Appendix specifies Method-Id, Peer-Id, Server-Id and Key- This Appendix specifies Session-Id, Peer-Id, Server-Id and Key-
Lifetime for EAP methods that have been published prior to this Lifetime for EAP methods that have been published prior to this
specification. Future EAP method specifications MUST include a specification. Future EAP method specifications MUST include a
definition of the Method-Id, Peer-Id, and Server-Id (could be the definition of the Session-Id, Peer-Id, and Server-Id (could be the
empty string) and MAY also define the Key-Lifetime (assumed to be empty string) and MAY also define the Key-Lifetime (assumed to be
indeterminate if not described). indeterminate if not described).
EAP-Identity EAP-Identity
The EAP-Identity method is defined in [RC3748]. It does not The EAP-Identity method is defined in [RC3748]. It does not
derive keys, and therefore does not define the Key-Lifetime or derive keys, and therefore does not define the Key-Lifetime or
Method-Id. The Peer-Id exported by the Identity method is Session-Id. The Peer-Id exported by the Identity method is
determined by the octets included within the EAP- determined by the octets included within the EAP-
Response/Identity. The Server-Id is the empty string (zero Response/Identity. The Server-Id is the empty string (zero
length). length).
EAP-Notification EAP-Notification
The EAP-Notification method is defined in [RFC3748]. It does not The EAP-Notification method is defined in [RFC3748]. It does not
derive keys and therefore does not define the Key-Lifetime and derive keys and therefore does not define the Key-Lifetime and
Method-Id. The Peer-Id and Server-Id are the empty string (zero Session-Id. The Peer-Id and Server-Id are the empty string (zero
length). length).
EAP-GTC EAP-GTC
The EAP-GTC method is defined in [RFC3748]. It does not derive The EAP-GTC method is defined in [RFC3748]. It does not derive
keys and therefore does not define the Key-Lifetime and Method-Id. keys and therefore does not define the Key-Lifetime and Session-
The Peer-Id and Server-Id are the empty string. Id. The Peer-Id and Server-Id are the empty string.
EAP-OTP EAP-OTP
The EAP-OTP method is defined in [RFC3748]. It does not derive The EAP-OTP method is defined in [RFC3748]. It does not derive
keys and therefore does not define the Key-Lifetime and Method-Id. keys and therefore does not define the Key-Lifetime and Session-
The Peer-Id and Server-Id are the empty string. Id. The Peer-Id and Server-Id are the empty string.
EAP-TLS EAP-TLS
EAP-TLS is defined in [RFC2716]. The EAP-TLS Method-Id is the EAP-TLS is defined in [RFC2716]. The EAP-TLS Session-Id is the
concatenation of the peer and server nonces. The Peer-Id and concatenation of the Expanded EAP Type Code (including the Type,
Server-Id are the contents of the altSubjectName in the peer and Vendor-Id and Vendor-Type fields defined in [RFC3748] Section 5.7)
server certificates. EAP-TLS does not negotiate a Key-Lifetime. 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-TLS does not negotiate a Key-Lifetime.
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 Method-Id is the concatentation of the Expanded EAP Type Code (including the Type,
contents of the RAND field from the AT_RAND attribute, followed by Vendor-Id and Vendor-Type fields defined in [RFC3748] Section 5.7)
the contents of the AUTN field in the AT_AUTN attribute. with the contents of the RAND field from the AT_RAND attribute,
followed by the contents of the AUTN field in the AT_AUTN
attribute.
The Peer-Id is the contents of the Identity field from the The Peer-Id is the contents of the Identity field from the
AT_IDENTITY attribute, using only the Actual Identity Length AT_IDENTITY attribute, using only the Actual Identity Length
octets from the beginning, however. Note that the contents are octets from the beginning, however. Note that the contents are
used as they are transmitted, regardless of whether the used as they are transmitted, regardless of whether the
transmitted identity was a permanent, pseudonym, or fast re- transmitted identity was a permanent, pseudonym, or fast re-
authentication identity. The Server-Id is an empty string. EAP- authentication identity. The Server-Id is an empty string. EAP-
AKA does not negotiate a key lifetime. AKA does not negotiate a key lifetime.
EAP-SIM EAP-SIM
EAP-SIM is defined in [RFC4186]. The EAP-SIM Method-Id is the EAP-SIM is defined in [RFC4186]. The EAP-SIM Session-Id is the
contents of the RAND field from the AT_RAND attribute, followed by concatentation of the Expanded EAP Type Code (including the Type,
the contents of the NONCE_MT field in the AT_NONCE_MT attribute. Vendor-Id and Vendor-Type fields defined in [RFC3748] Section 5.7)
with the contents of the RAND field from the AT_RAND attribute,
followed by the contents of the NONCE_MT field in the AT_NONCE_MT
attribute.
The Peer-Id is the contents of the Identity field from the The Peer-Id is the contents of the Identity field from the
AT_IDENTITY attribute, using only the Actual Identity Length AT_IDENTITY attribute, using only the Actual Identity Length
octets from the beginning, however. Note that the contents are octets from the beginning, however. Note that the contents are
used as they are transmitted, regardless of whether the used as they are transmitted, regardless of whether the
transmitted identity was a permanent, pseudonym, or fast re- transmitted identity was a permanent, pseudonym, or fast re-
authentication identity. The Server-Id is an empty string. EAP- authentication identity. The Server-Id is an empty string. EAP-
SIM does not negotiate a key lifetime. SIM does not negotiate a key lifetime.
Intellectual Property Statement Intellectual Property Statement
 End of changes. 73 change blocks. 
248 lines changed or deleted 337 lines changed or added

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