draft-ietf-eap-keying-07.txt   draft-ietf-eap-keying-08.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-07.txt> J. Arkko <draft-ietf-eap-keying-08.txt> J. Arkko
17 July 2005 Ericsson 23 October 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, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 January 22, 2006. This Internet-Draft will expire on April 22, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society 2005. 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 .......................................... 3
1.1 Requirements Language ........................... 4 1.1 Requirements Language ........................... 3
1.2 Terminology ..................................... 4 1.2 Terminology ..................................... 3
1.3 Overview ........................................ 7 1.3 Overview ........................................ 5
1.4 EAP Invariants .................................. 14 1.4 EAP Invariants .................................. 9
2. Lower Layer Operation ................................. 16 2. Lower Layer Operation ................................. 13
2.1 Discovery Phase ................................. 18 2.1 Overview ........................................ 13
2.2 Authentication Phase ............................ 18 2.2 Layering ........................................ 14
2.3 Secure Association Phase ........................ 19 2.3 Caching ......................................... 17
2.4 Lower Layer Key Hierarchy ....................... 21 2.4 Key Scope ....................................... 18
2.5 AAA-Key Derivation and Naming ................... 24 3. Key Management ........................................ 21
3. Security associations ................................. 26 3.1 Secure Association Protocol ..................... 22
3.1 EAP Method SA ................................... 26 3.2 Parent-Child Relationships ...................... 24
3.2 EAP-Key SA ...................................... 27 3.3 Local Key Lifetimes ............................. 25
3.3 AAA SA(s) ....................................... 27 3.4 Exported and Calculated Key Lifetimes ........... 25
3.4 Service SA(s) ................................... 27 3.5 Key Cache Synchronization ....................... 27
4. Key Management ........................................ 30 3.6 Key Strength .................................... 27
4.1 Key Caching ..................................... 31 3.7 Key Wrap ........................................ 28
4.2 Parent-Child Relationships ...................... 32 4. Handoff Vulnerabilities ............................... 29
4.3 Local Key Lifetimes ............................. 32 4.1 Authorization ................................... 29
4.4 Exported and Calculated Key Lifetimes ........... 33 4.2 Correctness ..................................... 30
4.5 Key Cache Synchronization ....................... 34 5. Security Considerations .............................. 33
4.6 Key Scope ....................................... 35 5.1 Security Terminology ............................ 34
4.7 Key Strength .................................... 36 5.2 Threat Model .................................... 34
4.8 Key Wrap ........................................ 37 5.3 Authenticator Compromise ........................ 35
5. Handoff Vulnerabilities ............................... 38 5.4 Spoofing ........................................ 36
5.1 Authorization ................................... 38 5.5 Downgrade Attacks ............................... 36
5.2 Correctness ..................................... 39 5.6 Unauthorized Disclosure ......................... 37
6. Security Considerations .............................. 42 5.7 Replay Protection ............................... 38
6.1 Security Terminology ............................ 42 5.8 Key Freshness ................................... 39
6.2 Threat Model .................................... 42 5.9 Elevation of Privilege .......................... 40
6.3 Security Analysis ............................... 44 5.10 Man-in-the-Middle Attacks ....................... 41
6.4 Man-in-the-middle Attacks ....................... 47 5.11 Denial of Service Attacks ....................... 41
6.5 Denial of Service Attacks ....................... 48 5.12 Impersonation ................................... 42
6.6 Impersonation ................................... 48 5.13 Channel Binding ................................. 43
6.7 Channel Binding ................................. 50 6. IANA Considerations ................................... 44
7. Security Requirements ................................. 50 7. References ............................................ 44
7.1 EAP Method Requirements ......................... 51 7.1 Normative References ............................ 44
7.2 AAA Protocol Requirements ....................... 53 7.2 Informative References .......................... 45
7.3 Secure Association Protocol Requirements ........ 55 Acknowledgments .............................................. 49
7.4 Ciphersuite Requirements ........................ 56 Author's Addresses ........................................... 49
8. IANA Considerations ................................... 57 Appendix A - EAP-TLS Key Hierarchy ........................... 51
9. References ............................................ 57 Appendix B - Exported Parameters in Existing Methods ......... 53
9.1 Normative References ............................ 57 Intellectual Property Statement .............................. 54
9.2 Informative References .......................... 57 Disclaimer of Validity ....................................... 55
Acknowledgments .............................................. 61 Copyright Statement .......................................... 55
Author's Addresses ........................................... 61
Appendix A - Ciphersuite Keying Requirements ................. 63
Appendix B - Example Transient EAP Key (TEK) Hierarchy ....... 64
Appendix C - EAP-TLS Key Hierarchy ........................... 65
Appendix D - Example Transient Session Key (TSK) Derivation .. 67
Appendix E - Exported Parameters in Existing Methods ......... 68
Appendix F - Security Association Examples ................... 70
Intellectual Property Statement .............................. 73
Disclaimer of Validity ....................................... 74
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 6 skipping to change at page 4, line 6
[IEEE-802.1X]. In this document, this end of the link is called [IEEE-802.1X]. In this document, this end of the link is called
the peer. the peer.
backend authentication server backend authentication server
A backend authentication server is an entity that provides an A backend authentication server is an entity that provides an
authentication service to an authenticator. When used, this server authentication service to an authenticator. When used, this server
typically executes EAP methods for the authenticator. This typically executes EAP methods for the authenticator. This
terminology is also used in [IEEE-802.1X]. terminology is also used in [IEEE-802.1X].
AAA Authentication, Authorization and Accounting. AAA protocols with AAA Authentication, Authorization and Accounting. AAA protocols with
EAP support include RADIUS [RFC3579] and Diameter [I-D.ietf-aaa- EAP support include RADIUS [RFC3579] and Diameter [RFC4072]. In
eap]. In this document, the terms "AAA server" and "backend this document, the terms "AAA server" and "backend authentication
authentication server" are used interchangeably. server" are used interchangeably.
EAP server EAP server
The entity that terminates the EAP authentication method with the The entity that terminates the EAP authentication method with the
peer. In the case where no backend authentication server is used, peer. In the case where no backend authentication server is used,
the EAP server is part of the authenticator. In the case where the the EAP server is part of the authenticator. In the case where the
authenticator operates in pass-through mode, the EAP server is authenticator operates in pass-through mode, the EAP server is
located on the backend authentication server. located on the backend authentication server.
security association security association
A set of policies and cryptographic state used to protect A set of policies and cryptographic state used to protect
skipping to change at page 5, line 51 skipping to change at page 4, line 51
Initialization Vector (IV) Initialization Vector (IV)
A quantity of at least 64 octets, suitable for use in an A quantity of at least 64 octets, suitable for use in an
initialization vector field, that is derived between the peer and initialization vector field, that is derived between the peer and
EAP server. Since the IV is a known value in methods such as EAP- EAP server. Since the IV is a known value in methods such as EAP-
TLS [RFC2716], it cannot be used by itself for computation of any TLS [RFC2716], it cannot be used by itself for computation of any
quantity that needs to remain secret. As a result, its use has quantity that needs to remain secret. As a result, its use has
been deprecated and EAP methods are not required to generate it. been deprecated and EAP methods are not required to generate it.
However, when it is generated it MUST be unpredictable. However, when it is generated it MUST be unpredictable.
Pairwise Master Key (PMK) Pairwise Master Key (PMK)
The AAA-Key is divided into two halves, the "Peer to Authenticator The MSK is divided into two halves, the "Peer to Authenticator
Encryption Key" (Enc-RECV-Key) and "Authenticator to Peer Encryption Key" (Enc-RECV-Key) and "Authenticator to Peer
Encryption Key" (Enc-SEND-Key) (reception is defined from the point Encryption Key" (Enc-SEND-Key) (reception is defined from the point
of view of the authenticator). Within [IEEE-802.11i] Octets 0-31 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 of the MSK (Enc-RECV-Key) are known as the Pairwise Master Key
(PMK). In [IEEE-802.11i] the TKIP and AES CCMP ciphersuites derive (PMK). In [IEEE-802.11i] the TKIP and AES CCMP ciphersuites derive
their Transient Session Keys (TSKs) solely from the PMK, whereas their Transient Session Keys (TSKs) solely from the PMK, whereas
the WEP ciphersuite as noted in [RFC3580], derives its TSKs from the WEP ciphersuite as noted in [RFC3580], derives its TSKs from
both halves of the AAA-Key. both halves of the MSK.
Transient EAP Keys (TEKs) Transient EAP Keys (TEKs)
Session keys which are used to establish a protected channel Session keys which are used to establish a protected channel
between the EAP peer and server during the EAP authentication between the EAP peer and server during the EAP authentication
exchange. The TEKs are appropriate for use with the ciphersuite exchange. The TEKs are appropriate for use with the ciphersuite
negotiated between EAP peer and server for use in protecting the negotiated between EAP peer and server for use in protecting the
EAP conversation. Note that the ciphersuite used to set up the EAP conversation. The TEKs are stored locally by the EAP method
and are not exported. Note that the ciphersuite used to set up the
protected channel between the EAP peer and server during EAP protected channel between the EAP peer and server during EAP
authentication is unrelated to the ciphersuite used to subsequently authentication is unrelated to the ciphersuite used to subsequently
protect data sent between the EAP peer and authenticator. An protect data sent between the EAP peer and authenticator. An
example TEK key hierarchy is described in Appendix C. example TEK key hierarchy is described in Appendix A.
Transient Session Keys (TSKs) Transient Session Keys (TSKs)
Session keys used to protect data exchanged between a port of the Session keys used to protect data exchanged in a session between
peer and a port of the authenticator after the EAP authentication the peer and authenticator after the EAP authentication has
has successfully completed. TSKs are appropriate for the lower successfully completed. TSKs are appropriate for the lower layer
layer ciphersuite negotiated between the ports of the EAP peer and ciphersuite negotiated between the ports of the EAP peer and
authenticator. Examples of TSK derivation are provided in Appendix authenticator. Examples of TSK derivation are provided in Appendix
D. B.
AAA-Key AAA-Key
A key derived by the peer and EAP server, used by the peer and A key derived by the peer and EAP server, used by the peer and
authenticator in the derivation of Transient Session Keys (TSKs). authenticator in the derivation of Transient Session Keys (TSKs).
Where a backend authentication server is present, the AAA-Key is Where a backend authentication server is present, the AAA-Key is
transported from the backend authentication server to the transported from the backend authentication server to the
authenticator, wrapped within the AAA-Token; it is therefore known authenticator. In existing usage, the AAA-Key is always derived
by the peer, authenticator and backend authentication server. from the MSK and so can be referred to using the MSK name. AAA-Key
Despite the name, the AAA-Key is computed regardless of whether a = MSK(0,63).
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, defined in [RFC3748], is a two-party protocol spoken between the
EAP peer and server. Within EAP, keying material is generated by EAP EAP peer and server. Within EAP, keying material is generated by EAP
methods. Part of this keying material may be used by EAP methods methods. Part of this keying material may be used by EAP methods
themselves and part of this material may be exported. In addition to themselves and part of this material may be exported. In addition to
export of keying material, EAP methods may also export associated export of keying material, EAP methods may also export associated
parameters, and may import and export Channel Bindings from the lower parameters, and may import and export Channel Bindings from the lower
layer. layer.
As illustrated in Figure 1, the EAP method key derivation has at the As illustrated in Figure 1, the EAP method key derivation has at the
root the long term credential utilized by the selected EAP method. root the long term credential utilized by the selected EAP method.
If authentication is based on a pre-shared key, the parties store the If authentication is based on a pre-shared key, the parties store the
skipping to change at page 8, line 5 skipping to change at page 6, line 32
[1] Keys calculated locally by the EAP method but not exported [1] Keys calculated locally by the EAP method but not exported
by the EAP method, such as the TEKs. by the EAP method, such as the TEKs.
[2] Keying material exported by the EAP method: MSK, EMSK, IV. [2] Keying material exported by the EAP method: MSK, EMSK, IV.
As noted in [RFC3748] Section 7.10, EAP methods generating keys are As noted in [RFC3748] Section 7.10, EAP methods generating keys are
required to calculate and export the MSK and EMSK, which must be at required to calculate and export the MSK and EMSK, which must be at
least 64 octets in length. EAP methods also may export the IV; least 64 octets in length. EAP methods also may export the IV;
however, the use of the IV is deprecated. however, the use of the IV is deprecated.
EAP methods also MAY export method-specific peer and server
identifiers (peer-ID and server-ID), a method-specific EAP
conversation identifier known as the 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.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | ^ | | ^
| EAP Method | | | EAP Method | |
| | | | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | |
| | | | | | | | | | | | | |
| | EAP Method Key |<->| Long-Term | | | | | EAP Method Key |<->| Long-Term | | |
| | Derivation | | Credential | | | | | Derivation | | Credential | | |
| | | | | | | | | | | | | |
| | | +-+-+-+-+-+-+-+ | Local to | | | | +-+-+-+-+-+-+-+ | Local to |
skipping to change at page 8, line 36 skipping to change at page 7, line 36
| | | | | | | | | | | |
| | ^ | | | V | | ^ | | | V
+-+-|-+-+-+-+-+-+-+-+-|-+-+-+-+-+-|-+-+-+-+-+-+-+-+-|-+-+-+ ---+ +-+-|-+-+-+-+-+-+-+-+-|-+-+-+-+-+-|-+-+-+-+-+-+-+-+-|-+-+-+ ---+
| | | | ^ | | | | ^
| Peer-ID, | | | Exported| | Peer-ID, | | | Exported|
| Server-ID, | Channel | MSK (64+B) | IV (64B) by | | Server-ID, | Channel | MSK (64+B) | IV (64B) by |
| Method-ID, | Bindings | EMSK (64+B) | EAP | | Method-ID, | Bindings | EMSK (64+B) | EAP |
| Key-Lifetime | & Result | | Method | | Key-Lifetime | & Result | | Method |
V V V V V V V V V V
Figure 1: EAP Parameter Import/Export Figure 1: EAP Method Parameter Import/Export
EAP methods also MAY export method-specific peer and server
identifiers (peer-ID and server-ID), a method-specific EAP
conversation identifier known as the 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 Peer-ID
As described in [RFC3748] Section 7.3, the identity provided in As described in [RFC3748] Section 7.3, the identity provided in the
the EAP-Response/Identity, may be different from the peer identity EAP-Response/Identity, may be different from the peer identity
authenticated by the EAP method. Where the EAP method authenticated by the EAP method. Where the EAP method authenticates
authenticates the peer identity, that identity is exported by the the peer identity, that identity is exported by the method as the
method as the Peer-ID. A suitable EAP peer name may not always be Peer-ID. A suitable EAP peer name may not always be available.
available. Where an EAP method does not define a method-specific Where an EAP method does not define a method-specific peer identity,
peer identity, the Peer-ID is the null string. The Peer-ID for the Peer-ID is the null string. The Peer-ID for existing EAP
existing EAP methods is defined in Appendix E. methods is defined in Appendix B.
Server-ID Server-ID
Where the EAP method authenticates the server identity, that Where the EAP method authenticates the server identity, that identity
identity is exported by the method as the Server-ID. A suitable is exported by the method as the Server-ID. A suitable EAP server
EAP server name may not always be available. Where an EAP method name may not always be available. Where an EAP method does not
does not define a method-specific peer identity, the Server-ID is define a method-specific peer identity, the Server-ID is the null
the null string. The Server-ID for existing EAP methods is string. The Server-ID for existing EAP methods is defined in
defined in Appendix E. Appendix B.
Method-ID Method-ID
EAP method specifications deriving keys MUST specify a temporally EAP method specifications deriving keys MUST specify a temporally
unique method identifier known as the Method-ID. The EAP Method- unique method identifier known as the Method-ID. The EAP Method-ID
ID uniquely identifies an EAP session of a given Type between an uniquely identifies an EAP session of a given Type between an EAP
EAP peer and server. The Method-ID is typically constructed from peer and server. The Method-ID is typically constructed from nonces
nonces or counters used within the EAP method exchange. The or counters used within the EAP method exchange. The Method-ID for
Method-ID for existing EAP methods is defined in Appendix E. existing EAP methods is defined in Appendix B.
Session-ID Session-ID
The Session-ID uniquely identifies an EAP session between an EAP The Session-ID uniquely identifies an EAP session between an EAP peer
peer (as identified by the Peer-ID) and server (as identified by (as identified by the Peer-ID) and server (as identified by the
the Server-ID). The EAP Session-ID consists of the concatenation Server-ID). The EAP Session-ID consists of the concatenation of the
of the Expanded EAP Type Code (including the Type, Vendor-ID and Expanded EAP Type Code (including the Type, Vendor-ID and Vendor-Type
Vendor-Type fields defined in [RFC3748] Section 5.7) and the fields defined in [RFC3748] Section 5.7) and the Method-ID. The
Method-ID. The inclusion of the Expanded Type Code in the EAP inclusion of the Expanded Type Code in the EAP Session-Id ensures
Session-Id ensures that each EAP method has a distinct Session-ID that each EAP method has a distinct Session-ID space. Since an EAP
space. Since an EAP session is not bound to a particular session is not bound to a particular authenticator or specific ports
authenticator or specific ports on the peer and authenticator, the on the peer and authenticator, the authenticator port or identity are
authenticator port or identity are not included in the Session-Id. not included in the Session-Id.
Key-Lifetime Key-Lifetime
While EAP itself does not support key lifetime negotiation, it is While EAP itself does not support key lifetime negotiation, it is
possible to specify methods that do. However, systems that rely possible to specify methods that do. However, systems that rely on
on such negotiation for exported keys would only function with such negotiation for exported keys would only function with these
these methods. As a result, it is NOT RECOMMENDED to use this methods. As a result, it is NOT RECOMMENDED to use this approach as
approach as the sole way to determine key lifetimes. the sole way to determine key lifetimes.
Channel Bindings Channel Bindings
Channel Bindings include lower layer parameters that are verified Channel Bindings include lower layer parameters that are verified for
for consistency between the EAP peer and server. In order to consistency between the EAP peer and server. In order to avoid
avoid introducing media dependencies, EAP methods MUST treat introducing media dependencies, EAP methods that transport Channel
Channel Bindings as opaque octets. Typically the EAP method Binding data MUST treat this data as opaque octets. Typically the
imports Channel Bindings from the lower layer on the peer, and EAP method imports Channel Bindings from the lower layer on the peer,
transmits them securely to the EAP server, which exports them to and transmits them securely to the EAP server, which exports them to
the lower layer. However, transport may occur from EAP server 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 peer, or may be bi-directional. On the side of the exchange (peer or
or server) where Channel Bindings are verified, the lower layer server) where Channel Bindings are verified, the lower layer passes
passes the result of the verification (TRUE or FALSE) up to the the result of the verification (TRUE or FALSE) up to the EAP method.
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 1.3.1. Key Naming
Each key created within the EAP key management framework has a name Each key created within the EAP key management framework has a name
(the identifier by which the key can be identified), as well as a (a unique identifier), as well as a scope (the parties to whom the
scope (the parties to whom the key is available). The scope of key is available). The scope of exported parameters is defined by
exported parameters is defined by the EAP peer name (if securely the EAP peer name (if securely exchanged within the method) and the
exchanged within the method) and the EAP server name (also only if EAP server name (also only if securely exchanged). Where a peer or
securely exchanged). Where a peer or server name is missing the null server name is missing the null string is used.
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 MSK, EMSK and IV Names
Use of the IV is deprecated. However, if necessary the IV can be These parameters are exported by the EAP peer and EAP server, and
referred to using the string "IV:" concatenated with the EAP can be referred to using the EAP Session-ID and a binary or textual
Session-ID. indication of the parameter being referred to.
PMK Name PMK Name
This document does not specify a naming scheme for the PMK. The This document does not specify a naming scheme for the PMK. The
PMK is only identified by the key from which it is derived. PMK is only identified by the key from which it is derived.
Note: IEEE 802.11i names the PMKID for the purposes of being able Note: IEEE 802.11i names the PMKID for the purposes of being able
to refer to it in the Secure Association protocol; this naming is to refer to it in the Secure Association protocol; this naming is
based on a hash of the PMK itself as well as some other parameters based on a hash of the PMK itself as well as some other parameters
(see Section 8.5.1.2 [IEEE-802.11i]). (see Section 8.5.1.2 [IEEE-802.11i]).
TEK Name TEK Name
The TEKs may or may not be named. Their naming is specified in the The TEKs may or may not be named. Their naming is specified in the
EAP method. EAP method.
1.3.3. EAP and AAA TSK Name
The TSKs are typically named. Their naming is specified in the
EAP is typically deployed in order to support extensible network lower layer so that the correct set of transient session keys can
access authentication in situations where a peer desires network be identified for processing a given packet.
access via one or more authenticators. Since both the peer and
authenticator may have more than one physical or logical port, a
given peer may simultaneously access the network via multiple
authenticators, or via multiple physical or logical ports on a given
authenticator. Similarly, an authenticator may offer network access
to multiple peers, each via a separate physical or logical port. The
situation is illustrated in Figure 3.
Where authenticators are deployed standalone, the EAP conversation
occurs between the peer and authenticator, and the authenticator must
locally implement an EAP method acceptable to the peer. However, one
of the advantages of EAP is that it enables deployment of new
authentication methods without requiring development of new code on
the authenticator. While the authenticator may implement some EAP
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
methods, forwarding EAP packets back and forth between the backend
authentication server and the peer.
This is accomplished by encapsulating EAP packets within the
Authentication, Authorization and Accounting (AAA) protocol, spoken
between the authenticator and backend authentication server. AAA
protocols supporting EAP include RADIUS [RFC3579] and Diameter [I-
D.ietf-aaa-eap].
+-+-+-+-+
| |
| EAP |
| Peer |
| |
+-+-+-+-+
| | | Peer Ports
/ | \
/ | \
/ | \
/ | \
/ | \
/ | \
/ | \
/ | \
| | | | | | | | | Authenticator Ports
+-+-+-+-+ +-+-+-+-+ +-+-+-+-+
| | | | | |
| Auth. | | Auth. | | Auth. |
| | | | | |
+-+-+-+-+ +-+-+-+-+ +-+-+-+-+
\ | /
\ | /
\ | /
EAP over AAA \ | /
(optional) \ | /
\ | /
\ | /
\ | /
+-+-+-+-+
| |
| AAA |
|Server |
| |
+-+-+-+-+
Figure 3: Relationship between peer, authenticator and backend server
1.4. EAP Invariants 1.4. EAP Invariants
Certain basic characteristics, known as "EAP Invariants", hold true Certain basic characteristics, known as "EAP Invariants", hold true
for EAP implementations on all media: for EAP implementations on all media:
Mode independence Mode independence
Media independence Media independence
Method independence Method independence
Ciphersuite independence Ciphersuite independence
1.4.1. Mode Independence 1.4.1. Mode Independence
EAP as defined in [RFC3748] is a two party protocol spoken between EAP is typically deployed in order to support extensible network
the EAP peer and server. A fundamental property of EAP is that at access authentication in situations where a peer desires network
the EAP method layer, the conversation between the EAP peer and access via one or more authenticators. Where authenticators are
server is unaffected by whether the EAP authenticator is operating in deployed standalone, the EAP conversation occurs between the peer and
"pass-through" mode. authenticator, and the authenticator must locally implement an EAP
method acceptable to the peer. However, one of the advantages of EAP
is that it enables deployment of new authentication methods without
requiring development of new code on the authenticator.
EAP methods operate identically in all aspects, including key While the authenticator may implement some EAP methods locally and
derivation and parameter import/export, regardless of whether the use those methods to authenticate local users, it may at the same
authenticator is operating as a pass-through or not. time act as a pass-through for other users and methods, forwarding
EAP packets back and forth between the backend authentication server
and the peer. This is accomplished by encapsulating EAP packets
within the Authentication, Authorization and Accounting (AAA)
protocol, spoken between the authenticator and backend authentication
server. AAA protocols supporting EAP include RADIUS [RFC3579] and
Diameter [RFC4072].
It is a fundamental property of EAP that at the EAP method layer, the
conversation between the EAP peer and server is unaffected by whether
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 The successful completion of an EAP method that supports key
derivation results in the export of keying material on the EAP peer derivation results in the export of keying material on the EAP peer
and server. Even though the EAP peer or server may import Channel- and server. Even though the EAP peer or server may import Channel-
Bindings that may include the identity of the EAP authenticator, Bindings that may include the identity of the EAP authenticator,
this information is treated as opaque octets. As a result, within this information is treated as opaque octets. As a result, within
EAP the only relevant identities are the Peer-ID and Server-ID. EAP the only relevant identities are the Peer-ID and Server-ID.
Channel Bindings are only interpreted by the lower layer. Channel Bindings are only interpreted by the lower layer.
Within EAP, the primary function of the AAA protocol is to maintain Within EAP, the primary function of the AAA protocol is to maintain
skipping to change at page 15, line 43 skipping to change at page 11, line 43
1.4.4. Ciphersuite Independence 1.4.4. Ciphersuite Independence
Ciphersuite Independence is a consequence of the principles of Mode Ciphersuite Independence is a consequence of the principles of Mode
Independence and Media Independence. Independence and Media Independence.
While EAP methods may negotiate the ciphersuite used in protection of While EAP methods may negotiate the ciphersuite used in protection of
the EAP conversation, the ciphersuite used for the protection of the the EAP conversation, the ciphersuite used for the protection of the
data exchanged after EAP authentication has completed is negotiated data exchanged after EAP authentication has completed is negotiated
between the peer and authenticator within the lower layer, outside of between the peer and authenticator within the lower layer, outside of
EAP. Since the ciphersuites used to protect data depend on the lower EAP.
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 For example, within PPP, the ciphersuite is negotiated within the
Encryption Control Protocol (ECP) defined in [RFC1968], after EAP Encryption Control Protocol (ECP) defined in [RFC1968], after EAP
authentication is completed. Within [IEEE-802.11i], the AP authentication is completed. Within [IEEE-802.11i], the AP
ciphersuites are advertised in the Beacon and Probe Responses prior ciphersuites are advertised in the Beacon and Probe Responses prior
to EAP authentication, and are securely verified during a 4-way to EAP authentication, and are securely verified during a 4-way
handshake exchange. handshake exchange.
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 Independence.
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.
Algorithms for deriving TSKs MUST NOT depend on the EAP method,
although algorithms for TEK derivation MAY be specific to the EAP
method.
In order to allow a ciphersuite to be usable within the EAP keying
framework, a specification MUST be provided describing how TSKs
suitable for use with the ciphersuite are derived from exported EAP
keying parameters.
Advantages of ciphersuite-independence include: Advantages of ciphersuite-independence include:
Reduced update requirements Reduced update requirements
If EAP methods were to specify how to derive transient session keys 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 for each ciphersuite, they would need to be updated each time a new
ciphersuite is developed. In addition, backend authentication ciphersuite is developed. In addition, backend authentication
servers might not be usable with all EAP-capable authenticators, servers might not be usable with all EAP-capable authenticators,
since the backend authentication server would also need to be since the backend authentication server would also need to be
updated each time support for a new ciphersuite is added to the updated each time support for a new ciphersuite is added to the
authenticator. authenticator.
skipping to change at page 16, line 41 skipping to change at page 13, line 7
As a result, the EAP server may not have knowledge of the As a result, the EAP server may not have knowledge of the
ciphersuites and negotiation policies implemented by the peer and ciphersuites and negotiation policies implemented by the peer and
authenticator, or be aware of the ciphersuite negotiated between authenticator, or be aware of the ciphersuite negotiated between
them. For example, since ECP negotiation occurs after them. For example, since ECP negotiation occurs after
authentication, when run over PPP, the EAP peer and server may not authentication, when run over PPP, the EAP peer and server may not
anticipate the negotiated ciphersuite and therefore this anticipate the negotiated ciphersuite and therefore this
information cannot be provided to the EAP method. information cannot be provided to the EAP method.
2. Lower Layer Operation 2. Lower Layer Operation
2.1. Overview
Where EAP key derivation is supported, the conversation typically Where EAP key derivation is supported, the conversation typically
takes place in three phases: takes place in three phases:
Phase 0: Discovery Phase 0: Discovery
Phase 1: Authentication Phase 1: Authentication
1a: EAP authentication 1a: EAP authentication
1b: AAA-Key Transport (optional) 1b: AAA Key Transport (optional)
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)
Of these phases, Phase 0, 1b and Phase 2 are handled by a lower Of these phases, Phase 0, 1b and Phase 2 are handled by a lower
layer. In the discovery phase (phase 0), peers locate layer. In the discovery phase (phase 0), peers locate
authenticators and discover their capabilities. For example, a peer authenticators and discover their capabilities. A peer may locate an
may locate an authenticator providing access to a particular network, authenticator providing access to a particular network, or a peer may
or a peer may locate an authenticator behind a bridge with which it locate an authenticator behind a bridge with which it desires to
desires to establish a Secure Association. establish a Secure Association. Discovery can occur manually or
automatically, depending on the lower layer over which EAP runs.
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, if it occurs, always
authentication (phase 1a). Where the chosen EAP method supports key includes EAP authentication (phase 1a). Where the chosen EAP method
derivation, in phase 1a keying material is derived on both the peer supports key derivation, in phase 1a EAP keying material is derived
and the EAP server. This keying material may be used for multiple on both the peer and the EAP server.
purposes, including protection of the EAP conversation and subsequent
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 from the backend authentication server to the authenticator.
server to the authenticator. In order to obey the principle of Mode Independence, where a backend
server is present AAA Key transport needs to provide the exported EAP
keying material and/or derived keys required for derivation of the
TSKs. Since existing TSK derivation techniques depend solely on the
MSK, in existing AAA implementations, this is the only keying
material replicated in the AAA key transport phase 1b.
A Secure Association exchange (phase 2) then occurs between the peer Successful completion of EAP authentication and key derivation by a
and authenticator in order to manage the creation and deletion of peer and EAP server does not necessarily imply that the peer is
unicast (phase 2a) and multicast (phase 2b) security associations committed to joining the network associated with an EAP server.
between the peer and authenticator. Rather, this commitment is implied by the creation of a security
association between the EAP peer and authenticator, as part of the
Secure Association Protocol (phase 2).
The conversation phases and relationship between the parties is shown The Secure Association exchange (phase 2) occurs between the peer and
in Figure 4. authenticator in order to manage the creation and deletion of unicast
(phase 2a) and multicast (phase 2b) security associations between the
peer and authenticator. The conversation between the parties is
shown in Figure 2.
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 4: Conversation Overview Figure 2: Conversation Overview
2.1. Discovery Phase
In the discovery phase (phase 0), the EAP peer and authenticator
locate each other and discover each other's capabilities. Discovery
can occur manually or automatically, depending on the lower layer
over which EAP runs. Since authenticator discovery is handled
outside of EAP, there is no need to provide this functionality within
EAP.
For example, where EAP runs over PPP, the EAP peer might be
configured with a phone book providing phone numbers of
authenticators and associated capabilities such as supported rates,
authentication protocols or ciphersuites. In contrast, PPPoE
[RFC2516] provides support for a Discovery Stage to allow a peer to
identify the Ethernet MAC address of one or more authenticators and
establish a PPPoE SESSION_ID.
IEEE 802.11 [IEEE-802.11] also provides integrated discovery support
utilizing Beacon and/or Probe Request/Response frames, allowing the
peer (known as the station or STA) to determine the MAC address and
capabilities of one or more authenticators (known as Access Point or
APs).
2.2. Authentication Phase
Once the peer and authenticator discover each other, they exchange
EAP packets. Typically, the peer desires access to the network, and
the authenticators provide that access. In such a situation, access
to the network can be provided by any authenticator attaching to the
desired network, and the EAP peer is typically willing to send data
traffic through any authenticator that can demonstrate that it is
authorized to provide access to the desired network.
An EAP authenticator may handle the authentication locally, or it may
act as a pass-through to a backend authentication server. In the
latter case the EAP exchange occurs between the EAP peer and a
backend authenticator server, with the authenticator forwarding EAP
packets between the two. The entity which terminates EAP
authentication with the peer is known as the EAP server. Where pass-
through is supported, the backend authentication server functions as
the EAP server; where authentication occurs locally, the EAP server
is the authenticator. Where a backend authentication server is
present, at the successful completion of an authentication exchange,
the AAA-Key is transported to the authenticator (phase 1b).
EAP may also be used when it is desired for two network devices (e.g.
two switches or routers) to authenticate each other, or where two
peers desire to authenticate each other and set up a secure
association suitable for protecting data traffic.
Some EAP methods exist which only support one-way authentication;
however, EAP methods deriving keys are required to support mutual
authentication. In either case, it can be assumed that the parties
do not utilize the link to exchange data traffic unless their
authentication requirements have been met. For example, a peer
completing mutual authentication with an EAP server will not send
data traffic over the link until the EAP server has authenticated
successfully to the peer, and a Secure Association has been
negotiated.
Since EAP is a peer-to-peer protocol, an independent and simultaneous
authentication may take place in the reverse direction. Both peers
may act as authenticators and authenticatees at the same time.
Successful completion of EAP authentication and key derivation by a
peer and EAP server does not necessarily imply that the peer is
committed to joining the network associated with an EAP server.
Rather, this commitment is implied by the creation of a security
association between the EAP peer and authenticator, as part of the
Secure Association Protocol (phase 2). As a result, EAP may be used
for "pre-authentication" in situations where it is necessary to pre-
establish EAP security associations in order to decrease handoff or
roaming latency.
2.3. Secure Association Phase
The Secure Association phase (phase 2), if it occurs, begins after
the completion of EAP authentication (phase 1a) and key transport
(phase 1b). A Secure Association Protocol used with EAP typically
supports the following features:
[1] Generation of fresh transient session keys (TSKs). Where AAA-Key
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
derived from a portion of the AAA-Key, this would result in reuse
of the session keys which could expose the underlying ciphersuite
to attack.
As a result, where AAA-Key caching is supported, the Secure
Association Protocol phase is REQUIRED, and MUST provide for
freshness of the TSKs. This is typically handled via the exchange
of nonces or counters, which are then mixed with the AAA-Key in
order to generate fresh unicast (phase 2a) and possibly multicast
(phase 2b) session keys. By not using the AAA-Key directly to
protect data, the Secure Association Protocol protects against
compromise of the AAA-Key.
[2] Entity Naming. A basic feature of a Secure Association Protocol is
the explicit naming of the parties engaged in the exchange.
Explicit identification of the parties is critical, since without
this the parties engaged in the exchange are not identified and the
scope of the transient session keys (TSKs) generated during the
exchange is undefined. As illustrated in Figure 3, both the peer
and NAS may have more than one physical or virtual port, so that
port identifiers are NOT RECOMMENDED as a naming mechanism.
[3] Secure capabilities negotiation. This includes the secure
negotiation of usage modes, session parameters (such as key
lifetimes), ciphersuites and required filters, including
confirmation of the capabilities discovered during phase 0. It is
RECOMMENDED that the Secure Association Protocol support secure
capabilities negotiation, in order to protect against spoofing
during the discovery phase, and to ensure agreement between the
peer and authenticator about how data is to be secured.
[4] Key management. EAP as defined in [RFC3748] supports key
derivation, but not key management. While EAP methods may derive
keying material, EAP does provide for the management of exported or
derived keys. For example, EAP does not support negotiation of the
key lifetime of exported or derived keys, nor does it support
rekey. Although EAP methods may support "fast reconnect" as
defined in [RFC3748] Section 7.2.1, rekey of exported keys cannot
occur without reauthentication. In order to provide method
independence, key management of exported or derived keys SHOULD NOT
be provided within EAP methods.
Since neither EAP nor EAP methods provide key management support,
it is RECOMMENDED that key management facilities be provided within
the Secure Association Protocol. This includes key lifetime
management (such as via explicit key lifetime negotiation, or
seamless rekey), as well synchronization of the installation and
deletion of keys so as to enable recovery from partial or complete
loss of key state by the peer or authenticator. Since key
management requires a key naming scheme, Secure Association
Protocols supporting key management support MUST also support key
naming.
[5] Mutual proof of possession of the AAA-Key. The Secure Association
Protocol MUST demonstrate mutual proof of posession of the AAA-Key,
in order to show that both the peer and authenticator have been
authenticated and authorized by the backend authentication server.
Since mutual proof of possession is not the same as mutual
authentication, the peer cannot verify authenticator assertions
(including the authenticator identity) as a result of this
exchange.
2.4. Lower Layer Key Hierarchy 2.2. Layering
From the keys exported by the EAP method, two other types of keys may In completion of EAP authentication, EAP methods on the peer and EAP
be derived: server export the Master Session Key (MSK), Extended Master Session
Key (EMSK), Initialization Vector (IV), Peer-ID, Server-ID, Session-
ID and Key-Lifetime. As illustrated in Figure 3, EAP methods export
keying material and parameters to the EAP peer or authenticator
layers.
[3] Keys calculated from exported quantities: AAA-Key. The EAP peer and authenticator layers MUST NOT modify or cache keying
[4] Keys calculated by the Secure Association Protocol from the material or parameters (including Channel Bindings) passing in either
AAA-Key: TSKs. direction between the EAP method layer and the EAP layer. The EAP
layer also MUST NOT cache keying material or parameters (including
Channel Bindings) passed to it by the EAP peer/authenticator layer or
the lower layer.
In order to protect the EAP conversation, methods supporting key Based on the Method-ID exported by the EAP method, the EAP layer
derivation typically negotiate a ciphersuite and derive Transient EAP forms the EAP Session-ID by concatenating the EAP Expanded Type with
Keys (TEKs) for use with that ciphersuite. The TEKs are stored the Method-ID. Together with the MSK, IV (deprecated), Peer-ID,
locally by the EAP method and are not exported. Server-ID, and Key-Lifetime, the EAP layer passes the Session-ID down
to the lower layer.
As noted in [RFC3748] Section 7.10, EAP methods generating keys are The EMSK MUST NOT be provided to the lower layer, nor is it permitted
required to calculate and export the MSK and EMSK, which must be at to pass any quantity to the lower layer from which the EMSK could be
least 64 octets in length. EAP methods also may export the IV; computed without breaking some cryptographic assumption, such as
however, the use of the IV is deprecated. On both the peer and EAP inverting a one-way function. As noted in [RFC3748] Section 7.10:
server, the exported MSK is utilized in order to calculate the AAA-
Key. Where a backend authentication server is present, the AAA-Key
is transported from the backend authentication server to the
authenticator within the AAA-Token, using the AAA protocol.
Once EAP authentication completes and is successful, the peer and The EMSK is reserved for future use and MUST remain on the EAP
authenticator obtain the AAA-Key and the Secure Association Protocol peer and EAP server where it is derived; it MUST NOT be
is run between the peer and authenticator in order to securely transported to, or shared with, additional parties, or used to
negotiate the ciphersuite, derive fresh TSKs used to protect data, derive any other keys. (This restriction will be relaxed in a
and provide mutual proof of possession of the AAA-Key. future document that specifies how the EMSK can be used.)
When the authenticator acts as an endpoint of the EAP conversation The Method-ID is exported by EAP methods rather than the Session-ID
rather than a pass-through, EAP methods are implemented on the so as to prevent EAP methods from writing into each other's Session-
authenticator as well as the peer. If the EAP method negotiated ID space.
between the EAP peer and authenticator supports mutual authentication
and key derivation, the EAP Master Session Key (MSK) and Extended
Master Session Key (EMSK) are derived on the EAP peer and
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
parties. The TEKs and TSKs also reside solely on the peer and
authenticator. This is illustrated in Figure 6. As demonstrated in
[I-D.ietf-roamops-cert], in this case it is still possible to support
roaming between providers, using certificate-based authentication.
Where a backend authentication server is utilized, the situation is In order to preserve the security of keys derived within EAP methods,
illustrated in Figure 7. Here the authenticator acts as a pass- lower layers other than AAA MUST NOT export keys passed down by EAP
through between the EAP peer and a backend authentication server. In methods. This implies that EAP keying material or parameters passed
this model, the authenticator delegates the access control decision down to a lower layer are for the exclusive use of that lower layer
to the backend authentication server, which acts as a Key and MUST NOT be used within another lower layer. This prevents
Distribution Center (KDC). In this case, the authenticator compromise of one lower layer from compromising other applications
encapsulates EAP packet with a AAA protocol such as RADIUS [RFC3579] using EAP keying parameters.
or Diameter [I-D.ietf-aaa-eap], and forwards packets to and from the
backend authentication server, which acts as the EAP server. Since
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
derived on the peer and EAP server.
On completion of EAP authentication, EAP methods on the peer and EAP EAP keying material and parameters provided to a lower layer other
server export the Master Session Key (MSK) and Extended Master than AAA MUST NOT be transported to another entity. For example, EAP
Session Key (EMSK). The peer and EAP server then calculate the AAA- keying material and parameters passed down to the EAP peer lower
Key from the MSK and EMSK, and the backend authentication server layer MUST NOT leave the peer; EAP keying material and parameters
sends an Access-Accept to the authenticator, providing the AAA-Key passed down or transported to the EAP authenticator lower layer MUST
within a protected package known as the AAA-Token. NOT leave the authenticator.
The AAA-Key is then used by the peer and authenticator within the The exception to the "no sharing" rule is the AAA layer. On EAP
Secure Association Protocol to derive Transient Session Keys (TSKs) server, keying material requested by and passed down to the AAA layer
required for the negotiated ciphersuite. The TSKs are known only to may be replicated to the AAA layer on the authenticator. On the
the peer and authenticator. authenticator, the AAA layer may provide the replicated keying
material to the lower layer over which the EAP authentication
conversation took place. This enables "mode independence" to be
maintained.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ As illustrated in Figure 4, a AAA client receiving transported EAP
| | ^ keying material and parameters passes them to the EAP authenticator
| EAP Method | Local to | and EAP layers, which then provide them to the authenticator lower
| | EAP | layer using the same mechanisms that would be used if the EAP peer
| +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | | and authenticator were conducting a stand-alone conversation. The
| | TEK | | MSK | |EMSK | |IV | | | resulting key state in the lower layer is indistinguishable between
| |Derivation | |Derivation | |Derivation | |Derivation | | | the standalone and pass-through cases, as required by the principle
| +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | | of mode independence. In order to prevent the compromise of
| | | | | V transported EAP keying material and parameters, the AAA client and
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ EAP authenticator MUST be co-resident.
| | | ^
| MSK (64B) | EMSK (64B) | IV (64B) Exported|
| | | by |
| | | EAP |
| V V v
| ---+
| AAA-Key Transported |
| by AAA |
| Protocol |
V V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | ^
| TSK Derivation | Lower layer |
| [AAA-Key Cache] | Specific |
| | V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
Figure 5: Complete Key Hierarchy +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+ +-+-+-+-+-+
| | | |
| | | |
| Cipher- | | Cipher- |
| Suite | | Suite |
| | | |
+-+-+-+-+-+ +-+-+-+-+-+
^ ^
| |
| |
| | | |
V V
+-+-+-+-+-+ +-+-+-+-+-+
| | | |
| |===============| |
| |EAP, TEK Deriv.|Authenti-|
| |<------------->| cator |
| | | |
| | Secure Assoc. | |
| peer |<------------->| (EAP |
| |===============| server) |
| | Link layer | |
| | (PPP,IEEE802) | |
| | | |
|MSK,EMSK | |MSK,EMSK |
| (TSKs) | | (TSKs) |
+-+-+-+-+-+ +-+-+-+-+-+
^ ^
| | | |
| MSK, EMSK | MSK, EMSK | EAP method |
| | | |
| MSK, EMSK, IV, Channel |
| Peer-ID, Server-ID, Bindings |
| Method-ID, |
| Key-Lifetime |
| | | |
+-+-+-+-+-+ +-+-+-+-+-+ | V ^ ^ |
| | | | +-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+
| EAP | | EAP | | ! ! ! |
| Method | | Method | | EAP ! Peer or Authenticator ! ! |
| | | | | ! layer ! ! |
| (TEKs) | | (TEKs) | | ! ! ! |
| | | | +-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+
+-+-+-+-+-+ +-+-+-+-+-+ | ! ! ! |
| EAP ! layer ! ! |
| ! ! ! |
| ! Session-ID = ! ! |
| ! Expanded-Type || ! ! |
| ! Method-ID ! ! |
| ! ! ! |
+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+
| ! ! ! |
| Lower ! layer ! ! |
| ! ! ! |
| V V ^ |
| MSK, IV, Peer-ID, Channel Result |
| Server-ID, Bindings |
| Session-ID, |
| Key-Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Relationship between EAP peer and authenticator (acting as Figure 3: Flow of EAP parameters
an EAP server), where no backend authentication server is present. Peer Pass-through Authenticator Authentication
Server
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+
| | | |
| | | |
| Cipher- | | Cipher- |
| Suite | | Suite |
| | | |
+-+-+-+-+-+ +-+-+-+-+-+
^ ^
| |
| |
| |
V V
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
| |===============| |========| |
| |EAP, TEK Deriv.| | | |
| |<-------------------------------->| backend |
| | | |AAA-Key/| |
| | Secure Assoc. | | Name | |
| peer |<------------->|Authenti-|<-------| auth |
| |===============| cator |========| server |
| | Link Layer | | AAA | (EAP |
| | (PPP,IEEE 802)| |Protocol| server) |
| | | | | |
|MSK,EMSK | | MSK | |MSK,EMSK |
| (TSKs) | | (TSKs) | | |
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
^ ^
| |
| MSK, EMSK | MSK, EMSK
| |
| |
+-+-+-+-+-+ +-+-+-+-+-+
| | | |
| EAP | | EAP |
| Method | | Method |
| | | |
| (TEKs) | | (TEKs) |
| | | | | | | |
+-+-+-+-+-+ +-+-+-+-+-+ |EAP method | |EAP method |
| V | | V |
Figure 7: Pass-through relationship between EAP peer, authenticator +-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+
and backend authentication server. | ! | |EAP | EAP | | | ! |
| ! | |Peer | Auth.| EAP Auth. | | ! |
2.5. AAA-Key Derivation and Naming |EAP ! peer| | | +-----------+ | |EAP !Auth.|
| ! | | | ! | ! | | ! |
In existing usage, where a AAA-Key is generated as the result of a +-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+
successful EAP authentication with the authenticator, the AAA-Key is | ! | | ! | ! | | ! |
based on the MSK: AAA-Key = MSK(0,63). |EAP !layer| | EAP !layer| EAP !layer | |EAP !layer|
| ! | | ! | ! | | ! |
In existing usage, the AAA-Key is always derived from the MSK so can +-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+
be referred to using the MSK name. | V | | V | ! | | ! |
|Lower layer| | Lower layer| AAA ! /IP | | AAA ! /IP |
The AAA-Key scope is provided by the concatenation of the EAP peer | | | | ! | | ! |
name (if securely provided to the authenticator), and the +-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+
authenticator name (if securely provided to the peer). ! !
! !
For the purpose of identifying the authenticator to the peer, the +---------<-------+
value of the NAS-Identifier attribute is recommended. The
authenticator may include the NAS-Identifier attribute to the AAA
server in an Access-Request, and the authenticator may provide the
NAS-Identifier to the EAP peer. Mechanisms for this include use of
the EAP-Request/Identity (unsecured) or a lower layer mechanism (such
as the 802.11 Beacon/Probe Response). Where the NAS-Identifier is
provided by the authenticator to the peer a secure mechanism is
RECOMMENDED.
For the purpose of identifying the peer to the authenticator, the EAP
peer identifier provided within the EAP method is recommended. It
cannot be assumed that the authenticator is aware of the EAP peer
name used within the method. Therefore alternatives mechanisms need
to be used to provide the EAP peer name to the authenticator. For
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
authenticator with its name via a lower layer mechanism.
Absent an explicit binding step within the Secure Association
Protocol, the AAA-Key is not bound to a specific peer or
authenticator port. As a result, the peer or authenticator port over
which the EAP conversation takes place is not included in the AAA-Key
scope.
2.5.1. TSKs
The TSKs are typically named. Their naming is specified in the Secure
Association (phase 2) protocol, so that the correct set of transient
session keys can be identified for processing a given packet. The
scope of the TSKs is negotiated within the Secure Association
Protocol.
TSK creation and deletion operations are typically supported so that
establishment and re-establishment of TSKs can be synchronized
between the parties.
In order to avoid confusion in the case where an EAP peer has more Figure 4: Flow of EAP Keying Material and Parameters
than one AAA-Key (phase 1b) applicable to establishment of a phase 2
security association, the secure Association protocol needs to
utilize the AAA-Key name so that the appropriate phase 1b keying
material can be identified for use in the Secure Association Protocol
exchange.
3. Security Associations 2.3. Caching
During EAP authentication and subsequent exchanges, four types of Where explicitly supported by the lower layer, lower layers MAY cache
security associations (SAs) are created: the exported EAP keying material and parameters and/or TSKs. The
structure of this key cache is defined by the lower layer. So as to
enable interoperability, new lower layer specifications MUST
describe EAP key caching behavior. Unless explicitly specified by
the lower layer, the EAP peer, server and authenticator MUST assume
that peers and authenticators do not cache exported EAP keying
parameters or TSKs.
[1] EAP method SA. This SA is between the peer and EAP server. It The caching behavior of existing EAP lower layers is as follows:
stores state that can be used for "fast reconnect" or other
functionality in some EAP methods. Not all EAP methods create such
an SA.
[2] EAP-Key SA. This is an SA between the peer and EAP server, which PPP PPP, defined in [RFC1661] does not support caching of EAP keying
is used to store the keying material exported by the EAP method. material or parameters. Since PPP ciphersuites derive their TSKs
Current EAP server implementations do not retain this SA after the directly from the MSK as described in [RFC2716], were PPP to
EAP conversation completes. support caching, this could result in stale TSKs. Therefore once
the PPP session is terminated, it is assumed that EAP keying
material and parameters are discarded.
[3] AAA SA(s). These SAs are between the authenticator and the backend IKEv2
authentication server. They permit the parties to mutually IKEv2, defined in [IKEv2] only uses EAP keying material for
authenticate each other and protect the communications between authentication purposes and not key derivation. As a result, IKEv2
them. does not cache EAP keying material or parameters, nor does it
utilize the Key-Lifetime to determine the lifetime of IPsec SAs.
As result, once IKEv2 authentication completes it is assumed that
EAP keying material and parameters are discarded.
[4] Service SA(s). These SAs are between the peer and authenticator, IEEE 802.11i
and they are created as a result of phases 1-2 of the conversation IEEE 802.11i enables caching of the MSK, but not the EMSK, IV,
(see Section 2). Peer-ID, Server-ID, Session-ID, or Key-Lifetime. More details are
about the structure of the cache are available in [IEEE-802.11i].
Examples of security associations are provided in Appendix F. IEEE 802.1X-2004
IEEE 802.1X-2004, defined in [IEEE-802.1X-2004] does not support
caching of EAP keying material or parameters. Therefore once EAP
authentication completes, it is assumed that EAP keying material
and parameters are discarded.
3.1. EAP Method SA (peer - EAP server) AAA Existing AAA servers supporting RADIUS/EAP [RFC3579] or Diameter
EAP [RFC4207] do not support caching of EAP keying material or
parameters. In existing AAA server implementations, exported EAP
keying material (MSK, EMSK and IV) as well as parameters and
derived keys are not cached and MUST be presumed lost after the AAA
exchange completes.
An EAP method may store some state on the peer and EAP server even In order to avoid key reuse, the AAA layer MUST delete transported
after phase 1a has completed. keys once they are sent. The AAA layer MUST NOT retain keys that
it has previously sent to the authenticator. For example, a AAA
layer that has transported the MSK MUST delete it, and keys MUST
NOT be derived from the MSK from that point forward.
Typically, this is used for "fast reconnect": the peer and EAP server 2.4. Key Scope
can confirm that they are still talking to the same party, perhaps
using fewer round-trips or less computational power. In this case,
the EAP method SA is essentially a cache for performance
optimization, and either party may remove the SA from its cache at
any point.
An EAP method may also keep state in order to support pseudonym-based It should be understood that an EAP authenticator or peer:
identity protection. This is typically a cache as well (the
information can be recreated if the original EAP method SA is lost),
but may be stored for longer periods of time.
The EAP method SA is not restricted to a particular service or [a] may contain one or more physical or logical ports;
authenticator and is most useful when the peer accesses many [b] may advertise itself as one or more "virtual"
different authenticators. An EAP method is responsible for authenticators or peers;
specifying how the parties select if an existing EAP method SA should [c] may utilize multiple CPUs;
be used, and if so, which one. Where multiple backend authentication [d] may support clustering services for load balancing or failover.
servers are used, EAP method SAs are not typically synchronized
between them.
EAP method implementations should consider the appropriate lifetime The issues that arise from this are discussed below.
for the EAP method SA. "Fast reconnect" assumes that the information
required (primarily the keys in the EAP method SA) hasn't been
compromised. In case the original authentication was carried out
using, for instance, a smart card, it may be easier to compromise the
EAP method SA (stored on the PC, for instance), so typically the EAP
method SAs have a limited lifetime.
Contents: 2.4.1. Multiple Ports
o Implicitly, the EAP method this SA refers to Both the EAP peer and authenticator may have more than one physical
o Internal (non-exported) cryptographic state or logical port. A peer may simultaneously access the network via
o EAP method SA name multiple authenticators, or via multiple physical or logical ports on
o SA lifetime a given authenticator. Similarly, an authenticator may offer network
access to multiple peers, each via a separate physical or logical
port. The situation is illustrated in Figure 5.
3.2. EAP-Key SA +-+-+-+-+
| EAP |
| Peer |
+-+-+-+-+
| | | Peer Ports
/ | \
/ | \
/ | \
/ | \
/ | \
/ | \
/ | \
/ | \
| | | | | | | | | Authenticator Ports
+-+-+-+-+ +-+-+-+-+ +-+-+-+-+
| | | | | |
| Auth. | | Auth. | | Auth. |
| | | | | |
+-+-+-+-+ +-+-+-+-+ +-+-+-+-+
\ | /
\ | /
\ | /
EAP over AAA \ | /
(optional) \ | /
\ | /
\ | /
\ | /
+-+-+-+-+
| EAP |
|Server |
+-+-+-+-+
This is an SA between the peer and EAP server, which is used to store Figure 5: Relationship between EAP peer, authenticator and server
the keying material exported by the EAP method. Current EAP server
implementations do not retain this SA after the EAP conversation
completes. As a result, all keys exported by the EAP method
(including the MSK, EMSK and IV) on the AAA server are discarded and
are not cached. Calculated keys (such as the AAA-Key) are also
discarded and not cached.
3.3. AAA SA(s) (authenticator - backend authentication server) Absent explicit specification within the lower layer, EAP keying
material and parameters are not bound to a specific peer or
authenticator port. Where the peer and authenticator identify
themselves within the lower layer using a port identifier such as a
link layer address, this creates a problem, because it may not be
obvious to the peer which authenticator ports are associated with
which authenticators. Similarly, it may not be obvious to the
authenticator which peer ports are associated with which peers. As a
result, the peer and authenticator may not be able to determine the
scope of the EAP keying material. This is particularly problematic
for lower layers where key caching is supported.
In order for the authenticator and backend authentication server to For example, where the EAP peer cannot identify the EAP
authenticate each other, they need to store some information. authenticator, it will be unable to determine whether EAP keying
material has been shared outside of its authorized scope, and
therefore needs to be considered compromised. There is also a
practical problem because the EAP peer will be unable to utilize the
EAP authenticator key cache in an efficient way.
In case the authenticator and backend authentication server are The solution to this problem is for lower layers to identify EAP
colocated, and they communicate using local procedure calls or shared peers and authenticators unambiguously, without incorporating
memory, this SA need not necessarily contain any information. implicit assumptions about peer and authenticator architectures. Use
of port identifiers is NOT RECOMMENDED where peers and authenticators
may support multiple ports.
3.4. Service SA(s) (peer - authenticator) AAA protocols such as RADIUS [RFC3579] and Diameter [RFC4072] provide
a mechanism for the identification of AAA clients; since the EAP
authenticator and AAA client are always co-resident, this mechanism
can be applied to the identification of EAP authenticators.
The service SAs store information about the service being provided. RADIUS requires that an Access-Request packet contain one or more of
These include the Root service SA and derived unicast and multicast the NAS-Identifier, NAS-IP-Address and NAS-IPv6-Address attributes.
service SAs. Since a NAS may have more than one IP address associated with it, the
NAS-Identifier attribute is RECOMMENDED for the unambiguous
identification of the EAP authenticator.
The Root service SA is established as the result of the completion of From the point of view of the AAA server, EAP keying material and
EAP authentication (phase 1a) and AAA-Key derivation or transport parameters are transported to the NAS identified by the NAS-
(phase 1b). It includes: Identifier attribute. Since the NAS/ EAP authenticator MUST NOT
share EAP keying material or parameters with another party, if the
EAP peer or AAA server detects use of EAP keying material and
parameters outside the scope defined by the NAS-Identifier, the
keying material MUST be considered compromised.
o Service parameters (or at least those parameters In order to further limit the key scope the following measures are
that are still needed) suggested:
o On the authenticator, service authorization
information received from the backend authentication
server (or necessary parts of it)
o On the peer, usually locally configured service
authorization information.
o The AAA-Key, if it can be needed again (to refresh
and/or resynchronize other keys or for another reason)
o AAA-Key lifetime
Unicast and (optionally) multicast service SAs are derived from the [a] The lower layer MAY specify additional restrictions on key usage,
Root service SA, via the Secure Association Protocol. In order for such as limiting the use of EAP keying material and parameters on
unicast and multicast service SAs and associated TSKs to be the EAP peer to the port over which on the EAP conversation was
established, it is not necessary for EAP authentication (phase 1a) to conducted.
be rerun each time. Instead, the Secure Association Protocol can be
used to mutually prove possession of the AAA-Key and create
associated unicast (phase 2a) and multicast (phase 2b) service SAs
and TSKs, enabling the EAP exchange to be bypassed. Unicast and
multicast service SAs include:
o Service parameters negotiated by the Secure Association Protocol. [b] The AAA server and client/authenticator MAY implement additional
o Endpoint identifiers. attributes in order to further restrict the scope of EAP keying
o Transient Session Keys used to protect the communication. material. For example, in 802.11, the AAA server may provide the
o Transient Session Key lifetime. authenticator with a list of authorized Called or Calling-Station-
Ids and/or SSIDs for which EAP keying material is valid.
One function of the Secure Association Protocol is to bind the the [c] Where the AAA server provides attributes restricting the key scope,
unicast and multicast service SAs and TSKs to endpoint identifiers. it is RECOMMENDED that restrictions be securely communicated by the
For example, within [IEEE802.11i], the 4-way handshake binds the TSKs authenticator to the peer. This can be accomplished using the
to the MAC addresses of the endpoints; in [IKEv2], the TSKs are bound Secure Association Protocol, but also can be accomplished via the
to the IP addresses of the endpoints and the negotiated SPI. EAP method or the lower layer.
It is possible for more than one unicast or multicast service SA to 2.4.2. Virtual Authenticators
be derived from a single Root service SA. However, a unicast or
multicast service SA is always descended from only one Root service
SA. Unicast or multicast service SAs descended from the same Root
service SA may utilize the same security parameters (e.g. mode,
ciphersuite, etc.) or they may utilize different parameters.
An EAP peer may be able to negotiate multiple service SAs with a When a single physical authenticator advertises itself as multiple
given authenticator, or may be able to maintain one or more service "virtual authenticators", the EAP peer and authenticator also may not
SAs with multiple authenticators, depending on the properties of the be able to agree on the scope of the EAP keying material, creating a
media. security vulnerability. For example, the peer may assume that the
"virtual authenticators" are distinct and do not share a key cache,
whereas, depending on the architecture of the physical authenticator,
a shared key cache may or may not be implemented.
Except where explicitly specified by the Secure Association Protocol, Where EAP keying material is shared between "virtual authenticators"
it should not be assumed that the installation of new service SAs an attacker acting as a peer could authenticate with the "Guest"
implies deletion of old service SAs. It is possible for multicast "virtual authenticator" and derive EAP keying material. If the
Root service SAs to between the same EAP peer and authenticator; virtual authenticators share a key cache, then the peer can utilize
during a re-key of a unicast or multicast service SA it is possible the EAP keying material derived for the "Guest" network to obtain
for two service SAs to exist during the period between when the new access to the "Corporate Intranet" virtual authenticator.
service SA and corresponding TSKs are calculated and when they are
installed.
Similarly, deletion or creation of a unicast or multicast service SA Several measures are recommended to address these issues:
does not necessarily imply deletion or creation of related unicast or
multicast service SAs, unless specified by the Secure Association
protocol. For example, a unicast service SA may be rekeyed without
implying a rekey of the multicast service SA.
The deletion of the Root service SA does not necessarily imply the [d] Authenticators are REQUIRED to cache associated authorizations
deletion of the derived unicast and multicast service SAs and along with EAP keying material and parameters and to apply
associated TSKs. Failure to mutually prove possession of the AAA-Key authorizations consistently. This ensures that an attacker cannot
during the Secure Association Protocol exchange need not be grounds obtain elevated privileges even where the key cache is shared
for deletion of the AAA-Key by both parties; the action to be taken between "virtual authenticators".
is defined by the Secure Association Protocol.
3.4.1. Sharing service SAs [e] It is RECOMMENDED that physical authenticators maintain separate
key caches for each "virtual authenticator".
A single service may be provided by multiple logical or physical [f] It is RECOMMENDED that each "virtual authenticator" identify itself
service elements. Each service is responsible for specifying how distinctly to the AAA server, such as by utilizing a distinct NAS-
changing service elements is handled. Some approaches include: Identifier attribute. This enables the AAA server to utilize a
separate credential to authenticate each "virtual authenticator".
Transparent sharing 3. Key Management
If the service parameters visible to the other party (either peer
or authenticator) do not change, the service can be moved without
requiring cooperation from the other party.
Whether such a move should be supported or used depends on EAP as defined in [RFC3748] supports key derivation, but not key
implementation and administrative considerations. For instance, an management. While EAP methods may derive keying material, EAP does
administrator may decide to configure a group of IKEv2/IPsec not provide for the management of exported or derived keys. For
gateways in a cluster for high-availability purposes, if the example, EAP does not support negotiation of the key lifetime of
implementation used supports this. The peer does not necessarily exported or derived keys, nor does it support re-key. Although EAP
have any way of knowing when the change occurs. methods may support "fast reconnect" as defined in [RFC3748] Section
7.2.1, re-key of exported keys cannot occur without re-
authentication. In order to provide method independence, key
management of exported or derived keys SHOULD NOT be provided within
EAP methods.
No sharing 3.1. Secure Association Protocol
If the service parameters require changing, some changes may
require terminating the old service, and starting a new
conversation from phase 0. This approach is used by all services
for at least some parameters, and it doesn't require any protocol
for transferring the service SA between the service elements.
The service may support keeping the old service element active Since neither EAP nor EAP methods provide key management support, it
while the new conversation takes phase, to decrease the time the is RECOMMENDED that key management facilities be provided within the
service is not available. Secure Association Protocol. This includes:
Some sharing [a] Entity Naming. A basic feature of a Secure Association Protocol is
The service may allow changing some parameters by simply agreeing the explicit naming of the parties engaged in the exchange.
about the new values. This may involve a similar exchange as in Without explicit identification, the parties engaged in the
phase 2, or perhaps a shorter conversation. exchange are not identified and the scope of the EAP keying
parameters negotiated during the EAP exchange is undefined. As
shown in Figure 5, both the peer and authenticator may have more
than one physical or virtual port, and as a result SHOULD identify
themselves in a manner that is independent of their attached ports.
This option usually requires some protocol for transferring the [b] Mutual proof of possession of EAP keying material. During the
service SA between the elements. An administrator may decide not to Secure Association Protocol the EAP peer and authenticator MUST
enable this feature at all, and typically the sharing is restricted demonstrate possession of the keying material transported between
to some particular service elements (defined either by a service the backend authentication server and authenticator (e.g. MSK), in
parameter, or simple administrative decision). If the old and new order to demonstrate that the peer and authenticator have been and
service element do not support such "context transfer", this authorized. Since mutual proof of possession is not the same as
approach falls back to the previous option (no transfer). mutual authentication, the peer cannot verify authenticator
assertions (including the authenticator identity) as a result of
this exchange.
Services supporting this feature should also consider what changes [c] Secure capabilities negotiation. In order to protect against
require new authorization from the backend authentication server spoofing during the discovery phase, ensure selection of the "best"
(see Section 5.2). ciphersuite, and protect against forging of negotiated security
parameters, the Secure Association Protocol MUST support secure
capabilities negotiation. This includes the secure negotiation of
usage modes, session parameters (such as security association
identifiers (SAIDs) and key lifetimes), ciphersuites and required
filters, including confirmation of security-relevant capabilities
discovered during phase 0. As part of secure capabilities
negotiation, the Secure Association Protocol MUST support integrity
and replay protection of all messages.
Note that these considerations are not limited to service [d] Key naming and selection. Where key caching is supported, it may
parameters related to the authenticator--they apply to peer be possible for the EAP peer and authenticator to share more than
parameters as well. one key of a given type. As a result, the Secure Association
Protocol MUST explicitly name the keys used in the proof of
possession exchange, so as to prevent confusion when more than one
set of keying material could potentially be used as the basis for
the exchange. Use of the key naming mechanism described in this
document is RECOMMENDED.
4. Key Management In order to support the correct processing of phase 2 security
associations, the Secure Association (phase 2) protocol MUST
support the naming of phase 2 security associations and associated
transient session keys, so that the correct set of transient
session keys can be identified for processing a given packet. The
phase 2 Secure Association Protocol also MUST support transient
session key activation and SHOULD support deletion, so that
establishment and re-establishment of transient session keys can be
synchronized between the parties.
EAP supports key derivation, but not key management. As a result, [e] Generation of fresh transient session keys (TSKs). Where the lower
key management functionality needs to be provided by the Secure layer supports caching of exported EAP keying material, the EAP
Association Protocol. This includes: peer lower layer may initiate a new session using keying material
that was derived in a previous session. Were the TSKs to be
derived from a portion of the exported EAP keying material, this
would result in reuse of the session keys which could expose the
underlying ciphersuite to attack.
[a] Generation of fresh transient session keys (TSKs). Where AAA-Key In lower layers where caching of EAP keying material is supported,
caching is supported, the EAP peer may initiate a new session using the Secure Association Protocol phase is REQUIRED, and MUST support
a AAA-Key that was used in a previous session. Were the TSKs to be the derivation of fresh unicast and multicast TSKs, even when the
derived from a portion of the AAA-Key, this would result in reuse keying material provided by the backend authentication server is
of the session keys which could expose the underlying ciphersuite not fresh. This is typically supported via the exchange of nonces
to attack. As a result, where AAA-Key caching is supported, the or counters, which are then mixed with the exported keying material
Secure Association Protocol phase is REQUIRED, and MUST provide for in order to generate fresh unicast (phase 2a) and possibly
freshness of the TSKs. multicast (phase 2b) session keys. By not using EAP keying
material directly to protect data, the Secure Association Protocol
protects it against compromise.
[b] Key lifetime determination. EAP does not support negotiation of [f] Key lifetime management. This includes explicit key lifetime
key lifetimes, nor does it support rekey without reauthentication. negotiation or seamless re-key. EAP does not support negotiation
As a result, the Secure Association Protocol may handle rekey and of key lifetimes, nor does it support re-key without re-
determination of the key lifetime. Where key caching is supported, authentication. As a result, the Secure Association Protocol may
secure negotiation of key lifetimes is RECOMMENDED. Lower layers handle re-key and determination of the key lifetime. Where key
that support rekey, but not key caching, may not require key caching is supported, secure negotiation of key lifetimes is
lifetime negotiation. To take an example from IKE, the difference RECOMMENDED. Lower layers that support re-key, but not key
between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes were caching, may not require key lifetime negotiation. To take an
negotiated. In IKEv2, each end of the SA is responsible for example from IKE, the difference between IKEv1 and IKEv2 is that in
enforcing its own lifetime policy on the SA and rekeying the SA IKEv1 SA lifetimes were negotiated. In IKEv2, each end of the SA is
when necessary. responsible for enforcing its own lifetime policy on the SA and re-
keying the SA when necessary.
[c] Key resynchronization. It is possible for the peer or [g] Key resynchronization. It is possible for the peer or
authenticator to reboot or reclaim resources, clearing portions or authenticator to reboot or reclaim resources, clearing portions or
all of the key cache. Therefore, key lifetime negotiation cannot all of the key cache. Therefore, key lifetime negotiation cannot
guarantee that the key cache will remain synchronized, and the peer guarantee that the key cache will remain synchronized, and the peer
may not be able to determine before attempting to use a AAA-Key may not be able to determine before attempting to use a key whether
whether it exists within the authenticator cache. It is therefore it exists within the authenticator cache. It is therefore
RECOMMENDED for the Secure Association Protocol to provide a RECOMMENDED for the Secure Association Protocol to provide a
mechanism for key state resynchronization. Since in this situation mechanism for key state resynchronization. Since in this situation
one or more of the parties initially do not possess a key with one or more of the parties initially do not possess a key with
which to protect the resynchronization exchange, securing this which to protect the resynchronization exchange, securing this
mechanism may be difficult. mechanism may be difficult.
[d] Key selection. Where key caching is supported, it may be possible [h] Key scope synchronization. Since the Discovery phase is handled
for the EAP peer and authenticator to share more than one key of a out-of-band, EAP does not provide a mechanism by which the peer can
given type. As a result, the Secure Association Protocol needs to
support key selection, using the EAP Key Naming scheme described in
this document.
[e] Key scope determination. Since the Discovery phase is handled out-
of-band, EAP does not provide a mechanism by which the peer can
determine the authenticator identity. As a result, where the determine the authenticator identity. As a result, where the
authenticator has multiple ports and AAA-Key caching is supported, authenticator has multiple ports and key caching is supported, the
the EAP peer may not be able to determine the scope of validity of EAP peer may not be able to determine the scope of validity of the
a AAA-Key. Similarly, where the EAP peer has multiple ports, the exported EAP keying material. Similarly, where the EAP peer has
authenticator may not be able to determine whether a peer has multiple ports, the authenticator may not be able to determine
authorization to use a particular AAA-Key. To allow key scope whether a peer has authorization to use a particular key. To allow
determination, the lower layer SHOULD provide a mechanism by which key scope determination, the Secure Association Protocol SHOULD
the peer can determine the scope of the AAA-Key cache on each provide a mechanism by which the peer can determine the scope of
authenticator, and by which the authenticator can determine the the key cache on each authenticator, and by which the authenticator
scope of the AAA-Key cache on a peer. can determine the scope of the key cache on a peer. This includes
negotiation of restrictions on key usage.
4.1. Key Caching
In existing implementations, key caching may be supported on the EAP
peer and authenticator but not on the backend server. Where
explicitly supported by the lower layer, the EAP peer and
authenticator MAY cache the AAA-Key and/or TSKs. The structure of
the key cache on the peer and authenticator is defined by the lower
layer. Unless specified by the lower layer, the EAP peer and
authenticator MUST assume that peers and authenticators do not cache
the AAA-Key or TSKs.
In existing AAA server implementations, all keys exported by EAP
methods (including the MSK, EMSK and IV) and calculated keys (e.g.
AAA-Key) are not cached and are lost after EAP authentication
completes:
[1] In order to avoid key reuse, on the EAP server, transported keys [i] Direct operation. Since the phase 2 Secure Association Protocol is
are deleted once they are sent. An EAP server MUST NOT retain keys concerned with the establishment of security associations between
that it has previously sent to the authenticator. For example, an the EAP peer and authenticator, including the derivation of
EAP server that has transported a AAA-Key based on the MSK MUST transient session keys, only those parties have "a need to know"
delete the MSK, and no keys may be derived from the MSK from that the transient session keys. The Secure Association Protocol MUST
point forward by the server. operate directly between the peer and authenticator, and MUST NOT
be passed-through to the backend authentication server, or include
additional parties.
[2] Keys which are not transported, such as the EMSK, are also deleted [j] Bi-directional operation While some ciphersuites only require a
by existing implementations. single set of transient session keys to protect traffic in both
directions, other ciphersuites require a unique set of transient
session keys in each direction. The phase 2 Secure Association
Protocol SHOULD provide for the derivation of unicast and multicast
keys in each direction, so as not to require two separate phase 2
exchanges in order to create a bi-directional phase 2 security
association.
4.2. Parent-Child Relationships 3.2. Parent-Child Relationships
When keying material exported by EAP methods expires, all keying When keying material exported by EAP methods expires, all keying
material derived from the exported keying material expires, including material derived from the exported keying material expires, including
the AAA-Key and TSKs. the TSKs.
When an EAP reauthentication takes place, new keying material is When an EAP re-authentication takes place, new keying material is
derived and exported by the EAP method, which eventually results in derived and exported by the EAP method, which eventually results in
replacement of calculated keys, including the AAA-Key and TSKs. replacement of calculated keys, including the TSKs.
As a result, while the lifetime of calculated keys can be less than As a result, while the lifetime of calculated keys can be less than
or equal that of the exported keys they are derived from, it cannot or equal that of the exported keys they are derived from, it cannot
be greater. For example, TSK rekey may occur prior to EAP be greater. For example, TSK re-key may occur prior to EAP re-
reauthentication. authentication.
Failure to mutually prove possession of the AAA-Key during the Secure Failure to mutually prove possession of keying material during the
Association Protocol exchange need not be grounds for deletion of the Secure Association Protocol exchange need not be grounds for deletion
AAA-Key by both parties; rate-limiting Secure Association Protocol of the keying material by both parties; rate-limiting Secure
exchanges could be used to prevent a brute force attack. Association Protocol exchanges could be used to prevent a brute force
attack.
4.3. Local Key Lifetimes 3.3. Local Key Lifetimes
The Transient EAP Keys (TEKs) are session keys used to protect the The Transient EAP Keys (TEKs) are session keys used to protect the
EAP conversation. The TEKs are internal to the EAP method and are EAP conversation. The TEKs are internal to the EAP method and are
not exported. TEKs are typically created during an EAP conversation, not exported. TEKs are typically created during an EAP conversation,
used until the end of the conversation and then discarded. However, used until the end of the conversation and then discarded. However,
methods may rekey TEKs during a conversation. methods may re-key TEKs during a conversation.
When using TEKs within an EAP conversation or across conversations, When using TEKs within an EAP conversation or across conversations,
it is necessary to ensure that replay protection and key separation it is necessary to ensure that replay protection and key separation
requirements are fulfilled. For instance, if a replay counter is requirements are fulfilled. For instance, if a replay counter is
used, TEK rekey MUST occur prior to wrapping of the counter. used, TEK re-key MUST occur prior to wrapping of the counter.
Similarly, TSKs MUST remain cryptographically separate from TEKs Similarly, TSKs MUST remain cryptographically separate from TEKs
despite TEK rekeying or caching. This prevents TEK compromise from despite TEK re-keying or caching. This prevents TEK compromise from
leading directly to compromise of the TSKs and vice versa. leading directly to compromise of the TSKs and vice versa.
EAP methods may cache local keying material which may persist for EAP methods may cache local keying material which may persist for
multiple EAP conversations when fast reconnect is used [RFC 3748]. multiple EAP conversations when fast reconnect is used [RFC 3748].
For example, EAP methods based on TLS (such as EAP-TLS [RFC2716]) For example, EAP methods based on TLS (such as EAP-TLS [RFC2716])
derive and cache the TLS Master Secret, typically for substantial derive and cache the TLS Master Secret, typically for substantial
time periods. The lifetime of other local keying material calculated time periods. The lifetime of other local keying material calculated
within the EAP method is defined by the method. Note that in within the EAP method is defined by the method. Note that in
general, when using fast reconnect, there is no guarantee to that the general, when using fast reconnect, there is no guarantee to that the
original long-term credentials are still in the possession of the original long-term credentials are still in the possession of the
peer. For instance, a card hold holding the private key for EAP-TLS peer. For instance, a card hold holding the private key for EAP-TLS
may have been removed. EAP servers SHOULD also verify that the long- may have been removed. EAP servers SHOULD also verify that the long-
term credentials are still valid, such as by checking that term credentials are still valid, such as by checking that
certificate used in the original authentication has not yet expired. certificate used in the original authentication has not yet expired.
4.4. Exported and Calculated Key Lifetimes 3.4. Exported and Calculated Key Lifetimes
All EAP methods generating keys are required to generate the MSK and All EAP methods generating keys are required to generate the MSK and
EMSK, and may optionally generate the IV. However, EAP, defined in EMSK, and may optionally generate the IV. However, EAP, defined in
[RFC3748], does not support the negotiation of lifetimes for exported [RFC3748], does not support the negotiation of lifetimes for exported
keying material such as the MSK, EMSK and IV. keying material such as the MSK, EMSK and IV.
Several mechanisms exist for managing key lifetimes: Several mechanisms exist for managing key lifetimes:
[a] AAA attributes. AAA protocols such as RADIUS [RFC2865] and [a] AAA attributes. AAA protocols such as RADIUS [RFC2865] and
Diameter [I-D.ietf-aaa-eap] support the Session-Timeout attribute. Diameter [RFC4072] support the Session-Timeout attribute. The
The Session-Timeout value represents the maximum lifetime of the Session-Timeout value represents the maximum lifetime of the
exported keys, and all keys calculated from it, on the exported keys, and all keys calculated from it, on the
authenticator. Since existing AAA servers do not cache keys authenticator. Since existing AAA servers do not cache keys
exported by EAP methods, or keys calculated from exported keys, the exported by EAP methods, or keys calculated from exported keys, the
value of the Session-Timeout attribute has no bearing on the key value of the Session-Timeout attribute has no bearing on the key
lifetime within the AAA server. lifetime within the AAA server.
On the authenticator, where EAP is used for authentication, the On the authenticator, where EAP is used for authentication, the
Session-Timeout value represents the maximum session time prior to Session-Timeout value represents the maximum session time prior to
re-authentication, as described in [RFC3580]. Where EAP is used re-authentication, as described in [RFC3580]. Where EAP is used
for pre-authentication, the session may not start until some future for pre-authentication, the session may not start until some future
time, or may never occur. Nevertheless, the Session-Timeout value time, or may never occur. Nevertheless, the Session-Timeout value
represents the time after which the AAA-Key, and all keys represents the time after which transported EAP keying material,
calculated from it, will have expired on the authenticator. If the and all keys calculated from it, will have expired on the
session subsequently starts, re-authentication will be initiated authenticator. If the session subsequently starts, re-
once the Session-Time has expired. If the session never started, authentication will be initiated once the Session-Time has expired.
or started and ended, the AAA-Key and all keys calculated from it If the session never started, or started and ended, by default keys
will be expired by the authenticator prior to the future time transported by AAA and all keys calculated from them will be
indicated by Session-Timeout. expired by the authenticator prior to the future time indicated by
Session-Timeout.
Since the TSK lifetime is often determined by authenticator Since the TSK lifetime is often determined by authenticator
resources, the AAA server has no insight into the TSK derivation resources, the AAA server has no insight into the TSK derivation
process, and by the principle of ciphersuite independence, it is process, and by the principle of ciphersuite independence, it is
not appropriate for the AAA server to manage any aspect of the TSK not appropriate for the AAA server to manage any aspect of the TSK
derivation process, including the TSK lifetime. derivation process, including the TSK lifetime.
[b] Lower layer mechanisms. While AAA attributes can communicate the [b] Lower layer mechanisms. While AAA attributes can communicate the
maximum exported key lifetime, this only serves to synchronize the maximum exported key lifetime, this only serves to synchronize the
key lifetime between the backend authentication server and the key lifetime between the backend authentication server and the
authenticator. Lower layer mechanisms such as the Secure authenticator. Lower layer mechanisms such as the Secure
Association Protocol can then be used to enable the lifetime of Association Protocol can then be used to enable the lifetime of
exported and calculated keys to be negotiated between the peer and exported and calculated keys to be negotiated between the peer and
authenticator. authenticator.
Where TSKs are established as the result of a Secure Association Where TSKs are established as the result of a Secure Association
Protocol exchange, it is RECOMMENDED that the Secure Association Protocol exchange, it is RECOMMENDED that the Secure Association
Protocol include support for TSK resynchronization. Where the TSK Protocol include support for TSK resynchronization. Where the TSK
is taken from the AAA-Key, there is no need to manage the TSK is taken from the MSK, there is no need to manage the TSK lifetime
lifetime as a separate parameter, since the TSK lifetime and AAA- as a separate parameter, since the TSK lifetime and MSK lifetime
Key lifetime are identical. are identical.
[c] System defaults. Where the EAP method does not support the [c] System defaults. Where the EAP method does not support the
negotiation of the exported key lifetime, and a key lifetime negotiation of the exported key lifetime, and a key lifetime
negotiation mechanism is not provided by the lower lower, there may negotiation mechanism is not provided by the lower lower, there may
be no way for the peer to learn the exported key lifetime. In this be no way for the peer to learn the exported key lifetime. In this
case it is RECOMMENDED that the peer assume a default value of the case it is RECOMMENDED that the peer assume a default value of the
exported key lifetime; 8 hours is recommended. Similarly, the exported key lifetime; 8 hours is recommended. Similarly, the
lifetime of calculated keys can also be managed as a system lifetime of calculated keys can also be managed as a system
parameter on the authenticator. parameter on the authenticator.
[d] Method specific negotiation within EAP. While EAP itself does not [d] Method specific negotiation within EAP. While EAP itself does not
support lifetime negotiation, it would be possible to specify support lifetime negotiation, it would be possible to specify
methods that do. However, systems that rely on such negotiation methods that do. However, systems that rely on such negotiation
for exported keys would only function with these methods. As a for exported keys would only function with these methods. As a
result, it is NOT RECOMMENDED to use this approach as the sole way result, it is NOT RECOMMENDED to use this approach as the sole way
to determine key lifetimes. to determine key lifetimes.
4.5. Key cache synchronization 3.5. Key cache synchronization
Issues arise when attempting to synchronize the key cache on the peer Issues arise when attempting to synchronize the key cache on the peer
and authenticator. Lifetime negotiation alone cannot guarantee key and authenticator. Lifetime negotiation alone cannot guarantee key
cache synchronization. cache synchronization.
One problem is that the AAA protocol cannot guarantee synchronization One problem is that the AAA protocol cannot guarantee synchronization
of key lifetimes between the peer and authenticator. Where the of key lifetimes between the peer and authenticator. Where the
Secure Association Protocol is not run immediately after EAP Secure Association Protocol is not run immediately after EAP
authentication, the exported and calculated key lifetimes will not be authentication, the exported and calculated key lifetimes will not be
known by the peer during the hiatus. Where EAP pre-authentication known by the peer during the hiatus. Where EAP pre-authentication
occurs, this can leave the peer uncertain whether a subsequent occurs, this can leave the peer uncertain whether a subsequent
attempt to use the exported keys will prove successful. attempt to use the exported keys will prove successful.
However, even where the Secure Association Protocol is run However, even where the Secure Association Protocol is run
immediately after EAP, it is still possible for the authenticator to immediately after EAP, it is still possible for the authenticator to
reclaim resources if the created key state is not immediately reclaim resources if the created key state is not immediately
utilized. utilized.
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 key cache by deleting the
the oldest AAA-Key first (LIFO), the relative creation time of the oldest key first (LIFO), the relative creation time of the last key
last AAA-Key to be deleted could be advertised with the Discovery to be deleted could be advertised with the Discovery phase, enabling
phase, enabling the peer to determine whether a given AAA-Key had the peer to determine whether a given key had been expired from the
been expired from the authenticator key cache prematurely. authenticator key cache prematurely.
4.6. Key Scope
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
root of the ciphersuite-specific key hierarchy. Where a backend
authentication server is present, the AAA-Key is transported from the
EAP server to the authenticator; where it is not present, the AAA-Key
is calculated on the authenticator.
Regardless of how many sessions are initiated using it, the AAA-Key
scope is between the EAP peer that calculates it, and the
authenticator that either calculates it (where no backend
authenticator is present) or receives it from the server (where a
backend authenticator server is present).
It should be understood that an authenticator or peer:
[a] may contain multiple physical ports;
[b] may advertise itself as multiple "virtual" authenticators
or peers;
[c] may utilize multiple CPUs;
[d] may support clustering services for load balancing or failover.
As illustrated in Figure 1, an EAP peer with multiple ports may be
attached to one or more authenticators, each with multiple ports.
Where the peer and authenticator identify themselves using a port
identifier such as a link layer address, it may not be obvious to the
peer which authenticator ports are associated with which
authenticators. Similarly, it may not be obvious to the
authenticator which peer ports are associated with which peers. As a
result, the peer and authenticator may not be able to determine the
scope of the AAA-Key.
When a single physical authenticator advertises itself as multiple
"virtual authenticators", the EAP peer and authenticator also may not
be able to agree on the scope of the AAA-Key, creating a security
vulnerability. For example, the peer may assume that the "virtual
authenticators" are distinct and do not share a key cache, whereas,
depending on the architecture of the physical AP, a shared key cache
may or may not be implemented.
Where the AAA-Key is shared between "virtual authenticators" an
attacker acting as a peer could authenticate with the "Guest"
"virtual authenticator" and derive a AAA-Key. If the virtual
authenticators share a key cache, then the peer can utilize the AAA-
Key derived for the "Guest" network to obtain access to the
"Corporate Intranet" virtual authenticator.
Several measures are recommended to address these issues:
[a] Authenticators are REQUIRED to cache associated authorizations
along with the AAA-Key and apply authorizations consistently. This
ensures that an attacker cannot obtain elevated privileges even
where the AAA-Key cache is shared between "virtual authenticators".
[b] It is RECOMMENDED that physical authenticators maintain separate
AAA-Key caches for each "virtual authenticator".
[c] It is RECOMMENDED that each "virtual authenticator" identify itself
distinctly to the AAA server, such as by utilizing a distinct NAS-
identifier attribute. This enables the AAA server to utilize a
separate credential to authenticate each "virtual authenticator".
[d] It is RECOMMENDED that Secure Association Protocols identify peers
and authenticators unambiguously, without incorporating implicit
assumptions about peer and authenticator architectures. Using
port-specific MAC addresses as identifiers is NOT RECOMMENDED where
peers and authenticators may support multiple ports.
[e] The AAA server and authenticator MAY implement additional
attributes in order to further restrict the AAA-Key scope. For
example, in 802.11, the AAA server may provide the authenticator
with a list of authorized Called or Calling-Station-Ids and/or
SSIDs for which the AAA-Key is valid.
[f] Where the AAA server provides attributes restricting the key scope,
it is RECOMMENDED that restrictions be securely communicated by the
authenticator to the peer. This can be accomplished using the
Secure Association Protocol, but also can be accomplished via the
EAP method or the lower layer.
4.7. Key Strength 3.6. Key Strength
In order to guard against brute force attacks, EAP methods deriving In order to guard against brute force attacks, EAP methods deriving
keys need to be capable of generating keys with an appropriate keys need to be capable of generating keys with an appropriate
effective symmetric key strength. In order to ensure that key effective symmetric key strength. In order to ensure that key
generation is not the weakest link, it is RECOMMENDED that EAP generation is not the weakest link, it is RECOMMENDED that EAP
methods utilizing public key cryptography choose a public key that methods utilizing public key cryptography choose a public key that
has a cryptographic strength meeting the symmetric key strength has a cryptographic strength meeting the symmetric key strength
requirement. requirement.
As noted in [RFC3766] Section 5, this results in the following As noted in [RFC3766] Section 5, this results in the following
skipping to change at page 37, line 25 skipping to change at page 28, line 21
(bits) size (bits) size (bits) (bits) size (bits) size (bits)
----------------- ----------------- ------------ ----------------- ----------------- ------------
70 947 128 70 947 128
80 1228 145 80 1228 145
90 1553 153 90 1553 153
100 1926 184 100 1926 184
150 4575 279 150 4575 279
200 8719 373 200 8719 373
250 14596 475 250 14596 475
4.8. Key Wrap 3.7. Key Wrap
As described in [RFC3579] Section 4.3, known problems exist in the As described in [RFC3579] Section 4.3, known problems exist in the
key wrap specified in [RFC2548]. Where the same RADIUS shared secret key wrap specified in [RFC2548]. Where the same RADIUS shared secret
is used by a PAP authenticator and an EAP authenticator, there is a is used by a PAP authenticator and an EAP authenticator, there is a
vulnerability to known plaintext attack. Since RADIUS uses the vulnerability to known plaintext attack. Since RADIUS uses the
shared secret for multiple purposes, including per-packet shared secret for multiple purposes, including per-packet
authentication, attribute hiding, considerable information is exposed authentication, attribute hiding, considerable information is exposed
about the shared secret with each packet. This exposes the shared about the shared secret with each packet. This exposes the shared
secret to dictionary attacks. MD5 is used both to compute the RADIUS secret to dictionary attacks. MD5 is used both to compute the RADIUS
Response Authenticator and the Message-Authenticator attribute, and Response Authenticator and the Message-Authenticator attribute, and
some concerns exist relating to the security of this hash some concerns exist relating to the security of this hash
[MD5Attack]. [MD5Attack].
As discussed in [RFC3579] Section 4.3, the security vulnerabilities As discussed in [RFC3579] Section 4.3, the security vulnerabilities
of RADIUS are extensive, and therefore development of an alternative of RADIUS are extensive, and therefore development of an alternative
key wrap technique based on the RADIUS shared secret would not key wrap technique based on the RADIUS shared secret would not
substantially improve security. As a result, [RFC3759] Section 4.2 substantially improve security. As a result, [RFC3759] Section 4.2
recommends running RADIUS over IPsec. The same approach is taken in recommends running RADIUS over IPsec. The same approach is taken in
Diameter EAP [I-D.ietf-aaa-eap], which defines cleartext key Diameter EAP [RFC4072], which defines cleartext key attributes, to be
attributes, to be protected by IPsec or TLS. protected by IPsec or TLS.
Where an untrusted AAA intermediary is present (such as a RADIUS Where an untrusted AAA intermediary is present (such as a RADIUS
proxy or a Diameter agent), and data object security is not used, the proxy or a Diameter agent), and data object security is not used,
AAA-Key may be recovered by an attacker in control of the untrusted transported keying material may be recovered by an attacker in
intermediary. Possession of the AAA-Key enables decryption of data control of the untrusted intermediary. Possession of transported
traffic sent between the peer and a specific authenticator. However, keying material enables decryption of data traffic sent between the
as long as a AAA-Key or keys derived from it is only utilized by a peer and a specific authenticator. However, as long as EAP keying
single authenticator, compromise of the AAA-Key does not enable an material or keys derived from it is only utilized by a single
attacker to impersonate the peer to another authenticator. authenticator, compromise of the transported keying material does not
enable an attacker to impersonate the peer to another authenticator.
Vulnerability to an untrusted AAA intermediary can be mitigated by Vulnerability to an untrusted AAA intermediary can be mitigated by
implementation of redirect functionality, as described in [RFC3588] implementation of redirect functionality, as described in [RFC3588]
and [I-D.ietf-aaa-eap]. and [RFC4072].
5. Handoff Vulnerabilities 4. Handoff Vulnerabilities
With EAP, a number of mechanisms are be utilized in order to reduce With EAP, a number of mechanisms are be utilized in order to reduce
the latency of handoff between authenticators. One such mechanism is the latency of handoff between authenticators. One such mechanism is
EAP pre-authentication, in which EAP is utilized to pre-establish a EAP pre-authentication, in which EAP is utilized to pre-establish EAP
AAA-Key on an authenticator prior to arrival of the peer. Another keying material on an authenticator prior to arrival of the peer.
such mechanism is AAA-Key caching, in which an EAP peer can re-attach Another such mechanism is key caching, in which an EAP peer can re-
to an authenticator without having to re-authenticate using EAP. Yet attach to an authenticator without having to re-authenticate using
another mechanism is context transfer, such as is defined in EAP. Yet another mechanism is context transfer, such as is defined
[IEEE-802.11F] and [CTP]. These mechanisms introduce new security in [IEEE-802.11F] and [CTP]. These mechanisms introduce new security
vulnerabilities, as discussed in the sections that follow. vulnerabilities, as discussed in the sections that follow.
5.1. Authorization 4.1. Authorization
In a typical network access scenario (dial-in, wireless LAN, etc.) In a typical network access scenario (dial-in, wireless LAN, etc.)
access control mechanisms are typically applied. These mechanisms access control mechanisms are typically applied. These mechanisms
include user authentication as well as authorization for the offered include user authentication as well as authorization for the offered
service. service.
As a part of the authentication process, the AAA network determines As a part of the authentication process, the AAA network determines
the user's authorization profile. The user authorizations are the user's authorization profile. The user authorizations are
transmitted by the backend authentication server to the EAP transmitted by the backend authentication server to the EAP
authenticator (also known as the Network Access Server or authenticator (also known as the Network Access Server or
authenticator) included with the AAA-Token, which also contains the authenticator) included with the AAA-Token, which also contains the
AAA-Key, in Phase 1b of the EAP conversation. Typically, the profile transported EAP keying material, in Phase 1b of the EAP conversation.
is determined based on the user identity, but a certificate presented Typically, the profile is determined based on the user identity, but
by the user may also provide authorization information. a certificate presented by the user may also provide authorization
information.
The backend authentication server is responsible for making a user The backend authentication server is responsible for making a user
authorization decision, answering the following questions: authorization decision, answering the following questions:
[a] Is this a legitimate user for this particular network? [a] Is this a legitimate user for this particular network?
[b] Is this user allowed the type of access he or she is requesting? [b] Is this user allowed the type of access he or she is requesting?
[c] Are there any specific parameters (mandatory tunneling, bandwidth, [c] Are there any specific parameters (mandatory tunneling, bandwidth,
filters, and so on) that the access network should be aware of for filters, and so on) that the access network should be aware of for
skipping to change at page 39, line 32 skipping to change at page 30, line 30
the authenticator. the authenticator.
The criteria for Accept/Reject decisions or the reasons for choosing The criteria for Accept/Reject decisions or the reasons for choosing
particular authorizations are typically not communicated to the particular authorizations are typically not communicated to the
authenticator, only the final result. As a result, the authenticator authenticator, only the final result. As a result, the authenticator
has no way to know what the decision was based on. Was a set of has no way to know what the decision was based on. Was a set of
authorization parameters sent because this service is always provided authorization parameters sent because this service is always provided
to the user, or was the decision based on the time/day and the to the user, or was the decision based on the time/day and the
capabilities of the requesting authenticator device? capabilities of the requesting authenticator device?
5.2. Correctness 4.2. Correctness
When the AAA exchange is bypassed via use of techniques such as AAA- When the AAA exchange is bypassed via use of techniques such as key
Key caching, this creates challenges in ensuring that authorization caching, this creates challenges in ensuring that authorization is
is properly handled. These include: properly handled. These include:
[a] Consistent application of session time limits. Bypassing AAA [a] Consistent application of session time limits. Bypassing AAA
should not automatically increase the available session time, should not automatically increase the available session time,
allowing a user to endlessly extend their network access by allowing a user to endlessly extend their network access by
changing the point of attachment. changing the point of attachment.
[b] Avoidance of privilege elevation. Bypassing AAA should not result [b] Avoidance of privilege elevation. Bypassing AAA should not result
in a user being granted access to services which they are not in a user being granted access to services which they are not
entitled to. entitled to.
skipping to change at page 42, line 22 skipping to change at page 33, line 20
between a authenticator providing confidentiality and another between a authenticator providing confidentiality and another
authenticator that does not support this service. The correct result authenticator that does not support this service. The correct result
of such a handoff would be a failure, since if the handoff were of such a handoff would be a failure, since if the handoff were
blindly carried out, then the user would be moved from a secure to an blindly carried out, then the user would be moved from a secure to an
insecure channel without permission from the backend authentication insecure channel without permission from the backend authentication
server. Thus the definition of a "known but unsupported service" server. Thus the definition of a "known but unsupported service"
MUST encompass requests for unavailable security services. This MUST encompass requests for unavailable security services. This
includes vendor-specific attributes related to security, such as includes vendor-specific attributes related to security, such as
those described in [RFC2548]. those described in [RFC2548].
6. Security Considerations 5. Security Considerations
6.1. Security Terminology In order to analyze whether the EAP conversation achieves it security
goals, it is first necessary to state those goals as well as the
underlying security assumptions.
The overall goal of the EAP conversation is to derive fresh session
keys between the EAP peer and authenticator that are known only to
those parties, and for both the EAP peer and authenticator to
demonstrate that they are authorized to perform their roles either by
each other or by a trusted third party (the AAA server).
The principals of the authentication phase are the EAP peer and
server. Completion of an EAP method exchange supporting key
derivation results in the derivation of EAP keying material (MSK,
EMSK, TEKs) known only to the EAP peer (identified by the Peer-ID)
and server (identified by the Server-ID). Both the EAP peer and EAP
server know the exported keying material to be fresh.
The principals of the AAA Key transport exchange are the EAP
authenticator and the EAP server. Completion of the AAA exchange
results in the transport of EAP keying material from the EAP server
(identified by the Server-ID) to the EAP authenticator (identified by
the NAS-Identifier) without disclosure to any other party. Both the
EAP server and EAP authenticator know this keying material to be
fresh.
The principals of the Secure Association Protocol are the EAP peer
(identified by the Peer-ID) and authenticator (identified by the NAS-
Identifier). Completion of the Secure Association Protocol results
in the derivation of TSKs known only to the EAP peer and
authenticator. Both the EAP peer and authenticator know the TSKs to
be fresh.
5.1. Terminology
"Cryptographic binding", "Cryptographic separation", "Key strength" "Cryptographic binding", "Cryptographic separation", "Key strength"
and "Mutual authentication" are defined in [RFC3748] and are used and "Mutual authentication" are defined in [RFC3748] and are used
with the same meaning here. with the same meaning here.
6.2. Threat Model 5.2. Threat Model
The EAP threat model is described in [RFC3748] Section 7.1. In order
to address these threats, EAP relies on the security properties of
EAP methods (known as "security claims", described in [RFC3784]
Section 7.2.1). EAP method requirements for application such as
Wireless LAN authentication are described in [RFC4017].
The RADIUS threat model is described in [RFC3579] Section 4.1, and The EAP threat model is described in [RFC3748] Section 7.1. The
responses to these threats are described in [RFC3579] Sections 4.2 security properties of EAP methods (known as "security claims",
and 4.3. Among other things, [RFC3579] Section 4.2 recommends the described in [RFC3784] Section 7.2.1), address these threats. EAP
use of IPsec ESP with non-null transform to provide per-packet method requirements for applications such as Wireless LAN
authentication and confidentiality, integrity and replay protection authentication are described in [RFC4017]. The RADIUS threat model
for RADIUS/EAP. is described in [RFC3579] Section 4.1, and responses to these threats
are described in [RFC3579] Sections 4.2 and 4.3.
Given the existing documentation of EAP and AAA threat models and However, in addition to threats against EAP and AAA, there are other
responses, there is no need to duplicate that material here. system-level threats worth discussing. These include:
However, there are many other system-level threats no covered in
these document which have not been described or analyzed elsewhere.
These include:
[1] An attacker may try to modify or spoof Secure Association Protocol [1] An attacker may compromise or steal an EAP authenticator, in an
packets. attempt to gain access to other EAP authenticators or obtain long-
term secrets.
[2] An attacker compromising an authenticator may provide incorrect [2] An attacker may compromise an EAP authenticator in an effort to
information to the EAP peer and/or server via out-of-band commit fraud. For example, a compromised authenticator may provide
incorrect information to the EAP peer and/or server via out-of-band
mechanisms (such as via a AAA or lower layer protocol). This mechanisms (such as via a AAA or lower layer protocol). This
includes impersonating another authenticator, or providing includes impersonating another authenticator, or providing
inconsistent information to the peer and EAP server. inconsistent information to the peer and EAP server.
[3] An attacker may attempt to perform downgrading attacks on the [3] An attacker may try to modify or spoof packets, including Discovery
ciphersuite negotiation within the Secure Association Protocol in or Secure Association Protocol frames, EAP or AAA packets.
order to ensure that a weaker ciphersuite is used to protect data.
Depending on the lower layer, these attacks may be carried out [4] An attacker may attempt a downgrade attack in order to exploit
without requiring physical proximity. known weaknesses in an authentication method or cryptographic
transform.
In order to address these threats, [Housley] describes the mandatory [5] An attacker may attempt to induce an EAP peer, authenticator or
system security properties: server to disclose keying material to an unauthorized party, or
utilize keying material outside the context that it was intended
for.
Algorithm independence [6] An attacker may replay packets.
Wherever cryptographic algorithms are chosen, the algorithms must
be negotiable, in order to provide resilient against compromise of
a particular algorithm. Algorithm independence must be
demonstrated within all aspects of the system, including within
EAP, AAA and the Secure Association Protocol. However, for
interoperability, at least one suite of algorithms MUST be
implemented.
Strong, fresh session keys [7] An attacker may cause an EAP peer, authenticator or server to reuse
Session keys must be demonstrated to be strong and fresh in all an stale key. Use of stale keys may also occur unintentionally.
circumstances, while at the same time retaining algorithm
independence.
Replay protection For example, a poorly implemented AAA server may provide stale
All protocol exchanges must be replay protected. This includes keying material to an authenticator, or a poorly implemented
exchanges within EAP, AAA, and the Secure Association Protocol. authenticator may reuse nonces.
Authentication [8] An authenticated attacker may attempt to obtain elevated privilege
All parties need to be authenticated. The confidentiality of the in order to access information that it does not have rights to.
authenticator must be maintained. No plaintext passwords are
allowed.
Authorization In order to address these threats, [Housley] provides a description
EAP peer and authenticator authorization must be performed. of mandatory system security properties. Issues relating system
security requirements are discussed in the sections that follow.
Session keys 5.3. Authenticator Compromise
Confidentiality of session keys must be maintained.
Ciphersuite negotiation In the event that an authenticator is compromised or stolen, an
The selection of the "best" ciphersuite must be securely confirmed. attacker may gain access to the network via that authenticator, or
may obtain the credentials required for that authenticator/AAA client
to communicate with one or more AAA servers. However, this should
not allow the attacker to compromise other authenticators or the AAA
server, or obtain long-term user credentials.
Unique naming The implications of this requirement are many, but some of the more
Session keys must be uniquely named. important are as follows:
Domino effect No Key Sharing
Compromise of a single authenticator cannot compromise any other An EAP authenticator MUST NOT share any keying material with
part of the system, including session keys and long-term secrets. another EAP authenticator, since if one EAP authenticator were
compromised, this would enable the compromise of keying material on
another authenticator. In order to be able to determine whether
keying material has been shared, it is necessary for the identity
of the EAP authenticator to be defined and understood by all
parties that communicate with it.
Key binding No AAA Credential Sharing
The key must be bound to the appropriate context. AAA credentials (such as RADIUS shared secrets, IPsec pre-shared
keys or certificates) MUST NOT be shared between AAA clients, since
if one AAA client were compromised, this would enable an attacker
to impersonate other AAA clients to the AAA server, or even to
impersonate a AAA server to other AAA clients.
6.3. Security Analysis No Compromise of Long-Term Credentials
An attacker obtaining TSKs, TEKs or EAP keying material such as the
MSK MUST NOT be able to obtain long-term user credentials such as
pre-shared keys, passwords or private-keys without breaking a
fundamental cryptographic assumption.
Figure 8 illustrates the relationship between the peer, authenticator 5.4. Spoofing
and backend authentication server.
EAP peer The use of per-packet authentication and integrity protection
/\ provides protection against spoofing attacks. Diameter [RFC3588]
/ \ provides support for per-packet authentication and integrity
Protocol: EAP / \ Protocol: Secure Association protection via use of IPsec or TLS. RADIUS/EAP [RFC3579] provides
Auth: Mutual / \ Auth: Mutual for per-packet authentication and integrity protection via use of the
Unique keys: / \ Unique keys: TSKs Message-Authenticator attribute.
TEKs,EMSK / \
/ \
EAP server +--------------+ Authenticator
Protocol: AAA
Auth: Mutual
Unique key: AAA session key
Figure 8: Relationship between peer, authenticator and auth. server [RFC3748] Section 7.2.1 describes the "integrity protection" security
claim and [RFC4017] requires use of EAP methods supporting this
claim.
The peer and EAP server communicate using EAP [RFC3748]. The In order to prevent forgery of Secure Association Protocol frames,
security properties of this communication are largely determined by per-frame authentication and integrity protection is RECOMMENDED on
the chosen EAP method. Method security claims are described in all messages. [IEEE-802.11i] supports per-frame integrity protection
[RFC3748] Section 7.2. These include the key strength, protected and authentication on all messages within the 4-way handshake except
ciphersuite negotiation, mutual authentication, integrity protection, the first message. An attack leveraging this ommission is described
replay protection, confidentiality, key derivation, key strength, in [Analysis].
dictionary attack resistance, fast reconnect, cryptographic binding,
session independence, fragmentation and channel binding claims. At a
minimum, methods claiming to support key derivation must also support
mutual authentication. As noted in [RFC3748] Section 7.10:
EAP Methods deriving keys MUST provide for mutual authentication 5.5. Downgrade Attacks
between the EAP peer and the EAP Server.
Ciphersuite independence is also required: The ability to negotiate the use of a particular cryptographic
algorithm provides resilience against compromise of a particular
cryptographic algorithm. This is usually accomplished by including
an algorithm identifier in the protocol, and by specifying the
algorithm requirements in the protocol specification. In order to
prevent downgrade attacks, secure confirmation of the "best"
ciphersuite is required.
Keying material exported by EAP methods MUST be independent of the [RFC3748] Section 7.2.1 describes the "protected ciphersuite
ciphersuite negotiated to protect data. negotiation" security claim that refers to the ability of an EAP
method to negotiate the ciphersuite used to protect the EAP
conversation, as well as to integrity protect the negotiation.
[RFC4017] requires EAP methods satisfying this security claim.
In terms of key strength and freshness, [RFC3748] Section 10 says: Diameter [RFC3588] provides support for cryptographic algorithm
negotiation via use of IPsec or TLS. RADIUS [RFC3579] does not
support the negotiation of cryptographic algorithms, and relies on
MD5 for integrity protection, authentication and confidentiality,
despite known weaknesses in the algorithm [MD5Attack]. This issue
can be addressed via use of RADIUS over IPsec, as described in
[RFC3579] Section 4.2.
EAP methods SHOULD ensure the freshness of the MSK and EMSK even As a result, EAP methods and AAA protocols are capable of addressing
in cases where one party may not have a high quality random number downgrade attacks. To ensure against downgrade attacks within lower
generator.... In order to preserve algorithm independence, EAP layer protocols, algorithm independence is REQUIRED with lower layers
methods deriving keys SHOULD support (and document) the protected using EAP for key derivation. For interoperability, at least one
negotiation of the ciphersuite used to protect the EAP suite of mandatory-to-implement algorithm MUST be selected. Lower
conversation between the peer and server... In order to enable layer protocols supporting EAP for key derivation SHOULD also support
deployments requiring strong keys, EAP methods supporting key secure ciphersuite negotiation. As described in [RFC1968], PPP ECP
derivation SHOULD be capable of generating an MSK and EMSK, each does not provide support for secure ciphersuite negotiation.
with an effective key strength of at least 128 bits. However, [IEEE-802.11i] does support secure ciphersuite negotiation.
The authenticator and backend authentication server communicate using 5.6. Unauthorized Disclosure
a AAA protocol such as RADIUS [RFC3579] or Diameter [I-D.ietf-aaa-
eap]. As noted in [RFC3588] Section 13, Diameter must be protected
by either IPsec ESP with non-null transform or TLS. As a result,
Diameter requires per-packet integrity and confidentiality. Replay
protection must be supported. For RADIUS, [RFC3579] Section 4.2
recommends that RADIUS be protected by IPsec ESP with a non-null
transform, and where IPsec is implemented replay protection must be
supported.
The peer and authenticator communicate using the Secure Association While preserving algorithm independence, confidentiality of all
Protocol. keying material MUST be maintained. To prevent unauthorized disclose
of keys, each party in the EAP conversation MUST be authenticated to
the other parties with whom it communicates. Keying material MUST be
bound to the appropriate context.
As noted in the figure, each party in the exchange mutually [RFC3748] Section 7.2.1 describes the "mutual authentication" and
authenticates with each of the other parties, and derives a unique "dictionary attack resistance" claims, and [RFC4017] requires EAP
key. All parties in the diagram have access to the AAA-Key. methods satisfying these claims. EAP methods complying with
[RFC4017] therefore provide for mutual authentication between the EAP
peer and server. Binding of EAP keying material (MSK, EMSK) to the
appropriate context is provided by the Peer-ID and Server-ID which
are exported along with the keying material.
The EAP peer and backend authentication server mutually authenticate Diameter [RFC3588] provides for per-packet authentication and
via the EAP method, and derive the TEKs and EMSK which are known only integrity protection via IPsec or TLS, and RADIUS/EAP [RFC3579] also
to them. The TEKs are used to protect some or all of the EAP provides for per-packet authentication and integrity protection.
conversation between the peer and authenticator, so as to guard Where the NAS/authenticator and AAA server communicate directly and
against modification or insertion of EAP packets by an attacker. The credible keywrap is used (see Section 3.7), this ensures that the AAA
degree of protection afforded by the TEKs is determined by the EAP Key Transport phase achieves its security objectives: mutually
method; some methods may protect the entire EAP packet, including the authenticating the AAA client/authenticator and AAA server and
EAP header, while other methods may only protect the contents of the providing EAP keying material to the EAP authenticator and to no
Type-Data field, defined in [RFC3748]. other party.
Since EAP is spoken only between the EAP peer and server, if a As noted in Section 3.1, the Secure Association Protocol does not by
backend authentication server is present then the EAP conversation itself provide for mutual authentication between the EAP peer and
does not provide mutual authentication between the peer and authenticator, even if mutual possession of EAP keying material is
authenticator, only between the EAP peer and EAP server (backend proven. However, where the NAS/authenticator and AAA server
authentication server). As a result, mutual authentication between communicate directly, the AAA server can verify the correspondence
the peer and authenticator only occurs where a Secure Association between NAS identification attributes, the source address of packets
protocol is used, such the unicast and group key derivation handshake sent by the NAS, and the AAA credentials. As long as the NAS has not
supported in [IEEE-802.11i]. This means that absent use of a secure shared its AAA credentials with another NAS, this allows the AAA
Association Protocol, from the point of view of the peer, EAP mutual server to authenticate the NAS. Using Channel Bindings, the EAP peer
authentication only proves that the authenticator is trusted by the can then determine whether the NAS/authenticator has provided the
backend authentication server; the identity of the authenticator is same identifying information to the EAP peer and AAA server.
not confirmed.
Utilizing the AAA protocol, the authenticator and backend Peer and authenticator authorization MUST be performed.
authentication server mutually authenticate and derive session keys Authorization is REQUIRED whenever a peer associates with a new
known only to them, used to provide per-packet integrity and replay authenticator. Authorization checking prevents an elevation of
protection, authentication and confidentiality. The AAA-Key is privilege attack, and ensures that an unauthorized authenticator is
distributed by the backend authentication server to the authenticator detected. Authorizations SHOULD be synchronized between the EAP
over this channel, bound to attributes constraining its usage, as peer, server, authenticator. Once the EAP conversation exchanges are
part of the AAA-Token. The binding of attributes to the AAA-Key complete, all of these parties should hold the same view of the
within a protected package is important so the authenticator authorizations associated the other parties. If peer authorization
receiving the AAA-Token can determine that it has not been is restricted, then the peer SHOULD be made aware of the restriction.
compromised, and that the keying material has not been replayed, or
mis-directed in some way.
The security properties of the EAP exchange are dependent on each leg The AAA exchange provides the EAP authenticator with authorizations
of the triangle: the selected EAP method, AAA protocol and the Secure relating to the EAP peer. However, neither the EAP nor AAA exchanges
Association Protocol. provides authorizations to the EAP peer. In order to ensure that all
parties hold the same view of the authorizations it is RECOMMENDED
that the Secure Association Protocol enable communication of
authorizations between the EAP authenticator and peer.
Assuming that the AAA protocol provides protection against rogue In order to enable key binding and authorization of all parties, it
authenticators forging their identity, then the AAA-Token can be is RECOMMENDED that the parties use a set of identities that are
assumed to be sent to the correct authenticator, and where it is consistent between the conversation phases. RADIUS [RFC2865] and
wrapped appropriately, it can be assumed to be immune to compromise Diameter NASREQ [RFC4005] require that the NAS/EAP authenticator
by a snooping attacker. identify itself by including one or more identification attributes
within an Access-Request packet (NAS-Identifier, NAS-IP-Address, NAS-
IPv6-Address).
Where an untrusted AAA intermediary is present, the AAA-Token must Since the AAA server provides EAP keying material for use by the EAP
not be provided to the intermediary so as to avoid compromise of the authenticator as identified by these attributes, where an EAP
AAA-Token. This can be avoided by use of re-direct as defined in authenticator may have multiple ports, it is RECOMMENDED for the EAP
[RFC3588]. authenticator to identify itself using NAS identification attributes
during the Secure Association Protocol exchange with the EAP peer.
This enables the EAP peer to determine whether EAP keying material
has been shared between EAP authenticators as well as to confirm with
the AAA server that an EAP authenticator proving possession of EAP
keying material during the Secure Association Protocol was authorized
to obtain it. Typically, the NAS-Identifier attribute is most
convenient for this purpose, since a NAS/authenticator may have
multiple IP addresses.
When EAP is used for authentication on PPP or wired IEEE 802 Similarly, the AAA server authorizes the EAP authenticator to provide
networks, it is typically assumed that the link is physically secure, access to the EAP peer identified by the Peer-ID, securely verified
so that an attacker cannot gain access to the link, or insert a rogue during the EAP authentication exchange. In order to determine
device. EAP methods defined in [RFC3748] reflect this usage model. whether EAP keying material has been shared between EAP peers, where
These include EAP MD5, as well as One-Time Password (OTP) and Generic the EAP peer has multiple ports it is RECOMMENDED for the EAP peer to
Token Card. These methods support one-way authentication (from EAP identify itself using the Peer-ID during the Secure Association
peer to authenticator) but not mutual authentication or key Protocol exchange with the EAP authenticator.
derivation. As a result, these methods do not bind the initial
authentication and subsequent data traffic, even when the the
ciphersuite used to protect data supports per-packet authentication
and integrity protection. As a result, EAP methods not supporting
mutual authentication are vulnerable to session hijacking as well as
attacks by rogue devices.
On wireless networks such as IEEE 802.11 [IEEE-802.11], these attacks 5.7. Replay Protection
become easy to mount, since any attacker within range can access the
wireless medium, or act as an access point. As a result, new
ciphersuites have been proposed for use with wireless LANs
[IEEE-802.11i] which provide per-packet authentication, integrity and
replay protection. In addition, mutual authentication and key
derivation, provided by methods such as EAP-TLS [RFC2716] are
required [IEEE-802.11i], so as to address the threat of rogue
devices, and provide keying material to bind the initial
authentication to subsequent data traffic.
If the selected EAP method does not support mutual authentication, Replay protection allows a protocol message recipient to discard any
then the peer will be vulnerable to attack by rogue authenticators message that was recorded during a previous legitimate dialogue and
and backend authentication servers. If the EAP method does not derive presented as though it belonged to the current dialogue.
keys, then TSKs will not be available for use with a negotiated
ciphersuite, and there will be no binding between the initial EAP
authentication and subsequent data traffic, leaving the session
vulnerable to hijack.
If the backend authentication server does not protect against [RFC3748] Section 7.2.1 describes the "replay protection" security
authenticator masquerade, or provide the proper binding of the AAA- claim and [RFC4017] requires use of EAP methods supporting this
Key to the session within the AAA-Token, then one or more AAA-Keys claim.
may be sent to an unauthorized party, and an attacker may be able to
gain access to the network. If the AAA-Token is provided to an
untrusted AAA intermediary, then that intermediary may be able to
modify the AAA-Key, or the attributes associated with it, as
described in [RFC2607].
If the Secure Association Protocol does not provide mutual proof of Diameter [RFC3588] provides support for replay protection via use of
possession of the AAA-Key material, then the peer will not have IPsec or TLS. RADIUS/EAP [RFC3579] protects against replay of keying
assurance that it is connected to the correct authenticator, only material via the Request Authenticator. However, some RADIUS packets
that the authenticator and backend authentication server share a are not replay protected. In Accounting, Disconnect and CoA-Request
trust relationship (since AAA protocols support mutual packets the Request Authenticator contains a keyed MAC rather than a
authentication). This distinction can become important when multiple Nonce. The Response Authenticator in Accounting, Disconnect and CoA
authenticators receive AAA-Keys from the backend authentication Response packets also contains a keyed MAC whose calculation does not
server, such as where fast handoff is supported. If the TSK depend on a Nonce in either the Request or Response packets.
derivation does not provide for protected ciphersuite and Therefore unless an Event-Timestamp attribute is included or IPsec is
capabilities negotiation, then downgrade attacks are possible. used, the recipient may not be able to determine whether these
packets have been replayed.
6.4. Man-in-the-middle Attacks In order to prevent replay of Secure Association Protocol frames,
replay protection is REQUIRED on all messages. [IEEE-802.11i]
supports replay protection on all messages within the 4-way
handshake.
5.8. Key Freshness
A session key should be considered compromised if it remains in use
too long. As noted in [Housley], session keys MUST be strong and
fresh, while preserving algorithm independence. A fresh
cryptographic key is one that is generated specifically for the
intended use. Each session deserves an independent session key;
disclosure of one session key MUST NOT aid the attacker in
discovering any other session keys.
Fresh keys are required even when a long replay counter (that is, one
that "will never wrap") is used to ensure that loss of state does not
cause the same counter value to be used more than once with the same
session key.
EAP, AAA and the lower layer each bear responsibility for ensuring
the use of fresh, strong session keys:
EAP EAP methods need to ensure the freshness and strength of EAP keying
material provided as an input to session key derivation. [RFC3748]
Section 7.10 states that "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 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." The contribution of nonces
enables the EAP peer and server to ensure that exported EAP keying
material is fresh.
[RFC3748] Section 7.2.1 describes the "key strength" and "session
independence" security claims, and and [RFC4017] requires use of
EAP methods supporting these claims as well as being capable of
providing an equivalent key strength of 128 bits or greater.
AAA The AAA protocol needs to ensure that transported keying material
is fresh and is not utilized outside its recommended lifetime.
Replay protection is necessary for key freshness, but an attacker
can deliver a stale (and therefore potentially compromised) key in
a replay-protected message, so replay protection is not sufficient.
The EAP Session-ID, derived from the EAP Type and Method-ID (based
on the nonces contributed by the peer and server) enables the EAP
peer, authenticator and server to distinguish EAP conversations.
However, unless the authenticator keeps track of EAP Session-IDs,
the authenticator cannot use the Session-ID to guarantee the
freshness of EAP keying material.
As described in [RFC3580] Section 3.17, When sent in an Access-
Accept along with a Termination-Action value of RADIUS-Request, the
Session-Timeout attribute specifies the maximum number of seconds
of service provided prior to re-authentication. [IEEE-802.11i]
also utilizes the Session-Timeout attribute to limit the maximum
time that EAP keying material may be cache. Therefore the use of
the Session-Timeout attribute enables the AAA server to limit the
exposure of EAP keying material.
Lower Layer
The lower layer Secure Association Protocol MUST generate a fresh
session key for each session, even if the keying material and
parameters provided by EAP methods are cached, or the peer or
authenticator lacks a high entropy random number generator. A
RECOMMENDED method is for the peer and authenticator to each
provide a nonce or counter of at least 128 bits, used in session
key derivation.
5.9. Elevation of Privilege
Parties MUST NOT have access to keying material that is not needed to
perform their own role. A party has access to a particular key if it
has access to all of the secret information needed to derive it. If
a post-EAP handshake is used to establish session keys, the post-EAP
handshake MUST specify the scope for session keys.
Transported EAP keying material is permitted to be accessed by the
EAP peer, authenticator and server. The EAP peer and server derive
the transported keying material during the process of mutually
authenticating each other using the selected EAP method. During the
Secure Association Protocol, the EAP peer utilizes the transported
EAP keying material to demonstrate to the authenticator that it is
the same party that authenticated to the EAP server and was
authorized by it. The EAP authenticator utilizes the transported EAP
keying material to prove to the peer not only that the EAP
conversation was transported through it (this could be demonstrated
by a man-in-the-middle), but that it was uniquely authorized by the
EAP server to provide the peer with access to the network. Unique
authorization can only be demonstrated if the EAP authenticator does
not share the transported keying material with a party other than the
EAP peer and server.
TSKs are permitted to be accessed only by the EAP peer and
authenticator. Since the TSKs can be determined from the transported
EAP keying material and the cleartext of the Secure Association
Protocol exchange, the AAA server will have access to the TSKs unless
it deletes the transported EAP keying material after sending it.
5.10. Man-in-the-middle Attacks
As described in [I-D.puthenkulam-eap-binding], EAP method sequences As described in [I-D.puthenkulam-eap-binding], EAP method sequences
and compound authentication mechanisms may be subject to man-in-the- and compound authentication mechanisms may be subject to man-in-the-
middle attacks. When such attacks are successfully carried out, the middle attacks. When such attacks are successfully carried out, the
attacker acts as an intermediary between a victim and a legitimate attacker acts as an intermediary between a victim and a legitimate
authenticator. This allows the attacker to authenticate successfully authenticator. This allows the attacker to authenticate successfully
to the authenticator, as well as to obtain access to the network. to the authenticator, as well as to obtain access to the network.
In order to prevent these attacks, [I-D.puthenkulam-eap-binding] In order to prevent these attacks, [I-D.puthenkulam-eap-binding]
recommends derivation of a compound key by which the EAP peer and recommends derivation of a compound key by which the EAP peer and
server can prove that they have participated in the entire EAP server can prove that they have participated in the entire EAP
exchange. Since the compound key must not be known to an attacker exchange. Since the compound key must not be known to an attacker
posing as an authenticator, and yet must be derived from quantities posing as an authenticator, and yet must be derived from quantities
that are exported by EAP methods, it may be desirable to derive the that are exported by EAP methods, it may be desirable to derive the
compound key from a portion of the EMSK. In order to provide proper compound key from a portion of the EMSK. In order to provide proper
key hygiene, it is recommended that the compound key used for man-in- key hygiene, it is recommended that the compound key used for man-in-
the-middle protection be cryptographically separate from other keys the-middle protection be cryptographically separate from other keys
derived from the EMSK, such as fast handoff keys, discussed in derived from the EMSK.
Section 2.3.
6.5. Denial of Service Attacks 5.11. Denial of Service Attacks
The caching of security associations may result in vulnerability to Key caching may result in vulnerability to denial of service attacks.
denial of service attacks. Since an EAP peer may derive multiple EAP For example, EAP methods that create persistent state may be
SAs with a given EAP server, and creation of a new EAP SA does not vulnerable to denial of service attacks on the EAP server by a rogue
implicitly delete a previous EAP SA, EAP methods that result in EAP peer.
creation of persistent state may be vulnerable to denial of service
attacks by a rogue EAP peer.
As a result, EAP methods creating persistent state may wish to limit To address this vulnerability, EAP methods creating persistent state
the number of cached EAP SAs (Phase 1a) corresponding to an EAP peer. may wish to limit the persistent state created by an EAP peer. For
For example, an EAP server may choose to only retain a few EAP SAs example, for each peer an EAP server may choose to limit persistent
for each peer. This prevents a rogue peer from denying access to state to a few EAP conversations, distinguished by the EAP Session-
other peers. ID. This prevents a rogue peer from denying access to other peers.
Similarly, an authenticator may have multiple AAA-Key SAs Similarly, to conserve resources an authenticator may choose to limit
corresponding to a given EAP peer; to conserve resources an the persistent state corresponding to each peer. This can be
authenticator may choose to limit the number of cached AAA-Key (Phase accomplished by limiting each peer to persistent sttate corresponding
1 b) SAs for each peer. to a few EAP converations, distinguished by the EAP Session-ID.
Depending on the media, creation of a new unicast Secure Association Depending on the media, creation of new TSKs may or may not imply
SA may or may not imply deletion of a previous unicast secure deletion of previously derived TSKs. Where there is no implied
association SA. Where there is no implied deletion, the deletion, the authenticator may choose to limit the number of TSKs
authenticator may choose to limit Phase 2 (unicast and multicast) and associated state that can be stored for each peer.
Secure Association SAs for each peer.
6.6. Impersonation 5.12. Impersonation
Both the RADIUS and Diameter protocols are potentially vulnerable to Both the RADIUS and Diameter protocols are potentially vulnerable to
impersonation by a rogue authenticator. impersonation by a rogue authenticator.
While AAA protocols such as RADIUS [RFC2865] or Diameter [RFC3588] While AAA protocols such as RADIUS [RFC2865] or Diameter [RFC3588]
support mutual authentication between the authenticator (known as the support mutual authentication between the authenticator (known as the
AAA client) and the backend authentication server (known as the AAA AAA client) and the backend authentication server (known as the AAA
server), the security mechanisms vary according to the AAA protocol. server), the security mechanisms vary according to the AAA protocol.
In RADIUS, the shared secret used for authentication is determined by In RADIUS, the shared secret used for authentication is determined by
skipping to change at page 49, line 25 skipping to change at page 42, line 47
Section 3 states: Section 3 states:
A RADIUS server MUST use the source IP address of the RADIUS A RADIUS server MUST use the source IP address of the RADIUS
UDP packet to decide which shared secret to use, so that UDP packet to decide which shared secret to use, so that
RADIUS requests can be proxied. RADIUS requests can be proxied.
This implies that it is possible for a rogue authenticator to forge This implies that it is possible for a rogue authenticator to forge
NAS-IP-Address, NAS-IPv6-Address or NAS-Identifier attributes within NAS-IP-Address, NAS-IPv6-Address or NAS-Identifier attributes within
a RADIUS Access-Request in order to impersonate another a RADIUS Access-Request in order to impersonate another
authenticator. Among other things, this can result in messages (and authenticator. Among other things, this can result in messages (and
MSKs) being sent to the wrong authenticator. Since the rogue transorted keying material) being sent to the wrong authenticator.
authenticator is authenticated by the RADIUS proxy or server purely Since the rogue authenticator is authenticated by the RADIUS proxy or
based on the source address, other mechanisms are required to detect server purely based on the source address, other mechanisms are
the forgery. In addition, it is possible for attributes such as the required to detect the forgery. In addition, it is possible for
Called-Station-Id and Calling-Station-Id to be forged as well. attributes such as the Called-Station-Id and Calling-Station-Id to be
forged as well.
As recommended in [RFC3579], this vulnerability can be mitigated by
having RADIUS proxies check authenticator identification attributes
against the source address.
To allow verification of session parameters such as the Called- As recommended in [RFC3579] Section 4.3.7, this vulnerability can be
Station- Id and Calling-Station-Id, these can be sent by the EAP peer mitigated by having RADIUS proxies check NAS identification
to the server, protected by the TEKs. The RADIUS server can then attributes against the source address.
check the parameters sent by the EAP peer against those claimed by
the authenticator. If a discrepancy is found, an error can be
logged.
While [RFC3588] requires use of the Route-Record AVP, this utilizes While [RFC3588] requires use of the Route-Record AVP, this utilizes
FQDNs, so that impersonation detection requires DNS A/AAAA and PTR FQDNs, so that impersonation detection requires DNS A/AAAA and PTR
RRs to be properly configured. As a result, it appears that Diameter RRs to be properly configured. As a result, it appears that Diameter
is as vulnerable to this attack as RADIUS, if not more so. To address is as vulnerable to this attack as RADIUS, if not more so. To
this vulnerability, it is necessary to allow the backend address this vulnerability, it is necessary to allow the backend
authentication server to communicate with the authenticator directly, authentication server to communicate with the authenticator directly,
such as via the redirect functionality supported in [RFC3588]. such as via the redirect functionality supported in [RFC3588].
6.7. Channel binding 5.13. Channel Binding
It is possible for a compromised or poorly implemented EAP It is possible for a compromised or poorly implemented EAP
authenticator to communicate incorrect information to the EAP peer authenticator to communicate incorrect information to the EAP peer
and/or server. This may enable an authenticator to impersonate and/or server. This may enable an authenticator to impersonate
another authenticator or communicate incorrect information via out- another authenticator or communicate incorrect information via out-
of-band mechanisms (such as via AAA or the lower layer protocol). of-band mechanisms (such as via AAA or the lower layer).
Where EAP is used in pass-through mode, the EAP peer typically does Where EAP is used in pass-through mode, the EAP peer does not verify
not verify the identity of the pass-through authenticator, it only the identity of the pass-through authenticator. Within the Secure
verifies that the pass-through authenticator is trusted by the EAP Association Protocol, the EAP peer and authenticator only demonstrate
server. This creates a potential security vulnerability, described in mutual possession of the transported EAP keying material. This
[RFC3748] Section 7.15. creates a potential security vulnerability, described in [RFC3748]
Section 7.15.
[RFC3579] Section 4.3.7 describes how an EAP pass-through [RFC3579] Section 4.3.7 describes how an EAP pass-through
authenticator acting as a AAA client can be detected if it attempts authenticator acting as a AAA client can be detected if it attempts
to impersonate another authenticator (such by sending incorrect NAS- to impersonate another authenticator (such by sending incorrect
Identifier [RFC2865], NAS-IP-Address [RFC2865] or NAS-IPv6-Address Called-Station-ID [RFC2865], NAS-Identifier [RFC2865], NAS-IP-Address
[RFC3162] attributes via the AAA protocol). However, it is possible [RFC2865] or NAS-IPv6-Address [RFC3162] attributes via the AAA
for a pass-through authenticator acting as a AAA client to provide protocol). However, it is possible for a pass-through authenticator
correct information to the AAA server while communicating misleading acting as a AAA client to provide correct information to the AAA
information to the EAP peer via a lower layer protocol. server while communicating misleading information to the EAP peer via
the lower layer.
For example, it is possible for a compromised authenticator to For example, a compromised authenticator can utilize another
utilize another authenticator's Called-Station-Id or NAS-Identifier authenticator's Called-Station-Id or NAS-Identifier in communicating
in communicating with the EAP peer via a lower layer protocol, or for with the EAP peer via the lower layer, or for a pass-through
a pass-through authenticator acting as a AAA client to provide an authenticator acting as a AAA client to provide an incorrect peer
incorrect peer Calling-Station-Id [RFC2865][RFC3580] to the AAA Calling-Station-Id [RFC2865][RFC3580] to the AAA server via the AAA
server via the AAA protocol. protocol.
As noted in [RFC3748] Section 7.15, this vulnerability can be As noted in [RFC3748] Section 7.15, this vulnerability can be
addressed by use of EAP methods that support a protected exchange of addressed by EAP methods that support a protected exchange of channel
channel properties such as endpoint identifiers, including (but not properties such as endpoint identifiers, including (but not limited
limited to): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id to): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id
[RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address [RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address
[RFC2865], and NAS-IPv6-Address [RFC3162]. [RFC2865], and NAS-IPv6-Address [RFC3162].
Using such a protected exchange, it is possible to match the channel Using such a protected exchange, it is possible to match the channel
properties provided by the authenticator via out-of-band mechanisms properties provided by the authenticator via out-of-band mechanisms
against those exchanged within the EAP method. For example, see against those exchanged within the EAP method. For example, see [I-
[ServiceIdent]. D.arkko-eap-service-identity-auth].
7. Security Requirements
This section summarizes the security requirements that must be met by
EAP methods, AAA protocols, Secure Association Protocols and
Ciphersuites in order to address the security threats described in
this document. These requirements MUST be met by specifications
requesting publication as an RFC. Each requirement provides a
pointer to the sections of this document describing the threat that
it mitigates.
7.1. EAP Method Requirements
It is possible for the peer and EAP server to mutually authenticate
and derive keys. In order to provide keying material for use in a
subsequently negotiated ciphersuite, an EAP method supporting key
derivation MUST export a Master Session Key (MSK) of at least 64
octets, and an Extended Master Session Key (EMSK) of at least 64
octets. EAP Methods deriving keys MUST provide for mutual
authentication between the EAP peer and the EAP Server.
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
subsequently used to derive Transient Session Keys (TSKs) for use
with the selected ciphersuite. Each ciphersuite is responsible for
specifying how to derive the TSKs from the AAA-Key.
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
many existing protocols that use EAP, the AAA-Key and MSK are
equivalent, but more complicated mechanisms are possible.
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
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.
EAP methods export the MSK and EMSK and not Transient Session Keys so
as to allow EAP methods to be ciphersuite and media independent.
Keying material exported by EAP methods MUST be independent of the
ciphersuite negotiated to protect data.
Depending on the lower layer, EAP methods may run before or after
ciphersuite negotiation, so that the selected ciphersuite may not be
known to the EAP method. By providing keying material usable with
any ciphersuite, EAP methods can used with a wide range of
ciphersuites and media.
It is RECOMMENDED that methods providing integrity protection of EAP
packets include coverage of all the EAP header fields, including the
Code, Identifier, Length, Type and Type-Data fields.
In order to preserve algorithm independence, EAP methods deriving
keys SHOULD support (and document) the protected negotiation of the
ciphersuite used to protect the EAP conversation between the peer and
server. This is distinct from the ciphersuite negotiated between the
peer and authenticator, used to protect data.
The strength of Transient Session Keys (TSKs) used to protect data is
ultimately dependent on the strength of keys generated by the EAP
method. If an EAP method cannot produce keying material of
sufficient strength, then the TSKs may be subject to brute force
attack. In order to enable deployments requiring strong keys, EAP
methods supporting key derivation SHOULD be capable of generating an
MSK and EMSK, each with an effective key strength of at least 128
bits.
Methods supporting key derivation MUST demonstrate cryptographic
separation between the MSK and EMSK branches of the EAP key
hierarchy. Without violating a fundamental cryptographic assumption
(such as the non-invertibility of a one-way function) an attacker
recovering the MSK or EMSK MUST NOT be able to recover the other
quantity with a level of effort less than brute force.
Non-overlapping substrings of the MSK MUST be cryptographically
separate from each other. That is, knowledge of one substring MUST
NOT help in recovering some other non-overlapping substring without
breaking some hard cryptographic assumption. This is required
because some existing ciphersuites form TSKs by simply splitting the
AAA-Key to pieces of appropriate length. Likewise, non-overlapping
substrings of the EMSK MUST be cryptographically separate from each
other, and from substrings of the MSK. The EMSK MUST NOT be
transported to, or shared with, additional parties.
Since EAP does not provide for explicit key lifetime negotiation, EAP
peers, authenticators and authentication servers MUST be prepared for
situations in which one of the parties discards key state which
remains valid on another party.
The development and validation of key derivation algorithms is
difficult, and as a result EAP methods SHOULD reuse well established
and analyzed mechanisms for MSK and EMSK key derivation (such as
those specified in IKE [RFC2409] or TLS [RFC2246]), rather than
inventing new ones.
7.1.1. Requirements for EAP methods
In order for an EAP method to meet the guidelines for EMSK usage it
must meet the following requirements:
o It MUST specify how to derive the EMSK
o The key material used for the EMSK MUST be
computationally independent of the MSK and TEKs.
o The EMSK MUST NOT be used for any other purpose than the key
derivation described in this document.
o The EMSK MUST be secret and not known to someone observing
the authentication mechanism protocol exchange.
o The EMSK MUST NOT be exported from the EAP server.
o The EMSK MUST be unique for each session.
o The EAP mechanism SHOULD a unique identifier suitable for naming the EMSK.
7.1.2. Requirements for EAP applications
In order for an application to meet the guidelines for EMSK usage it
must meet the following requirements:
o New applications following this specification SHOULD NOT use the
MSK. If more than one application uses the MSK, then the
cryptographic separation is not achieved. Implementations SHOULD
prevent such combinations.
o A peer MUST NOT use the EMSK directly for cryptographic
protection of data.
7.2. AAA Protocol Requirements
AAA protocols suitable for use in transporting EAP MUST provide the
following facilities:
Security services
AAA protocols used for transport of EAP keying material MUST
implement and SHOULD use per-packet integrity and authentication,
replay protection and confidentiality. These requirements are met
by Diameter EAP [I-D.ietf-aaa-eap], as well as RADIUS over IPsec
[RFC3579].
Session Keys
AAA protocols used for transport of EAP keying material MUST
implement and SHOULD use dynamic key management in order to derive
fresh session keys, as in Diameter EAP [I-D.ietf-aaa-eap] and
RADIUS over IPsec [RFC3579], rather than using a static key, as
originally defined in RADIUS [RFC2865].
Mutual authentication
AAA protocols used for transport of EAP keying material MUST
provide for mutual authentication between the authenticator and
backend authentication server. These requirements are met by
Diameter EAP [I-D.ietf-aaa-eap] as well as by RADIUS EAP [RFC3579].
Authorization
AAA protocols used for transport of EAP keying material SHOULD
provide protection against rogue authenticators masquerading as
other authenticators. This can be accomplished, for example, by
requiring that AAA agents check the source address of packets
against the origin attributes (Origin-Host AVP in Diameter, NAS-IP-
Address, NAS-IPv6-Address, NAS-Identifier in RADIUS). For details,
see [RFC3579] Section 4.3.7.
Key transport
Since EAP methods do not export Transient Session Keys (TSKs) in
order to maintain media and ciphersuite independence, the AAA
server MUST NOT transport TSKs from the backend authentication
server to authenticator.
Key transport specification
In order to enable backend authentication servers to provide keying
material to the authenticator in a well defined format, AAA
protocols suitable for use with EAP MUST define the format and
wrapping of the AAA-Token.
EMSK transport
Since the EMSK is a secret known only to the backend authentication
server and peer, the AAA-Token MUST NOT transport the EMSK from the
backend authentication server to the authenticator.
AAA-Token protection
To ensure against compromise, the AAA-Token MUST be integrity
protected, authenticated, replay protected and encrypted in
transit, using well-established cryptographic algorithms.
Session Keys
The AAA-Token SHOULD be protected with session keys as in Diameter
[RFC3588] or RADIUS over IPsec [RFC3579] rather than static keys,
as in [RFC2548].
Key naming
In order to ensure against confusion between the appropriate keying
material to be used in a given Secure Association Protocol
exchange, the AAA-Token SHOULD include explicit key names and
context appropriate for informing the authenticator how the keying
material is to be used.
Key Compromise
Where untrusted intermediaries are present, the AAA-Token SHOULD
NOT be provided to the intermediaries. In Diameter, handling of
keys by intermediaries can be avoided using Redirect functionality
[RFC3588].
7.3. Secure Association Protocol Requirements
The Secure Association Protocol supports the following:
Entity Naming
The peer and authenticator SHOULD identify themselves in a manner
that is independent of their attached ports.
Mutual proof of possession
The peer and authenticator MUST each demonstrate possession of the
keying material transported between the backend authentication
server and authenticator (AAA-Key).
Key Naming
The Secure Association Protocol MUST explicitly name the keys used
in the proof of possession exchange, so as to prevent confusion
when more than one set of keying material could potentially be used
as the basis for the exchange.
Creation and Deletion
In order to support the correct processing of phase 2 security
associations, the Secure Association (phase 2) protocol MUST
support the naming of phase 2 security associations and associated
transient session keys, so that the correct set of transient
session keys can be identified for processing a given packet. The
phase 2 Secure Association Protocol also MUST support transient
session key activation and SHOULD support deletion, so that
establishment and re-establishment of transient session keys can be
synchronized between the parties.
Integrity and Replay Protection
The Secure Association Protocol MUST support integrity and replay
protection of all messages.
Direct operation
Since the phase 2 Secure Association Protocol is concerned with the
establishment of security associations between the EAP peer and
authenticator, including the derivation of transient session keys,
only those parties have "a need to know" the transient session
keys. The Secure Association Protocol MUST operate directly between
the peer and authenticator, and MUST NOT be passed-through to the
backend authentication server, or include additional parties.
Derivation of transient session keys
The Secure Association Protocol negotiation MUST support derivation
of unicast and multicast transient session keys suitable for use
with the negotiated ciphersuite.
TSK freshness
The Secure Association (phase 2) Protocol MUST support the
derivation of fresh unicast and multicast transient session keys,
even when the keying material provided by the backend
authentication server is not fresh. This is typically supported by
including an exchange of nonces within the Secure Association
Protocol.
Bi-directional operation
While some ciphersuites only require a single set of transient
session keys to protect traffic in both directions, other
ciphersuites require a unique set of transient session keys in each
direction. The phase 2 Secure Association Protocol SHOULD provide
for the derivation of unicast and multicast keys in each direction,
so as not to require two separate phase 2 exchanges in order to
create a bi-directional phase 2 security association.
Secure capabilities negotiation
The Secure Association Protocol MUST support secure capabilities
negotiation. This includes security parameters such as the
security association identifier (SAID) and ciphersuites, as well as
negotiation of the lifetime of the TSKs, AAA-Key and exported EAP
keys. Secure capabilities negotiation also includes confirmation
of the capabilities discovered during the discovery phase (phase
0), so as to ensure that the announced capabilities have not been
forged.
Key Scoping
The Secure Association Protocol MUST ensure the synchronization of
key scope between the peer and authenticator. This includes
negotiation of restrictions on key usage.
7.4. Ciphersuite Requirements
Ciphersuites suitable for keying by EAP methods MUST provide the
following facilities:
TSK derivation
In order to allow a ciphersuite to be usable within the EAP keying
framework, a specification MUST be provided describing how
transient session keys suitable for use with the ciphersuite are
derived from the AAA-Key.
EAP method independence It is also possible to achieve Channel Bindings without transporting
Algorithms for deriving transient session keys from the AAA-Key data over EAP. For example, see [draft-ohba-eap-aaakey-binding]. In
MUST NOT depend on the EAP method. However, algorithms for this approach the authenticator informs the backend server about the
deriving TEKs MAY be specific to the EAP method. Channel Binding parameters using AAA, and the backend server
calculates transported keying material based on this parameter set,
making it impossible for the peer and authenticator to complete the
Secure Association Protocol if there was a mismatch in the
parameters.
Cryptographic separation The main difference between these approaches is that Channel Binding
The TSKs derived from the AAA-Key MUST be cryptographically support within an EAP method may require upgrading or changing the
separate from each other. Similarly, TEKs MUST be EAP method, impacting both the peer and the server. Where Channel
cryptographically separate from each other. In addition, the TSKs Bindings are implemented in AAA, the peer, authenticator and the
MUST be cryptographically separate from the TEKs. backend server need to be upgraded, but the EAP method need not be
modified.
8. IANA Considerations 6. IANA Considerations
This document does not create any new name spaces nor does it This document does not create any new name spaces nor does it
allocate any protocol parameters. allocate any protocol parameters.
9. References 7. References
9.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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 7.2. Informative References
[Analysis]
He, C. and J. Mitchell, "Analysis of the 802.11i 4-Way
Handshake", Proceedings of the 2004 ACM Workshop on Wireless
Security, pp. 43-50, ISBN: 1-58113-925-X.
[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.
[Housley] Housley, R. and B. Aboba, "AAA Key Management", draft-housley- [Housley] Housley, R. and B. Aboba, "AAA Key Management", draft-housley-
aaa-key-mgmt-00.txt, Internet draft (work in progress), June aaa-key-mgmt-00.txt, Internet draft (work in progress), June
2005..IP [IEEE-802] Institute of Electrical and Electronics 2005.
Engineers, "IEEE Standards for Local and Metropolitan Area
Networks: Overview and Architecture", ANSI/IEEE Standard 802, [IEEE-802]
1990. Institute of Electrical and Electronics 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 59, line 16 skipping to change at page 46, line 42
[IEEE-03-155] [IEEE-03-155]
Aboba, B., "Fast Handoff Issues", IEEE 802.11 Working Group, Aboba, B., "Fast Handoff Issues", IEEE 802.11 Working Group,
IEEE-03-155r0-I, http://www.ieee802.org/11/ IEEE-03-155r0-I, http://www.ieee802.org/11/
Documents/DocumentHolder/3-155.zip, March 2003. Documents/DocumentHolder/3-155.zip, March 2003.
[I-D.ietf-roamops-cert] [I-D.ietf-roamops-cert]
Aboba, B., "Certificate-Based Roaming", draft-ietf-roamops- Aboba, B., "Certificate-Based Roaming", draft-ietf-roamops-
cert-02 (work in progress), April 1999. cert-02 (work in progress), April 1999.
[I-D.ietf-aaa-eap]
Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application", draft-ietf-aaa-
eap-10 (work in progress), November 2004.
[I-D.puthenkulam-eap-binding] [I-D.puthenkulam-eap-binding]
Puthenkulam, J., "The Compound Authentication Binding Puthenkulam, J., "The Compound Authentication Binding
Problem", draft-puthenkulam-eap-binding-04 (work in 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.
[I-D.arkko-eap-service-identity-auth]
Arkko, J. and P. Eronen, "Authenticated Service Information
for the Extensible Authentication Protocol (EAP)", draft-
arkko-eap-service-identity-auth-02.txt (work in progress), May
2005.
[I-D.ohba-eap-aaakey-binding]
Ohba, Y., "AAA-Key Derivation with Channel Binding", draft-
ohba-eap-aaakey-binding-00.txt (work in progress), May 2005.
[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] [MD5Attack]
Dobbertin, H., "The Status of MD5 After a Recent Attack", Dobbertin, H., "The Status of MD5 After a Recent Attack",
CryptoBytes, Vol.2 No.2, 1996. CryptoBytes, Vol.2 No.2, 1996.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981. September 1981.
skipping to change at page 61, line 6 skipping to change at page 48, line 39
"IEEE 802.1X Remote Authentication Dial In User Service "IEEE 802.1X Remote Authentication Dial In User Service
(RADIUS) Usage Guidelines", RFC 3580, September 2003. (RADIUS) Usage Guidelines", RFC 3580, September 2003.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public
Keys Used For Exchanging Symmetric Keys", RFC 3766, April Keys Used For Exchanging Symmetric Keys", RFC 3766, April
2004. 2004.
[RFC4005] Calhoun, P., Zorn, G., Spence, D. and D. Mitton, "Diameter
Network Access Server Application", RFC 4005, August 2005.
[RFC4017] Stanley, D., Walker, J. and B. Aboba, "EAP Method Requirements [RFC4017] Stanley, D., Walker, J. and B. Aboba, "EAP Method Requirements
for Wireless LANs", RFC 4017, March 2005. for Wireless LANs", RFC 4017, March 2005.
[RFC4072] Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application", RFC 4072, August
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.
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
skipping to change at page 63, line 5 skipping to change at page 51, line 5
Henrik Levkowetz (editor) Henrik Levkowetz (editor)
ipUnplugged AB ipUnplugged AB
Arenavagen 27 Arenavagen 27
Stockholm S-121 28 Stockholm S-121 28
SWEDEN SWEDEN
Phone: +46 708 32 16 08 Phone: +46 708 32 16 08
EMail: henrik@levkowetz.com EMail: henrik@levkowetz.com
Appendix A - Ciphersuite Keying Requirements Appendix A - EAP-TLS Key Hierarchy
To date, PPP and IEEE 802.11 ciphersuites are suitable for keying by
EAP. This Appendix describes the keying requirements of common PPP
and 802.11 ciphersuites.
PPP ciphersuites include DESEbis [RFC2419], 3DES [RFC2420], and MPPE
[RFC3078]. The DES algorithm is described in [FIPSDES], and DES
modes (such as CBC, used in [RFC2419] and DES-EDE3-CBC, used in
[RFC2420]) are described in [DESMODES]. For PPP DESEbis, a single
56-bit encryption key is required, used in both directions. For PPP
3DES, a 168-bit encryption key is needed, used in both directions. As
described in [RFC2419] for DESEbis and [RFC2420] for 3DES, the IV,
which is different in each direction, is "deduced from an explicit
64-bit nonce, which is exchanged in the clear during the [ECP]
negotiation phase." There is therefore no need for the IV to be
provided by EAP.
For MPPE, 40-bit, 56-bit or 128-bit encryption keys are required in
each direction, as described in [RFC3078]. No initialization vector
is required.
While these PPP ciphersuites provide encryption, they do not provide
per-packet authentication or integrity protection, so an
authentication key is not required in either direction.
Within [IEEE-802.11], Transient Session Keys (TSKs) are required both
for unicast traffic as well as for multicast traffic, and therefore
separate key hierarchies are required for unicast keys and multicast
keys. IEEE 802.11 ciphersuites include WEP-40, described in
[IEEE-802.11], which requires a 40-bit encryption key, the same in
either direction; and WEP-128, which requires a 104-bit encryption
key, the same in either direction. These ciphersuites also do not
support per-packet authentication and integrity protection. In
addition to these unicast keys, authentication and encryption keys
are required to wrap the multicast encryption key.
Recently, new ciphersuites have been proposed for use with IEEE
802.11 that provide per-packet authentication and integrity
protection as well as encryption [IEEE-802.11i]. These include TKIP,
which requires a single 128-bit encryption key and two 64-bit
authentication keys (one for each direction); and AES CCMP, which
requires a single 128-bit key (used in both directions) in order to
authenticate and encrypt data.
As with WEP, authentication and encryption keys are also required to
wrap the multicast encryption (and possibly, authentication) keys.
Appendix B - Transient EAP Key (TEK) Hierarchy
Figure B-1 illustrates the TEK key hierarchy for EAP-TLS [RFC2716],
which is based on the TLS key hierarchy described in [RFC2246]. The
TLS-negotiated ciphersuite is used to set up a protected channel for
use in protecting the EAP conversation, keyed by the derived TEKs.
The TEK derivation proceeds as follows:
master_secret = TLS-PRF-48(pre_master_secret, "master secret",
client.random || server.random)
TEK = TLS-PRF-X(master_secret, "key expansion",
server.random || client.random)
Where:
TLS-PRF-X = TLS pseudo-random function defined in [RFC2246],
computed to X octets.
| | |
| | pre_master_secret |
server| | | client
Random| V | Random
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| | | |
+---->| master_secret |<------+
| | (TMS) | |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | |
| | |
| | |
V V V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| Key Block |
| (TEKs) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| client | server | client | server | client | server
| MAC | MAC | write | write | IV | IV
| | | | | |
V V V V V V
Figure B-1 - TLS [RFC2246] Key Hierarchy EAP-TLS [RFC 2716] was documented prior to the development of EAP key
management terminology [RFC3748], and therefore does not explicitly
define the MSK and EMSK.
Appendix C - EAP-TLS Key Hierarchy In EAP-TLS, the MSK, EMSK and IV are derived from the TLS master
secret via a one-way function. This ensures that the TLS master
secret cannot be derived from the MSK, EMSK or IV unless the one-way
function (TLS PRF) is broken. Since the MSK is derived from the the
TLS master secret, if the TLS master secret is compromised then the
MSK is also compromised.
In EAP-TLS [RFC2716], the MSK is divided into two halves, [RFC2716] specifies that the MSK is divided into two halves,
corresponding to the "Peer to Authenticator Encryption Key" (Enc- corresponding to the "Peer to Authenticator Encryption Key" (Enc-
RECV-Key, 32 octets, also known as the PMK) and "Authenticator to RECV-Key, 32 octets, also known as the PMK) and "Authenticator to
Peer Encryption Key" (Enc-SEND-Key, 32 octets). In [RFC2548], the Peer Encryption Key" (Enc-SEND-Key, 32 octets). In [RFC2548], the
Enc-RECV-Key (the PMK) is transported in the MS-MPPE-Recv-Key Enc-RECV-Key (the PMK) is transported in the MS-MPPE-Recv-Key
attribute, and the Enc-SEND-Key is transported in the MS-MPPE-Send- attribute, and the Enc-SEND-Key is transported in the MS-MPPE-Send-
Key attribute. Key attribute.
The EMSK is also divided into two halves, corresponding to the "Peer The EMSK is also divided into two halves, corresponding to the "Peer
to Authenticator Authentication Key" (Auth-RECV-Key, 32 octets) and to Authenticator Authentication Key" (Auth-RECV-Key, 32 octets) and
"Authenticator to Peer Authentication Key" (Auth-SEND-Key, 32 "Authenticator to Peer Authentication Key" (Auth-SEND-Key, 32
octets). The IV is a 64 octet quantity that is a known value; octets octets). The IV is a 64 octet quantity that is a known value; octets
0-31 are known as the "Peer to Authenticator IV" or RECV-IV, and 0-31 are known as the "Peer to Authenticator IV" or RECV-IV, and
Octets 32-63 are known as the "Authenticator to Peer IV", or SEND-IV. Octets 32-63 are known as the "Authenticator to Peer IV", or SEND-IV.
In EAP-TLS, the MSK, EMSK and IV are derived from the TLS master The key derivation scheme MUST be interpreted as follows:
secret via a one-way function. This ensures that the TLS master
secret cannot be derived from the MSK, EMSK or IV unless the one-way
function (TLS PRF) is broken. Since the MSK is derived from the the
TLS master secret, if the TLS master secret is compromised then the
MSK is also compromised.
The key derivation scheme specified in RFC 2716 that was specified
prior to the introduction of the terminology MSK and EMSK MUST be
interpreted as follows:
MSK = TLS-PRF-64(TMS, "client EAP encryption", MSK = TLS-PRF-64(TMS, "client EAP encryption",
client.random || server.random) client.random || server.random)
EMSK = second 64 octets of: EMSK = second 64 octets of:
TLS-PRF-128(TMS, "client EAP encryption", TLS-PRF-128(TMS, "client EAP encryption",
client.random || server.random) client.random || server.random)
IV = TLS-PRF-64("", "client EAP encryption", IV = TLS-PRF-64("", "client EAP encryption",
client.random || server.random) client.random || server.random)
AAA-Key(0,31) = Peer to Authenticator Encryption Key (Enc-RECV-Key) MSK(0,31) = Peer to Authenticator Encryption Key (Enc-RECV-Key)
(MS-MPPE-Recv-Key in [RFC2548]). Also known as the (MS-MPPE-Recv-Key in [RFC2548]). Also known as the
PMK. PMK.
AAA-Key(32,63)= Authenticator to Peer Encryption Key (Enc-SEND-Key) MSK(32,63) = Authenticator to Peer Encryption Key (Enc-SEND-Key)
(MS-MPPE-Send-Key in [RFC2548]) (MS-MPPE-Send-Key in [RFC2548])
EMSK(0,31) = Peer to Authenticator Authentication Key (Auth-RECV-Key) EMSK(0,31) = Peer to Authenticator Authentication Key (Auth-RECV-Key)
EMSK(32,63) = Authenticator to Peer Authentication Key (Auth-Send-Key) EMSK(32,63) = Authenticator to Peer Authentication Key (Auth-Send-Key)
IV(0,31) = Peer to Authenticator Initialization Vector (RECV-IV) IV(0,31) = Peer to Authenticator Initialization Vector (RECV-IV)
IV(32,63) = Authenticator to Peer Initialization vector (SEND-IV) IV(32,63) = Authenticator to Peer Initialization vector (SEND-IV)
Where: Where:
AAA-Key(W,Z) = Octets W through Z includes of the AAA-Key.
IV(W,Z) = Octets W through Z inclusive of the IV. IV(W,Z) = Octets W through Z inclusive of the IV.
MSK(W,Z) = Octets W through Z inclusive of the MSK. MSK(W,Z) = Octets W through Z inclusive of the MSK.
EMSK(W,Z) = Octets W through Z inclusive of the EMSK. EMSK(W,Z) = Octets W through Z inclusive of the EMSK.
TMS = TLS master_secret TMS = TLS master_secret
TLS-PRF-X = TLS PRF function defined in [RFC2246] computed to X octets TLS-PRF-X = TLS PRF function defined in [RFC2246] computed to X octets
client.random = Nonce generated by the TLS client. client.random = Nonce generated by the TLS client.
server.random = Nonce generated by the TLS server. server.random = Nonce generated by the TLS server.
Figure C-1 describes the process by which the MSK,EMSK,IV and Figure A-1 illustrates the TEK key hierarchy for EAP-TLS [RFC2716],
ultimately the TSKs, are derived from the TLS Master Secret. which is based on the TLS key hierarchy described in [RFC2246]. The
TLS-negotiated ciphersuite is used to set up a protected channel for
---+ use in protecting the EAP conversation, keyed by the derived TEKs.
| ^ The TEK derivation proceeds as follows:
| TLS Master Secret (TMS) |
| |
V |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | EAP |
| Master Session Key (MSK) | Method |
| Derivation | |
| | V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ EAP ---+
| | | API ^
| MSK | EMSK | IV |
| | | |
V V V v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | |
| | |
| backend authentication server | |
| | |
| | V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | ^
| AAA-Key(0,31) | AAA-Key(32,63) |
| (PMK) | Transported |
| | via AAA |
| | |
V V V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | ^
| Ciphersuite-Specific Transient Session | Auth.|
| Key Derivation | |
| | V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
Figure C-1 - EAP TLS [RFC2716] Key hierarchy
Appendix D - Example Transient Session Key (TSK) Derivation
Within IEEE 802.11 RSN, the Pairwise Transient Key (PTK), a transient
session key used to protect unicast traffic, is derived from the PMK
(octets 0-31 of the MSK), known in [RFC2716] as the Peer to
Authenticator Encryption Key. In [IEEE-802.11i], the PTK is derived
from the PMK via the following formula:
PTK = EAPOL-PRF-X(PMK, "Pairwise key expansion", Min(AA,SA) ||
Max(AA, SA) || Min(ANonce,SNonce) || Max(ANonce,SNonce))
master_secret = TLS-PRF-48(pre_master_secret, "master secret",
client.random || server.random)
TEK = TLS-PRF-X(master_secret, "key expansion",
server.random || client.random)
Where: Where:
PMK = AAA-Key(0,31) TLS-PRF-X = TLS pseudo-random function defined in [RFC2246],
SA = Station MAC address (Calling-Station-Id) computed to X octets.
AA = Access Point MAC address (Called-Station-Id)
ANonce = Access Point Nonce
SNonce = Station Nonce
EAPOL-PRF-X = Pseudo-Random Function based on HMAC-SHA1, generating
a PTK of size X octets.
TKIP uses X = 64, while CCMP, WRAP, and WEP use X = 48. | | pre_master_secret |
server| | | client
Random| V | Random
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
+---->| master_secret |<------+
| | (TMS) | |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | |
V V V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Key Block (TEKs) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| client | server | client | server | client | server
| MAC | MAC | write | write | IV | IV
| | | | | |
V V V V V V
The EAPOL-Key Confirmation Key (KCK) is used to provide data origin Figure A-1 - TLS [RFC2246] Key Hierarchy
authenticity in the TSK derivation. It utilizes the first 128 bits
(bits 0-127) of the PTK. The EAPOL-Key Encryption Key (KEK) provides
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
384-511 are used by Temporal Key 2. Usage of TK1 and TK2 is
ciphersuite specific. Details are available in [IEEE-802.11i].
Appendix E - Exported Parameters in Existing Methods Appendix B - Exported Parameters in Existing Methods
This Appendix specifies Method-ID, Peer-ID, Server-ID and Key- This Appendix specifies Method-ID, Peer-ID, Server-ID and Key-
Lifetime for EAP methods that have been published prior to this Lifetime for EAP methods that have been published prior to this
specification. Future EAP method specifications MUST include a specification. Future EAP method specifications MUST include a
definition of the Method-ID, Peer-ID, and Server-ID (could be the definition of the Method-ID, Peer-ID, and Server-ID (could be the
empty string) and MAY also define the Key-Lifetime (assumed to be empty string) and MAY also define the Key-Lifetime (assumed to be
indeterminate if not described). indeterminate if not described).
EAP-Identity EAP-Identity
skipping to change at page 69, line 11 skipping to change at page 54, line 11
EAP-AKA EAP-AKA
The EAP-AKA Method-Id is the contents of the RAND field from the 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 AT_RAND attribute, followed by the contents of the AUTN field in
the AT_AUTN attribute. the AT_AUTN attribute.
The Peer-ID is the contents of the Identity field from the The Peer-ID is the contents of the Identity field from the
AT_IDENTITY attribute, using only the Actual Identity Length AT_IDENTITY attribute, using only the Actual Identity Length
octets from the beginning, however. Note that the contents are octets from the beginning, however. Note that the contents are
used as they are transmitted, regardless of whether the used as they are transmitted, regardless of whether the
transmitted identity was a permanent, pseudonym, or fast transmitted identity was a permanent, pseudonym, or fast re-
reauthentication identity. The Server- ID is an empty string. authentication identity. The Server-ID is an empty string. EAP-
EAP-AKA does not negotiate a key lifetime. AKA does not negotiate a key lifetime.
EAP-SIM EAP-SIM
The Method-Id is the contents of the RAND field from the AT_RAND 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 attribute, followed by the contents of the NONCE_MT field in the
AT_NONCE_MT attribute. AT_NONCE_MT attribute.
The Peer-ID is the contents of the Identity field from the The Peer-ID is the contents of the Identity field from the
AT_IDENTITY attribute, using only the Actual Identity Length AT_IDENTITY attribute, using only the Actual Identity Length
octets from the beginning, however. Note that the contents are octets from the beginning, however. Note that the contents are
used as they are transmitted, regardless of whether the used as they are transmitted, regardless of whether the
transmitted identity was a permanent, pseudonym, or fast transmitted identity was a permanent, pseudonym, or fast re-
reauthentication identity. The Server- ID is an empty string. authentication identity. The Server-ID is an empty string. EAP-
EAP-SIM does not negotiate a key lifetime. SIM does not negotiate a key lifetime.
Appendix F - Security Association Examples
EAP Method SA Example: EAP-TLS
In EAP-TLS [RFC2716], after the EAP authentication the client (peer)
and server can store the following information:
o Implicitly, the EAP method this SA refers to (EAP-TLS)
o Session identifier (a value selected by the server)
o Certificate of the other party (server stores the client's
certificate and vice versa)
o Ciphersuite and compression method
o TLS Master secret (known as the EAP-TLS Master Key)
o SA lifetime (ensuring that the SA is not stored forever)
o If the client has multiple different credentials (certificates
and corresponding private keys), a pointer to those credentials
When the server initiates EAP-TLS, the client can look up the EAP-TLS
SA based on the credentials it was going to use (certificate and
private key), and the expected credentials (certificate or name) of
the server. If an EAP-TLS SA exists, and it is not too old, the
client informs the server about the existence of this SA by including
its Session-Id in the TLS ClientHello message. The server then looks
up the correct SA based on the Session-Id (or detects that it doesn't
yet have one).
EAP Method SA Example: EAP-AKA
In EAP-AKA [I-D.arkko-pppext-eap-aka], after EAP authentication the
client and server can store the following information:
o Implicitly, the EAP method this SA refers to (EAP-AKA)
o A re-authentication pseudonym
o The client's permanent identity (IMSI)
o Replay protection counter
o Authentication key (K_aut)
o Encryption key (K_encr)
o Original Master Key (MK)
o SA lifetime (ensuring that the SA is not stored forever)
When the server initiates EAP-AKA, the client can look up the EAP-AKA
SA based on the credentials it was going to use (permanent identity).
If an EAP-AKA SA exists, and it is not too old, the client informs
the server about the existence of this SA by sending its re-
authentication pseudonym as its identity in EAP Identity Response
message, instead of its permanent identity. The server then looks up
the correct SA based on this identity.
AAA SA Example: RADIUS
In RADIUS, where shared secret authentication is used, the client and
server store each other's IP address and the shared secret, which is
used to calculate the Response Authenticator [RFC2865] and Message-
Authenticator [RFC3579] values, and to encrypt some attributes (such
as the AAA-Key, see [RFC3580] Section 3.16).
Where IPsec is used to protect RADIUS [RFC3579] and IKE is used for
key management, the parties store information necessary to
authenticate and authorize the other party (e.g. certificates, trust
anchors and names). The IKE exchange results in IKE Phase 1 and Phase
2 SAs containing information used to protect the conversation
(session keys, selected ciphersuite, etc.)
AAA SA Example: Diameter with TLS
When using Diameter protected by TLS, the parties store information
necessary to authenticate and authorize the other party (e.g.
certificates, trust anchors and names). The TLS handshake results in
a short-term TLS SA that contains information used to protect the
actual communications (session keys, selected TLS ciphersuite, etc.).
Service SA Example: 802.11i
[IEEE802.11i] Section 8.4.1.1 defines the security associations used
within IEEE 802.11. A summary follows; the standard should be
consulted for details.
o Pairwise Master Key Security Association (PMKSA)
The PMKSA is a bi-directional SA, used by both parties for sending
and receiving. The PMKSA is the Root Service SA. It is created
on the peer when EAP authentication completes successfully or a
pre-shared key is configured. The PMKSA is created on the
authenticator when the PMK is received or created on the
authenticator or a pre-shared key is configured. The PMKSA is
used to create the PTKSA. PMKSAs are cached for their lifetimes.
The PMKSA consists of the following elements:
- PMKID (security association identifier)
- Authenticator MAC address
- PMK
- Lifetime
- Authenticated Key Management Protocol (AKMP)
- Authorization parameters specified by the AAA server or
by local configuration. This can include
parameters such as the peer's authorized SSID.
On the peer, this information can be locally
configured.
- Key replay counters (for EAPOL-Key messages)
- Reference to PTKSA (if any), needed to:
o delete it (e.g. AAA server-initiated disconnect)
o replace it when a new four-way handshake is done
- Reference to accounting context, the details of which depend
on the accounting protocol used, the implementation
and administrative details. In RADIUS, this could include
(e.g. packet and octet counters, and Acct-Multi-Session-Id).
o Pairwise Transient Key Security Association (PTKSA)
The PTKSA is a bi-directional SA created as the result of a
successful four-way handshake. The PTKSA is a unicast service SA.
There may only be one PTKSA between a pair of peer and
authenticator MAC addresses. PTKSAs are cached for the lifetime
of the PMKSA. Since the PTKSA is tied to the PMKSA, it only has
the additional information from the 4-way handshake. The PTKSA
consists of the following:
- Key (PTK)
- Selected ciphersuite
- MAC addresses of the parties
- Replay counters, and ciphersuite specific state
- Reference to PMKSA: This is needed when:
o A new four-way handshake is needed (lifetime, TKIP
countermeasures), and we need to know which PMKSA to use
o Group Transient Key Security Association (GTKSA)
The GTKSA is a uni-directional SA created based on the four-way
handshake or the group key handshake. The GTKSA is a multicast
service SA. A GTKSA consists of the following:
- Direction vector (whether the GTK is used for transmit or receive)
- Group cipher suite selector
- Key (GTK)
- Authenticator MAC address
- Via reference to PMKSA, or copied here:
o Authorization parameters
o Reference to accounting context
Service SA Example: IKEv2/IPsec
Note that this example is intended to be informative, and it does
not necessarily include all information stored.
o IKEv2 SA
- Protocol version
- Identities of the parties
- IKEv2 SPIs
- Selected ciphersuite
- Replay protection counters (Message ID)
- Keys for protecting IKEv2 messages (SK_ai/SK_ar/SK_ei/SK_er)
- Key for deriving keys for IPsec SAs (SK_d)
- Lifetime information
- On the authenticator, service authorization information
received from the backend authentication server.
When processing an incoming message, the correct SA is looked up
based on the SPIs.
o IPsec SAs/SPD
- Traffic selectors
- Replay protection counters
- Selected ciphersuite
- IPsec SPI
- Keys
- Lifetime information
- Protocol mode (tunnel or transport)
The correct SA is looked up based on SPI (for inbound packets), or
SPD traffic selectors (for outbound traffic). A separate IPsec SA
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 Rights 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; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
 End of changes. 229 change blocks. 
2009 lines changed or deleted 1168 lines changed or added

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