draft-ietf-eap-keying-03.txt   draft-ietf-eap-keying-04.txt 
EAP Working Group Bernard Aboba EAP Working Group Bernard Aboba
INTERNET-DRAFT Dan Simon INTERNET-DRAFT Dan Simon
Category: Informational Microsoft Category: Informational Microsoft
<draft-ietf-eap-keying-03.txt> J. Arkko <draft-ietf-eap-keying-04.txt> J. Arkko
18 July 2004 Ericsson 14 November 2004 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
Status of this Memo By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
This document is an Internet-Draft and is in full conformance with and any of which I become aware will be disclosed, in accordance with
all provisions of Section 10 of RFC 2026. RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 22, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). 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". "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. EAP Key Hierarchy ..................................... 13 2. EAP Key Hierarchy ..................................... 13
2.1 Key Terminology ................................. 13 2.1 Key Terminology ................................. 13
2.2 Key Hierarchy ................................... 15 2.2 Key Hierarchy ................................... 15
2.3 Key Lifetimes ................................... 17 2.3 Key Lifetimes ................................... 17
2.4 Key Naming ...................................... 24 2.4 Key Names and Scopes ............................ 24
3. Security associations ................................. 26 2.5 AAA-Key Derivation .............................. 27
3.1 EAP Method SA ................................... 26 2.6 AMSK Key Derivation ............................. 28
3.2 EAP-Key SA ...................................... 28 2.7 Key Scope Issues ................................ 29
3.3 AAA SA(s) ....................................... 28 3. Security associations ................................. 30
3.4 Service SA(s) ................................... 29 3.1 EAP Method SA ................................... 31
4. Handoff Support ....................................... 34 3.2 EAP-Key SA ...................................... 33
4.1 Key Scope Issues ................................ 35 3.3 AAA SA(s) ....................................... 33
4.2 Authorization Issues ............................ 36 3.4 Service SA(s) ................................... 34
4.3 Correctness Issues .............................. 38 4. Handoff Support ....................................... 39
5. Security Considerations .............................. 40 4.1 Authorization Issues ............................ 39
5.1 Security Terminology ............................ 40 4.2 Correctness Issues .............................. 41
5.2 Threat Model .................................... 41 5. Security Considerations .............................. 44
5.3 Security Analysis ............................... 43 5.1 Security Terminology ............................ 44
5.4 Man-in-the-middle Attacks ....................... 47 5.2 Threat Model .................................... 44
5.5 Denial of Service Attacks ....................... 47 5.3 Security Analysis ............................... 45
5.6 Impersonation ................................... 48 5.4 Man-in-the-middle Attacks ....................... 49
5.7 Channel Binding ................................. 49 5.5 Denial of Service Attacks ....................... 49
5.8 Key Strength .................................... 50 5.6 Impersonation ................................... 50
5.9 Key Wrap ........................................ 50 5.7 Channel Binding ................................. 51
6. Security Requirements ................................. 51 5.8 Key Strength .................................... 52
6.1 EAP Method Requirements ......................... 51 5.9 Key Wrap ........................................ 53
6.2 AAA Protocol Requirements ....................... 54 6. Security Requirements ................................. 53
6.3 Secure Association Protocol Requirements ........ 55 6.1 EAP Method Requirements ......................... 53
6.4 Ciphersuite Requirements ........................ 57 6.2 AAA Protocol Requirements ....................... 56
7. IANA Considerations ................................... 58 6.3 Secure Association Protocol Requirements ........ 58
8. References ............................................ 59 6.4 Ciphersuite Requirements ........................ 60
8.1 Normative References ............................ 59 7. IANA Considerations ................................... 60
8.2 Informative References .......................... 59 8. References ............................................ 61
Acknowledgments .............................................. 63 8.1 Normative References ............................ 61
Author's Addresses ........................................... 63 8.2 Informative References .......................... 61
Appendix A - Ciphersuite Keying Requirements ................. 65 Acknowledgments .............................................. 65
Appendix B - Transient EAP Key (TEK) Hierarchy ............... 66 Author's Addresses ........................................... 65
Appendix C - EAP Key Hierarchy ............................... 67 Appendix A - Ciphersuite Keying Requirements ................. 67
Appendix D - Transient Session Key (TSK) Derivation .......... 69 Appendix B - Example Transient EAP Key (TEK) Hierarchy ....... 68
Appendix E - AAA-Key Derivation .............................. 70 Appendix C - EAP-TLS Key Hierarchy ........................... 69
Appendix F - AMSK Derivation ................................. 71 Appendix D - Example Transient Session Key (TSK) Derivation .. 71
Intellectual Property Statement .............................. 72 Appendix E - Key Names and Scope in Existing Methods ......... 72
Full Copyright Statement ..................................... 72 Intellectual Property Statement .............................. 73
Disclaimer of Validity ....................................... 73
Copyright Statement .......................................... 73
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 [IEEE8021X].
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". Since in EAP keying material is generated by EAP known as "methods". In EAP keying material is generated by EAP
methods, transported by AAA protocols, transformed into session keys methods. Part of this keying material may be used by EAP methods
by Secure Association Protocols and used by lower layer ciphersuites, themselves and part of this material may be exported. The exported
it is necessary to describe each of these elements and provide a keying material may be transported by AAA protocols or transformed by
system-level security analysis. Secure Association Protocols into session keys which are used by
lower layer ciphersuites. This document describes each of these
elements and provides a system-level security analysis. It also
specifies the EAP key hierarchy.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119]. document are to be interpreted as described in BCP 14 [RFC2119].
1.2. Terminology 1.2. Terminology
This document frequently uses the following terms: This document frequently uses the following terms:
authenticator auth
enticator
The end of the link initiating EAP authentication. The term The end of the link initiating EAP authentication. The term
Authenticator is used in [IEEE-802.1X], and authenticator has the Authenticator is used in [IEEE-802.1X], and authenticator has the
same meaning in this document. same meaning in this document.
peer The end of the link that responds to the authenticator. In peer The end of the link that responds to the authenticator. In
[IEEE-802.1X], this end is known as the Supplicant. [IEEE-802.1X], this end is known as the Supplicant.
Supplicant Supplicant
The end of the link that responds to the authenticator in The end of the link that responds to the authenticator in
[IEEE-802.1X]. In this document, this end of the link is called [IEEE-802.1X]. In this document, this end of the link is called
skipping to change at page 5, line 14 skipping to change at page 5, line 18
authentication server" are used interchangeably. authentication server" are used interchangeably.
EAP server EAP server
The entity that terminates the EAP authentication method with the The entity that terminates the EAP authentication method with the
peer. In the case where no backend authentication server is used, peer. In the case where no backend authentication server is used,
the EAP server is part of the authenticator. In the case where the the EAP server is part of the authenticator. In the case where the
authenticator operates in pass-through mode, the EAP server is authenticator operates in pass-through mode, the EAP server is
located on the backend authentication server. located on the backend authentication server.
security association security association
A set of policies and key(s) used to protect information. This A set of policies and cryptographic state used to protect
information in the security association is stored by each party of information. Elements of a security association may include
the security association and must be consistent among the parties. cryptographic keys, negotiated ciphersuites and other parameters,
Elements of a security association include cryptographic keys, counters, sequence spaces, authorization attributes, etc.
negotiated ciphersuites and other parameters, counters, sequence
spaces, authorization attributes, etc.
1.3. Overview 1.3. Overview
EAP is typically deployed in order to support extensible network EAP is typically deployed in order to support extensible network
access authentication in situations where a peer desires network access authentication in situations where a peer desires network
access via one or more authenticators. The situation is illustrated access via one or more authenticators. Since both the peer and
in Figure 1. authenticator may have more than one physical or logical port, a
given peer may simultaneously access the network via multiple
Since both the peer and authenticator may have more than one physical authenticators, or via multiple physical or logical ports on a given
or logical port, a given peer may simultaneously access the network authenticator. Similarly, an authenticator may offer network access
via multiple authenticators, or via multiple physical or logical to multiple peers, each via a separate physical or logical port. The
ports on a given authenticator. Similarly, an authenticator may situation is illustrated in Figure 1.
offer network access to multiple peers, each via a separate physical
or logical port.
The peer may be stationary, in which case it may establish
communications with one or more authenticators while remaining in one
location. Alternatively, the peer may be mobile, changing its point
of attachment from one authenticator to another, or moving between
points of attachment on a single authenticator.
Where authenticators are deployed standalone, the EAP conversation Where authenticators are deployed standalone, the EAP conversation
occurs between the peer and authenticator, and the authenticator must occurs between the peer and authenticator, and the authenticator must
locally implement an EAP method acceptable to the peer. locally implement an EAP method acceptable to the peer. However, one
of the advantages of EAP is that it enables deployment of new
authentication methods without requiring development of new code on
the authenticator. While the authenticator may implement some EAP
methods locally and use those methods to authenticate local users, it
may at the same time act as a pass-through for other users and
methods, forwarding EAP packets back and forth between the backend
authentication server and the peer.
However, one of the advantages of EAP is that it enables deployment This is accomplished by encapsulating EAP packets within the
of new authentication methods without requiring development of new Authentication, Authorization and Accounting (AAA) protocol, spoken
code on the authenticator. While the authenticator may implement between the authenticator and backend authentication server. AAA
some EAP methods locally and use those methods to authenticate local protocols supporting EAP include RADIUS [RFC3579] and Diameter [I-
users, it may at the same time act as a pass-through for other users D.ietf-aaa-eap].
and methods, forwarding EAP packets back and forth between the
backend authentication server and the peer.
+-+-+-+-+ +-+-+-+-+
| | | |
| EAP | | EAP |
| Peer | | Peer |
| | | |
+-+-+-+-+ +-+-+-+-+
| | | Peer Ports | | | Peer Ports
/ | \ / | \
/ | \ / | \
Phase 0: Discovery / | \ / | \
Phase 1: Authentication / | \ / | \
Phase 2: Secure / | \ / | \
Association / | \ / | \
/ | \ / | \
/ | \ / | \
| | | | | | | | | Authenticator Ports | | | | | | | | | Authenticator Ports
+-+-+-+-+ +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ +-+-+-+-+
| | | | | | | | | | | |
| Auth. | | Auth. | | Auth. | | Auth. | | Auth. | | Auth. |
| | | | | | | | | | | |
+-+-+-+-+ +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ +-+-+-+-+
\ | / \ | /
\ | / \ | /
skipping to change at page 6, line 43 skipping to change at page 6, line 43
\ | / \ | /
+-+-+-+-+ +-+-+-+-+
| | | |
| AAA | | AAA |
|Server | |Server |
| | | |
+-+-+-+-+ +-+-+-+-+
Figure 1: Relationship between peer, authenticator and backend server Figure 1: Relationship between peer, authenticator and backend server
This is accomplished by encapsulating EAP packets within the
Authentication, Authorization and Accounting (AAA) protocol, spoken
between the authenticator and backend authentication server. AAA
protocols supporting EAP include RADIUS [RFC3579] and Diameter [I-
D.ietf-aaa-eap].
Where EAP key derivation is supported, the conversation between the Where EAP key derivation is supported, the conversation between the
peer and the authenticator typically takes place in three phases: peer and the authenticator typically takes place in three phases:
Phase 0: Discovery Phase 0: Discovery
Phase 1: Authentication Phase 1: Authentication
1a: EAP authentication 1a: EAP authentication
1b: AAA-Key Transport (optional) 1b: AAA-Key Transport (optional)
Phase 2: Secure Association Establishment Phase 2: Secure Association Establishment
2a: Unicast Secure Association 2a: Unicast Secure Association
2b: Multicast Secure Association (optional) 2b: Multicast Secure Association (optional)
skipping to change at page 7, line 40 skipping to change at page 7, line 28
An additional step (phase 1b) is required in deployments which An additional step (phase 1b) is required in deployments which
include a backend authentication server, in order to transport keying include a backend authentication server, in order to transport keying
material (known as the AAA-Key) from the backend authentication material (known as the AAA-Key) from the backend authentication
server to the authenticator. server to the authenticator.
A Secure Association exchange (phase 2) then occurs between the peer A Secure Association exchange (phase 2) then occurs between the peer
and authenticator in order to manage the creation and deletion of and authenticator in order to manage the creation and deletion of
unicast (phase 2a) and multicast (phase 2b) security associations unicast (phase 2a) and multicast (phase 2b) security associations
between the peer and authenticator. between the peer and authenticator.
The conversation phases and relationship between the parties is shown EAP may be used in the following scenarios:
in Figure 2.
[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 2) MAY be ommitted.
[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, the Secure Association
Protocol (Phase 2) is REQUIRED.
The conversation phases and relationship between the parties is
shown in Figure 2.
Abo
EAP peer Authenticator Auth. Server EAP peer Authenticator Auth. Server
-------- ------------- ------------ -------- ------------- ------------
|<----------------------------->| | |<----------------------------->| |
| Discovery (phase 0) | | | Discovery (phase 0) | |
|<----------------------------->|<----------------------------->| |<----------------------------->|<----------------------------->|
| EAP auth (phase 1a) | AAA pass-through (optional) | | EAP auth (phase 1a) | AAA pass-through (optional) |
| | | | | |
| |<----------------------------->| | |<----------------------------->|
| | AAA-Key transport | | | AAA-Key transport |
| | (optional; phase 1b) | | | (optional; phase 1b) |
skipping to change at page 8, line 31 skipping to change at page 8, line 30
| (optional; phase 2b) | | | (optional; phase 2b) | |
| | | | | |
Figure 2: Conversation Overview Figure 2: Conversation Overview
1.3.1. Discovery Phase 1.3.1. Discovery Phase
In the discovery phase (phase 0), the EAP peer and authenticator In the discovery phase (phase 0), the EAP peer and authenticator
locate each other and discover each other's capabilities. Discovery locate each other and discover each other's capabilities. Discovery
can occur manually or automatically, depending on the lower layer can occur manually or automatically, depending on the lower layer
over which EAP runs. Since discovery is handled outside of EAP, over which EAP runs. Since authenticator discovery is handled
there is no need to provide this functionality within EAP. outside of EAP, there is no need to provide this functionality within
EAP.
For example, where EAP runs over PPP, the EAP peer might be 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 In contrast, PPPoE [RFC2516] provides support for a Discovery Stage
to allow a peer to identify the Ethernet MAC address of one or more to allow a peer to identify the Ethernet MAC address of one or more
authenticators and establish a PPPoE SESSION_ID. authenticators and establish a PPPoE SESSION_ID.
skipping to change at page 10, line 7 skipping to change at page 10, line 9
committed to joining the network associated with an EAP server. committed to joining the network associated with an EAP server.
Rather, this commitment is implied by the creation of a security Rather, this commitment is implied by the creation of a security
association between the EAP peer and authenticator, as part of the association between the EAP peer and authenticator, as part of the
Secure Association Protocol (phase 2). As a result, EAP may be used Secure Association Protocol (phase 2). As a result, EAP may be used
for "pre-authentication" in situations where it is necessary to pre- for "pre-authentication" in situations where it is necessary to pre-
establish EAP security associations in order to decrease handoff or establish EAP security associations in order to decrease handoff or
roaming latency. roaming latency.
1.3.3. Secure Association Phase 1.3.3. Secure Association Phase
The Secure Association phase (phase 2) always occurs after the The Secure Association phase (phase 2), if it occurs, begins after
completion of EAP authentication (phase 1a) and key transport (phase the completion of EAP authentication (phase 1a) and key transport
1b), and typically supports the following features: (phase 1b), and typically supports the following features:
[1] Entity Naming. A basic feature of a Secure Association Protocol is [1] Generation of fresh transient session keys (TSKs). Where AAA-Key
the naming of the parties engaged in the exchange. As illustrated caching is supported, the EAP peer may initiate a new session using
in Figure 1, it is possible for both the peer and NAS to have more a AAA-Key that was used in a previous session. Were the TSKs to be
than one physical or virtual port. For the purposes of derived from a portion of the AAA-Key, this would result in reuse
identification, it is therefore not possible to identify either of the session keys which could expose the underlying ciphersuite
peers or NAS devices using port identifiers. Proper identification to attack.
of the parties is critical to the Secure Association phase, since
without this the parties engaged in the exchange are not identified
and the scope of the transient session keys (TSKs) generated during
the exchange is undefined.
[2] Secure capabilities negotiation. This provides for the secure As a result, where AAA-Key caching is supported, freshness of TSKs
MUST be provided by mechanisms outside of EAP. This is typically
handled within the Secure Association protocol via the exchange of
nonces or counters, which are then mixed with the AAA-Key in order
to generate fresh unicast (phase 2a) and possibly multicast (phase
2b) session keys. By not using the AAA-Key directly to protect
data, the secure Association Protocol protects against compromise
of the AAA-Key.
[2] Entity Naming. A basic feature of a Secure Association Protocol is
the explicit naming of the parties engaged in the exchange.
Explicit identification of the parties is critical, since without
this the parties engaged in the exchange are not identified and the
scope of the transient session keys (TSKs) generated during the
exchange is undefined. As illustrated in Figure 1, both the peer
and NAS may have more than one physical or virtual port, so that
port identifiers are typically inappropriate as a naming mechanism.
[3] Secure capabilities negotiation. This provides for 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. By confirmation of the capabilities discovered during phase 0. By
securely negotiating session parameters, the secure Association securely negotiating session parameters, the secure Association
Protocol protects against spoofing during the discovery phase and Protocol protects against spoofing during the discovery phase and
ensures that the peer and authenticator are in agreement about how ensures that the peer and authenticator are in agreement about how
data is to be secured. data is to be secured.
[3] Generation of fresh transient session keys (TSKs). The Secure [4] Key
Association Protocol typically guarantees the freshness of session activation and deletion. In order for the peer and
keys by exchanging nonces between both parties and then mixing the
nonces with the AAA-Key in order to generate fresh unicast (phase
2a) and multicast (phase 2b) session keys. By not using the AAA-
Key directly to protect data, the secure Association Protocol
protects against compromise of the AAA-Key, and by guaranteeing the
freshness of transient session keys, assures that they are not
reused.
[4] Key activation and deletion. In order for the peer and
authenticator to communicate securely, it is necessary for both authenticator to communicate securely, it is necessary for both
sides to derive the same session keys, and remain in sync with sides to derive the same session keys, and remain in sync with
respect to key state going forward. One of the functions of the respect to key state going forward. One of the functions of the
Secure Association Protocol is to synchronize the activation and Secure Association Protocol is to synchronize the activation and
deletion of keys so as to enable seamless rekey, or recovery from deletion of keys so as to enable seamless rekey, or recovery from
partial or complete loss of key state by the peer or authenticator. partial or complete loss of key state by the peer or authenticator.
[5] Mutual proof of possession of the AAA-Key. This demonstrates that [5] Mutual proof of possession of the AAA-Key. This demonstrates that
both the peer and authenticator have been authenticated and both the peer and authenticator have been authenticated and
authorized by the backend authentication server. Since mutual authorized by the backend authentication server. Since mutual
proof of possession is not the same as mutual authentication, the proof of possession is not the same as mutual authentication, the
peer cannot verify authenticator assertions (including the peer cannot verify authenticator assertions (including the
authenticator identity) as a result of this exchange. authenticator identity) as a result of this exchange.
1.4. EAP Invariants 1.4. EAP Invariants
By utilizing a three phase exchange, the EAP key management framework Certain basic characteristics, known as the "EAP Invariants" hold
guarantees that certain basic characteristics, known as the "EAP true for EAP implementations on all media:
Invariants" hold true for all implementations of EAP. These include:
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
skipping to change at page 12, line 32 skipping to change at page 12, line 34
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 [WLANREQ]. 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 data the EAP conversation, the ciphersuite used for the protection of the
is negotiated within the Secure Association Protocol, out-of-band of data exchanged after EAP authentication has completed is negotiated
EAP. between the peer and authenticator out-of-band of EAP. Since
ciphersuite negotiation is assumed to occur out-of-band, there is no
need for ciphersuite negotiation within EAP. Since ciphersuite
negotiation occurs outside of EAP, EAP methods generate keying
material that is ciphersuite-independent.
The backend authentication server is not a party to this negotiation For example, within PPP, the ciphersuite is negotiated within the
nor is it an intermediary in the data flow between the EAP peer and Encryption Control Protocol (ECP) defined in [RFC1968], after EAP
authenticator. The backend authentication server may not even have authentication is completed. Within [IEEE80211i], the AP
knowledge of the ciphersuites implemented by the peer and ciphersuites are advertised in the Beacon and Probe Responses prior
authenticator, or be aware of the ciphersuite negotiated between to EAP authentication, and are securely verified during a 4-way
them, and therefore does not implement ciphersuite-specific code. handshake exchange after EAP authentication has completed.
Since ciphersuite negotiation occurs in the Secure Association Advantages of ciphersuite-independence include:
protocol, not in EAP, ciphersuite-specific key generation, if
implemented within an EAP method, would potentially conflict with the
transient session key derivation occurring in the Secure Association
protocol. As a result, EAP methods generate keying material that is
ciphersuite-independent. Additional advantages of ciphersuite-
independence include:
Update requirements Reduced update requirements
If EAP methods were to specify how to derive transient session keys If EAP methods were to specify how to derive transient session keys
for each ciphersuite, they would need to be updated each time a new for each ciphersuite, they would need to be updated each time a new
ciphersuite is developed. In addition, backend authentication ciphersuite is developed. In addition, backend authentication
servers might not be usable with all EAP-capable authenticators, servers might not be usable with all EAP-capable authenticators,
since the backend authentication server would also need to be since the backend authentication server would also need to be
updated each time support for a new ciphersuite is added to the updated each time support for a new ciphersuite is added to the
authenticator. authenticator.
EAP method complexity Reduced EAP method complexity
Requiring each EAP method to include ciphersuite-specific code for Requiring each EAP method to include ciphersuite-specific code for
transient session key derivation would increase method complexity transient session key derivation would increase method complexity
and result in duplicated effort. and result in duplicated effort.
Knowledge of capabilities Simplified configuration
In practice, an EAP method may not have knowledge of the The ciphersuite is negotiated between the peer and authenticator
ciphersuite that has been negotiated between the peer and out-of-band of EAP. The backend authentication server is neither a
authenticator, since this negotiation typically occurs within the party to this negotiation, nor is it an intermediary in the data
Secure Association Protocol. flow between the EAP peer and authenticator. The backend
authentication server may not have knowledge of the ciphersuites
For example, PPP ciphersuite negotiation occurs in the Encryption and negotiation policies implemented by the peer and authenticator,
Control Protocol (ECP) [RFC1968]. Since ECP negotiation occurs or be aware of the ciphersuite negotiated between them. This
after authentication, unless an EAP method is utilized that simplifies the configuration of the backend authentication server.
supports ciphersuite negotiation, the peer, authenticator and
backend authentication server may not be able to anticipate the
negotiated ciphersuite and therefore this information cannot be
provided to the EAP method. Since ciphersuite negotiation is
assumed to occur out-of-band, there is no need for ciphersuite
negotiation within EAP.
For example, a peer might be pre-configured with policy indicating For example, since ECP negotiation occurs after authentication,
the ciphersuite to be used in communicating with a given when run over PPP, the EAP peer, authenticator and backend
authenticator. Within PPP, the ciphersuite is negotiated within authentication server may not anticipate the negotiated ciphersuite
the Encryption Control Protocol (ECP), after EAP authentication is and therefore this information cannot be provided to the EAP
completed. Within [IEEE80211i], the AP ciphersuites are advertised method.
in the Beacon and Probe Responses, and are securely verified during
a 4-way handshake exchange after EAP authentication has completed.
2. EAP Key Hierarchy 2. EAP Key Hierarchy
2.1. Key Terminology 2.1. Key Terminology
The EAP Key Hierarchy makes use of the following types of keys: The EAP Key Hierarchy makes use of the following types of keys:
Long Term Credential Long Term Credential
EAP methods frequently make use of long term secrets in order to EAP methods frequently make use of long term secrets in order to
enable authentication between the peer and server. In the case of enable authentication between the peer and server. In the case of
a method based on pre-shared key authentication, the long term a method based on pre-shared key authentication, the long term
credential is the pre-shared key. In the case of a public-key credential is the pre-shared key. In the case of a public-key
based method, the long term credential is the corresponding private based method, the long term credential is the corresponding private
key. key.
Master Session Key (MSK) Master Session Key (MSK)
Keying material that is derived between the EAP peer and server and Keying material that is derived between the EAP peer and server and
exported by the EAP method. The MSK is at least 64 octets in exported by the EAP method. The MSK is at least 64 octets in
length. length.
INTERNET-DRAFT EAP
Key Management Framework 14 November 2004
Extended Master Session Key (EMSK) Extended Master Session Key (EMSK)
Additional keying material derived between the peer and server that Additional keying material derived between the peer and server that
is exported by the EAP method. The EMSK is at least 64 octets in is exported by the EAP method. The EMSK is at least 64 octets in
length, and is never shared with a third party. length, and is never shared with a third party.
AAA-Key AAA-Key
A key derived by the peer and EAP server, used by the peer and A key derived by the peer and EAP server, used by the peer and
authenticator in the derivation of Transient Session Keys (TSKs). authenticator in the derivation of Transient Session Keys (TSKs).
Where a backend authentication server is present, the AAA-Key is Where a backend authentication server is present, the AAA-Key is
transported from the backend authentication server to the transported from the backend authentication server to the
authenticator, wrapped within the AAA-Token; it is therefore known authenticator, 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 Appendix E; in existing implementations the MSK is discussed in Section 2.5; in existing implementations the MSK is
used as the AAA-Key. used as the AAA-Key.
Application-specific Master Session Keys (AMSKs) Application-specific Master Session Keys (AMSKs)
Keys derived from the EMSK which are cryptographically separate Keys derived from the EMSK which are cryptographically separate
from each other and may be subsequently used in the derivation of from each other and may be subsequently used in the derivation of
Transient Session Keys (TSKs) for extended uses. AMSK derivation Transient Session Keys (TSKs) for extended uses. AMSK derivation
is discussed in Appendix F. is discussed in Section 2.6.
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].
skipping to change at page 15, line 28 skipping to change at page 15, line 20
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
protected channel between the EAP peer and server during EAP protected channel between the EAP peer and server during EAP
authentication is unrelated to the ciphersuite used to subsequently authentication is unrelated to the ciphersuite used to subsequently
protect data sent between the EAP peer and authenticator. An protect data sent between the EAP peer and authenticator. An
example TEK key hierarchy is described in Appendix C. example TEK key hierarchy is described in Appendix C.
Transient Session Keys (TSKs) Transient Session Keys (TSKs)
Session keys used to protect data which are appropriate for the Session keys used to protect data exchanged between the peer and
ciphersuite negotiated between the EAP peer and authenticator. The the authenticator after the EAP authentication has successfully
TSKs are derived from AAA-Key during the Secure Association completed. TSKs are appropriate for the lower layer ciphersuite
Protocol. In the case of [IEEE80211i] the Secure Association negotiated between the EAP peer and authenticator. Examples of TSK
Protocol consists of the 4-way handshake and group key derivation. derivation are provided in Appendix D.
An example TSK derivation is provided in Appendix D.
2.2. Key Hierarchy 2.2. Key Hierarchy
The EAP Key Hierarchy, illustrated in Figure 3, has at the root the The EAP Key Hierarchy, illustrated in Figure 3, has at the root the
long term credential utilized by the selected EAP method. If long term credential utilized by the selected EAP method. If
authentication is based on a pre-shared key, the parties store the authentication is based on a pre-shared key, the parties store the
EAP method to be used and the pre-shared key. The EAP server also EAP method to be used and the pre-shared key. The EAP server also
stores the peer's identity and/or other information necessary to stores the peer's identity and/or other information necessary to
decide whether access to some service should be granted. The peer decide whether access to some service should be granted. The peer
stores information necessary to choose which secret to use for which stores information necessary to choose which secret to use for which
skipping to change at page 16, line 6 skipping to change at page 15, line 46
If authentication is based on proof of possession of the private key If authentication is based on proof of possession of the private key
corresponding to the public key contained within a certificate, the corresponding to the public key contained within a certificate, the
parties store the EAP method to be used and the trust anchors used to parties store the EAP method to be used and the trust anchors used to
validate the certificates. The EAP server also stores the peer's validate the certificates. The EAP server also stores the peer's
identity and/or other information necessary to decide whether access identity and/or other information necessary to decide whether access
to some service should be granted. The peer stores information to some service should be granted. The peer stores information
necessary to choose which certificate to use for which service. necessary to choose which certificate to use for which service.
Based on the long term credential established between the peer and Based on the long term credential established between the peer and
the server, EAP derives four 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
be derived:
[3] Keys calculated from exported quantities: AAA-Key, AMSKs. [3] Keys calculated from exported quantities: AAA-Key, AMSKs.
[4] Keys calculated by the Secure Association Protocol: TSKs. [4] Keys calculated by the Secure Association Protocol from the
AAA-Key or AMSKs: 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. however, the use of the IV is deprecated.
On both the peer and EAP server, the exported MSK and EMSK are On both the peer and EAP server, the exported MSK and keys derived
utilized in order to calculate the AAA-Key, as described in Appendix from the AMSK are utilized in order to calculate the AAA-Key, as
E. described in Section 2.5.
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 within the AAA-Token, 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.
skipping to change at page 17, line 29 skipping to change at page 17, line 27
sends an Access-Accept to the authenticator, providing the AAA-Key sends an Access-Accept to the authenticator, providing the AAA-Key
within a protected package known as the AAA-Token. within a protected package known as the AAA-Token.
The AAA-Key is then used by the peer and authenticator within the The AAA-Key is then used by the peer and authenticator within the
Secure Association Protocol to derive Transient Session Keys (TSKs) Secure Association Protocol to derive Transient Session Keys (TSKs)
required for the negotiated ciphersuite. The TSKs are known only to required for the negotiated ciphersuite. The TSKs are known only to
the peer and authenticator. the peer and authenticator.
2.3. Key Lifetimes 2.3. Key Lifetimes
As noted earlier, the EAP Key Management framework includes several Key lifetime issues are discussed in the sections that follow.
types of keys. Key lifetime issues associated with each type of key Issues include:
are discussed in the sections that follow. Challenges include:
[a] Security. Where key lifetimes cannot be assumed, it may be [a] Key lifetime negotiation. Where key lifetimes cannot be assumed,
necessary to negotiate them. While key lifetimes may be announced it may be necessary to negotiate them. Where negotiation is
or negotiated in the clear, a protected lifetime negotiation is supported, it is RECOMMENDED that the negotiation be secured. Note
RECOMMENDED. that key lifetime negotiation may not always be required. A
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
when necessary.
[b] Resource reclamation. While key lifetimes may be securely [b] Key resynchronization. It is possible for the peer or
negotiated, it is possible for the NAS or peer to reboot or reclaim authenticator to reboot or reclaim resources, clearing portions or
resources, and therefore not be able to cache keys for their full all of the key cache. Therefore, key lifetime negotiation cannot
lifetime. As a result, lifetime negotiation does not guarantee guarantee that the key cache will remain synchronized, and the peer
that the key cache will remain synchronized. It is therefore may not be able to determine before attempting to use it whether a
RECOMMENDED for the lower layer to provide a mechanism for key particular key exists within the authenticator cache. It is
state resynchronization. Note that securing this mechanism may be therefore RECOMMENDED for the lower layer to provide a mechanism
difficult since in this situation one or more of the parties for key state resynchronization. Since in this situation one or
initially do not possess a key with which to protect the more of the parties initially do not possess a key with which to
resynchronization exchange. protect the resynchronization exchange, securing this mechanism may
be difficult.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | ^ | | ^
| EAP Method | | | EAP Method | |
| | | | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | |
| | | | | | | | | | | | | |
| | EAP Method Key |<->| Long-Term | | | | | EAP Method Key |<->| Long-Term | | |
| | Derivation | | Credential | | | | | Derivation | | Credential | | |
| | | | | | | | | | | | | |
skipping to change at page 18, line 40 skipping to change at page 18, line 40
| | | | | | | |
| MSK (64B) | EMSK (64B) | IV (64B) | | MSK (64B) | EMSK (64B) | IV (64B) |
| | | Exported| | | | Exported|
| | | by | | | | by |
V V V EAP | V V V EAP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ Method| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ Method|
| AAA Key Derivation, | | Known | | | AAA Key Derivation, | | Known | |
| Naming & Binding | |(Not Secret) | | | Naming & Binding | |(Not Secret) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ V +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ V
| ---+ | ---+
| Transported | | AAA-Key/ Transported |
| AAA-Key by AAA | | Name by AAA |
| Protocol | | Protocol |
V V V V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | ^ | | ^
| TSK | Ciphersuite | | TSK Derivation | Lower layer |
| Derivation | Specific | | [AAA-Key Cache] | Specific |
| | V | | V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
Figure 3: EAP Key Hierarchy Figure 3: EAP Key Hierarchy
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
| | | | | | | |
| | | | | | | |
| Cipher- | | Cipher- | | Cipher- | | Cipher- |
| Suite | | Suite | | Suite | | Suite |
| | | | | | | |
skipping to change at page 19, line 29 skipping to change at page 19, 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 | | AAA-Key/| | AAA-Key/|
| Name | | Name |
| (TSKs) | | (TSKs) | | (TSKs) | | (TSKs) |
| | | |
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
^ ^ ^ ^
| | | |
| MSK, EMSK | MSK, EMSK | MSK, EMSK | MSK, EMSK
| | | |
| | |
|
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
| | | | | | | |
| EAP | | EAP | | EAP | | EAP |
| Method | | Method | | Method | | Method |
| | | | | | | |
| (TEKs) | | (TEKs) | | (TEKs) | | (TEKs) |
| | | | | | | |
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
Figure 4: Relationship between EAP peer and authenticator Figure 4: Relationship between EAP peer and authenticator
skipping to change at page 20, line 21 skipping to change at page 20, line 21
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
^ ^ ^ ^
| | | |
| | | |
| | | |
V V V V
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
| |===============| |========| | | |===============| |========| |
| |EAP, TEK Deriv.| | | | | |EAP, TEK Deriv.| | | |
| |<-------------------------------->| backend | | |<-------------------------------->| backend |
| | | | | | | | | |AAA-Key/| |
| | Secure Assoc. | | AAA-Key| | | | 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 | | | | | |MSK,EMSK | | | | |
| AAA-Key | | AAA-Key | |MSK,EMSK,| | AAA-Key/| | AAA-Key/| |MSK,EMSK,|
| (TSKs) | | (TSKs) | | AAA-Key | | Name | | Name | | AAA-Key/|
| | | | | | | (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, Figure 5: Pass-through relationship between EAP peer,
authenticator and backend authentication server. authenticator and backend authentication server.
2.3.1. Local Key Lifetimes 2.3.1. Parent-child relationships
The Transient EAP Keys (TEKs) are session keys used to protect the When keying material exported by EAP methods expires, all keying
EAP conversation. The TEKs are internal to the EAP method and are material derived from the exported keying material, (including the
not exported. They remain valid only for the duration of the EAP AAA-Key, AMSKs and TSKs) also expires.
conversation, and are lost once the EAP conversation completes.
EAP methods may also implement a cache for other local keying Similarly, when an EAP reauthentication takes place, new keying
material which may persist for multiple EAP conversations. For material is derived and exported by the EAP method, which eventually
example, EAP methods based on TLS (such as EAP-TLS [RFC2716]) derive results in replacement of calculated keys, including the AAA-Key,
and cache the TLS Master Secret, typically for substantial time AMSKs, and TSKs.
periods. The lifetime of other local keying material calculated
within the EAP method is defined by the method.
2.3.2. Exported Key Lifetimes As a result, the lifetime of keys calculated from the exported keying
material can be no longer than the lifetime of the exported keying
material itself. However, the lifetime of calculated keys can be
less than that of the exported keys. For example, TSK rekey may
occur prior to EAP reauthentication.
All EAP methods generating keys are required to generate the MSK and Note that deletion of the AAA-Key does not necessarily imply deletion
EMSK, and may optionally generate the IV. However, although new of the corresponding TSKs. Replacement or deletion of TSKs only
exported keys are generated during re-authentication, the lifetime of implies replacement of the AAA-Key when the TSKs are taken from a
exported keys is conceptually distinct from the re-authentication portion of the AAA-Key.
time, since while re-authentication causes new exported keys to be
derived, exported keys may be cached on the peer and server after a
session completes and therefore their lifetime may be greater than
the re-authentication time.
Although exported keys are generated by the EAP method, most existing Failure to mutually prove possession of the AAA-Key during the Secure
EAP methods do not negotiate the lifetime of the exported keys. EAP, Association Protocol exchange need not be grounds for deletion of the
defined in [RFC3748], also does not support the negotiation of AAA-Key by both parties; rate-limiting Secure Association Protocol
lifetimes for exported keying material such as the MSK, EMSK and IV. exchanges could be used to prevent a brute force attack.
Several mechanisms exist for managing the lifetime of exported EAP 2.3.2. Local Key Lifetimes
keys. Exported EAP keys may be cached on the EAP server as well as
on the peer. On the EAP server, it is RECOMMENDED that the lifetime
of exported keys be managed as a system parameter. Where the EAP
method does not support the negotiation of the exported key lifetime,
and where a negotiation mechanism is not provided by the lower lower,
it is RECOMMENDED that the peer assume a default value of the
exported key lifetime. A value of 8 hours is suggested.
Attempting to manage the lifetime of the EAP-Key SA using AAA The Transient EAP Keys (TEKs) are session keys used to protect the
attributes is NOT RECOMMENDED, since this requires the authenticator EAP conversation. The TEKs are internal to the EAP method and are
to maintain EAP-Key SA state. As described in Section 3, EAP-Key SA not exported. TEKs are typically created during an EAP conversation,
state is typically only maintained on the peer and server, so used until the end of the conversation and then discarded. However,
requiring EAP-Key SA state to be maintained on the authenticator methods may rekey TEKs during a conversation.
represents an unnecessary additional burden.
2.3.3. Calculated Key Lifetimes When using TEKs within an EAP conversation or across conversations,
it is necessary to ensure that replay protection and key separation
requirements are fulfilled. For instance, if a replay counter is
used, TEK rekey MUST occur prior to wrapping of the counter.
Similarly, TSKs MUST remain cryptographically separate from TEKs
despite TEK rekeying or caching. This prevents TEK compromise from
leading directly to compromise of the TSKs and vice versa.
When keying material exported by EAP methods is replaced, new EAP methods may cache local keying material which may persist for
calculated keys are also put in place. Similarly, when the keying multiple EAP conversations when fast reconnect is used [RFC 3748].
material exported by EAP methods expires, so do the calculated keys. For example, EAP methods based on TLS (such as EAP-TLS [RFC2716])
As a result, the lifetime of keys calculated from key material derive and cache the TLS Master Secret, typically for substantial
exported by EAP methods can be no larger than the lifetime of the time periods. The lifetime of other local keying material calculated
exported keying material. within the EAP method is defined by the method. Note that in
general, when using fast reconnect, there is no guarantee to that the
original long-term credentials are still in the possession of the
peer. For instance, a card hold holding the private key for EAP-TLS
may have been removed. EAP servers should verify that the long-term
credentials are still valid, such as by checking that certificate
used in the original authentication has not yet expired.
However, since the lifetime of calculated keys can be less than that 2.3.3. Exported and Calculated Key Lifetimes
of the exported keys they are derived from, calculated key lifetimes
are conceptually distinct from exported key lifetimes and re-
authentication times, and need to be managed as a separate parameter.
Note that just as the re-authentication time and the exported key All EAP methods generating keys are required to generate the MSK and
lifetime are conceptually distinct parameters, so too are calculated EMSK, and may optionally generate the IV. Existing EAP methods do
key lifetimes conceptually distinct from the re-authentication time. not negotiate the lifetime of the exported keys. EAP, defined in
[RFC3748], also does not support the negotiation of lifetimes for
exported keying material such as the MSK, EMSK and IV.
AAA protocols such as RADIUS [RFC2865] support the Session-Timeout Several mechanisms exist for managing key lifetimes:
attribute. As described in [RFC3580], this may be used to determine
the maximum session time prior to re-authentication. Since re-
authentication results in the derivation of new exported keys and the
transport of a new AAA-Key, while a session is in progress the
maximum session time prior to re-authentication places an upper bound
on the AAA-Key lifetime.
However, after the session has terminated, it is possible for the [a] AAA attributes. AAA protocols such as RADIUS [RFC2865] and
AAA-Key to be cached on the authenticator. Therefore the AAA-Key Diameter [DiamEAP] support the Session-Timeout attribute. The
lifetime may be larger than the re-authentication time. As a result, Session-Timeout value represents the maximum lifetime of the
the AAA-Key lifetime needs to be managed as a separate parameter. exported keys, and all keys calculated from it, in all
circumstances. The AAA server MUST expire the exported keys, and
all keys calculated from them, prior to the future time indicated
by Session-Timeout. On the authenticator, where EAP is used for
authentication, the Session-Timeout value represents the maximum
session time prior to re-authentication, as described in [RFC3580].
Where EAP is used for pre-authentication, the session may not start
until some future time, or may never occur. Nevertheless, the
Session-Timeout value represents the time after which the AAA-Key,
and all keys calculated from it, will have expired on the
authenticator. If the session subsequently starts, re-
authentication will be initiated once the Session-Time has expired.
If the session never started, or started and ended, the AAA-Key and
all keys calculated from it will be expired by
the authenticator
prior to the future time indicated by Session-Timeout.
Since the lifetime of the AAA-Key within the authenticator key cache Since the TSK lifetime is often determined by authenticator
is in part determined by authenticator resources, the AAA-Key resources, the AAA server has no insight into the TSK derivation
lifetime is often managed as a system parameter on the authenticator. process, and by the principle of ciphersuite independence, it is
Since the authenticator may have fewer resources than either the EAP not appropriate for the AAA server to manage any aspect of the TSK
peer or server, it is possible that AAA-Key lifetime on the derivation process, including the TSK lifetime.
authenticator may be less than exported key lifetime maintained by
the server, or that the authenticator may need to reclaim AAA-Key
resources prior to expiration of the AAA-Key lifetime. As a result,
knowledge of the AAA-Key lifetime may not be sufficient for the peer
to determine whether a particular AAA-Key exists within the key cache
of a given authenticator.
Issues arise when attempting to manage synchronization of calculated [b] Lower layer mechanisms. While AAA attributes can communicate the
key lifetimes between the AAA server and the authenticator using AAA maximum exported key lifetime, this only serves to synchronize the
attributes. key lifetime between the backend authentication server and the
authenticator. Lower layer mechanisms can then be used to enable
the lifetime of exported and calculated keys to be negotiated
between the peer and authenticator.
Failure to mutually prove possession of the AAA-Key during the Secure Where TSKs are established as the result of a Secure Association
Association Protocol exchange need not be grounds for deletion of the Protocol exchange, it is RECOMMENDED that the Secure Association
AAA-Key by both parties; rate-limiting Secure Association Protocol Protocol include secure negotiation of the TSK lifetime between the
exchanges could be used to prevent a brute force attack. peer and authenticator. Where 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-Key lifetime are
identical.
One problem is that the AAA protocol cannot guarantee synchronization [c] System defaults. Where the EAP method does not support the
of the peer and authenticator with respect to calculated key negotiation of the exported key lifetime, and a negotiation
lifetimes. While this synchronization could be provided by the mechanism is not provided by the lower lower, there may be no way
Secure Association Protocol, in situations in which this protocol is for the peer to learn knowledge of the exported key liftime. In
not run immediately after EAP authentication, the calculated key this case it is RECOMMENDED that the peer assume a default value of
lifetime will be undefined during the hiatus between the two the exported key lifetime; 8 hours is suggested. Similarly, the
protocols. This can lead to problems with respect to key cache lifetime of calculated keys can also be managed as a system
management. parameter on the authenticator.
For example, where the AAA-key lifetime is negotiated between the 2.3.4. Key cache synchronization
authenticator and the peer within the Secure Association Protocol,
this may be used by the peer to manage the lifetime of the AAA-Key
once the Secure Association Protocol has completed. However, where
EAP pre-authentication is used, a hiatus may exist between the
completion of the EAP method and the initiation of the Secure
Association Protocol, during which peer cannot determine the lifetime
of the AAA-Key.
As a result, unless the AAA-Key lifetime is negotiated within the EAP Issues arise when attempting to synchronize the key cache on the peer
method or the lower layer, the peer will not be able to determine a and authenticator. Lifetime negotiation alone cannot guarantee key
session-specific AAA-Key lifetime until it attempts to negotiate the cache synchronization.
Secure Association Protocol, which could fail due to AAA-Key lifetime
expiration.
One solution is to simplify management of the AAA-Key lifetime by One problem is that the AAA protocol cannot guarantee synchronization
treating it as a system parameter of the peer, authenticator and of key lifetimes between the peer and authenticator. Where the
server. This enables a wider range of solutions. For example, the Secure Association Protocol is not run immediately after EAP
lower layer may utilize Discovery mechanisms to ensure AAA-Key cache authentication, the exported and calculated key lifetimes will not be
synchronization between the peer and authenticator. known by the peer during the hiatus. Where EAP pre-authentication
occurs, this can leave the peer uncertain whether a subsequent
attempt to use the exported keys will prove successful.
If the authenticator manages the AAA-Key cache by deleting the oldest However, even where the Secure Association Protocol is run
AAA-Key first (LIFO), the relative creation time of the last AAA-Key immediately after EAP, it is still possible for the authenticator to
to be deleted could be advertised with the Discovery phase, enabling reclaim resources if the created key state is not immediately
the peer to determine whether a given AAA-Key had been expired from utilized.
the authenticator key cache.
2.3.4. TSK Key Lifetimes The lower layer may utilize Discovery mechanisms to assist in this.
For example, the authenticator manages the AAA-Key cache by deleting
the oldest AAA-Key first (LIFO), the relative creation time of the
last AAA-Key to be deleted could be advertised with the Discovery
phase, enabling the peer to determine whether a given AAA-Key had
been expired from the authenticator key cache prematurely.
Since the TSKs depend on the AAA-Key, replacement of the AAA-Key 2.4. Key Names and Scopes
typically results in replacement of the TSKs. However, deletion of
the AAA-Key does not necessarily imply deletion of the corresponding
TSKs. Replacement or deletion of TSKs only implies replacement of
the AAA-Key when the TSKs are taken from a portion of the AAA-Key.
While the lifetime of the TSKs may be shorter than or equal to the Each key created within the EAP key management framework has a name
AAA-Key lifetime, the TSK lifetime cannot exceed the AAA-Key (the identifier by which the key can be identified), as well as a
lifetime. Where a Secure Association Protocol exists, it is possible scope (the parties to whom the key is available). This section
for TSKs to be refreshed prior to re-authentication, and so the TSK describes how keys are named, and the scope within which that name
Key Lifetime may also be shorter than or equal to the re- applies.
authentication timeout. It is RECOMMENDED that the TSK Key lifetime
be managed as a parameter distinct from the re-authentication timeout
and the AAA-Key lifetime (except where the TSK is taken from the AAA-
Key).
Where TSKs are established as the result of a Secure Association Session-Id
Protocol exchange, it is RECOMMENDED that the Secure Association
Protocol include secure negotiation of the TSK lifetime between the
peer and authenticator. Where 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-Key lifetime are identical.
As described in Section 3, TSKs are part of Service SAs which reside EAP methods supporting key naming MUST specify a temporally unique
on the peer and authenticator and as with the AAA-Key lifetime, the method identifier known as the EAP Method-Id, which is typically
TSK lifetime is often determined by authenticator resources. As a constructed from nonces or counters used within the exchange. Since
result, the AAA server has no insight into the TSK derivation multiple EAP sessions may exist between an EAP peer and EAP server,
process, and by the principle of ciphersuite independence, it is not the Method-Id allows MSKs to be differentiated.
appropriate for the AAA server to manage any aspect of the TSK
derivation process, including the TSK lifetime.
2.4. Key Naming The combination of the EAP Type and the Method-Id is known as the EAP
Session-Id. The inclusion of the Type in the EAP Session-Id ensures
that each EAP method has a distinct name space.
MSK Name The EAP Session-Id uniquely identifies the EAP session to the EAP
peer and server terminating the EAP conversation. However, suitable
EAP peer and server names may not always be available. As described
in [RFC3748] Section 7.3, the identity provided in the EAP-
Response/Identity, may be different from the identity authenticated
by the EAP method, and as a result the EAP-Response/Identity is
unsuitable for determination of the peer identity. As a result, the
Session-Id scope is defined by the EAP peer name (if securely
exchanged within the method) concatenated with the EAP server name
(also only if securely exchanged). Where a peer or server name is
missing the null string is used. Since an EAP session is not bound
to a particular authentication or specific ports on the peer and
authenticator, the authenticator port or identity are not included in
the Session-Id scope.
This key is created between the EAP peer and EAP server, and is The EAP Session-Id is exported by the EAP method along with the
uniquely named by the concatenation of the string "MSK", EAP Session-Id scope, if available, and is used to construct names for
Method Type, EAP peer name, EAP server name, EAP peer nonce, and other EAP keys. Note that the EAP Session-Id and scope are only
the EAP server nonce. Here the EAP peer name and EAP server name known by the EAP method. As a result, the format of the EAP Session-
are the identifiers securely exchanged within the EAP method. Id and the definition of the Session-Id scope needs to be specified
Since multiple MSKs may exist between an EAP peer and EAP server, within the method. Appendix E defines the EAP Session-Id and scope
the EAP peer nonce and EAP server nonce allow MSKs to be provided by existing methods.
differentiated; at least one of these nonces is necessary. The
inclusion of the Method Type in the name ensures that each EAP
method has a distinct name space.
Note that the components of the MSK Name are only known by the EAP MSK Name
method. As a result, the MSK Name is exported from the method, and
no detailed format of the MSK Name can be specified without a This key is created between the EAP peer and EAP server, and can be
reference to a particular method. referred to using the string "MSK" and the EAP Session-Id. As with
the EAP Session-Id, the MSK scope is defined by the EAP peer name (if
securely exchanged within the method) and the EAP server name (also
only if securely exchanged). Where a peer or server name is missing
the null string is used.
EMSK Name EMSK Name
The EMSK is named similarly to the above. Its name is the The EMSK can be referred to using the string "EMSK" and the EAP
concatenation of the string "EMSK", the EAP Method Type, EAP peer Session-Id.
name, EAP server name, EAP peer nonce, and the EAP server nonce.
Note that neither the MSK nor EMSK names include the authenticator As with the EAP Session-Id, the EMSK scope is defined by the EAP peer
identity or the peer or authenticator port over which the EAP name (if securely exchanged within the method) and the EAP server
conversation took place. This is because the MSK and EMSK are not name (also only if securely exchanged). Where a peer or server name
bound to an authenticator, or to specific ports on the peer or is missing the null string is used.
authenticator.
AMSK Name AMSK Name
AMSKs, if any, may be named by the concatenation of the string AMSKs, if any, can be referred to using the string "AMSK", the key
"AMSK", key label, application data (see Appendix F), and EMSK label, application data (see Section 2.6) and the EAP Session-Id.
Name.
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 named by the concatenation of the string "AAA-Key", The AAA-Key is derived from either the MSK or AMSK and so can be
the authenticator name (since the AAA-Key is bound to a particular referred to using the MSK or AMSK names.
authenticator), and the name of the key from which the AAA-Key is
derived (MSK or AMSK Name). For the purpose of identifying the
authenticator, the contents of the NAS-Identifier attribute is
recommended. In order to ensure that all parties can agree on the
authenticator name this requires the authenticator to advertise
its name (typically using a lower layer mechanism, such as the
802.11 Beacon/Probe Response).
Note that the AAA-Key name does not include the peer or The AAA-Key scope is provided by the concatenation of the EAP peer
authenticator port over which the EAP conversation took place. name (if securely provided to the authenticator), and the
This is because the AAA-Key is not bound to a specific peer or authenticator name (if securely provided to the peer).
authenticator port.
For the purpose of identifying the authenticator to the peer, the
value of the NAS-Identifier attribute is recommended. The
authenticator may include the NAS-Identifier attribute to the AAA
server in an Access-Request, and the authenticator may provide the
NAS-Identifier (unsecured) to the EAP peer in the EAP-
Request/Identity or via a lower layer mechanism (such as the 802.11
Beacon/Probe Response). Where the NAS-Identifier is provided by the
authenticator to the peer a secure mechanism is RECOMMENDED.
For the purpose of identifying the peer to the authenticator, the EAP
peer identifier provided within the EAP method is recommended. It
cannot be assumed that the authenticator is aware of the EAP peer
name used within
the method. Therefore alternatives mechanisms need
to be used to provide the EAP peer name to the authenticator. For
example, the AAA server may include the EAP peer name in the User-
Name attribute of the Access-Accept or the peer may provide the
authenticator with its name via a lower layer mechanism.
Absent an explicit binding step within the Secure Association
Protocol, the AAA-Key is not bound to a specific peer or
authenticator port. As a result, the peer or authenticator port over
which the EAP conversation takes place is not included in the AAA-Key
scope.
PMK Name PMK Name
The PMK has no name of its own, and is only identified by the AAA- This document does not specify a naming scheme for the PMK. The PMK
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.
Note: IEEE 802.11i names the PMKID for the purposes of being able to
refer to it in the Secure Association protocol; this naming is based
on a hash of the PMK itself as well as some other parameters (see
Section 8.5.1.2 [IEEE80211i]).
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. EAP method. Since the TEKs are only known by the EAP peer and
server, the TEK scope is the same as the Session-Id scope.
TSKs TSKs
The TSKs are typically named. Their naming is specified in the The TSKs are typically named. Their naming is specified in the Secure
Secure Association (phase 2) protocol, so that the correct set of Association (phase 2) protocol, so that the correct set of transient
transient session keys can be identified for processing a given session keys can be identified for processing a given packet. The
packet. Explicit creation and deletion operations are also scope of the TSKs is negotiated within the Secure Association
typically supported so that establishment and re-establishment of Protocol.
transient session keys can be synchronized between the parties.
TSK creation and deletion operations are typically supported so that
establishment and re-establishment of TSKs can be synchronized
between the parties.
In order to avoid confusion in the case where an EAP peer has more In order to avoid confusion in the case where an EAP peer has more
than one AAA-Key (phase 1b) applicable to establishment of a phase than one AAA-Key (phase 1b) applicable to establishment of a phase 2
2 security association, the secure Association protocol needs to security association, the secure Association protocol needs to
name the AAA-Key so that the appropriate phase 1b keying material utilize the AAA-Key name so that the appropriate phase 1b keying
can be identified for use in the Secure Association Protocol material can be identified for use in the Secure Association Protocol
exchange. exchange.
2.5. AAA-Key Derivation
Where a AAA-Key is generated as the result of a successful EAP
authentication with the authenticator A, the AAA-Key is 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.6:
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.6
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.6. 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 7 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.7. Key Scope Issues
As described in Section 2.5, the AAA-Key is calculated from the EMSK
and MSK by the EAP peer and server, and is used as the root of the
ciphersuite-specific key hierarchy. Where a backend authentication
server is present, the AAA-Key is transported from the EAP server to
the authenticator; where it is not present, the AAA-Key is calculated
on the authenticator.
Regardless of how many sessions are initiated using it, the AAA-Key
scope is between the EAP peer that calculates it, and the
authenticator
that either calculates it (where no backend
authenticator is present) or receives it from the server (where a
backend authenticator server is present).
It should be understood that an authenticator or peer:
[a] may contain multiple physical ports;
[b] may advertise itself as multiple "virtual" authenticators
or peers;
[c] may utilize multiple CPUs;
[d] may support clustering services for load balancing or failover.
As illustrated in Figure 1, an EAP peer with multiple ports may be
attached to one or more authenticators, each with multiple ports.
Where the peer and authenticator identify themselves using a port
identifier such as a link layer address, it may not be obvious to the
peer which authenticator ports are associated with which
authenticators. Similarly, it may not be obvious to the
authenticator which peer ports are associated with which peers. As a
result, the peer and authenticator may not be able to determine the
scope of the AAA-Key.
When a single physical authenticator advertises itself as multiple
"virtual authenticators", the EAP peer and authenticator also may not
be able to agree on the scope of the AAA-Key, creating a security
vulnerability. For example, the peer may assume that the "virtual
authenticators" are distinct and do not share a key cache, whereas,
depending on the architecture of the physical AP, a shared key cache
may or may not be implemented.
Where the AAA-Key is shared between "virtual authenticators" an
attacker acting as a peer could authenticate with the "Guest"
"virtual authenticator" and derive a AAA-Key. If the virtual
authenticators share a key cache, then the peer can utilize the AAA-
Key derived for the "Guest" network to obtain access to the
"Corporate Intranet" virtual authenticator.
Several measures are recommended to address these issues:
[a] Authenticators are REQUIRED to cache associated authorizations
along with the AAA-Key and apply authorizations consistently. This
ensures that an attacker cannot obtain elevated privileges even
where the AAA-Key cache is shared between "virtual authenticators".
[b] It is RECOMMENDED that physical authenticators maintain separate
AAA-Key caches for each "virtual authenticator".
[c] It is RECOMMENDED that each "virtual authenticator" identify itself
distinctly to the AAA server, such as by utilizing a distinct NAS-
identifier attribute. This enables the AAA server to utilize a
separate credential to authenticate each "virtual authenticator".
[d] It is RECOMMENDED that Secure Association Protocols identify peers
and authenticators unambiguously, without incorporating implicit
assumptions about peer and authenticator architectures. Using
port-specific MAC addresses as identifiers is NOT RECOMMENDED where
peers and authenticators may support multiple ports.
[e] The AAA server and authenticator MAY implement additional
attributes in order to further restrict the AAA-Key scope. For
example, in 802.11, the AAA server may provide the authenticator
with a list of authorized Called or Calling-Station-Ids and/or
SSIDs for which the AAA-Key is valid.
[f] Where the AAA server provides attributes restricting the key scope,
it is RECOMMENDED that restrictions be securely communicated by the
authenticator to the peer. This is typically accomplished using
the Secure Association Protocol, but also can be accomplished via
the EAP method or the lower layer.
3. Security Associations 3. Security Associations
During EAP authentication and subsequent exchanges, four types of During EAP authentication and subsequent exchanges, four types of
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 resume" 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, but proposals such as [IEEE-03-084] and
[I-D.irtf-aaaarch-handoff] use this SA for purposes such as pre- [I-D.irtf-aaaarch-handoff] use this SA for purposes such as pre-
emptive key distribution. emptive key distribution.
skipping to change at page 26, line 46 skipping to change at page 31, line 36
[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).
3.1. EAP Method SA (peer - EAP server) 3.1. EAP Method SA (peer - EAP server)
An EAP method may store some state on the peer and EAP server even An EAP method may store some state on the peer and EAP server even
after phase 1a has completed. after phase 1a has completed.
Typically, this is used for "fast resume": the peer and EAP server Typically, this is used for "fast reconnect": the peer and EAP server
can confirm that they are still talking to the same party, perhaps can confirm that they are still talking to the same party, perhaps
using fewer round-trips or less computational power. In this case, using fewer round-trips or less computational power. In this case,
the EAP method SA is essentially a cache for performance the EAP method SA is essentially a cache for performance
optimization, and either party may remove the SA from its cache at optimization, and either party may remove the SA from its cache at
any point. any point.
An EAP method may also keep state in order to support pseudonym-based An EAP method may also keep state in order to support pseudonym-based
identity protection. This is typically a cache as well (the identity protection. This is typically a cache as well (the
information can be recreated if the original EAP method SA is lost), information can be recreated if the original EAP method SA is lost),
but may be stored for longer periods of time. but may be stored for longer periods of time.
The EAP method SA is not restricted to a particular service or The EAP method SA is not restricted to a particular service or
authenticator and is most useful when the peer accesses many authenticator and is most useful when the peer accesses many
different authenticators. An EAP method is responsible for different authenticators. An EAP method is responsible for
specifying how the parties select if an existing EAP method SA should specifying how the parties select if an existing EAP method SA should
be used, and if so, which one. Where multiple backend authentication be used, and if so, which one. Where multiple backend authentication
servers are used, EAP method SAs are not typically synchronized servers are used, EAP method SAs are not typically synchronized
between them. between them.
EAP method implementations should consider the appropriate lifetime EAP method implementations should consider the appropriate lifetime
for the EAP method SA. "Fast resume" assumes that the information for the EAP method SA. "Fast reconnect" assumes that the information
required (primarily the keys in the EAP method SA) hasn't been required (primarily the keys in the EAP method SA) hasn't been
compromised. In case the original authentication was carried out compromised. In case the original authentication was carried out
using, for instance, a smart card, it may be easier to compromise the using, for instance, a smart card, it may be easier to compromise the
EAP method SA (stored on the PC, for instance), so typically the EAP EAP method SA (stored on the PC, for instance), so typically the EAP
method SAs have a limited lifetime. method SAs have a limited lifetime.
Contents: Contents:
o Implicitly, the EAP method this SA refers to o Implicitly, the EAP method this SA refers to
o One or more internal (non-exported) keys o Internal (non-exported) cryptographic state
o EAP method SA name o EAP method SA name
o SA lifetime o SA lifetime
3.1.1. Example: EAP-TLS 3.1.1. Example: EAP-TLS
In EAP-TLS [RFC2716], after the EAP authentication the client (peer) In EAP-TLS [RFC2716], after the EAP authentication the client (peer)
and server can store the following information: and server can store the following information:
o Implicitly, the EAP method this SA refers to (EAP-TLS) o Implicitly, the EAP method this SA refers to (EAP-TLS)
o Session identifier (a value selected by the server) o Session identifier (a value selected by the server)
o Certificate of the other party (server stores the client's o Certificate of the other party (server stores the client's
certificate and vice versa) certificate and vice versa)
o Ciphersuite and compression method o Ciphersuite and compression method
o TLS Master secret (known as the EAP-TLS Master Key or MK) o TLS Master secret (known as the EAP-TLS Master Key)
o SA lifetime (ensuring that the SA is not stored forever) o SA lifetime (ensuring that the SA is not stored forever)
o If the client has multiple different credentials (certificates o If the client has multiple different credentials (certificates
and corresponding private keys), a pointer to those credentials and corresponding private keys), a pointer to those credentials
When the server initiates EAP-TLS, the client can look up the EAP-TLS When the server initiates EAP-TLS, the client can look up the EAP-TLS
SA based on the credentials it was going to use (certificate and SA based on the credentials it was going to use (certificate and
private key), and the expected credentials (certificate or name) of private key), and the expected credentials (certificate or name) of
the server. If an EAP-TLS SA exists, and it is not too old, the the server. If an EAP-TLS SA exists, and it is not too old,
the
client informs the server about the existence of this SA by including client informs the server about the existence of this SA by including
its Session-Id in the TLS ClientHello message. The server then looks its Session-Id in the TLS ClientHello message. The server then looks
up the correct SA based on the Session-Id (or detects that it doesn't up the correct SA based on the Session-Id (or detects that it doesn't
yet have one). yet have one).
3.1.2. Example: EAP-AKA 3.1.2. Example: EAP-AKA
In EAP-AKA [I-D.arkko-pppext-eap-aka], after EAP authentication the In EAP-AKA [I-D.arkko-pppext-eap-aka], after EAP authentication the
client and server can store the following information: client and server can store the following information:
skipping to change at page 29, line 11 skipping to change at page 33, line 49
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.
3.3.1. Example: RADIUS 3.3.1. Example: RADIUS
In RADIUS, where shared secret authentication is used, the client and In RADIUS, where shared secret authentication is used, the client and
server store each other's IP address and the shared secret, which is server store each other's IP address and the shared secret, which is
used to calculate the Response Authenticator [RFC2865] and Message- used to calculate the Response Authenticator [RFC2865] and Message-
Authenticator [RFC3579] values, and to encrypt some attributes (such Authenticator [RFC3579] values, and to encrypt some attributes (such
as the AAA-Key [RFC2548]). as the AAA-Key, see [RFC3580] Section 3.16).
Where IPsec is used to protect RADIUS [RFC3579] and IKE is used for Where IPsec is used to protect RADIUS [RFC3579] and IKE is used for
key management, the parties store information necessary to key management, the parties store information necessary to
authenticate and authorize the other party (e.g. certificates, trust authenticate and authorize the other party (e.g. certificates, trust
anchors and names). The IKE exchange results in IKE Phase 1 and Phase anchors and names). The IKE exchange results in IKE Phase 1 and Phase
2 SAs containing information used to protect the conversation 2 SAs containing information used to protect the conversation
(session keys, selected ciphersuite, etc.) (session keys, selected ciphersuite, etc.)
3.3.2. Example: Diameter with TLS 3.3.2. Example: Diameter with TLS
skipping to change at page 30, line 13 skipping to change at page 35, line 4
established, it is not necessary for EAP authentication (phase 1a) to established, it is not necessary for EAP authentication (phase 1a) to
be rerun each time. Instead, the Secure Association Protocol can be be rerun each time. Instead, the Secure Association Protocol can be
used to mutually prove possession of the AAA-Key and create used to mutually prove possession of the AAA-Key and create
associated unicast (phase 2a) and multicast (phase 2b) service SAs associated unicast (phase 2a) and multicast (phase 2b) service SAs
and TSKs, enabling the EAP exchange to be bypassed. Unicast and and TSKs, enabling the EAP exchange to be bypassed. Unicast and
multicast service SAs include: multicast service SAs include:
o Service parameters negotiated by the Secure Association Protocol. o Service parameters negotiated by the Secure Association Protocol.
o Endpoint identifiers. o Endpoint identifiers.
o Transient Session Keys used to protect the communication. o Transient Session Keys used to protect the communication.
o Transient Session Key lifetime. o Transient Session Key lifetime.
One function of the Secure Association Protocol is to bind the the One function of the Secure Association Protocol is to bind the the
unicast and multicast service SAs and TSKs to endpoint identifiers. unicast and multicast service SAs and TSKs to endpoint identifiers.
For example, within [IEEE802.11i], the 4-way handshake binds the TSKs For example, within [IEEE802.11i], the 4-way handshake binds the TSKs
to the MAC addresses of the endpoints; in IKE [RFC2409], the TSKs are to the MAC addresses of the endpoints; in [IKEv2], the TSKs are bound
bound to the IP addresses of the endpoints and the negotiated SPI. to the IP addresses of the endpoints and the negotiated SPI.
It is possible for more than one unicast or multicast service SA to It is possible for more than one unicast or multicast service SA to
be derived from a single Root service SA. However, a unicast or be derived from a single Root service SA. However, a unicast or
multicast service SA is always descended from only one Root service multicast service SA is always descended from only one Root service
SA. Unicast or multicast service SAs descended from the same Root SA. Unicast or multicast service SAs descended from the same Root
service SA may utilize the same security parameters (e.g. mode, service SA may utilize the same security parameters (e.g. mode,
ciphersuite, etc.) or they may utilize different parameters. ciphersuite, etc.) or they may utilize different parameters.
An EAP peer may be able to negotiate multiple service SAs with a An EAP peer may be able to negotiate multiple service SAs with a
given authenticator, or may be able to maintain one or more service given authenticator, or may be able to maintain one or more service
skipping to change at page 31, line 15 skipping to change at page 36, line 7
is defined by the Secure Association Protocol. is defined by the Secure Association Protocol.
3.4.1. Example: 802.11i 3.4.1. Example: 802.11i
[IEEE802.11i] Section 8.4.1.1 defines the security associations used [IEEE802.11i] Section 8.4.1.1 defines the security associations used
within IEEE 802.11. A summary follows; the standard should be within IEEE 802.11. A summary follows; the standard should be
consulted for details. consulted for details.
o Pairwise Master Key Security Association (PMKSA) o Pairwise Master Key Security Association (PMKSA)
The PMKSA is a bi-directional SA, used by both parties for sending The PMKSA is a bi-directional SA, used
and receiving. It is created on the peer when EAP authentication by both parties for sending
completes successfully or a pre-shared key is configured. The and receiving. The PMKSA is the Root Service SA. It is created
PMKSA is created on the authenticator when the PMK is received or on the peer when EAP authentication completes successfully or a
created on the authenticator or a pre-shared key is configured. pre-shared key is configured. The PMKSA is created on the
The PMKSA is used to create the PTKSA. PMKSAs are cached for authenticator when the PMK is received or created on the
their lifetimes. The PMKSA consists of the following elements: authenticator or a pre-shared key is configured. The PMKSA is
used to create the PTKSA. PMKSAs are cached for their lifetimes.
The PMKSA consists of the following elements:
- PMKID (security association identifier) - PMKID (security association identifier)
- Authenticator MAC address - Authenticator MAC address
- PMK - PMK
- Lifetime - Lifetime
- Authenticated Key Management Protocol (AKMP) - Authenticated Key Management Protocol (AKMP)
- Authorization parameters specified by the AAA server or - Authorization parameters specified by the AAA server or
by local configuration. This can include by local configuration. This can include
parameters such as the peer's authorized SSID. parameters such as the peer's authorized SSID.
On the peer, this information can be locally On the peer, this information can be locally
skipping to change at page 31, line 45 skipping to change at page 36, line 39
o delete it (e.g. AAA server-initiated disconnect) o delete it (e.g. AAA server-initiated disconnect)
o replace it when a new four-way handshake is done o replace it when a new four-way handshake is done
- Reference to accounting context, the details of which depend - Reference to accounting context, the details of which depend
on the accounting protocol used, the implementation on the accounting protocol used, the implementation
and administrative details. In RADIUS, this could include and administrative details. In RADIUS, this could include
(e.g. packet and octet counters, and Acct-Multi-Session-Id). (e.g. packet and octet counters, and Acct-Multi-Session-Id).
o Pairwise Transient Key Security Association (PTKSA) o Pairwise Transient Key Security Association (PTKSA)
The PTKSA is a bi-directional SA created as the result of a The PTKSA is a bi-directional SA created as the result of a
successful four-way handshake. There may only be one PTKSA successful four-way handshake. The PTKSA is a unicast service SA.
between a pair of peer and authenticator MAC addresses. PTKSAs There may only be one PTKSA between a pair of peer and
are cached for the lifetime of the PMKSA. Since the PTKSA is tied authenticator MAC addresses. PTKSAs are cached for the lifetime
to the PMKSA, it only has the additional information from the of the PMKSA. Since the PTKSA is tied to the PMKSA, it only has
4-way handshake. The PTKSA consists of the following: the additional information from the 4-way handshake. The PTKSA
consists of the following:
- Key (PTK) - Key (PTK)
- Selected ciphersuite - Selected ciphersuite
- MAC addresses of the parties - MAC addresses of the parties
- Replay counters, and ciphersuite specific state - Replay counters, and ciphersuite specific state
- Reference to PMKSA: This is needed when: - Reference to PMKSA: This is needed when:
o A new four-way handshake is needed (lifetime, TKIP o A new four-way handshake is needed (lifetime, TKIP
countermeasures), and we need to know which PMKSA to use countermeasures), and we need to know which PMKSA to use
o Group Transient Key Security Association (GTKSA) o Group Transient Key Security Association (GTKSA)
The GTKSA is a uni-directional SA created based on the four-way The GTKSA is a uni-directional SA created based on the four-way
handshake or the group key handshake. A GTKSA consists of the handshake or the group key handshake. The GTKSA is a multicast
following: service SA. A GTKSA consists of the following:
- Direction vector (whether the GTK is used for transmit or receive) - Direction vector (whether the GTK is used for transmit or receive)
- Group cipher suite selector - Group cipher suite selector
- Key (GTK) - Key (GTK)
- Authenticator MAC address - Authenticator MAC address
- Via reference to PMKSA, or copied here: - Via reference to PMKSA, or copied here:
o Authorization parameters o Authorization parameters
o Reference to accounting context o Reference to accounting context
3.4.2. Example: IKEv2/IPsec 3.4.2. Example: IKEv2/IPsec
skipping to change at page 34, line 16 skipping to change at page 39, line 8
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's parameters related to the authenticator--they apply to peer's
parameters as well. parameters as well.
4. Handoff Support 4. Handoff Support
Within EAP, a number of mechanisms may be utilized in order to reduce With EAP, a number of mechanisms may 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.
"Fast Handoff" is defined as a conversation in which EAP exchange "Fast Handoff" is defined as a conversation in which EAP exchange
(phase 1a) and associated AAA pass-through is bypassed, so as to (phase 1a) and associated AAA pass-through is bypassed, so as to
reduce latency. Unlike EAP pre-authentication, "Fast Handoff" reduce latency. Unlike EAP pre-authentication, "Fast Handoff"
mechanisms do not result in additional AAA server load. Fast handoff mechanisms do not result in additional AAA server load. Fast handoff
mechanisms include: mechanisms include:
skipping to change at page 34, line 41 skipping to change at page 39, line 33
includes conventional AAA-Key transport, but without an EAP includes conventional AAA-Key transport, but without an EAP
authentication. authentication.
[b] Context transfer. In this technique, the old authenticator [b] Context transfer. In this technique, the old authenticator
transfers the session text to the new authenticator, either prior transfers the session text to the new authenticator, either prior
to, or after the arrival of the peer. As a result, AAA-Key to, or after the arrival of the peer. As a result, AAA-Key
transport (phase 1b) is bypassed. transport (phase 1b) is bypassed.
Regardless of how the AAA-Key is provisioned on a given Regardless of how the AAA-Key is provisioned on a given
authenticator, AAA-Key caching may be utilized in order to enable a authenticator, AAA-Key caching may be utilized in order to enable a
peer to quickly re-establish a session with an authenticator. peer to quickly re-esta
blish a session with an authenticator.
Where key caching is supported, once the AAA-Key is derived and/or Where key caching is supported, once the AAA-Key is derived and/or
transported to the authenticator, it may remain cached on the peer transported to the authenticator, it may remain cached on the peer
and authenticator, even after a subsequent session terminates. To and authenticator, even after a subsequent session terminates. To
initiate a subsequent session with the same authenticator, the peer initiate a subsequent session with the same authenticator, the peer
may utilize the Secure Association Protocol to confirm mutual may utilize the Secure Association Protocol to confirm mutual
possession of the AAA-Key by the peer and authenticator, thereby re- possession of the AAA-Key by the peer and authenticator, thereby re-
activating the AAA-Key for use in a subsequent session. activating the AAA-Key for use in a subsequent session.
The introduction of handoff support introduces new security The introduction of handoff support introduces new security
vulnerabilities as well as requirements for the secure handling of vulnerabilities as well as requirements for the secure handling of
authorization context. These issues are discussed in the sections authorization context. These issues are discussed in the sections
that follow. that follow.
4.1. Key Scope Issues 4.1. Authorization Issues
As described in Appendix E, the AAA-Key is calculated from the EMSK
and MSK by the EAP peer and server, and is used as the root of the
ciphersuite-specific key hierarchy. Where a backend authentication
server is present, the AAA-Key is transported from the EAP server to
the authenticator; where it is not present, the AAA-Key is calculated
on the authenticator.
Regardless of how many sessions are initiated using it, the AAA-Key
is restricted to use between the EAP peer that calculates it, and the
authenticator that either calculates it (where no backend
authenticator is present) or receives it from the server (where a
backend authenticator server is present). In the process of defining
the scope of the AAA-Key, it should be understood that an
authenticator or peer:
[a] may contain multiple physical ports;
[b] may advertise itself as multiple "virtual" authenticators or peers;
[c] may utilize multiple CPUs;
[d] may support clustering services for load balancing or failover.
As illustrated in Figure 1, an EAP peer with multiple ports may be
attached to one or more authenticators, each with multiple ports.
Where the peer and authenticator identify themselves using a port
identifier such as a link layer address, it may not be obvious to the
peer which authenticator ports are associated with which
authenticators. Similarly, it may not be obvious to the
authenticator which peer ports are associated with which peers. As a
result, the peer and authenticator may not be able to determine the
scope of the AAA-Key.
When a single physical authenticator advertises itself as multiple
"virtual authenticators", the EAP peer and authenticator also may not
be able to agree on the scope of the AAA-Key, creating a security
vulnerability. For example, the peer may assume that the "virtual
authenticators" are distinct and do not share a key cache, whereas,
depending on the architecture of the physical AP, a shared key cache
may or may not be implemented.
Where the AAA-Key is shared between "virtual authenticators" an
attacker acting as a peer could authenticate with the "Guest"
"virtual authenticator" and derive a AAA-Key. If the virtual
authenticators share a key cache, then the peer can utilize the AAA-
Key derived for the "Guest" network to obtain access to the
"Corporate Intranet" virtual authenticator.
Several measures are recommended to address these issues: peers and
authenticators may have multiple ports.
[a] Authenticators are REQUIRED to cache associated authorizations
along with the AAA-Key and apply authorizations consistently. This
ensures that an attacker cannot obtain elevated privileges even
where the AAA-Key cache is shared between "virtual authenticators".
[b] It is RECOMMENDED that physical authenticators maintain separate
AAA-Key caches for each "virtual authenticator".
[c] It is RECOMMENDED that each "virtual authenticator" identify itself
distinctly to the AAA server, such as by utilizing a distinct NAS-
identifier attribute. This enables the AAA server to utilize a
separate credential to authenticate each "virtual authenticator".
[d] It is RECOMMENDED that Secure Association Protocols identify peers
and authenticators unambiguously, without incorporating implicit
assumptions about peer and authenticator architectures. Using
port-specific MAC addresses as identifiers is NOT RECOMMENDED where
peers and authenticators may support multiple ports.
[e] The AAA server and authenticator MAY implement additional
attributes in order to further restrict the AAA-Key scope. For
example, in 802.11, the AAA server may provide the authenticator
with a list of authorized Called or Calling-Station-Ids and/or
SSIDs for which the AAA-Key is valid.
[f] Where the AAA server provides attributes restricting the key scope,
it is RECOMMENDED that restrictions be securely communicated by the
authenticator to the peer. This is typically accomplished using
the Secure Association Protocol, but also can be accomplished via
the EAP method or the lower layer.
4.2. Authorization Issues
In a typical network access scenario (dial-in, wireless LAN, etc.) In a typical network access scenario (dial-in, wireless LAN, etc.)
access control mechanisms are typically applied. These mechanisms access control mechanisms are typically applied. These mechanisms
include user authentication as well as authorization for the offered include user authentication as well as authorization for the offered
service. service.
As a part of the authentication process, the AAA network determines As a part of the authentication process, the AAA network determines
the user's authorization profile. The user authorizations are the user's authorization profile. The user authorizations are
transmitted by the backend authentication server to the EAP transmitted by the backend authentication server to the EAP
authenticator (also known as the Network Access Server or authenticator (also known as the Network Access Server or
skipping to change at page 38, line 5 skipping to change at page 41, line 8
the authenticator. the authenticator.
The criteria for Accept/Reject decisions or the reasons for choosing The criteria for Accept/Reject decisions or the reasons for choosing
particular authorizations are typically not communicated to the particular authorizations are typically not communicated to the
authenticator, only the final result. As a result, the authenticator authenticator, only the final result. As a result, the authenticator
has no way to know what the decision was based on. Was a set of has no way to know what the decision was based on. Was a set of
authorization parameters sent because this service is always provided authorization parameters sent because this service is always provided
to the user, or was the decision based on the time/day and the to the user, or was the decision based on the time/day and the
capabilities of the requesting authenticator device? capabilities of the requesting authenticator device?
4.3. Correctness Issues 4.2. Correctness Issues
Bypassing all or portions of the AAA conversation creates challenges Bypassing all or portions of the AAA conversation creates challenges
in ensuring that authorization is properly handled. These include: 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. A fast handoff
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. A fast handoff should not result
skipping to change at page 39, line 32 skipping to change at page 42, line 36
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 [IEEE8021Q]. If a fast
handoff bypassing the backend authentication server were to occur handoff bypassing the backend authentication server were to occur
between a authenticator supporting dynamic VLANs and another between a authenticator supporting dynamic VLANs and another
authenticator which does not, then a guest user with access authenticator which does not, then a guest user with access
restricted to a guest VLAN could be given unrestricted access to the restricted to a guest 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-Sta
tion-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. fast 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 fast 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 fast handoff may not succeed. For example, [RFC2865] section 1.1
skipping to change at page 40, line 48 skipping to change at page 44, line 9
insecure channel without permission from the backend authentication insecure channel without permission from the backend authentication
server. Thus the definition of a "known but unsupported service" server. Thus the definition of a "known but unsupported service"
MUST encompass requests for unavailable security services. This MUST encompass requests for unavailable security services. This
includes vendor-specific attributes related to security, such as includes vendor-specific attributes related to security, such as
those described in [RFC2548]. those described in [RFC2548].
5. Security Considerations 5. Security Considerations
5.1. Security Terminology 5.1. Security Terminology
Cryptographic binding "Cryptographic binding", "Cryptographic separation", "Key strength"
The demonstration of the EAP peer to the EAP server that a single and "Mutual authentication" are defined in [RFC3748] and are used
entity has acted as the EAP peer for all methods executed within a with the same meaning here.
tunnel method. Binding MAY also imply that the EAP server
demonstrates to the peer that a single entity has acted as the EAP
server for all methods executed within a tunnel method. If
executed correctly, binding serves to mitigate man-in-the-middle
vulnerabilities.
Cryptographic separation
Two keys (x and y) are "cryptographically separate" if an adversary
that knows all messages exchanged in the protocol cannot compute x
from y or y from x without "breaking" some cryptographic
assumption. In particular, this definition allows that the
adversary has the knowledge of all nonces sent in cleartext as well
as all predictable counter values used in the protocol. Breaking a
cryptographic assumption would typically require inverting a one-
way function or predicting the outcome of a cryptographic pseudo-
random number generator without knowledge of the secret state. In
other words, if the keys are cryptographically separate, there is
no shortcut to compute x from y or y from x, but the work an
adversary must do to perform this computation is equivalent to
performing exhaustive search for the secret state value.
Key strength
If the effective key strength is N bits, the best currently known
methods to recover the key (with non-negligible probability)
require on average an effort comparable to 2^(N-1) operations of a
typical block cipher.
Mutual authentication
This refers to an EAP method in which, within an interlocked
exchange, the authenticator authenticates the peer and the peer
authenticates the authenticator. Two independent one-way methods,
running in opposite directions do not provide mutual authentication
as defined here.
5.2. Threat Model 5.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 [WLANREQ].
The RADIUS threat model is described in [RFC3579] Section 4.1, and The RADIUS threat model is described in [RFC3579] Section 4.1, and
skipping to change at page 43, line 36 skipping to change at page 46, line 12
Figure 6 illustrates the relationship between the peer, authenticator Figure 6 illustrates the relationship between the peer, authenticator
and backend authentication server. and backend authentication server.
EAP peer EAP peer
/\ /\
/ \ / \
Protocol: EAP / \ Protocol: Secure Association Protocol: EAP / \ Protocol: Secure Association
Auth: Mutual / \ Auth: Mutual Auth: Mutual / \ Auth: Mutual
Unique keys: / \ Unique keys: TSKs Unique keys: / \ Unique keys: TSKs
TEKs,EMSK / \ TEKs,EMSK / \
/ \ /
\
EAP server +--------------+ Authenticator EAP server +--------------+ Authenticator
Protocol: AAA Protocol: AAA
Auth: Mutual Auth: Mutual
Unique key: AAA session key Unique key: AAA session key
Figure 6: Relationship between peer, authenticator and auth. server Figure 6: Relationship between peer, authenticator and auth. server
The peer and EAP server communicate using EAP [RFC3748]. The The peer and EAP server communicate using EAP [RFC3748]. The
security properties of this communication are largely determined by security properties of this communication are largely determined by
the chosen EAP method. Method security claims are described in the chosen EAP method. Method security claims are described in
skipping to change at page 46, line 29 skipping to change at page 49, line 4
required [IEEE80211i], so as to address the threat of rogue devices, required [IEEE80211i], so as to address the threat of rogue devices,
and provide keying material to bind the initial authentication to and provide keying material to bind the initial authentication to
subsequent data traffic. 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 hijac
k.
If the backend authentication server does not protect against If the backend authentication server does not protect against
authenticator masquerade, or provide the proper binding of the AAA- authenticator masquerade, or provide the proper binding of the AAA-
Key to the session within the AAA-Token, then one or more AAA-Keys Key to the session within the AAA-Token, then one or more AAA-Keys
may be sent to an unauthorized party, and an attacker may be able to may be sent to an unauthorized party, and an attacker may be able to
gain access to the network. If the AAA-Token is provided to an gain access to the network. If the AAA-Token is provided to an
untrusted AAA intermediary, then that intermediary may be able to untrusted AAA intermediary, then that intermediary may be able to
modify the AAA-Key, or the attributes associated with it, as modify the AAA-Key, or the attributes associated with it, as
described in [RFC2607]. described in [RFC2607].
skipping to change at page 47, line 24 skipping to change at page 49, line 46
In order to prevent these attacks, [I-D.puthenkulam-eap-binding] In order to prevent these attacks, [I-D.puthenkulam-eap-binding]
recommends derivation of a compound key by which the EAP peer and recommends derivation of a compound key by which the EAP peer and
server can prove that they have participated in the entire EAP server can prove that they have participated in the entire EAP
exchange. Since the compound key must not be known to an attacker exchange. Since the compound key must not be known to an attacker
posing as an authenticator, and yet must be derived from quantities posing as an authenticator, and yet must be derived from quantities
that are exported by EAP methods, it may be desirable to derive the that are exported by EAP methods, it may be desirable to derive the
compound key from a portion of the EMSK. In order to provide proper compound key from a portion of the EMSK. In order to provide proper
key hygiene, it is recommended that the compound key used for man-in- key hygiene, it is recommended that the compound key used for man-in-
the-middle protection be cryptographically separate from other keys the-middle protection be cryptographically separate from other keys
derived from the EMSK, such as fast handoff keys, discussed in derived from the EMSK, such as fast handoff keys, discussed in
Appendix E. Section 2.5.
5.5. Denial of Service Attacks 5.5. Denial of Service Attacks
The caching of security associations may result in vulnerability to The caching of security associations may result in vulnerability to
denial of service attacks. Since an EAP peer may derive multiple EAP denial of service attacks. Since an EAP peer may derive multiple EAP
SAs with a given EAP server, and creation of a new EAP SA does not SAs with a given EAP server, and creation of a new EAP SA does not
implicitly delete a previous EAP SA, EAP methods that result in implicitly delete a previous EAP SA, EAP methods that result in
creation of persistent state may be vulnerable to denial of service creation of persistent state may be vulnerable to denial of service
attacks by a rogue EAP peer. attacks by a rogue EAP peer.
skipping to change at page 49, line 17 skipping to change at page 51, line 38
this vulnerability, it is necessary to allow the backend this vulnerability, it is necessary to allow the backend
authentication server to communicate with the authenticator directly, authentication server to communicate with the authenticator directly,
such as via the redirect functionality supported in [RFC3588]. such as via the redirect functionality supported in [RFC3588].
5.7. Channel binding 5.7. Channel binding
It is possible for a compromised or poorly implemented EAP It is possible for a compromised or poorly implemented EAP
authenticator to communicate incorrect information to the EAP peer authenticator to communicate incorrect information to the EAP peer
and/or server. This may enable an authenticator to impersonate and/or server. This may enable an authenticator to impersonate
another authenticator or communicate incorrect information via out- another authenticator or communicate incorrect information via out-
of-band mechanisms (such as via a AAA or lower layer protocol). of-band mechanisms (such as via AAA or the lower layer protocol).
Where EAP is used in pass-through mode, the EAP peer typically does Where EAP is used in pass-through mode, the EAP peer typically does
not verify the identity of the pass-through authenticator, it only not verify the identity of the pass-through authenticator, it only
verifies that the pass-through authenticator is trusted by the EAP verifies that the pass-through authenticator is trusted by the EAP
server. This creates a potential security vulnerability, described in server. This creates a potential security vulnerability, described in
[RFC3748] Section 7.15. [RFC3748] Section 7.15.
[RFC3579] Section 4.3.7 describes how an EAP pass-through [RFC3579] Section 4.3.7 describes how an EAP pass-through
authenticator acting as a AAA client can be detected if it attempts authenticator acting as a AAA client can be detected if it attempts
to impersonate another authenticator (such by sending incorrect NAS- to impersonate another authenticator (such by sending incorrect NAS-
Identifier [RFC2865], NAS-IP-Address [RFC2865] or NAS-IPv6-Address Identifier [RFC2865], NAS-IP-Address [RFC2865] or NAS-IPv6-Address
[RFC3162] attributes via the AAA protocol). However, it is possible [RFC3162] attributes via the AAA protocol). However, it is possible
for a pass-through authenticator acting as a AAA client to provide for a pass-through authenticator acting as a AAA client to provide
INTERNET-DRAFT EAP Key Management Framework
14 November 2004
correct information to the AAA server while communicating misleading correct information to the AAA server while communicating misleading
information to the EAP peer via a lower layer protocol. information to the EAP peer via a lower layer protocol.
For example, it is possible for a compromised authenticator to For example, it is possible for a compromised authenticator to
utilize another authenticator's Called-Station-Id or NAS-Identifier utilize another authenticator's Called-Station-Id or NAS-Identifier
in communicating with the EAP peer via a lower layer protocol, or for in communicating with the EAP peer via a lower layer protocol, or for
a pass-through authenticator acting as a AAA client to provide an a pass-through authenticator acting as a AAA client to provide an
incorrect peer Calling-Station-Id [RFC2865][RFC3580] to the AAA incorrect peer Calling-Station-Id [RFC2865][RFC3580] to the AAA
server via the AAA protocol. server via the AAA protocol.
As noted in [RFC3748] Section 7.15, this vulnerability can be As noted in [RFC3748] Section 7.15, this vulnerability can be
addressed by use of EAP methods that support a protected exchange of addressed by use of EAP methods that support a protected exchange of
channel properties such as endpoint identifiers, including (but not channel properties such as endpoint identifiers, including (but not
limited to): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id limited to): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id
[RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address [RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address
[RFC2865], and NAS-IPv6-Address [RFC3162]. [RFC2865], and NAS-IPv6-Address [RFC3162].
Using such a protected exchange, it is possible to match the channel Using such a protected exchange, it is possible to match the channel
properties provided by the authenticator via out-of-band mechanisms properties provided by the authenticator via out-of-band mechanisms
against those exchanged within the EAP method. against those exchanged within the EAP method. For example, see
[ServiceIdent].
5.8. Key Strength 5.8. 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 necessary for EAP methods generation is not the weakest link, it is necessary for EAP methods
utilizing public key cryptography to choose a public key that has a utilizing public key cryptography to choose a public key that has a
cryptographic strength meeting the symmetric key strength cryptographic strength meeting the symmetric key strength
requirement. requirement.
skipping to change at page 51, line 10 skipping to change at page 53, line 34
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 where key separation is implemented, compromise of the AAA-Key does
not enable an attacker to impersonate the peer to another not enable an attacker to impersonate the peer to another
authenticator, since that requires possession of the MK or EMSK, authenticator, since that requires possession of the EMSK, which is
which are not transported by the AAA protocol. This vulnerability not transported by the AAA protocol. This vulnerability may be
may be mitigated by implementation of redirect functionality, as mitigated by implementation of redirect functionality, as provided in
provided in [RFC3588]. [RFC3588].
6. Security Requirements 6. Security Requirements
This section summarizes the security requirements that must be met by This section summarizes the security requirements that must be met by
EAP methods, AAA protocols, Secure Association Protocols and EAP methods, AAA protocols, Secure Association Protocols and
Ciphersuites in order to address the security threats described in Ciphersuites in order to address the security threats described in
this document. These requirements MUST be met by specifications this document. These requirements MUST be met by specifications
requesting publication as an RFC. Each requirement provides a requesting publication as an RFC. Each requirement provides a
pointer to the sections of this document describing the threat that pointer to the sections of this document describing the threat that
it mitigates. it mitigates.
skipping to change at page 51, line 44 skipping to change at page 54, line 19
The MSK and EMSK MUST NOT be used directly to protect data; however, The MSK and EMSK MUST NOT be used directly to protect data; however,
they are of sufficient size to enable derivation of a AAA-Key they are of sufficient size to enable derivation of a AAA-Key
subsequently used to derive Transient Session Keys (TSKs) for use subsequently used to derive Transient Session Keys (TSKs) for use
with the selected ciphersuite. Each ciphersuite is responsible for with the selected ciphersuite. Each ciphersuite is responsible for
specifying how to derive the TSKs from the AAA-Key. specifying how to derive the TSKs from the AAA-Key.
The AAA-Key is derived from the keying material exported by the EAP The AAA-Key is derived from the keying material exported by the EAP
method (MSK and EMSK). This derivation occurs on the AAA server. In method (MSK and EMSK). This derivation occurs on the AAA server. In
many existing protocols that use EAP, the AAA-Key and MSK are many existing protocols that use EAP, the AAA-Key and MSK are
equivalent, but more complicated mechanisms are possible (see equivalent, but more complicated mechanisms are possible (see Section
Appendix E for details). 2.5 for details).
EAP methods SHOULD ensure the freshness of the MSK and EMSK even in EAP methods SHOULD ensure the freshness of the MSK and EMSK even in
cases where one party may not have a high quality random number cases where one party may not have a high quality random number
generator. A RECOMMENDED method is for each party to provide a nonce generator. A RECOMMENDED method is for each party to provide a nonce
of at least 128 bits, used in the derivation of the MSK and EMSK. of at least 128 bits, used in the derivation of the MSK and EMSK.
EAP methods export the MSK and EMSK and not Transient Session Keys so EAP methods export the MSK and EMSK and not Transient Session Keys so
as to allow EAP methods to be ciphersuite and media independent. as to allow EAP methods to be ciphersuite and media independent.
Keying material exported by EAP methods MUST be independent of the Keying material exported by EAP methods MUST be independent of the
ciphersuite negotiated to protect data. ciphersuite negotiated to protect data.
skipping to change at page 52, line 30 skipping to change at page 55, line 4
In order to preserve algorithm independence, EAP methods deriving In order to preserve algorithm independence, EAP methods deriving
keys SHOULD support (and document) the protected negotiation of the keys SHOULD support (and document) the protected negotiation of the
ciphersuite used to protect the EAP conversation between the peer and ciphersuite used to protect the EAP conversation between the peer and
server. This is distinct from the ciphersuite negotiated between the server. This is distinct from the ciphersuite negotiated between the
peer and authenticator, used to protect data. peer and authenticator, used to protect data.
The strength of Transient Session Keys (TSKs) used to protect data is The strength of Transient Session Keys (TSKs) used to protect data is
ultimately dependent on the strength of keys generated by the EAP ultimately dependent on the strength of keys generated by the EAP
method. If an EAP method cannot produce keying material of method. If an EAP method cannot produce keying material of
sufficient strength, then the TSKs may be subject to brute force sufficient strength, then the TSKs may be subject to brute force
attack. In order to enable deployments requiring strong keys, EAP attack.
In order to enable deployments requiring strong keys, EAP
methods supporting key derivation SHOULD be capable of generating an methods supporting key derivation SHOULD be capable of generating an
MSK and EMSK, each with an effective key strength of at least 128 MSK and EMSK, each with an effective key strength of at least 128
bits. bits.
Methods supporting key derivation MUST demonstrate cryptographic Methods supporting key derivation MUST demonstrate cryptographic
separation between the MSK and EMSK branches of the EAP key separation between the MSK and EMSK branches of the EAP key
hierarchy. Without violating a fundamental cryptographic assumption hierarchy. Without violating a fundamental cryptographic assumption
(such as the non-invertibility of a one-way function) an attacker (such as the non-invertibility of a one-way function) an attacker
recovering the MSK or EMSK MUST NOT be able to recover the other 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 substring without breaking some NOT help in recovering some other non-overlapping substring without
hard cryptographic assumption. This is required because some breaking some hard cryptographic assumption. This is required
existing ciphersuites form TSKs by simply splitting the AAA-Key to because some existing ciphersuites form TSKs by simply splitting the
pieces of appropriate length. Likewise, non-overlapping substrings AAA-Key to pieces of appropriate length. Likewise, non-overlapping
of the EMSK MUST be cryptographically separate from each other, and substrings of the EMSK MUST be cryptographically separate from each
from substrings of the MSK. other, and from substrings of the MSK.
The EMSK MUST remain on the EAP peer and EAP server where it is 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 derived; it MUST NOT be transported to, or shared with, additional
parties, or used to derive any other keys. parties, or used for purposes other than AMSK derivation (see Section
2.6).
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 key derivation (such as those specified and analyzed mechanisms for MSK and EMSK key derivation (such as
in IKE [RFC2409] or TLS [RFC2246]), rather than inventing new ones. those specified in IKE [RFC2409] or TLS [RFC2246]), rather than
EAP methods SHOULD also utilize well established and analyzed inventing new ones.
mechanisms for MSK and EMSK derivation.
6.1.1. Requirements for EAP methods 6.1.1. Requirements for EAP methods
In order for an EAP method to meet the guidelines for EMSK usage it In order for an EAP method to meet the guidelines for EMSK usage it
must meet the following requirements: must meet the following requirements:
o It must specify how to derive the EMSK o It MUST specify how to derive the EMSK
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 be maintained within the EAP server. o The EMSK MUST NOT be exported from the EAP server.
Only keys (AMSKs) derived according to this specification Only keys (AMSKs) derived according to this specification
may be exported from the EAP server. 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 provide a way of 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 Implementations of EAP frameworks on the EAP-Peer and EAP-Server
SHOULD provide an interface to obtain AMSKs. The implementation MAY SHOULD provide an interface to obtain AMSKs. The implementation MAY
restrict which callers can obtain which keys. restrict which callers can obtain which keys.
6.1.2. Requirements for EAP applications 6.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 in any other way except to
derive Application Master Session Keys (AMSKs) using the derive Application Master Session Keys (AMSKs) using the
key derivation specified in Appendix F. It MUST NOT key derivation specified in Section 2.6. It MUST NOT
use the EMSK directly for cryptographic protection of data, use the EMSK directly for cryptographic protection of data,
and SHOULD provide only the AMSKs to applications. and SHOULD provide only the AMSKs to applications.
o Applications MUST define distinct key labels, application o Applications MUST define distinct key labels, application
specific data, and the length of derived key material used in the key specific data, and the length of derived key material used in the key
derivation described in Appendix F. derivation described in Section 2.6.
o Applications MUST define how they use their AMSK to derive TSKs o Applications MUST define how they use their AMSK to derive TSKs
for their use. for their use.
6.2. AAA Protocol Requirements 6.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
skipping to change at page 56, line 10 skipping to change at page 58, line 32
6.3. Secure Association Protocol Requirements 6.3. Secure Association Protocol Requirements
The Secure Association Protocol supports the following: The Secure Association Protocol supports the following:
Entity Naming Entity Naming
The peer and authenticator SHOULD identify themselves in a manner The peer and authenticator SHOULD identify themselves in a manner
that is independent of their attached ports. that is independent of their attached ports.
Mutual proof of possession Mutual proof of possession
The peer and authenticator MUST each demonstrate possession of the The peer and authenticator MUST each demo
nstrate possession of the
keying material transported between the backend authentication keying material transported between the backend authentication
server and authenticator (AAA-Key). server and authenticator (AAA-Key).
Key Naming Key Naming
The Secure Association Protocol MUST explicitly name the keys used The Secure Association Protocol MUST explicitly name the keys used
in the proof of possession exchange, so as to prevent confusion in the proof of possession exchange, so as to prevent confusion
when more than one set of keying material could potentially be used when more than one set of keying material could potentially be used
as the basis for the exchange. as the basis for the exchange.
Creation and Deletion Creation and Deletion
skipping to change at page 59, line 33 skipping to change at page 62, line 5
[RFC0793] [RFC0793]
Postel, J., "Transmission Control Protocol", STD 7, RFC 793, Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981. September 1981.
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
1661, July 1994. 1661, July 1994.
[RFC1968] Meyer, G. and K. Fox, "The PPP Encryption Control Protocol [RFC1968] Meyer, G. and K. Fox, "The PPP Encryption Control Protocol
(ECP)", RFC 1968, June 1996. (ECP)", RFC 1968, June 1996.
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing [RFC2104] Krawczyk, H., Bellare,
M. and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997. for Message Authentication", RFC 2104, February 1997.
[RFC2246] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. [RFC2246] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A.
and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246,
January 1999. January 1999.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
skipping to change at page 63, line 23 skipping to change at page 65, line 44
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, and Russ Dorothy Stanley of Agere, Bob Moskowitz of TruSecure, and Russ
Housley of Vigil Security for useful feedback. Housley of Vigil Security for useful feedback.
Author Addresses Author Addresses
Bernard Aboba Bernard Aboba
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98
052
EMail: bernarda@microsoft.com EMail: bernarda@microsoft.com
Phone: +1 425 706 6605 Phone: +1 425 706 6605
Fax: +1 425 936 7329 Fax: +1 425 936 7329
Dan Simon Dan Simon
Microsoft Research Microsoft Research
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
skipping to change at page 65, line 45 skipping to change at page 67, line 45
[IEEE80211], which requires a 40-bit encryption key, the same in [IEEE80211], 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 [IEEE80211i]. These include TKIP,
which requires a single 128-bit encryption key and a 128-bit which requires a single 128-bit encryption key and two 64-bit
authentication key (used in both directions); 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; and WRAP, which requires a single authenticate and encrypt data.
128-bit key (used in both directions).
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
Figure B-1 illustrates the TEK key hierarchy for EAP-TLS [RFC2716], Figure B-1 illustrates the TEK key hierarchy for EAP-TLS [RFC2716],
which is based on the TLS key hierarchy described in [RFC2246]. The which is based on the TLS key hierarchy described in [RFC2246]. The
TLS-negotiated ciphersuite is used to set up a protected channel for TLS-negotiated ciphersuite is used to set up a protected channel for
use in protecting the EAP conversation, keyed by the derived TEKs. use in protecting the EAP conversation, keyed by the derived TEKs.
The TEK derivation proceeds as follows: The TEK derivation proceeds as follows:
master_secret = TLS-PRF-48(pre_master_secret, "master secret", master_secret = TLS-PRF-48(pre_master_secret, "master secret",
client.random || server.random) client.random || server.random)
TEK = TLS-PRF-X(master_secret, "key expansion", TEK = TLS-PRF-X(master_secret, "key expansion",
server.random || client.random) server.random || client.random)
Where: Where:
TLS-PRF-X = TLS pseudo-random function defined in [RFC2246], TLS-PRF-X = TLS pseudo-random function defined in [RFC2246],
computed to X octets. computed to X octets.
master_secret = TLS term for the MK.
| | | | | |
| | pre_master_secret | | | pre_master_secret |
server| | | client server| | | client
Random| V | Random Random| V | Random
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | | | | | |
| | | | | | | |
+---->| master_secret |<------+ +---->| master_secret |<------+
| | (MK) | | | | (TMS) | |
| | | | | | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | | | |
| | | | | |
| | | | | |
V V V V V V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
| Key Block | | Key Block |
skipping to change at page 67, line 5 skipping to change at page 69, line 5
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | | | | | | |
| client | server | client | server | client | server | client | server | client | server | client | server
| MAC | MAC | write | write | IV | IV | MAC | MAC | write | write | IV | IV
| | | | | | | | | | | |
V V V V V V V V V V V V
Figure B-1 - TLS [RFC2246] Key Hierarchy Figure B-1 - TLS [RFC2246] Key Hierarchy
Appendix C - EAP Key Hierarchy Appendix C - EAP-TLS Key Hierarchy
In EAP-TLS [RFC2716], the MSK is divided into two halves, In EAP-TLS [RFC2716], the MSK is divided into two halves,
corresponding to the "Peer to Authenticator Encryption Key" (Enc- corresponding to the "Peer to Authenticator Encryption Key" (Enc-
RECV-Key, 32 octets, also known as the PMK) and "Authenticator to RECV-Key, 32 octets, also known as the PMK) and "Authenticator to
Peer Encryption Key" (Enc-SEND-Key, 32 octets). In [RFC2548], the Peer Encryption Key" (Enc-SEND-Key, 32 octets). In [RFC2548], the
Enc-RECV-Key (the PMK) is transported in the MS-MPPE-Recv-Key Enc-RECV-Key (the PMK) is transported in the MS-MPPE-Recv-Key
attribute, and the Enc-SEND-Key is transported in the MS-MPPE-Send- attribute, and the Enc-SEND-Key is transported in the MS-MPPE-Send-
Key attribute. Key attribute.
The EMSK is also divided into two halves, corresponding to the "Peer The EMSK is also divided into two halves, corresponding to the "Peer
to Authenticator Authentication Key" (Auth-RECV-Key, 32 octets) and to Authenticator Authentication Key" (Auth-RECV-Key, 32 octets) and
"Authenticator to Peer Authentication Key" (Auth-SEND-Key, 32 "Authenticator to Peer Authentication Key" (Auth-SEND-Key, 32
octets). The IV is a 64 octet quantity that is a known value; octets octets). The IV is a 64 octet quantity that is a known value; octets
0-31 are known as the "Peer to Authenticator IV" or RECV-IV, and 0-31 are known as the "Peer to Authenticator IV" or RECV-IV, and
Octets 32-63 are known as the "Authenticator to Peer IV", or SEND-IV. Octets 32-63 are known as the "Authenticator to Peer IV", or SEND-IV.
In EAP-TLS, the MSK, EMSK and IV are derived from the MK via a one- In EAP-TLS, the MSK, EMSK and IV are derived from the TLS master
way function. This ensures that the MK cannot be derived from the secret via a one-way function. This ensures that the TLS master
MSK, EMSK or IV unless the one-way function (TLS PRF) is broken. secret cannot be derived from the MSK, EMSK or IV unless the one-way
Since the MSK is derived from the MK, if the MK is compromised then function (TLS PRF) is broken. Since the MSK is derived from the the
the MSK is also compromised. TLS master secret, if the TLS master secret is compromised then the
MSK is also compromised.
As described in [RFC2716], the formula for the derivation of the MSK, As described in [RFC2716], the formula for the derivation of the MSK,
EMSK and IV from the MK is as follows: EMSK and IV is as follows:
MSK = TLS-PRF-64(MK, "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(MK, "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)
(MS-MPPE-Recv-Key in [RFC2548]). Also known as the (MS-MPPE-Recv-Key in [RFC2548]). Also known as the
PMK. PMK.
AAA-Key(32,63)= Authenticator to Peer Encryption Key (Enc-SEND-Key) AAA-Key(32,63)= Authenticator to Peer Encryption Key (Enc-SEND-Key)
(MS-MPPE-Send-Key in [RFC2548]) (MS-MPPE-Send-Key in [RFC2548])
EMSK(0,31) = Peer to Authenticator Authentication Key (Auth-RECV-Key) EMSK(0,31) = Peer to Authenticator Authentication Key (Auth-RECV-Key)
skipping to change at page 68, line 4 skipping to change at page 70, line 6
AAA-Key(32,63)= Authenticator to Peer Encryption Key (Enc-SEND-Key) AAA-Key(32,63)= Authenticator to Peer Encryption Key (Enc-SEND-Key)
(MS-MPPE-Send-Key in [RFC2548]) (MS-MPPE-Send-Key in [RFC2548])
EMSK(0,31) = Peer to Authenticator Authentication Key (Auth-RECV-Key) EMSK(0,31) = Peer to Authenticator Authentication Key (Auth-RECV-Key)
EMSK(32,63) = Authenticator to Peer Authentication Key (Auth-Send-Key) EMSK(32,63) = Authenticator to Peer Authentication Key (Auth-Send-Key)
IV(0,31) = Peer to Authenticator Initialization Vector (RECV-IV) IV(0,31) = Peer to Authenticator Initialization Vector (RECV-IV)
IV(32,63) = Authenticator to Peer Initialization vector (SEND-IV) IV(32,63) = Authenticator to Peer Initialization vector (SEND-IV)
Where: Where:
AAA-Key(W,Z) = Octets W through Z includes of the AAA-Key. AAA-Key(W,Z) = Octets W through Z includes of the AAA-Key.
IV(W,Z) = Octets W through Z inclusive of the IV. IV(W,Z) = Octets W through Z inclusive of the IV.
MSK(W,Z) = Octets W through Z inclusive of the MSK. MSK(W,Z) = Octets W through Z inclusive of the MSK.
EMSK(W,Z) = Octets W through Z inclusive of the EMSK. EMSK(W,Z) = Octets W through Z inclusive of the EMSK.
MK = TLS master_secret TMS = TLS master_secret
TLS-PRF-X = TLS PRF function defined in [RFC2246] computed to X octets TLS-PRF-X = TLS PRF function defined in [RFC2246] computed to X octets
client.random = Nonce generated by the TLS client. client.random = Nonce generated by the TLS client.
server.random = Nonce generated by the TLS server. server.random = Nonce generated by the TLS server.
Figure C-1 describes the process by which the MSK,EMSK,IV and Figure C-1 describes the process by which the MSK,EMSK,IV and
ultimately the TSKs, are derived from the MK. Note that in [RFC2716], ultimately the TSKs, are derived from the TLS Master Secret.
the MK is referred to as the "TLS Master Secret".
---+ ---+
| ^ | ^
| TLS Master Secret (MK) | | TLS Master Secret (TMS) |
| | | |
V | V |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | EAP | | | EAP |
| Master Session Key (MSK) | Method | | Master Session Key (MSK) | Method |
| Derivation | | | Derivation | |
| | V | | V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ EAP ---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ EAP ---+
| | | API ^ | | | API ^
| MSK | EMSK | IV | | MSK | EMSK | IV |
skipping to change at page 69, line 5 skipping to change at page 71, line 5
V V V V V V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | ^ | | ^
| Ciphersuite-Specific Transient Session | Auth.| | Ciphersuite-Specific Transient Session | Auth.|
| Key Derivation | | | Key Derivation | |
| | V | | V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
Figure C-1 - EAP TLS [RFC2716] Key hierarchy Figure C-1 - EAP TLS [RFC2716] Key hierarchy
Appendix D - 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 [IEEE80211i], 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))
skipping to change at page 70, line 5 skipping to change at page 72, line 5
TKIP uses X = 64, while CCMP, WRAP, and WEP use X = 48. TKIP uses X = 64, while CCMP, WRAP, and WEP use X = 48.
The EAPOL-Key Confirmation Key (KCK) is used to provide data origin The EAPOL-Key Confirmation Key (KCK) is used to provide data origin
authenticity in the TSK derivation. It utilizes the first 128 bits authenticity in the TSK derivation. It utilizes the first 128 bits
(bits 0-127) of the PTK. The EAPOL-Key Encryption Key (KEK) provides (bits 0-127) of the PTK. The EAPOL-Key Encryption Key (KEK) provides
confidentiality in the TSK derivation. It utilizes bits 128-255 of confidentiality in the TSK derivation. It utilizes bits 128-255 of
the PTK. Bits 256-383 of the PTK are used by Temporal Key 1, and Bits the PTK. Bits 256-383 of the PTK are used by Temporal Key 1, and Bits
384-511 are used by Temporal Key 2. Usage of TK1 and TK2 is 384-511 are used by Temporal Key 2. Usage of TK1 and TK2 is
ciphersuite specific. Details are available in [IEEE80211i]. ciphersuite specific. Details are available in [IEEE80211i].
Appendix E - AAA-Key Derivation Appendix E - Key Names and Scope in Existing Methods
Where a AAA-Key is generated as the result of a successful EAP
authentication, the AAA-Key is set to 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 multiple
authenticators in order to facilitate fast handoff, it is highly
desirable for the keying material used on different authenticators 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 EMSK, can be
used to provide cryptographically separate keying material for use in
fast handoff:
AAA-Key-A = MSK(0,63)
AAA-Key-B = PRF(EMSK(0,63),"EAP AAA-Key derivation for
multiple attachments", AAA-Key-A,B-Called-Station-Id,
Calling-Station-Id,length)
AAA-Key-E = PRF(EMSK(0,63),"EAP AAA-Key derivation for
multiple attachments",AAA-Key-A,E-Called-Station-Id,
Calling-Station-Id, length)
Where:
Calling-Station-Id = STA MAC address
B-Called-Station-Id = AP B MAC address
E-Called-Station-Id = AP E MAC address
PRF = Some suitable pseudo-random function
length = length of derived key material
Here AAA-Key-A is the AAA-Key derived during the initial EAP
authentication between the peer and authenticator A. Based on this
initial EAP authentication, the EMSK is also derived, which can be
used to derive AAA-Keys for fast authentication between the EAP peer
and authenticators B and E. Since the EMSK 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).
Appendix F - AMSK Key Derivation
The EAP AMSK key derivation function (KDF) derives an AMSK from the This appendix specifies the key names and scope in methods that have
Extended Master Session Key (EMSK), an application key label, been published prior to the publication of this RFC. What is needed
optional application data, and output length. 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
are encoded.
AMSK = KDF(EMSK, key label, optional application data, length) EAP-TLS
The key labels are printable ASCII strings unique for each The EAP-TLS Method-Id is provided by the concatenation of the peer
application (see Section 7 for IANA Considerations). and server nonces.
Additional ciphering keys (TSKs) can be derived from the AMSK using Where certificates are used, the Session-Id scope is determined via
an application specific key derivation mechanism. In many cases, this the EAP peer and server names, deduced from the altSubjectName in the
AMSK->TSK derivation can simply split the AMSK to pieces of correct peer and server certificates.
length. In particular, it is not necessary to use a cryptographic
one-way function. Note that the length of the AMSK must be specified
by the application.
F.1 The EAP AMSK Key Derivation Function Issue: What happens if a pre-shaked key ciphersuite is negotiated?
How are the EAP peer and server names determined?
The EAP key derivation function is taken from the PRF+ key expansion EAP-AKA
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 The EAP-AKA Method-Id is the contents of the RAND field from the
EMSK, the label is the key label described above concatenated with a AT_RAND attribute, followed by the contents of the AUTN field in the
NUL byte, the application data is also described above and the output AT_AUTN attribute.
length is two bytes. The application data is optional and may not be
used by some applications. The KDF is based on HMAC-SHA1 [RFC2104]
[SHA1]. For this specification we have:
KDF (K,L,D,O) = T1 | T2 | T3 | T4 | ... The EAP peer name is the contents of the Identity field from the
AT_IDENTITY attribute, using only the Actual Identity Length octets
from the beginning, however. Note that the contents are used as they
are transmitted, regardless of whether the transmitted identity was a
permanent, pseudonym, or fast reauthentication identity. The EAP
server name is an empty string.
where: EAP-SIM
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 The Method-Id is the contents of the RAND field from the AT_RAND
K = EMSK attribute, followed by the contents of the NONCE_MT field in the
L = key label AT_NONCE_MT attribute.
D = application data
O = OutputLength (2 bytes)
S = L | " " | D | O
The prf+ construction was chosen because of its simplicity and The EAP peer name is the contents of the Identity field from the
efficiency over other PRFs such as those used in [TLS]. The AT_IDENTITY attribute, using only the Actual Identity Length octets
motivation for the design of this PRF is described in [SIGMA]. from the beginning, however. Note that the contents are used as they
are transmitted, regardless of whether the transmitted identity was a
permanent, pseudonym, or fast reauthentication identity. The EAP
server name is an empty string.
The NUL byte after the key label is used to avoid collisions if one INTERNET-DRAFT EAP Key Manageme
key label is a prefix of another label (e.g. "foobar" and nt Framework 14 November 2004
"foobarExtendedV2"). This is considered a simpler solution than
requiring a key label assignment policy that prevents prefixes from
occurring.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
skipping to change at page 72, line 35 skipping to change at page 73, line 30
obtain a general license or permission for the use of such obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat. be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
Full Copyright Statement Disclaimer of Validity
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and the information contained herein are provided on an
others, and derivative works that comment on or otherwise explain it "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
or assist in its implementation may be prepared, copied, published OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
and distributed, in whole or in part, without restriction of any ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
kind, provided that the above copyright notice and this paragraph are INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
included on all such copies and derivative works. However, this INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English. The limited permissions granted above are perpetual and
will not be revoked by the Internet Society or its successors or
assigns. This document and the information contained herein is
provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Open Issues Open Issues
Open issues relating to this specification are tracked on the Open issues relating to this specification are tracked on the
following web site: following web site:
http://www.drizzle.com/~aboba/EAP/eapissues.html http://www.drizzle.com/~aboba/EAP/eapissues.html
Expiration Date
This memo is filed as <draft-ietf-eap-keying-03.txt>, and expires
January 5, 2005.
 End of changes. 

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