draft-ietf-eap-keying-13.txt   draft-ietf-eap-keying-14.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-13.txt> P. Eronen <draft-ietf-eap-keying-14.txt> P. Eronen
1 May 2006 Nokia 25 June 2006 Nokia
H. Levkowetz, Ed. H. Levkowetz
ipUnplugged 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.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
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 November 10, 2006. This Internet-Draft will expire on December 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
skipping to change at page 2, line 16 skipping to change at page 2, line 16
1. Introduction .......................................... 3 1. Introduction .......................................... 3
1.1 Requirements Language ........................... 3 1.1 Requirements Language ........................... 3
1.2 Terminology ..................................... 3 1.2 Terminology ..................................... 3
1.3 Overview ........................................ 6 1.3 Overview ........................................ 6
1.4 EAP Key Hierarchy ............................... 8 1.4 EAP Key Hierarchy ............................... 8
1.5 Security Goals .................................. 12 1.5 Security Goals .................................. 12
1.6 EAP Invariants .................................. 13 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 ...................... 19 2.2 Authenticator and Peer Architecture ............. 18
3. Key Management ........................................ 23 2.3 Server Identification ........................... 23
3.1 Secure Association Protocol ..................... 23 3. Key Management ........................................ 25
3.2 Key Scope ....................................... 26 3.1 Secure Association Protocol ..................... 25
3.3 Parent-Child Relationships ...................... 27 3.2 Key Scope ....................................... 28
3.4 Local Key Lifetimes ............................. 27 3.3 Parent-Child Relationships ...................... 29
3.5 Exported and Calculated Key Lifetimes ........... 28 3.4 Local Key Lifetimes ............................. 29
3.6 Key Cache Synchronization ....................... 29 3.5 Exported and Calculated Key Lifetimes ........... 30
3.7 Key Strength .................................... 30 3.6 Key Cache Synchronization ....................... 31
3.8 Key Wrap ........................................ 30 3.7 Key Strength .................................... 32
4. Handoff Vulnerabilities ............................... 31 3.8 Key Wrap ........................................ 33
4.1 EAP Pre-authentication .......................... 31 4. Handoff Vulnerabilities ............................... 33
4.2 Authorization ................................... 32 4.1 EAP Pre-authentication .......................... 34
4.3 Correctness ..................................... 34 4.2 Authorization ................................... 35
5. Security Considerations .............................. 37 4.3 Correctness ..................................... 36
5.1 Authenticator Compromise ........................ 38 5. Security Considerations .............................. 39
5.2 Spoofing ........................................ 39 5.1 Authenticator Compromise ........................ 40
5.3 Downgrade Attacks ............................... 39 5.2 Spoofing ........................................ 41
5.4 Unauthorized Disclosure ......................... 40 5.3 Downgrade Attacks ............................... 41
5.5 Replay Protection ............................... 42 5.4 Unauthorized Disclosure ......................... 42
5.6 Key Freshness ................................... 42 5.5 Replay Protection ............................... 44
5.7 Elevation of Privilege .......................... 43 5.6 Key Freshness ................................... 45
5.8 Man-in-the-Middle Attacks ....................... 44 5.7 Elevation of Privilege .......................... 46
5.9 Denial of Service Attacks ....................... 45 5.8 Man-in-the-Middle Attacks ....................... 47
5.10 Impersonation ................................... 45 5.9 Denial of Service Attacks ....................... 47
5.11 Channel Binding ................................. 46 5.10 Impersonation ................................... 47
6. IANA Considerations ................................... 47 5.11 Channel Binding ................................. 49
7. References ............................................ 48 6. IANA Considerations ................................... 50
7.1 Normative References ............................ 48 7. References ............................................ 50
7.2 Informative References .......................... 48 7.1 Normative References ............................ 50
Acknowledgments .............................................. 52 7.2 Informative References .......................... 50
Author's Addresses ........................................... 52 Acknowledgments .............................................. 55
Appendix A - Exported Parameters in Existing Methods ......... 54 Author's Addresses ........................................... 56
Intellectual Property Statement .............................. 55 Appendix A - Exported Parameters in Existing Methods ......... 57
Disclaimer of Validity ....................................... 56 Intellectual Property Statement .............................. 58
Copyright Statement .......................................... 56 Disclaimer of Validity ....................................... 59
Copyright Statement .......................................... 59
1. Introduction 1. Introduction
The Extensible Authentication Protocol (EAP), defined in [RFC3748], The Extensible Authentication Protocol (EAP), defined in [RFC3748],
was designed to enable extensible authentication for network access was designed to enable extensible authentication for network access
in situations in which the Internet Protocol (IP) protocol is not in situations in which the Internet Protocol (IP) protocol is not
available. Originally developed for use with Point-to-Point Protocol available. Originally developed for use with Point-to-Point Protocol
(PPP) [RFC1661], it has subsequently also been applied to IEEE 802 (PPP) [RFC1661], it has subsequently also been applied to IEEE 802
wired networks [IEEE-802.1X], wireless networks such as wired networks [IEEE-802.1X], wireless networks such as
[IEEE-802.11i] d [IEEE-802.16e], and IKEv2 [RFC4306]. [IEEE-802.11i] d [IEEE-802.16e], and IKEv2 [RFC4306].
skipping to change at page 4, line 12 skipping to change at page 4, line 12
peer The end of the link that responds to the authenticator. peer The end of the link that responds to the authenticator.
backend authentication server backend authentication server
A backend authentication server is an entity that provides an A backend authentication server is an entity that provides an
authentication service to an authenticator. When used, this server authentication service to an authenticator. When used, this server
typically executes EAP methods for the authenticator. This typically executes EAP methods for the authenticator. This
terminology is also used in [IEEE-802.1X]. terminology is also used in [IEEE-802.1X].
Channel Binding Channel Binding
The communication within an EAP method of integrity-protected A secure mechanism for ensuring that a subset of the parameters
channel properties such as endpoint identifiers which can be transmitted by the authenticator (such as authenticator identifiers
compared to values communicated via out of band mechanisms (such as and properties) are agreed upon by the EAP peer and server. It is
via a AAA or lower layer protocol). expected that the parameters are also securely agreed upon by the
EAP peer and authenticator via the lower layer if the authenticator
advertised the parameters.
EAP server EAP server
The entity that terminates the EAP authentication method with the The entity that terminates the EAP authentication method with the
peer. In the case where no backend authentication server is used, peer. In the case where no backend authentication server is used,
the EAP server is part of the authenticator. In the case where the the EAP server is part of the authenticator. In the case where the
authenticator operates in pass-through mode, the EAP server is authenticator operates in pass-through mode, the EAP server is
located on the backend authentication server. located on the backend authentication server.
Lower Layer Lower Layer
The lower layer is responsible for carrying EAP frames between the The lower layer is responsible for carrying EAP frames between the
skipping to change at page 4, line 42 skipping to change at page 4, line 44
credential is the pre-shared key. In the case of a public-key credential is the pre-shared key. In the case of a public-key
based method, the long term credential is the corresponding private based method, the long term credential is the corresponding private
key. key.
Master Session Key (MSK) Master Session Key (MSK)
Keying material that is derived between the EAP peer and server and Keying material that is derived between the EAP peer and server and
exported by the EAP method. The MSK is at least 64 octets in exported by the EAP method. The MSK is at least 64 octets in
length. length.
AAA-Key AAA-Key
The term AAA-Key is synonymous with MSK. The term AAA-Key is synonymous with MSK. Since multiple keys may
be transported by AAA, the term is potentially confusing and is not
used in this document.
Extended Master Session Key (EMSK) Extended Master Session Key (EMSK)
Additional keying material derived between the peer and server that Additional keying material derived between the peer and server that
is exported by the EAP method. The EMSK is at least 64 octets in is exported by the EAP method. The EMSK is at least 64 octets in
length, and is never shared with a third party. length, and is never shared with a third party.
Initialization Vector (IV) Initialization Vector (IV)
A quantity of at least 64 octets, suitable for use in an A quantity of at least 64 octets, suitable for use in an
initialization vector field, that is derived between the peer and initialization vector field, that is derived between the peer and
EAP server. Since the IV is a known value in methods such as EAP- EAP server. Since the IV is a known value in methods such as EAP-
TLS [RFC2716], it cannot be used by itself for computation of any TLS [RFC2716], it cannot be used by itself for computation of any
quantity that needs to remain secret. As a result, its use has quantity that needs to remain secret. As a result, its use has
been deprecated and EAP methods are not required to generate it. been deprecated and EAP methods are not required to generate it.
However, when it is generated it MUST be unpredictable. However, when it is generated it MUST be unpredictable.
Network Access Server (NAS)
A device that provides an access service for a user to a network.
Pairwise Master Key (PMK) Pairwise Master Key (PMK)
Lower layers use the MSK in lower-layer dependent manner. For Lower layers use the MSK in lower-layer dependent manner. For
instance, in [IEEE-802.11i] Octets 0-31 of the MSK are known as the instance, in [IEEE-802.11i] Octets 0-31 of the MSK are known as the
Pairwise Master Key (PMK). In [IEEE-802.11i] the TKIP and AES CCMP Pairwise Master Key (PMK). In [IEEE-802.11i] the TKIP and AES CCMP
ciphersuites derive their Transient Session Keys (TSKs) solely from ciphersuites derive their Transient Session Keys (TSKs) solely from
the PMK, whereas the WEP ciphersuite as noted in [RFC3580], derives the PMK, whereas the WEP ciphersuite as noted in [RFC3580], derives
its TSKs from both halves of the MSK. In [802.16e], the MSK is its TSKs from both halves of the MSK. In [802.16e], the MSK is
truncated to 20 octets for PMK and 20 octets for PMK2. truncated to 20 octets for PMK and 20 octets for PMK2.
security association security association
skipping to change at page 5, line 32 skipping to change at page 5, line 40
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 Session-Id
The EAP Session-Id uniquely identifies an EAP session between an The EAP Session-Id uniquely identifies an EAP session between an
EAP peer (as identified by the Peer-Id) and server (as identified EAP peer (as identified by the Peer-Id) and server (as identified
by the Server-Id). The EAP Session-Id consists of the by the Server-Id). For more information, see Section 1.4.
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
skipping to change at page 7, line 43 skipping to change at page 7, line 43
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
Figure 1. Figure 1.
1.3.1. Examples 1.3.1. Examples
Existing EAP lower layers implement phase 0, 2a and 2b in different Existing EAP lower layers implement phase 0, 2a and 2b in different
ways: ways:
PPP PPP, defined in [RFC1661] does not support discovery, nor does it PPP Point-to-Point Protocol (PPP), defined in [RFC1661] does not
include a Secure Association Protocol. support discovery, nor does it include a Secure Association
Protocol.
PPPoE PPPoE
PPPoE, defined in [RFC2516], includes support for a Discovery stage PPP over Ethernet (PPPoE), defined in [RFC2516], includes support
(phase 0). In this step, the EAP peer sends a PPPoE Active for a Discovery stage (phase 0). In this step, the EAP peer sends
Discovery Initiation (PADI) packet to the broadcast address, a PPPoE Active Discovery Initiation (PADI) packet to the broadcast
indicating the service it is requesting. The Access Concentrator address, indicating the service it is requesting. The Access
replies with a PPPoE Active Discovery Offer (PADO) packet Concentrator replies with a PPPoE Active Discovery Offer (PADO)
containing its name, the service name and an indication of the packet containing its name, the service name and an indication of
services offered by the concentrator. The discovery phase is not the services offered by the concentrator. The discovery phase is
secured. PPPoE, like PPP, does not include a Secure Association not secured. PPPoE, like PPP, does not include a Secure
Protocol. Association Protocol.
IKEv2 IKEv2
IKEv2, defined in [RFC4306], includes support for EAP and handles IKEv2, defined in [RFC4306], includes support for EAP and handles
the establishment of unicast security associations (phase 2a). the establishment of unicast security associations (phase 2a).
However, the establishment of multicast security associations However, the establishment of multicast security associations
(phase 2b) typically does not involve EAP and needs to be handled (phase 2b) typically does not involve EAP and needs to be handled
by a group key management protocol such as GDOI [RFC3547], GSAKMP by a group key management protocol such as GDOI [RFC3547], GSAKMP
[GSAKMP], MIKEY [RFC3830], or GKDP [GKDP]. Several mechanisms have [GSAKMP], MIKEY [RFC3830], or GKDP [GKDP]. Several mechanisms have
been proposed for discovery of IPsec security gateways. [RFC2230] been proposed for discovery of IPsec security gateways. [RFC2230]
discusses the use of KX Resource Records (RRs) for IPsec gateway discusses the use of KX Resource Records (RRs) for IPsec gateway
skipping to change at page 9, line 29 skipping to change at page 9, line 30
validate the certificates. The EAP server may also store additional validate the certificates. The EAP server may also store additional
information associated with the peer's identity and the peer stores information associated with the peer's identity and the peer stores
information necessary to choose which certificate to use for which information necessary to choose which certificate to use for which
service. 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 the server, EAP methods
Based on the long term credential established between the peer and derive two types of keys:
the server, EAP methods derive two types of keys:
[a] 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.
[b] 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.
The EMSK MUST NOT be provided to an entity outside the EAP server or
peer, nor is it permitted to pass any quantity to an entity outside
the EAP server or peer from which the EMSK could be computed without
breaking some cryptographic assumption, such as inverting a one-way
function.
EAP methods also MAY export method-specific peer and server EAP methods also MAY export method-specific peer and server
identifiers (Peer-Id and Server-Id), a method-specific EAP identifiers (Peer-Id and Server-Id) and a method-specific EAP
conversation identifier known as the Session-Id, and the lifetime of conversation identifier known as the Session-Id. EAP methods MAY
the exported keys, known as the Key-Lifetime. EAP methods MAY also also support the import and export of Channel Bindings. New EAP
support the import and export of Channel Bindings. New EAP method method specifications MUST define the Peer-Id, Server-Id and Session-
specifications MUST define the Peer-Id, Server-Id and Session-Id. Id. The combination of the Peer-Id and Server-Id uniquely specifies
The combination of the Peer-Id and Server-Id uniquely specifies the the endpoints of the EAP method exchange when they are provided. The
endpoints of the EAP method exchange when they are provided. The
Peer-Id, Server-Id, and Session-Id for existing EAP methods is Peer-Id, Server-Id, and Session-Id for existing EAP methods is
defined in Appendix A. defined in Appendix A.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | ^
| EAP Method | |
| | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | |
| | | | | | |
| | EAP Method Key |<->| Long-Term | | |
| | Derivation | | Credential | | |
| | | | | | |
| | | +-+-+-+-+-+-+-+ | Local to |
| | | | EAP |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Method |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | |
| | | TEK | |MSK, EMSK | |IV | | |
| | |Derivation | |Derivation | |Derivation | | |
| | | | | | |(Deprecated) | | |
| | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | |
| | ^ | | | |
| | | | | | V
+-+-|-+-+-+-+-+-+-+-+-|-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+ ---+
| | | | ^
| Peer-Id, | | | Exported |
| Server-Id, | Channel | MSK (64+B) | IV (64B) by |
| Session-Id, | Bindings | EMSK (64+B) | (Optional) EAP |
| Key-Lifetime | & Result | | Method |
V V V V V
Figure 2: EAP Method Parameter Import/Export
Peer-Id Peer-Id
As described in [RFC3748] Section 7.3, the identity provided in As described in [RFC3748] Section 7.3, the identity provided in
the 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 authenticated by the EAP method. Where the EAP method
authenticates the peer identity, that identity is exported by the authenticates the peer identity, that identity is exported by the
method as the Peer-Id. A suitable EAP peer name may not always be method as the Peer-Id. A suitable EAP peer name may not always be
available. Where an EAP method does not define a method-specific available. Where an EAP method does not define a method-specific
peer identity, the Peer-Id is the null string. peer identity, the Peer-Id is the null string.
Server-Id Server-Id
Where the EAP method authenticates the server identity, that Where the EAP method authenticates the server identity, that
identity is exported by the method as the Server-Id. A suitable identity is exported by the method as the Server-Id. A suitable
EAP server name may not always be available. Where an EAP method EAP server name may not always be available. Where an EAP method
does not define a method-specific peer identity, the Server-Id is does not define a method-specific server identity, the Server-Id
the null string. is the null string.
Session-Id Session-Id
The Session-Id uniquely identifies an EAP session between an EAP The Session-Id uniquely identifies an EAP session between an EAP
peer (as identified by the Peer-Id) and server (as identified by peer (as identified by the Peer-Id) and server (as identified by
the Server-Id). The EAP Session-Id consists of the concatenation the Server-Id). Where the EAP Type Code is less than 255, the EAP
of the Expanded EAP Type Code (including the Type, Vendor-Id and Session-Id consists of the concatenation of the EAP Type Code and
Vendor-Type fields defined in [RFC3748] Section 5.7) and a a temporally unique identifier obtained from the method. Where
expanded EAP Type Codes are used, the EAP Session-Id consists of
the Expanded Type Code (including the Type, Vendor-Id and Vendor-
Type fields defined in [RFC3748] Section 5.7) concatenated with a
temporally unique identifier obtained from the method. This temporally unique identifier obtained from the method. This
unique identifier is ty pically constructed from nonces or unique identifier is ty pically constructed from nonces or
counters used within the EAP method exchange. The inclusion of counters used within the EAP method exchange. The inclusion of
the Expanded Type Code in the EAP Session-Id ensures that each EAP the Type Code in the EAP Session-Id ensures that each EAP method
method has a distinct Session-Id space. Since an EAP session is has a distinct Session-Id space. Since an EAP session is not
not bound to a particular authenticator or specific ports on the bound to a particular authenticator or specific ports on the peer
peer and authenticator, the authenticator port or identity are not and authenticator, the authenticator port or identity are not
included in the Session-Id. included in the Session-Id.
Key-Lifetime
While EAP itself does not support key lifetime negotiation, it is
possible to specify methods that do. However, systems that rely
on such negotiation for exported keys would only function with
these methods. As a result, it is NOT RECOMMENDED to use this
approach as the sole way to determine key lifetimes.
Channel Bindings Channel Bindings
Channel Bindings include lower layer parameters that are verified Channel Bindings include lower layer parameters that are verified
for consistency between the EAP peer and server. In order to for consistency between the EAP peer and server. In order to
avoid introducing media dependencies, EAP methods that transport avoid introducing media dependencies, EAP methods that transport
Channel Binding data MUST treat this data as opaque octets. Channel Binding data MUST treat this data as opaque octets. See
Section 5.11 for further discussion.
Typically the EAP method imports Channel Bindings from the lower +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
layer on the peer, and transmits them securely to the EAP server, | | ^
which exports them to the lower layer or AAA layer. However, | EAP Method | |
transport may occur from EAP server to peer, or may be bi- | | |
directional. On the side of the exchange (peer or server) where | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | |
Channel Bindings are verified, the lower layer or AAA layer passes | | | | | | |
the result of the verification (TRUE or FALSE) up to the EAP | | EAP Method Key |<->| Long-Term | | |
method. | | Derivation | | Credential | | |
| | | | | | |
| | | +-+-+-+-+-+-+-+ | Local to |
| | | | EAP |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Method |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | |
| | | TEK | |MSK, EMSK | |IV | | |
| | |Derivation | |Derivation | |Derivation | | |
| | | | | | |(Deprecated) | | |
| | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | |
| | ^ | | | |
| | | | | | V
+-+-|-+-+-+-+-+-+-+-+-|-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+ ---+
| | | | ^
| Peer-Id, | | | Exported |
| Server-Id, | Channel | MSK (64+B) | IV (64B) by |
| Session-Id | Bindings | EMSK (64+B) | (Optional) EAP |
| | & Result | | Method |
V V V V V
While the verification can be done either by the peer or the Figure 2: EAP Method Parameter Import/Export
server, typically only the server has the knowledge to determine
the correctness of the values, as opposed to merely verifying
their equality. See Section 5.11 for further discussion.
1.4.1. Key Naming 1.4.1. Key Naming
Each key created within the EAP key management framework has a name Each key created within the EAP key management framework has a name
(a unique identifier), as well as a scope (the parties to whom the (a unique identifier), as well as a scope (the parties to whom the
key is available). The scope of exported parameters is defined by key is available). The scope of exported parameters is defined by
the EAP peer name (if securely exchanged within the method) and the the EAP Peer-Id (if securely exchanged within the method) and the EAP
EAP server name (also only if securely exchanged). Where a peer or Server-Id (also only if securely exchanged). Where a peer or server
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 key from which it is derived.
skipping to change at page 16, line 40 skipping to change at page 16, line 29
them. For example, since ECP negotiation occurs after them. For example, since ECP negotiation occurs after
authentication, when run over PPP, the EAP peer and server may not authentication, when run over PPP, the EAP peer and server may not
anticipate the negotiated ciphersuite and therefore this anticipate the negotiated ciphersuite and therefore this
information cannot be provided to the EAP method. information cannot be provided to the EAP method.
2. Lower Layer Operation 2. Lower Layer Operation
On completion of EAP authentication, keying material and material and On completion of EAP authentication, keying material and material and
parameters exported by the EAP method are provided to the lower layer parameters exported by the EAP method are provided to the lower layer
and AAA layer (if present). These include the Master Session Key and AAA layer (if present). These include the Master Session Key
(MSK), Extended Master Session Key (EMSK), Peer-Id, Server-Id, (MSK), Extended Master Session Key (EMSK), Peer-Id, Server-Id and
Session-Id and Key-Lifetime. The Initialization Vector (IV) is Session-Id. The Initialization Vector (IV) is deprecated.
deprecated.
In order to preserve the security of keys derived within EAP methods, In order to preserve the security of keys derived within EAP methods,
lower layers MUST NOT export keys passed down by EAP methods. This lower layers MUST NOT export keys passed down by EAP methods. This
implies that EAP keying material or parameters passed down to a lower implies that EAP keying material passed down to a lower layer is for
layer are for the exclusive use of that lower layer and MUST NOT be the exclusive use of that lower layer and MUST NOT be used within
used within another lower layer. This prevents compromise of one another lower layer. This prevents compromise of one lower layer
lower layer from compromising other applications using EAP keying from compromising other applications using EAP keying parameters.
parameters.
EAP keying material and parameters provided to a lower layer MUST NOT
be transported to another entity. For example, EAP keying material
and parameters passed down to the EAP peer lower layer MUST NOT leave
the peer; EAP keying material and parameters passed down or
transported to the EAP authenticator lower layer MUST NOT leave the
authenticator.
On the EAP server, keying material requested by and passed down to
the AAA layer may be replicated to the AAA layer on the
authenticator. On the authenticator, the AAA layer provides the
replicated keying material to the lower layer over which the EAP
authentication conversation took place. This enables "mode
independence" to be maintained.
The EMSK MUST NOT be provided to an entity outside the EAP server or EAP keying material provided to a lower layer MUST NOT be transported
peer, nor is it permitted to pass any quantity to an entity outside to another entity. For example, EAP keying material passed down to
the EAP server or peer from which the EMSK could be computed without the EAP peer lower layer MUST NOT leave the peer; EAP keying
breaking some cryptographic assumption, such as inverting a one-way material passed down or transported to the EAP authenticator lower
function. The EMSK MUST NOT be transported by the AAA layer. As layer MUST NOT leave the authenticator.
noted in [RFC3748] Section 7.10:
The EMSK is reserved for future use and MUST remain on the EAP On the EAP server, keying material and parameters requested by and
peer and EAP server where it is derived; it MUST NOT be passed down to the AAA layer may be replicated to the AAA layer on
transported to, or shared with, additional parties, or used to the authenticator (with the exception of the EMSK). On the
derive any other keys. authenticator, the AAA layer provides the replicated keying material
and parameters to the lower layer over which the EAP authentication
conversation took place. This enables "mode independence" to be
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
the exported EAP keying material and parameters and/or TSKs. The the exported EAP keying material and parameters and/or TSKs. The
skipping to change at page 18, line 13 skipping to change at page 17, line 36
completes, it is assumed that EAP keying material and parameters completes, it is assumed that EAP keying material and parameters
are discarded. are discarded.
PPP PPP, defined in [RFC1661] does not support caching of EAP keying PPP PPP, defined in [RFC1661] does not support caching of EAP keying
material or parameters. PPP ciphersuites derive their TSKs material or parameters. PPP ciphersuites derive their TSKs
directly from the MSK, as described in [RFC2716]. This method is directly from the MSK, as described in [RFC2716]. This method is
NOT RECOMMENDED, since if PPP were to support caching, this could NOT RECOMMENDED, since if PPP were to support caching, this could
result in TSK reuse. As a result, once the PPP session is result in TSK reuse. As a result, once the PPP session is
terminated, EAP keying material and parameters MUST be discarded. terminated, EAP keying material and parameters MUST be discarded.
Since caching of EAP keying material is not permitted, within PPP Since caching of EAP keying material is not permitted, within PPP
there is no way to handle TSK rekey without EAP re-authentication. there is no way to handle TSK re-key without EAP re-authentication.
Perfect Forward Secrecy (PFS) is only possible if the negotiated Perfect Forward Secrecy (PFS) is only possible if the negotiated
EAP method supports this. EAP method supports this.
IKEv2 IKEv2
IKEv2, defined in [RFC4306] only uses the MSK for authentication IKEv2, defined in [RFC4306] only uses the MSK for authentication
purposes and not key derivation. The EMSK, IV, Peer-Id, Server-Id purposes and not key derivation. The EMSK, IV, Peer-Id, Server-Id
or Session-Id are not used. As a result, the keying material or Session-Id are not used. As a result, the keying material
derived within IKEv2 is independent of the EAP keying material and derived within IKEv2 is independent of the EAP keying material and
rekey of IPsec SAs can be handled without requiring EAP re- 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 does not cache EAP keying the EAP method that is used. IKEv2 as specified in [RFC4306] does
material or parameters; once IKEv2 authentication completes it is not cache EAP keying material or parameters; once IKEv2
assumed that EAP keying material and parameters are discarded. The authentication completes it is assumed that EAP keying material and
Session-Timeout attribute is therefore interpreted as a limit on parameters are discarded. The Session-Timeout attribute is
the VPN session time, rather than an indication of the MSK key therefore interpreted as a limit on the VPN session time, rather
lifetime. than an indication of the MSK key lifetime.
IEEE 802.11i IEEE 802.11i
IEEE 802.11i enables caching of the MSK, but not the EMSK, IV, IEEE 802.11i enables caching of the MSK, but not the EMSK, IV,
Peer-Id, Server-Id, or Session-Id. More details about the Peer-Id, Server-Id, or Session-Id. More details about the
structure of the cache are available in [IEEE-802.11i]. In IEEE structure of the cache are available in [IEEE-802.11i]. In IEEE
802.11i, TSKs are derived from the MSK using the 4-way handshake, 802.11i, TSKs are derived from the MSK using the 4-way handshake,
which includes a nonce exchange. This guarantees TSK freshness which includes a nonce exchange. This guarantees TSK freshness
even if the MSK is reused. The 4-way handshake also enables TSK even if the MSK is reused. The 4-way handshake also enables TSK
rekey without EAP re-authentication. PFS is only possible within re-key without EAP re-authentication. PFS is only possible within
IEEE 802.11i if caching is not enabled and the negotiated EAP IEEE 802.11i if caching is not enabled and the negotiated EAP
method supports PFS. method supports PFS.
IEEE 802.16e IEEE 802.16e
IEEE 802.16e, defined in [IEEE-802.16e] supports caching of the IEEE 802.16e, defined in [IEEE-802.16e] supports caching of the
MSK, but not the EMSK, IV, Peer-Id, Server-Id or Session-Id. In MSK, but not the EMSK, IV, Peer-Id, Server-Id or Session-Id. In
IEEE 802.16e, TSKs are generated by the authenticator without any IEEE 802.16e, TSKs are generated by the authenticator without any
contribution by the peer. The TSKs are encrypted, authenticated contribution by the peer. The TSKs are encrypted, authenticated
and integrity protected using the MSK. As a result, TSK rekey is and integrity protected using the MSK. As a result, TSK re-key is
possible without EAP re-authentication. PFS is not possible even possible without EAP re-authentication. PFS is not possible even
if the negotiated EAP method supports it. if the negotiated EAP method supports it.
AAA Existing implementations of RADIUS/EAP [RFC3579] or Diameter EAP AAA Existing implementations of RADIUS/EAP [RFC3579] or Diameter EAP
[RFC4072] do not support caching of EAP keying material or [RFC4072] do not support caching of EAP keying material or
parameters. In existing AAA client, proxy and server parameters. In existing AAA client, proxy and server
implementations, exported EAP keying material (MSK, EMSK and IV) as implementations, exported EAP keying material (MSK, EMSK and IV) as
well as parameters and derived keys are not cached and MUST be well as parameters and derived keys are not cached and MUST be
presumed lost after the AAA exchange completes. presumed lost after the AAA exchange completes.
In order to avoid key reuse, the AAA layer MUST delete transported In order to avoid key reuse, the AAA layer MUST delete transported
keys once they are sent. The AAA layer MUST NOT retain keys that keys once they are sent. The AAA layer MUST NOT retain keys that
it has previously sent. For example, a AAA layer that has it has previously sent. For example, a AAA layer that has
transported the MSK MUST delete it, and keys MUST NOT be derived transported the MSK MUST delete it, and keys MUST NOT be derived
from the MSK from that point forward. from the MSK from that point forward.
2.2. Authenticator Architecture 2.2. Authenticator 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 the EAP authenticator or peer. Any of the authenticator architectures
architectures described in [RFC4118] can be used. As a result, lower described in [RFC4118] can be used. As a result, lower layers need to
layers need to identify EAP peers and authenticators unambiguously, identify EAP peers and authenticators unambiguously, without
without incorporating implicit assumptions about peer and incorporating implicit assumptions about peer and authenticator
authenticator architectures. 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 19, line 48 skipping to change at page 19, line 21
[c] may utilize multiple CPUs; [c] may utilize multiple CPUs;
[d] may support clustering services for load balancing or failover. [d] may support clustering services for load balancing or failover.
Both the EAP peer and authenticator may have more than one physical Both the EAP peer and authenticator may have more than one physical
or logical port. A peer may simultaneously access the network via or logical port. A peer may simultaneously access the network via
multiple authenticators, or via multiple physical or logical ports on multiple authenticators, or via multiple physical or logical ports on
a given authenticator. Similarly, an authenticator may offer network a given authenticator. Similarly, an authenticator may offer network
access to multiple peers, each via a separate physical or logical access to multiple peers, each via a separate physical or logical
port. When a single physical authenticator advertises itself as port. When a single physical authenticator advertises itself as
multiple "virtual authenticators", it is possible for a single multiple "virtual authenticators", it is possible for a single
physical port to belong to multiple "virtual authenticators". The physical port to belong to multiple "virtual authenticators".
situation is illustrated in Figure 3.
An authenticator may be configured to communicate with more than one
EAP server, each of which is configured to communicate with a subset
of the authenticators. The situation is illustrated in Figure 3.
2.2.1. Authenticator and Peer Identification
The EAP method conversation is between the EAP peer and server. The
authenticator identity, if considered at all by the EAP method, is
treated as an opaque blob for the purposes of Channel Bindings (see
Section 5.12). However, the authenticator identity is important in
two other exchanges - the AAA protocol exchange and the Secure
Association Protocol conversation.
The AAA conversation is between the EAP authenticator and the backend
authentication server. From the point of view of the backend
authentication server, EAP keying material and parameters are
transported to the EAP authenticator identified by the NAS-Identifier
attribute. Since an EAP authenticator MUST NOT share EAP keying
material or parameters with another party, if the EAP peer or backend
authentication server detects use of EAP keying material and
parameters outside the scope defined by the NAS-Identifier, the
keying material MUST be considered compromised.
The Secure Association Protocol conversation is between the peer and
the authenticator. For lower layers which support key caching it is
particularly important for the EAP peer, authenticator and backend
server to have a consistent view of the usage scope of the
transported EAP keying material. In order to enable this, it is
RECOMMENDED that the Secure Association Protocol explicitly
communicate the usage scope of the EAP keying material passed down to
the lower layer, rather than implicitly assuming that this is defined
by the authenticator and peer endpoint addresses.
+-+-+-+-+ +-+-+-+-+
| EAP | | EAP |
| Peer | | Peer |
+-+-+-+-+ +-+-+-+-+
| | | Peer Ports | | | Peer Ports
/ | \ / | \
/ | \ / | \
/ | \ / | \
/ | \ / | \
/ | \ / | \
/ | \ / | \
/ | \ / | \
/ | \ / | \ Authenticator
| | | | | | | | | Authenticator Ports | | | | | | | | | Ports
+-+-+-+-+ +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ +-+-+-+-+
| | | | | | | | | | | |
| Auth. | | Auth. | | Auth. | | Auth1 | | Auth2 | | Auth3 |
| | | | | | | | | | | |
+-+-+-+-+ +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ +-+-+-+-+
\ | / \ | \ |
\ | / \ | \ |
\ | / \ | \ |
EAP over AAA \ | / EAP over AAA \ | \ |
(optional) \ | / (optional) \ | \ |
\ | / \ | \ |
\ | / \ | \ |
\ | / \ | \ |
+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ Backend
| EAP | | EAP | | EAP | Authentication
|Server | | Server1 | | Server2 | Servers
+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
Figure 3: Relationship between EAP peer, authenticator and server Figure 3: Relationship between EAP peer, authenticator and server
2.2.1. Authenticator Identification Since an authenticator may have multiple ports, the scope of the
authenticator key cache may not be described by a single endpoint
The EAP method conversation is between the EAP peer and server, as address. Similarly, where a peer may have multiple ports and sharing
identified by the Peer-Id and Server-Id. The authenticator identity, of EAP keying material and parameters between peer ports of the same
if considered at all by the EAP method, is treated as an opaque blob link type is allowed, the extent of the peer key cache cannot be
for the purposes of Channel Bindings (see Section 5.12). However, communicated by using a single endpoint address. Instead, it is
the Secure Association Protocol conversation is between the peer and RECOMMENDED that the EAP peer and authenticator consistently identify
the authenticator, and therefore the authenticator and peer themselves utilizing explicit identifiers, rather than endpoint
identities are relevant to that exchange, and define the scope of use addresses or port identifiers.
of the EAP keying material passed down to the lower layer.
Where the EAP peer and authenticator cannot unambiguously identify AAA protocols such as RADIUS [RFC3579] and Diameter [RFC4072] provide
each other they may not be able to determine the scope of transported a mechanism for the identification of AAA clients; since the EAP
EAP keying material. This is particularly problematic for lower authenticator and AAA client are always co-resident, this mechanism
layers where key caching is supported. is applicable to the identification of EAP authenticators.
For example, if the EAP peer cannot identify the EAP authenticator, RADIUS [RFC2865] requires that an Access-Request packet contain one
it will be unable to determine whether transported EAP keying or more of the NAS-Identifier, NAS-IP-Address and NAS-IPv6-Address
material has been shared outside of its authorized scope, and attributes. Since a NAS may have more than one IP address, the NAS-
therefore needs to be considered compromised. There is also a Identifier attribute is RECOMMENDED for explicit identification of
practical problem because the EAP peer will be unable to utilize the the authenticator, both within the AAA protocol exchange and the
EAP authenticator key cache in an efficient way. Secure Association Protocol conversation.
Where the peer and authenticator identify themselves within the lower Problems which may arise where the peer and authenticator implicitly
layer using a port identifier such as a link layer address, this identify themselves using endpoint addresses include the following:
creates a number of problems:
[a] It may not be obvious to the peer which authenticator ports are [a] It may not be obvious to the peer which authenticator ports are
associated with which authenticators. associated with which authenticators. The EAP peer will be unable
to determine whether EAP keying material has been shared outside
its authorized scope, and needs to be considered compromised. The
EAP peer may also be unable to utilize the authenticator key cache
in an efficient way.
[b] 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. As a result, the authenticator may
not be able to enable a peer to communicate with it utilizing
multiple peer ports.
[c] 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. For example, multiple "virtual
authenticators" may share a MAC address, but utilize different NAS-
Identifiers.
[d] 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. Multiple "virtual peers" may share a MAC
address, but utilize different Peer-Ids.
Since an authenticator may have multiple ports, the authenticator
identifier used within the Secure Association Protocol exchange
SHOULD be distinct from any port identifier (e.g. MAC address).
Similarly, where a peer may have multiple ports, and sharing of EAP
keying material and parameters between peer ports of the same link
type is allowed, the peer identifier used within the Secure
Association Protocol exchange SHOULD also be distinct from any port
identifier.
AAA protocols such as RADIUS [RFC3579] and Diameter [RFC4072]
provide a mechanism for the identification of AAA clients; since
the EAP authenticator and AAA client are always co-resident, this
mechanism is applicable to the identification of EAP
authenticators.
RADIUS [RFC2865] requires that an Access-Request packet contain one [e] It may not be possible for the EAP peer and server to verify the
or more of the NAS-Identifier, NAS-IP-Address and NAS-IPv6-Address authenticator identity via channel bindings.
attributes. Since a NAS may have more than one IP address, the
NAS-Identifier attribute is RECOMMENDED for the unambiguous
identification of the EAP authenticator.
From the point of view of the backend authentication server, EAP For example, problems [a], [c] and [e] occur in [IEEE-802.11i], which
keying material and parameters are transported to the EAP utilizes peer and authenticator MAC addresses within the 4-way
authenticator identified by the NAS-Identifier attribute. Since an handshake. Problems [b] and [d] do not occur since [IEEE-802.11i]
EAP authenticator MUST NOT share EAP keying material or parameters only allows a peer to utilize a single port.
with another party, if the EAP peer or backend authentication
server detects use of EAP keying material and parameters outside
the scope defined by the NAS-Identifier, the keying material MUST
be considered compromised.
In order to ensure that lower layer identities are securely The following steps enable lower layer identities to be securely
verified by all parties, it is RECOMMENDED that the parties use a verified by all parties:
set of identities that are consistent between the conversation
phases. This can be achieved by:
[a] Specifying the lower layer parameters used to identify the [f] Specifying the lower layer parameters used to identify the
authenticator and peer; authenticator and peer. As noted earlier, endpoint or port
identifiers are not recommended for identification of the
authenticator or peer when it is possible for them to have multiple
ports.
[b] Communicating the lower layer identities between the peer and [g] Communicating the lower layer identities between the peer and
authenticator within phase 0; authenticator within phase 0. This allows the peer and
authenticator to determine the key scope if a key cache is
utilized.
[c] Communicating the lower layer authenticator identity between the [h] Communicating the lower layer authenticator identity between the
authenticator and backend server within the NAS-Identifier authenticator and backend server within the NAS-Identifier
attribute; attribute.
[d] Including the lower layer identities within Channel Bindings (if [i] Including the lower layer identities within Channel Bindings (if
supported) in phase 1a, ensuring that they are communicated between supported) in phase 1a, ensuring that they are communicated between
the EAP peer and server; the EAP peer and server.
[e] Supporting the integrity-protected exchange of identities within [j] Supporting the integrity-protected exchange of identities within
phase 2a; phase 2a.
[f] Utilizing the advertised lower layer identities to enable the peer [k] 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", if the virtual authenticators do not
arise. For example, the peer may assume that the "virtual maintain logically separate key caches, then by authenticating to
authenticators" are distinct and do not share a key cache, whereas, one virtual authenticator, the peer can gain access to the other
depending on the architecture of the physical authenticator, a shared virtual authenticators sharing a key cache.
key cache may or may not be implemented.
Where EAP keying material is shared between "virtual authenticators" For example, where a physical authenticator implements "Guest" and
an attacker acting as a peer could authenticate with the "Guest" "Corporate Intranet" virtual authenticators, an attacker acting as a
"virtual authenticator" and derive EAP keying material. If the peer could authenticate with the "Guest" "virtual authenticator" and
derive EAP keying material. If the "Guest" and "Corporate Intranet"
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" network.
In order to address these issues: In order to address this vulnerability:
[g] Authenticators are REQUIRED to cache associated authorizations [a] Authenticators are REQUIRED to cache associated authorizations
along with EAP keying material and parameters and to apply along with EAP keying material and parameters and to apply
authorizations consistently. This ensures that an attacker cannot authorizations consistently. This ensures that an attacker cannot
obtain elevated privileges even where the key cache is shared obtain elevated privileges even where the key cache is shared
between "virtual authenticators". between "virtual authenticators".
[h] It is RECOMMENDED that physical authenticators maintain separate [b] 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 [c] It is RECOMMENDED that each "virtual authenticator" identify itself
distinctly to the backend authentication server, such as by consistently to the peer and to the backend authentication server,
utilizing a distinct NAS-Identifier attribute. This enables the so as to enable the peer to verify the authenticator identity via
backend authentication server to utilize a separate credential to Channel Bindings (see Section 5.11).
authenticate each "virtual authenticator", and for the peer and
backend authentication server to verify the authenticator identity [d] It is RECOMMENDED that each "virtual authenticator" identify itself
via Channel Bindings (see Section 5.11). distinctly, in order to enable the peer and backend server to tell
them apart. For example, this can be accomplished by utilizing a
distinct NAS-Identifier attribute or BSSID.
2.3. Server Identification
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
authenticator may be configured to communicate with multiple EAP
servers; the EAP server that an authenticator communicates with may
vary according to configuration and network and server availability.
While the EAP peer can assume that all EAP servers within a realm
have access to the credentials necessary to validate an
authentication attempt, it cannot assume that all EAP servers share
persistent state.
Authenticators may be configured with different primary or secondary
EAP servers, in order to balance the load. Also, the authenticator
can dynamically determine the EAP server to which requests will be
sent; in event of a communication failure, the authenticator may fail
over to another EAP server. For example, in Figure 3, Authenticator2
may be initially configured with EAP server1 as its primary backend
authentication server, and EAP server2 as the backup, but if EAP
server1 becomes unavailable, EAP server2 may become the primary
server.
In general, the EAP peer cannot direct an authentication attempt to a
particular EAP server within a realm; this decision is made solely by
the authenticator. Nor can it determine which EAP server it will be
communicating with, prior to the start of the EAP method
conversation. The Server-Id is not included in the EAP-
Request/Identity, and since the authenticator determines the EAP
server dynamically, it typically is not possible for the
authenticator to advertise the Server-Id during the discovery phase.
EAP methods may or may not export the Server-Id, and as a result, the
EAP peer may not even learn which server it was conversing with after
the EAP conversation completes successfully.
As a result, an EAP peer, on connecting to a new authenticator or
reconnecting to the same authenticator, may find itself communicating
with a different EAP server. Fast reconnect, defined in [RFC3748]
Section 7.2, may fail if the EAP server that the peer communicates
with is not the same one with which it initially established a
security association. For example, an EAP peer attempting an EAP-TLS
session resume may find that the new EAP-TLS server will not have
access to the TLS Master Key identified by the TLS Session-Id, and
therefore the session resumption attempt will fail, requiring
completion of a full EAP-TLS exchange.
EAP methods that support mutual authentication may not allow the EAP
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
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
EAP server.
EAP methods that export the Server-Id MUST verify the server
identity. As noted in Appendix A, existing EAP methods exporting the
Server-Id determine this from the altSubjectName in the server
certificate, and as a result, the peer determines the identity of the
server (expressed as a Fully Qualified Domain Name (FQDN)) by
validating the server certificate.
Validating the EAP server identity may help the EAP peer to decide
whether a specific EAP server is authorized, and to determine whether
the EAP server is sharing keying material outside the intended scope.
In some cases, such as where the certificate extensions defined in
[RFC4334] are included in the server certificate, it may even be
possible for the peer to verify some Channel Binding parameters from
the server certificate. Where the EAP peer does not verify the EAP
server identity, it is not possible for the peer to determine whether
the EAP server has shared keying material outside its authorized
scope.
It is possible for problems to arise in situations where the EAP
server identifies itself differently to the EAP peer and
authenticator. For example, the Server-Id exported by EAP methods
may not be identical to the Fully Qualified Domain Name (FQDN) of the
backend authentication server. Where certificate-based
authentication is used within RADIUS or Diameter, the altSubjectName
used in the backend server certificate may not be identical to the
Server-Id or backend server FQDN.
Where the backend server FQDN differs from the altSubjectName in the
certificate, the AAA client may not be able to successfully determine
whether it is talking to the correct backend authentication server.
Where the Server-Id and backend server FQDN differ, the combination
of the key scope (Peer-Id, Server-Id) and EAP conversation identifier
(Session-Id) may not be sufficient for the authenticator to determine
where the key resides. For example, the authenticator may identify
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
not correspond to the IP address or FQDN of a known backend
authentication server, then the authenticator will not know which
backend authentication server possesses the key.
3. Key Management 3. Key Management
EAP as defined in [RFC3748] supports key derivation, but does not EAP as defined in [RFC3748] supports key derivation, but does not
provide for the management of exported or derived keys. Although EAP provide for the management of exported or derived keys. Missing
methods may support "fast reconnect" as defined in [RFC3748] Section functionality includes:
7.2.1, EAP does not support re-key of exported keys without re-
authentication. Existing EAP methods do not export the Key-Lifetime [a] Re-key. EAP does not support re-key of exported keys without re-
parameter; in the interest of method independence, key management of authentication, although EAP methods may support "fast reconnect"
exported or derived keys SHOULD NOT be provided within EAP methods. as defined in [RFC3748] Section 7.2.1.
[b] Key delete/install semantics. EAP does not synchronize
installation or deletion of keying material on the EAP peer and
authenticator.
[c] Lifetime negotiation. EAP does not support lifetime negotiation for
exported keys, and existing EAP methods also do not support key
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
be reused if EAP keying material is cached.
These deficiencies are typically addressed via a post-EAP handshake
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 key management support, it
is RECOMMENDED that key management facilities be provided within the is RECOMMENDED that key management facilities be provided within the
Secure Association Protocol. This includes: Secure Association Protocol. This includes:
[a] Entity Naming. A basic feature of a Secure Association Protocol is [a] Entity Naming. A basic feature of a Secure Association Protocol is
the explicit naming of the parties engaged in the exchange. the explicit naming of the parties engaged in the exchange.
Without explicit identification, the parties engaged in the Without explicit identification, the parties engaged in the
skipping to change at page 27, line 7 skipping to change at page 29, line 13
keying material is valid. keying material is valid.
[c] Where the backend authentication server provides attributes [c] Where the backend authentication server provides attributes
restricting the key scope, it is RECOMMENDED that restrictions be restricting the key scope, it is RECOMMENDED that restrictions be
securely communicated by the authenticator to the peer. This can securely communicated by the authenticator to the peer. This can
be accomplished using the Secure Association Protocol, but also be accomplished using the Secure Association Protocol, but also
can be accomplished via the EAP method or the lower layer. can be accomplished via the EAP method or the lower layer.
3.3. Parent-Child Relationships 3.3. Parent-Child Relationships
When keying material exported by EAP methods expires, all keying
material derived from the exported keying material expires, including
the TSKs.
When an EAP re-authentication takes place, new keying material is When an EAP re-authentication takes place, new keying material is
derived and exported by the EAP method, which eventually results in derived and exported by the EAP method, which eventually results in
replacement of calculated keys, including the TSKs. replacement of TSKs, regardless of the way they are derived (see
Section 2.1). While the maximum lifetime of TSKs or child keys can
be less than or equal to that of the MSK/EMSK, it cannot be greater.
This is true even where exported EAP keying material is only used for
entity authentication and is not used for key derivation (such as in
IKEv2), so that compromise of exported EAP keying material does not
imply compromise of the TSKs or child keys. However, where child
keys are derived from or are wrapped by EAP keying material,
compromise of the MSK/EMSK does imply compromise of the child keys.
As a result, while the lifetime of calculated keys can be less than Child keys that are used frequently (such as TSKs which are used for
or equal that of the exported keys they are derived from, it cannot traffic protection) can expire sooner than the exported EAP keying
be greater. For example, when EAP re-authentication occurs, TSK re- material they are dependent on, so that it is advantageous to support
key will also occur. However, this does not prohibit TSK re-key from re-key of child keys prior to EAP re-authentication. Note that
occurring prior to expiration of the lifetime of exported keys. For deletion of the MSK/EMSK does not necessarily imply deletion of TSKs
example, TSK re-key may occur prior to EAP re-authentication. or child keys.
Failure to mutually prove possession of keying material during the Failure to mutually prove possession of exported EAP keying material
Secure Association Protocol exchange need not be grounds for deletion during the Secure Association Protocol exchange need not be grounds
of the keying material by both parties; rate-limiting Secure for deletion of the keying material by both parties; rate-limiting
Association Protocol exchanges could be used to prevent a brute force Secure Association Protocol exchanges could be used to prevent a
attack. brute force attack.
3.4. Local Key Lifetimes 3.4. Local Key Lifetimes
The Transient EAP Keys (TEKs) are session keys used to protect the The Transient EAP Keys (TEKs) are session keys used to protect the
EAP conversation. The TEKs are internal to the EAP method and are EAP conversation. The TEKs are internal to the EAP method and are
not exported. TEKs are typically created during an EAP conversation, not exported. TEKs are typically created during an EAP conversation,
used until the end of the conversation and then discarded. However, used until the end of the conversation and then discarded. However,
methods may re-key TEKs during an EAP conversation. methods may re-key TEKs during an EAP conversation.
When using TEKs within an EAP conversation or across conversations, When using TEKs within an EAP conversation or across conversations,
skipping to change at page 28, line 20 skipping to change at page 30, line 30
All EAP methods generating keys are required to generate the MSK and All EAP methods generating keys are required to generate the MSK and
EMSK, and may optionally generate the IV. However, EAP, defined in EMSK, and may optionally generate the IV. However, EAP, defined in
[RFC3748], does not itself support the negotiation of lifetimes for [RFC3748], does not itself support the negotiation of lifetimes for
exported keying material such as the MSK, EMSK and IV. exported keying material such as the MSK, EMSK and IV.
Several mechanisms exist for managing key lifetimes: Several mechanisms exist for managing key lifetimes:
[a] AAA attributes. AAA protocols such as RADIUS [RFC2865] and [a] AAA attributes. AAA protocols such as RADIUS [RFC2865] and
Diameter [RFC4072] support the Session-Timeout attribute. The Diameter [RFC4072] support the Session-Timeout attribute. The
Session-Timeout attribute represents the maximum lifetime of the Session-Timeout attribute represents the maximum lifetime of the
exported keys, and all keys calculated from it, on the exported keying material, and all keys depending on it, on the
authenticator. Since existing backend authentication servers do authenticator. Since existing backend authentication servers do
not cache keys exported by EAP methods, or keys calculated from not cache keys exported by EAP methods, or keys calculated from
exported keys, the value of the Session-Timeout attribute has no exported keys, the value of the Session-Timeout attribute has no
bearing on the key lifetime within the backend authentication bearing on the key lifetime within the backend authentication
server. server.
On the authenticator, where EAP is used for authentication, the On the authenticator, where EAP is used for authentication the
Session-Timeout attribute represents the maximum session time prior Session-Timeout attribute represents the maximum session time prior
to re-authentication. As described in [RFC3580] Section 3.17, when to re-authentication. As described in [RFC3580] Section 3.17, when
sent in an Access-Accept along with a Termination-Action value of sent in an Access-Accept along with a Termination-Action value of
RADIUS-Request, the Session-Timeout attribute specifies the maximum RADIUS-Request, the Session-Timeout attribute specifies the maximum
number of seconds of service provided prior to re-authentication. number of seconds of service provided prior to re-authentication.
Where EAP is used for pre-authentication, the session may not start Where EAP is used for pre-authentication, the session may not start
until some future time, or may never occur. Nevertheless, the until some future time, or may never occur. Nevertheless, the
Session-Timeout value represents the maximum time after which Session-Timeout value represents the maximum time after which
transported EAP keying material, and all keys calculated from it, transported EAP keying material, and all keys dependent on it, will
will have expired on the authenticator. If the session have expired on the authenticator. If the session subsequently
subsequently starts, re-authentication will be initiated once the starts, re-authentication will be initiated once the Session-Time
Session-Time has expired. If the session never started, or started has expired. If the session never started, or started and ended, by
and ended, by default keys transported by AAA and all keys default keys transported by AAA and all keys dependent on them be
calculated from them will be expired by the authenticator prior to expired by the authenticator prior to the future time indicated by
the future time indicated by Session-Timeout; this feature is Session-Timeout; this feature is utilized by [IEEE-802.11i]. Note
utilized by [IEEE-802.11i]. Note that in future additional that in future additional attributes may be specified to control
attributes may be specified to control the lifetime of cached keys; the lifetime of cached keys; these attributes may modify the
these attributes may modify the meaning of the Session-Timeout meaning of the Session-Timeout attribute in specific circumstances.
attribute in specific circumstances.
Since the TSK lifetime is often determined by authenticator Since the TSK lifetime is often determined by authenticator
resources, the backend authentication server has no insight into resources, and the backend authentication server has no insight
the TSK derivation process, and by the principle of ciphersuite into the TSK derivation process, by the principle of ciphersuite
independence, it is not appropriate for the backend authentication independence, it is not appropriate for the backend authentication
server to manage any aspect of the TSK derivation process, server to manage any aspect of the TSK derivation process,
including the TSK lifetime. including the TSK lifetime.
[b] Lower layer mechanisms. While AAA attributes can communicate the [b] Lower layer mechanisms. While AAA attributes can communicate the
maximum exported key lifetime, this only serves to synchronize the maximum exported key lifetime, this only serves to synchronize the
key lifetime between the backend authentication server and the key lifetime between the backend authentication server and the
authenticator. Lower layer mechanisms such as the Secure authenticator. Lower layer mechanisms such as the Secure
Association Protocol can then be used to enable the lifetime of Association Protocol can then be used to enable the lifetime of
exported and calculated keys to be negotiated between the peer and exported and calculated keys to be negotiated between the peer and
authenticator. authenticator.
Where TSKs are established as the result of a Secure Association Where TSKs are established as the result of a Secure Association
Protocol exchange, it is RECOMMENDED that the Secure Association Protocol exchange, it is RECOMMENDED that the Secure Association
Protocol include support for TSK rekey. Where the TSK is taken Protocol include support for TSK re-key. Where the TSK is taken
directly from the MSK, there is no need to manage the TSK lifetime directly from the MSK, there is no need to manage the TSK lifetime
as a separate parameter, since the TSK lifetime and MSK lifetime as a separate parameter, since the TSK lifetime and MSK lifetime
are identical. are identical.
[c] System defaults. Where the EAP method does not support the [c] System defaults. Where the EAP method does not support the
negotiation of the exported key lifetime, and a key lifetime negotiation of the lifetime of exported keys, and a key lifetime
negotiation mechanism is not provided by the lower lower, there may negotiation mechanism is not provided by the lower lower, there may
be no way for the peer to learn the exported key lifetime. In this be no way for the peer to learn the lifetime of exported keys. In
case it is RECOMMENDED that the peer assume a default value of the this case it is RECOMMENDED that the peer assume a default value; 8
exported key lifetime; 8 hours is recommended. Similarly, the hours is recommended. Similarly, the lifetime of calculated keys
lifetime of calculated keys can also be managed as a system can also be managed as a system parameter on the authenticator.
parameter on the authenticator.
[d] Method specific negotiation within EAP. While EAP itself does not [d] Method specific negotiation within EAP. While EAP itself does not
support lifetime negotiation, it would be possible to specify support lifetime negotiation, it would be possible to specify
methods that do. However, systems that rely on such negotiation methods that do. However, systems that rely on such negotiation
for exported keys would only function with these methods. As a for exported keys would only function with these methods. In the
result, it is NOT RECOMMENDED to use this approach as the sole way interest of method independence, key management of exported or
to determine key lifetimes. derived keys SHOULD NOT be provided within EAP methods.
3.6. Key cache synchronization 3.6. Key cache synchronization
Issues arise when attempting to synchronize the key cache on the peer Issues arise when attempting to synchronize the key cache on the peer
and authenticator. and authenticator.
While the AAA protocol can enable the backend authentication server While the AAA protocol can enable the backend authentication server
to provide guidance on the lifetime of transported EAP keying to provide guidance on the lifetime of transported EAP keying
material to the authenticator, this does not address the problem of material to the authenticator, this does not address the problem of
key lifetime synchronization between the peer and authenticator. key lifetime synchronization between the peer and authenticator.
Where the EAP method does not export the Key-Lifetime parameter, the Where the EAP method does not negotiate the lifetime of exported
lifetime of the EAP keying material may not be defined until keys, the lifetime of the EAP keying material may not be defined
completion of the Secure Association Protocol, if ever. This can until completion of the Secure Association Protocol, if ever. This
leave the peer uncertain how long the authenticator will maintain EAP can leave the peer uncertain how long the authenticator will maintain
keying material within the key cache. EAP keying material within the key cache.
However, key lifetime negotiation alone cannot guarantee key cache However, key lifetime negotiation alone cannot guarantee key cache
synchronization. Even where the Secure Association Protocol is run synchronization. Even where the Secure Association Protocol is run
immediately after EAP and determines the lifetime of EAP keying immediately after EAP and determines the lifetime of EAP keying
material, it is still possible for the authenticator to reclaim material, it is still possible for the authenticator to reclaim
resources. resources.
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 supporting As noted in Section 2.1, EAP lower layers determine TSKs in different
key derivation need to be capable of generating keying material with ways. Where EAP keying material is utilized in the derivation,
an appropriate effective symmetric key strength. In order to ensure encryption or authentication of TSKs, it is possible for EAP key
that EAP key generation is not the weakest link, it is RECOMMENDED generation to represent the weakest link.
that EAP methods utilizing public key cryptography choose a public
key that has a cryptographic strength meeting the symmetric key In order to ensure that EAP methods produce keying material of an
strength requirement. appropriate symmetric key strength, it is RECOMMENDED that EAP
methods utilizing public key cryptography choose a public key that
has a cryptographic strength providing the required level of attack
resistance. This is typically provided by configuring EAP methods,
since there is no coordination between the lower layer and EAP method
with respect to minimum required symmetric key strength.
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 31, line 15 skipping to change at page 33, line 33
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, [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 cleartext key attributes, to be Diameter EAP [RFC4072], which defines clear-text key attributes, to
protected by IPsec or TLS. be protected by IPsec or TLS.
4. Handoff Vulnerabilities 4. Handoff Vulnerabilities
With EAP, several mechanisms are available to reduce the latency in With EAP, several mechanisms are available to reduce the latency in
handoff between authenticators: handoff between authenticators:
[a] EAP pre-authentication. This utilizes EAP to pre-establish EAP [a] EAP pre-authentication. This utilizes EAP to pre-establish EAP
keying material on an authenticator prior to arrival of the peer. keying material on an authenticator prior to arrival of the peer.
Use of pre-authentication within IEEE 802.11 is described in Use of pre-authentication within IEEE 802.11 is described in
[8021XHandoff] and [IEEE-802.11i]. [8021XHandoff] and [IEEE-802.11i].
skipping to change at page 32, line 41 skipping to change at page 35, line 11
pre-authentication requests may appear indistinguishable. As a pre-authentication requests may appear indistinguishable. As a
result, the backend authentication server may not be able to result, the backend authentication server may not be able to
correctly calculate the simultaneous sessions in progress, either correctly calculate the simultaneous sessions in progress, either
preventing successful completion of pre-authentication or enabling preventing successful completion of pre-authentication or enabling
the peer to engage in more simultaneous sessions than they are the peer to engage in more simultaneous sessions than they are
authorized for. authorized for.
In order to allow backend authentication servers to handle pre- In order to allow backend authentication servers to handle pre-
authentication requests more reliably, it is recommended that EAP authentication requests more reliably, it is recommended that EAP
pre-authentication requests be explicitly identified within AAA pre-authentication requests be explicitly identified within AAA
protocols. Also, in order to supress unnecessary EAP pre- protocols. Also, in order to suppress unnecessary EAP pre-
authentication exchanges, it is recommended that authenticators authentication exchanges, it is recommended that authenticators
unambiguously identify themselves as described in Section 2.2.1, unambiguously identify themselves as described in Section 2.2.1,
allowing the peer to determine whether it has previously established allowing the peer to determine whether it has previously established
EAP keying material with that authenticator. EAP keying material with that authenticator.
4.2. Authorization 4.2. Authorization
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
skipping to change at page 37, line 16 skipping to change at page 39, line 31
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.
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. In developing the threat model, it is assumed
that:
All traffic is visible to the attacker.
The attacker can alter, forge or replay messages.
The attacker can reroute messages to another principal.
The attacker may be a principal or an outsider.
The attacker can compromise any key that is sufficiently old.
Threats arising from these assumptions include:
[a] 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.
[b] 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.
[c] 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.
[d] 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.
[e] An attacker may replay packets. [e] An attacker may alter, forge or replay packets.
[f] 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.
[g] 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.
skipping to change at page 38, line 9 skipping to change at page 40, line 34
[i] 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.
[j] 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, [I-D.housley-aaa-key-mgmt]
of mandatory system security properties. Issues relating to system provides a description of mandatory system security properties.
security requirements are discussed in the sections that follow. Issues relating to system security requirements are discussed in the
sections that follow.
5.1. Authenticator Compromise 5.1. Authenticator Compromise
In the event that an authenticator is compromised or stolen, an In the event that an authenticator is compromised or stolen, an
attacker may gain access to the network via that authenticator, or attacker may gain access to the network via that authenticator, or
may obtain the credentials required for that authenticator/AAA client may obtain the credentials required for that authenticator/AAA client
to communicate with one or more backend authentication servers. to communicate with one or more backend authentication servers.
However, this should not allow the attacker to compromise other However, this should not allow the attacker to compromise other
authenticators or the backend authentication server, or obtain long- authenticators or the backend authentication server, or obtain long-
term user credentials. term user credentials.
skipping to change at page 42, line 35 skipping to change at page 45, line 8
packets have been replayed. packets have been replayed.
In order to prevent replay of Secure Association Protocol frames, In order to prevent replay of Secure Association Protocol frames,
replay protection is REQUIRED on all messages. [IEEE-802.11i] replay protection is REQUIRED on all messages. [IEEE-802.11i]
supports replay protection on all messages within the 4-way supports replay protection on all messages within the 4-way
handshake. handshake.
5.6. Key Freshness 5.6. Key Freshness
A session key should be considered compromised if it remains in use A session key should be considered compromised if it remains in use
too long. As noted in [Housley], session keys MUST be strong and too long. As noted in [I-D.housley-aaa-key-mgmt]], session keys MUST
fresh, while preserving algorithm independence. A fresh be strong and fresh, while preserving algorithm independence. A
cryptographic key is one that is generated specifically for the fresh cryptographic key is one that is generated specifically for the
intended use. Each session deserves an independent session key; intended use. Each session deserves an independent session key;
disclosure of one session key MUST NOT aid the attacker in disclosure of one session key MUST NOT aid the attacker in
discovering any other session keys. discovering any other session keys.
Fresh keys are required even when a long replay counter (that is, one Fresh keys are required even when a long replay counter (that is, one
that "will never wrap") is used to ensure that loss of state does not that "will never wrap") is used to ensure that loss of state does not
cause the same counter value to be used more than once with the same cause the same counter value to be used more than once with the same
session key. session key.
EAP, AAA and the lower layer each bear responsibility for ensuring EAP, AAA and the lower layer each bear responsibility for ensuring
skipping to change at page 46, line 24 skipping to change at page 48, line 44
[RFC3579] Section 4.3.7 describes how an EAP pass-through [RFC3579] Section 4.3.7 describes how an EAP pass-through
authenticator acting as a AAA client can be detected if it attempts authenticator acting as a AAA client can be detected if it attempts
to impersonate another authenticator (such by sending incorrect to impersonate another authenticator (such by sending incorrect
Called-Station-Id [RFC2865], NAS-Identifier [RFC2865], NAS-IP-Address Called-Station-Id [RFC2865], NAS-Identifier [RFC2865], NAS-IP-Address
[RFC2865] or NAS-IPv6-Address [RFC3162] attributes via the AAA [RFC2865] or NAS-IPv6-Address [RFC3162] attributes via the AAA
protocol). This vulnerability can be mitigated by having RADIUS protocol). This vulnerability can be mitigated by having RADIUS
proxies check NAS identification attributes against the source proxies check NAS identification attributes against the source
address. address.
While [RFC3588] requires use of the Route-Record AVP, this utilizes While [RFC3588] requires use of the Route-Record AVP, this utilizes
FQDNs, so that impersonation detection requires DNS A, AAAA and PTR Fully Qualified Domain Names (FQDNs), so that impersonation detection
Resource Records (RRs) to be properly configured. As a result, requires DNS A, AAAA and PTR Resource Records (RRs) to be properly
Diameter is as vulnerable to this attack as RADIUS, if not more so. configured. As a result, Diameter is as vulnerable to this attack as
To address this vulnerability, it is necessary to allow the backend RADIUS, if not more so. To address this vulnerability, it is
authentication server to communicate with the authenticator directly, necessary to allow the backend authentication server to communicate
such as via the redirect functionality supported in [RFC3588]. with the authenticator directly, such as via the redirect
functionality supported in [RFC3588].
5.11. Channel Binding 5.11. Channel Binding
It is possible for a compromised or poorly implemented EAP It is possible for a compromised or poorly implemented EAP
authenticator to communicate incorrect information to the EAP peer authenticator to communicate incorrect information to the EAP peer
and/or server. This may enable an authenticator to impersonate and/or server. This may enable an authenticator to impersonate
another authenticator or communicate incorrect information via out- another authenticator or communicate incorrect information via out-
of-band mechanisms (such as via AAA or the lower layer). of-band mechanisms (such as via AAA or the lower layer).
Where EAP is used in pass-through mode, the EAP peer does not verify Where EAP is used in pass-through mode, the EAP peer does not verify
skipping to change at page 47, line 24 skipping to change at page 49, line 46
As noted in [RFC3748] Section 7.15, this vulnerability can be As noted in [RFC3748] Section 7.15, this vulnerability can be
addressed by EAP methods that support a protected exchange of channel addressed by EAP methods that support a protected exchange of channel
properties such as endpoint identifiers, including (but not limited properties such as endpoint identifiers, including (but not limited
to): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id to): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id
[RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address [RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address
[RFC2865], and NAS-IPv6-Address [RFC3162]. [RFC2865], and NAS-IPv6-Address [RFC3162].
Using such a protected exchange, it is possible to match the channel Using such a protected exchange, it is possible to match the channel
properties provided by the authenticator via out-of-band mechanisms properties provided by the authenticator via out-of-band mechanisms
against those exchanged within the EAP method. For example, see the against those exchanged within the EAP method. Typically the EAP
discussion in Section 1.4 as well as [I-D.arkko-eap-service-identity- method imports Channel Bindings from the lower layer on the peer, and
auth]. transmits them securely to the EAP server, which exports them to the
lower layer or AAA layer. However, transport may occur from EAP
server to peer, or may be bi-directional. On the side of the
exchange (peer or server) where Channel Bindings are verified, the
lower layer or AAA layer passes 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, typically only the server has the
knowledge to determine the correctness of the values, as opposed to
merely verifying their equality. For further discussion, see [I-
D.arkko-eap-service-identity-auth].
It is also possible to achieve Channel Bindings without transporting It is also possible to achieve Channel Bindings without transporting
data over EAP. For example, see [I-D.draft-ohba-eap-channel- data over EAP. For example, see [I-D.draft-ohba-eap-channel-
binding]. In this approach the backend server calculates transported binding]. In this approach the EAP method includes Channel Bindings
keying material based on the parameter set pre-configured for the in the calculation of exported EAP keying material, making it
authenticator, making it impossible for the peer and authenticator to impossible for the peer and authenticator to complete the Secure
complete the Secure Association Protocol if there was a mismatch in Association Protocol if there is a mismatch in the Channel Bindings.
the parameters. However, this approach can only be applied where EAP methods
generating key material are used along with lower layers that utilize
The main difference between these approaches is that Channel Binding the keying material. For example, this mechanism would not enable
support within an EAP method may require upgrading or changing the verification of Channel Bindings on wired IEEE 802 networks using
EAP method, impacting both the peer and the server. Where Channel IEEE 802.1X.
Bindings are implemented in AAA, the peer, authenticator and the
backend server need to be upgraded, but the EAP method need not be
modified.
6. IANA Considerations 6. IANA Considerations
This specification does not request the creation of any new parameter This specification does not request the creation of any new parameter
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
skipping to change at page 48, line 36 skipping to change at page 51, line 10
[GSAKMP] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP: [GSAKMP] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP:
Group Secure Association Group Management Protocol", Group Secure Association Group Management Protocol",
Internet draft (work in progress), draft-ietf-msec-gsakmp- Internet draft (work in progress), draft-ietf-msec-gsakmp-
sec-10, May 2005. 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.
[Housley] Housley, R. and B. Aboba, "AAA Key Management", draft-
housley-aaa-key-mgmt-01.txt, Internet draft (work in
progress), 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 11:
Wireless LAN Medium Access Control (MAC) and Physical Layer Wireless LAN Medium Access Control (MAC) and Physical Layer
(PHY) Specifications", IEEE IEEE Standard 802.11-2003, (PHY) Specifications", IEEE IEEE Standard 802.11-2003,
2003. 2003.
[IEEE-802.1X] [IEEE-802.1X]
skipping to change at page 49, line 45 skipping to change at page 52, line 15
during 802.11 Handoff", IEEE 802.11 Working Group, during 802.11 Handoff", IEEE 802.11 Working Group,
IEEE-02-758r1-F Draft 802.11I/D5.0, November 2002. IEEE-02-758r1-F Draft 802.11I/D5.0, November 2002.
[IEEE-03-084] [IEEE-03-084]
Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang,
"Proactive Key Distribution to support fast and secure "Proactive Key Distribution to support fast and secure
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]
Housley, R. and B. Aboba, "AAA Key Management", draft-
housley-aaa-key-mgmt-02.txt, Internet draft (work in
progress), March 2006.
[I-D.puthenkulam-eap-binding] [I-D.puthenkulam-eap-binding]
Puthenkulam, J., "The Compound Authentication Binding Puthenkulam, J., "The Compound Authentication Binding
Problem", draft-puthenkulam-eap-binding-04 (work in Problem", draft-puthenkulam-eap-binding-04 (work in
progress), October 2003. progress), October 2003.
[I-D.arkko-eap-service-identity-auth] [I-D.arkko-eap-service-identity-auth]
Arkko, J. and P. Eronen, "Authenticated Service Information Arkko, J. and P. Eronen, "Authenticated Service Information
for the Extensible Authentication Protocol (EAP)", draft- for the Extensible Authentication Protocol (EAP)", draft-
arkko-eap-service-identity-auth-02.txt (work in progress), arkko-eap-service-identity-auth-02.txt (work in progress),
May 2005. May 2005.
skipping to change at page 51, line 23 skipping to change at page 53, line 45
[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] [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC
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.
[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
skipping to change at page 52, line 28 skipping to change at page 54, line 50
[RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication
Protocol Method for 3rd Generation Authentication and Key Protocol Method for 3rd Generation Authentication and Key
Agreement (EAP-AKA)", RFC 4187, January 2006. Agreement (EAP-AKA)", RFC 4187, January 2006.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
4306, December 2005. 4306, December 2005.
[RFC4372] Adrangi, F., Lior, A., Korhonen, J. and J. Loughney, [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
Attributes Suporting Authenticatoin in Point-to-Point
Protocol (PPP) and Wireless Local Area Neworks (WLAN)", RFC
4334, February 2006.
[8021XHandoff] [8021XHandoff]
Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff in a Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff in a
Public Wireless LAN Based on IEEE 802.1X Model", School of Public Wireless LAN Based on IEEE 802.1X Model", School of
Computer Science and Engineering, Seoul National Computer Science and Engineering, Seoul National
University, Seoul, Korea, 2002. University, Seoul, Korea, 2002.
Acknowledgments Acknowledgments
Thanks to Arun Ayyagari, Ashwin Palekar, and Tim Moore of Microsoft, Thanks to Ashwin Palekar, and Tim Moore of Microsoft, Jari Arkko of
Dorothy Stanley of Agere, Bob Moskowitz of TruSecure, Jesse Walker of Ericsson, Dorothy Stanley of Aruba Networks, Bob Moskowitz of
Intel, Joe Salowey of Cisco and Russ Housley of Vigil Security for TruSecure, Jesse Walker of Intel, Joe Salowey of Cisco and Russ
useful feedback. Housley of Vigil Security for useful feedback.
Authors' Addresses Authors' Addresses
Bernard Aboba Bernard Aboba
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
EMail: bernarda@microsoft.com EMail: bernarda@microsoft.com
Phone: +1 425 706 6605 Phone: +1 425 706 6605
skipping to change at page 53, line 13 skipping to change at page 56, line 26
Dan Simon Dan Simon
Microsoft Research Microsoft Research
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
EMail: dansimon@microsoft.com EMail: dansimon@microsoft.com
Phone: +1 425 706 6711 Phone: +1 425 706 6711
Fax: +1 425 936 7329 Fax: +1 425 936 7329
Jari Arkko
Ericsson
Jorvas 02420
Finland
Phone:
EMail: jari.arkko@ericsson.com
Pasi Eronen Pasi Eronen
Nokia Research Center Nokia Research Center
P.O. Box 407 P.O. Box 407
FIN-00045 Nokia Group FIN-00045 Nokia Group
Finland Finland
EMail: pasi.eronen@nokia.com EMail: pasi.eronen@nokia.com
Henrik Levkowetz (editor) Henrik Levkowetz
ipUnplugged AB Ericsson Research
Arenavagen 27 Torshamsgatan 23
Stockholm S-121 28 SE-164 80 Stockholm
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 Session-Id, Peer-Id, Server-Id and Key- This Appendix specifies Session-Id, Peer-Id, Server-Id and Key-
Lifetime for EAP methods that have been published prior to this Lifetime for EAP methods that have been published prior to this
specification. Future EAP method specifications MUST include a specification. Future EAP method specifications MUST include a
definition of the Session-Id, Peer-Id, and Server-Id (could be the definition of the Session-Id, Peer-Id, and Server-Id (could be the
empty string) and MAY also define the Key-Lifetime (assumed to be empty string).
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 Session-Id. The
Session-Id. The Peer-Id exported by the Identity method is Peer-Id exported by the Identity method is determined by the
determined by the octets included within the EAP- octets included within the EAP- Response/Identity. The Server-Id
Response/Identity. The Server-Id is the empty string (zero 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 Session-Id. The
Session-Id. The Peer-Id and Server-Id are the empty string (zero 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 Session- keys and therefore does not define the Session-Id. The Peer-Id
Id. The Peer-Id and Server-Id are the empty string. 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 Session- keys and therefore does not define the Session-Id. The Peer-Id
Id. The Peer-Id and Server-Id are the empty string. and Server-Id are the empty string.
EAP-TLS EAP-TLS
EAP-TLS is defined in [RFC2716]. The EAP-TLS Session-Id is the EAP-TLS is defined in [RFC2716]. The EAP-TLS Session-Id is the
concatenation of the Expanded EAP Type Code (including the Type, concatenation of the EAP Type Code (0x0D) with the peer and server
Vendor-Id and Vendor-Type fields defined in [RFC3748] Section 5.7) nonces. The Peer-Id and Server-Id are the contents of the
with the peer and server nonces. The Peer-Id and Server-Id are altSubjectName in the peer and server certificates.
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 Session-Id is the
concatentation of the Expanded EAP Type Code (including the Type, concatenation of the EAP Type Code (0x17) with the contents of the
Vendor-Id and Vendor-Type fields defined in [RFC3748] Section 5.7) RAND field from the AT_RAND attribute, followed by the contents of
with the contents of the RAND field from the AT_RAND attribute, the AUTN field in the AT_AUTN 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.
AKA does not negotiate a key lifetime.
EAP-SIM EAP-SIM
EAP-SIM is defined in [RFC4186]. The EAP-SIM Session-Id is the EAP-SIM is defined in [RFC4186]. The EAP-SIM Session-Id is the
concatentation of the Expanded EAP Type Code (including the Type, concatenation of the EAP Type Code (0x12) with the contents of the
Vendor-Id and Vendor-Type fields defined in [RFC3748] Section 5.7) RAND field from the AT_RAND attribute, followed by the contents of
with the contents of the RAND field from the AT_RAND attribute, the NONCE_MT field in the AT_NONCE_MT 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.
SIM does not negotiate a key lifetime.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed
pertain to the implementation or use of the technology described in to pertain to the implementation or use of the technology
this document or the extent to which any license under such rights described in this document or the extent to which any license
might or might not be available; nor does it represent that it has under such rights might or might not be available; nor does it
made any independent effort to identify any such rights. Information represent that it has made any independent effort to identify any
on the procedures with respect to rights in RFC documents can be such rights. Information on the procedures with respect to rights
found in BCP 78 and BCP 79. in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use
such proprietary rights by implementers or users of this of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository
http://www.ietf.org/ipr. at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention
copyrights, patents or patent applications, or other proprietary any copyrights, patents or patent applications, or other
rights that may cover technology that may be required to implement proprietary rights that may cover technology that may be required
this standard. Please address the information to the IETF at ietf- to implement this standard. Please address the information to the
ipr@ietf.org. IETF at ietf-ipr@ietf.org.
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided on
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject Copyright (C) The Internet Society (2006). This document is
to the rights, licenses and restrictions contained in BCP 78, and subject to the rights, licenses and restrictions contained in BCP
except as set forth therein, the authors retain all their rights. 78, and except as set forth therein, the authors retain all their
rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
Open Issues Open Issues
Open issues relating to this specification are tracked on the Open issues relating to this specification are tracked on the
following web site: following web site:
http://www.drizzle.com/~aboba/EAP/eapissues.html http://www.drizzle.com/~aboba/EAP/
 End of changes. 111 change blocks. 
471 lines changed or deleted 590 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/