draft-ietf-eap-keying-05.txt   draft-ietf-eap-keying-06.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-05.txt> J. Arkko <draft-ietf-eap-keying-06.txt> J. Arkko
18 February 2005 Ericsson 1 April 2005 Ericsson
P. Eronen P. Eronen
Nokia Nokia
H. Levkowetz, Ed. H. Levkowetz, Ed.
ipUnplugged ipUnplugged
Extensible Authentication Protocol (EAP) Key Management Framework Extensible Authentication Protocol (EAP) Key Management Framework
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with and any of which I become aware will be disclosed, in accordance with
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 August 22, 2005. This Internet-Draft will expire on November 22, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved. Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract Abstract
The Extensible Authentication Protocol (EAP), defined in [RFC3748], The Extensible Authentication Protocol (EAP), defined in [RFC3748],
enables extensible network access authentication. This document enables extensible network access authentication. This document
provides a framework for the generation, transport and usage of provides a framework for the generation, transport and usage of
keying material generated by EAP authentication algorithms, known as keying material generated by EAP authentication algorithms, known as
"methods". It also specifies the EAP key hierarchy. "methods". It also specifies the EAP key hierarchy.
Table of Contents Table of Contents
1. Introduction .......................................... 4 1. Introduction .......................................... 4
1.1 Requirements Language ........................... 4 1.1 Requirements Language ........................... 4
1.2 Terminology ..................................... 4 1.2 Terminology ..................................... 4
1.3 Overview ........................................ 5 1.3 Overview ........................................ 5
1.4 EAP Invariants .................................. 11 1.4 EAP Invariants .................................. 11
2. Key Derivation ........................................ 14 2. Key Derivation ........................................ 13
2.1 Key Terminology ................................. 14 2.1 Key Terminology ................................. 13
2.2 Key Hierarchy ................................... 15 2.2 Key Hierarchy ................................... 15
2.3 AAA-Key Derivation .............................. 21 2.3 AAA-Key Derivation .............................. 19
2.4 AMSK Key Derivation ............................. 22 2.4 Key Naming ...................................... 20
2.5 Key Naming ...................................... 23 3. Security associations ................................. 22
3. Security associations ................................. 26 3.1 EAP Method SA ................................... 23
3.1 EAP Method SA ................................... 26 3.2 EAP-Key SA ...................................... 24
3.2 EAP-Key SA ...................................... 27 3.3 AAA SA(s) ....................................... 24
3.3 AAA SA(s) ....................................... 28 3.4 Service SA(s) ................................... 24
3.4 Service SA(s) ................................... 28 4. Key Management ........................................ 27
4. Key Management ........................................ 30 4.1 Key Caching ..................................... 28
4.1 Key Caching ..................................... 31 4.2 Parent-Child Relationships ...................... 29
4.2 Parent-Child Relationships ...................... 32 4.3 Local Key Lifetimes ............................. 29
4.3 Local Key Lifetimes ............................. 32 4.4 Exported and Calculated Key Lifetimes ........... 30
4.4 Exported and Calculated Key Lifetimes ........... 33 4.5 Key Cache Synchronization ....................... 31
4.5 Key Cache Synchronization ....................... 34 4.6 Key Scope ....................................... 32
4.6 Key Scope ....................................... 35 4.7 Key Strength .................................... 33
4.7 Key Strength .................................... 36 4.8 Key Wrap ........................................ 34
4.8 Key Wrap ........................................ 37 5. Handoff Vulnerabilities ............................... 35
5. Handoff Support ....................................... 38 5.1 Authorization ................................... 35
5.1 Authorization ................................... 38 5.2 Correctness ..................................... 36
5.2 Correctness ..................................... 39 6. Security Considerations .............................. 39
6. Security Considerations .............................. 42 6.1 Security Terminology ............................ 39
6.1 Security Terminology ............................ 42 6.2 Threat Model .................................... 39
6.2 Threat Model .................................... 42 6.3 Security Analysis ............................... 41
6.3 Security Analysis ............................... 44 6.4 Man-in-the-middle Attacks ....................... 44
6.4 Man-in-the-middle Attacks ....................... 48 6.5 Denial of Service Attacks ....................... 45
6.5 Denial of Service Attacks ....................... 48 6.6 Impersonation ................................... 45
6.6 Impersonation ................................... 49 6.7 Channel Binding ................................. 46
6.7 Channel Binding ................................. 50 7. Security Requirements ................................. 47
7. Security Requirements ................................. 51 7.1 EAP Method Requirements ......................... 47
7.1 EAP Method Requirements ......................... 51 7.2 AAA Protocol Requirements ....................... 50
7.2 AAA Protocol Requirements ....................... 54 7.3 Secure Association Protocol Requirements ........ 51
7.3 Secure Association Protocol Requirements ........ 55 7.4 Ciphersuite Requirements ........................ 53
7.4 Ciphersuite Requirements ........................ 57 8. IANA Considerations ................................... 54
8. IANA Considerations ................................... 57 9. References ............................................ 54
9. References ............................................ 58 9.1 Normative References ............................ 54
9.1 Normative References ............................ 58 9.2 Informative References .......................... 54
9.2 Informative References .......................... 59 Acknowledgments .............................................. 58
Acknowledgments .............................................. 62 Author's Addresses ........................................... 58
Author's Addresses ........................................... 63 Appendix A - Ciphersuite Keying Requirements ................. 60
Appendix A - Ciphersuite Keying Requirements ................. 64 Appendix B - Example Transient EAP Key (TEK) Hierarchy ....... 61
Appendix B - Example Transient EAP Key (TEK) Hierarchy ....... 65 Appendix C - EAP-TLS Key Hierarchy ........................... 62
Appendix C - EAP-TLS Key Hierarchy ........................... 66 Appendix D - Example Transient Session Key (TSK) Derivation .. 64
Appendix D - Example Transient Session Key (TSK) Derivation .. 68 Appendix E - Key Names and Scope in Existing Methods ......... 65
Appendix E - Key Names and Scope in Existing Methods ......... 69 Appendix F - Security Association Examples ................... 66
Appendix F - Security Association Examples ................... 70 Intellectual Property Statement .............................. 69
Intellectual Property Statement .............................. 73 Disclaimer of Validity ....................................... 70
Disclaimer of Validity ....................................... 74 Copyright Statement .......................................... 70
Copyright Statement .......................................... 74
1. Introduction 1. Introduction
The Extensible Authentication Protocol (EAP), defined in [RFC3748], The Extensible Authentication Protocol (EAP), defined in [RFC3748],
was designed to enable extensible authentication for network access was designed to enable extensible authentication for network access
in situations in which the IP protocol is not available. Originally in situations in which the IP protocol is not available. Originally
developed for use with PPP [RFC1661], it has subsequently also been developed for use with PPP [RFC1661], it has subsequently also been
applied to IEEE 802 wired networks [IEEE8021X]. 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
usage of keying material generated by EAP authentication algorithms, usage of keying material generated by EAP authentication algorithms,
known as "methods". In EAP keying material is generated by EAP known as "methods". In 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. The exported themselves and part of this material may be exported. The exported
keying material may be transported by AAA protocols or transformed by keying material may be transported by AAA protocols or transformed by
Secure Association Protocols into session keys which are used by Secure Association Protocols into session keys which are used by
lower layer ciphersuites. This document describes each of these lower layer ciphersuites. This document describes each of these
elements and provides a system-level security analysis. It also elements and provides a system-level security analysis. It also
skipping to change at page 8, line 17 skipping to change at page 8, line 17
In the discovery phase (phase 0), the EAP peer and authenticator In the discovery phase (phase 0), the EAP peer and authenticator
locate each other and discover each other's capabilities. Discovery locate each other and discover each other's capabilities. Discovery
can occur manually or automatically, depending on the lower layer can occur manually or automatically, depending on the lower layer
over which EAP runs. Since authenticator discovery is handled over which EAP runs. Since authenticator discovery is handled
outside of EAP, there is no need to provide this functionality within outside of EAP, there is no need to provide this functionality within
EAP. EAP.
For example, where EAP runs over PPP, the EAP peer might be For example, where EAP runs over PPP, the EAP peer might be
configured with a phone book providing phone numbers of configured with a phone book providing phone numbers of
authenticators and associated capabilities such as supported rates, authenticators and associated capabilities such as supported rates,
authentication protocols or ciphersuites. authentication protocols or ciphersuites. In contrast, PPPoE
[RFC2516] provides support for a Discovery Stage to allow a peer to
In contrast, PPPoE [RFC2516] provides support for a Discovery Stage identify the Ethernet MAC address of one or more authenticators and
to allow a peer to identify the Ethernet MAC address of one or more establish a PPPoE SESSION_ID.
authenticators and establish a PPPoE SESSION_ID.
IEEE 802.11 [IEEE80211] also provides integrated discovery support IEEE 802.11 [IEEE-802.11] also provides integrated discovery support
utilizing Beacon and/or Probe Request/Response frames, allowing the utilizing Beacon and/or Probe Request/Response frames, allowing the
peer (known as the station or STA) to determine the MAC address and peer (known as the station or STA) to determine the MAC address and
capabilities of one or more authenticators (known as Access Point or capabilities of one or more authenticators (known as Access Point or
APs). APs).
1.3.2. Authentication Phase 1.3.2. Authentication Phase
Once the peer and authenticator discover each other, they exchange Once the peer and authenticator discover each other, they exchange
EAP packets. Typically, the peer desires access to the network, and EAP packets. Typically, the peer desires access to the network, and
the authenticators provide that access. In such a situation, access the authenticators provide that access. In such a situation, access
skipping to change at page 9, line 35 skipping to change at page 9, line 34
association between the EAP peer and authenticator, as part of the association between the EAP peer and authenticator, as part of the
Secure Association Protocol (phase 2). As a result, EAP may be used Secure Association Protocol (phase 2). As a result, EAP may be used
for "pre-authentication" in situations where it is necessary to pre- for "pre-authentication" in situations where it is necessary to pre-
establish EAP security associations in order to decrease handoff or establish EAP security associations in order to decrease handoff or
roaming latency. roaming latency.
1.3.3. Secure Association Phase 1.3.3. Secure Association Phase
The Secure Association phase (phase 2), if it occurs, begins after The Secure Association phase (phase 2), if it occurs, begins after
the completion of EAP authentication (phase 1a) and key transport the completion of EAP authentication (phase 1a) and key transport
(phase 1b). EAP may be used in the following scenarios: (phase 1b). A Secure Association Protocol used with EAP typically
supports the following features:
[a] Stationary peer. Where the peer is stationary it will establish
communications with one or more authenticators while remaining in
one location. In this scenario, EAP authentication typically
represents only a small fraction of the total session time, so that
it is acceptable for EAP authentication to occur each time the peer
wishes to access the network. In this scenario, the Secure
Association Protocol phase may be omitted.
[b] Mobile peer. Where the peer is mobile, it may move its point of
attachment from one authenticator to another, or between points of
attachment on a single authenticator. In this scenario, it is
often desirable to minimize the handoff latency, so that it is
desirable to avoid EAP authentication each time the peer changes
its point of attachment. In this scenario, caching of the AAA-Key
be supported on the EAP peer and authenticator. In this, a Secure
Assocation Protocol phase is required to allow EAP to be used
securely.
A Secure Association Protocol used with EAP typically supports the
following features:
[1] Generation of fresh transient session keys (TSKs). Where AAA-Key [1] Generation of fresh transient session keys (TSKs). Where AAA-Key
caching is supported, the EAP peer may initiate a new session using caching is supported, the EAP peer may initiate a new session using
a AAA-Key that was used in a previous session. Were the TSKs to be a AAA-Key that was used in a previous session. Were the TSKs to be
derived from a portion of the AAA-Key, this would result in reuse derived from a portion of the AAA-Key, this would result in reuse
of the session keys which could expose the underlying ciphersuite of the session keys which could expose the underlying ciphersuite
to attack. to attack.
As a result, where AAA-Key caching is supported, the Secure As a result, where AAA-Key caching is supported, the Secure
Association Protocol phase is REQUIRED, and MUST provide for Association Protocol phase is REQUIRED, and MUST provide for
skipping to change at page 10, line 33 skipping to change at page 10, line 12
protect data, the Secure Association Protocol protects against protect data, the Secure Association Protocol protects against
compromise of the AAA-Key. compromise of the AAA-Key.
[2] Entity Naming. A basic feature of a Secure Association Protocol is [2] Entity Naming. A basic feature of a Secure Association Protocol is
the explicit naming of the parties engaged in the exchange. the explicit naming of the parties engaged in the exchange.
Explicit identification of the parties is critical, since without Explicit identification of the parties is critical, since without
this the parties engaged in the exchange are not identified and the this the parties engaged in the exchange are not identified and the
scope of the transient session keys (TSKs) generated during the scope of the transient session keys (TSKs) generated during the
exchange is undefined. As illustrated in Figure 1, both the peer exchange is undefined. As illustrated in Figure 1, both the peer
and NAS may have more than one physical or virtual port, so that and NAS may have more than one physical or virtual port, so that
port identifiers are not recommended a naming mechanism. port identifiers are NOT RECOMMENDED as a naming mechanism.
[3] Secure capabilities negotiation. This includes the secure [3] Secure capabilities negotiation. This includes the secure
negotiation of usage modes, session parameters (such as key negotiation of usage modes, session parameters (such as key
lifetimes), ciphersuites and required filters, including lifetimes), ciphersuites and required filters, including
confirmation of the capabilities discovered during phase 0. It is confirmation of the capabilities discovered during phase 0. It is
RECOMMENDED that the Secure Association Protocol support secure RECOMMENDED that the Secure Association Protocol support secure
capabilities negotiation, in order to protect against spoofing capabilities negotiation, in order to protect against spoofing
during the discovery phase, and to ensure agreement between the during the discovery phase, and to ensure agreement between the
peer and authenticator about how data is to be secured. peer and authenticator about how data is to be secured.
skipping to change at page 11, line 41 skipping to change at page 11, line 19
Media independence Media independence
Method independence Method independence
Ciphersuite independence Ciphersuite independence
1.4.1. Media Independence 1.4.1. Media Independence
One of the goals of EAP is to allow EAP methods to function on any One of the goals of EAP is to allow EAP methods to function on any
lower layer meeting the criteria outlined in [RFC3748], Section 3.1. lower layer meeting the criteria outlined in [RFC3748], Section 3.1.
For example, as described in [RFC3748], EAP authentication can be run For example, as described in [RFC3748], EAP authentication can be run
over PPP [RFC1661], IEEE 802 wired networks [IEEE8021X], and IEEE over PPP [RFC1661], IEEE 802 wired networks [IEEE-802.1X], and IEEE
802.11 wireless LANs [IEEE80211i]. 802.11 wireless LANs [IEEE-802.11i].
In order to maintain media independence, it is necessary for EAP to In order to maintain media independence, it is necessary for EAP to
avoid inclusion of media-specific elements. For example, EAP methods avoid inclusion of media-specific elements. For example, EAP methods
cannot be assumed to have knowledge of the lower layer over which cannot be assumed to have knowledge of the lower layer over which
they are transported, and cannot utilize identifiers associated with they are transported, and cannot utilize identifiers associated with
a particular usage environment (e.g. MAC addresses). a particular usage environment (e.g. MAC addresses).
The need for media independence has also motivated the development of The need for media independence has also motivated the development of
the three phase exchange. Since discovery is typically media- the three phase exchange. Since discovery is typically media-
specific, this function is handled outside of EAP, rather than being specific, this function is handled outside of EAP, rather than being
skipping to change at page 12, line 40 skipping to change at page 12, line 17
capable of supporting any EAP method. Since the Discovery and Secure capable of supporting any EAP method. Since the Discovery and Secure
Association exchanges are also method independent, an authenticator Association exchanges are also method independent, an authenticator
can carry out the three phase exchange without having an EAP method can carry out the three phase exchange without having an EAP method
in common with the peer. in common with the peer.
This is useful where there is no single EAP method that is both This is useful where there is no single EAP method that is both
mandatory-to-implement and offers acceptable security for the media mandatory-to-implement and offers acceptable security for the media
in use. For example, the [RFC3748] mandatory-to-implement EAP method in use. For example, the [RFC3748] mandatory-to-implement EAP method
(MD5-Challenge) does not provide dictionary attack resistance, mutual (MD5-Challenge) does not provide dictionary attack resistance, mutual
authentication or key derivation, and as a result is not appropriate authentication or key derivation, and as a result is not appropriate
for use in wireless LAN authentication [WLANREQ]. However, despite for use in wireless LAN authentication [RFC4017]. However, despite
this it is possible for the peer and authenticator to interoperate as this it is possible for the peer and authenticator to interoperate as
long as a suitable EAP method is supported on the EAP server. long as a suitable EAP method is supported on the EAP server.
1.4.3. Ciphersuite Independence 1.4.3. Ciphersuite 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 out-of-band of EAP. Since between the peer and authenticator out-of-band of EAP. Since
ciphersuite negotiation is assumed to occur out-of-band, there is no ciphersuite negotiation is assumed to occur out-of-band, there is no
need for ciphersuite negotiation within EAP. Since ciphersuite need for ciphersuite negotiation within EAP. Since ciphersuite
negotiation occurs outside of EAP, EAP methods generate keying negotiation occurs outside of EAP, EAP methods generate keying
material that is ciphersuite-independent. 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 [IEEE80211i], 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 after EAP authentication has completed. handshake exchange after EAP authentication has completed.
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
skipping to change at page 14, line 41 skipping to change at page 14, line 10
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, wrapped within the AAA-Token; it is therefore known
by the peer, authenticator and backend authentication server. by the peer, authenticator and backend authentication server.
Despite the name, the AAA-Key is computed regardless of whether a Despite the name, the AAA-Key is computed regardless of whether a
backend authentication server is present. AAA-Key derivation is backend authentication server is present. AAA-Key derivation is
discussed in Section 2.3; in existing implementations the MSK is discussed in Section 2.3; in existing implementations the MSK is
used as the AAA-Key. used as the AAA-Key.
Application-specific Master Session Keys (AMSKs)
Keys derived from the EMSK which are cryptographically separate
from each other and may be subsequently used in the derivation of
Transient Session Keys (TSKs) for extended uses. AMSK derivation
is discussed in Section 2.4.
AAA-Token AAA-Token
Where a backend server is present, the AAA-Key and one or more Where a backend server is present, the AAA-Key and one or more
attributes is transported between the backend authentication server attributes is transported between the backend authentication server
and the authenticator within a package known as the AAA-Token. The and the authenticator within a package known as the AAA-Token. The
format and wrapping of the AAA-Token, which is intended to be format and wrapping of the AAA-Token, which is intended to be
accessible only to the backend authentication server and accessible only to the backend authentication server and
authenticator, is defined by the AAA protocol. Examples include authenticator, is defined by the AAA protocol. Examples include
RADIUS [RFC2548] and Diameter [I-D.ietf-aaa-eap]. RADIUS [RFC2548] and Diameter [I-D.ietf-aaa-eap].
Initialization Vector (IV) Initialization Vector (IV)
skipping to change at page 15, line 20 skipping to change at page 14, line 32
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 AAA-Key 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 [IEEE80211i] Octets 0-31 of of view of the authenticator). Within [IEEE-802.11i] Octets 0-31
the AAA-Key (Enc-RECV-Key) are known as the Pairwise Master Key of the AAA-Key (Enc-RECV-Key) are known as the Pairwise Master Key
(PMK). In [IEEE80211i] 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 AAA-Key.
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. Note that the ciphersuite used to set up the
skipping to change at page 16, line 26 skipping to change at page 15, line 38
Based on the long term credential established between the peer and Based on the long term credential established between the peer and
the server, EAP derives two types of keys: the server, EAP derives two types of keys:
[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] Keys exported by the EAP method: MSK, EMSK, IV [2] Keys exported by the EAP method: MSK, EMSK, IV
From the keys exported by the EAP method, two other types of keys may From the keys exported by the EAP method, two other types of keys may
be derived: be derived:
[3] Keys calculated from exported quantities: AAA-Key, AMSKs. [3] Keys calculated from exported quantities: AAA-Key.
[4] Keys calculated by the Secure Association Protocol from the [4] Keys calculated by the Secure Association Protocol from the
AAA-Key or AMSKs: TSKs. AAA-Key: TSKs.
In order to protect the EAP conversation, methods supporting key In order to protect the EAP conversation, methods supporting key
derivation typically negotiate a ciphersuite and derive Transient EAP derivation typically negotiate a ciphersuite and derive Transient EAP
Keys (TEKs) for use with that ciphersuite. The TEKs are stored Keys (TEKs) for use with that ciphersuite. The TEKs are stored
locally by the EAP method and are not exported. locally by the EAP method and are not exported.
As noted in [RFC3748] Section 7.10, EAP methods generating keys are As noted in [RFC3748] Section 7.10, EAP methods generating keys are
required to calculate and export the MSK and EMSK, which must be at required to calculate and export the MSK and EMSK, which must be at
least 64 octets in length. EAP methods also may export the IV; least 64 octets in length. EAP methods also may export the IV;
however, the use of the IV is deprecated. On both the peer and EAP however, the use of the IV is deprecated. On both the peer and EAP
server, the exported MSK and keys derived from the AMSK are utilized server, the exported MSK is utilized in order to calculate the AAA-
in order to calculate the AAA-Key, as described in Section 2.3. Key, as described in Section 2.3. Where a backend authentication
server is present, the AAA-Key is transported from the backend
Where a backend authentication server is present, the AAA-Key is authentication server to the authenticator within the AAA-Token,
transported from the backend authentication server to the using the AAA protocol.
authenticator within the AAA-Token, using the AAA protocol.
Once EAP authentication completes and is successful, the peer and Once EAP authentication completes and is successful, the peer and
authenticator obtain the AAA-Key and the Secure Association Protocol authenticator obtain the AAA-Key and the Secure Association Protocol
is run between the peer and authenticator in order to securely is run between the peer and authenticator in order to securely
negotiate the ciphersuite, derive fresh TSKs used to protect data, negotiate the ciphersuite, derive fresh TSKs used to protect data,
and provide mutual proof of possession of the AAA-Key. and provide mutual proof of possession of the AAA-Key.
When the authenticator acts as an endpoint of the EAP conversation When the authenticator acts as an endpoint of the EAP conversation
rather than a pass-through, EAP methods are implemented on the rather than a pass-through, EAP methods are implemented on the
authenticator as well as the peer. If the EAP method negotiated authenticator as well as the peer. If the EAP method negotiated
skipping to change at page 18, line 34 skipping to change at page 17, line 34
| |Derivation | |Derivation | |Derivation | |Derivation | | | | |Derivation | |Derivation | |Derivation | |Derivation | | |
| +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | | | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | |
| | | | | | | | | | | |
| | | | | V | | | | | V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | | ^ | | | ^
| | | | | | | |
| MSK (64B) | EMSK (64B) | IV (64B) | | MSK (64B) | EMSK (64B) | IV (64B) |
| | | Exported| | | | Exported|
| | | by | | | | by |
V V V EAP | | V V EAP v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ Method|
| AAA Key Derivation, | | Known | |
| Naming & Binding | |(Not Secret) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ V
| ---+ | ---+
| AAA-Key/ Transported | | AAA-Key Transported |
| Name by AAA | | by AAA |
| Protocol | | Protocol |
V V V V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | ^ | | ^
| TSK Derivation | Lower layer | | TSK Derivation | Lower layer |
| [AAA-Key Cache] | Specific | | [AAA-Key Cache] | Specific |
| | V | | V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
Figure 3: EAP Key Hierarchy Figure 3: EAP Key Hierarchy
skipping to change at page 19, line 29 skipping to change at page 18, line 29
| |EAP, TEK Deriv.|Authenti-| | |EAP, TEK Deriv.|Authenti-|
| |<------------->| cator | | |<------------->| cator |
| | | | | | | |
| | Secure Assoc. | | | | Secure Assoc. | |
| peer |<------------->| (EAP | | peer |<------------->| (EAP |
| |===============| server) | | |===============| server) |
| | Link layer | | | | Link layer | |
| | (PPP,IEEE802) | | | | (PPP,IEEE802) | |
| | | | | | | |
|MSK,EMSK | |MSK,EMSK | |MSK,EMSK | |MSK,EMSK |
| AAA-Key/| | AAA-Key/|
| Name | | Name |
| (TSKs) | | (TSKs) | | (TSKs) | | (TSKs) |
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
^ ^ ^ ^
| | | |
| MSK, EMSK | MSK, EMSK | MSK, EMSK | MSK, EMSK
| | | |
| | | |
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
| | | | | | | |
| EAP | | EAP | | EAP | | EAP |
skipping to change at page 20, line 27 skipping to change at page 19, line 27
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
| |===============| |========| | | |===============| |========| |
| |EAP, TEK Deriv.| | | | | |EAP, TEK Deriv.| | | |
| |<-------------------------------->| backend | | |<-------------------------------->| backend |
| | | |AAA-Key/| | | | | |AAA-Key/| |
| | Secure Assoc. | | Name | | | | Secure Assoc. | | Name | |
| peer |<------------->|Authenti-|<-------| auth | | peer |<------------->|Authenti-|<-------| auth |
| |===============| cator |========| server | | |===============| cator |========| server |
| | Link Layer | | AAA | (EAP | | | Link Layer | | AAA | (EAP |
| | (PPP,IEEE 802)| |Protocol| server) | | | (PPP,IEEE 802)| |Protocol| server) |
|MSK,EMSK | | | | | | | | | | |
| AAA-Key/| | AAA-Key/| |MSK,EMSK,| |MSK,EMSK | | MSK | |MSK,EMSK |
| Name | | Name | | AAA-Key/| | (TSKs) | | (TSKs) | | |
| (TSKs) | | (TSKs) | | Name |
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
^ ^ ^ ^
| | | |
| MSK, EMSK | MSK, EMSK | MSK, EMSK | MSK, EMSK
| | | |
| | | |
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
| | | | | | | |
| EAP | | EAP | | EAP | | EAP |
| Method | | Method | | Method | | Method |
| | | | | | | |
| (TEKs) | | (TEKs) | | (TEKs) | | (TEKs) |
| | | | | | | |
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
Figure 5: Pass-through relationship between EAP peer, authenticator Figure 5: Pass-through relationship between EAP peer, authenticator
and backend authentication server. and backend authentication server.
2.3. AAA-Key Derivation 2.3. AAA-Key Derivation
Where a AAA-Key is generated as the result of a successful EAP In existing usage, where a AAA-Key is generated as the result of a
authentication with the authenticator A, the AAA-Key is based on the successful EAP authentication with the authenticator, the AAA-Key is
MSK: AAA-Key = MSK(0,63). based on the MSK: AAA-Key = MSK(0,63).
As discussed in [I-D.irtf-aaaarch-handoff], [IEEE-02-758],
[IEEE-03-084], and [8021XHandoff], keying material may be required
for use in fast handoff between authenticators. Where the backend
authentication server provides keying material to additional
authenticators in order to facilitate fast handoff, it is highly
desirable for the keying material used on different authenticators B,
C to be cryptographically separate, so that if one authenticator is
compromised, it does not lead to the compromise of other
authenticators. Where keying material is provided by the backend
authentication server, a key hierarchy derived from the AMSK can be
used to provide cryptographically separate keying material for use in
fast handoff. Instead of using the EMSK directly an application
specific key (AMSK) is derived as described in Section 2.4:
AAA-Key = MSK(0,63)
AMSK = KDF(EMSK, "EAP AAA-Key derivation for multiple attachments",
length)
AAA-Key-B = prf(AMSK(0,63),"EAP AAA-Key derivation for
multiple attachments", AAA-Key, B-Called-Station-Id,
Calling-Station-Id,length)
AAA-Key-C = prf(AMSK(0,63),"EAP AAA-Key derivation for
multiple attachments",AAA-Key, C-Called-Station-Id,
Calling-Station-Id, length)
Where:
Calling-Station-Id = STA MAC address
B-Called-Station-Id = AP B MAC address
C-Called-Station-Id = AP C MAC address
prf = HMAC-SHA1
KDF = defined in Section 2.4
length = length of derived key material
Here AAA-Key is derived during the initial EAP authentication between
the peer and authenticator A. Based on this initial EAP
authentication, an AMSK is also derived, which can be used to derive
AAA-Keys for fast authentication between the EAP peer and
authenticators B and C. Since the AMSK is cryptographically separate
from the MSK, each of these AAA-Keys is cryptographically separate
from each other, and are guaranteed to be unique between the EAP peer
(also known as the STA) and the authenticator (also known as the AP).
2.4. AMSK Key Derivation
The EAP AMSK key derivation function (KDF) derives an AMSK from the
Extended Master Session Key (EMSK), an application key label,
optional application data, and output length.
AMSK = KDF(EMSK, key label, optional application data, length)
The key labels are printable ASCII strings unique for each
application (see Section 8 for IANA Considerations).
Additional ciphering keys (TSKs) can be derived from the AMSK using
an application specific key derivation mechanism. In many cases,
this AMSK->TSK derivation can simply split the AMSK to pieces of
correct length. In particular, it is not necessary to use a
cryptographic one-way function. The length of the AMSK MUST be
specified by the application.
The AMSK key derivation function is taken from the PRF+ key expansion
PRF from [IKEv2]. This KDF takes 4 parameters as input: secret,
label, application data, and output length. It is only defined for
255 iterations so it may produce up to 5100 bytes of key material.
For the purposes of this specification the secret is taken as the
EMSK, the label is the key label described above concatenated with a
NUL byte, the application data is also described above and the output
length is two bytes. Application data MAY be an empty string. The
KDF is based on HMAC-SHA1 [RFC2104] [SHA1]. For this specification we
have:
KDF (K,L,D,O) = T1 | T2 | T3 | T4 | ...
where:
T1 = prf (K, S | 0x01)
T2 = prf (K, T1 | S | 0x02)
T3 = prf (K, T2 | S | 0x03)
T4 = prf (K, T3 | S | 0x04)
prf = HMAC-SHA1
K = EMSK
L = key label
D = application data
O = OutputLength (2 bytes)
S = L | " " | D | O
The prf+ construction was chosen because of its simplicity and
efficiency over other PRFs such as those used in [TLS]. The
motivation for the design of this PRF is described in [SIGMA].
The NUL byte after the key label is used to avoid collisions if one
key label is a prefix of another label (e.g. "foobar" and
"foobarExtendedV2"). This is considered a simpler solution than
requiring a key label assignment policy that prevents prefixes from
occurring.
Where another prf needs to be negotiated, this can be handled within
the EAP method.
2.5. Key Naming 2.4. 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 (the identifier by which the key can be identified), as well as a
scope (the parties to whom the key is available). This section scope (the parties to whom the key is available). This section
describes how keys are named, and the scope within which that name describes how keys are named, and the scope within which that name
applies. applies.
Session-Id Session-Id
EAP methods supporting key naming MUST specify a temporally unique EAP methods supporting key naming MUST specify a temporally unique
skipping to change at page 24, line 32 skipping to change at page 21, line 21
EMSK Name EMSK Name
The EMSK can be referred to using the string "EMSK:", concatenated The EMSK can be referred to using the string "EMSK:", concatenated
with the EAP Session-Id. with the EAP Session-Id.
As with the EAP Session-Id, the EMSK scope is defined by the EAP peer As with the EAP Session-Id, the EMSK scope is defined by the EAP peer
name (if securely exchanged within the method) and the EAP server name (if securely exchanged within the method) and the EAP server
name (also only if securely exchanged). Where a peer or server name name (also only if securely exchanged). Where a peer or server name
is missing the null string is used. is missing the null string is used.
AMSK Name
AMSKs, if any, can be referred to using the string "AMSK:", the key
label, ":", application data (see Section 2.4), ":", and the EAP
Session-Id.
As with the EAP Session-Id, the AMSK scope is defined by the EAP peer
name (if securely exchanged within the method), ":" and the EAP
server name (also only if securely exchanged). Where a peer or
server name is missing the null string is used.
AAA-Key Name AAA-Key Name
The AAA-Key is derived from either the MSK or AMSK and so can be In existing usage, the AAA-Key is always derived from the MSK so can
referred to using the MSK or AMSK names. be referred to using the MSK name.
The AAA-Key scope is provided by the concatenation of the EAP peer The AAA-Key scope is provided by the concatenation of the EAP peer
name (if securely provided to the authenticator), and the name (if securely provided to the authenticator), and the
authenticator name (if securely provided to the peer). authenticator name (if securely provided to the peer).
For the purpose of identifying the authenticator to the peer, the For the purpose of identifying the authenticator to the peer, the
value of the NAS-Identifier attribute is recommended. The value of the NAS-Identifier attribute is recommended. The
authenticator may include the NAS-Identifier attribute to the AAA authenticator may include the NAS-Identifier attribute to the AAA
server in an Access-Request, and the authenticator may provide the server in an Access-Request, and the authenticator may provide the
NAS-Identifier (unsecured) to the EAP peer in the EAP- NAS-Identifier to the EAP peer. Mechanisms for this include use of
Request/Identity or via a lower layer mechanism (such as the 802.11 the EAP-Request/Identity (unsecured) or a lower layer mechanism (such
Beacon/Probe Response). Where the NAS-Identifier is provided by the as the 802.11 Beacon/Probe Response). Where the NAS-Identifier is
authenticator to the peer a secure mechanism is RECOMMENDED. provided by the authenticator to the peer a secure mechanism is
RECOMMENDED.
For the purpose of identifying the peer to the authenticator, the EAP For the purpose of identifying the peer to the authenticator, the EAP
peer identifier provided within the EAP method is recommended. It peer identifier provided within the EAP method is recommended. It
cannot be assumed that the authenticator is aware of the EAP peer cannot be assumed that the authenticator is aware of the EAP peer
name used within the method. Therefore alternatives mechanisms need name used within the method. Therefore alternatives mechanisms need
to be used to provide the EAP peer name to the authenticator. For 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- example, the AAA server may include the EAP peer name in the User-
Name attribute of the Access-Accept or the peer may provide the Name attribute of the Access-Accept or the peer may provide the
authenticator with its name via a lower layer mechanism. authenticator with its name via a lower layer mechanism.
skipping to change at page 25, line 36 skipping to change at page 22, line 16
PMK Name PMK Name
This document does not specify a naming scheme for the PMK. The PMK This document does not specify a naming scheme for the PMK. The PMK
is only identified by the AAA-Key from which it is derived. is only identified by the AAA-Key from which it is derived.
Similarly, the PMK scope is the same as the AAA-Key scope. Similarly, the PMK scope is the same as the AAA-Key scope.
Note: IEEE 802.11i names the PMKID for the purposes of being able to Note: IEEE 802.11i names the PMKID for the purposes of being able to
refer to it in the Secure Association protocol; this naming is based refer to it in the Secure Association protocol; this naming is based
on a hash of the PMK itself as well as some other parameters (see on a hash of the PMK itself as well as some other parameters (see
Section 8.5.1.2 [IEEE80211i]). Section 8.5.1.2 [IEEE-802.11i]).
TEKs TEKs
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. Since the TEKs are only known by the EAP peer and EAP method. Since the TEKs are only known by the EAP peer and
server, the TEK scope is the same as the Session-Id scope. server, the TEK scope is the same as the Session-Id scope.
TSKs TSKs
The TSKs are typically named. Their naming is specified in the Secure The TSKs are typically named. Their naming is specified in the Secure
skipping to change at page 26, line 29 skipping to change at page 23, line 8
security associations (SAs) are created: security associations (SAs) are created:
[1] EAP method SA. This SA is between the peer and EAP server. It [1] EAP method SA. This SA is between the peer and EAP server. It
stores state that can be used for "fast reconnect" or other stores state that can be used for "fast reconnect" or other
functionality in some EAP methods. Not all EAP methods create such functionality in some EAP methods. Not all EAP methods create such
an SA. an SA.
[2] EAP-Key SA. This is an SA between the peer and EAP server, which [2] EAP-Key SA. This is an SA between the peer and EAP server, which
is used to store the keying material exported by the EAP method. is used to store the keying material exported by the EAP method.
Current EAP server implementations do not retain this SA after the Current EAP server implementations do not retain this SA after the
EAP conversation completes, but proposals such as [IEEE-03-084] and EAP conversation completes.
[I-D.irtf-aaaarch-handoff] use this SA for purposes such as pre-
emptive key distribution.
[3] AAA SA(s). These SAs are between the authenticator and the backend [3] AAA SA(s). These SAs are between the authenticator and the backend
authentication server. They permit the parties to mutually authentication server. They permit the parties to mutually
authenticate each other and protect the communications between authenticate each other and protect the communications between
them. them.
[4] Service SA(s). These SAs are between the peer and authenticator, [4] Service SA(s). These SAs are between the peer and authenticator,
and they are created as a result of phases 1-2 of the conversation and they are created as a result of phases 1-2 of the conversation
(see Section 1.3). (see Section 1.3).
skipping to change at page 27, line 40 skipping to change at page 24, line 17
o Implicitly, the EAP method this SA refers to o Implicitly, the EAP method this SA refers to
o Internal (non-exported) cryptographic state o Internal (non-exported) cryptographic state
o EAP method SA name o EAP method SA name
o SA lifetime o SA lifetime
3.2. EAP-Key SA 3.2. EAP-Key SA
This is an SA between the peer and EAP server, which is used to store This is an SA between the peer and EAP server, which is used to store
the keying material exported by the EAP method. Current EAP server the keying material exported by the EAP method. Current EAP server
implementations do not retain this SA after the EAP conversation implementations do not retain this SA after the EAP conversation
completes, but future implementations could use this SA for pre- completes. As a result, all keys exported by the EAP method
emptive key distribution. (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
Contents: discarded and not cached.
o MSK and EMSK names
o MSK and EMSK
o SA lifetime
3.3. AAA SA(s) (authenticator - backend authentication server) 3.3. AAA SA(s) (authenticator - backend authentication server)
In order for the authenticator and backend authentication server to In order for the authenticator and backend authentication server to
authenticate each other, they need to store some information. authenticate each other, they need to store some information.
In case the authenticator and backend authentication server are In case the authenticator and backend authentication server are
colocated, and they communicate using local procedure calls or shared colocated, and they communicate using local procedure calls or shared
memory, this SA need not necessarily contain any information. memory, this SA need not necessarily contain any information.
skipping to change at page 30, line 46 skipping to change at page 27, line 15
Services supporting this feature should also consider what changes Services supporting this feature should also consider what changes
require new authorization from the backend authentication server require new authorization from the backend authentication server
(see Section 4.2). (see Section 4.2).
Note that these considerations are not limited to service Note that these considerations are not limited to service
parameters related to the authenticator--they apply to peer parameters related to the authenticator--they apply to peer
parameters as well. parameters as well.
4. Key Management 4. Key Management
The EAP peer, authenticator and backend server may support key EAP supports key derivation, but not key management. As a result,
caching. Since EAP supports key derivation, but not key management, key management functionality needs to be provided by the Secure
this functionality needs to be provided by the Secure Association Association Protocol. This includes:
Protocol. Key management support includes:
[a] Key lifetime determination. EAP does not support negotiation of [a] Generation of fresh transient session keys (TSKs). Where AAA-Key
key lifetimes, nor does it support rekey without reauthentication. 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.
As a result, the Secure Association Protocol is responsible for [b] Key lifetime determination. EAP does not support negotiation of
rekey and determination of the key lifetime. Where key caching is key lifetimes, nor does it support rekey without reauthentication.
supported, secure negotiation of key lifetimes is RECOMMENDED. As a result, the Secure Association Protocol may handle rekey and
Lower layers that support rekey, but not key caching may not determination of the key lifetime. Where key caching is supported,
require key lifetime negotiation. To take an example from IKE, the secure negotiation of key lifetimes is RECOMMENDED. Lower layers
difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes that support rekey, but not key caching, may not require key
were negotiated. In IKEv2, each end of the SA is responsible for lifetime negotiation. To take an example from IKE, the difference
between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes were
negotiated. In IKEv2, each end of the SA is responsible for
enforcing its own lifetime policy on the SA and rekeying the SA enforcing its own lifetime policy on the SA and rekeying the SA
when necessary. when necessary.
[b] Key resynchronization. It is possible for the peer or [c] 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 AAA-Key
whether it exists within the authenticator cache. It is therefore whether 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.
[c] Key selection. Where key caching is supported, it may be possible [d] Key selection. Where key caching is supported, it may be possible
for the EAP peer and authenticator to share more than one key of a for the EAP peer and authenticator to share more than one key of a
given type. As a result, the Secure Association Protocol needs to given type. As a result, the Secure Association Protocol needs to
support key selection, using the EAP Key Naming scheme described in support key selection, using the EAP Key Naming scheme described in
this document. this document.
[d] Key scope determination. Since the Discovery phase is handled out- [e] Key scope determination. Since the Discovery phase is handled out-
of-band, EAP does not provide a mechanism by which the peer can 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 AAA-Key caching is supported,
the EAP peer may not be able to determine the scope of validity of the EAP peer may not be able to determine the scope of validity of
a AAA-Key. Similarly, where the EAP peer has multiple ports, the a AAA-Key. Similarly, where the EAP peer has multiple ports, the
authenticator may not be able to determine whether a peer has authenticator may not be able to determine whether a peer has
authorization to use a particular AAA-Key. To allow key scope authorization to use a particular AAA-Key. To allow key scope
determination, the lower layer SHOULD provide a mechanism by which determination, the lower layer SHOULD provide a mechanism by which
the peer can determine the scope of the AAA-Key cache on each the peer can determine the scope of the AAA-Key cache on each
authenticator, and by which the authenticator can determine the authenticator, and by which the authenticator can determine the
scope of the AAA-Key cache on a peer. scope of the AAA-Key cache on a peer.
4.1. Key Caching 4.1. Key Caching
Key caching may be supported on the EAP peer, authenticator and In existing implementations, key caching may be supported on the EAP
backend server. Where explicitly supported by the lower layer, the peer and authenticator but not on the backend server. Where
EAP peer and authenticator MAY cache the AAA-Key and/or TSKs. The explicitly supported by the lower layer, the EAP peer and
structure of the key cache on the peer and authenticator is defined authenticator MAY cache the AAA-Key and/or TSKs. The structure of
by the lower layer. Unless specified by the lower layer, the EAP the key cache on the peer and authenticator is defined by the lower
peer, authenticator and server MUST assume that peers and layer. Unless specified by the lower layer, the EAP peer and
authenticators do not cache the AAA-Key or TSKs. authenticator MUST assume that peers and authenticators do not cache
the AAA-Key or TSKs.
The EAP peer and server MAY cache keys exported by the EAP method as In existing AAA server implementations, all keys exported by EAP
well as keys derived from them, subject to the following methods (including the MSK, EMSK and IV) and calculated keys (e.g.
restrictions: 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 [1] In order to avoid key reuse, on the EAP server, transported keys
are deleted once they are sent. An EAP server MUST NOT retain keys are deleted once they are sent. An EAP server MUST NOT retain keys
that it has previously sent to the authenticator. For example, an that it has previously sent to the authenticator. For example, an
EAP server that has transported a AAA-Key based on the MSK MUST EAP server that has transported a AAA-Key based on the MSK MUST
delete both the AAA-Key and the MSK, and no keys may be derived delete the MSK, and no keys may be derived from the MSK from that
from either the AAA-Key or the MSK from that point forward by the point forward by the server.
server.
[2] Keys which are not transported, such as the EMSK, MAY be cached on [2] Keys which are not transported, such as the EMSK, are also deleted
the EAP server. While AMSKs calculated from the EMSK MUST be by existing implementations.
deleted from the EAP server once they are transported, the parent
EMSK may remain in the EAP server cache.
4.2. Parent-Child Relationships 4.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, AMSKs and TSKs. the AAA-Key and TSKs.
When an EAP reauthentication takes place, new keying material is When an EAP reauthentication 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, AMSKs, and replacement of calculated keys, including the AAA-Key and TSKs.
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 rekey may occur prior to EAP
reauthentication. reauthentication.
Failure to mutually prove possession of the AAA-Key during the Secure Failure to mutually prove possession of the AAA-Key during the Secure
Association Protocol exchange need not be grounds for deletion of the Association Protocol exchange need not be grounds for deletion of the
AAA-Key by both parties; rate-limiting Secure Association Protocol AAA-Key by both parties; rate-limiting Secure Association Protocol
exchanges could be used to prevent a brute force attack. exchanges could be used to prevent a brute force attack.
skipping to change at page 33, line 36 skipping to change at page 30, line 15
4.4. Exported and Calculated Key Lifetimes 4.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 [DiamEAP] support the Session-Timeout attribute. The Diameter [I-D.ietf-aaa-eap] support the Session-Timeout attribute.
Session-Timeout value represents the maximum lifetime of the The Session-Timeout value represents the maximum lifetime of the
exported keys, and all keys calculated from it. If the AAA server exported keys, and all keys calculated from it, on the
caches exported keys, then it MUST expire the exported keys and all authenticator. Since existing AAA servers do not cache keys
keys calculated from them, no later than the future time indicated exported by EAP methods, or keys calculated from exported keys, the
by Session-Timeout. value of the Session-Timeout attribute has no bearing on the key
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 the AAA-Key, and all keys
calculated from it, will have expired on the authenticator. If the calculated from it, will have expired on the authenticator. If the
session subsequently starts, re-authentication will be initiated session subsequently starts, re-authentication will be initiated
once the Session-Time has expired. If the session never started, once the Session-Time has expired. If the session never started,
skipping to change at page 34, line 16 skipping to change at page 30, line 45
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 can then be used to enable authenticator. Lower layer mechanisms such as the Secure
the lifetime of exported and calculated keys to be negotiated Association Protocol can then be used to enable the lifetime of
between the peer and authenticator. exported and calculated keys to be negotiated between the peer and
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 AAA-Key, there is no need to manage the TSK
lifetime as a separate parameter, since the TSK lifetime and AAA- lifetime as a separate parameter, since the TSK lifetime and AAA-
Key lifetime are identical. Key lifetime 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 liftime. 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 suggested. 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
support lifetime negotiation, it would be possible to specify
methods that do. However, systems that rely on such negotiation
for exported keys would only function with these methods. As a
result, it is NOT RECOMMENDED to use this approach as the sole way
to determine key lifetimes.
4.5. Key cache synchronization 4.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
skipping to change at page 35, line 14 skipping to change at page 32, line 5
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 AAA-Key cache by deleting
the oldest AAA-Key first (LIFO), the relative creation time of the the oldest AAA-Key first (LIFO), the relative creation time of the
last AAA-Key to be deleted could be advertised with the Discovery last AAA-Key to be deleted could be advertised with the Discovery
phase, enabling the peer to determine whether a given AAA-Key had phase, enabling the peer to determine whether a given AAA-Key had
been expired from the authenticator key cache prematurely. been expired from the authenticator key cache prematurely.
4.6. Key Scope Issues 4.6. Key Scope
As described in Section 2.3, the AAA-Key is calculated from the EMSK As described in Section 2.3, in existing applications the AAA-Key is
and MSK by the EAP peer and server, and is used as the root of the derived from the MSK by the EAP peer and server, and is used as the
ciphersuite-specific key hierarchy. Where a backend authentication root of the ciphersuite-specific key hierarchy. Where a backend
server is present, the AAA-Key is transported from the EAP server to authentication server is present, the AAA-Key is transported from the
the authenticator; where it is not present, the AAA-Key is calculated EAP server to the authenticator; where it is not present, the AAA-Key
on the authenticator. is calculated on the authenticator.
Regardless of how many sessions are initiated using it, the AAA-Key Regardless of how many sessions are initiated using it, the AAA-Key
scope is between the EAP peer that calculates it, and the scope is between the EAP peer that calculates it, and the
authenticator that either calculates it (where no backend authenticator that either calculates it (where no backend
authenticator is present) or receives it from the server (where a authenticator is present) or receives it from the server (where a
backend authenticator server is present). backend authenticator server is present).
It should be understood that an authenticator or peer: It should be understood that an authenticator or peer:
[a] may contain multiple physical ports; [a] may contain multiple physical ports;
skipping to change at page 36, line 43 skipping to change at page 33, line 34
peers and authenticators may support multiple ports. peers and authenticators may support multiple ports.
[e] The AAA server and authenticator MAY implement additional [e] The AAA server and authenticator MAY implement additional
attributes in order to further restrict the AAA-Key scope. For attributes in order to further restrict the AAA-Key scope. For
example, in 802.11, the AAA server may provide the authenticator example, in 802.11, the AAA server may provide the authenticator
with a list of authorized Called or Calling-Station-Ids and/or with a list of authorized Called or Calling-Station-Ids and/or
SSIDs for which the AAA-Key is valid. SSIDs for which the AAA-Key is valid.
[f] Where the AAA server provides attributes restricting the key scope, [f] Where the AAA server provides attributes restricting the key scope,
it is RECOMMENDED that restrictions be securely communicated by the it is RECOMMENDED that restrictions be securely communicated by the
authenticator to the peer. This is typically accomplished using authenticator to the peer. This can be accomplished using the
the Secure Association Protocol, but also can be accomplished via Secure Association Protocol, but also can be accomplished via the
the EAP method or the lower layer. EAP method or the lower layer.
4.7. Key Strength 4.7. 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.
skipping to change at page 37, line 50 skipping to change at page 34, line 42
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 [I-D.ietf-aaa-eap], which defines cleartext key
attributes, to be protected by IPsec or TLS. attributes, to be 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, the
AAA-Key may be recovered by an attacker in control of the untrusted AAA-Key may be recovered by an attacker in control of the untrusted
intermediary. Possession of the AAA-Key enables decryption of data intermediary. Possession of the AAA-Key enables decryption of data
traffic sent between the peer and a specific authenticator; however traffic sent between the peer and a specific authenticator. However,
where key separation is implemented, compromise of the AAA-Key does as long as a AAA-Key or keys derived from it is only utilized by a
not enable an attacker to impersonate the peer to another single authenticator, compromise of the AAA-Key does not enable an
authenticator, since that requires possession of the EMSK, which is attacker to impersonate the peer to another authenticator.
not transported by the AAA protocol. This vulnerability may be Vulnerability to an untrusted AAA intermediary can be mitigated by
mitigated by implementation of redirect functionality, as provided in implementation of redirect functionality, as described in [RFC3588]
[RFC3588]. and [I-D.ietf-aaa-eap].
5. Handoff Support 5. Handoff Vulnerabilities
With EAP, a number of mechanisms may 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 a
AAA-Key on an authenticator prior to arrival of the peer. AAA-Key on an authenticator prior to arrival of the peer. Another
such mechanism is AAA-Key caching, in which an EAP peer can re-attach
"Fast Handoff" is defined as a conversation in which the EAP exchange to an authenticator without having to re-authenticate using EAP. Yet
(phase 1a) and associated AAA pass-through is bypassed, so as to another mechanism is context transfer, such as is defined in
reduce latency. Fast handoff mechanisms include: [IEEE-802.11F] and [CTP]. These mechanisms introduce new security
vulnerabilities, as discussed in the sections that follow.
[a] Pre-emptive handoff. In this technique, the AAA server pre-
establishes key state on the authenticator prior to arrival of the
peer, without completion of EAP authentication. As described in
[IEEE-03-084] and [I.D.irtf-aaaarch-handoff], this technique
includes conventional AAA-Key transport, but without an EAP
authentication.
[b] Context transfer. In this technique, the old authenticator
transfers the session text to the new authenticator, either prior
to, or after the arrival of the peer. As a result, AAA-Key
transport (phase 1b) is bypassed.
[c] Key Request. In this technique, the peer requests that the new
authenticator retrieve a named key from the EAP server for
potential use in a forthcoming session. In this technique, EAP
authentication (phase 1a) is bypassed, but AAA-Key transport (phase
1b) is not.
5.1. Authorization 5.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
skipping to change at page 39, line 49 skipping to change at page 36, line 27
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 5.2. Correctness
Bypassing all or portions of the AAA conversation creates challenges When the AAA exchange is bypassed via use of techniques such as AAA-
in ensuring that authorization is properly handled. These include: Key caching, this creates challenges in ensuring that authorization
is properly handled. These include:
[a] Consistent application of session time limits. A fast handoff [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. A fast handoff 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.
[c] Consideration of dynamic state. In situations in which dynamic [c] Consideration of dynamic state. In situations in which dynamic
state is involved in the access decision (day/time, simultaneous state is involved in the access decision (day/time, simultaneous
session limit) it should be possible to take this state into session limit) it should be possible to take this state into
account either before or after access is granted. Note that account either before or after access is granted. Note that
consideration of network-wide state such as simultaneous session consideration of network-wide state such as simultaneous session
limits can typically only be taken into account by the backend limits can typically only be taken into account by the backend
authentication server. authentication server.
skipping to change at page 40, line 32 skipping to change at page 37, line 9
[d] Encoding of restrictions. Since a authenticator may not be aware [d] Encoding of restrictions. Since a authenticator may not be aware
of the criteria considered by a backend authentication server when of the criteria considered by a backend authentication server when
allowing access, in order to ensure consistent authorization during allowing access, in order to ensure consistent authorization during
a fast handoff it may be necessary to explicitly encode the a fast handoff it may be necessary to explicitly encode the
restrictions within the authorizations provided in the AAA-Token. restrictions within the authorizations provided in the AAA-Token.
[e] State validity. The introduction of fast handoff should not render [e] State validity. The introduction of fast handoff should not render
the authentication server incapable of keeping track of network- the authentication server incapable of keeping track of network-
wide state. wide state.
A fast handoff mechanism capable of addressing these concerns is said A handoff mechanism capable of addressing these concerns is said to
to be "correct". One condition for correctness is as follows: For a be "correct". One condition for correctness is as follows: For a
fast handoff to be "correct" it MUST establish on the new device the handoff to be "correct" it MUST establish on the new device the same
same context as would have been created had the new device completed context as would have been created had the new device completed a AAA
a AAA conversation with the authentication server. conversation with the authentication server.
A properly designed fast handoff scheme will only succeed if it is A properly designed handoff scheme will only succeed if it is
"correct" in this way. If a successful fast handoff would establish "correct" in this way. If a successful handoff would establish
"incorrect" state, it is preferable for it to fail, in order to avoid "incorrect" state, it is preferable for it to fail, in order to avoid
creation of incorrect context. creation of incorrect context.
Some backend authentication server and authenticator configurations Some backend authentication server and authenticator configurations
are incapable of meeting this definition of "correctness". For are incapable of meeting this definition of "correctness". For
example, if the old and new device differ in their capabilities, it example, if the old and new device differ in their capabilities, it
may be difficult to meet this definition of correctness in a fast may be difficult to meet this definition of correctness in a handoff
handoff mechanism that bypasses AAA. Backend authentication servers mechanism that bypasses AAA. Backend authentication servers often
often perform conditional evaluation, in which the authorizations perform conditional evaluation, in which the authorizations returned
returned in an Access-Accept message are contingent on the in an Access-Accept message are contingent on the authenticator or on
authenticator or on dynamic state such as the time of day or number dynamic state such as the time of day or number of simultaneous
of simultaneous sessions. For example, in a heterogeneous sessions. For example, in a heterogeneous deployment, the backend
deployment, the backend authentication server might return different authentication server might return different authorizations depending
authorizations depending on the authenticator making the request, in on the authenticator making the request, in order to make sure that
order to make sure that the requested service is consistent with the the requested service is consistent with the authenticator
authenticator capabilities. capabilities.
If differences between the new and old device would result in the If differences between the new and old device would result in the
backend authentication server sending a different set of messages to backend authentication server sending a different set of messages to
the new device than were sent to the old device, then if the fast the new device than were sent to the old device, then if the handoff
handoff mechanism bypasses AAA, then the fast handoff cannot be mechanism bypasses AAA, then the handoff cannot be carried out
carried out correctly. correctly.
For example, if some authenticator devices within a deployment For example, if some authenticator devices within a deployment
support dynamic VLANs while others do not, then attributes present in support dynamic VLANs while others do not, then attributes present in
the Access-Request (such as the authenticator-IP-Address, the Access-Request (such as the authenticator-IP-Address,
authenticator-Identifier, Vendor-Identifier, etc.) could be examined authenticator-Identifier, Vendor-Identifier, etc.) could be examined
to determine when VLAN attributes will be returned, as described in to determine when VLAN attributes will be returned, as described in
[RFC3580]. VLAN support is defined in [IEEE8021Q]. If a fast [RFC3580]. VLAN support is defined in [IEEE-802.1Q]. If a handoff
handoff bypassing the backend authentication server were to occur bypassing the backend authentication server were to occur between a
between a authenticator supporting dynamic VLANs and another authenticator supporting dynamic VLANs and another authenticator
authenticator which does not, then a guest user with access which does not, then a guest user with access restricted to a guest
restricted to a guest VLAN could be given unrestricted access to the VLAN could be given unrestricted access to the network.
network.
Similarly, in a network where access is restricted based on the day Similarly, in a network where access is restricted based on the day
and time, Service Set Identifier (SSID), Calling-Station-Id or other and time, Service Set Identifier (SSID), Calling-Station-Id or other
factors, unless the restrictions are encoded within the factors, unless the restrictions are encoded within the
authorizations, or a partial AAA conversation is included, then a authorizations, or a partial AAA conversation is included, then a
fast handoff could result in the user bypassing the restrictions. handoff could result in the user bypassing the restrictions.
In practice, these considerations limit the situations in which fast In practice, these considerations limit the situations in which fast
handoff mechanisms bypassing AAA can be expected to be successful. handoff mechanisms bypassing AAA can be expected to be successful.
Where the deployed devices implement the same set of services, it may Where the deployed devices implement the same set of services, it may
be possible to do successful fast handoffs within such mechanisms. be possible to do successful handoffs within such mechanisms.
However, where the supported services differ between devices, the However, where the supported services differ between devices, the
fast handoff may not succeed. For example, [RFC2865] section 1.1 handoff may not succeed. For example, [RFC2865] section 1.1 states:
states:
"A authenticator that does not implement a given service MUST NOT "A authenticator that does not implement a given service MUST NOT
implement the RADIUS attributes for that service. For example, a implement the RADIUS attributes for that service. For example, a
authenticator that is unable to offer ARAP service MUST NOT authenticator that is unable to offer ARAP service MUST NOT
implement the RADIUS attributes for ARAP. A authenticator MUST implement the RADIUS attributes for ARAP. A authenticator MUST
treat a RADIUS access-accept authorizing an unavailable service as treat a RADIUS access-accept authorizing an unavailable service as
an access-reject instead." an access-reject instead."
Note that this behavior only applies to attributes that are known, Note that this behavior only applies to attributes that are known,
but not implemented. For attributes that are unknown, [RFC2865] but not implemented. For attributes that are unknown, [RFC2865]
Section 5 states: Section 5 states:
"A RADIUS server MAY ignore Attributes with an unknown Type. A "A RADIUS server MAY ignore Attributes with an unknown Type. A
RADIUS client MAY ignore Attributes with an unknown Type." RADIUS client MAY ignore Attributes with an unknown Type."
In order to perform a correct fast handoff, if a new device is In order to perform a correct handoff, if a new device is provided
provided with RADIUS context for a known but unavailable service, with RADIUS context for a known but unavailable service, then it MUST
then it MUST process this context the same way it would handle a process this context the same way it would handle a RADIUS Access-
RADIUS Access-Accept requesting an unavailable service. This MUST Accept requesting an unavailable service. This MUST cause the
cause the fast handoff to fail. However, if a new device is provided handoff to fail. However, if a new device is provided with RADIUS
with RADIUS context that indicates an unknown attribute, then this context that indicates an unknown attribute, then this attribute MAY
attribute MAY be ignored. be ignored.
Although it may seem somewhat counter-intuitive, failure is indeed Although it may seem somewhat counter-intuitive, failure is indeed
the "correct" result where a known but unsupported service is the "correct" result where a known but unsupported service is
requested. Presumably a correctly configured backend authentication requested. Presumably a correctly configured backend authentication
server would not request that a device carry out a service that it server would not request that a device carry out a service that it
does not implement. This implies that if the new device were to does not implement. This implies that if the new device were to
complete a AAA conversation that it would be likely to receive complete a AAA conversation that it would be likely to receive
different service instructions. In such a case, failure of the fast different service instructions. In such a case, failure of the
handoff is the desired result. This will cause the new device to go handoff is the desired result. This will cause the new device to go
back to the AAA server in order to receive the appropriate service back to the AAA server in order to receive the appropriate service
definition. definition.
In practice, this implies that fast handoff mechanisms which bypass In practice, this implies that handoff mechanisms which bypass AAA
AAA are most likely to be successful within a homogeneous device are most likely to be successful within a homogeneous device
deployment within a single administrative domain. For example, it deployment within a single administrative domain. For example, it
would not be advisable to carry out a fast handoff bypassing AAA would not be advisable to carry out a fast handoff bypassing AAA
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 fast 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 6. Security Considerations
6.1. Security Terminology 6.1. Security Terminology
skipping to change at page 43, line 5 skipping to change at page 39, line 28
"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 6.2. Threat Model
The EAP threat model is described in [RFC3748] Section 7.1. In order The EAP threat model is described in [RFC3748] Section 7.1. In order
to address these threats, EAP relies on the security properties of to address these threats, EAP relies on the security properties of
EAP methods (known as "security claims", described in [RFC3784] EAP methods (known as "security claims", described in [RFC3784]
Section 7.2.1). EAP method requirements for application such as Section 7.2.1). EAP method requirements for application such as
Wireless LAN authentication are described in [WLANREQ]. Wireless LAN authentication are described in [RFC4017].
The RADIUS threat model is described in [RFC3579] Section 4.1, and The RADIUS threat model is described in [RFC3579] Section 4.1, and
responses to these threats are described in [RFC3579] Sections 4.2 responses to these threats are described in [RFC3579] Sections 4.2
and 4.3. Among other things, [RFC3579] Section 4.2 recommends the and 4.3. Among other things, [RFC3579] Section 4.2 recommends the
use of IPsec ESP with non-null transform to provide per-packet use of IPsec ESP with non-null transform to provide per-packet
authentication and confidentiality, integrity and replay protection authentication and confidentiality, integrity and replay protection
for RADIUS/EAP. for RADIUS/EAP.
Given the existing documentation of EAP and AAA threat models and Given the existing documentation of EAP and AAA threat models and
responses, there is no need to duplicate that material here. responses, there is no need to duplicate that material here.
skipping to change at page 46, line 22 skipping to change at page 42, line 44
EAP header, while other methods may only protect the contents of the EAP header, while other methods may only protect the contents of the
Type-Data field, defined in [RFC3748]. Type-Data field, defined in [RFC3748].
Since EAP is spoken only between the EAP peer and server, if a Since EAP is spoken only between the EAP peer and server, if a
backend authentication server is present then the EAP conversation backend authentication server is present then the EAP conversation
does not provide mutual authentication between the peer and does not provide mutual authentication between the peer and
authenticator, only between the EAP peer and EAP server (backend authenticator, only between the EAP peer and EAP server (backend
authentication server). As a result, mutual authentication between authentication server). As a result, mutual authentication between
the peer and authenticator only occurs where a Secure Association the peer and authenticator only occurs where a Secure Association
protocol is used, such the unicast and group key derivation handshake protocol is used, such the unicast and group key derivation handshake
supported in [IEEE80211i]. This means that absent use of a secure supported in [IEEE-802.11i]. This means that absent use of a secure
Association Protocol, from the point of view of the peer, EAP mutual Association Protocol, from the point of view of the peer, EAP mutual
authentication only proves that the authenticator is trusted by the authentication only proves that the authenticator is trusted by the
backend authentication server; the identity of the authenticator is backend authentication server; the identity of the authenticator is
not confirmed. not confirmed.
Utilizing the AAA protocol, the authenticator and backend Utilizing the AAA protocol, the authenticator and backend
authentication server mutually authenticate and derive session keys authentication server mutually authenticate and derive session keys
known only to them, used to provide per-packet integrity and replay known only to them, used to provide per-packet integrity and replay
protection, authentication and confidentiality. The AAA-Key is protection, authentication and confidentiality. The AAA-Key is
distributed by the backend authentication server to the authenticator distributed by the backend authentication server to the authenticator
skipping to change at page 47, line 20 skipping to change at page 43, line 43
These include EAP MD5, as well as One-Time Password (OTP) and Generic These include EAP MD5, as well as One-Time Password (OTP) and Generic
Token Card. These methods support one-way authentication (from EAP Token Card. These methods support one-way authentication (from EAP
peer to authenticator) but not mutual authentication or key peer to authenticator) but not mutual authentication or key
derivation. As a result, these methods do not bind the initial derivation. As a result, these methods do not bind the initial
authentication and subsequent data traffic, even when the the authentication and subsequent data traffic, even when the the
ciphersuite used to protect data supports per-packet authentication ciphersuite used to protect data supports per-packet authentication
and integrity protection. As a result, EAP methods not supporting and integrity protection. As a result, EAP methods not supporting
mutual authentication are vulnerable to session hijacking as well as mutual authentication are vulnerable to session hijacking as well as
attacks by rogue devices. attacks by rogue devices.
On wireless networks such as IEEE 802.11 [IEEE80211], these attacks On wireless networks such as IEEE 802.11 [IEEE-802.11], these attacks
become easy to mount, since any attacker within range can access the become easy to mount, since any attacker within range can access the
wireless medium, or act as an access point. As a result, new wireless medium, or act as an access point. As a result, new
ciphersuites have been proposed for use with wireless LANs ciphersuites have been proposed for use with wireless LANs
[IEEE80211i] which provide per-packet authentication, integrity and [IEEE-802.11i] which provide per-packet authentication, integrity and
replay protection. In addition, mutual authentication and key replay protection. In addition, mutual authentication and key
derivation, provided by methods such as EAP-TLS [RFC2716] are derivation, provided by methods such as EAP-TLS [RFC2716] are
required [IEEE80211i], so as to address the threat of rogue devices, required [IEEE-802.11i], so as to address the threat of rogue
and provide keying material to bind the initial authentication to devices, and provide keying material to bind the initial
subsequent data traffic. authentication to subsequent data traffic.
If the selected EAP method does not support mutual authentication, If the selected EAP method does not support mutual authentication,
then the peer will be vulnerable to attack by rogue authenticators then the peer will be vulnerable to attack by rogue authenticators
and backend authentication servers. If the EAP method does not derive and backend authentication servers. If the EAP method does not derive
keys, then TSKs will not be available for use with a negotiated keys, then TSKs will not be available for use with a negotiated
ciphersuite, and there will be no binding between the initial EAP ciphersuite, and there will be no binding between the initial EAP
authentication and subsequent data traffic, leaving the session authentication and subsequent data traffic, leaving the session
vulnerable to hijack. vulnerable to hijack.
If the backend authentication server does not protect against If the backend authentication server does not protect against
skipping to change at page 52, line 44 skipping to change at page 49, line 19
recovering the MSK or EMSK MUST NOT be able to recover the other recovering the MSK or EMSK MUST NOT be able to recover the other
quantity with a level of effort less than brute force. quantity with a level of effort less than brute force.
Non-overlapping substrings of the MSK MUST be cryptographically Non-overlapping substrings of the MSK MUST be cryptographically
separate from each other. That is, knowledge of one substring MUST separate from each other. That is, knowledge of one substring MUST
NOT help in recovering some other non-overlapping substring without NOT help in recovering some other non-overlapping substring without
breaking some hard cryptographic assumption. This is required breaking some hard cryptographic assumption. This is required
because some existing ciphersuites form TSKs by simply splitting the because some existing ciphersuites form TSKs by simply splitting the
AAA-Key to pieces of appropriate length. Likewise, non-overlapping AAA-Key to pieces of appropriate length. Likewise, non-overlapping
substrings of the EMSK MUST be cryptographically separate from each substrings of the EMSK MUST be cryptographically separate from each
other, and from substrings of the MSK. other, and from substrings of the MSK. The EMSK MUST NOT be
transported to, or shared with, additional parties.
The EMSK MUST remain on the EAP peer and EAP server where it is
derived; it MUST NOT be transported to, or shared with, additional
parties, or used for purposes other than AMSK derivation (see Section
2.4).
Since EAP does not provide for explicit key lifetime negotiation, EAP Since EAP does not provide for explicit key lifetime negotiation, EAP
peers, authenticators and authentication servers MUST be prepared for peers, authenticators and authentication servers MUST be prepared for
situations in which one of the parties discards key state which situations in which one of the parties discards key state which
remains valid on another party. remains valid on another party.
The development and validation of key derivation algorithms is The development and validation of key derivation algorithms is
difficult, and as a result EAP methods SHOULD reuse well established difficult, and as a result EAP methods SHOULD reuse well established
and analyzed mechanisms for MSK and EMSK key derivation (such as and analyzed mechanisms for MSK and EMSK key derivation (such as
those specified in IKE [RFC2409] or TLS [RFC2246]), rather than those specified in IKE [RFC2409] or TLS [RFC2246]), rather than
skipping to change at page 53, line 30 skipping to change at page 49, line 50
o The key material used for the EMSK MUST be o The key material used for the EMSK MUST be
computationally independent of the MSK and TEKs. computationally independent of the MSK and TEKs.
o The EMSK MUST NOT be used for any other purpose than the key o The EMSK MUST NOT be used for any other purpose than the key
derivation described in this document. derivation described in this document.
o The EMSK MUST be secret and not known to someone observing o The EMSK MUST be secret and not known to someone observing
the authentication mechanism protocol exchange. the authentication mechanism protocol exchange.
o The EMSK MUST NOT be exported from the EAP server. o The EMSK MUST NOT be exported from the EAP server.
Only keys (AMSKs) derived according to this specification
may be exported from the EAP server.
o The EMSK MUST be unique for each session. o The EMSK MUST be unique for each session.
o The EAP mechanism SHOULD a unique identifier suitable for naming the EMSK. o The EAP mechanism SHOULD a unique identifier suitable for naming the EMSK.
Implementations of EAP frameworks on the EAP-Peer and EAP-Server
SHOULD provide an interface to obtain AMSKs. The implementation MAY
restrict which callers can obtain which keys.
7.1.2. Requirements for EAP applications 7.1.2. Requirements for EAP applications
In order for an application to meet the guidelines for EMSK usage it In order for an application to meet the guidelines for EMSK usage it
must meet the following requirements: must meet the following requirements:
o New applications following this specification SHOULD NOT use the o New applications following this specification SHOULD NOT use the
MSK. If more than one application uses the MSK, then the MSK. If more than one application uses the MSK, then the
cryptographic separation is not achieved. Implementations SHOULD cryptographic separation is not achieved. Implementations SHOULD
prevent such combinations. prevent such combinations.
o A peer MUST NOT use the EMSK in any other way except to o A peer MUST NOT use the EMSK directly for cryptographic
derive Application Master Session Keys (AMSKs) using the protection of data.
key derivation specified in Section 2.4. It MUST NOT
use the EMSK directly for cryptographic protection of data,
and SHOULD provide only the AMSKs to applications.
o Applications MUST define distinct key labels, application
specific data, and the length of derived key material used in the key
derivation described in Section 2.4.
o Applications MUST define how they use their AMSK to derive TSKs
for their use.
7.2. AAA Protocol Requirements 7.2. AAA Protocol Requirements
AAA protocols suitable for use in transporting EAP MUST provide the AAA protocols suitable for use in transporting EAP MUST provide the
following facilities: following facilities:
Security services Security services
AAA protocols used for transport of EAP keying material MUST AAA protocols used for transport of EAP keying material MUST
implement and SHOULD use per-packet integrity and authentication, implement and SHOULD use per-packet integrity and authentication,
replay protection and confidentiality. These requirements are met replay protection and confidentiality. These requirements are met
skipping to change at page 57, line 50 skipping to change at page 54, line 7
deriving TEKs MAY be specific to the EAP method. deriving TEKs MAY be specific to the EAP method.
Cryptographic separation Cryptographic separation
The TSKs derived from the AAA-Key MUST be cryptographically The TSKs derived from the AAA-Key MUST be cryptographically
separate from each other. Similarly, TEKs MUST be separate from each other. Similarly, TEKs MUST be
cryptographically separate from each other. In addition, the TSKs cryptographically separate from each other. In addition, the TSKs
MUST be cryptographically separate from the TEKs. MUST be cryptographically separate from the TEKs.
8. IANA Considerations 8. IANA Considerations
This section provides guidance to the Internet Assigned Numbers This document does not create any new name spaces nor does it
Authority (IANA) regarding registration of values related to EAP key allocate any protocol parameters.
management, in accordance with BCP 26, [RFC2434].
The following terms are used here with the meanings defined in BCP
26: "name space", "assigned value", "registration".
The following policies are used here with the meanings defined in BCP
26: "Private Use", "First Come First Served", "Expert Review",
"Specification Required", "IETF Consensus", "Standards Action".
For registration requests where a Designated Expert should be
consulted, the responsible IESG area director should appoint the
Designated Expert. The intention is that any allocation will be
accompanied by a published RFC. But in order to allow for the
allocation of values prior to the RFC being approved for publication,
the Designated Expert can approve allocations once it seems clear
that an RFC will be published. The Designated expert will post a
request to the EAP WG mailing list (or a successor designated by the
Area Director) for comment and review, including an Internet-Draft.
Before a period of 30 days has passed, the Designated Expert will
either approve or deny the registration request and publish a notice
of the decision to the EAP WG mailing list or its successor, as well
as informing IANA. A denial notice must be justified by an
explanation and, in the cases where it is possible, concrete
suggestions on how the request can be modified so as to become
acceptable.
This document introduces a new name space for "key labels". Key
labels are ASCII strings and are assigned via IETF Consensus. It is
expected that key label specifications will include the following
information:
o A description of the application
o The key label to be used
o How TSKs will be derived from the AMSK and how they will be used
o If application specific data is used, what it is and how it is
maintained
o Where the AMSKs or TSKs will be used and how they are
communicated if necessary.
9. References 9. References
9.1. Normative References 9.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
skipping to change at page 60, line 30 skipping to change at page 55, line 46
"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.
[FIPSDES] National Institute of Standards and Technology, "Data [RFC4017] Stanley, D., Walker, J. and B. Aboba, "EAP Method Requirements
Encryption Standard", FIPS PUB 46, January 1977. for Wireless LANs", RFC 4017, March 2005.
[CTP] Loughney, J., Nakhjiri, M., Perkins, C. and R. Koodli,
"Context Transfer Protocol", draft-ietf-seamoby-ctp-11.txt,
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>.
[IEEE802] Institute of Electrical and Electronics Engineers, "IEEE [FIPSDES] National Institute of Standards and Technology, "Data
Encryption Standard", FIPS PUB 46, January 1977.
[IEEE-802]
Institute of Electrical and Electronics Engineers, "IEEE
Standards for Local and Metropolitan Area Networks: Overview Standards for Local and Metropolitan Area Networks: Overview
and Architecture", ANSI/IEEE Standard 802, 1990. and Architecture", ANSI/IEEE Standard 802, 1990.
[IEEE80211] [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.
[IEEE8021X] [IEEE-802.1X]
Institute of Electrical and Electronics Engineers, "Local and Institute of Electrical and Electronics Engineers, "Local and
Metropolitan Area Networks: Port-Based Network Access Metropolitan Area Networks: Port-Based Network Access
Control", IEEE Standard 802.1X-2004, December 2004. Control", IEEE Standard 802.1X-2004, December 2004.
[IEEE8021Q] [IEEE-802.1Q]
Institute of Electrical and Electronics Engineers, "IEEE Institute of Electrical and Electronics Engineers, "IEEE
Standards for Local and Metropolitan Area Networks: Draft Standards for Local and Metropolitan Area Networks: Draft
Standard for Virtual Bridged Local Area Networks", IEEE Standard for Virtual Bridged Local Area Networks", IEEE
Standard 802.1Q/D8, January 1998. Standard 802.1Q/D8, January 1998.
[IEEE80211F] [IEEE-802.11i]
Institute of Electrical and Electronics Engineers,
"Recommended Practice for Multi-Vendor Access Point
Interoperability via an Inter-Access Point Protocol Across
Distribution Systems Supporting IEEE 802.11 Operation", IEEE
802.11F, July 2003.
[IEEE80211i]
Institute of Electrical and Electronics Engineers, "Supplement Institute of Electrical and Electronics Engineers, "Supplement
to STANDARD FOR Telecommunications and Information Exchange to STANDARD FOR Telecommunications and Information Exchange
between Systems - LAN/MAN Specific Requirements - Part 11: between Systems - LAN/MAN Specific Requirements - Part 11:
Wireless Medium Access Control (MAC) and physical layer (PHY) Wireless Medium Access Control (MAC) and physical layer (PHY)
specifications: Specification for Enhanced Security", IEEE specifications: Specification for Enhanced Security", IEEE
802.11i, December 2004. 802.11i, December 2004.
[IEEE-802.11F]
Institute of Electrical and Electronics Engineers,
"Recommended Practice for Multi-Vendor Access Point
Interoperability via an Inter-Access Point Protocol Across
Distribution Systems Supporting IEEE 802.11 Operation", IEEE
802.11F, July 2003.
[IEEE-02-758] [IEEE-02-758]
Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang,
"Proactive Caching Strategies for IAPP Latency Improvement "Proactive Caching Strategies for IAPP Latency Improvement
during 802.11 Handoff", IEEE 802.11 Working Group, during 802.11 Handoff", IEEE 802.11 Working Group,
IEEE-02-758r1-F Draft 802.11I/D5.0, November 2002. IEEE-02-758r1-F Draft 802.11I/D5.0, November 2002.
[IEEE-03-084] [IEEE-03-084]
Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang,
"Proactive Key Distribution to support fast and secure "Proactive Key Distribution to support fast and secure
roaming", IEEE 802.11 Working Group, IEEE-03-084r1-I, roaming", IEEE 802.11 Working Group, IEEE-03-084r1-I,
skipping to change at page 62, line 6 skipping to change at page 57, line 32
[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] [I-D.ietf-aaa-eap]
Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application", draft-ietf-aaa- Authentication Protocol (EAP) Application", draft-ietf-aaa-
eap-10 (work in progress), November 2004. eap-10 (work in progress), November 2004.
[I-D.irtf-aaaarch-handoff]
Arbaugh, W. and B. Aboba, "Handoff Extension to RADIUS",
draft-irtf-aaaarch-handoff-04 (work in progress), October
2003.
[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.aboba-802-context]
Aboba, B. and T. Moore, "A Model for Context Transfer in IEEE
802", draft-aboba-802-context-03 (work in progress), October
2003.
[I-D.arkko-pppext-eap-aka] [I-D.arkko-pppext-eap-aka]
Arkko, J. and H. Haverinen, "EAP AKA Authentication", draft- Arkko, J. and H. Haverinen, "EAP AKA Authentication", draft-
arkko-pppext-eap-aka-15.txt (work in progress), December 2004. arkko-pppext-eap-aka-15.txt (work in progress), December 2004.
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", draft- [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", draft-
ietf-ipsec-ikev2-17 (work in progress), September 2004. ietf-ipsec-ikev2-17 (work in progress), September 2004.
[8021XHandoff] [8021XHandoff]
Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff in a Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff in a
Public Wireless LAN Based on IEEE 802.1X Model", School of Public Wireless LAN Based on IEEE 802.1X Model", School of
Computer Science and Engineering, Seoul National University, Computer Science and Engineering, Seoul National University,
Seoul, Korea, 2002. Seoul, Korea, 2002.
[MD5Attack] [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.
[WLANREQ] Stanley, D., Walker, J. and B. Aboba, "EAP Method Requirements
for Wireless LANs", draft-walker-ieee802-req-04.txt (work in
progress), August 2004.
[Housley56] [Housley56]
Housley, R., "Key Management in AAA", Presentation to the AAA Housley, R., "Key Management in AAA", Presentation to the AAA
WG at IETF 56, WG at IETF 56,
http://www.ietf.org/proceedings/03mar/slides/aaa-5/index.html, http://www.ietf.org/proceedings/03mar/slides/aaa-5/index.html,
March 2003. March 2003.
Acknowledgments Acknowledgments
Thanks to Arun Ayyagari, Ashwin Palekar, and Tim Moore of Microsoft, Thanks to Arun Ayyagari, Ashwin Palekar, and Tim Moore of Microsoft,
Dorothy Stanley of Agere, Bob Moskowitz of TruSecure, Jesse Walker of Dorothy Stanley of Agere, Bob Moskowitz of TruSecure, Jesse Walker of
skipping to change at page 64, line 31 skipping to change at page 60, line 31
provided by EAP. provided by EAP.
For MPPE, 40-bit, 56-bit or 128-bit encryption keys are required in For MPPE, 40-bit, 56-bit or 128-bit encryption keys are required in
each direction, as described in [RFC3078]. No initialization vector each direction, as described in [RFC3078]. No initialization vector
is required. is required.
While these PPP ciphersuites provide encryption, they do not provide While these PPP ciphersuites provide encryption, they do not provide
per-packet authentication or integrity protection, so an per-packet authentication or integrity protection, so an
authentication key is not required in either direction. authentication key is not required in either direction.
Within [IEEE80211], Transient Session Keys (TSKs) are required both Within [IEEE-802.11], Transient Session Keys (TSKs) are required both
for unicast traffic as well as for multicast traffic, and therefore for unicast traffic as well as for multicast traffic, and therefore
separate key hierarchies are required for unicast keys and multicast separate key hierarchies are required for unicast keys and multicast
keys. IEEE 802.11 ciphersuites include WEP-40, described in keys. IEEE 802.11 ciphersuites include WEP-40, described in
[IEEE80211], which requires a 40-bit encryption key, the same 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 either direction; and WEP-128, which requires a 104-bit encryption
key, the same in either direction. These ciphersuites also do not key, the same in either direction. These ciphersuites also do not
support per-packet authentication and integrity protection. In support per-packet authentication and integrity protection. In
addition to these unicast keys, authentication and encryption keys addition to these unicast keys, authentication and encryption keys
are required to wrap the multicast encryption key. are required to wrap the multicast encryption key.
Recently, new ciphersuites have been proposed for use with IEEE Recently, new ciphersuites have been proposed for use with IEEE
802.11 that provide per-packet authentication and integrity 802.11 that provide per-packet authentication and integrity
protection as well as encryption [IEEE80211i]. These include TKIP, protection as well as encryption [IEEE-802.11i]. These include TKIP,
which requires a single 128-bit encryption key and two 64-bit which requires a single 128-bit encryption key and two 64-bit
authentication keys (one for each direction); and AES CCMP, which authentication keys (one for each direction); and AES CCMP, which
requires a single 128-bit key (used in both directions) in order to requires a single 128-bit key (used in both directions) in order to
authenticate and encrypt data. authenticate and encrypt data.
As with WEP, authentication and encryption keys are also required to As with WEP, authentication and encryption keys are also required to
wrap the multicast encryption (and possibly, authentication) keys. wrap the multicast encryption (and possibly, authentication) keys.
Appendix B - Transient EAP Key (TEK) Hierarchy Appendix B - Transient EAP Key (TEK) Hierarchy
skipping to change at page 66, line 29 skipping to change at page 62, line 29
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 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 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 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 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 TLS master secret, if the TLS master secret is compromised then the
MSK is also compromised. MSK is also compromised.
As described in [RFC2716], the formula for the derivation of the MSK, The key derivation scheme specified in RFC 2716 that was specified
EMSK and IV is as follows: 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) AAA-Key(0,31) = Peer to Authenticator Encryption Key (Enc-RECV-Key)
skipping to change at page 68, line 10 skipping to change at page 64, line 10
| | V | | V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
Figure C-1 - EAP TLS [RFC2716] Key hierarchy Figure C-1 - EAP TLS [RFC2716] Key hierarchy
Appendix D - Example Transient Session Key (TSK) Derivation Appendix D - Example Transient Session Key (TSK) Derivation
Within IEEE 802.11 RSN, the Pairwise Transient Key (PTK), a transient Within IEEE 802.11 RSN, the Pairwise Transient Key (PTK), a transient
session key used to protect unicast traffic, is derived from the PMK 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 (octets 0-31 of the MSK), known in [RFC2716] as the Peer to
Authenticator Encryption Key. In [IEEE80211i], the PTK is derived Authenticator Encryption Key. In [IEEE-802.11i], the PTK is derived
from the PMK via the following formula: from the PMK via the following formula:
PTK = EAPOL-PRF-X(PMK, "Pairwise key expansion", Min(AA,SA) || PTK = EAPOL-PRF-X(PMK, "Pairwise key expansion", Min(AA,SA) ||
Max(AA, SA) || Min(ANonce,SNonce) || Max(ANonce,SNonce)) Max(AA, SA) || Min(ANonce,SNonce) || Max(ANonce,SNonce))
Where: Where:
PMK = AAA-Key(0,31) PMK = AAA-Key(0,31)
SA = Station MAC address (Calling-Station-Id) SA = Station MAC address (Calling-Station-Id)
AA = Access Point MAC address (Called-Station-Id) AA = Access Point MAC address (Called-Station-Id)
skipping to change at page 68, line 34 skipping to change at page 64, line 34
a PTK of size X octets. a PTK of size X octets.
TKIP uses X = 64, while CCMP, WRAP, and WEP use X = 48. TKIP uses X = 64, while CCMP, WRAP, and WEP use X = 48.
The EAPOL-Key Confirmation Key (KCK) is used to provide data origin The EAPOL-Key Confirmation Key (KCK) is used to provide data origin
authenticity in the TSK derivation. It utilizes the first 128 bits authenticity in the TSK derivation. It utilizes the first 128 bits
(bits 0-127) of the PTK. The EAPOL-Key Encryption Key (KEK) provides (bits 0-127) of the PTK. The EAPOL-Key Encryption Key (KEK) provides
confidentiality in the TSK derivation. It utilizes bits 128-255 of confidentiality in the TSK derivation. It utilizes bits 128-255 of
the PTK. Bits 256-383 of the PTK are used by Temporal Key 1, and Bits the PTK. Bits 256-383 of the PTK are used by Temporal Key 1, and Bits
384-511 are used by Temporal Key 2. Usage of TK1 and TK2 is 384-511 are used by Temporal Key 2. Usage of TK1 and TK2 is
ciphersuite specific. Details are available in [IEEE80211i]. ciphersuite specific. Details are available in [IEEE-802.11i].
Appendix E - Key Names and Scope in Existing Methods Appendix E - Key Names and Scope in Existing Methods
This appendix specifies the key names and scope in methods that have This appendix specifies the key names and scope in methods that have
been published prior to the publication of this RFC. What is needed been published prior to the publication of this RFC. What is needed
in addition to the rules in Section 2.4 is the definition of what EAP in addition to the rules in Section 2.4 is the definition of what EAP
peer and server names are used, what Method-Id is used, and how these peer and server names are used, what Method-Id is used, and how these
are encoded. are encoded.
EAP-TLS EAP-TLS
 End of changes. 

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