draft-ietf-eap-keying-04.txt   draft-ietf-eap-keying-05.txt 
EAP Working Group Bernard Aboba EAP Working Group Bernard Aboba
INTERNET-DRAFT Dan Simon INTERNET-DRAFT Dan Simon
Category: Informational Microsoft Category: Standards Track Microsoft
<draft-ietf-eap-keying-04.txt> J. Arkko <draft-ietf-eap-keying-05.txt> J. Arkko
14 November 2004 Ericsson 18 February 2005 Ericsson
P. Eronen P. Eronen
Nokia Nokia
H. Levkowetz, Ed. H. Levkowetz, Ed.
ipUnplugged ipUnplugged
Extensible Authentication Protocol (EAP) Key Management Framework Extensible Authentication Protocol (EAP) Key Management Framework
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with and any of which I become aware will be disclosed, in accordance with
skipping to change at page 1, line 35 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 22, 2005. This Internet-Draft will expire on August 22, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract Abstract
The Extensible Authentication Protocol (EAP), defined in [RFC3748], The Extensible Authentication Protocol (EAP), defined in [RFC3748],
enables extensible network access authentication. This document enables extensible network access authentication. This document
provides a framework for the generation, transport and usage of provides a framework for the generation, transport and usage of
keying material generated by EAP authentication algorithms, known as keying material generated by EAP authentication algorithms, known as
"methods". It also specifies the EAP key hierarchy. "methods". It also specifies the EAP key hierarchy.
Table of Contents Table of Contents
1. Introduction .......................................... 4 1. Introduction .......................................... 4
1.1 Requirements Language ........................... 4 1.1 Requirements Language ........................... 4
1.2 Terminology ..................................... 4 1.2 Terminology ..................................... 4
1.3 Overview ........................................ 5 1.3 Overview ........................................ 5
1.4 EAP Invariants .................................. 11 1.4 EAP Invariants .................................. 11
2. EAP Key Hierarchy ..................................... 13 2. Key Derivation ........................................ 14
2.1 Key Terminology ................................. 13 2.1 Key Terminology ................................. 14
2.2 Key Hierarchy ................................... 15 2.2 Key Hierarchy ................................... 15
2.3 Key Lifetimes ................................... 17 2.3 AAA-Key Derivation .............................. 21
2.4 Key Names and Scopes ............................ 24 2.4 AMSK Key Derivation ............................. 22
2.5 AAA-Key Derivation .............................. 27 2.5 Key Naming ...................................... 23
2.6 AMSK Key Derivation ............................. 28 3. Security associations ................................. 26
2.7 Key Scope Issues ................................ 29 3.1 EAP Method SA ................................... 26
3. Security associations ................................. 30 3.2 EAP-Key SA ...................................... 27
3.1 EAP Method SA ................................... 31 3.3 AAA SA(s) ....................................... 28
3.2 EAP-Key SA ...................................... 33 3.4 Service SA(s) ................................... 28
3.3 AAA SA(s) ....................................... 33 4. Key Management ........................................ 30
3.4 Service SA(s) ................................... 34 4.1 Key Caching ..................................... 31
4. Handoff Support ....................................... 39 4.2 Parent-Child Relationships ...................... 32
4.1 Authorization Issues ............................ 39 4.3 Local Key Lifetimes ............................. 32
4.2 Correctness Issues .............................. 41 4.4 Exported and Calculated Key Lifetimes ........... 33
5. Security Considerations .............................. 44 4.5 Key Cache Synchronization ....................... 34
5.1 Security Terminology ............................ 44 4.6 Key Scope ....................................... 35
5.2 Threat Model .................................... 44 4.7 Key Strength .................................... 36
5.3 Security Analysis ............................... 45 4.8 Key Wrap ........................................ 37
5.4 Man-in-the-middle Attacks ....................... 49 5. Handoff Support ....................................... 38
5.5 Denial of Service Attacks ....................... 49 5.1 Authorization ................................... 38
5.6 Impersonation ................................... 50 5.2 Correctness ..................................... 39
5.7 Channel Binding ................................. 51 6. Security Considerations .............................. 42
5.8 Key Strength .................................... 52 6.1 Security Terminology ............................ 42
5.9 Key Wrap ........................................ 53 6.2 Threat Model .................................... 42
6. Security Requirements ................................. 53 6.3 Security Analysis ............................... 44
6.1 EAP Method Requirements ......................... 53 6.4 Man-in-the-middle Attacks ....................... 48
6.2 AAA Protocol Requirements ....................... 56 6.5 Denial of Service Attacks ....................... 48
6.3 Secure Association Protocol Requirements ........ 58 6.6 Impersonation ................................... 49
6.4 Ciphersuite Requirements ........................ 60 6.7 Channel Binding ................................. 50
7. IANA Considerations ................................... 60 7. Security Requirements ................................. 51
8. References ............................................ 61 7.1 EAP Method Requirements ......................... 51
8.1 Normative References ............................ 61 7.2 AAA Protocol Requirements ....................... 54
8.2 Informative References .......................... 61 7.3 Secure Association Protocol Requirements ........ 55
Acknowledgments .............................................. 65 7.4 Ciphersuite Requirements ........................ 57
Author's Addresses ........................................... 65 8. IANA Considerations ................................... 57
Appendix A - Ciphersuite Keying Requirements ................. 67 9. References ............................................ 58
Appendix B - Example Transient EAP Key (TEK) Hierarchy ....... 68 9.1 Normative References ............................ 58
Appendix C - EAP-TLS Key Hierarchy ........................... 69 9.2 Informative References .......................... 59
Appendix D - Example Transient Session Key (TSK) Derivation .. 71 Acknowledgments .............................................. 62
Appendix E - Key Names and Scope in Existing Methods ......... 72 Author's Addresses ........................................... 63
Appendix A - Ciphersuite Keying Requirements ................. 64
Appendix B - Example Transient EAP Key (TEK) Hierarchy ....... 65
Appendix C - EAP-TLS Key Hierarchy ........................... 66
Appendix D - Example Transient Session Key (TSK) Derivation .. 68
Appendix E - Key Names and Scope in Existing Methods ......... 69
Appendix F - Security Association Examples ................... 70
Intellectual Property Statement .............................. 73 Intellectual Property Statement .............................. 73
Disclaimer of Validity ....................................... 73 Disclaimer of Validity ....................................... 74
Copyright Statement .......................................... 73 Copyright Statement .......................................... 74
1. Introduction 1. Introduction
The Extensible Authentication Protocol (EAP), defined in [RFC3748], The Extensible Authentication Protocol (EAP), defined in [RFC3748],
was designed to enable extensible authentication for network access was designed to enable extensible authentication for network access
in situations in which the IP protocol is not available. Originally in situations in which the IP protocol is not available. Originally
developed for use with PPP [RFC1661], it has subsequently also been developed for use with PPP [RFC1661], it has subsequently also been
applied to IEEE 802 wired networks [IEEE8021X]. applied to IEEE 802 wired networks [IEEE8021X].
This document provides a framework for the generation, transport and This document provides a framework for the generation, transport and
skipping to change at page 4, line 34 skipping to change at page 4, line 34
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:
auth authenticator
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 7, line 28 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.
EAP may be used in the following scenarios: The conversation phases and relationship between the parties is shown
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 10, line 11 skipping to change at page 9, line 35
association between the EAP peer and authenticator, as part of the association between the EAP peer and authenticator, as part of the
Secure Association Protocol (phase 2). As a result, EAP may be used Secure Association Protocol (phase 2). As a result, EAP may be used
for "pre-authentication" in situations where it is necessary to pre- for "pre-authentication" in situations where it is necessary to pre-
establish EAP security associations in order to decrease handoff or establish EAP security associations in order to decrease handoff or
roaming latency. roaming latency.
1.3.3. Secure Association Phase 1.3.3. Secure Association Phase
The Secure Association phase (phase 2), if it occurs, begins after The Secure Association phase (phase 2), if it occurs, begins after
the completion of EAP authentication (phase 1a) and key transport the completion of EAP authentication (phase 1a) and key transport
(phase 1b), and typically supports the following features: (phase 1b). EAP may be used in the following scenarios:
[a] Stationary peer. Where the peer is stationary it will establish
communications with one or more authenticators while remaining in
one location. In this scenario, EAP authentication typically
represents only a small fraction of the total session time, so that
it is acceptable for EAP authentication to occur each time the peer
wishes to access the network. In this scenario, the Secure
Association Protocol phase may be omitted.
[b] Mobile peer. Where the peer is mobile, it may move its point of
attachment from one authenticator to another, or between points of
attachment on a single authenticator. In this scenario, it is
often desirable to minimize the handoff latency, so that it is
desirable to avoid EAP authentication each time the peer changes
its point of attachment. In this scenario, caching of the AAA-Key
be supported on the EAP peer and authenticator. In this, a Secure
Assocation Protocol phase is required to allow EAP to be used
securely.
A Secure Association Protocol used with EAP typically supports the
following features:
[1] Generation of fresh transient session keys (TSKs). Where AAA-Key [1] Generation of fresh transient session keys (TSKs). Where AAA-Key
caching is supported, the EAP peer may initiate a new session using caching is supported, the EAP peer may initiate a new session using
a AAA-Key that was used in a previous session. Were the TSKs to be a AAA-Key that was used in a previous session. Were the TSKs to be
derived from a portion of the AAA-Key, this would result in reuse derived from a portion of the AAA-Key, this would result in reuse
of the session keys which could expose the underlying ciphersuite of the session keys which could expose the underlying ciphersuite
to attack. to attack.
As a result, where AAA-Key caching is supported, freshness of TSKs As a result, where AAA-Key caching is supported, the Secure
MUST be provided by mechanisms outside of EAP. This is typically Association Protocol phase is REQUIRED, and MUST provide for
handled within the Secure Association protocol via the exchange of freshness of the TSKs. This is typically handled via the exchange
nonces or counters, which are then mixed with the AAA-Key in order of nonces or counters, which are then mixed with the AAA-Key in
to generate fresh unicast (phase 2a) and possibly multicast (phase order to generate fresh unicast (phase 2a) and possibly multicast
2b) session keys. By not using the AAA-Key directly to protect (phase 2b) session keys. By not using the AAA-Key directly to
data, the secure Association Protocol protects against compromise protect data, the Secure Association Protocol protects against
of the AAA-Key. compromise of the AAA-Key.
[2] Entity Naming. A basic feature of a Secure Association Protocol is [2] Entity Naming. A basic feature of a Secure Association Protocol is
the explicit naming of the parties engaged in the exchange. the explicit naming of the parties engaged in the exchange.
Explicit identification of the parties is critical, since without Explicit identification of the parties is critical, since without
this the parties engaged in the exchange are not identified and the this the parties engaged in the exchange are not identified and the
scope of the transient session keys (TSKs) generated during the scope of the transient session keys (TSKs) generated during the
exchange is undefined. As illustrated in Figure 1, both the peer exchange is undefined. As illustrated in Figure 1, both the peer
and NAS may have more than one physical or virtual port, so that and NAS may have more than one physical or virtual port, so that
port identifiers are typically inappropriate as a naming mechanism. port identifiers are not recommended a naming mechanism.
[3] Secure capabilities negotiation. This provides for the secure [3] Secure capabilities negotiation. This includes the secure
negotiation of usage modes, session parameters (such as key negotiation of usage modes, session parameters (such as key
lifetimes), ciphersuites, and required filters, including lifetimes), ciphersuites and required filters, including
confirmation of the capabilities discovered during phase 0. By confirmation of the capabilities discovered during phase 0. It is
securely negotiating session parameters, the secure Association RECOMMENDED that the Secure Association Protocol support secure
Protocol protects against spoofing during the discovery phase and capabilities negotiation, in order to protect against spoofing
ensures that the peer and authenticator are in agreement about how during the discovery phase, and to ensure agreement between the
data is to be secured. peer and authenticator about how data is to be secured.
[4] Key [4] Key management. EAP as defined in [RFC3748] supports key
activation and deletion. In order for the peer and derivation, but not key management. While EAP methods may derive
authenticator to communicate securely, it is necessary for both keying material, EAP does provide for the management of exported or
sides to derive the same session keys, and remain in sync with derived keys. For example, EAP does not support negotiation of the
respect to key state going forward. One of the functions of the key lifetime of exported or derived keys, nor does it support
Secure Association Protocol is to synchronize the activation and rekey. Although EAP methods may support "fast reconnect" as
deletion of keys so as to enable seamless rekey, or recovery from defined in [RFC3748] Section 7.2.1, rekey of exported keys cannot
partial or complete loss of key state by the peer or authenticator. occur without reauthentication. In order to provide method
independence, key management of exported or derived keys SHOULD NOT
be provided within EAP methods.
[5] Mutual proof of possession of the AAA-Key. This demonstrates that Since neither EAP nor EAP methods provide key management support,
both the peer and authenticator have been authenticated and it is RECOMMENDED that key management facilities be provided within
authorized by the backend authentication server. Since mutual the Secure Association Protocol. This includes key lifetime
proof of possession is not the same as mutual authentication, the management (such as via explicit key lifetime negotiation, or
peer cannot verify authenticator assertions (including the seamless rekey), as well synchronization of the installation and
authenticator identity) as a result of this exchange. deletion of keys so as to enable recovery from partial or complete
loss of key state by the peer or authenticator. Since key
management requires a key naming scheme, Secure Association
Protocols supporting key management support MUST also support key
naming.
[5] Mutual proof of possession of the AAA-Key. The Secure Association
Protocol MUST demonstrate mutual proof of posession of the AAA-Key,
in order to show that both the peer and authenticator have been
authenticated and authorized by the backend authentication server.
Since mutual proof of possession is not the same as mutual
authentication, the peer cannot verify authenticator assertions
(including the authenticator identity) as a result of this
exchange.
1.4. EAP Invariants 1.4. EAP Invariants
Certain basic characteristics, known as the "EAP Invariants" hold Certain basic characteristics, known as the "EAP Invariants" hold
true for EAP implementations on all media: true for EAP implementations on all media:
Media independence Media independence
Method independence Method independence
Ciphersuite independence Ciphersuite independence
skipping to change at page 13, line 35 skipping to change at page 14, line 5
and negotiation policies implemented by the peer and authenticator, and negotiation policies implemented by the peer and authenticator,
or be aware of the ciphersuite negotiated between them. This or be aware of the ciphersuite negotiated between them. This
simplifies the configuration of the backend authentication server. simplifies the configuration of the backend authentication server.
For example, since ECP negotiation occurs after authentication, For example, since ECP negotiation occurs after authentication,
when run over PPP, the EAP peer, authenticator and backend when run over PPP, the EAP peer, authenticator and backend
authentication server may not anticipate the negotiated ciphersuite authentication server may not anticipate the negotiated ciphersuite
and therefore this information cannot be provided to the EAP and therefore this information cannot be provided to the EAP
method. method.
2. EAP Key Hierarchy 2. Key Derivation
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 Section 2.5; in existing implementations the MSK is discussed in Section 2.3; in existing implementations the MSK is
used as the AAA-Key. used as the AAA-Key.
Application-specific Master Session Keys (AMSKs) 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 Section 2.6. is discussed in Section 2.4.
AAA-Token AAA-Token
Where a backend server is present, the AAA-Key and one or more Where a backend server is present, the AAA-Key and one or more
attributes is transported between the backend authentication server attributes is transported between the backend authentication server
and the authenticator within a package known as the AAA-Token. The and the authenticator within a package known as the AAA-Token. The
format and wrapping of the AAA-Token, which is intended to be format and wrapping of the AAA-Token, which is intended to be
accessible only to the backend authentication server and accessible only to the backend authentication server and
authenticator, is defined by the AAA protocol. Examples include authenticator, is defined by the AAA protocol. Examples include
RADIUS [RFC2548] and Diameter [I-D.ietf-aaa-eap]. RADIUS [RFC2548] and Diameter [I-D.ietf-aaa-eap].
skipping to change at page 16, line 19 skipping to change at page 16, line 38
AAA-Key or AMSKs: TSKs. 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 keys derived from the AMSK are utilized
On both the peer and EAP server, the exported MSK and keys derived in order to calculate the AAA-Key, as described in Section 2.3.
from the AMSK are utilized in order to calculate the AAA-Key, as
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 25 skipping to change at page 18, line 5
Session Key (EMSK). The peer and EAP server then calculate the AAA- Session Key (EMSK). The peer and EAP server then calculate the AAA-
Key from the MSK and EMSK, and the backend authentication server Key from the MSK and EMSK, and the backend authentication server
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
Key lifetime issues are discussed in the sections that follow.
Issues include:
[a] Key lifetime negotiation. Where key lifetimes cannot be assumed,
it may be necessary to negotiate them. Where negotiation is
supported, it is RECOMMENDED that the negotiation be secured. Note
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] Key resynchronization. It is possible for the peer or
authenticator to reboot or reclaim resources, clearing portions or
all of the key cache. Therefore, key lifetime negotiation cannot
guarantee that the key cache will remain synchronized, and the peer
may not be able to determine before attempting to use it whether a
particular key exists within the authenticator cache. It is
therefore RECOMMENDED for the lower layer to provide a mechanism
for key state resynchronization. Since in this situation one or
more of the parties initially do not possess a key with which to
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 | | |
| | | | | | | | | | | | | |
| | | +-+-+-+-+-+-+-+ | Local to | | | | +-+-+-+-+-+-+-+ | Local to |
skipping to change at page 19, line 37 skipping to change at page 19, line 37
| | | | | | | |
|MSK,EMSK | |MSK,EMSK | |MSK,EMSK | |MSK,EMSK |
| AAA-Key/| | AAA-Key/| | AAA-Key/| | AAA-Key/|
| Name | | Name | | 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 (acting as
(acting as an EAP server), where no backend authentication an EAP server), where no backend authentication server is present.
server is present.
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
| | | | | | | |
| | | | | | | |
| Cipher- | | Cipher- | | Cipher- | | Cipher- |
| Suite | | Suite | | Suite | | Suite |
| | | | | | | |
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
^ ^ ^ ^
| | | |
skipping to change at page 20, line 46 skipping to change at page 20, line 46
| | | |
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
| | | | | | | |
| 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
authenticator and backend authentication server. and backend authentication server.
2.3.1. Parent-child relationships
When keying material exported by EAP methods expires, all keying 2.3. AAA-Key Derivation
material derived from the exported keying material, (including the
AAA-Key, AMSKs and TSKs) also expires.
Similarly, when an EAP reauthentication takes place, new keying Where a AAA-Key is generated as the result of a successful EAP
material is derived and exported by the EAP method, which eventually authentication with the authenticator A, the AAA-Key is based on the
results in replacement of calculated keys, including the AAA-Key, MSK: AAA-Key = MSK(0,63).
AMSKs, and TSKs.
As a result, the lifetime of keys calculated from the exported keying As discussed in [I-D.irtf-aaaarch-handoff], [IEEE-02-758],
material can be no longer than the lifetime of the exported keying [IEEE-03-084], and [8021XHandoff], keying material may be required
material itself. However, the lifetime of calculated keys can be for use in fast handoff between authenticators. Where the backend
less than that of the exported keys. For example, TSK rekey may authentication server provides keying material to additional
occur prior to EAP reauthentication. authenticators in order to facilitate fast handoff, it is highly
desirable for the keying material used on different authenticators B,
C to be cryptographically separate, so that if one authenticator is
compromised, it does not lead to the compromise of other
authenticators. Where keying material is provided by the backend
authentication server, a key hierarchy derived from the AMSK can be
used to provide cryptographically separate keying material for use in
fast handoff. Instead of using the EMSK directly an application
specific key (AMSK) is derived as described in Section 2.4:
Note that deletion of the AAA-Key does not necessarily imply deletion AAA-Key = MSK(0,63)
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.
Failure to mutually prove possession of the AAA-Key during the Secure AMSK = KDF(EMSK, "EAP AAA-Key derivation for multiple attachments",
Association Protocol exchange need not be grounds for deletion of the length)
AAA-Key by both parties; rate-limiting Secure Association Protocol
exchanges could be used to prevent a brute force attack.
2.3.2. Local Key Lifetimes AAA-Key-B = prf(AMSK(0,63),"EAP AAA-Key derivation for
multiple attachments", AAA-Key, B-Called-Station-Id,
Calling-Station-Id,length)
The Transient EAP Keys (TEKs) are session keys used to protect the AAA-Key-C = prf(AMSK(0,63),"EAP AAA-Key derivation for
EAP conversation. The TEKs are internal to the EAP method and are multiple attachments",AAA-Key, C-Called-Station-Id,
not exported. TEKs are typically created during an EAP conversation, Calling-Station-Id, length)
used until the end of the conversation and then discarded. However,
methods may rekey TEKs during a conversation.
When using TEKs within an EAP conversation or across conversations, Where:
it is necessary to ensure that replay protection and key separation Calling-Station-Id = STA MAC address
requirements are fulfilled. For instance, if a replay counter is B-Called-Station-Id = AP B MAC address
used, TEK rekey MUST occur prior to wrapping of the counter. C-Called-Station-Id = AP C MAC address
Similarly, TSKs MUST remain cryptographically separate from TEKs prf = HMAC-SHA1
despite TEK rekeying or caching. This prevents TEK compromise from KDF = defined in Section 2.4
leading directly to compromise of the TSKs and vice versa. length = length of derived key material
EAP methods may cache local keying material which may persist for Here AAA-Key is derived during the initial EAP authentication between
multiple EAP conversations when fast reconnect is used [RFC 3748]. the peer and authenticator A. Based on this initial EAP
For example, EAP methods based on TLS (such as EAP-TLS [RFC2716]) authentication, an AMSK is also derived, which can be used to derive
derive and cache the TLS Master Secret, typically for substantial AAA-Keys for fast authentication between the EAP peer and
time periods. The lifetime of other local keying material calculated authenticators B and C. Since the AMSK is cryptographically separate
within the EAP method is defined by the method. Note that in from the MSK, each of these AAA-Keys is cryptographically separate
general, when using fast reconnect, there is no guarantee to that the from each other, and are guaranteed to be unique between the EAP peer
original long-term credentials are still in the possession of the (also known as the STA) and the authenticator (also known as the AP).
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.
2.3.3. Exported and Calculated Key Lifetimes 2.4. AMSK Key Derivation
All EAP methods generating keys are required to generate the MSK and The EAP AMSK key derivation function (KDF) derives an AMSK from the
EMSK, and may optionally generate the IV. Existing EAP methods do Extended Master Session Key (EMSK), an application key label,
not negotiate the lifetime of the exported keys. EAP, defined in optional application data, and output length.
[RFC3748], also does not support the negotiation of lifetimes for
exported keying material such as the MSK, EMSK and IV.
Several mechanisms exist for managing key lifetimes: AMSK = KDF(EMSK, key label, optional application data, length)
[a] AAA attributes. AAA protocols such as RADIUS [RFC2865] and The key labels are printable ASCII strings unique for each
Diameter [DiamEAP] support the Session-Timeout attribute. The application (see Section 8 for IANA Considerations).
Session-Timeout value represents the maximum lifetime of the
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 TSK lifetime is often determined by authenticator Additional ciphering keys (TSKs) can be derived from the AMSK using
resources, the AAA server has no insight into the TSK derivation an application specific key derivation mechanism. In many cases,
process, and by the principle of ciphersuite independence, it is this AMSK->TSK derivation can simply split the AMSK to pieces of
not appropriate for the AAA server to manage any aspect of the TSK correct length. In particular, it is not necessary to use a
derivation process, including the TSK lifetime. cryptographic one-way function. The length of the AMSK MUST be
specified by the application.
[b] Lower layer mechanisms. While AAA attributes can communicate the The AMSK key derivation function is taken from the PRF+ key expansion
maximum exported key lifetime, this only serves to synchronize the PRF from [IKEv2]. This KDF takes 4 parameters as input: secret,
key lifetime between the backend authentication server and the label, application data, and output length. It is only defined for
authenticator. Lower layer mechanisms can then be used to enable 255 iterations so it may produce up to 5100 bytes of key material.
the lifetime of exported and calculated keys to be negotiated
between the peer and authenticator.
Where TSKs are established as the result of a Secure Association For the purposes of this specification the secret is taken as the
Protocol exchange, it is RECOMMENDED that the Secure Association EMSK, the label is the key label described above concatenated with a
Protocol include secure negotiation of the TSK lifetime between the NUL byte, the application data is also described above and the output
peer and authenticator. Where the TSK is taken from the AAA-Key, length is two bytes. Application data MAY be an empty string. The
there is no need to manage the TSK lifetime as a separate KDF is based on HMAC-SHA1 [RFC2104] [SHA1]. For this specification we
parameter, since the TSK lifetime and AAA-Key lifetime are have:
identical.
[c] System defaults. Where the EAP method does not support the KDF (K,L,D,O) = T1 | T2 | T3 | T4 | ...
negotiation of the exported key lifetime, and a negotiation
mechanism is not provided by the lower lower, there may be no way
for the peer to learn knowledge of the exported key liftime. In
this case it is RECOMMENDED that the peer assume a default value of
the exported key lifetime; 8 hours is suggested. Similarly, the
lifetime of calculated keys can also be managed as a system
parameter on the authenticator.
2.3.4. Key cache synchronization where:
T1 = prf (K, S | 0x01)
T2 = prf (K, T1 | S | 0x02)
T3 = prf (K, T2 | S | 0x03)
T4 = prf (K, T3 | S | 0x04)
Issues arise when attempting to synchronize the key cache on the peer prf = HMAC-SHA1
and authenticator. Lifetime negotiation alone cannot guarantee key K = EMSK
cache synchronization. L = key label
D = application data
O = OutputLength (2 bytes)
S = L | " " | D | O
One problem is that the AAA protocol cannot guarantee synchronization The prf+ construction was chosen because of its simplicity and
of key lifetimes between the peer and authenticator. Where the efficiency over other PRFs such as those used in [TLS]. The
Secure Association Protocol is not run immediately after EAP motivation for the design of this PRF is described in [SIGMA].
authentication, the exported and calculated key lifetimes will not be
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.
However, even where the Secure Association Protocol is run The NUL byte after the key label is used to avoid collisions if one
immediately after EAP, it is still possible for the authenticator to key label is a prefix of another label (e.g. "foobar" and
reclaim resources if the created key state is not immediately "foobarExtendedV2"). This is considered a simpler solution than
utilized. requiring a key label assignment policy that prevents prefixes from
occurring.
The lower layer may utilize Discovery mechanisms to assist in this. Where another prf needs to be negotiated, this can be handled within
For example, the authenticator manages the AAA-Key cache by deleting the EAP method.
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.
2.4. Key Names and Scopes 2.5. Key Naming
Each key created within the EAP key management framework has a name Each key created within the EAP key management framework has a name
(the identifier by which the key can be identified), as well as a (the identifier by which the key can be identified), as well as a
scope (the parties to whom the key is available). This section scope (the parties to whom the key is available). This section
describes how keys are named, and the scope within which that name describes how keys are named, and the scope within which that name
applies. applies.
Session-Id Session-Id
EAP methods supporting key naming MUST specify a temporally unique EAP methods supporting key naming MUST specify a temporally unique
method identifier known as the EAP Method-Id, which is typically method identifier known as the EAP Method-Id, which is typically
constructed from nonces or counters used within the exchange. Since constructed from nonces or counters used within the exchange. Since
multiple EAP sessions may exist between an EAP peer and EAP server, multiple EAP sessions may exist between an EAP peer and EAP server,
the Method-Id allows MSKs to be differentiated. the Method-Id allows MSKs to be differentiated.
The combination of the EAP Type and the Method-Id is known as the EAP The concatenation of the EAP Type (expressed in ASCII text), ":" and
the Method-Id (also expressed in ASCII text) is known as the EAP
Session-Id. The inclusion of the Type in the EAP Session-Id ensures Session-Id. The inclusion of the Type in the EAP Session-Id ensures
that each EAP method has a distinct name space. that each EAP method has a distinct name space.
The EAP Session-Id uniquely identifies the EAP session to the EAP The EAP Session-Id uniquely identifies the EAP session to the EAP
peer and server terminating the EAP conversation. However, suitable peer and server terminating the EAP conversation. However, suitable
EAP peer and server names may not always be available. As described EAP peer and server names may not always be available. As described
in [RFC3748] Section 7.3, the identity provided in the EAP- in [RFC3748] Section 7.3, the identity provided in the EAP-
Response/Identity, may be different from the identity authenticated Response/Identity, may be different from the identity authenticated
by the EAP method, and as a result the EAP-Response/Identity is by the EAP method, and as a result the EAP-Response/Identity is
unsuitable for determination of the peer identity. As a result, the unsuitable for determination of the peer identity. As a result, the
skipping to change at page 24, line 51 skipping to change at page 24, line 16
Session-Id scope, if available, and is used to construct names for Session-Id scope, if available, and is used to construct names for
other EAP keys. Note that the EAP Session-Id and scope are only other EAP keys. Note that the EAP Session-Id and scope are only
known by the EAP method. As a result, the format of the EAP Session- known by the EAP method. As a result, the format of the EAP Session-
Id and the definition of the Session-Id scope needs to be specified Id and the definition of the Session-Id scope needs to be specified
within the method. Appendix E defines the EAP Session-Id and scope within the method. Appendix E defines the EAP Session-Id and scope
provided by existing methods. provided by existing methods.
MSK Name MSK Name
This key is created between the EAP peer and EAP server, and can be This key is created between the EAP peer and EAP server, and can be
referred to using the string "MSK" and the EAP Session-Id. As with referred to using the string "MSK:", concatenated with the EAP
the EAP Session-Id, the MSK scope is defined by the EAP peer name (if Session-Id. As with the EAP Session-Id, the MSK scope is defined by
securely exchanged within the method) and the EAP server name (also the EAP peer name (if securely exchanged within the method) and the
only if securely exchanged). Where a peer or server name is missing EAP server name (also only if securely exchanged). Where a peer or
the null string is used. server name is missing the null string is used.
EMSK Name EMSK Name
The EMSK can be referred to using the string "EMSK" and the EAP The EMSK can be referred to using the string "EMSK:", concatenated
Session-Id. with the EAP Session-Id.
As with the EAP Session-Id, the EMSK scope is defined by the EAP peer As with the EAP Session-Id, the EMSK scope is defined by the EAP peer
name (if securely exchanged within the method) and the EAP server name (if securely exchanged within the method) and the EAP server
name (also only if securely exchanged). Where a peer or server name name (also only if securely exchanged). Where a peer or server name
is missing the null string is used. is missing the null string is used.
AMSK Name AMSK Name
AMSKs, if any, can be referred to using the string "AMSK", the key AMSKs, if any, can be referred to using the string "AMSK:", the key
label, application data (see Section 2.6) and the EAP Session-Id. label, ":", application data (see Section 2.4), ":", and the EAP
Session-Id.
As with the EAP Session-Id, the AMSK scope is defined by the EAP peer 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 (if securely exchanged within the method), ":" and the EAP
name (also only if securely exchanged). Where a peer or server name server name (also only if securely exchanged). Where a peer or
is missing the null string is used. server name is missing the null string is used.
AAA-Key Name AAA-Key Name
The AAA-Key is derived from either the MSK or AMSK and so can be The AAA-Key is derived from either the MSK or AMSK and so can be
referred to using the MSK or AMSK names. referred to using the MSK or AMSK names.
The AAA-Key scope is provided by the concatenation of the EAP peer The AAA-Key scope is provided by the concatenation of the EAP peer
name (if securely provided to the authenticator), and the name (if securely provided to the authenticator), and the
authenticator name (if securely provided to the peer). authenticator name (if securely provided to the peer).
skipping to change at page 25, line 49 skipping to change at page 25, line 15
authenticator may include the NAS-Identifier attribute to the AAA authenticator may include the NAS-Identifier attribute to the AAA
server in an Access-Request, and the authenticator may provide the server in an Access-Request, and the authenticator may provide the
NAS-Identifier (unsecured) to the EAP peer in the EAP- NAS-Identifier (unsecured) to the EAP peer in the EAP-
Request/Identity or via a lower layer mechanism (such as the 802.11 Request/Identity or via a lower layer mechanism (such as the 802.11
Beacon/Probe Response). Where the NAS-Identifier is provided by the Beacon/Probe Response). Where the NAS-Identifier is provided by the
authenticator to the peer a secure mechanism is RECOMMENDED. authenticator to the peer a secure mechanism is RECOMMENDED.
For the purpose of identifying the peer to the authenticator, the EAP For the purpose of identifying the peer to the authenticator, the EAP
peer identifier provided within the EAP method is recommended. It peer identifier provided within the EAP method is recommended. It
cannot be assumed that the authenticator is aware of the EAP peer cannot be assumed that the authenticator is aware of the EAP peer
name used within name used within the method. Therefore alternatives mechanisms need
the method. Therefore alternatives mechanisms need
to be used to provide the EAP peer name to the authenticator. For to be used to provide the EAP peer name to the authenticator. For
example, the AAA server may include the EAP peer name in the User- example, the AAA server may include the EAP peer name in the User-
Name attribute of the Access-Accept or the peer may provide the Name attribute of the Access-Accept or the peer may provide the
authenticator with its name via a lower layer mechanism. authenticator with its name via a lower layer mechanism.
Absent an explicit binding step within the Secure Association Absent an explicit binding step within the Secure Association
Protocol, the AAA-Key is not bound to a specific peer or Protocol, the AAA-Key is not bound to a specific peer or
authenticator port. As a result, the peer or authenticator port over authenticator port. As a result, the peer or authenticator port over
which the EAP conversation takes place is not included in the AAA-Key which the EAP conversation takes place is not included in the AAA-Key
scope. scope.
skipping to change at page 27, line 5 skipping to change at page 26, line 16
establishment and re-establishment of TSKs can be synchronized establishment and re-establishment of TSKs can be synchronized
between the parties. 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 2 than one AAA-Key (phase 1b) applicable to establishment of a phase 2
security association, the secure Association protocol needs to security association, the secure Association protocol needs to
utilize the AAA-Key name so that the appropriate phase 1b keying utilize the AAA-Key name so that the appropriate phase 1b keying
material 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 reconnect" or other stores state that can be used for "fast reconnect" or other
functionality in some EAP methods. Not all EAP methods create such functionality in some EAP methods. Not all EAP methods create such
an SA. an SA.
skipping to change at page 31, line 31 skipping to change at page 26, line 42
[3] AAA SA(s). These SAs are between the authenticator and the backend [3] AAA SA(s). These SAs are between the authenticator and the backend
authentication server. They permit the parties to mutually authentication server. They permit the parties to mutually
authenticate each other and protect the communications between authenticate each other and protect the communications between
them. them.
[4] Service SA(s). These SAs are between the peer and authenticator, [4] Service SA(s). These SAs are between the peer and authenticator,
and they are created as a result of phases 1-2 of the conversation and they are created as a result of phases 1-2 of the conversation
(see Section 1.3). (see Section 1.3).
Examples of security associations are provided in Appendix F.
3.1. EAP Method SA (peer - EAP server) 3.1. EAP Method SA (peer - EAP server)
An EAP method may store some state on the peer and EAP server even An EAP method may store some state on the peer and EAP server even
after phase 1a has completed. after phase 1a has completed.
Typically, this is used for "fast reconnect": the peer and EAP server Typically, this is used for "fast reconnect": the peer and EAP server
can confirm that they are still talking to the same party, perhaps can confirm that they are still talking to the same party, perhaps
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
skipping to change at page 32, line 22 skipping to change at page 27, line 35
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 Internal (non-exported) cryptographic state o Internal (non-exported) cryptographic state
o EAP method SA name o EAP method SA name
o SA lifetime o SA lifetime
3.1.1. Example: EAP-TLS
In EAP-TLS [RFC2716], after the EAP authentication the client (peer)
and server can store the following information:
o Implicitly, the EAP method this SA refers to (EAP-TLS)
o Session identifier (a value selected by the server)
o Certificate of the other party (server stores the client's
certificate and vice versa)
o Ciphersuite and compression method
o TLS Master secret (known as the EAP-TLS Master Key)
o SA lifetime (ensuring that the SA is not stored forever)
o If the client has multiple different credentials (certificates
and corresponding private keys), a pointer to those credentials
When the server initiates EAP-TLS, the client can look up the EAP-TLS
SA based on the credentials it was going to use (certificate and
private key), and the expected credentials (certificate or name) of
the server. If an EAP-TLS SA exists, and it is not too old,
the
client informs the server about the existence of this SA by including
its Session-Id in the TLS ClientHello message. The server then looks
up the correct SA based on the Session-Id (or detects that it doesn't
yet have one).
3.1.2. Example: EAP-AKA
In EAP-AKA [I-D.arkko-pppext-eap-aka], after EAP authentication the
client and server can store the following information:
o Implicitly, the EAP method this SA refers to (EAP-AKA)
o A re-authentication pseudonym
o The client's permanent identity (IMSI)
o Replay protection counter
o Authentication key (K_aut)
o Encryption key (K_encr)
o Original Master Key (MK)
o SA lifetime (ensuring that the SA is not stored forever)
When the server initiates EAP-AKA, the client can look up the EAP-AKA
SA based on the credentials it was going to use (permanent identity).
If an EAP-AKA SA exists, and it is not too old, the client informs
the server about the existence of this SA by sending its re-
authentication pseudonym as its identity in EAP Identity Response
message, instead of its permanent identity. The server then looks up
the correct SA based on this identity.
3.2. EAP-Key SA 3.2. EAP-Key SA
This is an SA between the peer and EAP server, which is used to store This is an SA between the peer and EAP server, which is used to store
the keying material exported by the EAP method. Current EAP server the keying material exported by the EAP method. Current EAP server
implementations do not retain this SA after the EAP conversation implementations do not retain this SA after the EAP conversation
completes, but future implementations could use this SA for pre- completes, but future implementations could use this SA for pre-
emptive key distribution. emptive key distribution.
Contents: Contents:
skipping to change at page 33, line 43 skipping to change at page 28, line 14
3.3. AAA SA(s) (authenticator - backend authentication server) 3.3. AAA SA(s) (authenticator - backend authentication server)
In order for the authenticator and backend authentication server to In order for the authenticator and backend authentication server to
authenticate each other, they need to store some information. authenticate each other, they need to store some information.
In case the authenticator and backend authentication server are In case the authenticator and backend authentication server are
colocated, and they communicate using local procedure calls or shared colocated, and they communicate using local procedure calls or shared
memory, this SA need not necessarily contain any information. memory, this SA need not necessarily contain any information.
3.3.1. Example: RADIUS
In RADIUS, where shared secret authentication is used, the client and
server store each other's IP address and the shared secret, which is
used to calculate the Response Authenticator [RFC2865] and Message-
Authenticator [RFC3579] values, and to encrypt some attributes (such
as the AAA-Key, see [RFC3580] Section 3.16).
Where IPsec is used to protect RADIUS [RFC3579] and IKE is used for
key management, the parties store information necessary to
authenticate and authorize the other party (e.g. certificates, trust
anchors and names). The IKE exchange results in IKE Phase 1 and Phase
2 SAs containing information used to protect the conversation
(session keys, selected ciphersuite, etc.)
3.3.2. Example: Diameter with TLS
When using Diameter protected by TLS, the parties store information
necessary to authenticate and authorize the other party (e.g.
certificates, trust anchors and names). The TLS handshake results in
a short-term TLS SA that contains information used to protect the
actual communications (session keys, selected TLS ciphersuite, etc.).
3.4. Service SA(s) (peer - authenticator) 3.4. Service SA(s) (peer - authenticator)
The service SAs store information about the service being provided. The service SAs store information about the service being provided.
These include the Root service SA and derived unicast and multicast These include the Root service SA and derived unicast and multicast
service SAs. service SAs.
The Root service SA is established as the result of the completion of The Root service SA is established as the result of the completion of
EAP authentication (phase 1a) and AAA-Key derivation or transport EAP authentication (phase 1a) and AAA-Key derivation or transport
(phase 1b). It includes: (phase 1b). It includes:
skipping to change at page 35, line 47 skipping to change at page 29, line 41
protocol. For example, a unicast service SA may be rekeyed without protocol. For example, a unicast service SA may be rekeyed without
implying a rekey of the multicast service SA. implying a rekey of the multicast service SA.
The deletion of the Root service SA does not necessarily imply the The deletion of the Root service SA does not necessarily imply the
deletion of the derived unicast and multicast service SAs and deletion of the derived unicast and multicast service SAs and
associated TSKs. Failure to mutually prove possession of the AAA-Key associated TSKs. Failure to mutually prove possession of the AAA-Key
during the Secure Association Protocol exchange need not be grounds during the Secure Association Protocol exchange need not be grounds
for deletion of the AAA-Key by both parties; the action to be taken for deletion of the AAA-Key by both parties; the action to be taken
is defined by the Secure Association Protocol. is defined by the Secure Association Protocol.
3.4.1. Example: 802.11i 3.4.1. Sharing service SAs
[IEEE802.11i] Section 8.4.1.1 defines the security associations used
within IEEE 802.11. A summary follows; the standard should be
consulted for details.
o Pairwise Master Key Security Association (PMKSA)
The PMKSA is a bi-directional SA, used
by both parties for sending
and receiving. The PMKSA is the Root Service SA. It is created
on the peer when EAP authentication completes successfully or a
pre-shared key is configured. The PMKSA is created on the
authenticator when the PMK is received or created on the
authenticator or a pre-shared key is configured. The PMKSA is
used to create the PTKSA. PMKSAs are cached for their lifetimes.
The PMKSA consists of the following elements:
- PMKID (security association identifier)
- Authenticator MAC address
- PMK
- Lifetime
- Authenticated Key Management Protocol (AKMP)
- Authorization parameters specified by the AAA server or
by local configuration. This can include
parameters such as the peer's authorized SSID.
On the peer, this information can be locally
configured.
- Key replay counters (for EAPOL-Key messages)
- Reference to PTKSA (if any), needed to:
o delete it (e.g. AAA server-initiated disconnect)
o replace it when a new four-way handshake is done
- Reference to accounting context, the details of which depend
on the accounting protocol used, the implementation
and administrative details. In RADIUS, this could include
(e.g. packet and octet counters, and Acct-Multi-Session-Id).
o Pairwise Transient Key Security Association (PTKSA)
The PTKSA is a bi-directional SA created as the result of a
successful four-way handshake. The PTKSA is a unicast service SA.
There may only be one PTKSA between a pair of peer and
authenticator MAC addresses. PTKSAs are cached for the lifetime
of the PMKSA. Since the PTKSA is tied to the PMKSA, it only has
the additional information from the 4-way handshake. The PTKSA
consists of the following:
- Key (PTK)
- Selected ciphersuite
- MAC addresses of the parties
- Replay counters, and ciphersuite specific state
- Reference to PMKSA: This is needed when:
o A new four-way handshake is needed (lifetime, TKIP
countermeasures), and we need to know which PMKSA to use
o Group Transient Key Security Association (GTKSA)
The GTKSA is a uni-directional SA created based on the four-way
handshake or the group key handshake. The GTKSA is a multicast
service SA. A GTKSA consists of the following:
- Direction vector (whether the GTK is used for transmit or receive)
- Group cipher suite selector
- Key (GTK)
- Authenticator MAC address
- Via reference to PMKSA, or copied here:
o Authorization parameters
o Reference to accounting context
3.4.2. Example: IKEv2/IPsec
Note that this example is intended to be informative, and it does not
necessarily include all information stored.
o IKEv2 SA
- Protocol version
- Identities of the parties
- IKEv2 SPIs
- Selected ciphersuite
- Replay protection counters (Message ID)
- Keys for protecting IKEv2 messages (SK_ai/SK_ar/SK_ei/SK_er)
- Key for deriving keys for IPsec SAs (SK_d)
- Lifetime information
- On the authenticator, service authorization information
received from the backend authentication server.
When processing an incoming message, the correct SA is looked up based
on the SPIs.
o IPsec SAs/SPD
- Traffic selectors
- Replay protection counters
- Selected ciphersuite
- IPsec SPI
- Keys
- Lifetime information
- Protocol mode (tunnel or transport)
The correct SA is looked up based on SPI (for inbound packets), or
SPD traffic selectors (for outbound traffic). A separate IPsec SA
exists for each direction.
3.4.3. Sharing service SAs
A single service may be provided by multiple logical or physical A single service may be provided by multiple logical or physical
service elements. Each service is responsible for specifying how service elements. Each service is responsible for specifying how
changing service elements is handled. Some approaches include: changing service elements is handled. Some approaches include:
Transparent sharing Transparent sharing
If the service parameters visible to the other party (either peer If the service parameters visible to the other party (either peer
or authenticator) do not change, the service can be moved without or authenticator) do not change, the service can be moved without
requiring cooperation from the other party. requiring cooperation from the other party.
skipping to change at page 38, line 52 skipping to change at page 30, line 41
to some particular service elements (defined either by a service to some particular service elements (defined either by a service
parameter, or simple administrative decision). If the old and new parameter, or simple administrative decision). If the old and new
service element do not support such "context transfer", this service element do not support such "context transfer", this
approach falls back to the previous option (no transfer). approach falls back to the previous option (no transfer).
Services supporting this feature should also consider what changes Services supporting this feature should also consider what changes
require new authorization from the backend authentication server require new authorization from the backend authentication server
(see Section 4.2). (see Section 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
parameters as well. parameters as well.
4. Handoff Support 4. Key Management
The EAP peer, authenticator and backend server may support key
caching. Since EAP supports key derivation, but not key management,
this functionality needs to be provided by the Secure Association
Protocol. Key management support includes:
[a] Key lifetime determination. EAP does not support negotiation of
key lifetimes, nor does it support rekey without reauthentication.
As a result, the Secure Association Protocol is responsible for
rekey and determination of the key lifetime. Where key caching is
supported, secure negotiation of key lifetimes is RECOMMENDED.
Lower layers that support rekey, but not key caching may not
require key lifetime negotiation. To take an example from IKE, the
difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes
were negotiated. In IKEv2, each end of the SA is responsible for
enforcing its own lifetime policy on the SA and rekeying the SA
when necessary.
[b] Key resynchronization. It is possible for the peer or
authenticator to reboot or reclaim resources, clearing portions or
all of the key cache. Therefore, key lifetime negotiation cannot
guarantee that the key cache will remain synchronized, and the peer
may not be able to determine before attempting to use a AAA-Key
whether it exists within the authenticator cache. It is therefore
RECOMMENDED for the Secure Association Protocol to provide a
mechanism for key state resynchronization. Since in this situation
one or more of the parties initially do not possess a key with
which to protect the resynchronization exchange, securing this
mechanism may be difficult.
[c] Key selection. Where key caching is supported, it may be possible
for the EAP peer and authenticator to share more than one key of a
given type. As a result, the Secure Association Protocol needs to
support key selection, using the EAP Key Naming scheme described in
this document.
[d] Key scope determination. Since the Discovery phase is handled out-
of-band, EAP does not provide a mechanism by which the peer can
determine the authenticator identity. As a result, where the
authenticator has multiple ports and AAA-Key caching is supported,
the EAP peer may not be able to determine the scope of validity of
a AAA-Key. Similarly, where the EAP peer has multiple ports, the
authenticator may not be able to determine whether a peer has
authorization to use a particular AAA-Key. To allow key scope
determination, the lower layer SHOULD provide a mechanism by which
the peer can determine the scope of the AAA-Key cache on each
authenticator, and by which the authenticator can determine the
scope of the AAA-Key cache on a peer.
4.1. Key Caching
Key caching may be supported on the EAP peer, authenticator and
backend server. Where explicitly supported by the lower layer, the
EAP peer and authenticator MAY cache the AAA-Key and/or TSKs. The
structure of the key cache on the peer and authenticator is defined
by the lower layer. Unless specified by the lower layer, the EAP
peer, authenticator and server MUST assume that peers and
authenticators do not cache the AAA-Key or TSKs.
The EAP peer and server MAY cache keys exported by the EAP method as
well as keys derived from them, subject to the following
restrictions:
[1] In order to avoid key reuse, on the EAP server, transported keys
are deleted once they are sent. An EAP server MUST NOT retain keys
that it has previously sent to the authenticator. For example, an
EAP server that has transported a AAA-Key based on the MSK MUST
delete both the AAA-Key and the MSK, and no keys may be derived
from either the AAA-Key or the MSK from that point forward by the
server.
[2] Keys which are not transported, such as the EMSK, MAY be cached on
the EAP server. While AMSKs calculated from the EMSK MUST be
deleted from the EAP server once they are transported, the parent
EMSK may remain in the EAP server cache.
4.2. Parent-Child Relationships
When keying material exported by EAP methods expires, all keying
material derived from the exported keying material expires, including
the AAA-Key, AMSKs and TSKs.
When an EAP reauthentication takes place, new keying material is
derived and exported by the EAP method, which eventually results in
replacement of calculated keys, including the AAA-Key, AMSKs, and
TSKs.
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
be greater. For example, TSK rekey may occur prior to EAP
reauthentication.
Failure to mutually prove possession of the AAA-Key during the Secure
Association Protocol exchange need not be grounds for deletion of the
AAA-Key by both parties; rate-limiting Secure Association Protocol
exchanges could be used to prevent a brute force attack.
4.3. Local Key Lifetimes
The Transient EAP Keys (TEKs) are session keys used to protect the
EAP conversation. The TEKs are internal to the EAP method and are
not exported. TEKs are typically created during an EAP conversation,
used until the end of the conversation and then discarded. However,
methods may rekey TEKs during a conversation.
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.
EAP methods may cache local keying material which may persist for
multiple EAP conversations when fast reconnect is used [RFC 3748].
For example, EAP methods based on TLS (such as EAP-TLS [RFC2716])
derive and cache the TLS Master Secret, typically for substantial
time periods. The lifetime of other local keying material calculated
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 also verify that the long-
term credentials are still valid, such as by checking that
certificate used in the original authentication has not yet expired.
4.4. Exported and Calculated Key Lifetimes
All EAP methods generating keys are required to generate the MSK and
EMSK, and may optionally generate the IV. However, EAP, defined in
[RFC3748], does not support the negotiation of lifetimes for exported
keying material such as the MSK, EMSK and IV.
Several mechanisms exist for managing key lifetimes:
[a] AAA attributes. AAA protocols such as RADIUS [RFC2865] and
Diameter [DiamEAP] support the Session-Timeout attribute. The
Session-Timeout value represents the maximum lifetime of the
exported keys, and all keys calculated from it. If the AAA server
caches exported keys, then it MUST expire the exported keys and all
keys calculated from them, no later than 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 TSK lifetime is often determined by authenticator
resources, the AAA server has no insight into the TSK derivation
process, and by the principle of ciphersuite independence, it is
not appropriate for the AAA server to manage any aspect of the TSK
derivation process, including the TSK lifetime.
[b] Lower layer mechanisms. While AAA attributes can communicate the
maximum exported key lifetime, this only serves to synchronize the
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.
Where TSKs are established as the result of a Secure Association
Protocol exchange, it is RECOMMENDED that the Secure Association
Protocol include support for TSK resynchronization. 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.
[c] System defaults. Where the EAP method does not support the
negotiation of the exported key lifetime, and a key lifetime
negotiation mechanism is not provided by the lower lower, there may
be no way for the peer to learn the exported key liftime. In this
case it is RECOMMENDED that the peer assume a default value of the
exported key lifetime; 8 hours is suggested. Similarly, the
lifetime of calculated keys can also be managed as a system
parameter on the authenticator.
4.5. Key cache synchronization
Issues arise when attempting to synchronize the key cache on the peer
and authenticator. Lifetime negotiation alone cannot guarantee key
cache synchronization.
One problem is that the AAA protocol cannot guarantee synchronization
of key lifetimes between the peer and authenticator. Where the
Secure Association Protocol is not run immediately after EAP
authentication, the exported and calculated key lifetimes will not be
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.
However, even where the Secure Association Protocol is run
immediately after EAP, it is still possible for the authenticator to
reclaim resources if the created key state is not immediately
utilized.
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.
4.6. Key Scope Issues
As described in Section 2.3, 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.
4.7. Key Strength
In order to guard against brute force attacks, EAP methods deriving
keys need to be capable of generating keys with an appropriate
effective symmetric key strength. In order to ensure that key
generation is not the weakest link, it is RECOMMENDED that EAP
methods utilizing public key cryptography choose a public key that
has a cryptographic strength meeting the symmetric key strength
requirement.
As noted in [RFC3766] Section 5, this results in the following
required RSA or DH module and DSA subgroup size in bits, for a given
level of attack resistance in bits:
Attack Resistance RSA or DH Modulus DSA subgroup
(bits) size (bits) size (bits)
----------------- ----------------- ------------
70 947 128
80 1228 145
90 1553 153
100 1926 184
150 4575 279
200 8719 373
250 14596 475
4.8. Key Wrap
As described in [RFC3579] Section 4.3, known problems exist in the
key wrap specified in [RFC2548]. Where the same RADIUS shared secret
is used by a PAP authenticator and an EAP authenticator, there is a
vulnerability to known plaintext attack. Since RADIUS uses the
shared secret for multiple purposes, including per-packet
authentication, attribute hiding, considerable information is exposed
about the shared secret with each packet. This exposes the shared
secret to dictionary attacks. MD5 is used both to compute the RADIUS
Response Authenticator and the Message-Authenticator attribute, and
some concerns exist relating to the security of this hash
[MD5Attack].
As discussed in [RFC3579] Section 4.3, the security vulnerabilities
of RADIUS are extensive, and therefore development of an alternative
key wrap technique based on the RADIUS shared secret would not
substantially improve security. As a result, [RFC3759] Section 4.2
recommends running RADIUS over IPsec. The same approach is taken in
Diameter EAP [I-D.ietf-aaa-eap], which defines cleartext key
attributes, to be protected by IPsec or TLS.
Where an untrusted AAA intermediary is present (such as a RADIUS
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
intermediary. Possession of the AAA-Key enables decryption of data
traffic sent between the peer and a specific authenticator; however
where key separation is implemented, compromise of the AAA-Key does
not enable an attacker to impersonate the peer to another
authenticator, since that requires possession of the EMSK, which is
not transported by the AAA protocol. This vulnerability may be
mitigated by implementation of redirect functionality, as provided in
[RFC3588].
5. Handoff Support
With 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 the 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. Fast handoff mechanisms include:
mechanisms do not result in additional AAA server load. Fast handoff
mechanisms include:
[a] Pre-emptive handoff. In this technique, the AAA server pre- [a] Pre-emptive handoff. In this technique, the AAA server pre-
establishes key state on the authenticator prior to arrival of the establishes key state on the authenticator prior to arrival of the
peer, without completion of EAP authentication. As described in peer, without completion of EAP authentication. As described in
[IEEE-03-084] and [I.D.irtf-aaaarch-handoff], this technique [IEEE-03-084] and [I.D.irtf-aaaarch-handoff], this technique
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 [c] Key Request. In this technique, the peer requests that the new
authenticator, AAA-Key caching may be utilized in order to enable a authenticator retrieve a named key from the EAP server for
peer to quickly re-esta potential use in a forthcoming session. In this technique, EAP
blish a session with an authenticator. authentication (phase 1a) is bypassed, but AAA-Key transport (phase
1b) is not.
Where key caching is supported, once the AAA-Key is derived and/or
transported to the authenticator, it may remain cached on the peer
and authenticator, even after a subsequent session terminates. To
initiate a subsequent session with the same authenticator, the peer
may utilize the Secure Association Protocol to confirm mutual
possession of the AAA-Key by the peer and authenticator, thereby re-
activating the AAA-Key for use in a subsequent session.
The introduction of handoff support introduces new security
vulnerabilities as well as requirements for the secure handling of
authorization context. These issues are discussed in the sections
that follow.
4.1. Authorization Issues 5.1. Authorization
In a typical network access scenario (dial-in, wireless LAN, etc.) In a typical network access scenario (dial-in, wireless LAN, etc.)
access control mechanisms are typically applied. These mechanisms access control mechanisms are typically applied. These mechanisms
include user authentication as well as authorization for the offered include user authentication as well as authorization for the offered
service. service.
As a part of the authentication process, the AAA network determines As a part of the authentication process, the AAA network determines
the user's authorization profile. The user authorizations are the user's authorization profile. The user authorizations are
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 41, line 8 skipping to change at page 39, line 47
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.2. Correctness Issues 5.2. Correctness
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 42, line 36 skipping to change at page 41, line 27
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-Sta and time, Service Set Identifier (SSID), Calling-Station-Id or other
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 44, line 5 skipping to change at page 42, line 39
between a authenticator providing confidentiality and another between a authenticator providing confidentiality and another
authenticator that does not support this service. The correct result authenticator that does not support this service. The correct result
of such a fast handoff would be a failure, since if the handoff were of such a fast handoff would be a failure, since if the handoff were
blindly carried out, then the user would be moved from a secure to an blindly carried out, then the user would be moved from a secure to an
insecure channel without permission from the backend authentication insecure channel without permission from the backend authentication
server. Thus the definition of a "known but unsupported service" server. Thus the definition of a "known but unsupported service"
MUST encompass requests for unavailable security services. This MUST encompass requests for unavailable security services. This
includes vendor-specific attributes related to security, such as includes vendor-specific attributes related to security, such as
those described in [RFC2548]. those described in [RFC2548].
5. Security Considerations 6. Security Considerations
5.1. Security Terminology 6.1. Security Terminology
"Cryptographic binding", "Cryptographic separation", "Key strength" "Cryptographic binding", "Cryptographic separation", "Key strength"
and "Mutual authentication" are defined in [RFC3748] and are used and "Mutual authentication" are defined in [RFC3748] and are used
with the same meaning here. with the same meaning here.
5.2. Threat Model 6.2. Threat Model
The EAP threat model is described in [RFC3748] Section 7.1. In order The EAP threat model is described in [RFC3748] Section 7.1. In order
to address these threats, EAP relies on the security properties of to address these threats, EAP relies on the security properties of
EAP methods (known as "security claims", described in [RFC3784] EAP methods (known as "security claims", described in [RFC3784]
Section 7.2.1). EAP method requirements for application such as Section 7.2.1). EAP method requirements for application such as
Wireless LAN authentication are described in [WLANREQ]. Wireless LAN authentication are described in [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
responses to these threats are described in [RFC3579] Sections 4.2 responses to these threats are described in [RFC3579] Sections 4.2
and 4.3. Among other things, [RFC3579] Section 4.2 recommends the and 4.3. Among other things, [RFC3579] Section 4.2 recommends the
skipping to change at page 45, line 47 skipping to change at page 44, line 33
Unique naming Unique naming
Session keys must be uniquely named. Session keys must be uniquely named.
Domino effect Domino effect
Compromise of a single authenticator cannot compromise any other Compromise of a single authenticator cannot compromise any other
part of the system, including session keys and long-term secrets. part of the system, including session keys and long-term secrets.
Key binding Key binding
The key must be bound to the appropriate context. The key must be bound to the appropriate context.
5.3. Security Analysis 6.3. Security Analysis
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
[RFC3748] Section 7.2. These include the key strength, protected [RFC3748] Section 7.2. These include the key strength, protected
ciphersuite negotiation, mutual authentication, integrity protection, ciphersuite negotiation, mutual authentication, integrity protection,
replay protection, confidentiality, key derivation, key strength, replay protection, confidentiality, key derivation, key strength,
dictionary attack resistance, fast reconnect, cryptographic binding, dictionary attack resistance, fast reconnect, cryptographic binding,
session independence, fragmentation and channel binding claims. At a session independence, fragmentation and channel binding claims. At a
minimum, methods claiming to support key derivation must also support minimum, methods claiming to support key derivation must also support
mutual authentication. As noted in [RFC3748] Section 7.10: mutual authentication. As noted in [RFC3748] Section 7.10:
skipping to change at page 49, line 4 skipping to change at page 47, line 37
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 hijac vulnerable to hijack.
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 49, line 27 skipping to change at page 48, line 11
possession of the AAA-Key material, then the peer will not have possession of the AAA-Key material, then the peer will not have
assurance that it is connected to the correct authenticator, only assurance that it is connected to the correct authenticator, only
that the authenticator and backend authentication server share a that the authenticator and backend authentication server share a
trust relationship (since AAA protocols support mutual trust relationship (since AAA protocols support mutual
authentication). This distinction can become important when multiple authentication). This distinction can become important when multiple
authenticators receive AAA-Keys from the backend authentication authenticators receive AAA-Keys from the backend authentication
server, such as where fast handoff is supported. If the TSK server, such as where fast handoff is supported. If the TSK
derivation does not provide for protected ciphersuite and derivation does not provide for protected ciphersuite and
capabilities negotiation, then downgrade attacks are possible. capabilities negotiation, then downgrade attacks are possible.
5.4. Man-in-the-middle Attacks 6.4. Man-in-the-middle Attacks
As described in [I-D.puthenkulam-eap-binding], EAP method sequences As described in [I-D.puthenkulam-eap-binding], EAP method sequences
and compound authentication mechanisms may be subject to man-in-the- and compound authentication mechanisms may be subject to man-in-the-
middle attacks. When such attacks are successfully carried out, the middle attacks. When such attacks are successfully carried out, the
attacker acts as an intermediary between a victim and a legitimate attacker acts as an intermediary between a victim and a legitimate
authenticator. This allows the attacker to authenticate successfully authenticator. This allows the attacker to authenticate successfully
to the authenticator, as well as to obtain access to the network. to the authenticator, as well as to obtain access to the network.
In order to prevent these attacks, [I-D.puthenkulam-eap-binding] In order to prevent these attacks, [I-D.puthenkulam-eap-binding]
recommends derivation of a compound key by which the EAP peer and recommends derivation of a compound key by which the EAP peer and
server can prove that they have participated in the entire EAP server can prove that they have participated in the entire EAP
exchange. Since the compound key must not be known to an attacker exchange. Since the compound key must not be known to an attacker
posing as an authenticator, and yet must be derived from quantities posing as an authenticator, and yet must be derived from quantities
that are exported by EAP methods, it may be desirable to derive the that are exported by EAP methods, it may be desirable to derive the
compound key from a portion of the EMSK. In order to provide proper compound key from a portion of the EMSK. In order to provide proper
key hygiene, it is recommended that the compound key used for man-in- key hygiene, it is recommended that the compound key used for man-in-
the-middle protection be cryptographically separate from other keys the-middle protection be cryptographically separate from other keys
derived from the EMSK, such as fast handoff keys, discussed in derived from the EMSK, such as fast handoff keys, discussed in
Section 2.5. Section 2.3.
5.5. Denial of Service Attacks 6.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.
As a result, EAP methods creating persistent state may wish to limit As a result, EAP methods creating persistent state may wish to limit
the number of cached EAP SAs (Phase 1a) corresponding to an EAP peer. the number of cached EAP SAs (Phase 1a) corresponding to an EAP peer.
skipping to change at page 50, line 25 skipping to change at page 49, line 11
corresponding to a given EAP peer; to conserve resources an corresponding to a given EAP peer; to conserve resources an
authenticator may choose to limit the number of cached AAA-Key (Phase authenticator may choose to limit the number of cached AAA-Key (Phase
1 b) SAs for each peer. 1 b) SAs for each peer.
Depending on the media, creation of a new unicast Secure Association Depending on the media, creation of a new unicast Secure Association
SA may or may not imply deletion of a previous unicast secure SA may or may not imply deletion of a previous unicast secure
association SA. Where there is no implied deletion, the association SA. Where there is no implied deletion, the
authenticator may choose to limit Phase 2 (unicast and multicast) authenticator may choose to limit Phase 2 (unicast and multicast)
Secure Association SAs for each peer. Secure Association SAs for each peer.
5.6. Impersonation 6.6. Impersonation
Both the RADIUS and Diameter protocols are potentially vulnerable to Both the RADIUS and Diameter protocols are potentially vulnerable to
impersonation by a rogue authenticator. impersonation by a rogue authenticator.
While AAA protocols such as RADIUS [RFC2865] or Diameter [RFC3588] While AAA protocols such as RADIUS [RFC2865] or Diameter [RFC3588]
support mutual authentication between the authenticator (known as the support mutual authentication between the authenticator (known as the
AAA client) and the backend authentication server (known as the AAA AAA client) and the backend authentication server (known as the AAA
server), the security mechanisms vary according to the AAA protocol. server), the security mechanisms vary according to the AAA protocol.
In RADIUS, the shared secret used for authentication is determined by In RADIUS, the shared secret used for authentication is determined by
skipping to change at page 51, line 32 skipping to change at page 50, line 17
logged. logged.
While [RFC3588] requires use of the Route-Record AVP, this utilizes While [RFC3588] requires use of the Route-Record AVP, this utilizes
FQDNs, so that impersonation detection requires DNS A/AAAA and PTR FQDNs, so that impersonation detection requires DNS A/AAAA and PTR
RRs to be properly configured. As a result, it appears that Diameter RRs to be properly configured. As a result, it appears that Diameter
is as vulnerable to this attack as RADIUS, if not more so. To address is as vulnerable to this attack as RADIUS, if not more so. To address
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 6.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 AAA or the 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.
skipping to change at page 52, line 30 skipping to change at page 51, line 11
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. For example, see against those exchanged within the EAP method. For example, see
[ServiceIdent]. [ServiceIdent].
5.8. Key Strength 7. Security Requirements
In order to guard against brute force attacks, EAP methods deriving
keys need to be capable of generating keys with an appropriate
effective symmetric key strength. In order to ensure that key
generation is not the weakest link, it is necessary for EAP methods
utilizing public key cryptography to choose a public key that has a
cryptographic strength meeting the symmetric key strength
requirement.
As noted in [RFC3766] Section 5, this results in the following
required RSA or DH module and DSA subgroup size in bits, for a given
level of attack resistance in bits:
Attack Resistance RSA or DH Modulus DSA subgroup
(bits) size (bits) size (bits)
----------------- ----------------- ------------
70 947 128
80 1228 145
90 1553 153
100 1926 184
150 4575 279
200 8719 373
250 14596 475
5.9. Key Wrap
As described in [RFC3579] Section 4.3, known problems exist in the
key wrap specified in [RFC2548]. Where the same RADIUS shared secret
is used by a PAP authenticator and an EAP authenticator, there is a
vulnerability to known plaintext attack. Since RADIUS uses the
shared secret for multiple purposes, including per-packet
authentication, attribute hiding, considerable information is exposed
about the shared secret with each packet. This exposes the shared
secret to dictionary attacks. MD5 is used both to compute the RADIUS
Response Authenticator and the Message-Authenticator attribute, and
some concerns exist relating to the security of this hash
[MD5Attack].
As discussed in [RFC3579] Section 4.3, the security vulnerabilities
of RADIUS are extensive, and therefore development of an alternative
key wrap technique based on the RADIUS shared secret would not
substantially improve security. As a result, [RFC3759] Section 4.2
recommends running RADIUS over IPsec. The same approach is taken in
Diameter EAP [I-D.ietf-aaa-eap], which defines cleartext key
attributes, to be protected by IPsec or TLS.
Where an untrusted AAA intermediary is present (such as a RADIUS
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
intermediary. Possession of the AAA-Key enables decryption of data
traffic sent between the peer and a specific authenticator; however
where key separation is implemented, compromise of the AAA-Key does
not enable an attacker to impersonate the peer to another
authenticator, since that requires possession of the EMSK, which is
not transported by the AAA protocol. This vulnerability may be
mitigated by implementation of redirect functionality, as provided in
[RFC3588].
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.
6.1. EAP Method Requirements 7.1. EAP Method Requirements
It is possible for the peer and EAP server to mutually authenticate It is possible for the peer and EAP server to mutually authenticate
and derive keys. In order to provide keying material for use in a and derive keys. In order to provide keying material for use in a
subsequently negotiated ciphersuite, an EAP method supporting key subsequently negotiated ciphersuite, an EAP method supporting key
derivation MUST export a Master Session Key (MSK) of at least 64 derivation MUST export a Master Session Key (MSK) of at least 64
octets, and an Extended Master Session Key (EMSK) of at least 64 octets, and an Extended Master Session Key (EMSK) of at least 64
octets. EAP Methods deriving keys MUST provide for mutual octets. EAP Methods deriving keys MUST provide for mutual
authentication between the EAP peer and the EAP Server. authentication between the EAP peer and the EAP Server.
The MSK and EMSK MUST NOT be used directly to protect data; however, The MSK and EMSK MUST NOT be used directly to protect data; however,
they are of sufficient size to enable derivation of a AAA-Key they are of sufficient size to enable derivation of a AAA-Key
subsequently used to derive Transient Session Keys (TSKs) for use subsequently used to derive Transient Session Keys (TSKs) for use
with the selected ciphersuite. Each ciphersuite is responsible for with the selected ciphersuite. Each ciphersuite is responsible for
specifying how to derive the TSKs from the AAA-Key. specifying how to derive the TSKs from the AAA-Key.
The AAA-Key is derived from the keying material exported by the EAP The AAA-Key is derived from the keying material exported by the EAP
method (MSK and EMSK). This derivation occurs on the AAA server. In method (MSK and EMSK). This derivation occurs on the AAA server. In
many existing protocols that use EAP, the AAA-Key and MSK are many existing protocols that use EAP, the AAA-Key and MSK are
equivalent, but more complicated mechanisms are possible (see Section equivalent, but more complicated mechanisms are possible (see Section
2.5 for details). 2.3 for details).
EAP methods SHOULD ensure the freshness of the MSK and EMSK even in EAP methods SHOULD ensure the freshness of the MSK and EMSK even in
cases where one party may not have a high quality random number cases where one party may not have a high quality random number
generator. A RECOMMENDED method is for each party to provide a nonce generator. A RECOMMENDED method is for each party to provide a nonce
of at least 128 bits, used in the derivation of the MSK and EMSK. of at least 128 bits, used in the derivation of the MSK and EMSK.
EAP methods export the MSK and EMSK and not Transient Session Keys so EAP methods export the MSK and EMSK and not Transient Session Keys so
as to allow EAP methods to be ciphersuite and media independent. as to allow EAP methods to be ciphersuite and media independent.
Keying material exported by EAP methods MUST be independent of the Keying material exported by EAP methods MUST be independent of the
ciphersuite negotiated to protect data. ciphersuite negotiated to protect data.
skipping to change at page 55, line 4 skipping to change at page 52, line 25
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. attack. In order to enable deployments requiring strong keys, EAP
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.
skipping to change at page 55, line 29 skipping to change at page 52, line 49
NOT help in recovering some other non-overlapping substring without NOT help in recovering some other non-overlapping substring without
breaking some hard cryptographic assumption. This is required breaking some hard cryptographic assumption. This is required
because some existing ciphersuites form TSKs by simply splitting the because some existing ciphersuites form TSKs by simply splitting the
AAA-Key to pieces of appropriate length. Likewise, non-overlapping AAA-Key to pieces of appropriate length. Likewise, non-overlapping
substrings of the EMSK MUST be cryptographically separate from each substrings of the EMSK MUST be cryptographically separate from each
other, and from substrings of the MSK. other, and from substrings of the MSK.
The EMSK MUST 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 for purposes other than AMSK derivation (see Section parties, or used for purposes other than AMSK derivation (see Section
2.6). 2.4).
Since EAP does not provide for explicit key lifetime negotiation, EAP Since EAP does not provide for explicit key lifetime negotiation, EAP
peers, authenticators and authentication servers MUST be prepared for peers, authenticators and authentication servers MUST be prepared for
situations in which one of the parties discards key state which situations in which one of the parties discards key state which
remains valid on another party. remains valid on another party.
The development and validation of key derivation algorithms is The development and validation of key derivation algorithms is
difficult, and as a result EAP methods SHOULD reuse well established difficult, and as a result EAP methods SHOULD reuse well established
and analyzed mechanisms for MSK and EMSK key derivation (such as and analyzed mechanisms for MSK and EMSK key derivation (such as
those specified in IKE [RFC2409] or TLS [RFC2246]), rather than those specified in IKE [RFC2409] or TLS [RFC2246]), rather than
inventing new ones. inventing new ones.
6.1.1. Requirements for EAP methods 7.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
skipping to change at page 56, line 21 skipping to change at page 53, line 41
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 a unique identifier suitable for naming the EMSK. o The EAP mechanism SHOULD a unique identifier suitable for naming the EMSK.
Implementations of EAP frameworks on the EAP-Peer and EAP-Server 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 7.1.2. Requirements for EAP applications
In order for an application to meet the guidelines for EMSK usage it In order for an application to meet the guidelines for EMSK usage it
must meet the following requirements: must meet the following requirements:
o New applications following this specification SHOULD NOT use the o New applications following this specification SHOULD NOT use the
MSK. If more than one application uses the MSK, then the MSK. If more than one application uses the MSK, then the
cryptographic separation is not achieved. Implementations SHOULD cryptographic separation is not achieved. Implementations SHOULD
prevent such combinations. prevent such combinations.
o A peer MUST NOT use the EMSK in any other way except to o A peer MUST NOT use the EMSK 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 Section 2.6. It MUST NOT key derivation specified in Section 2.4. 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 Section 2.6. derivation described in Section 2.4.
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 7.2. AAA Protocol Requirements
AAA protocols suitable for use in transporting EAP MUST provide the AAA protocols suitable for use in transporting EAP MUST provide the
following facilities: following facilities:
Security services Security services
AAA protocols used for transport of EAP keying material MUST AAA protocols used for transport of EAP keying material MUST
implement and SHOULD use per-packet integrity and authentication, implement and SHOULD use per-packet integrity and authentication,
replay protection and confidentiality. These requirements are met replay protection and confidentiality. These requirements are met
by Diameter EAP [I-D.ietf-aaa-eap], as well as RADIUS over IPsec by Diameter EAP [I-D.ietf-aaa-eap], as well as RADIUS over IPsec
[RFC3579]. [RFC3579].
skipping to change at page 58, line 23 skipping to change at page 55, line 42
exchange, the AAA-Token SHOULD include explicit key names and exchange, the AAA-Token SHOULD include explicit key names and
context appropriate for informing the authenticator how the keying context appropriate for informing the authenticator how the keying
material is to be used. material is to be used.
Key Compromise Key Compromise
Where untrusted intermediaries are present, the AAA-Token SHOULD Where untrusted intermediaries are present, the AAA-Token SHOULD
NOT be provided to the intermediaries. In Diameter, handling of NOT be provided to the intermediaries. In Diameter, handling of
keys by intermediaries can be avoided using Redirect functionality keys by intermediaries can be avoided using Redirect functionality
[RFC3588]. [RFC3588].
6.3. Secure Association Protocol Requirements 7.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 demo The peer and authenticator MUST each demonstrate possession of the
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 60, line 6 skipping to change at page 57, line 26
keys. Secure capabilities negotiation also includes confirmation keys. Secure capabilities negotiation also includes confirmation
of the capabilities discovered during the discovery phase (phase of the capabilities discovered during the discovery phase (phase
0), so as to ensure that the announced capabilities have not been 0), so as to ensure that the announced capabilities have not been
forged. forged.
Key Scoping Key Scoping
The Secure Association Protocol MUST ensure the synchronization of The Secure Association Protocol MUST ensure the synchronization of
key scope between the peer and authenticator. This includes key scope between the peer and authenticator. This includes
negotiation of restrictions on key usage. negotiation of restrictions on key usage.
6.4. Ciphersuite Requirements 7.4. Ciphersuite Requirements
Ciphersuites suitable for keying by EAP methods MUST provide the Ciphersuites suitable for keying by EAP methods MUST provide the
following facilities: following facilities:
TSK derivation TSK derivation
In order to allow a ciphersuite to be usable within the EAP keying In order to allow a ciphersuite to be usable within the EAP keying
framework, a specification MUST be provided describing how framework, a specification MUST be provided describing how
transient session keys suitable for use with the ciphersuite are transient session keys suitable for use with the ciphersuite are
derived from the AAA-Key. derived from the AAA-Key.
skipping to change at page 60, line 28 skipping to change at page 57, line 48
Algorithms for deriving transient session keys from the AAA-Key Algorithms for deriving transient session keys from the AAA-Key
MUST NOT depend on the EAP method. However, algorithms for MUST NOT depend on the EAP method. However, algorithms for
deriving TEKs MAY be specific to the EAP method. deriving TEKs MAY be specific to the EAP method.
Cryptographic separation Cryptographic separation
The TSKs derived from the AAA-Key MUST be cryptographically The TSKs derived from the AAA-Key MUST be cryptographically
separate from each other. Similarly, TEKs MUST be separate from each other. Similarly, TEKs MUST be
cryptographically separate from each other. In addition, the TSKs cryptographically separate from each other. In addition, the TSKs
MUST be cryptographically separate from the TEKs. MUST be cryptographically separate from the TEKs.
7. IANA Considerations 8. IANA Considerations
This section provides guidance to the Internet Assigned Numbers This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to EAP key Authority (IANA) regarding registration of values related to EAP key
management, in accordance with BCP 26, [RFC2434]. management, in accordance with BCP 26, [RFC2434].
The following terms are used here with the meanings defined in BCP The following terms are used here with the meanings defined in BCP
26: "name space", "assigned value", "registration". 26: "name space", "assigned value", "registration".
The following policies are used here with the meanings defined in BCP The following policies are used here with the meanings defined in BCP
26: "Private Use", "First Come First Served", "Expert Review", 26: "Private Use", "First Come First Served", "Expert Review",
skipping to change at page 61, line 23 skipping to change at page 58, line 43
information: information:
o A description of the application o A description of the application
o The key label to be used o The key label to be used
o How TSKs will be derived from the AMSK and how they will be used o How TSKs will be derived from the AMSK and how they will be used
o If application specific data is used, what it is and how it is o If application specific data is used, what it is and how it is
maintained maintained
o Where the AMSKs or TSKs will be used and how they are o Where the AMSKs or TSKs will be used and how they are
communicated if necessary. communicated if necessary.
8. References 9. References
8.1. Normative References 9.1. Normative References
[RFC2119] [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Bradner, S., "Key words for use in RFCs to Indicate Requirement Requirement Levels", BCP 14, RFC 2119, March 1997.
Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 1998.
[RFC3748] [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H.
Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. Lefkowetz, Lefkowetz, "Extensible Authentication Protocol (EAP)", RFC
"Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. 3748, June 2004.
8.2. Informative References 9.2. Informative References
[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, [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
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 31 skipping to change at page 60, line 48
[IEEE802] Institute of Electrical and Electronics Engineers, "IEEE [IEEE802] Institute of Electrical and Electronics Engineers, "IEEE
Standards for Local and Metropolitan Area Networks: Overview Standards for Local and Metropolitan Area Networks: Overview
and Architecture", ANSI/IEEE Standard 802, 1990. and Architecture", ANSI/IEEE Standard 802, 1990.
[IEEE80211] [IEEE80211]
Institute of Electrical and Electronics Engineers, Institute of Electrical and Electronics Engineers,
"Information technology - Telecommunications and information "Information technology - Telecommunications and information
exchange between systems - Local and metropolitan area exchange between systems - Local and metropolitan area
networks - Specific Requirements Part 11: Wireless LAN Medium networks - Specific Requirements Part 11: Wireless LAN Medium
Access Control (MAC) and Physical Layer (PHY) Specifications", Access Control (MAC) and Physical Layer (PHY) Specifications",
IEEE IEEE Standard 802.11-1999, 1999. IEEE IEEE Standard 802.11-2003, 2003.
[IEEE8021X] [IEEE8021X]
Institute of Electrical and Electronics Engineers, "Local and Institute of Electrical and Electronics Engineers, "Local and
Metropolitan Area Networks: Port-Based Network Access Metropolitan Area Networks: Port-Based Network Access
Control", IEEE Standard 802.1X-2004, September 2004. Control", IEEE Standard 802.1X-2004, December 2004.
[IEEE8021Q] [IEEE8021Q]
Institute of Electrical and Electronics Engineers, "IEEE Institute of Electrical and Electronics Engineers, "IEEE
Standards for Local and Metropolitan Area Networks: Draft Standards for Local and Metropolitan Area Networks: Draft
Standard for Virtual Bridged Local Area Networks", IEEE Standard for Virtual Bridged Local Area Networks", IEEE
Standard 802.1Q/D8, January 1998. Standard 802.1Q/D8, January 1998.
[IEEE80211F] [IEEE80211F]
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. 802.11F, July 2003.
[IEEE80211i] [IEEE80211i]
Institute of Electrical and Electronics Engineers, "Draft Institute of Electrical and Electronics Engineers, "Supplement
Supplement to STANDARD FOR Telecommunications and Information to STANDARD FOR Telecommunications and Information Exchange
Exchange between Systems - LAN/MAN Specific Requirements - between Systems - LAN/MAN Specific Requirements - Part 11:
Part 11: Wireless Medium Access Control (MAC) and physical Wireless Medium Access Control (MAC) and physical layer (PHY)
layer (PHY) specifications: Specification for Enhanced specifications: Specification for Enhanced Security", IEEE
Security", IEEE Draft 802.11I/ D8, February 2004. 802.11i, December 2004.
[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
skipping to change at page 64, line 38 skipping to change at page 62, line 4
IEEE-03-155r0-I, http://www.ieee802.org/11/ IEEE-03-155r0-I, http://www.ieee802.org/11/
Documents/DocumentHolder/3-155.zip, March 2003. Documents/DocumentHolder/3-155.zip, March 2003.
[I-D.ietf-roamops-cert] [I-D.ietf-roamops-cert]
Aboba, B., "Certificate-Based Roaming", draft-ietf-roamops- Aboba, B., "Certificate-Based Roaming", draft-ietf-roamops-
cert-02 (work in progress), April 1999. cert-02 (work in progress), April 1999.
[I-D.ietf-aaa-eap] [I-D.ietf-aaa-eap]
Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application", draft-ietf-aaa- Authentication Protocol (EAP) Application", draft-ietf-aaa-
eap-08 (work in progress), June 2004. eap-10 (work in progress), November 2004.
[I-D.irtf-aaaarch-handoff] [I-D.irtf-aaaarch-handoff]
Arbaugh, W. and B. Aboba, "Handoff Extension to RADIUS", Arbaugh, W. and B. Aboba, "Handoff Extension to RADIUS",
draft-irtf-aaaarch-handoff-04 (work in progress), October draft-irtf-aaaarch-handoff-04 (work in progress), October
2003. 2003.
[I-D.puthenkulam-eap-binding] [I-D.puthenkulam-eap-binding]
Puthenkulam, J., "The Compound Authentication Binding Puthenkulam, J., "The Compound Authentication Binding
Problem", draft-puthenkulam-eap-binding-04 (work in progress), Problem", draft-puthenkulam-eap-binding-04 (work in progress),
October 2003. October 2003.
[I-D.aboba-802-context] [I-D.aboba-802-context]
Aboba, B. and T. Moore, "A Model for Context Transfer in IEEE Aboba, B. and T. Moore, "A Model for Context Transfer in IEEE
802", draft-aboba-802-context-03 (work in progress), October 802", draft-aboba-802-context-03 (work in progress), October
2003. 2003.
[I-D.arkko-pppext-eap-aka] [I-D.arkko-pppext-eap-aka]
Arkko, J. and H. Haverinen, "EAP AKA Authentication", draft- Arkko, J. and H. Haverinen, "EAP AKA Authentication", draft-
arkko-pppext-eap-aka-11 (work in progress), October 2003. arkko-pppext-eap-aka-15.txt (work in progress), December 2004.
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", draft- [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", draft-
ietf-ipsec-ikev2-14 (work in progress), June 2004. ietf-ipsec-ikev2-17 (work in progress), September 2004.
[8021XHandoff] [8021XHandoff]
Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff in a Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff in a
Public Wireless LAN Based on IEEE 802.1X Model", School of Public Wireless LAN Based on IEEE 802.1X Model", School of
Computer Science and Engineering, Seoul National University, Computer Science and Engineering, Seoul National University,
Seoul, Korea, 2002. Seoul, Korea, 2002.
[MD5Attack] [MD5Attack]
Dobbertin, H., "The Status of MD5 After a Recent Attack", Dobbertin, H., "The Status of MD5 After a Recent Attack",
CryptoBytes, Vol.2 No.2, 1996. CryptoBytes, Vol.2 No.2, 1996.
[WLANREQ] Stanley, D., Walker, J. and B. Aboba, "EAP Method Requirements [WLANREQ] Stanley, D., Walker, J. and B. Aboba, "EAP Method Requirements
for Wireless LANs", draft-walker-ieee802-req-02.txt (work in for Wireless LANs", draft-walker-ieee802-req-04.txt (work in
progress), July 2004. progress), August 2004.
[Housley56] [Housley56]
Housley, R., "Key Management in AAA", Presentation to the AAA Housley, R., "Key Management in AAA", Presentation to the AAA
WG at IETF 56, WG at IETF 56,
http://www.ietf.org/proceedings/03mar/slides/aaa-5/index.html, http://www.ietf.org/proceedings/03mar/slides/aaa-5/index.html,
March 2003. March 2003.
Acknowledgments Acknowledgments
Thanks to Arun Ayyagari, Ashwin Palekar, and Tim Moore of Microsoft, Thanks to Arun Ayyagari, Ashwin Palekar, and Tim Moore of Microsoft,
Dorothy Stanley of Agere, Bob Moskowitz of TruSecure, and Russ Dorothy Stanley of Agere, Bob Moskowitz of TruSecure, Jesse Walker of
Housley of Vigil Security for useful feedback. Intel, Joe Salowey of Cisco and Russ 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 98 Redmond, WA 98052
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 73, line 5 skipping to change at page 70, line 5
attribute, followed by the contents of the NONCE_MT field in the attribute, followed by the contents of the NONCE_MT field in the
AT_NONCE_MT attribute. AT_NONCE_MT attribute.
The EAP peer name is the contents of the Identity field from the The EAP peer name is the contents of the Identity field from the
AT_IDENTITY attribute, using only the Actual Identity Length octets AT_IDENTITY attribute, using only the Actual Identity Length octets
from the beginning, however. Note that the contents are used as they from the beginning, however. Note that the contents are used as they
are transmitted, regardless of whether the transmitted identity was a are transmitted, regardless of whether the transmitted identity was a
permanent, pseudonym, or fast reauthentication identity. The EAP permanent, pseudonym, or fast reauthentication identity. The EAP
server name is an empty string. server name is an empty string.
INTERNET-DRAFT EAP Key Manageme Appendix F - Security Association Examples
nt Framework 14 November 2004
EAP Method SA Example: EAP-TLS
In EAP-TLS [RFC2716], after the EAP authentication the client (peer)
and server can store the following information:
o Implicitly, the EAP method this SA refers to (EAP-TLS)
o Session identifier (a value selected by the server)
o Certificate of the other party (server stores the client's
certificate and vice versa)
o Ciphersuite and compression method
o TLS Master secret (known as the EAP-TLS Master Key)
o SA lifetime (ensuring that the SA is not stored forever)
o If the client has multiple different credentials (certificates
and corresponding private keys), a pointer to those credentials
When the server initiates EAP-TLS, the client can look up the EAP-TLS
SA based on the credentials it was going to use (certificate and
private key), and the expected credentials (certificate or name) of
the server. If an EAP-TLS SA exists, and it is not too old, the
client informs the server about the existence of this SA by including
its Session-Id in the TLS ClientHello message. The server then looks
up the correct SA based on the Session-Id (or detects that it doesn't
yet have one).
EAP Method SA Example: EAP-AKA
In EAP-AKA [I-D.arkko-pppext-eap-aka], after EAP authentication the
client and server can store the following information:
o Implicitly, the EAP method this SA refers to (EAP-AKA)
o A re-authentication pseudonym
o The client's permanent identity (IMSI)
o Replay protection counter
o Authentication key (K_aut)
o Encryption key (K_encr)
o Original Master Key (MK)
o SA lifetime (ensuring that the SA is not stored forever)
When the server initiates EAP-AKA, the client can look up the EAP-AKA
SA based on the credentials it was going to use (permanent identity).
If an EAP-AKA SA exists, and it is not too old, the client informs
the server about the existence of this SA by sending its re-
authentication pseudonym as its identity in EAP Identity Response
message, instead of its permanent identity. The server then looks up
the correct SA based on this identity.
AAA SA Example: RADIUS
In RADIUS, where shared secret authentication is used, the client and
server store each other's IP address and the shared secret, which is
used to calculate the Response Authenticator [RFC2865] and Message-
Authenticator [RFC3579] values, and to encrypt some attributes (such
as the AAA-Key, see [RFC3580] Section 3.16).
Where IPsec is used to protect RADIUS [RFC3579] and IKE is used for
key management, the parties store information necessary to
authenticate and authorize the other party (e.g. certificates, trust
anchors and names). The IKE exchange results in IKE Phase 1 and Phase
2 SAs containing information used to protect the conversation
(session keys, selected ciphersuite, etc.)
AAA SA Example: Diameter with TLS
When using Diameter protected by TLS, the parties store information
necessary to authenticate and authorize the other party (e.g.
certificates, trust anchors and names). The TLS handshake results in
a short-term TLS SA that contains information used to protect the
actual communications (session keys, selected TLS ciphersuite, etc.).
Service SA Example: 802.11i
[IEEE802.11i] Section 8.4.1.1 defines the security associations used
within IEEE 802.11. A summary follows; the standard should be
consulted for details.
o Pairwise Master Key Security Association (PMKSA)
The PMKSA is a bi-directional SA, used by both parties for sending
and receiving. The PMKSA is the Root Service SA. It is created
on the peer when EAP authentication completes successfully or a
pre-shared key is configured. The PMKSA is created on the
authenticator when the PMK is received or created on the
authenticator or a pre-shared key is configured. The PMKSA is
used to create the PTKSA. PMKSAs are cached for their lifetimes.
The PMKSA consists of the following elements:
- PMKID (security association identifier)
- Authenticator MAC address
- PMK
- Lifetime
- Authenticated Key Management Protocol (AKMP)
- Authorization parameters specified by the AAA server or
by local configuration. This can include
parameters such as the peer's authorized SSID.
On the peer, this information can be locally
configured.
- Key replay counters (for EAPOL-Key messages)
- Reference to PTKSA (if any), needed to:
o delete it (e.g. AAA server-initiated disconnect)
o replace it when a new four-way handshake is done
- Reference to accounting context, the details of which depend
on the accounting protocol used, the implementation
and administrative details. In RADIUS, this could include
(e.g. packet and octet counters, and Acct-Multi-Session-Id).
o Pairwise Transient Key Security Association (PTKSA)
The PTKSA is a bi-directional SA created as the result of a
successful four-way handshake. The PTKSA is a unicast service SA.
There may only be one PTKSA between a pair of peer and
authenticator MAC addresses. PTKSAs are cached for the lifetime
of the PMKSA. Since the PTKSA is tied to the PMKSA, it only has
the additional information from the 4-way handshake. The PTKSA
consists of the following:
- Key (PTK)
- Selected ciphersuite
- MAC addresses of the parties
- Replay counters, and ciphersuite specific state
- Reference to PMKSA: This is needed when:
o A new four-way handshake is needed (lifetime, TKIP
countermeasures), and we need to know which PMKSA to use
o Group Transient Key Security Association (GTKSA)
The GTKSA is a uni-directional SA created based on the four-way
handshake or the group key handshake. The GTKSA is a multicast
service SA. A GTKSA consists of the following:
- Direction vector (whether the GTK is used for transmit or receive)
- Group cipher suite selector
- Key (GTK)
- Authenticator MAC address
- Via reference to PMKSA, or copied here:
o Authorization parameters
o Reference to accounting context
Service SA Example: IKEv2/IPsec
Note that this example is intended to be informative, and it does
not necessarily include all information stored.
o IKEv2 SA
- Protocol version
- Identities of the parties
- IKEv2 SPIs
- Selected ciphersuite
- Replay protection counters (Message ID)
- Keys for protecting IKEv2 messages (SK_ai/SK_ar/SK_ei/SK_er)
- Key for deriving keys for IPsec SAs (SK_d)
- Lifetime information
- On the authenticator, service authorization information
received from the backend authentication server.
When processing an incoming message, the correct SA is looked up
based on the SPIs.
o IPsec SAs/SPD
- Traffic selectors
- Replay protection counters
- Selected ciphersuite
- IPsec SPI
- Keys
- Lifetime information
- Protocol mode (tunnel or transport)
The correct SA is looked up based on SPI (for inbound packets), or
SPD traffic selectors (for outbound traffic). A separate IPsec SA
exists for each direction.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property 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 73, line 42 skipping to change at page 74, line 20
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Open Issues Open Issues
Open issues relating to this specification are tracked on the Open issues relating to this specification are tracked on the
following web site: following web site:
http://www.drizzle.com/~aboba/EAP/eapissues.html http://www.drizzle.com/~aboba/EAP/eapissues.html
 End of changes. 

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