< draft-ietf-eap-keying-06.txt   draft-ietf-eap-keying-07.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-06.txt> J. Arkko <draft-ietf-eap-keying-07.txt> J. Arkko
1 April 2005 Ericsson 17 July 2005 Ericsson
P. Eronen P. Eronen
Nokia Nokia
H. Levkowetz, Ed. H. Levkowetz, Ed.
ipUnplugged ipUnplugged
Extensible Authentication Protocol (EAP) Key Management Framework Extensible Authentication Protocol (EAP) Key Management Framework
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, each author represents that any
patent or other IPR claims of which I am aware have been disclosed, applicable patent or other IPR claims of which he or she is aware
and any of which I become aware will be disclosed, in accordance with have been or will be disclosed, and any of which he or she becomes
RFC 3668. 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 22, 2005. This Internet-Draft will expire on January 22, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved. Copyright (C) The Internet Society 2005.
Abstract Abstract
The Extensible Authentication Protocol (EAP), defined in [RFC3748], The Extensible Authentication Protocol (EAP), defined in [RFC3748],
enables extensible network access authentication. This document enables extensible network access authentication. This document
provides a framework for the generation, transport and usage of provides a framework for the generation, transport and usage of
keying material generated by EAP authentication algorithms, known as keying material generated by EAP authentication algorithms, known as
"methods". It also specifies the EAP key hierarchy. "methods". It also specifies the EAP key hierarchy.
Table of Contents Table of Contents
1. Introduction .......................................... 4 1. Introduction .......................................... 4
1.1 Requirements Language ........................... 4 1.1 Requirements Language ........................... 4
1.2 Terminology ..................................... 4 1.2 Terminology ..................................... 4
1.3 Overview ........................................ 5 1.3 Overview ........................................ 7
1.4 EAP Invariants .................................. 11 1.4 EAP Invariants .................................. 14
2. Key Derivation ........................................ 13 2. Lower Layer Operation ................................. 16
2.1 Key Terminology ................................. 13 2.1 Discovery Phase ................................. 18
2.2 Key Hierarchy ................................... 15 2.2 Authentication Phase ............................ 18
2.3 AAA-Key Derivation .............................. 19 2.3 Secure Association Phase ........................ 19
2.4 Key Naming ...................................... 20 2.4 Lower Layer Key Hierarchy ....................... 21
3. Security associations ................................. 22 2.5 AAA-Key Derivation and Naming ................... 24
3.1 EAP Method SA ................................... 23 3. Security associations ................................. 26
3.2 EAP-Key SA ...................................... 24 3.1 EAP Method SA ................................... 26
3.3 AAA SA(s) ....................................... 24 3.2 EAP-Key SA ...................................... 27
3.4 Service SA(s) ................................... 24 3.3 AAA SA(s) ....................................... 27
4. Key Management ........................................ 27 3.4 Service SA(s) ................................... 27
4.1 Key Caching ..................................... 28 4. Key Management ........................................ 30
4.2 Parent-Child Relationships ...................... 29 4.1 Key Caching ..................................... 31
4.3 Local Key Lifetimes ............................. 29 4.2 Parent-Child Relationships ...................... 32
4.4 Exported and Calculated Key Lifetimes ........... 30 4.3 Local Key Lifetimes ............................. 32
4.5 Key Cache Synchronization ....................... 31 4.4 Exported and Calculated Key Lifetimes ........... 33
4.6 Key Scope ....................................... 32 4.5 Key Cache Synchronization ....................... 34
4.7 Key Strength .................................... 33 4.6 Key Scope ....................................... 35
4.8 Key Wrap ........................................ 34 4.7 Key Strength .................................... 36
5. Handoff Vulnerabilities ............................... 35 4.8 Key Wrap ........................................ 37
5.1 Authorization ................................... 35 5. Handoff Vulnerabilities ............................... 38
5.2 Correctness ..................................... 36 5.1 Authorization ................................... 38
6. Security Considerations .............................. 39 5.2 Correctness ..................................... 39
6.1 Security Terminology ............................ 39 6. Security Considerations .............................. 42
6.2 Threat Model .................................... 39 6.1 Security Terminology ............................ 42
6.3 Security Analysis ............................... 41 6.2 Threat Model .................................... 42
6.4 Man-in-the-middle Attacks ....................... 44 6.3 Security Analysis ............................... 44
6.5 Denial of Service Attacks ....................... 45 6.4 Man-in-the-middle Attacks ....................... 47
6.6 Impersonation ................................... 45 6.5 Denial of Service Attacks ....................... 48
6.7 Channel Binding ................................. 46 6.6 Impersonation ................................... 48
6.7 Channel Binding ................................. 50
7. Security Requirements ................................. 47 7. Security Requirements ................................. 50
7.1 EAP Method Requirements ......................... 47 7.1 EAP Method Requirements ......................... 51
7.2 AAA Protocol Requirements ....................... 50 7.2 AAA Protocol Requirements ....................... 53
7.3 Secure Association Protocol Requirements ........ 51 7.3 Secure Association Protocol Requirements ........ 55
7.4 Ciphersuite Requirements ........................ 53 7.4 Ciphersuite Requirements ........................ 56
8. IANA Considerations ................................... 54 8. IANA Considerations ................................... 57
9. References ............................................ 54 9. References ............................................ 57
9.1 Normative References ............................ 54 9.1 Normative References ............................ 57
9.2 Informative References .......................... 54 9.2 Informative References .......................... 57
Acknowledgments .............................................. 58 Acknowledgments .............................................. 61
Author's Addresses ........................................... 58 Author's Addresses ........................................... 61
Appendix A - Ciphersuite Keying Requirements ................. 60 Appendix A - Ciphersuite Keying Requirements ................. 63
Appendix B - Example Transient EAP Key (TEK) Hierarchy ....... 61 Appendix B - Example Transient EAP Key (TEK) Hierarchy ....... 64
Appendix C - EAP-TLS Key Hierarchy ........................... 62 Appendix C - EAP-TLS Key Hierarchy ........................... 65
Appendix D - Example Transient Session Key (TSK) Derivation .. 64 Appendix D - Example Transient Session Key (TSK) Derivation .. 67
Appendix E - Key Names and Scope in Existing Methods ......... 65 Appendix E - Exported Parameters in Existing Methods ......... 68
Appendix F - Security Association Examples ................... 66 Appendix F - Security Association Examples ................... 70
Intellectual Property Statement .............................. 69 Intellectual Property Statement .............................. 73
Disclaimer of Validity ....................................... 70 Disclaimer of Validity ....................................... 74
Copyright Statement .......................................... 70 Copyright Statement .......................................... 74
1. Introduction 1. Introduction
The Extensible Authentication Protocol (EAP), defined in [RFC3748], The Extensible Authentication Protocol (EAP), defined in [RFC3748],
was designed to enable extensible authentication for network access was designed to enable extensible authentication for network access
in situations in which the IP protocol is not available. Originally in situations in which the IP protocol is not available. Originally
developed for use with PPP [RFC1661], it has subsequently also been developed for use with PPP [RFC1661], it has subsequently also been
applied to IEEE 802 wired networks [IEEE-802.1X]. applied to IEEE 802 wired networks [IEEE-802.1X].
This document provides a framework for the generation, transport and This document provides a framework for the generation, transport and
skipping to change at page 5, line 23 skipping to change at page 5, line 23
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.
security association security association
A set of policies and cryptographic state used to protect A set of policies and cryptographic state used to protect
information. Elements of a security association may include information. Elements of a security association may include
cryptographic keys, negotiated ciphersuites and other parameters, cryptographic keys, negotiated ciphersuites and other parameters,
counters, sequence spaces, authorization attributes, etc. counters, sequence spaces, authorization attributes, etc.
Long Term Credential
EAP methods frequently make use of long term secrets in order to
enable authentication between the peer and server. In the case of
a method based on pre-shared key authentication, the long term
credential is the pre-shared key. In the case of a public-key
based method, the long term credential is the corresponding private
key.
Master Session Key (MSK)
Keying material that is derived between the EAP peer and server and
exported by the EAP method. The MSK is at least 64 octets in
length.
Extended Master Session Key (EMSK)
Additional keying material derived between the peer and server that
is exported by the EAP method. The EMSK is at least 64 octets in
length, and is never shared with a third party.
Initialization Vector (IV)
A quantity of at least 64 octets, suitable for use in an
initialization vector field, that is derived between the peer and
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
quantity that needs to remain secret. As a result, its use has
been deprecated and EAP methods are not required to generate it.
However, when it is generated it MUST be unpredictable.
Pairwise Master Key (PMK)
The AAA-Key is divided into two halves, the "Peer to Authenticator
Encryption Key" (Enc-RECV-Key) and "Authenticator to Peer
Encryption Key" (Enc-SEND-Key) (reception is defined from the point
of view of the authenticator). Within [IEEE-802.11i] Octets 0-31
of the AAA-Key (Enc-RECV-Key) are known as the Pairwise Master Key
(PMK). In [IEEE-802.11i] the TKIP and AES CCMP ciphersuites derive
their Transient Session Keys (TSKs) solely from the PMK, whereas
the WEP ciphersuite as noted in [RFC3580], derives its TSKs from
both halves of the AAA-Key.
Transient EAP Keys (TEKs)
Session keys which are used to establish a protected channel
between the EAP peer and server during the EAP authentication
exchange. The TEKs are appropriate for use with the ciphersuite
negotiated between EAP peer and server for use in protecting the
EAP conversation. Note that the ciphersuite used to set up the
protected channel between the EAP peer and server during EAP
authentication is unrelated to the ciphersuite used to subsequently
protect data sent between the EAP peer and authenticator. An
example TEK key hierarchy is described in Appendix C.
Transient Session Keys (TSKs)
Session keys used to protect data exchanged between a port of the
peer and a port of the authenticator after the EAP authentication
has successfully completed. TSKs are appropriate for the lower
layer ciphersuite negotiated between the ports of the EAP peer and
authenticator. Examples of TSK derivation are provided in Appendix
D.
AAA-Key
A key derived by the peer and EAP server, used by the peer and
authenticator in the derivation of Transient Session Keys (TSKs).
Where a backend authentication server is present, the AAA-Key is
transported from the backend authentication server to the
authenticator, wrapped within the AAA-Token; it is therefore known
by the peer, authenticator and backend authentication server.
Despite the name, the AAA-Key is computed regardless of whether a
backend authentication server is present. AAA-Key derivation is
discussed in Section 2.5; in existing implementations the MSK is
used as the AAA-Key.
AAA-Token
Where a backend server is present, the AAA-Key and one or more
attributes is transported between the backend authentication server
and the authenticator within a package known as the AAA-Token. The
format and wrapping of the AAA-Token, which is intended to be
accessible only to the backend authentication server and
authenticator, is defined by the AAA protocol. Examples include
RADIUS [RFC2548] and Diameter [I-D.ietf-aaa-eap].
1.3. Overview 1.3. Overview
EAP, defined in [RFC3748] is a two-party protocol spoken between the
EAP peer and server. Within EAP, keying material is generated by EAP
methods. Part of this keying material may be used by EAP methods
themselves and part of this material may be exported. In addition to
export of keying material, EAP methods may also export associated
parameters, and may import and export Channel Bindings from the lower
layer.
As illustrated in Figure 1, the EAP method key derivation has at the
root the long term credential utilized by the selected EAP method.
If authentication is based on a pre-shared key, the parties store the
EAP method to be used and the pre-shared key. The EAP server also
stores the peer's identity and/or other information necessary to
decide whether access to some service should be granted. The peer
stores information necessary to choose which secret to use for which
service.
If authentication is based on proof of possession of the private key
corresponding to the public key contained within a certificate, the
parties store the EAP method to be used and the trust anchors used to
validate the certificates. The EAP server also stores the peer's
identity and/or other information necessary to decide whether access
to some service should be granted. The peer stores information
necessary to choose which certificate to use for which service.
Based on the long term credential established between the peer and
the server, EAP methods derive two types of keys:
[1] Keys calculated locally by the EAP method but not exported
by the EAP method, such as the TEKs.
[2] Keying material exported by the EAP method: MSK, EMSK, IV.
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
least 64 octets in length. EAP methods also may export the IV;
however, the use of the IV is deprecated.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | ^
| EAP Method | |
| | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | |
| | | | | | |
| | EAP Method Key |<->| Long-Term | | |
| | Derivation | | Credential | | |
| | | | | | |
| | | +-+-+-+-+-+-+-+ | Local to |
| | | | EAP |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Method |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | |
| | | TEK | |MSK, EMSK | |IV | | |
| | |Derivation | |Derivation | |Derivation | | |
| | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | |
| | | | | |
| | ^ | | | V
+-+-|-+-+-+-+-+-+-+-+-|-+-+-+-+-+-|-+-+-+-+-+-+-+-+-|-+-+-+ ---+
| | | | ^
| Peer-ID, | | | Exported|
| Server-ID, | Channel | MSK (64+B) | IV (64B) by |
| Method-ID, | Bindings | EMSK (64+B) | EAP |
| Key-Lifetime | & Result | | Method |
V V V V V
Figure 1: EAP Parameter Import/Export
EAP methods also MAY export method-specific peer and server
identifiers (peer-ID and server-ID), a method-specific EAP
conversation identifier known as the Method-ID, and the lifetime of
the exported keys, known the Key-Lifetime. EAP methods MAY also
support the import and export of Channel Bindings. New EAP method
specifications MUST define the Peer-ID, Server-ID and Method-ID. The
combination of the Peer-ID and Server-ID uniquely specifies the
endpoints of the EAP method exchange.
Peer-ID
As described in [RFC3748] Section 7.3, the identity provided in
the EAP-Response/Identity, may be different from the peer identity
authenticated by the EAP method. Where the EAP method
authenticates the peer identity, that identity is exported by the
method as the Peer-ID. A suitable EAP peer name may not always be
available. Where an EAP method does not define a method-specific
peer identity, the Peer-ID is the null string. The Peer-ID for
existing EAP methods is defined in Appendix E.
Server-ID
Where the EAP method authenticates the server identity, that
identity is exported by the method as the Server-ID. A suitable
EAP server name may not always be available. Where an EAP method
does not define a method-specific peer identity, the Server-ID is
the null string. The Server-ID for existing EAP methods is
defined in Appendix E.
Method-ID
EAP method specifications deriving keys MUST specify a temporally
unique method identifier known as the Method-ID. The EAP Method-
ID uniquely identifies an EAP session of a given Type between an
EAP peer and server. The Method-ID is typically constructed from
nonces or counters used within the EAP method exchange. The
Method-ID for existing EAP methods is defined in Appendix E.
Session-ID
The Session-ID uniquely identifies an EAP session between an EAP
peer (as identified by the Peer-ID) and server (as identified by
the Server-ID). The EAP Session-ID consists of the concatenation
of the Expanded EAP Type Code (including the Type, Vendor-ID and
Vendor-Type fields defined in [RFC3748] Section 5.7) and the
Method-ID. 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.
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 include lower layer parameters that are verified
for consistency between the EAP peer and server. In order to
avoid introducing media dependencies, EAP methods MUST treat
Channel Bindings as opaque octets. 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. 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
passes the result of the verification (TRUE or FALSE) up to the
EAP method.
1.3.1. Layering
As illustrated in Figure 2, keying material and parameters exported
by EAP methods are passed down to the EAP peer or authenticator
layers, which passes them to the EAP layer. Keying material and
related parameters (including Channel Bindings) MUST NOT be cached by
the EAP peer or authenticator layers, or the EAP layer.
Based on the Method-ID exported by the EAP method, the EAP layer
forms the EAP Session-ID by concatenating the EAP Expanded Type with
the Method-ID. Together with the MSK, EMSK, IV, Peer-ID, Server-ID,
and Key-Lifetime, the EAP layer passes the Session-ID down to the
lower layer.
The Method-ID is exported by EAP methods rather than the Session-ID
so as to prevent EAP methods from writing into each other's Session-
ID space. Lower layers MAY cache keying material and related
parameters, including Channel Bindings. Lower Layer behavior is
discussed in more detail in Section 2.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| EAP method |
| |
| MSK, EMSK, IV, Channel |
| Peer-ID, Server-ID, Bindings |
| Method-ID, |
| Key-Lifetime |
| |
| V ^ ^ |
+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+
| ! ! ! |
| EAP ! Peer or Authenticator ! ! |
| ! layer ! ! |
| ! ! ! |
+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+
| ! ! ! |
| EAP ! layer ! ! |
| ! ! ! |
| ! Session-ID = ! ! |
| ! Expanded-Type || ! ! |
| ! Method-ID ! ! |
| ! ! ! |
+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+
| ! ! ! |
| Lower ! layer ! ! |
| ! ! ! |
| V V ^ |
| MSK, EMSK, IV, Channel Result |
| Peer-ID, Server-ID, Bindings |
| Session-ID, |
| Key-Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Flow of EAP parameters
1.3.2. Key Naming
Each key created within the EAP key management framework has a name
(the identifier by which the key can be identified), as well as a
scope (the parties to whom the key is available). The scope of
exported parameters is defined by the EAP peer name (if securely
exchanged within the method) and the EAP server name (also only if
securely exchanged). Where a peer or server name is missing the null
string is used.
MSK Name
This key is created between the EAP peer and EAP server, and can be
referred to using the string "MSK:", concatenated with the EAP
Session-ID.
EMSK Name
The EMSK can be referred to using the string "EMSK:", concatenated
with the EAP Session-ID.
IV Name
Use of the IV is deprecated. However, if necessary the IV can be
referred to using the string "IV:" concatenated with the EAP
Session-ID.
PMK Name
This document does not specify a naming scheme for the PMK. The
PMK is only identified by the key from which it is derived.
Note: IEEE 802.11i names the PMKID for the purposes of being able
to refer to it in the Secure Association protocol; this naming is
based on a hash of the PMK itself as well as some other parameters
(see Section 8.5.1.2 [IEEE-802.11i]).
TEK Name
The TEKs may or may not be named. Their naming is specified in the
EAP method.
1.3.3. EAP and AAA
EAP is typically deployed in order to support extensible network EAP is typically deployed in order to support extensible network
access authentication in situations where a peer desires network access authentication in situations where a peer desires network
access via one or more authenticators. Since both the peer and access via one or more authenticators. Since both the peer and
authenticator may have more than one physical or logical port, a authenticator may have more than one physical or logical port, a
given peer may simultaneously access the network via multiple given peer may simultaneously access the network via multiple
authenticators, or via multiple physical or logical ports on a given authenticators, or via multiple physical or logical ports on a given
authenticator. Similarly, an authenticator may offer network access authenticator. Similarly, an authenticator may offer network access
to multiple peers, each via a separate physical or logical port. The to multiple peers, each via a separate physical or logical port. The
situation is illustrated in Figure 1. situation is illustrated in Figure 3.
Where authenticators are deployed standalone, the EAP conversation Where authenticators are deployed standalone, the EAP conversation
occurs between the peer and authenticator, and the authenticator must occurs between the peer and authenticator, and the authenticator must
locally implement an EAP method acceptable to the peer. However, one locally implement an EAP method acceptable to the peer. However, one
of the advantages of EAP is that it enables deployment of new of the advantages of EAP is that it enables deployment of new
authentication methods without requiring development of new code on authentication methods without requiring development of new code on
the authenticator. While the authenticator may implement some EAP the authenticator. While the authenticator may implement some EAP
methods locally and use those methods to authenticate local users, it methods locally and use those methods to authenticate local users, it
may at the same time act as a pass-through for other users and may at the same time act as a pass-through for other users and
methods, forwarding EAP packets back and forth between the backend methods, forwarding EAP packets back and forth between the backend
skipping to change at page 6, line 41 skipping to change at page 13, line 48
\ | / \ | /
\ | / \ | /
\ | / \ | /
+-+-+-+-+ +-+-+-+-+
| | | |
| AAA | | AAA |
|Server | |Server |
| | | |
+-+-+-+-+ +-+-+-+-+
Figure 1: Relationship between peer, authenticator and backend server Figure 3: Relationship between peer, authenticator and backend server
1.4. EAP Invariants
Where EAP key derivation is supported, the conversation between the Certain basic characteristics, known as "EAP Invariants", hold true
peer and the authenticator typically takes place in three phases: for EAP implementations on all media:
Mode independence
Media independence
Method independence
Ciphersuite independence
1.4.1. Mode Independence
EAP as defined in [RFC3748] is a two party protocol spoken between
the EAP peer and server. A fundamental property of EAP is that at
the EAP method layer, the conversation between the EAP peer and
server is unaffected by whether the EAP authenticator is operating in
"pass-through" mode.
EAP methods operate identically in all aspects, including key
derivation and parameter import/export, regardless of whether the
authenticator is operating as a pass-through or not.
The successful completion of an EAP method that supports key
derivation results in the export of keying material on the EAP peer
and server. Even though the EAP peer or server may import Channel-
Bindings that may include the identity of the EAP authenticator,
this information is treated as opaque octets. As a result, within
EAP the only relevant identities are the Peer-ID and Server-ID.
Channel Bindings are only interpreted by the lower layer.
Within EAP, the primary function of the AAA protocol is to maintain
the principle of Mode Independence, so that as far as the EAP peer is
concerned, its conversation with the EAP authenticator, and all
consequences of that conversation, are identical, regardless of the
authenticator mode of operation.
1.4.2. Media Independence
One of the goals of EAP is to allow EAP methods to function on any
lower layer meeting the criteria outlined in [RFC3748], Section 3.1.
For example, as described in [RFC3748], EAP authentication can be run
over PPP [RFC1661], IEEE 802 wired networks [IEEE-802.1X], and IEEE
802.11 wireless LANs [IEEE-802.11i].
In order to maintain media independence, it is necessary for EAP to
avoid consideration of media-specific elements. For example, EAP
methods cannot be assumed to have knowledge of the lower layer over
which they are transported, and cannot be restricted to identifiers
associated with a particular usage environment (e.g. MAC addresses).
Note that media independence may be retained within EAP methods that
support Channel-Bindings or method-specific identification. An EAP
method need not be aware of the content of an identifier in order to
use it. This enables an EAP method to use media-specific identifiers
such as MAC addresses without compromising media independence.
Channel-Bindings are treated as opaque octets by EAP methods, so that
handling them does not require media-specific knowledge.
1.4.3. Method Independence
By enabling pass-through, authenticators can support any method
implemented on the peer and server, not just locally implemented
methods. This allows the authenticator to avoid implementing code
for each EAP method required by peers. In fact, since a pass-through
authenticator is not required to implement any EAP methods at all, it
cannot be assumed to support any EAP method-specific code.
As a result, as noted in [RFC3748], authenticators must by default be
capable of supporting any EAP method. This is useful where there is
no single EAP method that is both mandatory-to-implement and offers
acceptable security for the media in use. For example, the [RFC3748]
mandatory-to-implement EAP method (MD5-Challenge) does not provide
dictionary attack resistance, mutual authentication or key
derivation, and as a result is not appropriate for use in wireless
LAN authentication [RFC4017]. However, despite this it is possible
for the peer and authenticator to interoperate as long as a suitable
EAP method is supported on the EAP server.
1.4.4. Ciphersuite Independence
Ciphersuite Independence is a consequence of the principles of Mode
Independence and Media Independence.
While EAP methods may negotiate the ciphersuite used in protection of
the EAP conversation, the ciphersuite used for the protection of the
data exchanged after EAP authentication has completed is negotiated
between the peer and authenticator within the lower layer, outside of
EAP. Since the ciphersuites used to protect data depend on the lower
layer, requiring EAP methods have knowledge of lower layer
ciphersuites would compromise the principle of Media Indepence.
Since ciphersuite negotiation occurs in the lower layer, there is no
need for ciphersuite negotiation within EAP, and EAP methods generate
keying material that is ciphersuite-independent.
For example, within PPP, the ciphersuite is negotiated within the
Encryption Control Protocol (ECP) defined in [RFC1968], after EAP
authentication is completed. Within [IEEE-802.11i], the AP
ciphersuites are advertised in the Beacon and Probe Responses prior
to EAP authentication, and are securely verified during a 4-way
handshake exchange.
Advantages of ciphersuite-independence include:
Reduced update requirements
If EAP methods were to specify how to derive transient session keys
for each ciphersuite, they would need to be updated each time a new
ciphersuite is developed. In addition, backend authentication
servers might not be usable with all EAP-capable authenticators,
since the backend authentication server would also need to be
updated each time support for a new ciphersuite is added to the
authenticator.
Reduced EAP method complexity
Requiring each EAP method to include ciphersuite-specific code for
transient session key derivation would increase method complexity
and result in duplicated effort.
Simplified configuration
The ciphersuite is negotiated between the peer and authenticator
outside of EAP. Where the authenticator operates in "pass-through"
mode, the EAP server is not a party to this negotiation, nor is it
involved in the data flow between the EAP peer and authenticator.
As a result, the EAP server may not have knowledge of the
ciphersuites and negotiation policies implemented by the peer and
authenticator, or be aware of the ciphersuite negotiated between
them. For example, since ECP negotiation occurs after
authentication, when run over PPP, the EAP peer and server may not
anticipate the negotiated ciphersuite and therefore this
information cannot be provided to the EAP method.
2. Lower Layer Operation
Where EAP key derivation is supported, the conversation typically
takes place in three phases:
Phase 0: Discovery Phase 0: Discovery
Phase 1: Authentication Phase 1: Authentication
1a: EAP authentication 1a: EAP authentication
1b: AAA-Key Transport (optional) 1b: AAA-Key Transport (optional)
Phase 2: Secure Association Establishment Phase 2: Secure Association Establishment
2a: Unicast Secure Association 2a: Unicast Secure Association
2b: Multicast Secure Association (optional) 2b: Multicast Secure Association (optional)
In the discovery phase (phase 0), peers locate authenticators and Of these phases, Phase 0, 1b and Phase 2 are handled by a lower
discover their capabilities. For example, a peer may locate an layer. In the discovery phase (phase 0), peers locate
authenticator providing access to a particular network, or a peer may authenticators and discover their capabilities. For example, a peer
locate an authenticator behind a bridge with which it desires to may locate an authenticator providing access to a particular network,
establish a Secure Association. or a peer may locate an authenticator behind a bridge with which it
desires to establish a Secure Association.
The authentication phase (phase 1) may begin once the peer and The authentication phase (phase 1) may begin once the peer and
authenticator discover each other. This phase always includes EAP authenticator discover each other. This phase always includes EAP
authentication (phase 1a). Where the chosen EAP method supports key authentication (phase 1a). Where the chosen EAP method supports key
derivation, in phase 1a keying material is derived on both the peer derivation, in phase 1a keying material is derived on both the peer
and the EAP server. This keying material may be used for multiple and the EAP server. This keying material may be used for multiple
purposes, including protection of the EAP conversation and subsequent purposes, including protection of the EAP conversation and subsequent
data exchanges. data exchanges.
An additional step (phase 1b) is required in deployments which An additional step (phase 1b) is required in deployments which
include a backend authentication server, in order to transport keying include a backend authentication server, in order to transport keying
material (known as the AAA-Key) from the backend authentication material (known as the AAA-Key) from the backend authentication
server to the authenticator. server to the authenticator.
A Secure Association exchange (phase 2) then occurs between the peer A Secure Association exchange (phase 2) then occurs between the peer
and authenticator in order to manage the creation and deletion of and authenticator in order to manage the creation and deletion of
unicast (phase 2a) and multicast (phase 2b) security associations unicast (phase 2a) and multicast (phase 2b) security associations
between the peer and authenticator. between the peer and authenticator.
The conversation phases and relationship between the parties is shown The conversation phases and relationship between the parties is shown
in Figure 2. in Figure 4.
EAP peer Authenticator Auth. Server EAP peer Authenticator Auth. Server
-------- ------------- ------------ -------- ------------- ------------
|<----------------------------->| | |<----------------------------->| |
| Discovery (phase 0) | | | Discovery (phase 0) | |
|<----------------------------->|<----------------------------->| |<----------------------------->|<----------------------------->|
| EAP auth (phase 1a) | AAA pass-through (optional) | | EAP auth (phase 1a) | AAA pass-through (optional) |
| | | | | |
| |<----------------------------->| | |<----------------------------->|
| | AAA-Key transport | | | AAA-Key transport |
| | (optional; phase 1b) | | | (optional; phase 1b) |
|<----------------------------->| | |<----------------------------->| |
| Unicast Secure association | | | Unicast Secure association | |
| (phase 2a) | | | (phase 2a) | |
| | | | | |
|<----------------------------->| | |<----------------------------->| |
| Multicast Secure association | | | Multicast Secure association | |
| (optional; phase 2b) | | | (optional; phase 2b) | |
| | | | | |
Figure 2: Conversation Overview Figure 4: Conversation Overview
1.3.1. Discovery Phase 2.1. Discovery Phase
In the discovery phase (phase 0), the EAP peer and authenticator In the discovery phase (phase 0), the EAP peer and authenticator
locate each other and discover each other's capabilities. Discovery locate each other and discover each other's capabilities. Discovery
can occur manually or automatically, depending on the lower layer can occur manually or automatically, depending on the lower layer
over which EAP runs. Since authenticator discovery is handled over which EAP runs. Since authenticator discovery is handled
outside of EAP, there is no need to provide this functionality within outside of EAP, there is no need to provide this functionality within
EAP. EAP.
For example, where EAP runs over PPP, the EAP peer might be For example, where EAP runs over PPP, the EAP peer might be
configured with a phone book providing phone numbers of configured with a phone book providing phone numbers of
skipping to change at page 8, line 28 skipping to change at page 18, line 28
[RFC2516] provides support for a Discovery Stage to allow a peer to [RFC2516] provides support for a Discovery Stage to allow a peer to
identify the Ethernet MAC address of one or more authenticators and identify the Ethernet MAC address of one or more authenticators and
establish a PPPoE SESSION_ID. establish a PPPoE SESSION_ID.
IEEE 802.11 [IEEE-802.11] also provides integrated discovery support IEEE 802.11 [IEEE-802.11] also provides integrated discovery support
utilizing Beacon and/or Probe Request/Response frames, allowing the utilizing Beacon and/or Probe Request/Response frames, allowing the
peer (known as the station or STA) to determine the MAC address and peer (known as the station or STA) to determine the MAC address and
capabilities of one or more authenticators (known as Access Point or capabilities of one or more authenticators (known as Access Point or
APs). APs).
1.3.2. Authentication Phase 2.2. Authentication Phase
Once the peer and authenticator discover each other, they exchange Once the peer and authenticator discover each other, they exchange
EAP packets. Typically, the peer desires access to the network, and EAP packets. Typically, the peer desires access to the network, and
the authenticators provide that access. In such a situation, access the authenticators provide that access. In such a situation, access
to the network can be provided by any authenticator attaching to the to the network can be provided by any authenticator attaching to the
desired network, and the EAP peer is typically willing to send data desired network, and the EAP peer is typically willing to send data
traffic through any authenticator that can demonstrate that it is traffic through any authenticator that can demonstrate that it is
authorized to provide access to the desired network. authorized to provide access to the desired network.
An EAP authenticator may handle the authentication locally, or it may An EAP authenticator may handle the authentication locally, or it may
skipping to change at page 9, line 30 skipping to change at page 19, line 30
Successful completion of EAP authentication and key derivation by a Successful completion of EAP authentication and key derivation by a
peer and EAP server does not necessarily imply that the peer is peer and EAP server does not necessarily imply that the peer is
committed to joining the network associated with an EAP server. committed to joining the network associated with an EAP server.
Rather, this commitment is implied by the creation of a security Rather, this commitment is implied by the creation of a security
association between the EAP peer and authenticator, as part of the association between the EAP peer and authenticator, as part of the
Secure Association Protocol (phase 2). As a result, EAP may be used Secure Association Protocol (phase 2). As a result, EAP may be used
for "pre-authentication" in situations where it is necessary to pre- for "pre-authentication" in situations where it is necessary to pre-
establish EAP security associations in order to decrease handoff or establish EAP security associations in order to decrease handoff or
roaming latency. roaming latency.
1.3.3. Secure Association Phase 2.3. Secure Association Phase
The Secure Association phase (phase 2), if it occurs, begins after The Secure Association phase (phase 2), if it occurs, begins after
the completion of EAP authentication (phase 1a) and key transport the completion of EAP authentication (phase 1a) and key transport
(phase 1b). A Secure Association Protocol used with EAP typically (phase 1b). A Secure Association Protocol used with EAP typically
supports the following features: supports the following features:
[1] Generation of fresh transient session keys (TSKs). Where AAA-Key [1] Generation of fresh transient session keys (TSKs). Where AAA-Key
caching is supported, the EAP peer may initiate a new session using caching is supported, the EAP peer may initiate a new session using
a AAA-Key that was used in a previous session. Were the TSKs to be a AAA-Key that was used in a previous session. Were the TSKs to be
derived from a portion of the AAA-Key, this would result in reuse derived from a portion of the AAA-Key, this would result in reuse
skipping to change at page 10, line 10 skipping to change at page 20, line 10
order to generate fresh unicast (phase 2a) and possibly multicast order to generate fresh unicast (phase 2a) and possibly multicast
(phase 2b) session keys. By not using the AAA-Key directly to (phase 2b) session keys. By not using the AAA-Key directly to
protect data, the Secure Association Protocol protects against protect data, the Secure Association Protocol protects against
compromise of the AAA-Key. compromise of the AAA-Key.
[2] Entity Naming. A basic feature of a Secure Association Protocol is [2] 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.
Explicit identification of the parties is critical, since without Explicit identification of the parties is critical, since without
this the parties engaged in the exchange are not identified and the this the parties engaged in the exchange are not identified and the
scope of the transient session keys (TSKs) generated during the scope of the transient session keys (TSKs) generated during the
exchange is undefined. As illustrated in Figure 1, both the peer exchange is undefined. As illustrated in Figure 3, both the peer
and NAS may have more than one physical or virtual port, so that and NAS may have more than one physical or virtual port, so that
port identifiers are NOT RECOMMENDED as a naming mechanism. port identifiers are NOT RECOMMENDED as a naming mechanism.
[3] Secure capabilities negotiation. This includes the secure [3] Secure capabilities negotiation. This includes the secure
negotiation of usage modes, session parameters (such as key negotiation of usage modes, session parameters (such as key
lifetimes), ciphersuites and required filters, including lifetimes), ciphersuites and required filters, including
confirmation of the capabilities discovered during phase 0. It is confirmation of the capabilities discovered during phase 0. It is
RECOMMENDED that the Secure Association Protocol support secure RECOMMENDED that the Secure Association Protocol support secure
capabilities negotiation, in order to protect against spoofing capabilities negotiation, in order to protect against spoofing
during the discovery phase, and to ensure agreement between the during the discovery phase, and to ensure agreement between the
skipping to change at page 11, line 5 skipping to change at page 21, line 5
[5] Mutual proof of possession of the AAA-Key. The Secure Association [5] Mutual proof of possession of the AAA-Key. The Secure Association
Protocol MUST demonstrate mutual proof of posession of the AAA-Key, Protocol MUST demonstrate mutual proof of posession of the AAA-Key,
in order to show that both the peer and authenticator have been in order to show that both the peer and authenticator have been
authenticated and authorized by the backend authentication server. authenticated and authorized by the backend authentication server.
Since mutual proof of possession is not the same as mutual Since mutual proof of possession is not the same as mutual
authentication, the peer cannot verify authenticator assertions authentication, the peer cannot verify authenticator assertions
(including the authenticator identity) as a result of this (including the authenticator identity) as a result of this
exchange. exchange.
1.4. EAP Invariants 2.4. Lower Layer Key Hierarchy
Certain basic characteristics, known as the "EAP Invariants" hold
true for EAP implementations on all media:
Media independence
Method independence
Ciphersuite independence
1.4.1. Media Independence
One of the goals of EAP is to allow EAP methods to function on any
lower layer meeting the criteria outlined in [RFC3748], Section 3.1.
For example, as described in [RFC3748], EAP authentication can be run
over PPP [RFC1661], IEEE 802 wired networks [IEEE-802.1X], and IEEE
802.11 wireless LANs [IEEE-802.11i].
In order to maintain media independence, it is necessary for EAP to
avoid inclusion of media-specific elements. For example, EAP methods
cannot be assumed to have knowledge of the lower layer over which
they are transported, and cannot utilize identifiers associated with
a particular usage environment (e.g. MAC addresses).
The need for media independence has also motivated the development of
the three phase exchange. Since discovery is typically media-
specific, this function is handled outside of EAP, rather than being
incorporated within it. Similarly, the Secure Association Protocol
often contains media dependencies such as negotiation of media-
specific ciphersuites or session parameters, and as a result this
functionality also cannot be incorporated within EAP.
Note that media independence may be retained within EAP methods that
support channel binding or method-specific identification. An EAP
method need not be aware of the content of an identifier in order to
use it. This enables an EAP method to use media-specific identifiers
such as MAC addresses without compromising media independence. To
support channel binding, an EAP method can pass binding parameters to
the AAA server in the form of an opaque blob, and receive
confirmation of whether the parameters match, without requiring
media-specific knowledge.
1.4.2. Method Independence
By enabling pass-through, authenticators can support any method
implemented on the peer and server, not just locally implemented
methods. This allows the authenticator to avoid implementing code
for each EAP method required by peers. In fact, since a pass-through
authenticator is not required to implement any EAP methods at all, it
cannot be assumed to support any EAP method-specific code.
As a result, as noted in [RFC3748], authenticators must by default be
capable of supporting any EAP method. Since the Discovery and Secure
Association exchanges are also method independent, an authenticator
can carry out the three phase exchange without having an EAP method
in common with the peer.
This is useful where there is no single EAP method that is both
mandatory-to-implement and offers acceptable security for the media
in use. For example, the [RFC3748] mandatory-to-implement EAP method
(MD5-Challenge) does not provide dictionary attack resistance, mutual
authentication or key derivation, and as a result is not appropriate
for use in wireless LAN authentication [RFC4017]. However, despite
this it is possible for the peer and authenticator to interoperate as
long as a suitable EAP method is supported on the EAP server.
1.4.3. Ciphersuite Independence
While EAP methods may negotiate the ciphersuite used in protection of
the EAP conversation, the ciphersuite used for the protection of the
data exchanged after EAP authentication has completed is negotiated
between the peer and authenticator out-of-band of EAP. Since
ciphersuite negotiation is assumed to occur out-of-band, there is no
need for ciphersuite negotiation within EAP. Since ciphersuite
negotiation occurs outside of EAP, EAP methods generate keying
material that is ciphersuite-independent.
For example, within PPP, the ciphersuite is negotiated within the
Encryption Control Protocol (ECP) defined in [RFC1968], after EAP
authentication is completed. Within [IEEE-802.11i], the AP
ciphersuites are advertised in the Beacon and Probe Responses prior
to EAP authentication, and are securely verified during a 4-way
handshake exchange after EAP authentication has completed.
Advantages of ciphersuite-independence include:
Reduced update requirements
If EAP methods were to specify how to derive transient session keys
for each ciphersuite, they would need to be updated each time a new
ciphersuite is developed. In addition, backend authentication
servers might not be usable with all EAP-capable authenticators,
since the backend authentication server would also need to be
updated each time support for a new ciphersuite is added to the
authenticator.
Reduced EAP method complexity
Requiring each EAP method to include ciphersuite-specific code for
transient session key derivation would increase method complexity
and result in duplicated effort.
Simplified configuration
The ciphersuite is negotiated between the peer and authenticator
out-of-band of EAP. The backend authentication server is neither a
party to this negotiation, nor is it an intermediary in the data
flow between the EAP peer and authenticator. The backend
authentication server may not have knowledge of the ciphersuites
and negotiation policies implemented by the peer and authenticator,
or be aware of the ciphersuite negotiated between them. This
simplifies the configuration of the backend authentication server.
For example, since ECP negotiation occurs after authentication,
when run over PPP, the EAP peer, authenticator and backend
authentication server may not anticipate the negotiated ciphersuite
and therefore this information cannot be provided to the EAP
method.
2. Key Derivation
2.1. Key Terminology
The EAP Key Hierarchy makes use of the following types of keys:
Long Term Credential
EAP methods frequently make use of long term secrets in order to
enable authentication between the peer and server. In the case of
a method based on pre-shared key authentication, the long term
credential is the pre-shared key. In the case of a public-key
based method, the long term credential is the corresponding private
key.
Master Session Key (MSK)
Keying material that is derived between the EAP peer and server and
exported by the EAP method. The MSK is at least 64 octets in
length.
Extended Master Session Key (EMSK)
Additional keying material derived between the peer and server that
is exported by the EAP method. The EMSK is at least 64 octets in
length, and is never shared with a third party.
AAA-Key
A key derived by the peer and EAP server, used by the peer and
authenticator in the derivation of Transient Session Keys (TSKs).
Where a backend authentication server is present, the AAA-Key is
transported from the backend authentication server to the
authenticator, wrapped within the AAA-Token; it is therefore known
by the peer, authenticator and backend authentication server.
Despite the name, the AAA-Key is computed regardless of whether a
backend authentication server is present. AAA-Key derivation is
discussed in Section 2.3; in existing implementations the MSK is
used as the AAA-Key.
AAA-Token
Where a backend server is present, the AAA-Key and one or more
attributes is transported between the backend authentication server
and the authenticator within a package known as the AAA-Token. The
format and wrapping of the AAA-Token, which is intended to be
accessible only to the backend authentication server and
authenticator, is defined by the AAA protocol. Examples include
RADIUS [RFC2548] and Diameter [I-D.ietf-aaa-eap].
Initialization Vector (IV)
A quantity of at least 64 octets, suitable for use in an
initialization vector field, that is derived between the peer and
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
quantity that needs to remain secret. As a result, its use has
been deprecated and EAP methods are not required to generate it.
However, when it is generated it MUST be unpredictable.
Pairwise Master Key (PMK)
The AAA-Key is divided into two halves, the "Peer to Authenticator
Encryption Key" (Enc-RECV-Key) and "Authenticator to Peer
Encryption Key" (Enc-SEND-Key) (reception is defined from the point
of view of the authenticator). Within [IEEE-802.11i] Octets 0-31
of the AAA-Key (Enc-RECV-Key) are known as the Pairwise Master Key
(PMK). In [IEEE-802.11i] the TKIP and AES CCMP ciphersuites derive
their Transient Session Keys (TSKs) solely from the PMK, whereas
the WEP ciphersuite as noted in [RFC3580], derives its TSKs from
both halves of the AAA-Key.
Transient EAP Keys (TEKs)
Session keys which are used to establish a protected channel
between the EAP peer and server during the EAP authentication
exchange. The TEKs are appropriate for use with the ciphersuite
negotiated between EAP peer and server for use in protecting the
EAP conversation. Note that the ciphersuite used to set up the
protected channel between the EAP peer and server during EAP
authentication is unrelated to the ciphersuite used to subsequently
protect data sent between the EAP peer and authenticator. An
example TEK key hierarchy is described in Appendix C.
Transient Session Keys (TSKs)
Session keys used to protect data exchanged between the peer and
the authenticator after the EAP authentication has successfully
completed. TSKs are appropriate for the lower layer ciphersuite
negotiated between the EAP peer and authenticator. Examples of TSK
derivation are provided in Appendix D.
2.2. Key Hierarchy
The EAP Key Hierarchy, illustrated in Figure 3, has at the root the
long term credential utilized by the selected EAP method. If
authentication is based on a pre-shared key, the parties store the
EAP method to be used and the pre-shared key. The EAP server also
stores the peer's identity and/or other information necessary to
decide whether access to some service should be granted. The peer
stores information necessary to choose which secret to use for which
service.
If authentication is based on proof of possession of the private key
corresponding to the public key contained within a certificate, the
parties store the EAP method to be used and the trust anchors used to
validate the certificates. The EAP server also stores the peer's
identity and/or other information necessary to decide whether access
to some service should be granted. The peer stores information
necessary to choose which certificate to use for which service.
Based on the long term credential established between the peer and
the server, EAP derives two types of keys:
[1] Keys calculated locally by the EAP method but not exported
by the EAP method, such as the TEKs.
[2] Keys exported by the EAP method: MSK, EMSK, IV
From the keys exported by the EAP method, two other types of keys may From the keys exported by the EAP method, two other types of keys may
be derived: be derived:
[3] Keys calculated from exported quantities: AAA-Key. [3] Keys calculated from exported quantities: AAA-Key.
[4] Keys calculated by the Secure Association Protocol from the [4] Keys calculated by the Secure Association Protocol from the
AAA-Key: TSKs. AAA-Key: TSKs.
In order to protect the EAP conversation, methods supporting key In order to protect the EAP conversation, methods supporting key
derivation typically negotiate a ciphersuite and derive Transient EAP derivation typically negotiate a ciphersuite and derive Transient EAP
Keys (TEKs) for use with that ciphersuite. The TEKs are stored Keys (TEKs) for use with that ciphersuite. The TEKs are stored
locally by the EAP method and are not exported. locally by the EAP method and are not exported.
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. On both the peer and EAP however, the use of the IV is deprecated. On both the peer and EAP
server, the exported MSK is utilized in order to calculate the AAA- server, the exported MSK is utilized in order to calculate the AAA-
Key, as described in Section 2.3. Where a backend authentication Key. Where a backend authentication server is present, the AAA-Key
server is present, the AAA-Key is transported from the backend is transported from the backend authentication server to the
authentication server to the authenticator within the AAA-Token, authenticator within the AAA-Token, using the AAA protocol.
using the AAA protocol.
Once EAP authentication completes and is successful, the peer and Once EAP authentication completes and is successful, the peer and
authenticator obtain the AAA-Key and the Secure Association Protocol authenticator obtain the AAA-Key and the Secure Association Protocol
is run between the peer and authenticator in order to securely is run between the peer and authenticator in order to securely
negotiate the ciphersuite, derive fresh TSKs used to protect data, negotiate the ciphersuite, derive fresh TSKs used to protect data,
and provide mutual proof of possession of the AAA-Key. and provide mutual proof of possession of the AAA-Key.
When the authenticator acts as an endpoint of the EAP conversation When the authenticator acts as an endpoint of the EAP conversation
rather than a pass-through, EAP methods are implemented on the rather than a pass-through, EAP methods are implemented on the
authenticator as well as the peer. If the EAP method negotiated authenticator as well as the peer. If the EAP method negotiated
between the EAP peer and authenticator supports mutual authentication between the EAP peer and authenticator supports mutual authentication
and key derivation, the EAP Master Session Key (MSK) and Extended and key derivation, the EAP Master Session Key (MSK) and Extended
Master Session Key (EMSK) are derived on the EAP peer and Master Session Key (EMSK) are derived on the EAP peer and
authenticator and exported by the EAP method. In this case, the MSK authenticator and exported by the EAP method. In this case, the MSK
and EMSK are known only to the peer and authenticator and no other and EMSK are known only to the peer and authenticator and no other
parties. The TEKs and TSKs also reside solely on the peer and parties. The TEKs and TSKs also reside solely on the peer and
authenticator. This is illustrated in Figure 4. As demonstrated in authenticator. This is illustrated in Figure 6. As demonstrated in
[I-D.ietf-roamops-cert], in this case it is still possible to support [I-D.ietf-roamops-cert], in this case it is still possible to support
roaming between providers, using certificate-based authentication. roaming between providers, using certificate-based authentication.
Where a backend authentication server is utilized, the situation is Where a backend authentication server is utilized, the situation is
illustrated in Figure 5. Here the authenticator acts as a pass- illustrated in Figure 7. Here the authenticator acts as a pass-
through between the EAP peer and a backend authentication server. In through between the EAP peer and a backend authentication server. In
this model, the authenticator delegates the access control decision this model, the authenticator delegates the access control decision
to the backend authentication server, which acts as a Key to the backend authentication server, which acts as a Key
Distribution Center (KDC). In this case, the authenticator Distribution Center (KDC). In this case, the authenticator
encapsulates EAP packet with a AAA protocol such as RADIUS [RFC3579] encapsulates EAP packet with a AAA protocol such as RADIUS [RFC3579]
or Diameter [I-D.ietf-aaa-eap], and forwards packets to and from the or Diameter [I-D.ietf-aaa-eap], and forwards packets to and from the
backend authentication server, which acts as the EAP server. Since backend authentication server, which acts as the EAP server. Since
the authenticator acts as a pass-through, EAP methods reside only on the authenticator acts as a pass-through, EAP methods reside only on
the peer and EAP server As a result, the TEKs, MSK and EMSK are the peer and EAP server As a result, the TEKs, MSK and EMSK are
derived on the peer and EAP server. derived on the peer and EAP server.
skipping to change at page 17, line 7 skipping to change at page 22, line 25
sends an Access-Accept to the authenticator, providing the AAA-Key sends an Access-Accept to the authenticator, providing the AAA-Key
within a protected package known as the AAA-Token. within a protected package known as the AAA-Token.
The AAA-Key is then used by the peer and authenticator within the The AAA-Key is then used by the peer and authenticator within the
Secure Association Protocol to derive Transient Session Keys (TSKs) Secure Association Protocol to derive Transient Session Keys (TSKs)
required for the negotiated ciphersuite. The TSKs are known only to required for the negotiated ciphersuite. The TSKs are known only to
the peer and authenticator. the peer and authenticator.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | ^ | | ^
| EAP Method | | | EAP Method | Local to |
| | | | | EAP |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | |
| | | | | | |
| | EAP Method Key |<->| Long-Term | | |
| | Derivation | | Credential | | |
| | | | | | |
| | | +-+-+-+-+-+-+-+ | Local to |
| | | | EAP |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Method |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| V | | | |
| +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | | | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | |
| | TEK | | MSK | |EMSK | |IV | | | | | TEK | | MSK | |EMSK | |IV | | |
| |Derivation | |Derivation | |Derivation | |Derivation | | | | |Derivation | |Derivation | |Derivation | |Derivation | | |
| +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | | | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | |
| | | | | |
| | | | | V | | | | | V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | | ^ | | | ^
| | | | | MSK (64B) | EMSK (64B) | IV (64B) Exported|
| MSK (64B) | EMSK (64B) | IV (64B) |
| | | Exported|
| | | by | | | | by |
| V V EAP v | | | EAP |
| V V v
| ---+ | ---+
| AAA-Key Transported | | AAA-Key Transported |
| by AAA | | by AAA |
| Protocol | | Protocol |
V V V V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | ^ | | ^
| TSK Derivation | Lower layer | | TSK Derivation | Lower layer |
| [AAA-Key Cache] | Specific | | [AAA-Key Cache] | Specific |
| | V | | V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
Figure 3: EAP Key Hierarchy Figure 5: Complete Key Hierarchy
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
| | | | | | | |
| | | | | | | |
| Cipher- | | Cipher- | | Cipher- | | Cipher- |
| Suite | | Suite | | Suite | | Suite |
| | | | | | | |
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
^ ^ ^ ^
| | | |
skipping to change at page 18, line 46 skipping to change at page 23, line 46
| | | |
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
| | | | | | | |
| EAP | | EAP | | EAP | | EAP |
| Method | | Method | | Method | | Method |
| | | | | | | |
| (TEKs) | | (TEKs) | | (TEKs) | | (TEKs) |
| | | | | | | |
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
Figure 4: Relationship between EAP peer and authenticator (acting as Figure 6: Relationship between EAP peer and authenticator (acting as
an EAP server), where no backend authentication server is present. an EAP server), where no backend authentication server is present.
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
| | | | | | | |
| | | | | | | |
| Cipher- | | Cipher- | | Cipher- | | Cipher- |
| Suite | | Suite | | Suite | | Suite |
| | | | | | | |
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
^ ^ ^ ^
skipping to change at page 19, line 45 skipping to change at page 24, line 45
| | | |
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
| | | | | | | |
| EAP | | EAP | | EAP | | EAP |
| Method | | Method | | Method | | Method |
| | | | | | | |
| (TEKs) | | (TEKs) | | (TEKs) | | (TEKs) |
| | | | | | | |
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
Figure 5: Pass-through relationship between EAP peer, authenticator Figure 7: Pass-through relationship between EAP peer, authenticator
and backend authentication server. and backend authentication server.
2.3. AAA-Key Derivation 2.5. AAA-Key Derivation and Naming
In existing usage, where a AAA-Key is generated as the result of a In existing usage, where a AAA-Key is generated as the result of a
successful EAP authentication with the authenticator, the AAA-Key is successful EAP authentication with the authenticator, the AAA-Key is
based on the MSK: AAA-Key = MSK(0,63). based on the MSK: AAA-Key = MSK(0,63).
2.4. Key Naming
Each key created within the EAP key management framework has a name
(the identifier by which the key can be identified), as well as a
scope (the parties to whom the key is available). This section
describes how keys are named, and the scope within which that name
applies.
Session-Id
EAP methods supporting key naming MUST specify a temporally unique
method identifier known as the EAP Method-Id, which is typically
constructed from nonces or counters used within the exchange. Since
multiple EAP sessions may exist between an EAP peer and EAP server,
the Method-Id allows MSKs to be differentiated.
The concatenation of the EAP Type (expressed in ASCII text), ":" and
the Method-Id (also expressed in ASCII text) is known as the EAP
Session-Id. The inclusion of the Type in the EAP Session-Id ensures
that each EAP method has a distinct name space.
The EAP Session-Id uniquely identifies the EAP session to the EAP
peer and server terminating the EAP conversation. However, suitable
EAP peer and server names may not always be available. As described
in [RFC3748] Section 7.3, the identity provided in the EAP-
Response/Identity, may be different from the identity authenticated
by the EAP method, and as a result the EAP-Response/Identity is
unsuitable for determination of the peer identity. As a result, the
Session-Id scope is defined by the EAP peer name (if securely
exchanged within the method) concatenated with the EAP server name
(also only if securely exchanged). Where a peer or server name is
missing the null string is used. Since an EAP session is not bound
to a particular authentication or specific ports on the peer and
authenticator, the authenticator port or identity are not included in
the Session-Id scope.
The EAP Session-Id is exported by the EAP method along with the
Session-Id scope, if available, and is used to construct names for
other EAP keys. Note that the EAP Session-Id and scope are only
known by the EAP method. As a result, the format of the EAP Session-
Id and the definition of the Session-Id scope needs to be specified
within the method. Appendix E defines the EAP Session-Id and scope
provided by existing methods.
MSK Name
This key is created between the EAP peer and EAP server, and can be
referred to using the string "MSK:", concatenated with the EAP
Session-Id. As with the EAP Session-Id, the MSK scope is defined by
the EAP peer name (if securely exchanged within the method) and the
EAP server name (also only if securely exchanged). Where a peer or
server name is missing the null string is used.
EMSK Name
The EMSK can be referred to using the string "EMSK:", concatenated
with the EAP Session-Id.
As with the EAP Session-Id, the EMSK scope is defined by the EAP peer
name (if securely exchanged within the method) and the EAP server
name (also only if securely exchanged). Where a peer or server name
is missing the null string is used.
AAA-Key Name
In existing usage, the AAA-Key is always derived from the MSK so can In existing usage, the AAA-Key is always derived from the MSK so can
be referred to using the MSK name. be referred to using the MSK name.
The AAA-Key scope is provided by the concatenation of the EAP peer The AAA-Key scope is provided by the concatenation of the EAP peer
name (if securely provided to the authenticator), and the name (if securely provided to the authenticator), and the
authenticator name (if securely provided to the peer). authenticator name (if securely provided to the peer).
For the purpose of identifying the authenticator to the peer, the For the purpose of identifying the authenticator to the peer, the
value of the NAS-Identifier attribute is recommended. The value of the NAS-Identifier attribute is recommended. The
authenticator may include the NAS-Identifier attribute to the AAA authenticator may include the NAS-Identifier attribute to the AAA
skipping to change at page 22, line 7 skipping to change at page 25, line 38
example, the AAA server may include the EAP peer name in the User- example, the AAA server may include the EAP peer name in the User-
Name attribute of the Access-Accept or the peer may provide the Name attribute of the Access-Accept or the peer may provide the
authenticator with its name via a lower layer mechanism. authenticator with its name via a lower layer mechanism.
Absent an explicit binding step within the Secure Association Absent an explicit binding step within the Secure Association
Protocol, the AAA-Key is not bound to a specific peer or Protocol, the AAA-Key is not bound to a specific peer or
authenticator port. As a result, the peer or authenticator port over authenticator port. As a result, the peer or authenticator port over
which the EAP conversation takes place is not included in the AAA-Key which the EAP conversation takes place is not included in the AAA-Key
scope. scope.
PMK Name 2.5.1. TSKs
This document does not specify a naming scheme for the PMK. The PMK
is only identified by the AAA-Key from which it is derived.
Similarly, the PMK scope is the same as the AAA-Key scope.
Note: IEEE 802.11i names the PMKID for the purposes of being able to
refer to it in the Secure Association protocol; this naming is based
on a hash of the PMK itself as well as some other parameters (see
Section 8.5.1.2 [IEEE-802.11i]).
TEKs
The TEKs may or may not be named. Their naming is specified in the
EAP method. Since the TEKs are only known by the EAP peer and
server, the TEK scope is the same as the Session-Id scope.
TSKs
The TSKs are typically named. Their naming is specified in the Secure The TSKs are typically named. Their naming is specified in the Secure
Association (phase 2) protocol, so that the correct set of transient Association (phase 2) protocol, so that the correct set of transient
session keys can be identified for processing a given packet. The session keys can be identified for processing a given packet. The
scope of the TSKs is negotiated within the Secure Association scope of the TSKs is negotiated within the Secure Association
Protocol. Protocol.
TSK creation and deletion operations are typically supported so that TSK creation and deletion operations are typically supported so that
establishment and re-establishment of TSKs can be synchronized establishment and re-establishment of TSKs can be synchronized
between the parties. between the parties.
skipping to change at page 23, line 17 skipping to change at page 26, line 31
Current EAP server implementations do not retain this SA after the Current EAP server implementations do not retain this SA after the
EAP conversation completes. EAP conversation completes.
[3] AAA SA(s). These SAs are between the authenticator and the backend [3] AAA SA(s). These SAs are between the authenticator and the backend
authentication server. They permit the parties to mutually authentication server. They permit the parties to mutually
authenticate each other and protect the communications between authenticate each other and protect the communications between
them. them.
[4] Service SA(s). These SAs are between the peer and authenticator, [4] Service SA(s). These SAs are between the peer and authenticator,
and they are created as a result of phases 1-2 of the conversation and they are created as a result of phases 1-2 of the conversation
(see Section 1.3). (see Section 2).
Examples of security associations are provided in Appendix F. Examples of security associations are provided in Appendix F.
3.1. EAP Method SA (peer - EAP server) 3.1. EAP Method SA (peer - EAP server)
An EAP method may store some state on the peer and EAP server even An EAP method may store some state on the peer and EAP server even
after phase 1a has completed. after phase 1a has completed.
Typically, this is used for "fast reconnect": the peer and EAP server Typically, this is used for "fast reconnect": the peer and EAP server
can confirm that they are still talking to the same party, perhaps can confirm that they are still talking to the same party, perhaps
skipping to change at page 27, line 7 skipping to change at page 30, line 22
This option usually requires some protocol for transferring the This option usually requires some protocol for transferring the
service SA between the elements. An administrator may decide not to service SA between the elements. An administrator may decide not to
enable this feature at all, and typically the sharing is restricted enable this feature at all, and typically the sharing is restricted
to some particular service elements (defined either by a service to some particular service elements (defined either by a service
parameter, or simple administrative decision). If the old and new parameter, or simple administrative decision). If the old and new
service element do not support such "context transfer", this service element do not support such "context transfer", this
approach falls back to the previous option (no transfer). approach falls back to the previous option (no transfer).
Services supporting this feature should also consider what changes Services supporting this feature should also consider what changes
require new authorization from the backend authentication server require new authorization from the backend authentication server
(see Section 4.2). (see Section 5.2).
Note that these considerations are not limited to service Note that these considerations are not limited to service
parameters related to the authenticator--they apply to peer parameters related to the authenticator--they apply to peer
parameters as well. parameters as well.
4. Key Management 4. Key Management
EAP supports key derivation, but not key management. As a result, EAP supports key derivation, but not key management. As a result,
key management functionality needs to be provided by the Secure key management functionality needs to be provided by the Secure
Association Protocol. This includes: Association Protocol. This includes:
skipping to change at page 32, line 7 skipping to change at page 35, line 17
The lower layer may utilize Discovery mechanisms to assist in this. The lower layer may utilize Discovery mechanisms to assist in this.
For example, the authenticator manages the AAA-Key cache by deleting For example, the authenticator manages the AAA-Key cache by deleting
the oldest AAA-Key first (LIFO), the relative creation time of the the oldest AAA-Key first (LIFO), the relative creation time of the
last AAA-Key to be deleted could be advertised with the Discovery last AAA-Key to be deleted could be advertised with the Discovery
phase, enabling the peer to determine whether a given AAA-Key had phase, enabling the peer to determine whether a given AAA-Key had
been expired from the authenticator key cache prematurely. been expired from the authenticator key cache prematurely.
4.6. Key Scope 4.6. Key Scope
As described in Section 2.3, in existing applications the AAA-Key is As described in Section 2.5, in existing applications the AAA-Key is
derived from the MSK by the EAP peer and server, and is used as the derived from the MSK by the EAP peer and server, and is used as the
root of the ciphersuite-specific key hierarchy. Where a backend root of the ciphersuite-specific key hierarchy. Where a backend
authentication server is present, the AAA-Key is transported from the authentication server is present, the AAA-Key is transported from the
EAP server to the authenticator; where it is not present, the AAA-Key EAP server to the authenticator; where it is not present, the AAA-Key
is calculated on the authenticator. is calculated on the authenticator.
Regardless of how many sessions are initiated using it, the AAA-Key Regardless of how many sessions are initiated using it, the AAA-Key
scope is between the EAP peer that calculates it, and the scope is between the EAP peer that calculates it, and the
authenticator that either calculates it (where no backend authenticator that either calculates it (where no backend
authenticator is present) or receives it from the server (where a authenticator is present) or receives it from the server (where a
skipping to change at page 40, line 12 skipping to change at page 43, line 21
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.
[3] An attacker may attempt to perform downgrading attacks on the [3] An attacker may attempt to perform downgrading attacks on the
ciphersuite negotiation within the Secure Association Protocol in ciphersuite negotiation within the Secure Association Protocol in
order to ensure that a weaker ciphersuite is used to protect data. order to ensure that a weaker ciphersuite is used to protect data.
Depending on the lower layer, these attacks may be carried out Depending on the lower layer, these attacks may be carried out
without requiring physical proximity. without requiring physical proximity.
In order to address these threats, [Housley56] describes the In order to address these threats, [Housley] describes the mandatory
mandatory system security properties: system security properties:
Algorithm independence Algorithm independence
Wherever cryptographic algorithms are chosen, the algorithms must Wherever cryptographic algorithms are chosen, the algorithms must
be negotiable, in order to provide resilient against compromise of be negotiable, in order to provide resilient against compromise of
a particular algorithm. Algorithm independence must be a particular algorithm. Algorithm independence must be
demonstrated within all aspects of the system, including within demonstrated within all aspects of the system, including within
EAP, AAA and the Secure Association Protocol. However, for EAP, AAA and the Secure Association Protocol. However, for
interoperability, at least one suite of algorithms MUST be interoperability, at least one suite of algorithms MUST be
implemented. implemented.
skipping to change at page 41, line 10 skipping to change at page 44, line 20
Domino effect Domino effect
Compromise of a single authenticator cannot compromise any other Compromise of a single authenticator cannot compromise any other
part of the system, including session keys and long-term secrets. part of the system, including session keys and long-term secrets.
Key binding Key binding
The key must be bound to the appropriate context. The key must be bound to the appropriate context.
6.3. Security Analysis 6.3. Security Analysis
Figure 6 illustrates the relationship between the peer, authenticator Figure 8 illustrates the relationship between the peer, authenticator
and backend authentication server. and backend authentication server.
EAP peer EAP peer
/\ /\
/ \ / \
Protocol: EAP / \ Protocol: Secure Association Protocol: EAP / \ Protocol: Secure Association
Auth: Mutual / \ Auth: Mutual Auth: Mutual / \ Auth: Mutual
Unique keys: / \ Unique keys: TSKs Unique keys: / \ Unique keys: TSKs
TEKs,EMSK / \ TEKs,EMSK / \
/ \ / \
EAP server +--------------+ Authenticator EAP server +--------------+ Authenticator
Protocol: AAA Protocol: AAA
Auth: Mutual Auth: Mutual
Unique key: AAA session key Unique key: AAA session key
Figure 6: Relationship between peer, authenticator and auth. server Figure 8: Relationship between peer, authenticator and auth. server
The peer and EAP server communicate using EAP [RFC3748]. The The peer and EAP server communicate using EAP [RFC3748]. The
security properties of this communication are largely determined by security properties of this communication are largely determined by
the chosen EAP method. Method security claims are described in the chosen EAP method. Method security claims are described in
[RFC3748] Section 7.2. These include the key strength, protected [RFC3748] Section 7.2. These include the key strength, protected
ciphersuite negotiation, mutual authentication, integrity protection, ciphersuite negotiation, mutual authentication, integrity protection,
replay protection, confidentiality, key derivation, key strength, replay protection, confidentiality, key derivation, key strength,
dictionary attack resistance, fast reconnect, cryptographic binding, dictionary attack resistance, fast reconnect, cryptographic binding,
session independence, fragmentation and channel binding claims. At a session independence, fragmentation and channel binding claims. At a
minimum, methods claiming to support key derivation must also support minimum, methods claiming to support key derivation must also support
skipping to change at page 48, line 15 skipping to change at page 51, line 27
The MSK and EMSK MUST NOT be used directly to protect data; however, The MSK and EMSK MUST NOT be used directly to protect data; however,
they are of sufficient size to enable derivation of a AAA-Key they are of sufficient size to enable derivation of a AAA-Key
subsequently used to derive Transient Session Keys (TSKs) for use subsequently used to derive Transient Session Keys (TSKs) for use
with the selected ciphersuite. Each ciphersuite is responsible for with the selected ciphersuite. Each ciphersuite is responsible for
specifying how to derive the TSKs from the AAA-Key. specifying how to derive the TSKs from the AAA-Key.
The AAA-Key is derived from the keying material exported by the EAP The AAA-Key is derived from the keying material exported by the EAP
method (MSK and EMSK). This derivation occurs on the AAA server. In method (MSK and EMSK). This derivation occurs on the AAA server. In
many existing protocols that use EAP, the AAA-Key and MSK are many existing protocols that use EAP, the AAA-Key and MSK are
equivalent, but more complicated mechanisms are possible (see Section equivalent, but more complicated mechanisms are possible.
2.3 for details).
EAP methods SHOULD ensure the freshness of the MSK and EMSK even in EAP methods SHOULD ensure the freshness of the MSK and EMSK even in
cases where one party may not have a high quality random number cases where one party may not have a high quality random number
generator. A RECOMMENDED method is for each party to provide a nonce generator. A RECOMMENDED method is for each party to provide a nonce
of at least 128 bits, used in the derivation of the MSK and EMSK. of at least 128 bits, used in the derivation of the MSK and EMSK.
EAP methods export the MSK and EMSK and not Transient Session Keys so EAP methods export the MSK and EMSK and not Transient Session Keys so
as to allow EAP methods to be ciphersuite and media independent. as to allow EAP methods to be ciphersuite and media independent.
Keying material exported by EAP methods MUST be independent of the Keying material exported by EAP methods MUST be independent of the
ciphersuite negotiated to protect data. ciphersuite negotiated to protect data.
skipping to change at page 54, line 27 skipping to change at page 57, line 38
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October Considerations Section in RFCs", BCP 26, RFC 2434, October
1998. 1998.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H.
Lefkowetz, "Extensible Authentication Protocol (EAP)", RFC Lefkowetz, "Extensible Authentication Protocol (EAP)", RFC
3748, June 2004. 3748, June 2004.
9.2. Informative References 9.2. Informative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
1661, July 1994.
[RFC1968] Meyer, G. and K. Fox, "The PPP Encryption Control Protocol
(ECP)", RFC 1968, June 1996.
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997.
[RFC2246] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A.
and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246,
January 1999.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[RFC2419] Sklower, K. and G. Meyer, "The PPP DES Encryption Protocol,
Version 2 (DESE-bis)", RFC 2419, September 1998.
[RFC2420] Kummert, H., "The PPP Triple-DES Encryption Protocol (3DESE)",
RFC 2420, September 1998.
[RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D. and
R. Wheeler, "A Method for Transmitting PPP Over Ethernet
(PPPoE)", RFC 2516, February 1999.
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC
2548, March 1999.
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
Implementation in Roaming", RFC 2607, June 1999.
[RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol",
RFC 2716, October 1999.
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, June
2000.
[RFC3078] Pall, G. and G. Zorn, "Microsoft Point-To-Point Encryption
(MPPE) Protocol", RFC 3078, March 2001.
[RFC3079] Zorn, G., "Deriving Keys for use with Microsoft Point-to-Point
Encryption (MPPE)", RFC 3079, March 2001.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial
In User Service) Support For Extensible Authentication
Protocol (EAP)", RFC 3579, September 2003.
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese,
"IEEE 802.1X Remote Authentication Dial In User Service
(RADIUS) Usage Guidelines", RFC 3580, September 2003.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public
Keys Used For Exchanging Symmetric Keys", RFC 3766, April
2004.
[RFC4017] Stanley, D., Walker, J. and B. Aboba, "EAP Method Requirements
for Wireless LANs", RFC 4017, March 2005.
[CTP] Loughney, J., Nakhjiri, M., Perkins, C. and R. Koodli, [CTP] Loughney, J., Nakhjiri, M., Perkins, C. and R. Koodli,
"Context Transfer Protocol", draft-ietf-seamoby-ctp-11.txt, "Context Transfer Protocol", draft-ietf-seamoby-ctp-11.txt,
Internet draft (work in progress), August 2004. Internet draft (work in progress), August 2004.
[DESMODES] [DESMODES]
National Institute of Standards and Technology, "DES Modes of National Institute of Standards and Technology, "DES Modes of
Operation", FIPS PUB 81, December 1980, <http:// Operation", FIPS PUB 81, December 1980, <http://
www.itl.nist.gov/fipspubs/fip81.htm>. www.itl.nist.gov/fipspubs/fip81.htm>.
[FIPSDES] National Institute of Standards and Technology, "Data [FIPSDES] National Institute of Standards and Technology, "Data
Encryption Standard", FIPS PUB 46, January 1977. Encryption Standard", FIPS PUB 46, January 1977.
[IEEE-802] [Housley] Housley, R. and B. Aboba, "AAA Key Management", draft-housley-
Institute of Electrical and Electronics Engineers, "IEEE aaa-key-mgmt-00.txt, Internet draft (work in progress), June
Standards for Local and Metropolitan Area Networks: Overview 2005..IP [IEEE-802] Institute of Electrical and Electronics
and Architecture", ANSI/IEEE Standard 802, 1990. Engineers, "IEEE Standards for Local and Metropolitan Area
Networks: Overview and Architecture", ANSI/IEEE Standard 802,
1990.
[IEEE-802.11] [IEEE-802.11]
Institute of Electrical and Electronics Engineers, Institute of Electrical and Electronics Engineers,
"Information technology - Telecommunications and information "Information technology - Telecommunications and information
exchange between systems - Local and metropolitan area exchange between systems - Local and metropolitan area
networks - Specific Requirements Part 11: Wireless LAN Medium networks - Specific Requirements Part 11: Wireless LAN Medium
Access Control (MAC) and Physical Layer (PHY) Specifications", Access Control (MAC) and Physical Layer (PHY) Specifications",
IEEE IEEE Standard 802.11-2003, 2003. IEEE IEEE Standard 802.11-2003, 2003.
[IEEE-802.1X] [IEEE-802.1X]
skipping to change at page 57, line 44 skipping to change at page 59, line 33
Problem", draft-puthenkulam-eap-binding-04 (work in progress), Problem", draft-puthenkulam-eap-binding-04 (work in progress),
October 2003. October 2003.
[I-D.arkko-pppext-eap-aka] [I-D.arkko-pppext-eap-aka]
Arkko, J. and H. Haverinen, "EAP AKA Authentication", draft- Arkko, J. and H. Haverinen, "EAP AKA Authentication", draft-
arkko-pppext-eap-aka-15.txt (work in progress), December 2004. arkko-pppext-eap-aka-15.txt (work in progress), December 2004.
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", draft- [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", draft-
ietf-ipsec-ikev2-17 (work in progress), September 2004. ietf-ipsec-ikev2-17 (work in progress), September 2004.
[MD5Attack]
Dobbertin, H., "The Status of MD5 After a Recent Attack",
CryptoBytes, Vol.2 No.2, 1996.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
1661, July 1994.
[RFC1968] Meyer, G. and K. Fox, "The PPP Encryption Control Protocol
(ECP)", RFC 1968, June 1996.
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997.
[RFC2246] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A.
and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246,
January 1999.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[RFC2419] Sklower, K. and G. Meyer, "The PPP DES Encryption Protocol,
Version 2 (DESE-bis)", RFC 2419, September 1998.
[RFC2420] Kummert, H., "The PPP Triple-DES Encryption Protocol (3DESE)",
RFC 2420, September 1998.
[RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D. and
R. Wheeler, "A Method for Transmitting PPP Over Ethernet
(PPPoE)", RFC 2516, February 1999.
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC
2548, March 1999.
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
Implementation in Roaming", RFC 2607, June 1999.
[RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol",
RFC 2716, October 1999.
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, June
2000.
[RFC3078] Pall, G. and G. Zorn, "Microsoft Point-To-Point Encryption
(MPPE) Protocol", RFC 3078, March 2001.
[RFC3079] Zorn, G., "Deriving Keys for use with Microsoft Point-to-Point
Encryption (MPPE)", RFC 3079, March 2001.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial
In User Service) Support For Extensible Authentication
Protocol (EAP)", RFC 3579, September 2003.
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese,
"IEEE 802.1X Remote Authentication Dial In User Service
(RADIUS) Usage Guidelines", RFC 3580, September 2003.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public
Keys Used For Exchanging Symmetric Keys", RFC 3766, April
2004.
[RFC4017] Stanley, D., Walker, J. and B. Aboba, "EAP Method Requirements
for Wireless LANs", RFC 4017, March 2005.
[8021XHandoff] [8021XHandoff]
Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff in a Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff in a
Public Wireless LAN Based on IEEE 802.1X Model", School of Public Wireless LAN Based on IEEE 802.1X Model", School of
Computer Science and Engineering, Seoul National University, Computer Science and Engineering, Seoul National University,
Seoul, Korea, 2002. Seoul, Korea, 2002.
[MD5Attack]
Dobbertin, H., "The Status of MD5 After a Recent Attack",
CryptoBytes, Vol.2 No.2, 1996.
[Housley56]
Housley, R., "Key Management in AAA", Presentation to the AAA
WG at IETF 56,
http://www.ietf.org/proceedings/03mar/slides/aaa-5/index.html,
March 2003.
Acknowledgments Acknowledgments
Thanks to Arun Ayyagari, Ashwin Palekar, and Tim Moore of Microsoft, Thanks to Arun Ayyagari, Ashwin Palekar, and Tim Moore of Microsoft,
Dorothy Stanley of Agere, Bob Moskowitz of TruSecure, Jesse Walker of Dorothy Stanley of Agere, Bob Moskowitz of TruSecure, Jesse Walker of
Intel, Joe Salowey of Cisco and Russ Housley of Vigil Security for Intel, Joe Salowey of Cisco and Russ Housley of Vigil Security for
useful feedback. useful feedback.
Author Addresses Author Addresses
Bernard Aboba Bernard Aboba
skipping to change at page 65, line 5 skipping to change at page 68, line 5
TKIP uses X = 64, while CCMP, WRAP, and WEP use X = 48. TKIP uses X = 64, while CCMP, WRAP, and WEP use X = 48.
The EAPOL-Key Confirmation Key (KCK) is used to provide data origin The EAPOL-Key Confirmation Key (KCK) is used to provide data origin
authenticity in the TSK derivation. It utilizes the first 128 bits authenticity in the TSK derivation. It utilizes the first 128 bits
(bits 0-127) of the PTK. The EAPOL-Key Encryption Key (KEK) provides (bits 0-127) of the PTK. The EAPOL-Key Encryption Key (KEK) provides
confidentiality in the TSK derivation. It utilizes bits 128-255 of confidentiality in the TSK derivation. It utilizes bits 128-255 of
the PTK. Bits 256-383 of the PTK are used by Temporal Key 1, and Bits the PTK. Bits 256-383 of the PTK are used by Temporal Key 1, and Bits
384-511 are used by Temporal Key 2. Usage of TK1 and TK2 is 384-511 are used by Temporal Key 2. Usage of TK1 and TK2 is
ciphersuite specific. Details are available in [IEEE-802.11i]. ciphersuite specific. Details are available in [IEEE-802.11i].
Appendix E - Key Names and Scope in Existing Methods Appendix E - Exported Parameters in Existing Methods
This appendix specifies the key names and scope in methods that have This Appendix specifies Method-ID, Peer-ID, Server-ID and Key-
been published prior to the publication of this RFC. What is needed Lifetime for EAP methods that have been published prior to this
in addition to the rules in Section 2.4 is the definition of what EAP specification. Future EAP method specifications MUST include a
peer and server names are used, what Method-Id is used, and how these definition of the Method-ID, Peer-ID, and Server-ID (could be the
are encoded. empty string) and MAY also define the Key-Lifetime (assumed to be
indeterminate if not described).
EAP-TLS EAP-Identity
The EAP-TLS Method-Id is provided by the concatenation of the peer The EAP-Identity method does not derive keys, and therefore does
and server nonces. not define the Key-Lifetime or Method-ID. The Peer-ID exported by
the Identity method is determined by the octets included within
the EAP- Response/Identity. The Server-ID is the empty string
(zero length).
Where certificates are used, the Session-Id scope is determined via EAP-Notification
the EAP peer and server names, deduced from the altSubjectName in the
peer and server certificates.
Issue: What happens if a pre-shaked key ciphersuite is negotiated? The EAP-Notification method does not derive keys and therefore
How are the EAP peer and server names determined? does not define the Key-Lifetime and Method-ID. The Peer-ID and
Server-ID are the empty string (zero length).
EAP-AKA EAP-GTC
The EAP-AKA Method-Id is the contents of the RAND field from the The EAP-GTC method does not derive keys and therefore does not
AT_RAND attribute, followed by the contents of the AUTN field in the define the Key-Lifetime and Method-ID. The Peer-ID and Server-ID
AT_AUTN attribute. are the empty string.
The EAP peer name is the contents of the Identity field from the EAP-OTP
AT_IDENTITY attribute, using only the Actual Identity Length octets
from the beginning, however. Note that the contents are used as they
are transmitted, regardless of whether the transmitted identity was a
permanent, pseudonym, or fast reauthentication identity. The EAP
server name is an empty string.
EAP-SIM The EAP-OTP method does not derive keys and therefore does not
define the Key-Lifetime and Method-ID. The Peer-ID and Server-ID
are the empty string.
The Method-Id is the contents of the RAND field from the AT_RAND EAP-TLS
attribute, followed by the contents of the NONCE_MT field in the
AT_NONCE_MT attribute.
The EAP peer name is the contents of the Identity field from the The EAP-TLS Method-Id is the concatenation of the peer and server
AT_IDENTITY attribute, using only the Actual Identity Length octets nonces.
from the beginning, however. Note that the contents are used as they
are transmitted, regardless of whether the transmitted identity was a The Peer-ID and Server-ID are the contents of the altSubjectName
permanent, pseudonym, or fast reauthentication identity. The EAP in the peer and server certificates.
server name is an empty string.
EAP-TLS does not negotiate a Key-Lifetime.
EAP-AKA
The EAP-AKA Method-Id is the contents of the RAND field from the
AT_RAND attribute, followed by the contents of the AUTN field in
the AT_AUTN attribute.
The Peer-ID is the contents of the Identity field from the
AT_IDENTITY attribute, using only the Actual Identity Length
octets from the beginning, however. Note that the contents are
used as they are transmitted, regardless of whether the
transmitted identity was a permanent, pseudonym, or fast
reauthentication identity. The Server- ID is an empty string.
EAP-AKA does not negotiate a key lifetime.
EAP-SIM
The Method-Id is the contents of the RAND field from the AT_RAND
attribute, followed by the contents of the NONCE_MT field in the
AT_NONCE_MT attribute.
The Peer-ID is the contents of the Identity field from the
AT_IDENTITY attribute, using only the Actual Identity Length
octets from the beginning, however. Note that the contents are
used as they are transmitted, regardless of whether the
transmitted identity was a permanent, pseudonym, or fast
reauthentication identity. The Server- ID is an empty string.
EAP-SIM does not negotiate a key lifetime.
Appendix F - Security Association Examples Appendix F - Security Association Examples
EAP Method SA Example: EAP-TLS EAP Method SA Example: EAP-TLS
In EAP-TLS [RFC2716], after the EAP authentication the client (peer) In EAP-TLS [RFC2716], after the EAP authentication the client (peer)
and server can store the following information: and server can store the following information:
o Implicitly, the EAP method this SA refers to (EAP-TLS) o Implicitly, the EAP method this SA refers to (EAP-TLS)
o Session identifier (a value selected by the server) o Session identifier (a value selected by the server)
skipping to change at page 69, line 38 skipping to change at page 73, line 38
- Lifetime information - Lifetime information
- Protocol mode (tunnel or transport) - Protocol mode (tunnel or transport)
The correct SA is looked up based on SPI (for inbound packets), or The correct SA is looked up based on SPI (for inbound packets), or
SPD traffic selectors (for outbound traffic). A separate IPsec SA SPD traffic selectors (for outbound traffic). A separate IPsec SA
exists for each direction. exists for each direction.
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 or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be
standards-related documentation can be found in BCP-11. Copies of found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification can attempt made to obtain a general license or permission for the use of
be obtained from the IETF Secretariat. such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository 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 any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at ietf-
Director. 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 an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
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/eapissues.html
 End of changes. 59 change blocks. 
548 lines changed or deleted 710 lines changed or added

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