< draft-ietf-eap-keying-02.txt   draft-ietf-eap-keying-03.txt >
EAP Working Group Bernard Aboba EAP Working Group Bernard Aboba
INTERNET-DRAFT Dan Simon INTERNET-DRAFT Dan Simon
Category: Informational Microsoft Category: Informational Microsoft
<draft-ietf-eap-keying-02.txt> J. Arkko <draft-ietf-eap-keying-03.txt> J. Arkko
26 June 2004 Ericsson 18 July 2004 Ericsson
P. Eronen P. Eronen
Nokia Nokia
H. Levkowetz, Ed. H. Levkowetz, Ed.
ipUnplugged ipUnplugged
Extensible Authentication Protocol (EAP) Key Management Framework Extensible Authentication Protocol (EAP) Key Management Framework
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
skipping to change at page 2, line 16 skipping to change at page 2, line 16
1. Introduction .......................................... 4 1. Introduction .......................................... 4
1.1 Requirements Language ........................... 4 1.1 Requirements Language ........................... 4
1.2 Terminology ..................................... 4 1.2 Terminology ..................................... 4
1.3 Overview ........................................ 5 1.3 Overview ........................................ 5
1.4 EAP Invariants .................................. 11 1.4 EAP Invariants .................................. 11
2. EAP Key Hierarchy ..................................... 13 2. EAP Key Hierarchy ..................................... 13
2.1 Key Terminology ................................. 13 2.1 Key Terminology ................................. 13
2.2 Key Hierarchy ................................... 15 2.2 Key Hierarchy ................................... 15
2.3 Key Lifetimes ................................... 17 2.3 Key Lifetimes ................................... 17
2.4 AAA-Key Scope ................................... 24 2.4 Key Naming ...................................... 24
2.5 Fast Handoff Support ............................ 26 3. Security associations ................................. 26
3. Security associations ................................. 30 3.1 EAP Method SA ................................... 26
3.1 EAP Method SA ................................... 31 3.2 EAP-Key SA ...................................... 28
3.2 EAP-Key SA ...................................... 33 3.3 AAA SA(s) ....................................... 28
3.3 AAA SA(s) ....................................... 33 3.4 Service SA(s) ................................... 29
3.4 Service SA(s) ................................... 34 4. Handoff Support ....................................... 34
3.5 SA Naming ....................................... 37 4.1 Key Scope Issues ................................ 35
4. Security Considerations .............................. 39 4.2 Authorization Issues ............................ 36
4.1 Security Terminology ............................ 39 4.3 Correctness Issues .............................. 38
4.2 Threat Model .................................... 39 5. Security Considerations .............................. 40
4.3 Security Analysis ............................... 41 5.1 Security Terminology ............................ 40
4.4 Man-in-the-middle Attacks ....................... 45 5.2 Threat Model .................................... 41
4.5 Denial of Service Attacks ....................... 45 5.3 Security Analysis ............................... 43
4.6 Impersonation ................................... 46 5.4 Man-in-the-middle Attacks ....................... 47
4.7 Channel Binding ................................. 47 5.5 Denial of Service Attacks ....................... 47
4.8 Key Strength .................................... 48 5.6 Impersonation ................................... 48
4.9 Key Wrap ........................................ 48 5.7 Channel Binding ................................. 49
5.8 Key Strength .................................... 50
5.9 Key Wrap ........................................ 50
5. Security Requirements ................................. 49 6. Security Requirements ................................. 51
5.1 EAP Method Requirements ......................... 49 6.1 EAP Method Requirements ......................... 51
5.2 AAA Protocol Requirements ....................... 52 6.2 AAA Protocol Requirements ....................... 54
5.3 Secure Association Protocol Requirements ........ 54 6.3 Secure Association Protocol Requirements ........ 55
5.4 Ciphersuite Requirements ........................ 55 6.4 Ciphersuite Requirements ........................ 57
6. IANA Considerations ................................... 56 7. IANA Considerations ................................... 58
7. References ............................................ 56 8. References ............................................ 59
7.1 Normative References ............................ 56 8.1 Normative References ............................ 59
7.2 Informative References .......................... 57 8.2 Informative References .......................... 59
Acknowledgments .............................................. 60 Acknowledgments .............................................. 63
Author's Addresses ........................................... 61 Author's Addresses ........................................... 63
Appendix A - Ciphersuite Keying Requirements ................. 62 Appendix A - Ciphersuite Keying Requirements ................. 65
Appendix B - Transient EAP Key (TEK) Hierarchy ............... 63 Appendix B - Transient EAP Key (TEK) Hierarchy ............... 66
Appendix C - EAP Key Hierarchy ............................... 64 Appendix C - EAP Key Hierarchy ............................... 67
Appendix D - Transient Session Key (TSK) Derivation .......... 66 Appendix D - Transient Session Key (TSK) Derivation .......... 69
Appendix E - AAA-Key Derivation .............................. 67 Appendix E - AAA-Key Derivation .............................. 70
Intellectual Property Statement .............................. 68 Appendix F - AMSK Derivation ................................. 71
Full Copyright Statement ..................................... 68 Intellectual Property Statement .............................. 72
Full Copyright Statement ..................................... 72
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 13, line 32 skipping to change at page 13, line 32
For example, PPP ciphersuite negotiation occurs in the Encryption For example, PPP ciphersuite negotiation occurs in the Encryption
Control Protocol (ECP) [RFC1968]. Since ECP negotiation occurs Control Protocol (ECP) [RFC1968]. Since ECP negotiation occurs
after authentication, unless an EAP method is utilized that after authentication, unless an EAP method is utilized that
supports ciphersuite negotiation, the peer, authenticator and supports ciphersuite negotiation, the peer, authenticator and
backend authentication server may not be able to anticipate the backend authentication server may not be able to anticipate the
negotiated ciphersuite and therefore this information cannot be negotiated ciphersuite and therefore this information cannot be
provided to the EAP method. Since ciphersuite negotiation is provided to the EAP method. Since ciphersuite negotiation is
assumed to occur out-of-band, there is no need for ciphersuite assumed to occur out-of-band, there is no need for ciphersuite
negotiation within EAP. negotiation within EAP.
For example, a peer might be pre-configured with policy indicating
the ciphersuite to be used in communicating with a given
authenticator. Within PPP, the ciphersuite is negotiated within
the Encryption Control Protocol (ECP), after EAP authentication is
completed. Within [IEEE80211i], the AP ciphersuites are advertised
in the Beacon and Probe Responses, and are securely verified during
a 4-way handshake exchange after EAP authentication has completed.
2. EAP Key Hierarchy 2. EAP Key Hierarchy
2.1. Key Terminology 2.1. Key Terminology
The EAP Key Hierarchy makes use of the following types of keys: The EAP Key Hierarchy makes use of the following types of keys:
Long Term Credential Long Term Credential
EAP methods frequently make use of long term secrets in order to EAP methods frequently make use of long term secrets in order to
enable authentication between the peer and server. In the case of enable authentication between the peer and server. In the case of
a method based on pre-shared key authentication, the long term a method based on pre-shared key authentication, the long term
skipping to change at page 14, line 17 skipping to change at page 14, line 23
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.
However, despite the name, the AAA-Key is computed regardless of Despite the name, the AAA-Key is computed regardless of whether a
whether a backend authentication server is present. AAA-Key backend authentication server is present. AAA-Key derivation is
derivation is discussed in Appendix E; in existing implementations discussed in Appendix E; in existing implementations the MSK is
the MSK is used as the AAA-Key. used as the AAA-Key.
Application-specific Master Session Keys (AMSKs) Application-specific Master Session Keys (AMSKs)
Keys derived from the EMSK which are cryptographically separate Keys derived from the EMSK which are cryptographically separate
from each other and may be subsequently used in the derivation of from each other and may be subsequently used in the derivation of
Transient Session Keys (TSKs) for extended uses. AMSK derivation Transient Session Keys (TSKs) for extended uses. AMSK derivation
is discussed in Appendix E. is discussed in Appendix F.
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 17, line 24 skipping to change at page 17, line 30
within a protected package known as the AAA-Token. within a protected package known as the AAA-Token.
The AAA-Key is then used by the peer and authenticator within the The AAA-Key is then used by the peer and authenticator within the
Secure Association Protocol to derive Transient Session Keys (TSKs) Secure Association Protocol to derive Transient Session Keys (TSKs)
required for the negotiated ciphersuite. The TSKs are known only to required for the negotiated ciphersuite. The TSKs are known only to
the peer and authenticator. the peer and authenticator.
2.3. Key Lifetimes 2.3. Key Lifetimes
As noted earlier, the EAP Key Management framework includes several As noted earlier, the EAP Key Management framework includes several
types of keys, including: types of keys. Key lifetime issues associated with each type of key
are discussed in the sections that follow. Challenges include:
[1] Keys calculated locally by the EAP method but not exported
by the EAP method, such as the TEKs.
[2] Keys exported by the EAP method: MSK, EMSK, IV
[3] Keys calculated from exported quantities: AAA-Key, AMSKs.
[4] Keys calculated by the Secure Association Protocol: TSKs.
Key lifetime issues associated with each type of key are discussed in
the sections that follow. Challenges include:
[a] Security. Where key lifetimes cannot be assumed, it may be [a] Security. Where key lifetimes cannot be assumed, it may be
necessary to negotiate them. While key lifetimes may be announced necessary to negotiate them. While key lifetimes may be announced
or negotiated in the clear, a protected lifetime negotiation is or negotiated in the clear, a protected lifetime negotiation is
RECOMMENDED. RECOMMENDED.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ [b] Resource reclamation. While key lifetimes may be securely
| | ^
| EAP Method | |
| | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | |
| | | | | | |
| | EAP Method Key |<->| Long-Term | | |
| | Derivation | | Credential | | |
| | | | | | |
| | | +-+-+-+-+-+-+-+ | Local to |
| | | | EAP |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Method |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| V | | | |
| +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | |
| | TEK | | MSK | |EMSK | |IV | | |
| |Derivation | |Derivation | |Derivation | |Derivation | | |
| +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | |
| | | | | |
| | | | | V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | | ^
| | | |
| MSK (64B) | EMSK (64B) | IV (64B) |
| | | Exported|
| | | by |
V V V EAP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ Method|
| AAA Key Derivation, | | Known | |
| Naming & Binding | |(Not Secret) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ V
| ---+
| Transported |
| AAA-Key by AAA |
| Protocol |
V V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | ^
| TSK | Ciphersuite |
| Derivation | Specific |
| | V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
Figure 3: EAP Key Hierarchy
+-+-+-+-+-+ +-+-+-+-+-+
| | | |
| | | |
| Cipher- | | Cipher- |
| Suite | | Suite |
| | | |
+-+-+-+-+-+ +-+-+-+-+-+
^ ^
| |
| |
| |
V V
+-+-+-+-+-+ +-+-+-+-+-+
| | | |
| |===============| |
| |EAP, TEK Deriv.|Authenti-|
| |<------------->| cator |
| | | |
| | Secure Assoc. | |
| peer |<------------->| (EAP |
| |===============| server) |
| | Link layer | |
| | (PPP,IEEE802) | |
| | | |
|MSK,EMSK | |MSK,EMSK |
| AAA-Key | | AAA-Key |
| (TSKs) | | (TSKs) |
| | | |
+-+-+-+-+-+ +-+-+-+-+-+
^ ^
| |
| MSK, EMSK | MSK, EMSK
| |
| |
+-+-+-+-+-+ +-+-+-+-+-+
| | | |
| EAP | | EAP |
| Method | | Method |
| | | |
| (TEKs) | | (TEKs) |
| | | |
+-+-+-+-+-+ +-+-+-+-+-+
Figure 4: Relationship between EAP peer and authenticator (acting
as an EAP server), where no backend authentication server is
present.
+-+-+-+-+-+ +-+-+-+-+-+
| | | |
| | | |
| Cipher- | | Cipher- |
| Suite | | Suite |
| | | |
+-+-+-+-+-+ +-+-+-+-+-+
^ ^
| |
| |
| |
V V
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
| |===============| |========| |
| |EAP, TEK Deriv.| | | |
| |<-------------------------------->| backend |
| | | | | |
| | Secure Assoc. | | AAA-Key| |
| peer |<------------->|Authenti-|<-------| auth |
| |===============| cator |========| server |
| | Link Layer | | AAA | (EAP |
| | (PPP,IEEE 802)| |Protocol| server) |
|MSK,EMSK | | | | |
| AAA-Key | | AAA-Key | |MSK,EMSK,|
| (TSKs) | | (TSKs) | | AAA-Key |
| | | | | |
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
^ ^
| |
| MSK, EMSK | MSK, EMSK
| |
| |
+-+-+-+-+-+ +-+-+-+-+-+
| | | |
| EAP | | EAP |
| Method | | Method |
| | | |
| (TEKs) | | (TEKs) |
| | | |
+-+-+-+-+-+ +-+-+-+-+-+
Figure 5: Pass-through relationship between EAP peer, authenticator
and backend authentication server.
[b] Resource reclaimation. While key lifetimes may be securely
negotiated, it is possible for the NAS or peer to reboot or reclaim negotiated, it is possible for the NAS or peer to reboot or reclaim
resources, and therefore not be able to cache keys for their full resources, and therefore not be able to cache keys for their full
lifetime. As a result, lifetime negotiation does not guarantee lifetime. As a result, lifetime negotiation does not guarantee
that the key cache will remain sychronized. It is therefore that the key cache will remain synchronized. It is therefore
RECOMMENDED for the lower layer to provide a mechanism for key RECOMMENDED for the lower layer to provide a mechanism for key
state resynchronization. Note that securing this mechanism may be state resynchronization. Note that securing this mechanism may be
difficult since in this situation one or more of the parties difficult since in this situation one or more of the parties
initially do not possess a key with which to protect the initially do not possess a key with which to protect the
resynchronization exchange. resynchronization exchange.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | ^
| EAP Method | |
| | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | |
| | | | | | |
| | EAP Method Key |<->| Long-Term | | |
| | Derivation | | Credential | | |
| | | | | | |
| | | +-+-+-+-+-+-+-+ | Local to |
| | | | EAP |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Method |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| V | | | |
| +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | |
| | TEK | | MSK | |EMSK | |IV | | |
| |Derivation | |Derivation | |Derivation | |Derivation | | |
| +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | |
| | | | | |
| | | | | V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | | ^
| | | |
| MSK (64B) | EMSK (64B) | IV (64B) |
| | | Exported|
| | | by |
V V V EAP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ Method|
| AAA Key Derivation, | | Known | |
| Naming & Binding | |(Not Secret) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ V
| ---+
| Transported |
| AAA-Key by AAA |
| Protocol |
V V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | ^
| TSK | Ciphersuite |
| Derivation | Specific |
| | V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
Figure 3: EAP Key Hierarchy
+-+-+-+-+-+ +-+-+-+-+-+
| | | |
| | | |
| Cipher- | | Cipher- |
| Suite | | Suite |
| | | |
+-+-+-+-+-+ +-+-+-+-+-+
^ ^
| |
| |
| |
V V
+-+-+-+-+-+ +-+-+-+-+-+
| | | |
| |===============| |
| |EAP, TEK Deriv.|Authenti-|
| |<------------->| cator |
| | | |
| | Secure Assoc. | |
| peer |<------------->| (EAP |
| |===============| server) |
| | Link layer | |
| | (PPP,IEEE802) | |
| | | |
|MSK,EMSK | |MSK,EMSK |
| AAA-Key | | AAA-Key |
| (TSKs) | | (TSKs) |
| | | |
+-+-+-+-+-+ +-+-+-+-+-+
^ ^
| |
| MSK, EMSK | MSK, EMSK
| |
| |
+-+-+-+-+-+ +-+-+-+-+-+
| | | |
| EAP | | EAP |
| Method | | Method |
| | | |
| (TEKs) | | (TEKs) |
| | | |
+-+-+-+-+-+ +-+-+-+-+-+
Figure 4: Relationship between EAP peer and authenticator
(acting as an EAP server), where no backend authentication
server is present.
+-+-+-+-+-+ +-+-+-+-+-+
| | | |
| | | |
| Cipher- | | Cipher- |
| Suite | | Suite |
| | | |
+-+-+-+-+-+ +-+-+-+-+-+
^ ^
| |
| |
| |
V V
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
| |===============| |========| |
| |EAP, TEK Deriv.| | | |
| |<-------------------------------->| backend |
| | | | | |
| | Secure Assoc. | | AAA-Key| |
| peer |<------------->|Authenti-|<-------| auth |
| |===============| cator |========| server |
| | Link Layer | | AAA | (EAP |
| | (PPP,IEEE 802)| |Protocol| server) |
|MSK,EMSK | | | | |
| AAA-Key | | AAA-Key | |MSK,EMSK,|
| (TSKs) | | (TSKs) | | AAA-Key |
| | | | | |
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
^ ^
| |
| MSK, EMSK | MSK, EMSK
| |
| |
+-+-+-+-+-+ +-+-+-+-+-+
| | | |
| EAP | | EAP |
| Method | | Method |
| | | |
| (TEKs) | | (TEKs) |
| | | |
+-+-+-+-+-+ +-+-+-+-+-+
Figure 5: Pass-through relationship between EAP peer,
authenticator and backend authentication server.
2.3.1. Local Key Lifetimes 2.3.1. Local Key Lifetimes
The Transient EAP Keys (TEKs) are session keys used to protect the The Transient EAP Keys (TEKs) are session keys used to protect the
EAP conversation. The TEKs are internal to the EAP method and are EAP conversation. The TEKs are internal to the EAP method and are
not exported. They remain valid only for the duration of the EAP not exported. They remain valid only for the duration of the EAP
conversation, and are lost once the EAP conversation completes. conversation, and are lost once the EAP conversation completes.
EAP methods may also implement a cache for other local keying EAP methods may also implement a cache for other local keying
material which may persist for multiple EAP conversations. For material which may persist for multiple EAP conversations. For
example, EAP methods based on TLS (such as EAP-TLS [RFC2716]) derive example, EAP methods based on TLS (such as EAP-TLS [RFC2716]) derive
and cache the TLS Master Secret, typically for substantial time and cache the TLS Master Secret, typically for substantial time
periods. The lifetime of other local keying material calculated periods. The lifetime of other local keying material calculated
within the EAP method is defined by the method. within the EAP method is defined by the method.
2.3.2. Exported Key Lifetimes 2.3.2. Exported Key Lifetimes
All EAP methods generating keys are required to generate the MSK and All EAP methods generating keys are required to generate the MSK and
EMSK, and may optionally generate the IV. However, although new EMSK, and may optionally generate the IV. However, although new
exported keys are generated during reauthentication, the lifetime of exported keys are generated during re-authentication, the lifetime of
exported keys is conceptually distinct from the reauthentication exported keys is conceptually distinct from the re-authentication
time, since while reauthentication causes new exported keys to be time, since while re-authentication causes new exported keys to be
derived, exported keys may be cached on the peer and server after a derived, exported keys may be cached on the peer and server after a
session completes and therefore their lifetime may be greater than session completes and therefore their lifetime may be greater than
the reauthentication time. the re-authentication time.
Although exported keys are generated by the EAP method, most existing Although exported keys are generated by the EAP method, most existing
EAP methods do not negotiate the lifetime of the exported keys. EAP, EAP methods do not negotiate the lifetime of the exported keys. EAP,
defined in [RFC3748], also does not support the negotiation of defined in [RFC3748], also does not support the negotiation of
lifetimes for exported keying material such as the MSK, EMSK and IV. lifetimes for exported keying material such as the MSK, EMSK and IV.
Several mechanisms exist for managing the lifetime of exported EAP Several mechanisms exist for managing the lifetime of exported EAP
keys. Exported EAP keys may be cached on the EAP server as well as keys. Exported EAP keys may be cached on the EAP server as well as
on the peer. On the EAP server, it is RECOMMENDED that the lifetime on the peer. On the EAP server, it is RECOMMENDED that the lifetime
of exported keys be managed as a system parameter. Where the EAP of exported keys be managed as a system parameter. Where the EAP
method does not support the negotiation of the exported key lifetime, method does not support the negotiation of the exported key lifetime,
and where a negotiation mechanism is not provided by the lower lower, and where a negotiation mechanism is not provided by the lower lower,
it is RECOMMENDED that the peer assume a default value of the it is RECOMMENDED that the peer assume a default value of the
exported key lifetime. A value of 8 hours is suggested. exported key lifetime. A value of 8 hours is suggested.
Managing the lifetime of exported keys using a AAA attribute is NOT Attempting to manage the lifetime of the EAP-Key SA using AAA
RECOMMENDED. This is problematic because although this would ensure attributes is NOT RECOMMENDED, since this requires the authenticator
transport of the exported key lifetime between the AAA server and the to maintain EAP-Key SA state. As described in Section 3, EAP-Key SA
authenticator, the goal is to synchronize the exported key lifetime state is typically only maintained on the peer and server, so
between the peer and EAP server. Providing the the exported key requiring EAP-Key SA state to be maintained on the authenticator
lifetime on an per-session basis to the authenticator results in represents an unnecessary additional burden.
requiring the authenticator to maintain EAP-Key SA state. As a
described in Section 3, EAP-Key SA state is typically only maintained
on the peer and server, so that this represents a substantial
additional burden.
2.3.3. Calculated Key Lifetimes 2.3.3. Calculated Key Lifetimes
When keying material exported by EAP methods is replaced, new When keying material exported by EAP methods is replaced, new
calculated keys are also put in place. Similarly, when the keying calculated keys are also put in place. Similarly, when the keying
material exported by EAP methods expires, so do the calculated keys. material exported by EAP methods expires, so do the calculated keys.
As a result, the lifetime of keys calculated from material exported As a result, the lifetime of keys calculated from key material
by EAP methods can be no larger than the lifetime of the keying exported by EAP methods can be no larger than the lifetime of the
material they are calculated from. Since the lifetime of calculated exported keying material.
keys can be less than that of the exported keys they are derived
from, calculated key lifetimes are conceptually distinct from
exported key lifetimes and reauthentication times, and need to be
managed as a separate parameter.
Note that just as the reauthentication time and the exported key However, since the lifetime of calculated keys can be less than that
of the exported keys they are derived from, calculated key lifetimes
are conceptually distinct from exported key lifetimes and re-
authentication times, and need to be managed as a separate parameter.
Note that just as the re-authentication time and the exported key
lifetime are conceptually distinct parameters, so too are calculated lifetime are conceptually distinct parameters, so too are calculated
key lifetimes conceptually distinct from the reauthentication time. key lifetimes conceptually distinct from the re-authentication time.
Today AAA protocols such as RADIUS [RFC2865] support the Session- AAA protocols such as RADIUS [RFC2865] support the Session-Timeout
Timeout attribute. As described in [RFC3580], this may be used to attribute. As described in [RFC3580], this may be used to determine
determine the maximum session time prior to reauthentication. Since the maximum session time prior to re-authentication. Since re-
reauthentication results in the derivation of new exported keys and authentication results in the derivation of new exported keys and the
the transport of a new AAA-Key, while a session is in progress the transport of a new AAA-Key, while a session is in progress the
maximum session time prior to reauthentication places an upper bound maximum session time prior to re-authentication places an upper bound
on the AAA-Key lifetime. on the AAA-Key lifetime.
However, after the session has terminated, it is possible for the However, after the session has terminated, it is possible for the
AAA-Key to be cached on the authenticator. Therefore the AAA-Key AAA-Key to be cached on the authenticator. Therefore the AAA-Key
lifetime may be larger than the reauthentication time. As a result, lifetime may be larger than the re-authentication time. As a result,
the AAA-Key lifetime needs to be managed as a separate parameter. the AAA-Key lifetime needs to be managed as a separate parameter.
Since the lifetime of the AAA-Key within the authenticator key cache Since the lifetime of the AAA-Key within the authenticator key cache
is in part determined by authenticator resources, the AAA-Key is in part determined by authenticator resources, the AAA-Key
lifetime is typically managed as a system parameter on the lifetime is often managed as a system parameter on the authenticator.
authenticator. Since the authenticator may have considerably fewer Since the authenticator may have fewer resources than either the EAP
resources than either the EAP peer or server, it is possible that peer or server, it is possible that AAA-Key lifetime on the
AAA-Key lifetime on the authenticator may be less than exported key authenticator may be less than exported key lifetime maintained by
lifetime maintained by the server, or that the authenticator may need the server, or that the authenticator may need to reclaim AAA-Key
to reclaim AAA-Key resources prior to expiration of the AAA-Key resources prior to expiration of the AAA-Key lifetime. As a result,
lifetime. knowledge of the AAA-Key lifetime may not be sufficient for the peer
to determine whether a particular AAA-Key exists within the key cache
of a given authenticator.
As a result, the primary issue with managing the AAA-Key lifetime is Issues arise when attempting to manage synchronization of calculated
the determination by the peer whether a particular AAA-Key exists key lifetimes between the AAA server and the authenticator using AAA
within the key cache of a given authenticator. Transmitting the AAA- attributes.
Key lifetime from the AAA server to the authenticator is not helpful
in solving this problem in several important scenarios.
Where the AAA-key lifetime is negotiated between the authenticator Failure to mutually prove possession of the AAA-Key during the Secure
and the peer within the Secure Association Protocol, this may be used Association Protocol exchange need not be grounds for deletion of the
by the peer to manage the lifetime of the AAA-Key once the Secure AAA-Key by both parties; rate-limiting Secure Association Protocol
Association Protocol has completed. exchanges could be used to prevent a brute force attack.
However, should a time gap may exist between the time of completion One problem is that the AAA protocol cannot guarantee synchronization
of the EAP method and the initiation of the Secure Association of the peer and authenticator with respect to calculated key
Protocol, the lifetime of the AAA-Key cannot be determined by the lifetimes. While this synchronization could be provided by the
peer during this period. As a result, unless the Secure Association Secure Association Protocol, in situations in which this protocol is
Protocol always follos the completion of the EAP method exchange not run immediately after EAP authentication, the calculated key
without a gap in time, it may not be possible for the peer and lifetime will be undefined during the hiatus between the two
authenticator to negotiate session-specific value of the AAA-Key protocols. This can lead to problems with respect to key cache
lifetime. For example, where EAP pre-authentication is used, the management.
AAA-Key may be derived and remain resident on the peer and
authenticator prior to initiation of the Secure Association Protocol.
However, if the AAA-Key lifetime is managed as an authenticator For example, where the AAA-key lifetime is negotiated between the
system parameter, it may be possible for lower layer solutions to authenticator and the peer within the Secure Association Protocol,
bridge the gap. For example, the lower layer may utilize Discovery this may be used by the peer to manage the lifetime of the AAA-Key
mechanisms to ensure AAA-Key cache synchronization between the peer once the Secure Association Protocol has completed. However, where
and authenticator. EAP pre-authentication is used, a hiatus may exist between the
completion of the EAP method and the initiation of the Secure
Association Protocol, during which peer cannot determine the lifetime
of the AAA-Key.
As a result, unless the AAA-Key lifetime is negotiated within the EAP
method or the lower layer, the peer will not be able to determine a
session-specific AAA-Key lifetime until it attempts to negotiate the
Secure Association Protocol, which could fail due to AAA-Key lifetime
expiration.
One solution is to simplify management of the AAA-Key lifetime by
treating it as a system parameter of the peer, authenticator and
server. This enables a wider range of solutions. For example, the
lower layer may utilize Discovery mechanisms to ensure AAA-Key cache
synchronization between the peer and authenticator.
If the authenticator manages the AAA-Key cache by deleting the oldest If the authenticator manages the AAA-Key cache by deleting the oldest
AAA-Key first (LIFO), the relative creation time of the last AAA-Key AAA-Key first (LIFO), the relative creation time of the last AAA-Key
to be deleted could be advertised with the Discovery phase, enabling 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 peer to determine whether a given AAA-Key had been expired from
the authenticator key cache. the authenticator key cache.
2.3.4. TSK Key Lifetimes 2.3.4. TSK Key Lifetimes
Since the TSKs depend on the AAA-Key, replacement of the AAA-Key Since the TSKs depend on the AAA-Key, replacement of the AAA-Key
implies replacement of the TSKs. However, replacement of the TSKs typically results in replacement of the TSKs. However, deletion of
only implies replacement of the AAA-Key when the TSKs are taken from the AAA-Key does not necessarily imply deletion of the corresponding
a portion of the AAA-Key. 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.
Therefore while the lifetime of the TSKs may be shorter than or equal While the lifetime of the TSKs may be shorter than or equal to the
to the AAA-Key lifetime, the TSK lifetime cannot exceed the AAA-Key AAA-Key lifetime, the TSK lifetime cannot exceed the AAA-Key
lifetime. Where a Secure Association Protocol exists, it is possible lifetime. Where a Secure Association Protocol exists, it is possible
for TSKs to be refreshed prior to reauthentication, and so the TSK for TSKs to be refreshed prior to re-authentication, and so the TSK
Key Lifetime may also be shorter than or equal to the Key Lifetime may also be shorter than or equal to the re-
reauthentication timeout. It is therefore RECOMMENDED that the TSK authentication timeout. It is RECOMMENDED that the TSK Key lifetime
Key lifetime be managed parameter distinct from the reauthentication be managed as a parameter distinct from the re-authentication timeout
timeout and the AAA-Key lifetime (except where the TSK is taken from and the AAA-Key lifetime (except where the TSK is taken from the AAA-
the AAA-Key). Key).
Where TSKs are established as the result of a Secure Association Where TSKs are established as the result of a Secure Association
Protocol exchange, it is RECOMMENDED that the Secure Association Protocol exchange, it is RECOMMENDED that the Secure Association
Protocol include secure negotiation of the TSK lifetime between the Protocol include secure negotiation of the TSK lifetime between the
peer and authenticator. Where the TSK is taken from the AAA-Key, peer and authenticator. Where the TSK is taken from the AAA-Key,
there is no need to manage the TSK lifetime as a separate parameter, there is no need to manage the TSK lifetime as a separate parameter,
since the TSK lifetime and AAA-Key lifetime are identical. since the TSK lifetime and AAA-Key lifetime are identical.
As described in Section 3, TSKs are part of Service SAs which reside As described in Section 3, TSKs are part of Service SAs which reside
on the peer and authenticator and as with the AAA-Key lifetime, the on the peer and authenticator and as with the AAA-Key lifetime, the
TSK lifetime is often determined by authenticator resources. As a TSK lifetime is often determined by authenticator resources. As a
result, the AAA server has no insight into the TSK derivation result, the AAA server has no insight into the TSK derivation
process, and by the principle of ciphersuite independence, it is not process, and by the principle of ciphersuite independence, it is not
appropriate for the AAA server to manage any aspect of the TSK appropriate for the AAA server to manage any aspect of the TSK
derivation process, including the TSK lifetime. derivation process, including the TSK lifetime.
2.4. AAA-Key Scope 2.4. Key Naming
As described in Appendix E, the AAA-Key is calculated from the EMSK
and MSK by the EAP peer and server, and is used as the root of the
ciphersuite-specific key hierarchy. Where a backend authentication
server is present, the AAA-Key is transported from the EAP server to
the authenticator; where it is not present, the AAA-Key is calculated
on the authenticator.
The AAA-Key is restricted to use between the EAP peer that calculates
it, and the authenticator that either calculates it (where no backend
authenticator is present) or receives it from the server (where a
backend authenticator server is present). However, in practice
difficulties arise in ensuring that the AAA-Key is used only within
the defined scope.
A wide variety of authenticator and peer designs need to be
accomodated within the EAP key management framework. An
authenticator may contain multiple physical ports; a single physical
authenticator may, for the purpose of peer discovery, advertise
itself as multiple "virtual authenticators"; authenticators may be
compromised of multiple CPUs; authenticators may utilize clustering
in order to provide load balancing or failover. Similarly, a peer
may support multiple ports; may support multiple CPUs; or may support
clustering.
As illustrated in Figure 1, an EAP peer with multiple ports may be
attached to one or more authenticators, each with multiple ports.
Where an authenticator identifies itself to the peer only via use of
a port identifer (such as a link layer address), it may not be
obvious to the peer which authenticator ports are associated with
which authenticators.
Similarly, where an EAP peer identifies itself using a port
identifier (such as a link layer address), it may not be obvious to
the authenticator which peer ports are associated with which peers.
In such situations, the peer and authenticator may not be able to
determine the appropriate AAA-Key scope.
Additional issues arise when a single physical authenticator
advertises itself as multiple "virtual authenticators". In such a
situation, the EAP peer may act as though each "virtual
authenticator" represented a distinct physical authenticator, thereby
restricting the AAA-Key to use with the "virtual authenticator" that
it interacts with. However, depending on the architecture of the
physical AP, it may or may not share AAA-Keys between "virtual
authenticators". Once again, the peer and authenticator may not be
in agreement on the AAA-key scope.
This lack of synchronization may create security vulnerabilities.
For example, where the AAA-Key is shared between "virtual
authenticators" an EAP peer could authenticate with the "Guest"
"virtual authenticator" and derive a AAA-Key. The peer could then
use that AAA-Key within the Secure Association Protocol in order to
connect to the "Corporate Intranet" "virtual authenticator" within
the same physical authenticator. If the "virtual authenticators"
share a AAA-Key cache, then the attempt will be successful.
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 Secure Association Protocols utilize peer
and authenticator identities that are unambiguous and do not
incorporate implicit assumptions about peer and authenticator
architectures.
For example, using port-specific MAC addresses as identifiers is a
particularly poor choice, given that peers and authenticators may
have multiple ports.
[c] It is RECOMMENDED that physical authenticators maintain separate
AAA-Key caches for each "virtual authenticator".
[d] Where a "virtual authenticator" is implemented, the AAA client MAY
also be virtualized. Where a "virtual AAA client" is implemented,
each "virtual authenticator" identifies itself distinctly to the
AAA server. Where the AAA client and server communicate directly,
this enables the AAA server to authenticate each "virtual AAA
client" distinctly.
[e] The AAA server and authenticator MAY implement additional
attributes in order to further restrict the AAA-Key scope. When
this is done, it is RECOMMENDED that the Secure Association
Protocol be extended to enable the restrictions to be communicated
between the authenticator and the peer. For example, in 802.11,
the AAA server may provide the authenticator with a list of
authorized Called-Station-Ids and/or SSIDs for which the AAA-Key
is valid, restricting the use of the AAA-Key by the peer.
Similarly, the authenticator may provide the peer with a list of
Calling-Station-Ids for which the AAA-Key is valid.
2.5. Fast Handoff Support
Within EAP, "fast handoff" is defined as a conversation in which the
EAP exchange (phase 1a) and associated AAA passthrough is bypassed,
so as to reduce latency. Depending on the fast handoff mechanism,
AAA-Key transport (phase 1b) may also be bypassed or it may be
provided in a pre-emptive manner as in [IEEE-03-084] and [I-D.irtf-
aaaarch-handoff].
The introduction of fast handoff creates a new class of security
vulnerabilities as well as requirements for the secure handling of
authorization context.
2.5.1. Authorization Issues
In a typical network access scenario (dial-in, wireless LAN, etc.)
access control mechanisms are typically applied. These mechanisms
include user authentication as well as authorization for the offered
service.
As a part of the authentication process, the AAA network determines
the user's authorization profile. The user authorizations are
transmitted by the backend authentication server to the EAP
authenticator (also known as the Network Access Server or
authenticator) included with the AAA-Token, which also contains the
AAA-Key, in Phase 1b of the EAP conversation. Typically, the profile
is determined based on the user identity, but a certificate presented
by the user may also provide authorization information.
The backend authentication server is responsible for making a user
authorization decision, answering the following questions:
[a] Is this a legitimate user for this particular network?
[b] Is this user allowed the type of access he or she is requesting?
[c] Are there any specific parameters (mandatory tunneling, bandwidth,
filters, and so on) that the access network should be aware of for
this user?
[d] Is this user within the subscription rules regarding time of day?
[e] Is this user within his limits for concurrent sessions?
[f] Are there any fraud, credit limit, or other concerns that indicate
that access should be denied?
While the authorization decision is in principle simple, the process
is complicated by the distributed nature of AAA decision making.
Where brokering entities or proxies are involved, all of the AAA
devices in the chain from the authenticator to the home AAA server
are involved in the decision. For instance, a broker can disallow
access even if the home AAA server would allow it, or a proxy can add
authorizations (e.g., bandwidth limits).
Decisions can be based on static policy definitions and profiles as
well as dynamic state (e.g. time of day or limits on the number of
concurrent sessions). In addition to the Accept/Reject decision made
by the AAA chain, parameters or constraints can be communicated to
the authenticator.
The criteria for Accept/Reject decisions or the reasons for choosing
particular authorizations are typically not communicated to the
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
authorization parameters sent because this service is always provided
to the user, or was the decision based on the time/day and the
capabilities of the requesting authenticator device?
2.5.2. Correctness in Fast Handoff
Bypassing all or portions of the AAA conversation creates challenges
in ensuring that authorization is properly handled. These include:
[a] Consistent application of session time limits. A fast handoff MSK Name
should not automatically increase the available session time,
allowing a user to endlessly extend their network access by
changing the point of attachment.
[b] Avoidance of privilege elevation. A fast handoff should not result This key is created between the EAP peer and EAP server, and is
in a user being granted access to services which they are not uniquely named by the concatenation of the string "MSK", EAP
entitled to. Method Type, EAP peer name, EAP server name, EAP peer nonce, and
the EAP server nonce. Here the EAP peer name and EAP server name
are the identifiers securely exchanged within the EAP method.
Since multiple MSKs may exist between an EAP peer and EAP server,
the EAP peer nonce and EAP server nonce allow MSKs to be
differentiated; at least one of these nonces is necessary. The
inclusion of the Method Type in the name ensures that each EAP
method has a distinct name space.
[c] Consideration of dynamic state. In situations in which dynamic Note that the components of the MSK Name are only known by the EAP
state is involved in the access decision (day/time, simultaneous method. As a result, the MSK Name is exported from the method, and
session limit) it should be possible to take this state into no detailed format of the MSK Name can be specified without a
account either before or after access is granted. Note that reference to a particular method.
consideration of network-wide state such as simultaneous session
limits can typically only be taken into account by the backend
authentication server.
[d] Encoding of restrictions. Since a authenticator may not be aware EMSK Name
of the criteria considered by a backend authentication server when
allowing access, in order to ensure consistent authorization during
a fast handoff it may be necessary to explicitly encode the
restrictions within the authorizations provided in the AAA-Token.
[e] State validity. The introduction of fast handoff should not render The EMSK is named similarly to the above. Its name is the
the authentication server incapable of keeping track of network- concatenation of the string "EMSK", the EAP Method Type, EAP peer
wide state. name, EAP server name, EAP peer nonce, and the EAP server nonce.
A fast handoff mechanism capable of addressing these concerns is Note that neither the MSK nor EMSK names include the authenticator
said to be "correct". One condition for correctness is as follows: identity or the peer or authenticator port over which the EAP
For a fast handoff to be "correct" it MUST establish on the new conversation took place. This is because the MSK and EMSK are not
device the same context as would have been created had the new bound to an authenticator, or to specific ports on the peer or
device completed a AAA conversation with the authentication server. authenticator.
A properly designed fast handoff scheme will only succeed if it is AMSK Name
"correct" in this way. If a successful fast handoff would
establish "incorrect" state, it is preferable for it to fail, in
order to avoid creation of incorrect context.
Some backend authentication server and authenticator configurations AMSKs, if any, may be named by the concatenation of the string
are incapable of meeting this definition of "correctness". For "AMSK", key label, application data (see Appendix F), and EMSK
example, if the old and new device differ in their capabilities, it Name.
may be difficult to meet this definition of correctness in a fast
handoff mechanism that bypasses AAA. Backend authentication
servers often perform conditional evaluation, in which the
authorizations returned in an Access-Accept message are contingent
on the authenticator or on dynamic state such as the time of day or
number of simultaneous sessions. For example, in a heterogeneous
deployment, the backend authentication server might return
different authorizations depending on the authenticator making the
request, in order to make sure that the requested service is
consistent with the authenticator capabilities.
If differences between the new and old device would result in the AAA-Key Name
backend authentication server sending a different set of messages
to the new device than were sent to the old device, then if the
fast handoff mechanism bypasses AAA, then the fast handoff cannot
be carried out correctly.
For example, if some authenticator devices within a deployment The AAA-Key is named by the concatenation of the string "AAA-Key",
support dynamic VLANs while others do not, then attributes present the authenticator name (since the AAA-Key is bound to a particular
in the Access-Request (such as the authenticator-IP-Address, authenticator), and the name of the key from which the AAA-Key is
authenticator-Identifier, Vendor-Identifier, etc.) could be derived (MSK or AMSK Name). For the purpose of identifying the
examined to determine when VLAN attributes will be returned, as authenticator, the contents of the NAS-Identifier attribute is
described in [RFC3580]. VLAN support is defined in [IEEE8021Q]. recommended. In order to ensure that all parties can agree on the
If a fast handoff bypassing the backend authentication server were authenticator name this requires the authenticator to advertise
to occur between a authenticator supporting dynamic VLANs and its name (typically using a lower layer mechanism, such as the
another authenticator which does not, then a guest user with access 802.11 Beacon/Probe Response).
restricted to a guest VLAN could be given unrestricted access to
the network.
Similarly, in a network where access is restricted based on the day Note that the AAA-Key name does not include the peer or
and time, Service Set Identifier (SSID), Calling-Station-Id or authenticator port over which the EAP conversation took place.
other factors, unless the restrictions are encoded within the This is because the AAA-Key is not bound to a specific peer or
authorizations, or a partial AAA conversation is included, then a authenticator port.
fast handoff could result in the user bypassing the restrictions.
In practice, these considerations limit the situations in which PMK Name
fast handoff mechanisms bypassing AAA can be expected to be
successful. Where the deployed devices implement the same set of
services, it may be possible to do successful fast handoffs within
such mechanisms. However, where the supported services differ
between devices, the fast handoff may not succeed. For example,
[RFC2865], section 1.1 states:
"A authenticator that does not implement a given service MUST The PMK has no name of its own, and is only identified by the AAA-
NOT implement the RADIUS attributes for that service. For Key from which it is derived.
example, a authenticator that is unable to offer ARAP service
MUST NOT implement the RADIUS attributes for ARAP. A
authenticator MUST treat a RADIUS access-accept authorizing an
unavailable service as an access-reject instead."
Note that this behavior only applies to attributes that are known, TEKs
but not implemented. For attributes that are unknown, section of 5
of [RFC2865] states:
"A RADIUS server MAY ignore Attributes with an unknown Type. A The TEKs may or may not be named. Their naming is specified in the
RADIUS client MAY ignore Attributes with an unknown Type." EAP method.
In order to perform a correct fast handoff, if a new device is TSKs
provided with RADIUS context for a known but unavailable service,
then it MUST process this context the same way it would handle a
RADIUS Access-Accept requesting an unavailable service. This MUST
cause the fast handoff to fail. However, if a new device is
provided with RADIUS context that indicates an unknown attribute,
then this attribute MAY be ignored.
Although it may seem somewhat counter-intuitive, failure is indeed The TSKs are typically named. Their naming is specified in the
the "correct" result where a known but unsupported service is Secure Association (phase 2) protocol, so that the correct set of
requested. Presumably a correctly configured backend authentication transient session keys can be identified for processing a given
server would not request that a device carry out a service that it packet. Explicit creation and deletion operations are also
does not implement. This implies that if the new device were to typically supported so that establishment and re-establishment of
complete a AAA conversation that it would be likely to receive transient session keys can be synchronized between the parties.
different service instructions. In such a case, failure of the
fast handoff is the desired result. This will cause the new device
to go back to the AAA server in order to receive the appropriate
service definition.
In practice, this implies that fast handoff mechanisms which bypass In order to avoid confusion in the case where an EAP peer has more
AAA are most likely to be successful within a homogeneous device than one AAA-Key (phase 1b) applicable to establishment of a phase
deployment within a single administrative domain. For example, it 2 security association, the secure Association protocol needs to
would not be advisable to carry out a fast handoff bypassing AAA name the AAA-Key so that the appropriate phase 1b keying material
between a authenticator providing confidentiality and another can be identified for use in the Secure Association Protocol
authenticator that does not support this service. The correct exchange.
result 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 insecure channel without permission from the backend
authentication server. Thus the definition of a "known but
unsupported service" MUST encompass requests for unavailable
security services. This includes vendor-specific attributes
related to security, such as those described in [RFC2548].
3. Security Associations 3. Security Associations
During EAP authentication and subsequent exchanges, four types of During EAP authentication and subsequent exchanges, four types of
security associations (SAs) are created: security associations (SAs) are created:
[1] EAP method SA. This SA is between the peer and EAP server. It [1] EAP method SA. This SA is between the peer and EAP server. It
stores state that can be used for "fast resume" or other stores state that can be used for "fast resume" or other
functionality in some EAP methods. Not all EAP methods create such functionality in some EAP methods. Not all EAP methods create such
an SA. an SA.
[2] EAP-Key SA. This is an SA between the peer and EAP server, which [2] EAP-Key SA. This is an SA between the peer and EAP server, which
is used to store the keying material exported by the EAP method. is used to store the keying material exported by the EAP method.
Current EAP server implementations do not retain this SA after the Current EAP server implementations do not retain this SA after the
EAP conversation completes, but future implementations could use EAP conversation completes, but proposals such as [IEEE-03-084] and
this SA for purposes such as pre-emptive key distribution. [I-D.irtf-aaaarch-handoff] use this SA for purposes such as pre-
emptive key distribution.
[3] AAA SA(s). These SAs are between the authenticator and the backend [3] AAA SA(s). These SAs are between the authenticator and the backend
authentication server. They permit the parties to mutually authentication server. They permit the parties to mutually
authenticate each other and protect the communications between authenticate each other and protect the communications between
them. them.
[4] Service SA(s). These SAs are between the peer and authenticator, [4] Service SA(s). These SAs are between the peer and authenticator,
and they are created as a result of phases 1-2 of the conversation and they are created as a result of phases 1-2 of the conversation
(see Section 1.3). (see Section 1.3).
3.1. EAP Method SA (peer - EAP server) 3.1. EAP Method SA (peer - EAP server)
An EAP method may store some state on the peer and EAP server even An EAP method may store some state on the peer and EAP server even
after phase 1a has completed. after phase 1a has completed.
Typically, this is used for "fast resume": the peer and EAP server Typically, this is used for "fast resume": 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 roundtrips or less computational power. In this case, using fewer round-trips or less computational power. In this case,
the EAP method SA is essentially a cache for performance the EAP method SA is essentially a cache for performance
optimization, and either party may remove the SA from its cache at optimization, and either party may remove the SA from its cache at
any point. any point.
An EAP method may also keep state in order to support pseudonym-based An EAP method may also keep state in order to support pseudonym-based
identity protection. This is typically a cache as well (the identity protection. This is typically a cache as well (the
information can be recreated if the original EAP method SA is lost), information can be recreated if the original EAP method SA is lost),
but may be stored for longer periods of time. but may be stored for longer periods of time.
The EAP method SA is not restricted to a particular service or The EAP method SA is not restricted to a particular service or
authenticator and is most useful when the peer accesses many authenticator and is most useful when the peer accesses many
different authenticators. different authenticators. An EAP method is responsible for
specifying how the parties select if an existing EAP method SA should
An EAP method is responsible for specifying how the parties select if be used, and if so, which one. Where multiple backend authentication
an existing EAP method SA should be used, and if so, which one. servers are used, EAP method SAs are not typically synchronized
Where multiple backend authentication servers are used, EAP method between them.
SAs are not typically synchronized between them.
EAP method implementations should consider the appropriate lifetime EAP method implementations should consider the appropriate lifetime
for the EAP method SA. "Fast resume" assumes that the information for the EAP method SA. "Fast resume" assumes that the information
required (primarily the keys in the EAP method SA) hasn't been required (primarily the keys in the EAP method SA) hasn't been
compromised. In case the original authentication was carried out compromised. In case the original authentication was carried out
using, for instance, a smart card, it may be easier to compromise the using, for instance, a smart card, it may be easier to compromise the
EAP method SA (stored on the PC, for instance), so typically the EAP EAP method SA (stored on the PC, for instance), so typically the EAP
method SAs have a limited lifetime. method SAs have a limited lifetime.
Contents: Contents:
o Implicitly, the EAP method this SA refers to o Implicitly, the EAP method this SA refers to
o One or more internal (non-exported) keys o One or more internal (non-exported) keys
o EAP method SA name o EAP method SA name
o SA lifetime o SA lifetime
3.1.1. Example: EAP-TLS 3.1.1. Example: EAP-TLS
In EAP-TLS [RFC2716], after the EAP authentication the client (peer) In EAP-TLS [RFC2716], after the EAP authentication the client (peer)
and server can store the following information: and server can store the following information:
o Implicitly, the EAP method this SA refers to (EAP-TLS) o Implicitly, the EAP method this SA refers to (EAP-TLS)
o Session identifier (a value selected by the server) o Session identifier (a value selected by the server)
o Certificate of the other party (server stores the clients's o Certificate of the other party (server stores the client's
certificate and vice versa) certificate and vice versa)
o Ciphersuite and compression method o Ciphersuite and compression method
o TLS Master secret (known as the EAP-TLS Master Key or MK) o TLS Master secret (known as the EAP-TLS Master Key or MK)
o SA lifetime (ensuring that the SA is not stored forever) o SA lifetime (ensuring that the SA is not stored forever)
o If the client has multiple different credentials (certificates o If the client has multiple different credentials (certificates
and corresponding private keys), a pointer to those credentials and corresponding private keys), a pointer to those credentials
When the server initiates EAP-TLS, the client can look up the EAP-TLS When the server initiates EAP-TLS, the client can look up the EAP-TLS
SA based on the credentials it was going to use (certificate and SA based on the credentials it was going to use (certificate and
private key), and the expected credentials (certificate or name) of private key), and the expected credentials (certificate or name) of
the server. If an EAP-TLS SA exists, and it is not too old, the the server. If an EAP-TLS SA exists, and it is not too old, the
client informs the server about the existence of this SA by including client informs the server about the existence of this SA by including
its Session-Id in the TLS ClientHello message. The server then looks its Session-Id in the TLS ClientHello message. The server then looks
up the correct SA based on the Session-Id (or detects that it doesn't up the correct SA based on the Session-Id (or detects that it doesn't
yet have one). yet have one).
3.1.2. Example: EAP-AKA 3.1.2. Example: EAP-AKA
In EAP-AKA [I-D.arkko-pppext-eap-aka], after EAP authentication the In EAP-AKA [I-D.arkko-pppext-eap-aka], after EAP authentication the
client and server can store the following information: client and server can store the following information:
o Implicitly, the EAP method this SA refers to (EAP-AKA) o Implicitly, the EAP method this SA refers to (EAP-AKA)
o A re-authentication pseudonym o A re-authentication pseudonym
o The client's permanent identity (IMSI) (server) o The client's permanent identity (IMSI)
o Replay protection counter o Replay protection counter
o Authentication key (K_aut) o Authentication key (K_aut)
o Encryption key (K_encr) o Encryption key (K_encr)
o Original Master Key (MK) o Original Master Key (MK)
o SA lifetime (ensuring that the SA is not stored forever) 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 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). 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 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- the server about the existence of this SA by sending its re-
authentication pseudonym as its identity in EAP Identity Response authentication pseudonym as its identity in EAP Identity Response
message, instead of its permanent identity. The server then looks up message, instead of its permanent identity. The server then looks up
the correct SA based on this identity. 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:
o Name/identifier for this SA o MSK and EMSK names
o Identities of the parties
o MSK and EMSK o MSK and EMSK
o SA lifetime o SA lifetime
3.3. AAA SA(s) (authenticator - backend authentication server) 3.3. AAA SA(s) (authenticator - backend authentication server)
In order for the authenticator and backend authentication server to In order for the authenticator and backend authentication server to
authenticate each other, they need to store some information. authenticate each other, they need to store some information.
In case the authenticator and backend authentication server are In case the authenticator and backend authentication server are
colocated, and they communicate using local procedure calls or shared colocated, and they communicate using local procedure calls or shared
skipping to change at page 33, line 42 skipping to change at page 29, line 16
In RADIUS, where shared secret authentication is used, the client and In RADIUS, where shared secret authentication is used, the client and
server store each other's IP address and the shared secret, which is server store each other's IP address and the shared secret, which is
used to calculate the Response Authenticator [RFC2865] and Message- used to calculate the Response Authenticator [RFC2865] and Message-
Authenticator [RFC3579] values, and to encrypt some attributes (such Authenticator [RFC3579] values, and to encrypt some attributes (such
as the AAA-Key [RFC2548]). as the AAA-Key [RFC2548]).
Where IPsec is used to protect RADIUS [RFC3579] and IKE is used for Where IPsec is used to protect RADIUS [RFC3579] and IKE is used for
key management, the parties store information necessary to key management, the parties store information necessary to
authenticate and authorize the other party (e.g. certificates, trust authenticate and authorize the other party (e.g. certificates, trust
anchors and names). The IKE exchange results in IKE Phase 1 and anchors and names). The IKE exchange results in IKE Phase 1 and Phase
Phase 2 SAs containing information used to protect the conversation 2 SAs containing information used to protect the conversation
(session keys, selected ciphersuite, etc.) (session keys, selected ciphersuite, etc.)
3.3.2. Example: Diameter with TLS 3.3.2. Example: Diameter with TLS
When using Diameter protected by TLS, the parties store information When using Diameter protected by TLS, the parties store information
necessary to authenticate and authorize the other party (e.g. necessary to authenticate and authorize the other party (e.g.
certificates, trust anchors and names). The TLS handshake results in certificates, trust anchors and names). The TLS handshake results in
a short-term TLS SA that contains information used to protect the a short-term TLS SA that contains information used to protect the
actual communications (session keys, selected TLS ciphersuite, etc.). actual communications (session keys, selected TLS ciphersuite, etc.).
3.4. Service SA(s) (peer - authenticator) 3.4. Service SA(s) (peer - authenticator)
The service SA stores information about the service being provided. The service SAs store information about the service being provided.
This includes: These include the Root service SA and derived unicast and multicast
service SAs.
The Root service SA is established as the result of the completion of
EAP authentication (phase 1a) and AAA-Key derivation or transport
(phase 1b). It includes:
o Service parameters (or at least those parameters o Service parameters (or at least those parameters
that are still needed) that are still needed)
o On the authenticator, service authorization o On the authenticator, service authorization
information received from the backend authentication information received from the backend authentication
server (or necessary parts of it) server (or necessary parts of it)
o On the peer, usually locally configured service o On the peer, usually locally configured service
authorization information. authorization information.
o Transient Session Keys used to protect the communication
o The AAA-Key, if it can be needed again (to refresh o The AAA-Key, if it can be needed again (to refresh
and/or resynchronize other keys or for another reason) and/or resynchronize other keys or for another reason)
o AAA-Key lifetime o AAA-Key lifetime
The information in the service SA can be grouped into several Unicast and (optionally) multicast service SAs are derived from the
different SAs. This would make sense if, for instance, the service Root service SA, via the Secure Association Protocol. In order for
provided is naturally divided into several different subconversations unicast and multicast service SAs and associated TSKs to be
with different parameters. established, it is not necessary for EAP authentication (phase 1a) to
be rerun each time. Instead, the Secure Association Protocol can be
used to mutually prove possession of the AAA-Key and create
associated unicast (phase 2a) and multicast (phase 2b) service SAs
and TSKs, enabling the EAP exchange to be bypassed. Unicast and
multicast service SAs include:
How exactly the relevant service SA is chosen at each point depends o Service parameters negotiated by the Secure Association Protocol.
on the protocol; see below for examples. o Endpoint identifiers.
o Transient Session Keys used to protect the communication.
o Transient Session Key lifetime.
One function of the Secure Association Protocol is to bind the the
unicast and multicast service SAs and TSKs to endpoint identifiers.
For example, within [IEEE802.11i], the 4-way handshake binds the TSKs
to the MAC addresses of the endpoints; in IKE [RFC2409], the TSKs are
bound to the IP addresses of the endpoints and the negotiated SPI.
It is possible for more than one unicast or multicast service SA to
be derived from a single Root service SA. However, a unicast or
multicast service SA is always descended from only one Root service
SA. Unicast or multicast service SAs descended from the same Root
service SA may utilize the same security parameters (e.g. mode,
ciphersuite, etc.) or they may utilize different parameters.
An EAP peer may be able to negotiate multiple service SAs with a
given authenticator, or may be able to maintain one or more service
SAs with multiple authenticators, depending on the properties of the
media.
Except where explicitly specified by the Secure Association Protocol,
it should not be assumed that the installation of new service SAs
implies deletion of old service SAs. It is possible for multicast
Root service SAs to between the same EAP peer and authenticator;
during a re-key of a unicast or multicast service SA it is possible
for two service SAs to exist during the period between when the new
service SA and corresponding TSKs are calculated and when they are
installed.
Similarly, deletion or creation of a unicast or multicast service SA
does not necessarily imply deletion or creation of related unicast or
multicast service SAs, unless specified by the Secure Association
protocol. For example, a unicast service SA may be rekeyed without
implying a rekey of the multicast service SA.
The deletion of the Root service SA does not necessarily imply the
deletion of the derived unicast and multicast service SAs and
associated TSKs. 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; the action to be taken
is defined by the Secure Association Protocol.
3.4.1. Example: 802.11i 3.4.1. Example: 802.11i
[IEEE802.11i] Section 8.4.1.1 defines the security associations used [IEEE802.11i] Section 8.4.1.1 defines the security associations used
within IEEE 802.11. A summary follows; the standard should be within IEEE 802.11. A summary follows; the standard should be
consulted for details. consulted for details.
o Pairwise Master Key Security Association (PMKSA) o Pairwise Master Key Security Association (PMKSA)
The PMKSA is a bi-directional SA, used by both parties for sending The PMKSA is a bi-directional SA, used by both parties for sending
skipping to change at page 35, line 4 skipping to change at page 31, line 28
PMKSA is created on the authenticator when the PMK is received or PMKSA is created on the authenticator when the PMK is received or
created on the authenticator or a pre-shared key is configured. created on the authenticator or a pre-shared key is configured.
The PMKSA is used to create the PTKSA. PMKSAs are cached for The PMKSA is used to create the PTKSA. PMKSAs are cached for
their lifetimes. The PMKSA consists of the following elements: their lifetimes. The PMKSA consists of the following elements:
- PMKID (security association identifier) - PMKID (security association identifier)
- Authenticator MAC address - Authenticator MAC address
- PMK - PMK
- Lifetime - Lifetime
- Authenticated Key Management Protocol (AKMP) - Authenticated Key Management Protocol (AKMP)
- Authorization parameters specified the AAA server or - Authorization parameters specified by the AAA server or
by local configuration. This can include by local configuration. This can include
parameters such as the peer's authorized SSID. parameters such as the peer's authorized SSID.
On the peer, this information can be locally On the peer, this information can be locally
configured. configured.
- Key replay counters (for EAPOL-Key messages) - Key replay counters (for EAPOL-Key messages)
- Reference to PTKSA (if any), needed to: - Reference to PTKSA (if any), needed to:
o delete it (e.g. AAA server initiated disconnect) o delete it (e.g. AAA server-initiated disconnect)
o replace it when a new four-way handshake is done o replace it when a new four-way handshake is done
- Reference to accounting context (the details of which depend - Reference to accounting context, the details of which depend
on the accounting protocol used, and various implementation on the accounting protocol used, the implementation
and administrative details. In RADIUS, this could include and administrative details. In RADIUS, this could include
(e.g. packet and octet counters, and Acct-Multi-Session-Id). (e.g. packet and octet counters, and Acct-Multi-Session-Id).
o Pairwise Transient Key Security Association (PTKSA) o Pairwise Transient Key Security Association (PTKSA)
The PTKSA is a bi-directional SA created as the result of a The PTKSA is a bi-directional SA created as the result of a
successful four-way handshake. There may only be one PTKSA successful four-way handshake. There may only be one PTKSA
between a pair of peer and authenticator MAC addresses. PTKSAs between a pair of peer and authenticator MAC addresses. PTKSAs
are cached for the lifetime of the PMKSA. Since the PTKSA is tied are cached for the lifetime of the PMKSA. Since the PTKSA is tied
to the PMKSA, it only has the addititional information from the to the PMKSA, it only has the additional information from the
4-way handshake. The PTKSA consists of the following: 4-way handshake. The PTKSA consists of the following:
- Key (PTK) - Key (PTK)
- Selected ciphersuite - Selected ciphersuite
- MAC addresses of the parties - MAC addresses of the parties
- Replay counters, and ciphersuite specific state - Replay counters, and ciphersuite specific state
- Reference to PMKSA: This is needed when: - Reference to PMKSA: This is needed when:
o A new four-way handshake is needed (lifetime, TKIP o A new four-way handshake is needed (lifetime, TKIP
countermeasures), and we need to know which PMKSA to use countermeasures), and we need to know which PMKSA to use
o Group Transient Key Security Association (GTKSA) o Group Transient Key Security Association (GTKSA)
The GTKSA is a uni-directional SA created based on the four-way The GTKSA is a uni-directional SA created based on the four-way
handshake or the group key handshake. A GTKSA consists of the handshake or the group key handshake. A GTKSA consists of the
following: following:
- Direction vector (whether the GTK is used for transmit or receive) - Direction vector (whether the GTK is used for transmit or receive)
- Group cipher suite selector - Group cipher suite selector
- Key (GTK) - Key (GTK)
- Authenticator MAC addres - Authenticator MAC address
- Via reference to PMKSA, or copied here: - Via reference to PMKSA, or copied here:
o Authorization parameters o Authorization parameters
o Reference to accounting context o Reference to accounting context
3.4.2. Example: IKEv2/IPsec 3.4.2. Example: IKEv2/IPsec
Note that this example is intended to be informative, and it does not Note that this example is intended to be informative, and it does not
necessarily include all information stored. necessarily include all information stored.
o IKEv2 SA o IKEv2 SA
- Protocol version - Protocol version
- Identitities of the parties - Identities of the parties
- IKEv2 SPIs - IKEv2 SPIs
- Selected ciphersuite - Selected ciphersuite
- Replay protection counters (Message ID) - Replay protection counters (Message ID)
- Keys for protecting IKEv2 messages (SK_ai/SK_ar/SK_ei/SK_er) - Keys for protecting IKEv2 messages (SK_ai/SK_ar/SK_ei/SK_er)
- Key for deriving keys for IPsec SAs (SK_d) - Key for deriving keys for IPsec SAs (SK_d)
- Lifetime information - Lifetime information
- On the authenticator, service authorization information - On the authenticator, service authorization information
received from the backend authentication server. received from the backend authentication server.
When processing an incoming message, the correct SA is looked up based When processing an incoming message, the correct SA is looked up based
skipping to change at page 36, line 37 skipping to change at page 33, line 9
- Traffic selectors - Traffic selectors
- Replay protection counters - Replay protection counters
- Selected ciphersuite - Selected ciphersuite
- IPsec SPI - IPsec SPI
- Keys - Keys
- Lifetime information - Lifetime information
- Protocol mode (tunnel or transport) - Protocol mode (tunnel or transport)
The correct SA is looked up based on SPI (for inbound packets), or The correct SA is looked up based on SPI (for inbound packets), or
SPD traffic selectors (for outbound traffic). A separate IPsec SA SPD traffic selectors (for outbound traffic). A separate IPsec SA
exists for each direction. exists for each direction.
3.4.3. Sharing service SAs 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.
Whether such a move should be supported or used depends on Whether such a move should be supported or used depends on
implementation and administrative considerations. For instance, an implementation and administrative considerations. For instance, an
administrator may decide to configure a group of IKEv2/IPsec administrator may decide to configure a group of IKEv2/IPsec
skipping to change at page 37, line 35 skipping to change at page 34, line 8
This option usually requires some protocol for transferring the This option usually requires some protocol for transferring the
service SA between the elements. An administrator may decide not to service SA between the elements. An administrator may decide not to
enable this feature at all, and typically the sharing is restricted enable this feature at all, and typically the sharing is restricted
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 1.7). (see Section 4.2).
Note that these considerations are not limited to service Note that these considerations are not limited to service
parameters related to the authenticator--they apply to peer's parameters related to the authenticator--they apply to peer's
parameters as well. parameters as well.
3.5. SA Naming 4. Handoff Support
In order to support the correct processing of phase 2 security Within EAP, a number of mechanisms may be utilized in order to reduce
associations, the Secure Association (phase 2) protocol supports the the latency of handoff between authenticators. One such mechanism is
naming of phase 2 security associations and associated transient EAP pre-authentication, in which EAP is utilized to pre-establish a
session keys, so that the correct set of transient session keys can AAA-Key on an authenticator prior to arrival of the peer.
be identified for processing a given packet. Explicit creation and
deletion operations are also typically supported so that
establishment and re-establishment of transient session keys can be
synchronized between the parties.
In order to securely bind the AAA SA (phase 1b) to its child phase 2 "Fast Handoff" is defined as a conversation in which EAP exchange
security associations, the phase 2 Secure Association Protocol allows (phase 1a) and associated AAA pass-through is bypassed, so as to
the EAP peer and authenticator to mutually prove possession of the reduce latency. Unlike EAP pre-authentication, "Fast Handoff"
AAA-Key. In order to avoid confusion in the case where an EAP peer mechanisms do not result in additional AAA server load. Fast handoff
has more than one AAA-Key (phase 1b) applicable to establishment of a mechanisms include:
phase 2 security association, it is necessary for the secure
Association Protocol (phase 2) to support key selection, so that the
appropriate phase 1b keying material can be utilized by both parties
in the Secure Association Protocol exchange.
For example, a peer might be pre-configured with policy indicating [a] Pre-emptive handoff. In this technique, the AAA server pre-
the ciphersuite to be used in communicating with a given establishes key state on the authenticator prior to arrival of the
authenticator. Within PPP, the ciphersuite is negotiated within the peer, without completion of EAP authentication. As described in
Encryption Control Protocol (ECP), after EAP authentication is [IEEE-03-084] and [I.D.irtf-aaaarch-handoff], this technique
completed. Within [IEEE80211i], the AP ciphersuites are advertised includes conventional AAA-Key transport, but without an EAP
in the Beacon and Probe Responses, and are securely verified during a authentication.
4-way exchange after EAP authentication has completed.
As part of the Secure Association Protocol (phase 2), it is necessary [b] Context transfer. In this technique, the old authenticator
to bind the Transient Session Keys (TSKs) to the keying material transfers the session text to the new authenticator, either prior
provided in the AAA-Token. This ensures that the EAP peer and to, or after the arrival of the peer. As a result, AAA-Key
authenticator are both clear about what key to use to provide mutual transport (phase 1b) is bypassed.
proof of possession.
Keys within the EAP key hierarchy are named as follows: Regardless of how the AAA-Key is provisioned on a given
authenticator, AAA-Key caching may be utilized in order to enable a
peer to quickly re-establish a session with an authenticator.
EAP SA name Where key caching is supported, once the AAA-Key is derived and/or
The EAP security association is negotiated between the EAP peer and transported to the authenticator, it may remain cached on the peer
EAP server, and is uniquely named as follows <EAP peer name, EAP and authenticator, even after a subsequent session terminates. To
server name, EAP Method Type, EAP peer nonce, EAP server nonce>. initiate a subsequent session with the same authenticator, the peer
Here the EAP peer name and EAP server name are the identifiers may utilize the Secure Association Protocol to confirm mutual
securely exchanged within the EAP method. Since multiple EAP SAs possession of the AAA-Key by the peer and authenticator, thereby re-
may exist between an EAP peer and EAP server, the EAP peer nonce activating the AAA-Key for use in a subsequent session.
and EAP server nonce allow EAP SAs to be differentiated. The
inclusion of the Method Type in the EAP SA name ensures that each
EAP method has a distinct EAP SA space.
AAA-Key Name The introduction of handoff support introduces new security
The AAA-Key is named by the concatenation of the EAP SA name, "AAA- vulnerabilities as well as requirements for the secure handling of
Key" and the authenticator name, since the AAA-Key is bound to a authorization context. These issues are discussed in the sections
particular authenticator. For the purpose of identification, the that follow.
NAS-Identifier attribute is recommended. In order to ensure that
all parties can agree on the NAS name this requires the NAS to
advertise its name (typically using a media-specific mechanism,
such as the 802.11 Beacon/Probe Response)."
4. Security considerations 4.1. Key Scope Issues
4.1. Security Terminology As described in Appendix E, the AAA-Key is calculated from the EMSK
and MSK by the EAP peer and server, and is used as the root of the
ciphersuite-specific key hierarchy. Where a backend authentication
server is present, the AAA-Key is transported from the EAP server to
the authenticator; where it is not present, the AAA-Key is calculated
on the authenticator.
Regardless of how many sessions are initiated using it, the AAA-Key
is restricted to use between the EAP peer that calculates it, and the
authenticator that either calculates it (where no backend
authenticator is present) or receives it from the server (where a
backend authenticator server is present). In the process of defining
the scope of the AAA-Key, it should be understood that an
authenticator or peer:
[a] may contain multiple physical ports;
[b] may advertise itself as multiple "virtual" authenticators or peers;
[c] may utilize multiple CPUs;
[d] may support clustering services for load balancing or failover.
As illustrated in Figure 1, an EAP peer with multiple ports may be
attached to one or more authenticators, each with multiple ports.
Where the peer and authenticator identify themselves using a port
identifier such as a link layer address, it may not be obvious to the
peer which authenticator ports are associated with which
authenticators. Similarly, it may not be obvious to the
authenticator which peer ports are associated with which peers. As a
result, the peer and authenticator may not be able to determine the
scope of the AAA-Key.
When a single physical authenticator advertises itself as multiple
"virtual authenticators", the EAP peer and authenticator also may not
be able to agree on the scope of the AAA-Key, creating a security
vulnerability. For example, the peer may assume that the "virtual
authenticators" are distinct and do not share a key cache, whereas,
depending on the architecture of the physical AP, a shared key cache
may or may not be implemented.
Where the AAA-Key is shared between "virtual authenticators" an
attacker acting as a peer could authenticate with the "Guest"
"virtual authenticator" and derive a AAA-Key. If the virtual
authenticators share a key cache, then the peer can utilize the AAA-
Key derived for the "Guest" network to obtain access to the
"Corporate Intranet" virtual authenticator.
Several measures are recommended to address these issues: peers and
authenticators may have multiple ports.
[a] Authenticators are REQUIRED to cache associated authorizations
along with the AAA-Key and apply authorizations consistently. This
ensures that an attacker cannot obtain elevated privileges even
where the AAA-Key cache is shared between "virtual authenticators".
[b] It is RECOMMENDED that physical authenticators maintain separate
AAA-Key caches for each "virtual authenticator".
[c] It is RECOMMENDED that each "virtual authenticator" identify itself
distinctly to the AAA server, such as by utilizing a distinct NAS-
identifier attribute. This enables the AAA server to utilize a
separate credential to authenticate each "virtual authenticator".
[d] It is RECOMMENDED that Secure Association Protocols identify peers
and authenticators unambiguously, without incorporating implicit
assumptions about peer and authenticator architectures. Using
port-specific MAC addresses as identifiers is NOT RECOMMENDED where
peers and authenticators may support multiple ports.
[e] The AAA server and authenticator MAY implement additional
attributes in order to further restrict the AAA-Key scope. For
example, in 802.11, the AAA server may provide the authenticator
with a list of authorized Called or Calling-Station-Ids and/or
SSIDs for which the AAA-Key is valid.
[f] Where the AAA server provides attributes restricting the key scope,
it is RECOMMENDED that restrictions be securely communicated by the
authenticator to the peer. This is typically accomplished using
the Secure Association Protocol, but also can be accomplished via
the EAP method or the lower layer.
4.2. Authorization Issues
In a typical network access scenario (dial-in, wireless LAN, etc.)
access control mechanisms are typically applied. These mechanisms
include user authentication as well as authorization for the offered
service.
As a part of the authentication process, the AAA network determines
the user's authorization profile. The user authorizations are
transmitted by the backend authentication server to the EAP
authenticator (also known as the Network Access Server or
authenticator) included with the AAA-Token, which also contains the
AAA-Key, in Phase 1b of the EAP conversation. Typically, the profile
is determined based on the user identity, but a certificate presented
by the user may also provide authorization information.
The backend authentication server is responsible for making a user
authorization decision, answering the following questions:
[a] Is this a legitimate user for this particular network?
[b] Is this user allowed the type of access he or she is requesting?
[c] Are there any specific parameters (mandatory tunneling, bandwidth,
filters, and so on) that the access network should be aware of for
this user?
[d] Is this user within the subscription rules regarding time of day?
[e] Is this user within his limits for concurrent sessions?
[f] Are there any fraud, credit limit, or other concerns that indicate
that access should be denied?
While the authorization decision is in principle simple, the process
is complicated by the distributed nature of AAA decision making.
Where brokering entities or proxies are involved, all of the AAA
devices in the chain from the authenticator to the home AAA server
are involved in the decision. For instance, a broker can disallow
access even if the home AAA server would allow it, or a proxy can add
authorizations (e.g., bandwidth limits).
Decisions can be based on static policy definitions and profiles as
well as dynamic state (e.g. time of day or limits on the number of
concurrent sessions). In addition to the Accept/Reject decision made
by the AAA chain, parameters or constraints can be communicated to
the authenticator.
The criteria for Accept/Reject decisions or the reasons for choosing
particular authorizations are typically not communicated to the
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
authorization parameters sent because this service is always provided
to the user, or was the decision based on the time/day and the
capabilities of the requesting authenticator device?
4.3. Correctness Issues
Bypassing all or portions of the AAA conversation creates challenges
in ensuring that authorization is properly handled. These include:
[a] Consistent application of session time limits. A fast handoff
should not automatically increase the available session time,
allowing a user to endlessly extend their network access by
changing the point of attachment.
[b] Avoidance of privilege elevation. A fast handoff should not result
in a user being granted access to services which they are not
entitled to.
[c] Consideration of dynamic state. In situations in which dynamic
state is involved in the access decision (day/time, simultaneous
session limit) it should be possible to take this state into
account either before or after access is granted. Note that
consideration of network-wide state such as simultaneous session
limits can typically only be taken into account by the backend
authentication server.
[d] Encoding of restrictions. Since a authenticator may not be aware
of the criteria considered by a backend authentication server when
allowing access, in order to ensure consistent authorization during
a fast handoff it may be necessary to explicitly encode the
restrictions within the authorizations provided in the AAA-Token.
[e] State validity. The introduction of fast handoff should not render
the authentication server incapable of keeping track of network-
wide state.
A fast handoff mechanism capable of addressing these concerns is said
to be "correct". One condition for correctness is as follows: For a
fast handoff to be "correct" it MUST establish on the new device the
same context as would have been created had the new device completed
a AAA conversation with the authentication server.
A properly designed fast handoff scheme will only succeed if it is
"correct" in this way. If a successful fast handoff would establish
"incorrect" state, it is preferable for it to fail, in order to avoid
creation of incorrect context.
Some backend authentication server and authenticator configurations
are incapable of meeting this definition of "correctness". For
example, if the old and new device differ in their capabilities, it
may be difficult to meet this definition of correctness in a fast
handoff mechanism that bypasses AAA. Backend authentication servers
often perform conditional evaluation, in which the authorizations
returned in an Access-Accept message are contingent on the
authenticator or on dynamic state such as the time of day or number
of simultaneous sessions. For example, in a heterogeneous
deployment, the backend authentication server might return different
authorizations depending on the authenticator making the request, in
order to make sure that the requested service is consistent with the
authenticator capabilities.
If differences between the new and old device would result in the
backend authentication server sending a different set of messages to
the new device than were sent to the old device, then if the fast
handoff mechanism bypasses AAA, then the fast handoff cannot be
carried out correctly.
For example, if some authenticator devices within a deployment
support dynamic VLANs while others do not, then attributes present in
the Access-Request (such as the authenticator-IP-Address,
authenticator-Identifier, Vendor-Identifier, etc.) could be examined
to determine when VLAN attributes will be returned, as described in
[RFC3580]. VLAN support is defined in [IEEE8021Q]. If a fast
handoff bypassing the backend authentication server were to occur
between a authenticator supporting dynamic VLANs and another
authenticator which does not, then a guest user with access
restricted to a guest VLAN could be given unrestricted access to the
network.
Similarly, in a network where access is restricted based on the day
and time, Service Set Identifier (SSID), Calling-Station-Id or other
factors, unless the restrictions are encoded within the
authorizations, or a partial AAA conversation is included, then a
fast handoff could result in the user bypassing the restrictions.
In practice, these considerations limit the situations in which fast
handoff mechanisms bypassing AAA can be expected to be successful.
Where the deployed devices implement the same set of services, it may
be possible to do successful fast handoffs within such mechanisms.
However, where the supported services differ between devices, the
fast handoff may not succeed. For example, [RFC2865] section 1.1
states:
"A authenticator that does not implement a given service MUST NOT
implement the RADIUS attributes for that service. For example, a
authenticator that is unable to offer ARAP service MUST NOT
implement the RADIUS attributes for ARAP. A authenticator MUST
treat a RADIUS access-accept authorizing an unavailable service as
an access-reject instead."
Note that this behavior only applies to attributes that are known,
but not implemented. For attributes that are unknown, [RFC2865]
Section 5 states:
"A RADIUS server MAY ignore Attributes with an unknown Type. A
RADIUS client MAY ignore Attributes with an unknown Type."
In order to perform a correct fast handoff, if a new device is
provided with RADIUS context for a known but unavailable service,
then it MUST process this context the same way it would handle a
RADIUS Access-Accept requesting an unavailable service. This MUST
cause the fast handoff to fail. However, if a new device is provided
with RADIUS context that indicates an unknown attribute, then this
attribute MAY be ignored.
Although it may seem somewhat counter-intuitive, failure is indeed
the "correct" result where a known but unsupported service is
requested. Presumably a correctly configured backend authentication
server would not request that a device carry out a service that it
does not implement. This implies that if the new device were to
complete a AAA conversation that it would be likely to receive
different service instructions. In such a case, failure of the fast
handoff is the desired result. This will cause the new device to go
back to the AAA server in order to receive the appropriate service
definition.
In practice, this implies that fast handoff mechanisms which bypass
AAA are most likely to be successful within a homogeneous device
deployment within a single administrative domain. For example, it
would not be advisable to carry out a fast handoff bypassing AAA
between a authenticator providing confidentiality and another
authenticator that does not support this service. The correct result
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
insecure channel without permission from the backend authentication
server. Thus the definition of a "known but unsupported service"
MUST encompass requests for unavailable security services. This
includes vendor-specific attributes related to security, such as
those described in [RFC2548].
5. Security Considerations
5.1. Security Terminology
Cryptographic binding Cryptographic binding
The demonstration of the EAP peer to the EAP server that a single The demonstration of the EAP peer to the EAP server that a single
entity has acted as the EAP peer for all methods executed within a entity has acted as the EAP peer for all methods executed within a
tunnel method. Binding MAY also imply that the EAP server tunnel method. Binding MAY also imply that the EAP server
demonstrates to the peer that a single entity has acted as the EAP demonstrates to the peer that a single entity has acted as the EAP
server for all methods executed within a tunnel method. If server for all methods executed within a tunnel method. If
executed correctly, binding serves to mitigate man-in-the-middle executed correctly, binding serves to mitigate man-in-the-middle
vulnerabilities. vulnerabilities.
skipping to change at page 39, line 46 skipping to change at page 41, line 37
require on average an effort comparable to 2^(N-1) operations of a require on average an effort comparable to 2^(N-1) operations of a
typical block cipher. typical block cipher.
Mutual authentication Mutual authentication
This refers to an EAP method in which, within an interlocked This refers to an EAP method in which, within an interlocked
exchange, the authenticator authenticates the peer and the peer exchange, the authenticator authenticates the peer and the peer
authenticates the authenticator. Two independent one-way methods, authenticates the authenticator. Two independent one-way methods,
running in opposite directions do not provide mutual authentication running in opposite directions do not provide mutual authentication
as defined here. as defined here.
4.2. Threat Model 5.2. Threat Model
The EAP threat model is described in [RFC3748], Section 7.1. In The EAP threat model is described in [RFC3748] Section 7.1. In order
order to address these threats, EAP relies on the security properties to address these threats, EAP relies on the security properties of
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
use of IPsec ESP with non-null transform to provide per-packet use of IPsec ESP with non-null transform to provide per-packet
authentication and confidentiality, integrity and replay protection authentication and confidentiality, integrity and replay protection
for RADIUS/EAP. for RADIUS/EAP.
skipping to change at page 41, line 30 skipping to change at page 43, line 24
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.
4.3. Security Analysis 5.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
skipping to change at page 45, line 9 skipping to change at page 47, line 5
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.
4.4. Man-in-the-middle Attacks 5.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
Appendix E. Appendix E.
4.5. Denial of Service Attacks 5.5. Denial of Service Attacks
The caching of security associations may result in vulnerability to The caching of security associations may result in vulnerability to
denial of service attacks. Since an EAP peer may derive multiple EAP denial of service attacks. Since an EAP peer may derive multiple EAP
SAs with a given EAP server, and creation of a new EAP SA does not SAs with a given EAP server, and creation of a new EAP SA does not
implicitly delete a previous EAP SA, EAP methods that result in implicitly delete a previous EAP SA, EAP methods that result in
creation of persistent state may be vulnerable to denial of service creation of persistent state may be vulnerable to denial of service
attacks by a rogue EAP peer. attacks by a rogue EAP peer.
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 46, line 8 skipping to change at page 48, line 5
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.
4.6. Impersonation 5.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 47, line 15 skipping to change at page 49, line 11
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].
4.7. Channel binding 5.7. Channel binding
It is possible for a compromised or poorly implemented EAP It is possible for a compromised or poorly implemented EAP
authenticator to communicate incorrect information to the EAP peer authenticator to communicate incorrect information to the EAP peer
and/or server. This may enable an authenticator to impersonate and/or server. This may enable an authenticator to impersonate
another authenticator or communicate incorrect information via out- another authenticator or communicate incorrect information via out-
of-band mechanisms (such as via a AAA or lower layer protocol). of-band mechanisms (such as via a AAA or 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
Section 7.15 of [RFC2284bis]. [RFC3748] Section 7.15.
Section 4.3.7 of [RFC3579] 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
correct information to the AAA server while communicating misleading correct information to the AAA server while communicating misleading
information to the EAP peer via a lower layer protocol. information to the EAP peer via a lower layer protocol.
For example, it is possible for a compromised authenticator to For example, it is possible for a compromised authenticator to
utilize another authenticator's Called-Station-Id or NAS-Identifier utilize another authenticator's Called-Station-Id or NAS-Identifier
in communicating with the EAP peer via a lower layer protocol, or for in communicating with the EAP peer via a lower layer protocol, or for
a pass-through authenticator acting as a AAA client to provide an a pass-through authenticator acting as a AAA client to provide an
incorrect peer Calling-Station-Id [RFC2865][RFC3580] to the AAA incorrect peer Calling-Station-Id [RFC2865][RFC3580] to the AAA
server via the AAA protocol. server via the AAA protocol.
As noted in Section 7.15 of [RFC3748] this vulnerability can be As noted in [RFC3748] Section 7.15, this vulnerability can be
addressed by use of EAP methods that support a protected exchange of addressed by use of EAP methods that support a protected exchange of
channel properties such as endpoint identifiers, including (but not channel properties such as endpoint identifiers, including (but not
limited to): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id limited to): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id
[RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address [RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address
[RFC2865], and NAS-IPv6-Address [RFC3162]. [RFC2865], and NAS-IPv6-Address [RFC3162].
Using such a protected exchange, it is possible to match the channel Using such a protected exchange, it is possible to match the channel
properties provided by the authenticator via out-of-band mechanisms properties provided by the authenticator via out-of-band mechanisms
against those exchanged within the EAP method. against those exchanged within the EAP method.
4.8. Key Strength 5.8. Key Strength
In order to guard against brute force attacks, EAP methods deriving In order to guard against brute force attacks, EAP methods deriving
keys need to be capable of generating keys with an appropriate keys need to be capable of generating keys with an appropriate
effective symmetric key strength. In order to ensure that key effective symmetric key strength. In order to ensure that key
generation is not the weakest link, it is necessary for EAP methods generation is not the weakest link, it is necessary for EAP methods
utilizing public key cryptography to choose a public key that has a utilizing public key cryptography to choose a public key that has a
cryptographic strength meeting the symmetric key strength cryptographic strength meeting the symmetric key strength
requirement. requirement.
As noted in Section 5 of [RFC3766], this results in the following 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 required RSA or DH module and DSA subgroup size in bits, for a given
level of attack resistance in bits: level of attack resistance in bits:
Attack Resistance RSA or DH Modulus DSA subgroup Attack Resistance RSA or DH Modulus DSA subgroup
(bits) size (bits) size (bits) (bits) size (bits) size (bits)
----------------- ----------------- ------------ ----------------- ----------------- ------------
70 947 128 70 947 128
80 1228 145 80 1228 145
90 1553 153 90 1553 153
100 1926 184 100 1926 184
150 4575 279 150 4575 279
200 8719 373 200 8719 373
250 14596 475 250 14596 475
4.9. Key Wrap 5.9. Key Wrap
As described in [RFC3579], Section 4.3, known problems exist in the As described in [RFC3579] Section 4.3, known problems exist in the
key wrap specified in [RFC2548]. Where the same RADIUS shared secret key wrap specified in [RFC2548]. Where the same RADIUS shared secret
is used by a PAP authenticator and an EAP authenticator, there is a is used by a PAP authenticator and an EAP authenticator, there is a
vulnerability to known plaintext attack. Since RADIUS uses the vulnerability to known plaintext attack. Since RADIUS uses the
shared secret for multiple purposes, including per-packet shared secret for multiple purposes, including per-packet
authentication, attribute hiding, considerable information is exposed authentication, attribute hiding, considerable information is exposed
about the shared secret with each packet. This exposes the shared about the shared secret with each packet. This exposes the shared
secret to dictionary attacks. MD5 is used both to compute the RADIUS secret to dictionary attacks. MD5 is used both to compute the RADIUS
Response Authenticator and the Message-Authenticator attribute, and Response Authenticator and the Message-Authenticator attribute, and
some concerns exist relating to the security of this hash some concerns exist relating to the security of this hash
[MD5Attack]. [MD5Attack].
As discussed in [RFC3579], Section 4.3, the security vulnerabilities As discussed in [RFC3579] Section 4.3, the security vulnerabilities
of RADIUS are extensive, and therefore development of an alternative of RADIUS are extensive, and therefore development of an alternative
key wrap technique based on the RADIUS shared secret would not key wrap technique based on the RADIUS shared secret would not
substantially improve security. As a result, [RFC3759], Section 4.2 substantially improve security. As a result, [RFC3759] Section 4.2
recommends running RADIUS over IPsec. The same approach is taken in recommends running RADIUS over IPsec. The same approach is taken in
Diameter EAP [I-D.ietf-aaa-eap], which defines cleartext key Diameter EAP [I-D.ietf-aaa-eap], which defines cleartext key
attributes, to be protected by IPsec or TLS. attributes, to be protected by IPsec or TLS.
Where an untrusted AAA intermediary is present (such as a RADIUS Where an untrusted AAA intermediary is present (such as a RADIUS
proxy or a Diameter agent), and data object security is not used, the proxy or a Diameter agent), and data object security is not used, the
AAA-Key may be recovered by an attacker in control of the untrusted AAA-Key may be recovered by an attacker in control of the untrusted
intermediary. Possession of the AAA-Key enables decryption of data intermediary. Possession of the AAA-Key enables decryption of data
traffic sent between the peer and a specific authenticator; however traffic sent between the peer and a specific authenticator; however
where key separation is implemented, compromise of the AAA-Key does where key separation is implemented, compromise of the AAA-Key does
not enable an attacker to impersonate the peer to another not enable an attacker to impersonate the peer to another
authenticator, since that requires possession of the MK or EMSK, authenticator, since that requires possession of the MK or EMSK,
which are not transported by the AAA protocol. This vulnerability which are not transported by the AAA protocol. This vulnerability
may be mitigated by implementation of redirect functionality, as may be mitigated by implementation of redirect functionality, as
provided in [RFC3588]. provided in [RFC3588].
5. Security Requirements 6. Security Requirements
This section summarizes the security requirements that must be met by This section summarizes the security requirements that must be met by
EAP methods, AAA protocols, Secure Association Protocols and EAP methods, AAA protocols, Secure Association Protocols and
Ciphersuites in order to address the security threats described in Ciphersuites in order to address the security threats described in
this document. These requirements MUST be met by specifications this document. These requirements MUST be met by specifications
requesting publication as an RFC. Each requirement provides a requesting publication as an RFC. Each requirement provides a
pointer to the sections of this document describing the threat that pointer to the sections of this document describing the threat that
it mitigates. it mitigates.
5.1. EAP Method Requirements 6.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,
skipping to change at page 51, line 23 skipping to change at page 53, line 18
situations in which one of the parties discards key state which situations in which one of the parties discards key state which
remains valid on another party. remains valid on another party.
The development and validation of key derivation algorithms is The development and validation of key derivation algorithms is
difficult, and as a result EAP methods SHOULD reuse well established difficult, and as a result EAP methods SHOULD reuse well established
and analyzed mechanisms for key derivation (such as those specified and analyzed mechanisms for key derivation (such as those specified
in IKE [RFC2409] or TLS [RFC2246]), rather than inventing new ones. in IKE [RFC2409] or TLS [RFC2246]), rather than inventing new ones.
EAP methods SHOULD also utilize well established and analyzed EAP methods SHOULD also utilize well established and analyzed
mechanisms for MSK and EMSK derivation. mechanisms for MSK and EMSK derivation.
5.1.1. Requirements for EAP methods 6.1.1. Requirements for EAP methods
In order for an EAP method to meet the guidelines for EMSK usage it In order for an EAP method to meet the guidelines for EMSK usage it
must meet the following requirements: must meet the following requirements:
o It must specify how to derive the EMSK o It must specify how to derive the EMSK
o The key material used for the EMSK MUST be o The key material used for the EMSK MUST be
computationally independent of the MSK and TEKs. computationally independent of the MSK and TEKs.
o The EMSK MUST NOT be used for any other purpose than the key o The EMSK MUST NOT be used for any other purpose than the key
skipping to change at page 52, line 5 skipping to change at page 53, line 46
may be exported from the EAP server. may be exported from the EAP server.
o The EMSK MUST be unique for each session. o The EMSK MUST be unique for each session.
o The EAP mechanism SHOULD provide a way of naming the EMSK. o The EAP mechanism SHOULD provide a way of 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.
5.1.2. Requirements for EAP applications 6.1.2. Requirements for EAP applications
In order for an application to meet the guidelines for EMSK usage it In order for an application to meet the guidelines for EMSK usage it
must meet the following requirements: must meet the following requirements:
o The application MAY use the MSK transmitted to the NAS in any o New applications following this specification SHOULD NOT use the
way it chooses. This is required for backward compatibility. 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 The application 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 (AMSK) using the key derive Application Master Session Keys (AMSKs) using the
derivation specified in this document. It MUST NOT key derivation specified in Appendix F. 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.
o Applications MUST define distinct key labels, application o Applications MUST define distinct key labels, application
specific data, 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.4.3. derivation described in Appendix F.
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.
5.2. AAA Protocol Requirements 6.2. AAA Protocol Requirements
AAA protocols suitable for use in transporting EAP MUST provide the AAA protocols suitable for use in transporting EAP MUST provide the
following facilities: following facilities:
Security services Security services
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 53, line 12 skipping to change at page 55, line 5
backend authentication server. These requirements are met by backend authentication server. These requirements are met by
Diameter EAP [I-D.ietf-aaa-eap] as well as by RADIUS EAP [RFC3579]. Diameter EAP [I-D.ietf-aaa-eap] as well as by RADIUS EAP [RFC3579].
Authorization Authorization
AAA protocols used for transport of EAP keying material SHOULD AAA protocols used for transport of EAP keying material SHOULD
provide protection against rogue authenticators masquerading as provide protection against rogue authenticators masquerading as
other authenticators. This can be accomplished, for example, by other authenticators. This can be accomplished, for example, by
requiring that AAA agents check the source address of packets requiring that AAA agents check the source address of packets
against the origin attributes (Origin-Host AVP in Diameter, NAS-IP- against the origin attributes (Origin-Host AVP in Diameter, NAS-IP-
Address, NAS-IPv6-Address, NAS-Identifier in RADIUS). For details, Address, NAS-IPv6-Address, NAS-Identifier in RADIUS). For details,
see Section 4.3.7 of [RFC3579]. see [RFC3579] Section 4.3.7.
Key transport Key transport
Since EAP methods do not export Transient Session Keys (TSKs) in Since EAP methods do not export Transient Session Keys (TSKs) in
order to maintain media and ciphersuite independence, the AAA order to maintain media and ciphersuite independence, the AAA
server MUST NOT transport TSKs from the backend authentication server MUST NOT transport TSKs from the backend authentication
server to authenticator. server to authenticator.
Key transport specification Key transport specification
In order to enable backend authentication servers to provide keying In order to enable backend authentication servers to provide keying
material to the authenticator in a well defined format, AAA material to the authenticator in a well defined format, AAA
skipping to change at page 54, line 5 skipping to change at page 55, line 47
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].
5.3. Secure Association Protocol Requirements 6.3. Secure Association Protocol Requirements
The Secure Association Protocol supports the following: The Secure Association Protocol supports the following:
Entity Naming Entity Naming
The peer and authenticator SHOULD identify themselves in a manner The peer and authenticator SHOULD identify themselves in a manner
that is independent of their attached ports. that is independent of their attached ports.
Mutual proof of possession Mutual proof of possession
The peer and authenticator MUST each demonstrate possession of the The peer and authenticator MUST each demonstrate possession of the
keying material transported between the backend authentication keying material transported between the backend authentication
skipping to change at page 55, line 37 skipping to change at page 57, line 32
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.
5.4. Ciphersuite Requirements 6.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 56, line 11 skipping to change at page 58, line 6
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.
6. IANA Considerations 7. 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 56, line 41 skipping to change at page 58, line 36
request to the EAP WG mailing list (or a successor designated by the request to the EAP WG mailing list (or a successor designated by the
Area Director) for comment and review, including an Internet-Draft. Area Director) for comment and review, including an Internet-Draft.
Before a period of 30 days has passed, the Designated Expert will Before a period of 30 days has passed, the Designated Expert will
either approve or deny the registration request and publish a notice either approve or deny the registration request and publish a notice
of the decision to the EAP WG mailing list or its successor, as well of the decision to the EAP WG mailing list or its successor, as well
as informing IANA. A denial notice must be justified by an as informing IANA. A denial notice must be justified by an
explanation and, in the cases where it is possible, concrete explanation and, in the cases where it is possible, concrete
suggestions on how the request can be modified so as to become suggestions on how the request can be modified so as to become
acceptable. acceptable.
7. References This document introduces a new name space for "key labels". Key
labels are ASCII strings and are assigned via IETF Consensus. It is
expected that key label specifications will include the following
information:
7.1. Normative References o A description of the application
o The key label to be used
o How TSKs will be derived from the AMSK and how they will be used
o If application specific data is used, what it is and how it is
maintained
o Where the AMSKs or TSKs will be used and how they are
communicated if necessary.
8. References
8.1. Normative References
[RFC2119] [RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Bradner, S., "Key words for use in RFCs to Indicate 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 1998. Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC3748] [RFC3748]
Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. Lefkowetz, Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. Lefkowetz,
"Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
7.2. Informative References 8.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.
skipping to change at page 60, line 26 skipping to change at page 62, line 39
[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-11 (work in progress), October 2003.
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", draft- [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", draft-
ietf-ipsec-ikev2-12 (work in progress), March 2004. ietf-ipsec-ikev2-14 (work in progress), June 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.
skipping to change at page 67, line 36 skipping to change at page 70, line 36
Calling-Station-Id,length) Calling-Station-Id,length)
AAA-Key-E = PRF(EMSK(0,63),"EAP AAA-Key derivation for AAA-Key-E = PRF(EMSK(0,63),"EAP AAA-Key derivation for
multiple attachments",AAA-Key-A,E-Called-Station-Id, multiple attachments",AAA-Key-A,E-Called-Station-Id,
Calling-Station-Id, length) Calling-Station-Id, length)
Where: Where:
Calling-Station-Id = STA MAC address Calling-Station-Id = STA MAC address
B-Called-Station-Id = AP B MAC address B-Called-Station-Id = AP B MAC address
E-Called-Station-Id = AP E MAC address E-Called-Station-Id = AP E MAC address
PRF = Some suitable pseudo-random function
length = length of derived key material length = length of derived key material
Here AAA-Key-A is the AAA-Key derived during the initial EAP Here AAA-Key-A is the AAA-Key derived during the initial EAP
authentication between the peer and authenticator A. Based on this authentication between the peer and authenticator A. Based on this
initial EAP authentication, the EMSK is also derived, which can be initial EAP authentication, the EMSK is also derived, which can be
used to derive AAA-Keys for fast authentication between the EAP peer used to derive AAA-Keys for fast authentication between the EAP peer
and authenticators B and E. Since the EMSK is cryptographically and authenticators B and E. Since the EMSK is cryptographically
separate from the MSK, each of these AAA-Keys 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 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 EAP peer (also known as the STA) and the authenticator (also known as
the AP). the AP).
Appendix F - 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. Note that the length of the AMSK must be specified
by the application.
F.1 The EAP AMSK Key Derivation Function
The EAP 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. The application data is optional and may not be
used by some applications. The KDF is based on HMAC-SHA1 [RFC2104]
[SHA1]. For this specification we have:
KDF (K,L,D,O) = T1 | T2 | T3 | T4 | ...
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.
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
standards- related documentation can be found in BCP-11. Copies of standards- related documentation can be found in BCP-11. Copies of
skipping to change at page 68, line 50 skipping to change at page 73, line 10
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. The limited permissions granted above are perpetual and English. The limited permissions granted above are perpetual and
will not be revoked by the Internet Society or its successors or will not be revoked by the Internet Society or its successors or
assigns. This document and the information contained herein is assigns. This document and the information contained herein is
provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Open Issues Open Issues
Open issues relating to this specification are tracked on the Open issues relating to this specification are tracked on the
following web site: following web site:
http://www.drizzle.com/~aboba/EAP/eapissues.html http://www.drizzle.com/~aboba/EAP/eapissues.html
Expiration Date Expiration Date
This memo is filed as <draft-ietf-eap-keying-02.txt>, and expires This memo is filed as <draft-ietf-eap-keying-03.txt>, and expires
December 22, 2004. January 5, 2005.
 End of changes. 119 change blocks. 
681 lines changed or deleted 857 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/