draft-ietf-eap-keying-09.txt   draft-ietf-eap-keying-10.txt 
EAP Working Group Bernard Aboba EAP Working Group Bernard Aboba
INTERNET-DRAFT Dan Simon INTERNET-DRAFT Dan Simon
Category: Standards Track Microsoft Category: Standards Track Microsoft
<draft-ietf-eap-keying-09.txt> J. Arkko <draft-ietf-eap-keying-10.txt> J. Arkko
8 January 2006 Ericsson 5 March 2006 Ericsson
P. Eronen P. Eronen
Nokia Nokia
H. Levkowetz, Ed. H. Levkowetz, Ed.
ipUnplugged ipUnplugged
Extensible Authentication Protocol (EAP) Key Management Framework Extensible Authentication Protocol (EAP) Key Management Framework
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
skipping to change at page 2, line 14 skipping to change at page 2, line 14
Table of Contents Table of Contents
1. Introduction .......................................... 3 1. Introduction .......................................... 3
1.1 Requirements Language ........................... 3 1.1 Requirements Language ........................... 3
1.2 Terminology ..................................... 3 1.2 Terminology ..................................... 3
1.3 Overview ........................................ 5 1.3 Overview ........................................ 5
1.4 EAP Invariants .................................. 9 1.4 EAP Invariants .................................. 9
2. Lower Layer Operation ................................. 12 2. Lower Layer Operation ................................. 12
2.1 Overview ........................................ 12 2.1 Overview ........................................ 12
2.2 Layering ........................................ 13 2.2 Layering ........................................ 14
2.3 Transient Session Keys .......................... 15 2.3 Transient Session Keys .......................... 16
2.4 Key Scope ....................................... 18 2.4 Authenticator Architecture ...................... 19
3. Key Management ........................................ 22 2.5 Key Scope ....................................... 22
3.1 Secure Association Protocol ..................... 22 3. Key Management ........................................ 24
3.2 Parent-Child Relationships ...................... 25 3.1 Secure Association Protocol ..................... 24
3.3 Local Key Lifetimes ............................. 26 3.2 Parent-Child Relationships ...................... 27
3.4 Exported and Calculated Key Lifetimes ........... 26 3.3 Local Key Lifetimes ............................. 27
3.5 Key Cache Synchronization ....................... 28 3.4 Exported and Calculated Key Lifetimes ........... 28
3.6 Key Strength .................................... 28 3.5 Key Cache Synchronization ....................... 29
3.7 Key Wrap ........................................ 29 3.6 Key Strength .................................... 30
4. Handoff Vulnerabilities ............................... 30 3.7 Key Wrap ........................................ 31
4.1 Authorization ................................... 30 4. Handoff Vulnerabilities ............................... 31
4.2 Correctness ..................................... 31 4.1 Authorization ................................... 32
5. Security Considerations .............................. 34 4.2 Correctness ..................................... 33
5.1 Security Terminology ............................ 35 5. Security Considerations .............................. 36
5.2 Threat Model .................................... 35 5.1 Security Terminology ............................ 36
5.3 Authenticator Compromise ........................ 36 5.2 Threat Model .................................... 36
5.4 Spoofing ........................................ 37 5.3 Authenticator Compromise ........................ 37
5.5 Downgrade Attacks ............................... 37 5.4 Spoofing ........................................ 38
5.6 Unauthorized Disclosure ......................... 38 5.5 Downgrade Attacks ............................... 39
5.7 Replay Protection ............................... 40 5.6 Unauthorized Disclosure ......................... 39
5.8 Key Freshness ................................... 40 5.7 Replay Protection ............................... 41
5.9 Elevation of Privilege .......................... 41 5.8 Key Freshness ................................... 42
5.10 Man-in-the-Middle Attacks ....................... 42 5.9 Elevation of Privilege .......................... 43
5.11 Denial of Service Attacks ....................... 43 5.10 Man-in-the-Middle Attacks ....................... 44
5.12 Impersonation ................................... 43 5.11 Denial of Service Attacks ....................... 44
5.13 Channel Binding ................................. 44 5.12 Impersonation ................................... 45
6. IANA Considerations ................................... 45 5.13 Channel Binding ................................. 46
7. References ............................................ 45 6. IANA Considerations ................................... 47
7.1 Normative References ............................ 45 7. References ............................................ 47
7.2 Informative References .......................... 46 7.1 Normative References ............................ 47
Acknowledgments .............................................. 50 7.2 Informative References .......................... 47
Author's Addresses ........................................... 50 Acknowledgments .............................................. 52
Appendix A - EAP-TLS Key Hierarchy ........................... 52 Author's Addresses ........................................... 53
Appendix B - Exported Parameters in Existing Methods ......... 53 Appendix A - Exported Parameters in Existing Methods ......... 54
Intellectual Property Statement .............................. 55 Intellectual Property Statement .............................. 55
Disclaimer of Validity ....................................... 56 Disclaimer of Validity ....................................... 56
Copyright Statement .......................................... 56 Copyright Statement .......................................... 56
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
skipping to change at page 5, line 19 skipping to change at page 5, line 19
Transient EAP Keys (TEKs) Transient EAP Keys (TEKs)
Session keys which are used to establish a protected channel Session keys which are used to establish a protected channel
between the EAP peer and server during the EAP authentication between the EAP peer and server during the EAP authentication
exchange. The TEKs are appropriate for use with the ciphersuite exchange. The TEKs are appropriate for use with the ciphersuite
negotiated between EAP peer and server for use in protecting the negotiated between EAP peer and server for use in protecting the
EAP conversation. The TEKs are stored locally by the EAP method EAP conversation. The TEKs are stored locally by the EAP method
and are not exported. Note that the ciphersuite used to set up the and are not exported. Note that the ciphersuite used to set up the
protected channel between the EAP peer and server during EAP protected channel between the EAP peer and server during EAP
authentication is unrelated to the ciphersuite used to subsequently authentication is unrelated to the ciphersuite used to subsequently
protect data sent between the EAP peer and authenticator. An protect data sent between the EAP peer and authenticator.
example TEK key hierarchy is described in Appendix A.
Transient Session Keys (TSKs) Transient Session Keys (TSKs)
Session keys used to protect data exchanged after EAP Session keys used to protect data exchanged after EAP
authentication has successfully completed, using the ciphersuite authentication has successfully completed, using the ciphersuite
negotiated between the EAP peer and authenticator. negotiated between the EAP peer and authenticator.
AAA-Key AAA-Key
The term AAA-Key is synonymous with MSK. The term AAA-Key is synonymous with MSK.
1.3. Overview 1.3. Overview
skipping to change at page 6, line 27 skipping to change at page 6, line 26
least 64 octets in length. EAP methods also may export the IV; least 64 octets in length. EAP methods also may export the IV;
however, the use of the IV is deprecated. however, the use of the IV is deprecated.
EAP methods also MAY export method-specific peer and server EAP methods also MAY export method-specific peer and server
identifiers (peer-ID and server-ID), a method-specific EAP identifiers (peer-ID and server-ID), a method-specific EAP
conversation identifier known as the Method-ID, and the lifetime of conversation identifier known as the Method-ID, and the lifetime of
the exported keys, known as the Key-Lifetime. EAP methods MAY also the exported keys, known as the Key-Lifetime. EAP methods MAY also
support the import and export of Channel Bindings. New EAP method support the import and export of Channel Bindings. New EAP method
specifications MUST define the Peer-ID, Server-ID and Method-ID. The specifications MUST define the Peer-ID, Server-ID and Method-ID. The
combination of the Peer-ID and Server-ID uniquely specifies the combination of the Peer-ID and Server-ID uniquely specifies the
endpoints of the EAP method exchange. endpoints of the EAP method exchange when they are provided.
Peer-ID Peer-ID
As described in [RFC3748] Section 7.3, the identity provided in the As described in [RFC3748] Section 7.3, the identity provided in the
EAP-Response/Identity, may be different from the peer identity EAP-Response/Identity, may be different from the peer identity
authenticated by the EAP method. Where the EAP method authenticates authenticated by the EAP method. Where the EAP method authenticates
the peer identity, that identity is exported by the method as the the peer identity, that identity is exported by the method as the
Peer-ID. A suitable EAP peer name may not always be available. Peer-ID. A suitable EAP peer name may not always be available.
Where an EAP method does not define a method-specific peer identity, Where an EAP method does not define a method-specific peer identity,
the Peer-ID is the null string. The Peer-ID for existing EAP the Peer-ID is the null string. The Peer-ID for existing EAP
methods is defined in Appendix B. methods is defined in Appendix A.
Server-ID Server-ID
Where the EAP method authenticates the server identity, that identity Where the EAP method authenticates the server identity, that identity
is exported by the method as the Server-ID. A suitable EAP server is exported by the method as the Server-ID. A suitable EAP server
name may not always be available. Where an EAP method does not name may not always be available. Where an EAP method does not
define a method-specific peer identity, the Server-ID is the null define a method-specific peer identity, the Server-ID is the null
string. The Server-ID for existing EAP methods is defined in string. The Server-ID for existing EAP methods is defined in
Appendix B. Appendix A.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | ^ | | ^
| EAP Method | | | EAP Method | |
| | | | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | |
| | | | | | | | | | | | | |
| | EAP Method Key |<->| Long-Term | | | | | EAP Method Key |<->| Long-Term | | |
| | Derivation | | Credential | | | | | Derivation | | Credential | | |
| | | | | | | | | | | | | |
skipping to change at page 7, line 46 skipping to change at page 7, line 46
Figure 1: EAP Method Parameter Import/Export Figure 1: EAP Method Parameter Import/Export
Method-ID Method-ID
EAP method specifications deriving keys MUST specify a temporally EAP method specifications deriving keys MUST specify a temporally
unique method identifier known as the Method-ID. The EAP Method-ID unique method identifier known as the Method-ID. The EAP Method-ID
uniquely identifies an EAP session of a given Type between an EAP uniquely identifies an EAP session of a given Type between an EAP
peer and server. The Method-ID is typically constructed from nonces peer and server. The Method-ID is typically constructed from nonces
or counters used within the EAP method exchange. The Method-ID for or counters used within the EAP method exchange. The Method-ID for
existing EAP methods is defined in Appendix B. existing EAP methods is defined in Appendix A.
Session-ID Session-ID
The Session-ID uniquely identifies an EAP session between an EAP peer The Session-ID uniquely identifies an EAP session between an EAP peer
(as identified by the Peer-ID) and server (as identified by the (as identified by the Peer-ID) and server (as identified by the
Server-ID). The EAP Session-ID consists of the concatenation of the Server-ID). The EAP Session-ID consists of the concatenation of the
Expanded EAP Type Code (including the Type, Vendor-ID and Vendor-Type Expanded EAP Type Code (including the Type, Vendor-ID and Vendor-Type
fields defined in [RFC3748] Section 5.7) and the Method-ID. The fields defined in [RFC3748] Section 5.7) and the Method-ID. The
inclusion of the Expanded Type Code in the EAP Session-Id ensures inclusion of the Expanded Type Code in the EAP Session-Id ensures
that each EAP method has a distinct Session-ID space. Since an EAP that each EAP method has a distinct Session-ID space. Since an EAP
skipping to change at page 12, line 47 skipping to change at page 12, line 47
takes place in three phases: takes place in three phases:
Phase 0: Discovery Phase 0: Discovery
Phase 1: Authentication Phase 1: Authentication
1a: EAP authentication 1a: EAP authentication
1b: AAA Key Transport (optional) 1b: AAA Key Transport (optional)
Phase 2: Secure Association Establishment Phase 2: Secure Association Establishment
2a: Unicast Secure Association 2a: Unicast Secure Association
2b: Multicast Secure Association (optional) 2b: Multicast Secure Association (optional)
Of these phases, Phase 0, 1b and Phase 2 are handled by a lower Of these phases, Phase 0, 1b and Phase 2 are handled external to EAP.
layer. In the discovery phase (phase 0), peers locate Phases 0 and 2 are handled by the lower layer protocol and phase 1b
authenticators and discover their capabilities. A peer may locate an is typically handled by a AAA protocol. In the discovery phase
authenticator providing access to a particular network, or a peer may (phase 0), peers locate authenticators and discover their
locate an authenticator behind a bridge with which it desires to capabilities. A peer may locate an authenticator providing access to
establish a Secure Association. Discovery can occur manually or a particular network, or a peer may locate an authenticator behind a
automatically, depending on the lower layer over which EAP runs. bridge with which it desires to establish a Secure Association.
Discovery can occur manually or automatically, depending on the lower
layer over which EAP runs.
The authentication phase (phase 1) may begin once the peer and The authentication phase (phase 1) may begin once the peer and
authenticator discover each other. This phase, if it occurs, always authenticator discover each other. This phase, if it occurs, always
includes EAP authentication (phase 1a). Where the chosen EAP method includes EAP authentication (phase 1a). Where the chosen EAP method
supports key derivation, in phase 1a EAP keying material is derived supports key derivation, in phase 1a EAP keying material is derived
on both the peer and the EAP server. on both the peer and the EAP server.
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 from the backend authentication server to the authenticator. material from the backend authentication server to the authenticator.
In order to obey the principle of Mode Independence, where a backend In order to obey the principle of Mode Independence, where a backend
server is present, all keying material which us required by the lower server is present, all keying material which is required by the lower
layer needs to be transported from the EAP server to the layer needs to be transported from the EAP server to the
authenticator. Since existing TSK derivation techniques depend authenticator. Since existing TSK derivation techniques depend
solely on the MSK, in existing implementations, this is the only solely on the MSK, in existing implementations, this is the only
keying material replicated in the AAA key transport phase 1b. keying material replicated in the AAA key transport phase 1b.
Successful completion of EAP authentication and key derivation by a Successful completion of EAP authentication and key derivation by a
peer and EAP server does not necessarily imply that the peer is peer and EAP server does not necessarily imply that the peer is
committed to joining the network associated with an EAP server. committed to joining the network associated with an EAP server.
Rather, this commitment is implied by the creation of a security Rather, this commitment is implied by the creation of a security
association between the EAP peer and authenticator, as part of the association between the EAP peer and authenticator, as part of the
Secure Association Protocol (phase 2). Secure Association Protocol (phase 2).
The Secure Association exchange (phase 2) occurs between the peer and The Secure Association exchange (phase 2) occurs between the peer and
authenticator in order to manage the creation and deletion of unicast authenticator in order to manage the creation and deletion of unicast
(phase 2a) and multicast (phase 2b) security associations between the (phase 2a) and multicast (phase 2b) security associations between the
peer and authenticator. The conversation between the parties is peer and authenticator. The conversation between the parties is
shown in Figure 2. shown in Figure 2.
Existing EAP lower layers implement phase 0, 2a and 2b in different
ways:
PPP PPP, defined in [RFC1661] does not support discovery, nor does it
include a Secure Association Protocol.
PPPOE
PPPOE, defined in [RFC2516], includes support for a Discovery stage
(phase 0). In this step, the EAP peer sends a PPPoE Active
Discovery Initiation (PADI) packet to the broadcast address,
indicating the service it is requesting. The Access Concentrator
replies with a PPPOE Active Discovery Offer (PADO) packet
containing its name, the service name and an indication of the
services offered by the concentrator. The discovery phase is not
secured. PPPOE, like PPP, does not include a Secure Association
Protocol.
IKEv2
IKEv2, defined in [RFC4306], handles the derivation of unicast
security associations (phase 2a), while the derivation of multicast
security associations (phase 2b) is handled in a separate group key
management protocol, as described in [RFC4046]. Several mechanisms
have been proposed for discovery of IPsec security gateways.
[RFC2230] discusses the use of KX Resource Records (RRs) for IPsec
gateway discovery; while KX RRs are supported by many DNS server
implementations, they have not yet been widely deployed.
Alternatively, DNS SRV [RFC2782] can be used for this purpose.
Where DNS is used for gateway location, DNS security mechanisms
such as DNSSEC ([RFC2535], [RFC2931]), TSIG [RFC2845], and Simple
Secure Dynamic Update [RFC3007] are available.
IEEE 802.11i
IEEE 802.11, defined in [IEEE-802.11], handles discovery via the
Beacon and Probe Request/Response mechanisms. IEEE 802.11 access
points periodically announce their Service Set Identifiers (SSIDs)
as well as capabilities using Beacon frames. Stations can query
for access points by sending a Probe Request to the broadcast
address. Neither Beacon nor Probe Request/Response frames are
secured. The 4-way handshake defined in [IEEE-802.11i] enables the
derivation of unicast (phase 2a) and multicast/broadcast (phase 2b)
secure associations. Since the group key exchange transports a
group key from the access point to the station, two 4-way
handshakes may be required in order to support peer-to-peer
communications.
IEEE 802.1X-2004
IEEE 802.1X-2004, defined in [IEEE-802.1X-2004] does not support
discovery (phase 0), nor does it provide for derivation of unicast
or multicast secure associations.
2.2. Layering 2.2. Layering
In completion of EAP authentication, EAP methods on the peer and EAP As illustrated in Figure 3, on completion of EAP authentication, EAP
server export the Master Session Key (MSK), Extended Master Session methods export the Master Session Key (MSK), Extended Master Session
Key (EMSK), Initialization Vector (IV), Peer-ID, Server-ID, Session- Key (EMSK), Peer-ID, Server-ID, Session-ID and Key-Lifetime to the
ID and Key-Lifetime. As illustrated in Figure 3, EAP methods export EAP peer or authenticator layers. The Initialization Vector (IV) is
keying material and parameters to the EAP peer or authenticator deprecated.
layers.
The EAP peer and authenticator layers MUST NOT modify or cache keying The EAP peer and authenticator layers MUST NOT modify or cache keying
material or parameters (including Channel Bindings) passing in either material or parameters (including Channel Bindings) passing in either
direction between the EAP method layer and the EAP layer. The EAP direction between the EAP method layer and the EAP layer. The EAP
layer also MUST NOT cache keying material or parameters (including layer also MUST NOT cache keying material or parameters (including
Channel Bindings) passed to it by the EAP peer/authenticator layer or Channel Bindings) passed to it, whether by the EAP peer/authenticator
the lower layer. layer, the lower layer or the AAA layer.
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 |
skipping to change at page 14, line 34 skipping to change at page 15, line 35
Figure 2: Conversation Overview Figure 2: Conversation Overview
Based on the Method-ID exported by the EAP method, the EAP layer Based on the Method-ID exported by the EAP method, the EAP layer
forms the EAP Session-ID by concatenating the EAP Expanded Type with forms the EAP Session-ID by concatenating the EAP Expanded Type with
the Method-ID. Together with the MSK, IV (deprecated), Peer-ID, the Method-ID. Together with the MSK, IV (deprecated), Peer-ID,
Server-ID, and Key-Lifetime, the EAP layer passes the Session-ID down Server-ID, and Key-Lifetime, the EAP layer passes the Session-ID down
to the lower layer. The Method-ID is exported by EAP methods rather to the lower layer. The Method-ID is exported by EAP methods rather
than the Session-ID so as to prevent EAP methods from writing into than the Session-ID so as to prevent EAP methods from writing into
each other's Session- ID space. each other's Session- ID space.
The EMSK MUST NOT be provided to the lower layer, nor is it permitted The EMSK MUST NOT be provided to an entity outside the EAP server or
to pass any quantity to the lower layer from which the EMSK could be peer, nor is it permitted to pass any quantity to an entity outside
computed without breaking some cryptographic assumption, such as the EAP server or peer from which the EMSK could be computed without
inverting a one-way function. As noted in [RFC3748] Section 7.10: breaking some cryptographic assumption, such as inverting a one-way
function. As noted in [RFC3748] Section 7.10:
The EMSK is reserved for future use and MUST remain on the EAP The EMSK is reserved for future use and MUST remain on the EAP
peer and EAP server where it is derived; it MUST NOT be peer and EAP server where it is derived; it MUST NOT be
transported to, or shared with, additional parties, or used to transported to, or shared with, additional parties, or used to
derive any other keys. (This restriction will be relaxed in a derive any other keys. (This restriction will be relaxed in a
future document that specifies how the EMSK can be used.) future document that specifies how the EMSK can be used.)
In order to preserve the security of keys derived within EAP methods, In order to preserve the security of keys derived within EAP methods,
lower layers other than AAA MUST NOT export keys passed down by EAP lower layers MUST NOT export keys passed down by EAP methods. This
methods. This implies that EAP keying material or parameters passed implies that EAP keying material or parameters passed down to a lower
down to a lower layer are for the exclusive use of that lower layer layer are for the exclusive use of that lower layer and MUST NOT be
and MUST NOT be used within another lower layer. This prevents used within another lower layer. This prevents compromise of one
compromise of one lower layer from compromising other applications lower layer from compromising other applications using EAP keying
using EAP keying parameters. parameters.
EAP keying material and parameters provided to a lower layer other EAP keying material and parameters provided to a lower layer MUST NOT
than AAA MUST NOT be transported to another entity. For example, EAP be transported to another entity. For example, EAP keying material
keying material and parameters passed down to the EAP peer lower and parameters passed down to the EAP peer lower layer MUST NOT leave
layer MUST NOT leave the peer; EAP keying material and parameters the peer; EAP keying material and parameters passed down or
passed down or transported to the EAP authenticator lower layer MUST transported to the EAP authenticator lower layer MUST NOT leave the
NOT leave the authenticator. authenticator.
The exception to the "no sharing" rule is the AAA layer. On EAP On the EAP server, keying material requested by and passed down to
server, keying material requested by and passed down to the AAA layer the AAA layer may be replicated to the AAA layer on the
may be replicated to the AAA layer on the authenticator. On the authenticator. On the authenticator, the AAA layer may provide the
authenticator, the AAA layer may provide the replicated keying replicated keying material to the lower layer over which the EAP
material to the lower layer over which the EAP authentication authentication conversation took place. This enables "mode
conversation took place. This enables "mode independence" to be independence" to be maintained. However, the EMSK MUST NOT be
maintained. transported by the AAA layer.
As illustrated in Figure 4, a AAA client receiving transported EAP As illustrated in Figure 4, a AAA client receiving transported EAP
keying material and parameters passes them to the EAP authenticator keying material and parameters passes them to the EAP authenticator
and EAP layers, which then provide them to the authenticator lower and EAP layers, which then provide them to the authenticator lower
layer using the same mechanisms that would be used if the EAP peer layer using the same mechanisms that would be used if the EAP peer
and authenticator were conducting a stand-alone conversation. The and authenticator were conducting a stand-alone conversation. The
resulting key state in the lower layer is indistinguishable between resulting key state in the lower layer is indistinguishable between
the standalone and pass-through cases, as required by the principle the standalone and pass-through cases, as required by the principle
of mode independence. of mode independence.
2.3. Transient Session Keys 2.3. Transient Session Keys
Where explicitly supported by the lower layer, lower layers MAY cache Where explicitly supported by the lower layer, lower layers MAY cache
the exported EAP keying material and parameters and/or TSKs. The the exported EAP keying material and parameters and/or TSKs. The
structure of this key cache is defined by the lower layer. So as to structure of this key cache is defined by the lower layer. So as to
enable interoperability, new lower layer specifications MUST enable interoperability, new lower layer specifications MUST
describe EAP key caching behavior. Unless explicitly specified by describe EAP key caching behavior. Unless explicitly specified by
the lower layer, the EAP peer, server and authenticator MUST assume the lower layer, the EAP peer, server and authenticator MUST assume
that peers and authenticators do not cache exported EAP keying that peers and authenticators do not cache exported EAP keying
parameters or TSKs. Existing EAP lower layers handle the caching of parameters or TSKs. Existing EAP lower layers and AAA layers handle
EAP keying material and the generation of transient session keys in the caching of EAP keying material and the generation of transient
different ways: session keys in different ways:
IEEE 802.1X-2004
IEEE 802.1X-2004, defined in [IEEE-802.1X-2004] does not support
caching of EAP keying material or parameters. Once EAP
authentication completes, it is assumed that EAP keying material
and parameters are discarded.
PPP PPP, defined in [RFC1661] does not support caching of EAP keying PPP PPP, defined in [RFC1661] does not support caching of EAP keying
material or parameters. PPP ciphersuites derive their TSKs material or parameters. PPP ciphersuites derive their TSKs
directly from the MSK, as described in [RFC2716]. This method is directly from the MSK, as described in [RFC2716]. This method is
NOT RECOMMENDED, since were PPP to support caching, this could NOT RECOMMENDED, since were PPP to support caching, this could
result in stale TSKs. As a result, once the PPP session is result in stale TSKs. As a result, once the PPP session is
terminated, EAP keying material and parameters MUST be discarded. terminated, EAP keying material and parameters MUST be discarded.
Since caching of EAP keying material is not permitted, within PPP Since caching of EAP keying material is not permitted, within PPP
there is no way to handle TSK rekey without EAP re-authentication. there is no way to handle TSK rekey without EAP re-authentication.
Perfect Forward Secrecy (PFS) is only possible within PPP if the Perfect Forward Secrecy (PFS) is only possible within PPP if the
skipping to change at page 16, line 31 skipping to change at page 17, line 39
+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+
| ! ! ! | | ! ! ! |
| EAP ! layer ! ! | | EAP ! layer ! ! |
| ! ! ! | | ! ! ! |
| ! Session-ID = ! ! | | ! Session-ID = ! ! |
| ! Expanded-Type || ! ! | | ! Expanded-Type || ! ! |
| ! Method-ID ! ! | | ! Method-ID ! ! |
| ! ! ! | | ! ! ! |
+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+
| ! ! ! | | ! ! ! |
| Lower ! layer ! ! | | Lower ! layer or AAA ! ! |
| ! ! ! | | ! ! ! |
| V V ^ | | V V ^ |
| MSK, Peer-ID, Channel Result | | MSK, Peer-ID, Channel Result |
| Server-ID, Bindings | | Server-ID, Bindings |
| Session-ID, | | Session-ID, |
| Key-Lifetime, | | Key-Lifetime, |
| IV (deprecated) | | IV (deprecated) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Flow of EAP parameters Figure 3: Flow of EAP parameters
skipping to change at page 17, line 32 skipping to change at page 18, line 32
|Lower layer| | Lower layer| AAA ! /IP | | AAA ! /IP | |Lower layer| | Lower layer| AAA ! /IP | | AAA ! /IP |
| | | | ! | | ! | | | | | ! | | ! |
+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+
! ! ! !
! ! ! !
+---------<-------+ +---------<-------+
Figure 4: Flow of EAP Keying Material and Parameters Figure 4: Flow of EAP Keying Material and Parameters
IKEv2 IKEv2
IKEv2, defined in [IKEv2] only uses EAP keying material for IKEv2, defined in [RFC4306] only uses the MSK for authentication
authentication purposes and not key derivation. As a result, the purposes and not key derivation. The EMSK, IV, Peer-ID, Server-ID
keying material derived within IKEv2 is independent of the EAP or Session-ID are not used. As a result, the keying material
keying material and rekey of IPsec SAs can be handled without derived within IKEv2 is independent of the EAP keying material and
requiring EAP re-authentiation. Since generation of keying rekey of IPsec SAs can be handled without requiring EAP re-
material is independent of EAP, within IKEv2 it is possible to authentication. Since generation of keying material is independent
negotiate PFS, regardless of the EAP method that is used. IKEv2 of EAP, within IKEv2 it is possible to negotiate PFS, regardless of
does not cache EAP keying material or parameters, nor does it the EAP method that is used. IKEv2 does not cache EAP keying
utilize the EAP Key-Lifetime parameter to determine the lifetime of material or parameters; once IKEv2 authentication completes it is
IPsec SAs. As a result, once IKEv2 authentication completes it is assumed that EAP keying material and parameters are discarded. The
assumed that EAP keying material and parameters are discarded. Session-Timeout attribute is therefore interpreted as a limit on
the VPN session time, rather than an indication of the MSK key
lifetime.
IEEE 802.11i IEEE 802.11i
IEEE 802.11i enables caching of the MSK, but not the EMSK, IV, IEEE 802.11i enables caching of the MSK, but not the EMSK, IV,
Peer-ID, Server-ID, or Session-ID. More details about the Peer-ID, Server-ID, or Session-ID. More details about the
structure of the cache are available in [IEEE-802.11i]. In IEEE structure of the cache are available in [IEEE-802.11i]. In IEEE
802.11i, TSKs are derived from the MSK using the 4-way handshake, 802.11i, TSKs are derived from the MSK using the 4-way handshake,
which includes a nonce exchange. This guarantees TSK freshness which includes a nonce exchange. This guarantees TSK freshness
even if the MSK is reused. The 4-way handshake also enables TSK even if the MSK is reused. The 4-way handshake also enables TSK
rekey without EAP re-authentication. PFS is only possible within rekey without EAP re-authentication. PFS is only possible within
IEEE 802.11i if the negotiated EAP method supports this. IEEE 802.11i if the negotiated EAP method supports this.
IEEE 802.1X-2004
IEEE 802.1X-2004, defined in [IEEE-802.1X-2004] does not support
caching of EAP keying material or parameters. Once EAP
authentication completes, it is assumed that EAP keying material
and parameters are discarded.
IEEE 802.16e IEEE 802.16e
IEEE 802.16e, defined in [IEEE-802.16e] supports caching of the IEEE 802.16e, defined in [IEEE-802.16e] supports caching of the
MSK, but not the EMSK, IV, Peer-ID, Server-ID or Session-ID. In MSK, but not the EMSK, IV, Peer-ID, Server-ID or Session-ID. In
IEEE 802.16e, TSKs are generated by the authenticator without any IEEE 802.16e, TSKs are generated by the authenticator without any
contribution by the peer. The TSKs are encrypted, authenticated contribution by the peer. The TSKs are encrypted, authenticated
and integrity protected using the MSK. As a result, TSK rekey is and integrity protected using the MSK. As a result, TSK rekey is
possible without EAP re-authentication. PFS is not possible even possible without EAP re-authentication. PFS is not possible even
if the negotiated EAP method supports it. if the negotiated EAP method supports it.
AAA Existing AAA implementations supporting RADIUS/EAP [RFC3579] or AAA Existing implementations of RADIUS/EAP [RFC3579] or Diameter EAP
Diameter EAP [RFC4072] do not support caching of EAP keying [RFC4072] do not support caching of EAP keying material or
material or parameters. In existing AAA client, proxy and server parameters. In existing AAA client, proxy and server
implementations, exported EAP keying material (MSK, EMSK and IV) as implementations, exported EAP keying material (MSK, EMSK and IV) as
well as parameters and derived keys are not cached and MUST be well as parameters and derived keys are not cached and MUST be
presumed lost after the AAA exchange completes. presumed lost after the AAA exchange completes.
In order to avoid key reuse, the AAA layer MUST delete transported In order to avoid key reuse, the AAA layer MUST delete transported
keys once they are sent. The AAA layer MUST NOT retain keys that keys once they are sent. The AAA layer MUST NOT retain keys that
it has previously sent. For example, a AAA layer that has it has previously sent. For example, a AAA layer that has
transported the MSK MUST delete it, and keys MUST NOT be derived transported the MSK MUST delete it, and keys MUST NOT be derived
from the MSK from that point forward. from the MSK from that point forward.
2.4. Key Scope 2.4. Authenticator Architecture
This specification does not impose constraints on the architecture of
the EAP authenticator or peer. Any of the authenticator
architectures described in [RFC4118] can be used. For example, it is
possible for multiple base stations and a "controller" (e.g. WLAN
switch) to comprise a single EAP authenticator. In such a situation,
the "base station identity" is irrelevant to the EAP method
conversation, except perhaps as an opaque blob to be used in Channel
Bindings. Many base stations can share the same authenticator
identity. As a result, lower layers need to identify EAP peers and
authenticators unambiguously, without incorporating implicit
assumptions about peer and authenticator architectures.
It should be understood that an EAP authenticator or peer: It should be understood that an EAP authenticator or peer:
[a] may contain one or more physical or logical ports; [a] may contain one or more physical or logical ports;
[b] may advertise itself as one or more "virtual" [b] may advertise itself as one or more "virtual"
authenticators or peers; authenticators or peers;
[c] may utilize multiple CPUs; [c] may utilize multiple CPUs;
[d] may support clustering services for load balancing or failover. [d] may support clustering services for load balancing or failover.
The issues that arise from this are discussed below.
2.4.1. Multiple Ports
Both the EAP peer and authenticator may have more than one physical Both the EAP peer and authenticator may have more than one physical
or logical port. A peer may simultaneously access the network via or logical port. A peer may simultaneously access the network via
multiple authenticators, or via multiple physical or logical ports on multiple authenticators, or via multiple physical or logical ports on
a given authenticator. Similarly, an authenticator may offer network a given authenticator. Similarly, an authenticator may offer network
access to multiple peers, each via a separate physical or logical access to multiple peers, each via a separate physical or logical
port. The situation is illustrated in Figure 5. port. When a single physical authenticator advertises itself as
multiple "virtual authenticators", it is possible for a single
physical port to belong to multiple "virtual authenticators". The
situation is illustrated in Figure 5.
+-+-+-+-+ +-+-+-+-+
| EAP | | EAP |
| Peer | | Peer |
+-+-+-+-+ +-+-+-+-+
| | | Peer Ports | | | Peer Ports
/ | \ / | \
/ | \ / | \
/ | \ / | \
/ | \ / | \
skipping to change at page 19, line 41 skipping to change at page 21, line 5
\ | / \ | /
\ | / \ | /
\ | / \ | /
+-+-+-+-+ +-+-+-+-+
| EAP | | EAP |
|Server | |Server |
+-+-+-+-+ +-+-+-+-+
Figure 5: Relationship between EAP peer, authenticator and server Figure 5: Relationship between EAP peer, authenticator and server
Absent explicit specification within the lower layer, EAP keying 2.4.1. Authenticator Identification
material and parameters are not bound to a specific peer or
authenticator port. Where the peer and authenticator identify
themselves within the lower layer using a port identifier such as a
link layer address, this creates a problem, because it may not be
obvious to the peer which authenticator ports are associated with
which authenticators. Similarly, it may not be obvious to the
authenticator which peer ports are associated with which peers. As a
result, the peer and authenticator may not be able to determine the
scope of the EAP keying material. This is particularly problematic
for lower layers where key caching is supported.
For example, where the EAP peer cannot identify the EAP The EAP method conversation is between the EAP peer and server, as
authenticator, it will be unable to determine whether EAP keying identified by the Peer-ID and Server-ID. The authenticator identity,
if considered at all by the EAP method, is treated as an opaque blob
for the purposes of Channel bindings. However, the Secure
Association Protocol conversation is between the peer and the
authenticator, and therefore the authenticator and peer identities
are relevant to that exchange, and define the scope of use of the EAP
keying material passed down to the lower layer.
Since an authenticator may have multiple ports, the authenticator
identifiers used within the Secure Association Protocol exchange
SHOULD be distinct from any port identifier (e.g. MAC address).
Similarly, where a peer may have multiple ports, and sharing of EAP
keying material and parameters between peer ports of the same link
type is allowed, the peer identifier used within the Secure
Association Protocol exchange SHOULD also be distinct from any port
identifier.
Where the peer and authenticator identify themselves within the lower
layer using a port identifier such as a link layer address, this
creates a number of problems:
[1] It may not be obvious to the peer which authenticator ports are
associated with which authenticators.
[2] It may not be obvious to the authenticator which peer ports are
associated with which peers.
[3] It may not be obvious to the peer which "virtual authenticator" it
is communicating with.
[4] It may not be obvious to the authenticator which "virtual peer" it
is communicating with.
AAA protocols such as RADIUS [RFC3579] and Diameter [RFC4072]
provide a mechanism for the identification of AAA clients; since
the EAP authenticator and AAA client are always co-resident, this
mechanism is applicable to the identification of EAP
authenticators.
RADIUS [RFC2865] requires that an Access-Request packet contain one
or more of the NAS-Identifier, NAS-IP-Address and NAS-IPv6-Address
attributes. Since a NAS may have more than one IP address, the
NAS-Identifier attribute is RECOMMENDED for the unambiguous
identification of the EAP authenticator.
From the point of view of the AAA server, EAP keying material and
parameters are transported to the EAP authenticator identified by
the NAS-Identifier attribute. Since an EAP authenticator MUST NOT
share EAP keying material or parameters with another party, if the
EAP peer or AAA server detects use of EAP keying material and
parameters outside the scope defined by the NAS-Identifier, the
keying material MUST be considered compromised.
2.5. Key Scope
Where the EAP peer and authenticator cannot unambiguously identify
each other they may not be able to determine the scope of transported
EAP keying material. This is particularly problematic for lower
layers where key caching is supported.
For example, if the EAP peer cannot identify the EAP authenticator,
it will be unable to determine whether transported EAP keying
material has been shared outside of its authorized scope, and material has been shared outside of its authorized scope, and
therefore needs to be considered compromised. There is also a therefore needs to be considered compromised. There is also a
practical problem because the EAP peer will be unable to utilize the practical problem because the EAP peer will be unable to utilize the
EAP authenticator key cache in an efficient way. EAP authenticator key cache in an efficient way.
The solution to this problem is for lower layers to identify EAP To avoid these problems, it is recomended that lower layers:
peers and authenticators unambiguously, without incorporating
implicit assumptions about peer and authenticator architectures. Use [1] Specify the lower layer parameters used to identify the
of port identifiers is NOT RECOMMENDED where peers and authenticators authenticator and peer;
may support multiple ports.
[2] Communicate the lower layer identities between the peer and
authenticator within phase 0;
[3] Communicate the lower layer authenticator identity between the
authenticator and backend server within the NAS-Identifier
attribute;
[4] Include the lower layer identities within channel bindings (if
supported) in phase 1a, ensuring that they are communicated between
the EAP peer and server;
[5] Securely verify the lower layer identities within phase 2a;
[6] Utilize the advertised lower layer identities to enable the peer
and authenticator to verify that keys are maintained within the
advertised scope;
Absent explicit specification within the lower layer, after the
completion of phase 1b, EAP keying material and parameters are
bound to the EAP peer and authenticator, but are not bound to a
specific peer or authenticator port.
While EAP Keying Material passed down to the lower layer is not
intrinsically bound to particular authenticator and peer ports,
Transient Session Keys MAY be bound to particular authenticator and
peer ports by the Secure Association Protocol. However, a lower
layer MAY also permit TSKs to be used on multiple peer and/or
authenticator ports, providing that TSK freshness is guaranteed
(such as by keeping replay counter state within the authenticator).
In order to further limit the key scope the following measures are In order to further limit the key scope the following measures are
suggested: suggested:
[a] The lower layer MAY specify additional restrictions on key usage, [a] The lower layer MAY specify additional restrictions on key usage,
such as limiting the use of EAP keying material and parameters on such as limiting the use of EAP keying material and parameters on
the EAP peer to the port over which on the EAP conversation was the EAP peer to the port over which on the EAP conversation was
conducted. conducted.
[b] The backend authentication server and authenticator MAY implement [b] The backend authentication server and authenticator MAY implement
skipping to change at page 20, line 39 skipping to change at page 23, line 34
authentication server may provide the authenticator with a list of authentication server may provide the authenticator with a list of
authorized Called or Calling-Station-Ids and/or SSIDs for which EAP authorized Called or Calling-Station-Ids and/or SSIDs for which EAP
keying material is valid. keying material is valid.
[c] Where the backend authentication server provides attributes [c] Where the backend authentication server provides attributes
restricting the key scope, it is RECOMMENDED that restrictions be restricting the key scope, it is RECOMMENDED that restrictions be
securely communicated by the authenticator to the peer. This can securely communicated by the authenticator to the peer. This can
be accomplished using the Secure Association Protocol, but also be accomplished using the Secure Association Protocol, but also
can be accomplished via the EAP method or the lower layer. can be accomplished via the EAP method or the lower layer.
2.4.2. Authenticator Architecture 2.5.1. Virtual Authenticators
The EAP method conversation is between the EAP peer and server, as
identified by the Peer-ID and Server-ID. The authenticator identity,
if considered at all by the EAP method, is treated as an opaque blob
for the purposes of Channel bindings. However, the Secure
Association Protocol conversation is between the peer and the
authenticator, and therefore the authenticator and peer identities
are relevant to that exchange, and define the scope of use of the EAP
keying material passed down to the lower layer.
Since an authenticator may have many ports, the authenticator
identifier used within the Secure Association Protocol exchange
SHOULD be distinct from any port identifier (e.g. MAC address).
Similarly, where a peer may have multiple ports, and sharing of EAP
keying material and parameters between peer ports of the same link
type is allowed, the peer identifier used within the Secure
Association Protocol exchange SHOULD also be distinct from any port
identifier.
While EAP Keying Material passed down to the lower layer is not
intrinsically bound to particular authenticator and peer ports,
Transient Session Keys MAY be bound to particular authenticator and
peer ports by the Secure Association Protocol. However, a lower
layer MAY also permit TSKs to be used on multiple peer and/or
authenticator ports, providing that TSK freshness is guaranteed (such
as by keeping replay counter state within the authenticator).
This specification does not impose constraints on the architecture of
the EAP authenticator or peer. Any of the authenticator
architectures described in [RFC4118] can be used. For example, it is
possible for multiple base stations and a "controller" (e.g. WLAN
switch) to comprise a single EAP authenticator. In such a situation,
the "base station identity" is irrelevant to the EAP method
conversation, except perhaps as an opaque blob to be used in Channel
Bindings. Many base stations can share the same authenticator
identity.
AAA protocols such as RADIUS [RFC3579] and Diameter [RFC4072] provide
a mechanism for the identification of AAA clients; since the EAP
authenticator and AAA client are always co-resident, this mechanism
is applicable to the identification of EAP authenticators.
RADIUS [RFC2865] requires that an Access-Request packet contain one
or more of the NAS-Identifier, NAS-IP-Address and NAS-IPv6-Address
attributes. Since a NAS may have more than one IP address, the NAS-
Identifier attribute is RECOMMENDED for the unambiguous
identification of the EAP authenticator.
From the point of view of the AAA server, EAP keying material and
parameters are transported to the EAP authenticator identified by the
NAS-Identifier attribute. Since an EAP authenticator MUST NOT share
EAP keying material or parameters with another party, if the EAP peer
or AAA server detects use of EAP keying material and parameters
outside the scope defined by the NAS-Identifier, the keying material
MUST be considered compromised.
2.4.3. Virtual Authenticators
When a single physical authenticator advertises itself as multiple When a single physical authenticator advertises itself as multiple
"virtual authenticators", the EAP peer and authenticator also may not "virtual authenticators", the EAP peer and authenticator may not be
be able to agree on the scope of the EAP keying material, creating a able to agree on the scope of the EAP keying material, creating a
security vulnerability. For example, the peer may assume that the security vulnerability. For example, the peer may assume that the
"virtual authenticators" are distinct and do not share a key cache, "virtual authenticators" are distinct and do not share a key cache,
whereas, depending on the architecture of the physical authenticator, whereas, depending on the architecture of the physical authenticator,
a shared key cache may or may not be implemented. a shared key cache may or may not be implemented.
Where EAP keying material is shared between "virtual authenticators" Where EAP keying material is shared between "virtual authenticators"
an attacker acting as a peer could authenticate with the "Guest" an attacker acting as a peer could authenticate with the "Guest"
"virtual authenticator" and derive EAP keying material. If the "virtual authenticator" and derive EAP keying material. If the
virtual authenticators share a key cache, then the peer can utilize virtual authenticators share a key cache, then the peer can utilize
the EAP keying material derived for the "Guest" network to obtain the EAP keying material derived for the "Guest" network to obtain
skipping to change at page 25, line 46 skipping to change at page 27, line 32
When keying material exported by EAP methods expires, all keying When keying material exported by EAP methods expires, all keying
material derived from the exported keying material expires, including material derived from the exported keying material expires, including
the TSKs. the TSKs.
When an EAP re-authentication takes place, new keying material is When an EAP re-authentication takes place, new keying material is
derived and exported by the EAP method, which eventually results in derived and exported by the EAP method, which eventually results in
replacement of calculated keys, including the TSKs. replacement of calculated keys, including the TSKs.
As a result, while the lifetime of calculated keys can be less than As a result, while the lifetime of calculated keys can be less than
or equal that of the exported keys they are derived from, it cannot or equal that of the exported keys they are derived from, it cannot
be greater. For example, TSK re-key may occur prior to EAP re- be greater. For example, when EAP re-authentication occurs, TSK re-
authentication. key will also occur. However, this does not prohibit TSK re-key from
occurring prior to expiration of the lifetime of exported keys. For
example, TSK re-key may occur prior to EAP re-authentication.
Failure to mutually prove possession of keying material during the Failure to mutually prove possession of keying material during the
Secure Association Protocol exchange need not be grounds for deletion Secure Association Protocol exchange need not be grounds for deletion
of the keying material by both parties; rate-limiting Secure of the keying material by both parties; rate-limiting Secure
Association Protocol exchanges could be used to prevent a brute force Association Protocol exchanges could be used to prevent a brute force
attack. attack.
3.3. Local Key Lifetimes 3.3. Local Key Lifetimes
The Transient EAP Keys (TEKs) are session keys used to protect the The Transient EAP Keys (TEKs) are session keys used to protect the
skipping to change at page 47, line 26 skipping to change at page 49, line 7
specifications: Specification for Enhanced Security", IEEE specifications: Specification for Enhanced Security", IEEE
802.11i, December 2004. 802.11i, December 2004.
[IEEE-802.11F] [IEEE-802.11F]
Institute of Electrical and Electronics Engineers, Institute of Electrical and Electronics Engineers,
"Recommended Practice for Multi-Vendor Access Point "Recommended Practice for Multi-Vendor Access Point
Interoperability via an Inter-Access Point Protocol Across Interoperability via an Inter-Access Point Protocol Across
Distribution Systems Supporting IEEE 802.11 Operation", IEEE Distribution Systems Supporting IEEE 802.11 Operation", IEEE
802.11F, July 2003 (now deprecated). 802.11F, July 2003 (now deprecated).
[IEEE-802.16e]
Institute of Electrical and Electronics Engineers, "IEEE
Standard for Local and Metropolitan Area Networks: Part 16:
Air Interface for Fixed and Mobile Broadband Wireless Access
Systems: Amendment for Physical and Medium Access Control
Layers for Combined Fixed and Mobile Operations in Licensed
Bands" IEEE 802.16e, August 2005.
[IEEE-02-758] [IEEE-02-758]
Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang,
"Proactive Caching Strategies for IAPP Latency Improvement "Proactive Caching Strategies for IAPP Latency Improvement
during 802.11 Handoff", IEEE 802.11 Working Group, during 802.11 Handoff", IEEE 802.11 Working Group,
IEEE-02-758r1-F Draft 802.11I/D5.0, November 2002. IEEE-02-758r1-F Draft 802.11I/D5.0, November 2002.
[IEEE-03-084] [IEEE-03-084]
Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang,
"Proactive Key Distribution to support fast and secure "Proactive Key Distribution to support fast and secure
roaming", IEEE 802.11 Working Group, IEEE-03-084r1-I, roaming", IEEE 802.11 Working Group, IEEE-03-084r1-I,
skipping to change at page 48, line 19 skipping to change at page 50, line 9
[I-D.arkko-eap-service-identity-auth] [I-D.arkko-eap-service-identity-auth]
Arkko, J. and P. Eronen, "Authenticated Service Information Arkko, J. and P. Eronen, "Authenticated Service Information
for the Extensible Authentication Protocol (EAP)", draft- for the Extensible Authentication Protocol (EAP)", draft-
arkko-eap-service-identity-auth-02.txt (work in progress), May arkko-eap-service-identity-auth-02.txt (work in progress), May
2005. 2005.
[I-D.ohba-eap-aaakey-binding] [I-D.ohba-eap-aaakey-binding]
Ohba, Y., "AAA-Key Derivation with Channel Binding", draft- Ohba, Y., "AAA-Key Derivation with Channel Binding", draft-
ohba-eap-aaakey-binding-00.txt (work in progress), May 2005. ohba-eap-aaakey-binding-00.txt (work in progress), May 2005.
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", draft-
ietf-ipsec-ikev2-17 (work in progress), September 2004.
[MD5Attack] [MD5Attack]
Dobbertin, H., "The Status of MD5 After a Recent Attack", Dobbertin, H., "The Status of MD5 After a Recent Attack",
CryptoBytes, Vol.2 No.2, 1996. CryptoBytes, Vol.2 No.2, 1996.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981. September 1981.
[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.
skipping to change at page 49, line 9 skipping to change at page 50, line 45
[RFC2419] Sklower, K. and G. Meyer, "The PPP DES Encryption Protocol, [RFC2419] Sklower, K. and G. Meyer, "The PPP DES Encryption Protocol,
Version 2 (DESE-bis)", RFC 2419, September 1998. Version 2 (DESE-bis)", RFC 2419, September 1998.
[RFC2420] Kummert, H., "The PPP Triple-DES Encryption Protocol (3DESE)", [RFC2420] Kummert, H., "The PPP Triple-DES Encryption Protocol (3DESE)",
RFC 2420, September 1998. RFC 2420, September 1998.
[RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D. and [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D. and
R. Wheeler, "A Method for Transmitting PPP Over Ethernet R. Wheeler, "A Method for Transmitting PPP Over Ethernet
(PPPoE)", RFC 2516, February 1999. (PPPoE)", RFC 2516, February 1999.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC
2548, March 1999. 2548, March 1999.
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
Implementation in Roaming", RFC 2607, June 1999. Implementation in Roaming", RFC 2607, June 1999.
[RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol", [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol",
RFC 2716, October 1999. RFC 2716, October 1999.
[RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
"Secret Key Transaction Authentication for DNS (TSIG)", RFC
2845, May 2000.
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, June Authentication Dial In User Service (RADIUS)", RFC 2865, June
2000. 2000.
[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (SIG(0)s
)", RFC 2931, September 2000.
[RFC3007] Wellington, B., "Simple Secure Domain Name System (DNS)
Dynamic Update", RFC 3007, November 2000.
[RFC3078] Pall, G. and G. Zorn, "Microsoft Point-To-Point Encryption [RFC3078] Pall, G. and G. Zorn, "Microsoft Point-To-Point Encryption
(MPPE) Protocol", RFC 3078, March 2001. (MPPE) Protocol", RFC 3078, March 2001.
[RFC3079] Zorn, G., "Deriving Keys for use with Microsoft Point-to-Point [RFC3079] Zorn, G., "Deriving Keys for use with Microsoft Point-to-Point
Encryption (MPPE)", RFC 3079, March 2001. Encryption (MPPE)", RFC 3079, March 2001.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial
In User Service) Support For Extensible Authentication In User Service) Support For Extensible Authentication
Protocol (EAP)", RFC 3579, September 2003. Protocol (EAP)", RFC 3579, September 2003.
skipping to change at page 49, line 49 skipping to change at page 52, line 5
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public
Keys Used For Exchanging Symmetric Keys", RFC 3766, April Keys Used For Exchanging Symmetric Keys", RFC 3766, April
2004. 2004.
[RFC4005] Calhoun, P., Zorn, G., Spence, D. and D. Mitton, "Diameter [RFC4005] Calhoun, P., Zorn, G., Spence, D. and D. Mitton, "Diameter
Network Access Server Application", RFC 4005, August 2005. Network Access Server Application", RFC 4005, August 2005.
[RFC4017] Stanley, D., Walker, J. and B. Aboba, "EAP Method Requirements [RFC4017] Stanley, D., Walker, J. and B. Aboba, "EAP Method Requirements
for Wireless LANs", RFC 4017, March 2005. for Wireless LANs", RFC 4017, March 2005.
[RFC4046] Baugher, M., Canetti, R., Dondeti, L. and F. Lindholm,
"Multicast Security (MSEC) Group Key Management Architecture",
RFC 4046, April 2005.
[RFC4072] Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible [RFC4072] Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application", RFC 4072, August Authentication Protocol (EAP) Application", RFC 4072, August
2005. 2005.
[RFC4118] Yang, L., Zerfos, P. and E. Sadot, "Architecture Taxonomy for [RFC4118] Yang, L., Zerfos, P. and E. Sadot, "Architecture Taxonomy for
Control and Provisioning of Wireless Access Points (CAPWAP)", Control and Provisioning of Wireless Access Points (CAPWAP)",
RFC 4118, June 2005. RFC 4118, June 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
4306, December 2005.
[8021XHandoff] [8021XHandoff]
Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff in a Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff in a
Public Wireless LAN Based on IEEE 802.1X Model", School of Public Wireless LAN Based on IEEE 802.1X Model", School of
Computer Science and Engineering, Seoul National University, Computer Science and Engineering, Seoul National University,
Seoul, Korea, 2002. Seoul, Korea, 2002.
Acknowledgments Acknowledgments
Thanks to Arun Ayyagari, Ashwin Palekar, and Tim Moore of Microsoft, Thanks to Arun Ayyagari, Ashwin Palekar, and Tim Moore of Microsoft,
Dorothy Stanley of Agere, Bob Moskowitz of TruSecure, Jesse Walker of Dorothy Stanley of Agere, Bob Moskowitz of TruSecure, Jesse Walker of
skipping to change at page 52, line 5 skipping to change at page 54, line 5
Henrik Levkowetz (editor) Henrik Levkowetz (editor)
ipUnplugged AB ipUnplugged AB
Arenavagen 27 Arenavagen 27
Stockholm S-121 28 Stockholm S-121 28
SWEDEN SWEDEN
Phone: +46 708 32 16 08 Phone: +46 708 32 16 08
EMail: henrik@levkowetz.com EMail: henrik@levkowetz.com
Appendix A - EAP-TLS Key Hierarchy Appendix A - Exported Parameters in Existing Methods
EAP-TLS [RFC 2716] was documented prior to the development of EAP key
management terminology [RFC3748], and therefore does not explicitly
define the MSK and EMSK.
In EAP-TLS, the MSK, EMSK and IV are derived from the TLS master
secret via a one-way function. This ensures that the TLS master
secret cannot be derived from the MSK, EMSK or IV unless the one-way
function (TLS PRF) is broken. Since the MSK is derived from the the
TLS master secret, if the TLS master secret is compromised then the
MSK is also compromised.
[RFC2716] specifies that the MSK is divided into two halves,
corresponding to the "Peer to Authenticator Encryption Key" (Enc-
RECV-Key, 32 octets) and "Authenticator to Peer Encryption Key" (Enc-
SEND-Key, 32 octets). In [RFC2548], the Enc-RECV-Key is transported
in the MS-MPPE-Recv-Key attribute, and the Enc-SEND-Key is
transported in the MS-MPPE-Send- Key attribute.
The EMSK is also divided into two halves, corresponding to the "Peer
to Authenticator Authentication Key" (Auth-RECV-Key, 32 octets) and
"Authenticator to Peer Authentication Key" (Auth-SEND-Key, 32
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
Octets 32-63 are known as the "Authenticator to Peer IV", or SEND-IV.
The key derivation scheme MUST be interpreted as follows:
MSK = TLS-PRF-64(TMS, "client EAP encryption",
client.random || server.random)
EMSK = second 64 octets of:
TLS-PRF-128(TMS, "client EAP encryption",
client.random || server.random)
IV = TLS-PRF-64("", "client EAP encryption",
client.random || server.random)
MSK(0,31) = Peer to Authenticator Encryption Key (Enc-RECV-Key)
(MS-MPPE-Recv-Key in [RFC2548]). Also known as the
PMK.
MSK(32,63) = Authenticator to Peer Encryption Key (Enc-SEND-Key)
(MS-MPPE-Send-Key in [RFC2548])
EMSK(0,31) = Peer to Authenticator Authentication Key (Auth-RECV-Key)
EMSK(32,63) = Authenticator to Peer Authentication Key (Auth-Send-Key)
IV(0,31) = Peer to Authenticator Initialization Vector (RECV-IV)
IV(32,63) = Authenticator to Peer Initialization vector (SEND-IV)
Where:
IV(W,Z) = Octets W through Z inclusive of the IV.
MSK(W,Z) = Octets W through Z inclusive of the MSK.
EMSK(W,Z) = Octets W through Z inclusive of the EMSK.
TMS = TLS master_secret
TLS-PRF-X = TLS PRF function defined in [RFC2246] computed to X octets
client.random = Nonce generated by the TLS client.
server.random = Nonce generated by the TLS server.
Figure A-1 illustrates the TEK key hierarchy for EAP-TLS [RFC2716],
which is based on the TLS key hierarchy described in [RFC2246]. The
TLS-negotiated ciphersuite is used to set up a protected channel for
use in protecting the EAP conversation, keyed by the derived TEKs.
The TEK derivation proceeds as follows:
master_secret = TLS-PRF-48(pre_master_secret, "master secret",
client.random || server.random)
TEK = TLS-PRF-X(master_secret, "key expansion",
server.random || client.random)
Where:
TLS-PRF-X = TLS pseudo-random function defined in [RFC2246],
computed to X octets.
| | pre_master_secret |
server| | | client
Random| V | Random
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
+---->| master_secret |<------+
| | (TMS) | |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | |
V V V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Key Block (TEKs) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| client | server | client | server | client | server
| MAC | MAC | write | write | IV | IV
| | | | | |
V V V V V V
Figure A-1 - TLS [RFC2246] Key Hierarchy
Appendix B - Exported Parameters in Existing Methods
This Appendix specifies Method-ID, Peer-ID, Server-ID and Key- This Appendix specifies Method-ID, Peer-ID, Server-ID and Key-
Lifetime for EAP methods that have been published prior to this Lifetime for EAP methods that have been published prior to this
specification. Future EAP method specifications MUST include a specification. Future EAP method specifications MUST include a
definition of the Method-ID, Peer-ID, and Server-ID (could be the definition of the Method-ID, Peer-ID, and Server-ID (could be the
empty string) and MAY also define the Key-Lifetime (assumed to be empty string) and MAY also define the Key-Lifetime (assumed to be
indeterminate if not described). indeterminate if not described).
EAP-Identity EAP-Identity
 End of changes. 38 change blocks. 
294 lines changed or deleted 315 lines changed or added

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