WDIFF

draft-ietf-eap-keying-07.txt --> draft-ietf-eap-keying-08.txt

EAP Working Group Bernard Aboba
INTERNET-DRAFT Dan Simon
Category: Standards Track Microsoft
<draft-ietf-eap-keying-07.txt>
<draft-ietf-eap-keying-08.txt> J. Arkko
17 July
23 October 2005 Ericsson
P. Eronen
Nokia
H. Levkowetz, Ed.
ipUnplugged

Extensible Authentication Protocol (EAP) Key Management Framework

By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on January April 22, 2006.

Abstract

The Extensible Authentication Protocol (EAP), defined in [RFC3748],
enables extensible network access authentication. This document
provides a framework for the generation, transport and usage of
keying material generated by EAP authentication algorithms, known as
"methods". It also specifies the EAP key hierarchy.

Aboba, et al. Standards Track [Page 1]

INTERNET-DRAFT EAP Key Management Framework 17 July 23 October 2005

Table of Contents

1. Introduction .......................................... 4 3
1.1 Requirements Language ........................... 4 3
1.2 Terminology ..................................... 4 3
1.3 Overview ........................................ 7 5
1.4 EAP Invariants .................................. 14 9
2. Lower Layer Operation ................................. 16 13
2.1 Discovery Phase ................................. 18 Overview ........................................ 13
2.2 Authentication Phase ............................ 18 Layering ........................................ 14
2.3 Secure Association Phase ........................ 19 Caching ......................................... 17
2.4 Lower Layer Key Hierarchy ....................... 21
2.5 AAA-Key Derivation and Naming ................... 24
3. Security associations ................................. 26
3.1 EAP Method SA ................................... 26
3.2 EAP-Key SA ...................................... 27
3.3 AAA SA(s) Scope ....................................... 27
3.4 Service SA(s) ................................... 27
4. 18
3. Key Management ........................................ 30
4.1 Key Caching ..................................... 31
4.2 21
3.1 Secure Association Protocol ..................... 22
3.2 Parent-Child Relationships ...................... 32
4.3 24
3.3 Local Key Lifetimes ............................. 32
4.4 25
3.4 Exported and Calculated Key Lifetimes ........... 33
4.5 25
3.5 Key Cache Synchronization ....................... 34
4.6 Key Scope ....................................... 35
4.7 27
3.6 Key Strength .................................... 36
4.8 27
3.7 Key Wrap ........................................ 37
5. 28
4. Handoff Vulnerabilities ............................... 38
5.1 29
4.1 Authorization ................................... 38
5.2 29
4.2 Correctness ..................................... 39
6. 30
5. Security Considerations .............................. 42
6.1 33
5.1 Security Terminology ............................ 42
6.2 34
5.2 Threat Model .................................... 42
6.3 Security Analysis 34
5.3 Authenticator Compromise ........................ 35
5.4 Spoofing ........................................ 36
5.5 Downgrade Attacks ............................... 44
6.4 Man-in-the-middle 36
5.6 Unauthorized Disclosure ......................... 37
5.7 Replay Protection ............................... 38
5.8 Key Freshness ................................... 39
5.9 Elevation of Privilege .......................... 40
5.10 Man-in-the-Middle Attacks ....................... 47
6.5 41
5.11 Denial of Service Attacks ....................... 48
6.6 41
5.12 Impersonation ................................... 48
6.7 42
5.13 Channel Binding ................................. 50

Aboba, et al. Standards Track [Page 2]

INTERNET-DRAFT EAP Key Management Framework 17 July 2005

7. Security Requirements ................................. 50
7.1 EAP Method Requirements ......................... 51
7.2 AAA Protocol Requirements ....................... 53
7.3 Secure Association Protocol Requirements ........ 55
7.4 Ciphersuite Requirements ........................ 56
8. 43
6. IANA Considerations ................................... 57
9. 44
7. References ............................................ 57
9.1 44
7.1 Normative References ............................ 57
9.2 44
7.2 Informative References .......................... 57 45
Acknowledgments .............................................. 61 49
Author's Addresses ........................................... 61 49
Appendix A - Ciphersuite Keying Requirements ................. 63
Appendix B - Example Transient EAP Key (TEK) Hierarchy ....... 64
Appendix C - EAP-TLS Key Hierarchy ........................... 65
Appendix D - Example Transient Session Key (TSK) Derivation .. 67 51
Appendix E B - Exported Parameters in Existing Methods ......... 68
Appendix F - Security Association Examples ................... 70 53
Intellectual Property Statement .............................. 73 54
Disclaimer of Validity ....................................... 74 55
Copyright Statement .......................................... 74 55

Aboba, et al. Standards Track [Page 3] 2]

INTERNET-DRAFT EAP Key Management Framework 17 July 23 October 2005

1. Introduction

The Extensible Authentication Protocol (EAP), defined in [RFC3748],
was designed to enable extensible authentication for network access
in situations in which the IP protocol is not available. Originally
developed for use with PPP [RFC1661], it has subsequently also been
applied to IEEE 802 wired networks [IEEE-802.1X].

This document provides a framework for the generation, transport and
usage of keying material generated by EAP authentication algorithms,
known as "methods". In EAP keying material is generated by EAP
methods. Part of this keying material may be used by EAP methods
themselves and part of this material may be exported. The exported
keying material may be transported by AAA protocols or transformed by
Secure Association Protocols into session keys which are used by
lower layer ciphersuites. This document describes each of these
elements and provides a system-level security analysis. It also
specifies the EAP key hierarchy.

1.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119].

1.2. Terminology

This document frequently uses the following terms:

authenticator
The end of the link initiating EAP authentication. The term
Authenticator is used in [IEEE-802.1X], and authenticator has the
same meaning in this document.

peer The end of the link that responds to the authenticator. In
[IEEE-802.1X], this end is known as the Supplicant.

Supplicant
The end of the link that responds to the authenticator in
[IEEE-802.1X]. In this document, this end of the link is called
the peer.

backend authentication server
A backend authentication server is an entity that provides an
authentication service to an authenticator. When used, this server
typically executes EAP methods for the authenticator. This
terminology is also used in [IEEE-802.1X].

Aboba, et al. Standards Track [Page 4] 3]

INTERNET-DRAFT EAP Key Management Framework 17 July 23 October 2005

AAA Authentication, Authorization and Accounting. AAA protocols with
EAP support include RADIUS [RFC3579] and Diameter [I-D.ietf-aaa-
eap]. [RFC4072]. In
this document, the terms "AAA server" and "backend authentication
server" are used interchangeably.

EAP server
The entity that terminates the EAP authentication method with the
peer. In the case where no backend authentication server is used,
the EAP server is part of the authenticator. In the case where the
authenticator operates in pass-through mode, the EAP server is
located on the backend authentication server.

security association
A set of policies and cryptographic state used to protect
information. Elements of a security association may include
cryptographic keys, negotiated ciphersuites and other parameters,
counters, sequence spaces, authorization attributes, etc.

Long Term Credential
EAP methods frequently make use of long term secrets in order to
enable authentication between the peer and server. In the case of
a method based on pre-shared key authentication, the long term
credential is the pre-shared key. In the case of a public-key
based method, the long term credential is the corresponding private
key.

Master Session Key (MSK)
Keying material that is derived between the EAP peer and server and
exported by the EAP method. The MSK is at least 64 octets in
length.

Extended Master Session Key (EMSK)
Additional keying material derived between the peer and server that
is exported by the EAP method. The EMSK is at least 64 octets in
length, and is never shared with a third party.

Initialization Vector (IV)
A quantity of at least 64 octets, suitable for use in an
initialization vector field, that is derived between the peer and
EAP server. Since the IV is a known value in methods such as EAP-
TLS [RFC2716], it cannot be used by itself for computation of any
quantity that needs to remain secret. As a result, its use has
been deprecated and EAP methods are not required to generate it.
However, when it is generated it MUST be unpredictable.

Pairwise Master Key (PMK)
The AAA-Key MSK is divided into two halves, the "Peer to Authenticator
Encryption Key" (Enc-RECV-Key) and "Authenticator to Peer

Aboba, et al. Standards Track [Page 5] 4]

INTERNET-DRAFT EAP Key Management Framework 17 July 23 October 2005

Encryption Key" (Enc-SEND-Key) (reception is defined from the point
of view of the authenticator). Within [IEEE-802.11i] Octets 0-31
of the AAA-Key MSK (Enc-RECV-Key) are known as the Pairwise Master Key
(PMK). In [IEEE-802.11i] the TKIP and AES CCMP ciphersuites derive
their Transient Session Keys (TSKs) solely from the PMK, whereas
the WEP ciphersuite as noted in [RFC3580], derives its TSKs from
both halves of the AAA-Key. MSK.

Transient EAP Keys (TEKs)
Session keys which are used to establish a protected channel
between the EAP peer and server during the EAP authentication
exchange. The TEKs are appropriate for use with the ciphersuite
negotiated between EAP peer and server for use in protecting the
EAP conversation. The TEKs are stored locally by the EAP method
and are not exported. Note that the ciphersuite used to set up the
protected channel between the EAP peer and server during EAP
authentication is unrelated to the ciphersuite used to subsequently
protect data sent between the EAP peer and authenticator. An
example TEK key hierarchy is described in Appendix C. A.

Transient Session Keys (TSKs)
Session keys used to protect data exchanged between in a port of session between
the peer and a port of the authenticator after the EAP authentication has
successfully completed. TSKs are appropriate for the lower layer
ciphersuite negotiated between the ports of the EAP peer and
authenticator. Examples of TSK derivation are provided in Appendix
D.
B.

AAA-Key
A key derived by the peer and EAP server, used by the peer and
authenticator in the derivation of Transient Session Keys (TSKs).
Where a backend authentication server is present, the AAA-Key is
transported from the backend authentication server to the
authenticator, wrapped within the AAA-Token; it is therefore known
by the peer, authenticator and backend authentication server.
Despite the name, the AAA-Key is computed regardless of whether a
backend authentication server is present. AAA-Key derivation is
discussed in Section 2.5; in
authenticator. In existing implementations the MSK is
used as the AAA-Key.

AAA-Token
Where a backend server is present, usage, the AAA-Key and one or more
attributes is transported between the backend authentication server
and the authenticator within a package known as always derived
from the AAA-Token. The
format MSK and wrapping of the AAA-Token, which is intended to so can be
accessible only referred to using the backend authentication server and
authenticator, is defined by the AAA protocol. Examples include
RADIUS [RFC2548] and Diameter [I-D.ietf-aaa-eap].

Aboba, et al. Standards Track [Page 6]

INTERNET-DRAFT EAP Key Management Framework 17 July 2005 MSK name. AAA-Key
= MSK(0,63).

1.3. Overview

EAP, defined in [RFC3748] [RFC3748], is a two-party protocol spoken between the
EAP peer and server. Within EAP, keying material is generated by EAP
methods. Part of this keying material may be used by EAP methods
themselves and part of this material may be exported. In addition to
export of keying material, EAP methods may also export associated
parameters, and may import and export Channel Bindings from the lower
layer.

As illustrated in Figure 1, the EAP method key derivation has at the

Aboba, et al. Standards Track [Page 5]

INTERNET-DRAFT EAP Key Management Framework 23 October 2005

root the long term credential utilized by the selected EAP method.
If authentication is based on a pre-shared key, the parties store the
EAP method to be used and the pre-shared key. The EAP server also
stores the peer's identity and/or other information necessary to
decide whether access to some service should be granted. The peer
stores information necessary to choose which secret to use for which
service.

If authentication is based on proof of possession of the private key
corresponding to the public key contained within a certificate, the
parties store the EAP method to be used and the trust anchors used to
validate the certificates. The EAP server also stores the peer's
identity and/or other information necessary to decide whether access
to some service should be granted. The peer stores information
necessary to choose which certificate to use for which service.

Based on the long term credential established between the peer and
the server, EAP methods derive two types of keys:

[1] Keys calculated locally by the EAP method but not exported
by the EAP method, such as the TEKs.
[2] Keying material exported by the EAP method: MSK, EMSK, IV.

EAP methods also MAY export method-specific peer and server
identifiers (peer-ID and server-ID), a method-specific EAP
conversation identifier known as the Method-ID, and the lifetime of
the exported keys, known the Key-Lifetime. EAP methods MAY also
support the import and export of Channel Bindings. New EAP method
specifications MUST define the Peer-ID, Server-ID and Method-ID. The
combination of the Peer-ID and Server-ID uniquely specifies the
endpoints of the EAP method exchange.

Aboba, et al. Standards Track [Page 7] 6]

INTERNET-DRAFT EAP Key Management Framework 17 July 23 October 2005

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | ^
| EAP Method | |
| | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | |
| | | | | | |
| | EAP Method Key |<->| Long-Term | | |
| | Derivation | | Credential | | |
| | | | | | |
| | | +-+-+-+-+-+-+-+ | Local to |
| | | | EAP |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Method |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | |
| | | TEK | |MSK, EMSK | |IV | | |
| | |Derivation | |Derivation | |Derivation | | |
| | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | |
| | | | | |
| | ^ | | | V
+-+-|-+-+-+-+-+-+-+-+-|-+-+-+-+-+-|-+-+-+-+-+-+-+-+-|-+-+-+ ---+
| | | | ^
| Peer-ID, | | | Exported|
| Server-ID, | Channel | MSK (64+B) | IV (64B) by |
| Method-ID, | Bindings | EMSK (64+B) | EAP |
| Key-Lifetime | & Result | | Method |
V V V V V

Figure 1: EAP Method Parameter Import/Export

EAP methods also MAY export method-specific peer and server
identifiers (peer-ID and server-ID), a method-specific EAP
conversation identifier known as

Peer-ID

As described in [RFC3748] Section 7.3, the Method-ID, and the lifetime of
the exported keys, known the Key-Lifetime. EAP methods MAY also
support the import and export of Channel Bindings. New EAP method
specifications MUST define the Peer-ID, Server-ID and Method-ID. The
combination of the Peer-ID and Server-ID uniquely specifies the
endpoints of the EAP method exchange.

Peer-ID

As described in [RFC3748] Section 7.3, the identity provided in identity provided in the
EAP-Response/Identity, may be different from the peer identity
authenticated by the EAP method. Where the EAP method authenticates
the peer identity, that identity is exported by the

Aboba, et al. Standards Track [Page 8]

INTERNET-DRAFT EAP Key Management Framework 17 July 2005 method as the
Peer-ID. A suitable EAP peer name may not always be available.
Where an EAP method does not define a method-specific peer identity,
the Peer-ID is the null string. The Peer-ID for existing EAP
methods is defined in Appendix E. B.

Server-ID

Where the EAP method authenticates the server identity, that identity
is exported by the method as the Server-ID. A suitable EAP server

Aboba, et al. Standards Track [Page 7]

INTERNET-DRAFT EAP Key Management Framework 23 October 2005

name may not always be available. Where an EAP method does not
define a method-specific peer identity, the Server-ID is the null
string. The Server-ID for existing EAP methods is defined in
Appendix E. B.

Method-ID

EAP method specifications deriving keys MUST specify a temporally
unique method identifier known as the Method-ID. The EAP Method-
ID Method-ID
uniquely identifies an EAP session of a given Type between an EAP
peer and server. The Method-ID is typically constructed from nonces
or counters used within the EAP method exchange. The Method-ID for
existing EAP methods is defined in Appendix E. B.

Session-ID

The Session-ID uniquely identifies an EAP session between an EAP peer
(as identified by the Peer-ID) and server (as identified by the
Server-ID). The EAP Session-ID consists of the concatenation of the
Expanded EAP Type Code (including the Type, Vendor-ID and Vendor-Type
fields defined in [RFC3748] Section 5.7) and the Method-ID. The
inclusion of the Expanded Type Code in the EAP Session-Id ensures
that each EAP method has a distinct Session-ID space. Since an EAP
session is not bound to a particular authenticator or specific ports
on the peer and authenticator, the authenticator port or identity are
not included in the Session-Id.

Key-Lifetime

While EAP itself does not support key lifetime negotiation, it is
possible to specify methods that do. However, systems that rely on
such negotiation for exported keys would only function with these
methods. As a result, it is NOT RECOMMENDED to use this approach as
the sole way to determine key lifetimes.

Channel Bindings

Channel Bindings include lower layer parameters that are verified for
consistency between the EAP peer and server. In order to

Aboba, et al. Standards Track [Page 9]

INTERNET-DRAFT EAP Key Management Framework 17 July 2005 avoid
introducing media dependencies, EAP methods that transport Channel
Binding data MUST treat
Channel Bindings this data as opaque octets. Typically the
EAP method imports Channel Bindings from the lower layer on the peer,
and transmits them securely to the EAP server, which exports them to
the lower layer. However, transport may occur from EAP server to
peer, or may be bi-directional. On the side of the exchange (peer or
server) where Channel Bindings are verified, the lower layer passes
the result of the verification (TRUE or FALSE) up to the EAP method.

1.3.1. Layering

As illustrated in Figure 2, keying material and parameters exported
by

Aboba, et al. Standards Track [Page 8]

INTERNET-DRAFT EAP methods are passed down to Key Management Framework 23 October 2005

1.3.1. Key Naming

Each key created within the EAP peer or authenticator
layers, which passes them key management framework has a name
(a unique identifier), as well as a scope (the parties to whom the EAP layer. Keying material and
related
key is available). The scope of exported parameters (including Channel Bindings) MUST NOT be cached is defined by
the EAP peer or authenticator layers, or name (if securely exchanged within the method) and the
EAP layer.

Based on server name (also only if securely exchanged). Where a peer or
server name is missing the Method-ID null string is used.

MSK, EMSK and IV Names
These parameters are exported by the EAP method, the peer and EAP layer
forms server, and
can be referred to using the EAP Session-ID by concatenating the EAP Expanded Type with and a binary or textual
indication of the Method-ID. Together with parameter being referred to.

PMK Name
This document does not specify a naming scheme for the MSK, EMSK, IV, Peer-ID, Server-ID,
and Key-Lifetime, PMK. The
PMK is only identified by the EAP layer passes key from which it is derived.

Note: IEEE 802.11i names the Session-ID down PMKID for the purposes of being able
to refer to it in the
lower layer. Secure Association protocol; this naming is
based on a hash of the PMK itself as well as some other parameters
(see Section 8.5.1.2 [IEEE-802.11i]).

TEK Name
The Method-ID TEKs may or may not be named. Their naming is exported by specified in the
EAP methods rather than method.

TSK Name
The TSKs are typically named. Their naming is specified in the Session-ID
lower layer so that the correct set of transient session keys can
be identified for processing a given packet.

1.4. EAP Invariants

Certain basic characteristics, known as to prevent "EAP Invariants", hold true
for EAP implementations on all media:

Mode independence
Media independence
Method independence
Ciphersuite independence

1.4.1. Mode Independence

EAP methods from writing into each other's Session-
ID space. Lower layers MAY cache keying material and related
parameters, including Channel Bindings. Lower Layer behavior is
discussed typically deployed in more detail order to support extensible network
access authentication in Section 2. situations where a peer desires network
access via one or more authenticators. Where authenticators are
deployed standalone, the EAP conversation occurs between the peer and

Aboba, et al. Standards Track [Page 10] 9]

INTERNET-DRAFT EAP Key Management Framework 17 July 23 October 2005

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
|

authenticator, and the authenticator must locally implement an EAP
method |
| |
| MSK, EMSK, IV, Channel |
| Peer-ID, Server-ID, Bindings |
| Method-ID, |
| Key-Lifetime |
| |
| V ^ ^ |
+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+
| ! ! ! |
| EAP ! Peer or Authenticator ! ! |
| ! layer ! ! |
| ! ! ! |
+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+
| ! ! ! |
| EAP ! layer ! ! |
| ! ! ! |
| ! Session-ID = ! ! |
| ! Expanded-Type || ! ! |
| ! Method-ID ! ! |
| ! ! ! |
+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+
| ! ! ! |
| Lower ! layer ! ! |
| ! ! ! |
| V V ^ |
| MSK, EMSK, IV, Channel Result |
| Peer-ID, Server-ID, Bindings |
| Session-ID, |
| Key-Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: Flow acceptable to the peer. However, one of the advantages of EAP parameters

1.3.2. Key Naming

Each key created within
is that it enables deployment of new authentication methods without
requiring development of new code on the authenticator.

While the authenticator may implement some EAP key management framework has a name
(the identifier by which methods locally and
use those methods to authenticate local users, it may at the key can be identified), as well same
time act as a
scope (the parties to whom pass-through for other users and methods, forwarding
EAP packets back and forth between the key is available). The scope of
exported parameters backend authentication server
and the peer. This is defined accomplished by the encapsulating EAP peer name (if securely
exchanged packets
within the method) Authentication, Authorization and the Accounting (AAA)
protocol, spoken between the authenticator and backend authentication
server. AAA protocols supporting EAP server name (also only if
securely exchanged). Where a peer or server name include RADIUS [RFC3579] and
Diameter [RFC4072].

It is missing a fundamental property of EAP that at the null
string is used.

Aboba, et al. Standards Track [Page 11]

INTERNET-DRAFT EAP Key Management Framework 17 July 2005

MSK Name
This key is created method layer, the
conversation between the EAP peer and server is unaffected by whether
the EAP server, authenticator is operating in "pass-through" mode. EAP
methods operate identically in all aspects, including key derivation
and can be
referred to using the string "MSK:", concatenated with parameter import/export, regardless of whether the EAP
Session-ID.

EMSK Name authenticator
is operating as a pass-through or not.

The EMSK can be referred to using the string "EMSK:", concatenated
with the successful completion of an EAP Session-ID.

IV Name
Use method that supports key
derivation results in the export of keying material on the IV is deprecated. However, if necessary EAP peer
and server. Even though the IV can be
referred to using EAP peer or server may import Channel-
Bindings that may include the string "IV:" concatenated with identity of the EAP
Session-ID.

PMK Name
This document does not specify authenticator,
this information is treated as opaque octets. As a naming scheme for result, within
EAP the PMK. The
PMK is only identified by relevant identities are the key from which it is derived.

Note: IEEE 802.11i names Peer-ID and Server-ID.
Channel Bindings are only interpreted by the PMKID for lower layer.

Within EAP, the purposes primary function of being able
to refer to it in the Secure Association protocol; this naming AAA protocol is
based on a hash of to maintain
the PMK itself principle of Mode Independence, so that as well far as some other parameters
(see Section 8.5.1.2 [IEEE-802.11i]).

TEK Name
The TEKs may or may not be named. Their naming is specified in the EAP method.

1.3.3. EAP and AAA

EAP is typically deployed in order to support extensible network
access authentication in situations where a peer desires network
access via one or more authenticators. Since both the peer and
authenticator may have more than one physical or logical port, a
given peer may simultaneously access the network via multiple
authenticators, or via multiple physical or logical ports on a given
authenticator. Similarly, an authenticator may offer network access
to multiple peers, each via a separate physical or logical port. The
situation is illustrated in Figure 3.

Where authenticators are deployed standalone, the EAP
concerned, its conversation
occurs between with the peer and EAP authenticator, and all
consequences of that conversation, are identical, regardless of the
authenticator must
locally implement an EAP method acceptable to the peer. However, one mode of operation.

1.4.2. Media Independence

One of the advantages goals of EAP is that it enables deployment of new
authentication to allow EAP methods without requiring development of new code to function on any
lower layer meeting the authenticator. While the authenticator may implement some criteria outlined in [RFC3748], Section 3.1.
For example, as described in [RFC3748], EAP
methods locally authentication can be run
over PPP [RFC1661], IEEE 802 wired networks [IEEE-802.1X], and use those methods IEEE
802.11 wireless LANs [IEEE-802.11i].

In order to authenticate local users, maintain media independence, it
may at the same time act as a pass-through is necessary for other users and
methods, forwarding EAP packets back and forth between to
avoid consideration of media-specific elements. For example, EAP
methods cannot be assumed to have knowledge of the backend lower layer over
which they are transported, and cannot be restricted to identifiers

Aboba, et al. Standards Track [Page 12] 10]

INTERNET-DRAFT EAP Key Management Framework 17 July 23 October 2005

authentication server and

associated with a particular usage environment (e.g. MAC addresses).

Note that media independence may be retained within EAP methods that
support Channel-Bindings or method-specific identification. An EAP
method need not be aware of the peer. content of an identifier in order to
use it. This is accomplished enables an EAP method to use media-specific identifiers
such as MAC addresses without compromising media independence.
Channel-Bindings are treated as opaque octets by encapsulating EAP packets within methods, so that
handling them does not require media-specific knowledge.

1.4.3. Method Independence

By enabling pass-through, authenticators can support any method
implemented on the
Authentication, Authorization peer and Accounting (AAA) protocol, spoken
between server, not just locally implemented
methods. This allows the authenticator and backend authentication server. AAA
protocols to avoid implementing code
for each EAP method required by peers. In fact, since a pass-through
authenticator is not required to implement any EAP methods at all, it
cannot be assumed to support any EAP method-specific code.

As a result, as noted in [RFC3748], authenticators must by default be
capable of supporting any EAP include RADIUS [RFC3579] method. This is useful where there is
no single EAP method that is both mandatory-to-implement and Diameter [I-
D.ietf-aaa-eap].

+-+-+-+-+
| |
| offers
acceptable security for the media in use. For example, the [RFC3748]
mandatory-to-implement EAP |
| Peer |
| |
+-+-+-+-+
| | | Peer Ports
/ | \
/ | \
/ | \
/ | \
/ | \
/ | \
/ | \
/ | \
| | | | | | | | | Authenticator Ports
+-+-+-+-+ +-+-+-+-+ +-+-+-+-+
| | | | | |
| Auth. | | Auth. | | Auth. |
| | | | | |
+-+-+-+-+ +-+-+-+-+ +-+-+-+-+
\ | /
\ | /
\ | /
EAP over AAA \ | /
(optional) \ | /
\ | /
\ | /
\ | /
+-+-+-+-+
| |
| AAA |
|Server |
| |
+-+-+-+-+

Figure 3: Relationship between peer, authenticator method (MD5-Challenge) does not provide
dictionary attack resistance, mutual authentication or key
derivation, and backend server

Aboba, et al. Standards Track [Page 13]

INTERNET-DRAFT EAP Key Management Framework 17 July 2005

1.4. EAP Invariants

Certain basic characteristics, known as "EAP Invariants", hold true a result is not appropriate for use in wireless
LAN authentication [RFC4017]. However, despite this it is possible
for the peer and authenticator to interoperate as long as a suitable
EAP implementations method is supported on all media:

Mode independence
Media independence
Method independence the EAP server.

1.4.4. Ciphersuite Independence

Ciphersuite independence

1.4.1. Mode Independence

EAP as defined in [RFC3748] is a two party protocol spoken between consequence of the EAP peer and server. A fundamental property principles of Mode
Independence and Media Independence.

While EAP is that at methods may negotiate the ciphersuite used in protection of
the EAP method layer, conversation, the conversation between ciphersuite used for the protection of the
data exchanged after EAP peer and
server is unaffected by whether the EAP authenticator is operating in
"pass-through" mode.

EAP methods operate identically in all aspects, including key
derivation and parameter import/export, regardless of whether the
authenticator authentication has completed is operating as a pass-through or not.

The successful completion of an EAP method that supports key
derivation results in the export of keying material on negotiated
between the EAP peer and server. Even though the EAP peer or server may import Channel-
Bindings that may include authenticator within the identity lower layer, outside of
EAP.

For example, within PPP, the EAP authenticator,
this information ciphersuite is treated as opaque octets. As a result, negotiated within the
Encryption Control Protocol (ECP) defined in [RFC1968], after EAP
authentication is completed. Within [IEEE-802.11i], the only relevant identities AP
ciphersuites are advertised in the Peer-ID Beacon and Probe Responses prior
to EAP authentication, and Server-ID.
Channel Bindings are only interpreted by the lower layer.

Within EAP, the primary function of securely verified during a 4-way
handshake exchange.

Aboba, et al. Standards Track [Page 11]

INTERNET-DRAFT EAP Key Management Framework 23 October 2005

Since the AAA protocol is ciphersuites used to maintain
the principle of Mode Independence, so that as far as the EAP peer is
concerned, its conversation with protect data depend on the lower
layer, requiring EAP authenticator, and all
consequences of that conversation, are identical, regardless methods have knowledge of lower layer
ciphersuites would compromise the
authenticator mode principle of operation.

1.4.2. Media Independence

One of Independence.
Since ciphersuite negotiation occurs in the goals of EAP lower layer, there is to allow no
need for ciphersuite negotiation within EAP, and EAP methods to function on any
lower layer meeting generate
keying material that is ciphersuite-independent.

Algorithms for deriving TSKs MUST NOT depend on the criteria outlined in [RFC3748], Section 3.1.
For example, as described in [RFC3748], EAP authentication can method,
although algorithms for TEK derivation MAY be run
over PPP [RFC1661], IEEE 802 wired networks [IEEE-802.1X], and IEEE
802.11 wireless LANs [IEEE-802.11i]. specific to the EAP
method.

In order to maintain media independence, it is necessary for EAP allow a ciphersuite to
avoid consideration of media-specific elements. For example, EAP
methods cannot be assumed to have knowledge of usable within the lower layer over
which they are transported, and cannot be restricted to identifiers

Aboba, et al. Standards Track [Page 14]

INTERNET-DRAFT EAP Key Management Framework 17 July 2005

associated with keying
framework, a particular usage environment (e.g. MAC addresses).

Note that media independence may specification MUST be retained within provided describing how TSKs
suitable for use with the ciphersuite are derived from exported EAP methods that
support Channel-Bindings or method-specific identification. An
keying parameters.

Advantages of ciphersuite-independence include:

Reduced update requirements
If EAP
method methods were to specify how to derive transient session keys
for each ciphersuite, they would need to be updated each time a new
ciphersuite is developed. In addition, backend authentication
servers might not be aware of usable with all EAP-capable authenticators,
since the content of an identifier in order backend authentication server would also need to
use it. This enables an be
updated each time support for a new ciphersuite is added to the
authenticator.

Reduced EAP method to use media-specific identifiers
such as MAC addresses without compromising media independence.
Channel-Bindings are treated as opaque octets by complexity
Requiring each EAP methods, so that
handling them does not require media-specific knowledge.

1.4.3. Method Independence

By enabling pass-through, authenticators can support any method
implemented on the peer and server, not just locally implemented
methods. This allows the authenticator to avoid implementing include ciphersuite-specific code for each EAP
transient session key derivation would increase method required by peers. In fact, since a pass-through
authenticator is not required to implement any EAP methods at all, it
cannot be assumed to support any EAP method-specific code.

As a result, as noted complexity
and result in [RFC3748], authenticators must by default be
capable of supporting any EAP method. This is useful where there is
no single EAP method that duplicated effort.

Simplified configuration
The ciphersuite is both mandatory-to-implement negotiated between the peer and offers
acceptable security for authenticator
outside of EAP. Where the media authenticator operates in use. For example, "pass-through"
mode, the [RFC3748]
mandatory-to-implement EAP method (MD5-Challenge) does not provide
dictionary attack resistance, mutual authentication or key
derivation, and as a result server is not appropriate for use in wireless
LAN authentication [RFC4017]. However, despite a party to this it negotiation, nor is possible
for it
involved in the data flow between the EAP peer and authenticator to interoperate as long as authenticator.
As a suitable
EAP method is supported on result, the EAP server.

1.4.4. Ciphersuite Independence

Ciphersuite Independence is a consequence server may not have knowledge of the principles of Mode
Independence
ciphersuites and Media Independence.

While EAP methods may negotiate negotiation policies implemented by the ciphersuite used in protection peer and
authenticator, or be aware of the EAP conversation, the ciphersuite used for the protection of the
data exchanged after EAP authentication has completed is negotiated between the peer and authenticator within the lower layer, outside of
EAP. Since the ciphersuites used to protect data depend on the lower
layer, requiring EAP methods have knowledge of lower layer
ciphersuites would compromise the principle of Media Indepence.

Since ciphersuite
them. For example, since ECP negotiation occurs in after
authentication, when run over PPP, the lower layer, there is no
need for ciphersuite negotiation within EAP, and EAP methods generate
keying material that is ciphersuite-independent.

For example, within PPP, peer and server may not
anticipate the ciphersuite is negotiated within ciphersuite and therefore this
information cannot be provided to the EAP method.

Aboba, et al. Standards Track [Page 15] 12]

INTERNET-DRAFT EAP Key Management Framework 17 July 23 October 2005

Encryption Control Protocol (ECP) defined in [RFC1968], after

2. Lower Layer Operation

2.1. Overview

Where EAP
authentication key derivation is completed. Within [IEEE-802.11i], supported, the AP
ciphersuites are advertised conversation typically
takes place in the Beacon and Probe Responses prior
to three phases:

Phase 0: Discovery
Phase 1: Authentication
1a: EAP authentication, authentication
1b: AAA Key Transport (optional)
Phase 2: Secure Association Establishment
2a: Unicast Secure Association
2b: Multicast Secure Association (optional)

Of these phases, Phase 0, 1b and Phase 2 are securely verified during a 4-way
handshake exchange.

Advantages of ciphersuite-independence include:

Reduced update requirements
If EAP methods were to specify how to derive transient session keys
for each ciphersuite, they would need to be updated each time handled by a new
ciphersuite is developed. lower
layer. In addition, backend authentication
servers might not be usable with all EAP-capable authenticators,
since the backend authentication server would also need discovery phase (phase 0), peers locate
authenticators and discover their capabilities. A peer may locate an
authenticator providing access to be
updated each time support for a new ciphersuite is added particular network, or a peer may
locate an authenticator behind a bridge with which it desires to
establish a Secure Association. Discovery can occur manually or
automatically, depending on the
authenticator.

Reduced lower layer over which EAP method complexity
Requiring runs.

The authentication phase (phase 1) may begin once the peer and
authenticator discover each other. This phase, if it occurs, always
includes EAP authentication (phase 1a). Where the chosen EAP method to include ciphersuite-specific code for
transient session
supports key derivation would increase method complexity
and result derivation, in duplicated effort.

Simplified configuration
The ciphersuite phase 1a EAP keying material is negotiated between derived
on both the peer and authenticator
outside of EAP. Where the authenticator operates in "pass-through"
mode, the EAP server server.

An additional step (phase 1b) is not required in deployments which
include a party to this negotiation, nor is it
involved backend authentication server, in order to transport keying
material from the data flow between backend authentication server to the EAP peer and authenticator.
As
In order to obey the principle of Mode Independence, where a result, backend
server is present AAA Key transport needs to provide the exported EAP server may not have knowledge
keying material and/or derived keys required for derivation of the
ciphersuites and negotiation policies implemented by
TSKs. Since existing TSK derivation techniques depend solely on the peer and
authenticator, or be aware of
MSK, in existing AAA implementations, this is the ciphersuite negotiated between
them. For example, since ECP negotiation occurs after
authentication, when run over PPP, only keying
material replicated in the AAA key transport phase 1b.

Successful completion of EAP authentication and key derivation by a
peer and EAP server may does not
anticipate necessarily imply that the negotiated ciphersuite and therefore this
information cannot be provided peer is
committed to joining the network associated with an EAP method.

2. Lower Layer Operation

Where EAP key derivation server.
Rather, this commitment is supported, the conversation typically
takes place in three phases:

Phase 0: Discovery
Phase 1: Authentication
1a: EAP authentication
1b: AAA-Key Transport (optional)
Phase 2: Secure Association Establishment
2a: Unicast Secure Association
2b: Multicast Secure Association (optional)

Aboba, et al. Standards Track [Page 16]

INTERNET-DRAFT EAP Key Management Framework 17 July 2005

Of these phases, Phase 0, 1b and Phase 2 are handled implied by a lower
layer. In the discovery phase (phase 0), peers locate
authenticators and discover their capabilities. For example, a peer
may locate an authenticator providing access to a particular network,
or a peer may locate an authenticator behind a bridge with which it
desires to establish creation of a Secure Association.

The authentication phase (phase 1) may begin once the peer and
authenticator discover each other. This phase always includes EAP
authentication (phase 1a). Where security
association between the chosen EAP method supports key
derivation, in phase 1a keying material is derived on both the peer and the EAP server. This keying material may be used for multiple
purposes, including protection authenticator, as part of the EAP conversation and subsequent
data exchanges.

An additional step
Secure Association Protocol (phase 1b) is required in deployments which
include a backend authentication server, in order to transport keying
material (known as the AAA-Key) from the backend authentication
server to the authenticator.

A 2).

The Secure Association exchange (phase 2) then occurs between the peer and
authenticator in order to manage the creation and deletion of unicast (phase 2a) and multicast (phase 2b) security

Aboba, et al. Standards Track [Page 13]

INTERNET-DRAFT EAP Key Management Framework 23 October 2005

(phase 2a) and multicast (phase 2b) security associations between the
peer and authenticator. The conversation phases and relationship between the parties is
shown in Figure 4. 2.

Figure 4: 2: Conversation Overview

Aboba, et al. Standards Track [Page 17]

INTERNET-DRAFT EAP Key Management Framework 17 July 2005

2.1. Discovery Phase

2.2. Layering

In the discovery phase (phase 0), the completion of EAP authentication, EAP methods on the peer and authenticator
locate each other and discover each other's capabilities. Discovery
can occur manually or automatically, depending on EAP
server export the lower layer
over which Master Session Key (MSK), Extended Master Session
Key (EMSK), Initialization Vector (IV), Peer-ID, Server-ID, Session-
ID and Key-Lifetime. As illustrated in Figure 3, EAP runs. Since authenticator discovery is handled
outside of EAP, there is no need methods export
keying material and parameters to provide this functionality within
EAP.

For example, where EAP runs over PPP, the EAP peer might be
configured with a phone book providing phone numbers of
authenticators and associated capabilities such as supported rates,
authentication protocols or ciphersuites. In contrast, PPPoE
[RFC2516] provides support for a Discovery Stage to allow a authenticator
layers.

The EAP peer to
identify the Ethernet MAC address of one or more authenticators and
establish a PPPoE SESSION_ID.

IEEE 802.11 [IEEE-802.11] also provides integrated discovery support
utilizing Beacon and/or Probe Request/Response frames, allowing authenticator layers MUST NOT modify or cache keying
material or parameters (including Channel Bindings) passing in either
direction between the
peer (known as EAP method layer and the station EAP layer. The EAP
layer also MUST NOT cache keying material or STA) parameters (including
Channel Bindings) passed to determine it by the MAC address and
capabilities of one or more authenticators (known as Access Point EAP peer/authenticator layer or
APs).

2.2. Authentication Phase

Once
the peer and authenticator discover each other, they exchange
EAP packets. Typically, the peer desires access to the network, and
the authenticators provide that access. In such a situation, access
to lower layer.

Based on the network can be provided Method-ID exported by any authenticator attaching to the
desired network, and the EAP peer is typically willing to send data
traffic through any authenticator that can demonstrate that it is
authorized to provide access to method, the desired network.

An EAP authenticator may handle the authentication locally, or it may
act as a pass-through to a backend authentication server. In the
latter case layer
forms the EAP exchange occurs between Session-ID by concatenating the EAP peer and a
backend authenticator server, Expanded Type with
the authenticator forwarding EAP
packets between the two. The entity which terminates EAP
authentication Method-ID. Together with the peer is known as the EAP server. Where pass-
through is supported, the backend authentication server functions as
the EAP server; where authentication occurs locally, MSK, IV (deprecated), Peer-ID,
Server-ID, and Key-Lifetime, the EAP server
is the authenticator. Where a backend authentication server is
present, at the successful completion of an authentication exchange, layer passes the AAA-Key is transported Session-ID down
to the authenticator (phase 1b).

EAP may also lower layer.

The EMSK MUST NOT be used when it is desired for two network devices (e.g.
two switches or routers) to authenticate each other, or where two
peers desire provided to authenticate each other and set up a secure the lower layer, nor is it permitted

Aboba, et al. Standards Track [Page 18] 14]

INTERNET-DRAFT EAP Key Management Framework 17 July 23 October 2005

association suitable for protecting data traffic.

Some EAP methods exist which only support one-way authentication;
however, EAP methods deriving keys are required

to support mutual
authentication. In either case, it can be assumed that pass any quantity to the parties
do not utilize the link to exchange data traffic unless their
authentication requirements have been met. For example, a peer
completing mutual authentication with an EAP server will not send
data traffic over the link until the EAP server has authenticated
successfully to lower layer from which the peer, and a Secure Association has been
negotiated.

Since EAP is EMSK could be
computed without breaking some cryptographic assumption, such as
inverting a peer-to-peer protocol, an independent and simultaneous
authentication may take place one-way function. As noted in the reverse direction. Both peers
may act as authenticators [RFC3748] Section 7.10:

The EMSK is reserved for future use and authenticatees at MUST remain on the same time.

Successful completion of EAP authentication and key derivation by a
peer and EAP server does not necessarily imply that the peer where it is
committed derived; it MUST NOT be
transported to, or shared with, additional parties, or used to joining
derive any other keys. (This restriction will be relaxed in a
future document that specifies how the network associated with an EAP server.
Rather, this commitment EMSK can be used.)

The Method-ID is implied exported by the creation of a security
association between the EAP peer and authenticator, as part of methods rather than the
Secure Association Protocol (phase 2). As a result, EAP may be used
for "pre-authentication" in situations where it is necessary Session-ID
so as to pre-
establish prevent EAP security associations in methods from writing into each other's Session-
ID space.

In order to decrease handoff or
roaming latency.

2.3. Secure Association Phase

The Secure Association phase (phase 2), if it occurs, begins after preserve the completion security of keys derived within EAP authentication (phase 1a) and key transport
(phase 1b). A Secure Association Protocol used with EAP typically
supports the following features:

[1] Generation of fresh transient session methods,
lower layers other than AAA MUST NOT export keys (TSKs). Where AAA-Key
caching is supported, the passed down by EAP peer may initiate a new session using
a AAA-Key
methods. This implies that was used in EAP keying material or parameters passed
down to a previous session. Were lower layer are for the TSKs to exclusive use of that lower layer
and MUST NOT be
derived used within another lower layer. This prevents
compromise of one lower layer from compromising other applications
using EAP keying parameters.

EAP keying material and parameters provided to a portion of the AAA-Key, this would result in reuse
of lower layer other
than AAA MUST NOT be transported to another entity. For example, EAP
keying material and parameters passed down to the session keys which could expose EAP peer lower
layer MUST NOT leave the underlying ciphersuite peer; EAP keying material and parameters
passed down or transported to attack.

As a result, where AAA-Key caching is supported, the Secure
Association Protocol phase is REQUIRED, and EAP authenticator lower layer MUST provide for
freshness of
NOT leave the TSKs. This authenticator.

The exception to the "no sharing" rule is typically handled via the exchange
of nonces or counters, which are then mixed with AAA layer. On EAP
server, keying material requested by and passed down to the AAA-Key in
order AAA layer
may be replicated to generate fresh unicast (phase 2a) and possibly multicast
(phase 2b) session keys. By not using the AAA-Key directly AAA layer on the authenticator. On the
authenticator, the AAA layer may provide the replicated keying
material to
protect data, the Secure Association Protocol protects against
compromise of lower layer over which the AAA-Key.

Aboba, et al. Standards Track [Page 19]

INTERNET-DRAFT EAP Key Management Framework 17 July 2005

[2] Entity Naming. A basic feature of a Secure Association Protocol is
the explicit naming of the parties engaged in the exchange.
Explicit identification of the parties is critical, since without
this the parties engaged authentication
conversation took place. This enables "mode independence" to be
maintained.

As illustrated in the exchange are not identified Figure 4, a AAA client receiving transported EAP
keying material and parameters passes them to the
scope of EAP authenticator
and EAP layers, which then provide them to the transient session keys (TSKs) generated during authenticator lower
layer using the
exchange is undefined. As illustrated in Figure 3, both same mechanisms that would be used if the EAP peer
and NAS may have more than one physical or virtual port, so that
port identifiers are NOT RECOMMENDED as authenticator were conducting a naming mechanism.

[3] Secure capabilities negotiation. This includes the secure
negotiation of usage modes, session parameters (such as stand-alone conversation. The
resulting key
lifetimes), ciphersuites and required filters, including
confirmation of state in the capabilities discovered during phase 0. It lower layer is
RECOMMENDED that indistinguishable between
the Secure Association Protocol support secure
capabilities negotiation, in standalone and pass-through cases, as required by the principle
of mode independence. In order to protect against spoofing
during prevent the discovery phase, compromise of
transported EAP keying material and to ensure agreement between parameters, the
peer AAA client and
EAP authenticator about how data is to MUST be secured.

[4] Key management. co-resident.

Aboba, et al. Standards Track [Page 15]

INTERNET-DRAFT EAP as defined in [RFC3748] supports key
derivation, but not key management. While Key Management Framework 23 October 2005

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| EAP methods may derive
keying material, method |
| |
| MSK, EMSK, IV, Channel |
| Peer-ID, Server-ID, Bindings |
| Method-ID, |
| Key-Lifetime |
| |
| V ^ ^ |
+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+
| ! ! ! |
| EAP does provide for the management of exported ! Peer or
derived keys. For example, Authenticator ! ! |
| ! layer ! ! |
| ! ! ! |
+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+
| ! ! ! |
| EAP does not support negotiation of the
key lifetime ! layer ! ! |
| ! ! ! |
| ! Session-ID = ! ! |
| ! Expanded-Type || ! ! |
| ! Method-ID ! ! |
| ! ! ! |
+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+
| ! ! ! |
| Lower ! layer ! ! |
| ! ! ! |
| V V ^ |
| MSK, IV, Peer-ID, Channel Result |
| Server-ID, Bindings |
| Session-ID, |
| Key-Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: Flow of exported or derived keys, nor does it support
rekey. Although EAP methods may support "fast reconnect" as
defined in [RFC3748] Section 7.2.1, rekey of exported keys cannot
occur without reauthentication. In order to provide method
independence, key management of exported or derived keys SHOULD NOT
be provided within parameters

Aboba, et al. Standards Track [Page 16]

INTERNET-DRAFT EAP methods.

Since neither Key Management Framework 23 October 2005

Peer Pass-through Authenticator Authentication
Server

+-+-+-+-+-+-+ +-+-+-+-+-+-+
| | | |
|EAP method | |EAP method |
| V | | V |
+-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+
| ! | |EAP | EAP nor | | | ! |
| ! | |Peer | Auth.| EAP methods provide key management support,
it is RECOMMENDED that key management facilities be provided within
the Secure Association Protocol. This includes key lifetime
management (such as via explicit key lifetime negotiation, or
seamless rekey), as well synchronization Auth. | | ! |
|EAP ! peer| | | +-----------+ | |EAP !Auth.|
| ! | | | ! | ! | | ! |
+-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+
| ! | | ! | ! | | ! |
|EAP !layer| | EAP !layer| EAP !layer | |EAP !layer|
| ! | | ! | ! | | ! |
+-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+
| V | | V | ! | | ! |
|Lower layer| | Lower layer| AAA ! /IP | | AAA ! /IP |
| | | | ! | | ! |
+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+
! !
! !
+---------<-------+

Figure 4: Flow of EAP Keying Material and Parameters

2.3. Caching

Where explicitly supported by the lower layer, lower layers MAY cache
the installation exported EAP keying material and
deletion of keys so as to enable recovery from partial or complete
loss parameters and/or TSKs. The
structure of this key state cache is defined by the peer or authenticator. Since key
management requires a key naming scheme, Secure Association
Protocols supporting key management support lower layer. So as to
enable interoperability, new lower layer specifications MUST also support
describe EAP key
naming.

[5] Mutual proof of possession of the AAA-Key. The Secure Association
Protocol MUST demonstrate mutual proof of posession of caching behavior. Unless explicitly specified by
the AAA-Key,
in order to show that both lower layer, the peer EAP peer, server and authenticator have been
authenticated MUST assume
that peers and authorized by the backend authentication server.
Since mutual proof of possession is authenticators do not the same as mutual
authentication, the peer cannot verify authenticator assertions
(including the authenticator identity) cache exported EAP keying
parameters or TSKs.

The caching behavior of existing EAP lower layers is as a result follows:

PPP PPP, defined in [RFC1661] does not support caching of EAP keying
material or parameters. Since PPP ciphersuites derive their TSKs
directly from the MSK as described in [RFC2716], were PPP to
support caching, this
exchange. could result in stale TSKs. Therefore once
the PPP session is terminated, it is assumed that EAP keying
material and parameters are discarded.

Aboba, et al. Standards Track [Page 20] 17]

INTERNET-DRAFT EAP Key Management Framework 17 July 23 October 2005

2.4. Lower Layer Key Hierarchy

From the keys exported by the EAP method, two other types of keys may
be derived:

[3] Keys calculated from exported quantities: AAA-Key.
[4] Keys calculated by the Secure Association Protocol from the
AAA-Key: TSKs.

In order to protect the

IKEv2
IKEv2, defined in [IKEv2] only uses EAP conversation, methods supporting keying material for
authentication purposes and not key
derivation typically negotiate derivation. As a ciphersuite and derive Transient result, IKEv2
does not cache EAP
Keys (TEKs) for use with that ciphersuite. The TEKs are stored
locally by keying material or parameters, nor does it
utilize the Key-Lifetime to determine the lifetime of IPsec SAs.
As result, once IKEv2 authentication completes it is assumed that
EAP method keying material and parameters are discarded.

IEEE 802.11i
IEEE 802.11i enables caching of the MSK, but not exported.

As noted in [RFC3748] Section 7.10, EAP methods generating keys are
required to calculate and export the MSK and EMSK, which must be at
least 64 octets in length. EAP methods also may export IV,
Peer-ID, Server-ID, Session-ID, or Key-Lifetime. More details are
about the IV;
however, structure of the use cache are available in [IEEE-802.11i].

IEEE 802.1X-2004
IEEE 802.1X-2004, defined in [IEEE-802.1X-2004] does not support
caching of the IV is deprecated. On both the peer and EAP
server, the exported MSK is utilized in order to calculate the AAA-
Key. Where a backend authentication server is present, the AAA-Key
is transported from the backend authentication server to the
authenticator within the AAA-Token, using the AAA protocol.

Once keying material or parameters. Therefore once EAP
authentication completes and is successful, the peer and
authenticator obtain the AAA-Key and the Secure Association Protocol completes, it is run between the peer and authenticator in order to securely
negotiate the ciphersuite, derive fresh TSKs used to protect data, assumed that EAP keying material
and provide mutual proof of possession of the AAA-Key.

When the authenticator acts as an endpoint parameters are discarded.

AAA Existing AAA servers supporting RADIUS/EAP [RFC3579] or Diameter
EAP [RFC4207] do not support caching of the EAP conversation
rather than a pass-through, keying material or
parameters. In existing AAA server implementations, exported EAP methods are implemented on the
authenticator
keying material (MSK, EMSK and IV) as well as the peer. If the EAP method negotiated
between the EAP peer and authenticator supports mutual authentication
and key derivation, the EAP Master Session Key (MSK) parameters and Extended
Master Session Key (EMSK) are
derived on the EAP peer and
authenticator keys are not cached and exported by MUST be presumed lost after the EAP method. AAA
exchange completes.

In this case, order to avoid key reuse, the MSK
and EMSK AAA layer MUST delete transported
keys once they are known only sent. The AAA layer MUST NOT retain keys that
it has previously sent to the peer and authenticator and no other
parties. The TEKs and TSKs also reside solely on the peer and authenticator. This is illustrated in Figure 6. As demonstrated in
[I-D.ietf-roamops-cert], in this case it is still possible to support
roaming between providers, using certificate-based authentication.

Where For example, a backend authentication server is utilized, AAA
layer that has transported the situation is
illustrated in Figure 7. Here MSK MUST delete it, and keys MUST
NOT be derived from the MSK from that point forward.

2.4. Key Scope

It should be understood that an EAP authenticator acts or peer:

[a] may contain one or more physical or logical ports;
[b] may advertise itself as a pass-
through between one or more "virtual"
authenticators or peers;
[c] may utilize multiple CPUs;
[d] may support clustering services for load balancing or failover.

The issues that arise from this are discussed below.

2.4.1. Multiple Ports

Both the EAP peer and a backend authentication server. In
this model, the authenticator delegates the may have more than one physical
or logical port. A peer may simultaneously access control decision
to the backend authentication server, which acts as a Key
Distribution Center (KDC). In this case, the authenticator network via

Aboba, et al. Standards Track [Page 21] 18]

INTERNET-DRAFT EAP Key Management Framework 17 July 23 October 2005

encapsulates EAP packet with a AAA protocol such as RADIUS [RFC3579]

multiple authenticators, or Diameter [I-D.ietf-aaa-eap], and forwards packets to and from the
backend authentication server, which acts as the EAP server. Since
the via multiple physical or logical ports on
a given authenticator. Similarly, an authenticator acts as may offer network
access to multiple peers, each via a pass-through, EAP methods reside only on
the peer and separate physical or logical
port. The situation is illustrated in Figure 5.

+-+-+-+-+
| EAP server As a result, the TEKs, MSK and EMSK are
derived on the peer and EAP server.

On completion of EAP authentication, EAP methods on the peer and EAP
server export the Master Session Key (MSK) and Extended Master
Session Key (EMSK). The peer and EAP server then calculate the AAA-
Key from the MSK and EMSK, and the backend authentication server
sends an Access-Accept to the authenticator, providing the AAA-Key
within a protected package known as the AAA-Token.

The AAA-Key is then used by the peer and authenticator within the
Secure Association Protocol to derive Transient Session Keys (TSKs)
required for the negotiated ciphersuite. The TSKs are known only to
the peer and authenticator.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | ^
| EAP Method | Local to |
| Peer | EAP
+-+-+-+-+
| | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | Peer Ports
/ | \
/ | \
/ | TEK \
/ | \
/ | MSK \
/ | |EMSK \
/ | |IV \
/ | \
| | | |Derivation | |Derivation | |Derivation | |Derivation | | | Authenticator Ports
+-+-+-+-+ +-+-+-+-+ +-+-+-+-+
| +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | | | | |
| Auth. | V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ | Auth. | | ^ Auth. | MSK (64B)
| EMSK (64B) | IV (64B) Exported| | | | by |
+-+-+-+-+ +-+-+-+-+ +-+-+-+-+
\ | /
\ | /
\ | /
EAP |
| V V v
| ---+
| AAA-Key Transported |
| by over AAA \ | /
(optional) \ | Protocol |
V V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | ^
| TSK Derivation | Lower layer /
\ | /
\ | [AAA-Key Cache] /
\ | Specific /
+-+-+-+-+
| EAP |
|Server | V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
+-+-+-+-+

Figure 5: Complete Key Hierarchy

Aboba, et al. Standards Track [Page 22]

INTERNET-DRAFT Relationship between EAP Key Management Framework 17 July 2005

Figure 6: Relationship between peer, authenticator and server

Absent explicit specification within the lower layer, EAP keying
material and parameters are not bound to a specific peer or
authenticator port. Where the peer and authenticator (acting identify
themselves within the lower layer using a port identifier such as
an EAP server), where no backend authentication server is present. a
link layer address, this creates a problem, because it may not be
obvious to the peer which authenticator ports are associated with
which authenticators. Similarly, it may not be obvious to the
authenticator which peer ports are associated with which peers. As a
result, the peer and authenticator may not be able to determine the

Aboba, et al. Standards Track [Page 23] 19]

INTERNET-DRAFT EAP Key Management Framework 17 July 23 October 2005

+-+-+-+-+-+ +-+-+-+-+-+
| | | |
| | | |
| Cipher- | | Cipher- |
| Suite | | Suite |
| | | |
+-+-+-+-+-+ +-+-+-+-+-+
^ ^
| |
| |
| |
V V
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
| |===============| |========| |
| |EAP, TEK Deriv.| | | |
| |<-------------------------------->| backend |
| | | |AAA-Key/| |
| | Secure Assoc. | | Name | |
| peer |<------------->|Authenti-|<-------| auth |
| |===============| cator |========| server |
| | Link Layer | | AAA | (EAP |
| | (PPP,IEEE 802)| |Protocol| server) |
| | | | | |
|MSK,EMSK | | MSK | |MSK,EMSK |
| (TSKs) | | (TSKs) | | |
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
^ ^
| |
| MSK, EMSK | MSK, EMSK
| |
| |
+-+-+-+-+-+ +-+-+-+-+-+
| | | |
| EAP | | EAP |
| Method | | Method |
| | | |
| (TEKs) | | (TEKs) |
| | | |
+-+-+-+-+-+ +-+-+-+-+-+

Figure 7: Pass-through relationship between

scope of the EAP peer, authenticator
and backend authentication server.

2.5. AAA-Key Derivation and Naming

In existing usage, keying material. This is particularly problematic
for lower layers where a AAA-Key key caching is generated as supported.

For example, where the result of a
successful EAP authentication with peer cannot identify the EAP
authenticator, the AAA-Key is

Aboba, et al. Standards Track [Page 24]

INTERNET-DRAFT it will be unable to determine whether EAP Key Management Framework 17 July 2005

based on the MSK: AAA-Key = MSK(0,63).

In existing usage, the AAA-Key keying
material has been shared outside of its authorized scope, and
therefore needs to be considered compromised. There is always derived from also a
practical problem because the MSK so can EAP peer will be referred unable to using utilize the MSK name.
EAP authenticator key cache in an efficient way.

The AAA-Key scope solution to this problem is provided by the concatenation of the for lower layers to identify EAP
peers and authenticators unambiguously, without incorporating
implicit assumptions about peer
name (if securely provided to the authenticator), and the authenticator name (if securely provided to the peer).

For the purpose of identifying the authenticator to the peer, the
value architectures. Use
of the NAS-Identifier attribute port identifiers is recommended. The
authenticator NOT RECOMMENDED where peers and authenticators
may include the NAS-Identifier attribute to the support multiple ports.

AAA
server in an Access-Request, protocols such as RADIUS [RFC3579] and the authenticator may Diameter [RFC4072] provide
a mechanism for the
NAS-Identifier to identification of AAA clients; since the EAP peer. Mechanisms for
authenticator and AAA client are always co-resident, this include use of mechanism
can be applied to the EAP-Request/Identity (unsecured) identification of EAP authenticators.

RADIUS requires that an Access-Request packet contain one or a lower layer mechanism (such
as more of
the 802.11 Beacon/Probe Response). Where NAS-Identifier, NAS-IP-Address and NAS-IPv6-Address attributes.
Since a NAS may have more than one IP address associated with it, the
NAS-Identifier attribute is
provided by RECOMMENDED for the authenticator to unambiguous
identification of the peer a secure mechanism is
RECOMMENDED.

For EAP authenticator.

From the purpose point of view of identifying the peer AAA server, EAP keying material and
parameters are transported to the authenticator, NAS identified by the EAP
peer identifier provided within NAS-
Identifier attribute. Since the NAS/ EAP method is recommended. It
cannot be assumed that the authenticator is aware of the MUST NOT
share EAP peer
name used within the method. Therefore alternatives mechanisms need
to be used to provide keying material or parameters with another party, if the
EAP peer name to the authenticator. For
example, the or AAA server may include the detects use of EAP peer name in keying material and
parameters outside the User-
Name attribute of scope defined by the Access-Accept or NAS-Identifier, the peer may provide
keying material MUST be considered compromised.

In order to further limit the
authenticator with its name via a key scope the following measures are
suggested:

[a] The lower layer mechanism.

Absent an explicit binding step within MAY specify additional restrictions on key usage,
such as limiting the Secure Association
Protocol, use of EAP keying material and parameters on
the AAA-Key is not bound to a specific EAP peer or
authenticator port. As a result, to the peer or authenticator port over which on the EAP conversation takes place is not included in the AAA-Key
scope.

2.5.1. TSKs was
conducted.

[b] The TSKs are typically named. Their naming is specified AAA server and client/authenticator MAY implement additional
attributes in order to further restrict the Secure
Association (phase 2) protocol, so that the correct set of transient
session keys can be identified for processing a given packet. The scope of EAP keying
material. For example, in 802.11, the TSKs is negotiated within AAA server may provide the Secure Association
Protocol.

TSK creation and deletion operations are typically supported so that
establishment and re-establishment
authenticator with a list of TSKs can be synchronized
between the parties.

In order to avoid confusion in the case where an authorized Called or Calling-Station-
Ids and/or SSIDs for which EAP peer has more
than one AAA-Key (phase 1b) applicable to establishment of a phase 2 keying material is valid.

Aboba, et al. Standards Track [Page 25] 20]

INTERNET-DRAFT EAP Key Management Framework 17 July 23 October 2005

security association,

[c] Where the secure Association protocol needs to
utilize AAA server provides attributes restricting the AAA-Key name so key scope,
it is RECOMMENDED that restrictions be securely communicated by the appropriate phase 1b keying
material
authenticator to the peer. This can be identified for use in accomplished using the
Secure Association Protocol
exchange.

3. Security Associations

During EAP authentication and subsequent exchanges, four types of
security associations (SAs) are created:

[1] Protocol, but also can be accomplished via the
EAP method SA. This SA is between or the peer and EAP server. It
stores state that can be used for "fast reconnect" or other
functionality in some EAP methods. Not all EAP methods create such
an SA.

[2] EAP-Key SA. This is an SA between lower layer.

2.4.2. Virtual Authenticators

When a single physical authenticator advertises itself as multiple
"virtual authenticators", the EAP peer and EAP server, which
is used authenticator also may not
be able to store the keying material exported by agree on the EAP method.
Current EAP server implementations do not retain this SA after scope of the EAP conversation completes.

[3] AAA SA(s). These SAs are between the authenticator and the backend
authentication server. They permit keying material, creating a
security vulnerability. For example, the parties to mutually
authenticate each other and protect peer may assume that the communications between
them.

[4] Service SA(s). These SAs
"virtual authenticators" are between the peer and authenticator, distinct and they are created as do not share a result of phases 1-2 of key cache,
whereas, depending on the conversation
(see Section 2).

Examples architecture of security associations are provided in Appendix F.

3.1. EAP Method SA (peer - EAP server)

An EAP method may store some state on the peer and physical authenticator,
a shared key cache may or may not be implemented.

Where EAP server even
after phase 1a has completed.

Typically, this keying material is used for "fast reconnect": the shared between "virtual authenticators"
an attacker acting as a peer could authenticate with the "Guest"
"virtual authenticator" and derive EAP server
can confirm that they are still talking to keying material. If the same party, perhaps
using fewer round-trips or less computational power. In this case,
virtual authenticators share a key cache, then the peer can utilize
the EAP method SA is essentially a cache keying material derived for performance
optimization, and either party may remove the SA from its "Guest" network to obtain
access to the "Corporate Intranet" virtual authenticator.

Several measures are recommended to address these issues:

[d] Authenticators are REQUIRED to cache at
any point.

An associated authorizations
along with EAP method may also keep state in order keying material and parameters and to support pseudonym-based
identity protection. apply
authorizations consistently. This is typically a ensures that an attacker cannot
obtain elevated privileges even where the key cache is shared
between "virtual authenticators".

[e] It is RECOMMENDED that physical authenticators maintain separate
key caches for each "virtual authenticator".

[f] It is RECOMMENDED that each "virtual authenticator" identify itself
distinctly to the AAA server, such as well (the
information can be recreated if by utilizing a distinct NAS-
Identifier attribute. This enables the original AAA server to utilize a
separate credential to authenticate each "virtual authenticator".

3. Key Management

EAP method SA is lost), as defined in [RFC3748] supports key derivation, but not key
management. While EAP methods may be stored derive keying material, EAP does
not provide for longer periods the management of time. exported or derived keys. For
example, EAP does not support negotiation of the key lifetime of
exported or derived keys, nor does it support re-key. Although EAP
methods may support "fast reconnect" as defined in [RFC3748] Section
7.2.1, re-key of exported keys cannot occur without re-

Aboba, et al. Standards Track [Page 26] 21]

INTERNET-DRAFT EAP Key Management Framework 17 July 23 October 2005

The EAP method SA is not restricted

authentication. In order to a particular service provide method independence, key
management of exported or
authenticator and is most useful when the peer accesses many
different authenticators. An derived keys SHOULD NOT be provided within
EAP method is responsible for
specifying how the parties select if an existing EAP method SA should
be used, and if so, which one. Where multiple backend authentication
servers are used, EAP method SAs are not typically synchronized
between them. methods.

3.1. Secure Association Protocol

Since neither EAP method implementations should consider the appropriate lifetime
for the nor EAP method SA. "Fast reconnect" assumes methods provide key management support, it
is RECOMMENDED that key management facilities be provided within the information
required (primarily
Secure Association Protocol. This includes:

[a] Entity Naming. A basic feature of a Secure Association Protocol is
the keys explicit naming of the parties engaged in the EAP method SA) hasn't been
compromised. In case exchange.
Without explicit identification, the original authentication was carried out
using, for instance, a smart card, it may be easier to compromise parties engaged in the
EAP method SA (stored on
exchange are not identified and the PC, for instance), so typically scope of the EAP
method SAs have a limited lifetime.

Contents:

o Implicitly, keying
parameters negotiated during the EAP method this SA refers to
o Internal (non-exported) cryptographic state
o EAP method SA name
o SA lifetime

3.2. EAP-Key SA

This exchange is an SA between undefined. As
shown in Figure 5, both the peer and EAP server, which authenticator may have more
than one physical or virtual port, and as a result SHOULD identify
themselves in a manner that is used to store
the keying material exported by the EAP method. Current independent of their attached ports.

[b] Mutual proof of possession of EAP server
implementations do not retain this SA after keying material. During the EAP conversation
completes. As a result, all keys exported by
Secure Association Protocol the EAP method
(including the MSK, EMSK peer and IV) on authenticator MUST
demonstrate possession of the AAA keying material transported between
the backend authentication server are discarded and
are not cached. Calculated keys (such as the AAA-Key) are also
discarded and not cached.

3.3. AAA SA(s) (authenticator - backend authentication server)

In order for the authenticator and backend authentication server to
authenticate each other, they need (e.g. MSK), in
order to store some information.

In case demonstrate that the authenticator peer and backend authentication server are
colocated, authenticator have been and they communicate using local procedure calls or shared
memory, this SA need
authorized. Since mutual proof of possession is not necessarily contain any information.

3.4. Service SA(s) (peer - authenticator)

The service SAs store information about the service being provided.
These include the Root service SA and derived unicast and multicast
service SAs.

Aboba, et al. Standards Track [Page 27]

INTERNET-DRAFT EAP Key Management Framework 17 July 2005

The Root service SA is established same as
mutual authentication, the peer cannot verify authenticator
assertions (including the authenticator identity) as a result of
this exchange.

[c] Secure capabilities negotiation. In order to protect against
spoofing during the completion discovery phase, ensure selection of
EAP authentication (phase 1a) the "best"
ciphersuite, and AAA-Key derivation or transport
(phase 1b). It includes:

o Service parameters (or at least those parameters
that are still needed)
o On protect against forging of negotiated security
parameters, the authenticator, service authorization
information received from Secure Association Protocol MUST support secure
capabilities negotiation. This includes the backend authentication
server (or necessary parts secure negotiation of it)
o On the peer, usually locally configured service
authorization information.
o The AAA-Key, if it can be needed again (to refresh
and/or resynchronize other keys or for another reason)
o AAA-Key lifetime

Unicast
usage modes, session parameters (such as security association
identifiers (SAIDs) and (optionally) multicast service SAs are derived from the
Root service SA, via key lifetimes), ciphersuites and required
filters, including confirmation of security-relevant capabilities
discovered during phase 0. As part of secure capabilities
negotiation, the Secure Association Protocol. In order for
unicast Protocol MUST support integrity
and multicast service SAs replay protection of all messages.

[d] Key naming and associated TSKs to be
established, it selection. Where key caching is not necessary supported, it may
be possible for the EAP authentication (phase 1a) peer and authenticator to
be rerun each time. Instead, share more than
one key of a given type. As a result, the Secure Association
Protocol can be MUST explicitly name the keys used to mutually prove in the proof of
possession exchange, so as to prevent confusion when more than one
set of keying material could potentially be used as the AAA-Key and create
associated unicast (phase 2a) and multicast (phase 2b) service SAs
and TSKs, enabling basis for
the exchange. Use of the key naming mechanism described in this

Aboba, et al. Standards Track [Page 22]

INTERNET-DRAFT EAP exchange Key Management Framework 23 October 2005

document is RECOMMENDED.

In order to be bypassed. Unicast and
multicast service SAs include:

o Service parameters negotiated by support the correct processing of phase 2 security
associations, the Secure Association Protocol.
o Endpoint identifiers.
o Transient Session Keys used to protect (phase 2) protocol MUST
support the communication.
o Transient Session Key lifetime.

One function naming of phase 2 security associations and associated
transient session keys, so that the correct set of transient
session keys can be identified for processing a given packet. The
phase 2 Secure Association Protocol is to bind the the
unicast also MUST support transient
session key activation and multicast service SAs SHOULD support deletion, so that
establishment and TSKs to endpoint identifiers.
For example, within [IEEE802.11i], the 4-way handshake binds the TSKs
to the MAC addresses re-establishment of transient session keys can be
synchronized between the endpoints; in [IKEv2], the TSKs are bound
to the IP addresses parties.

[e] Generation of fresh transient session keys (TSKs). Where 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 lower
layer supports caching of exported EAP keying material, the same security parameters (e.g. mode,
ciphersuite, etc.) or they may utilize different parameters.

An EAP
peer lower layer may be able to negotiate multiple service SAs with initiate a
given authenticator, or may be able to maintain one or more service
SAs with multiple authenticators, depending on new session using keying material
that was derived in a previous session. Were the properties TSKs to be
derived from a portion of the
media.

Aboba, et al. Standards Track [Page 28]

INTERNET-DRAFT exported EAP Key Management Framework 17 July 2005

Except where explicitly specified by keying material, this
would result in reuse of the Secure Association Protocol,
it should not be assumed that session keys which could expose the installation of new service SAs
implies deletion
underlying ciphersuite to attack.

In lower layers where caching of old service SAs. It EAP keying material is possible for multicast
Root service SAs to between supported,
the same EAP peer Secure Association Protocol phase is REQUIRED, and authenticator;
during a re-key MUST support
the derivation of a fresh unicast or and multicast service SA it is possible
for two service SAs to exist during the period between TSKs, even when the new
service SA and corresponding TSKs
keying material provided by the backend authentication server is
not fresh. This is typically supported via the exchange of nonces
or counters, which are calculated and when they are
installed.

Similarly, deletion or creation of a then mixed with the exported keying material
in order to generate fresh unicast or (phase 2a) and possibly
multicast service SA
does (phase 2b) session keys. By not necessarily imply deletion or creation of related unicast or
multicast service SAs, unless specified by using EAP keying
material directly to protect data, 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 Protocol
protects it against compromise.

[f] Key lifetime management. This includes explicit key lifetime
negotiation or seamless re-key. EAP does not necessarily imply the
deletion of the derived unicast and multicast service SAs and
associated TSKs. Failure to mutually prove possession support negotiation
of the AAA-Key
during key lifetimes, nor does it support re-key without re-
authentication. As a result, the Secure Association Protocol exchange need not be grounds
for deletion may
handle re-key and determination of the AAA-Key by both parties; key lifetime. Where key
caching is supported, secure negotiation of key lifetimes is
RECOMMENDED. Lower layers that support re-key, but not key
caching, may not require key lifetime negotiation. To take an
example from IKE, the action to be taken difference between IKEv1 and IKEv2 is defined by that in
IKEv1 SA lifetimes were negotiated. In IKEv2, each end of the Secure Association Protocol.

3.4.1. Sharing service SAs

A single service may be provided by multiple logical or physical
service elements. Each service SA is
responsible for specifying how
changing service elements is handled. Some approaches include:

Transparent sharing
If the service parameters visible to enforcing its own lifetime policy on the other party (either peer
or authenticator) do not change, SA and re-
keying the service can be moved without
requiring cooperation from the other party.

Whether such a move should be supported or used depends on
implementation and administrative considerations. For instance, an
administrator may decide to configure a group of IKEv2/IPsec
gateways in a cluster SA when necessary.

[g] Key resynchronization. It is possible for high-availability purposes, if the
implementation used supports this. The peer does not necessarily
have any way or
authenticator to reboot or reclaim resources, clearing portions or
all of knowing when the change occurs.

No sharing
If the service parameters require changing, some changes may
require terminating key cache. Therefore, key lifetime negotiation cannot
guarantee that the old service, and starting a new
conversation from phase 0. This approach is used by all services
for at least some parameters, key cache will remain synchronized, and it doesn't require any protocol
for transferring the service SA between the service elements.

The service may support keeping the old service element active peer

Aboba, et al. Standards Track [Page 29] 23]

INTERNET-DRAFT EAP Key Management Framework 17 July 23 October 2005

while the new conversation takes phase,

may not be able to decrease the time determine before attempting to use a key whether
it exists within the
service authenticator cache. It is not available.

Some sharing
The service may allow changing some parameters by simply agreeing
about therefore
RECOMMENDED for the new values. This may involve Secure Association Protocol to provide a similar exchange as
mechanism for key state resynchronization. Since in
phase 2, this situation
one or perhaps a shorter conversation.

This option usually requires some protocol for transferring the
service SA between more of the elements. An administrator may decide parties initially do not possess a key with
which to
enable protect the resynchronization exchange, securing this feature at all, and typically
mechanism may be difficult.

[h] Key scope synchronization. Since the sharing Discovery phase is restricted
to some particular service elements (defined either by handled
out-of-band, EAP does not provide a service
parameter, or simple administrative decision). If the old and new
service element do not support such "context transfer", this
approach falls back to the previous option (no transfer).

Services supporting this feature should also consider what changes
require new authorization from the backend authentication server
(see Section 5.2).

Note that these considerations are not limited to service
parameters related to mechanism by which the authenticator--they apply to peer
parameters as well.

4. Key Management

EAP supports key derivation, but not key management. can
determine the authenticator identity. As a result,
key management functionality needs to be provided by where the Secure
Association Protocol. This includes:

[a] Generation of fresh transient session keys (TSKs). Where AAA-Key
authenticator has multiple ports and key caching is supported, the
EAP peer may initiate a new session using
a AAA-Key that was used in a previous session. Were the TSKs to not be
derived from a portion of able to determine the AAA-Key, this would result in reuse scope of validity of the session keys which could expose
exported EAP keying material. Similarly, where the underlying ciphersuite EAP peer has
multiple ports, the authenticator may not be able to attack. As determine
whether a result, where AAA-Key caching is supported, peer has authorization to use a particular key. To allow
key scope determination, the Secure Association Protocol phase is REQUIRED, and MUST SHOULD
provide for
freshness of a mechanism by which the TSKs.

[b] Key lifetime determination. EAP does not support negotiation peer can determine the scope of
key lifetimes, nor does it support rekey without reauthentication.
As a result,
the Secure Association Protocol may handle rekey key cache on each authenticator, and
determination by which the authenticator
can determine the scope of the key lifetime. Where key caching is supported,
secure cache on a peer. This includes
negotiation of restrictions on key lifetimes is RECOMMENDED. Lower layers
that support rekey, but not key caching, may not require key
lifetime negotiation. To take an example from IKE, usage.

[i] Direct operation. Since the difference
between IKEv1 and IKEv2 phase 2 Secure Association Protocol is that in IKEv1 SA lifetimes were
negotiated. In IKEv2, each end
concerned with the establishment of security associations between
the SA is responsible for

Aboba, et al. Standards Track [Page 30]

INTERNET-DRAFT EAP Key Management Framework 17 July 2005

enforcing its own lifetime policy on the SA peer and rekeying the SA
when necessary.

[c] Key resynchronization. It is possible for authenticator, including the peer or
authenticator to reboot or reclaim resources, clearing portions or
all derivation of
transient session keys, only those parties have "a need to know"
the key cache. Therefore, key lifetime negotiation cannot
guarantee that the key cache will remain synchronized, and transient session keys. The Secure Association Protocol MUST
operate directly between the peer
may not and authenticator, and MUST NOT
be able passed-through to determine before attempting the backend authentication server, or include
additional parties.

[j] Bi-directional operation While some ciphersuites only require a
single set of transient session keys to use protect traffic in both
directions, other ciphersuites require a AAA-Key
whether it exists within the authenticator cache. It is therefore
RECOMMENDED for the unique set of transient
session keys in each direction. The phase 2 Secure Association
Protocol to SHOULD provide a
mechanism for key state resynchronization. Since in this situation
one or more of the parties initially do derivation of unicast and multicast
keys in each direction, so as not possess a key with
which to protect the resynchronization exchange, securing this
mechanism may be difficult.

[d] Key selection. Where key caching is supported, it may be possible
for the EAP peer and authenticator require two separate phase 2
exchanges in order to share more than one key of a
given type. As create a result, bi-directional phase 2 security
association.

3.2. Parent-Child Relationships

When keying material exported by EAP methods expires, all keying
material derived from the Secure Association Protocol needs to
support key selection, using exported keying material expires, including
the TSKs.

When an EAP Key Naming scheme described in
this document.

[e] Key scope determination. Since the Discovery phase re-authentication takes place, new keying material is handled out-
of-band, EAP does not provide a mechanism
derived and exported by which the peer can
determine EAP method, which eventually results in

Aboba, et al. Standards Track [Page 24]

INTERNET-DRAFT EAP Key Management Framework 23 October 2005

replacement of calculated keys, including the authenticator identity. TSKs.

As a result, where the
authenticator has multiple ports and AAA-Key caching is supported,
the EAP peer may not be able to determine while the scope lifetime of validity calculated keys can be less than
or equal that of
a AAA-Key. Similarly, where the EAP peer has multiple ports, the
authenticator may not exported keys they are derived from, it cannot
be able greater. For example, TSK re-key may occur prior to determine whether a peer has
authorization EAP re-
authentication.

Failure to use a particular AAA-Key. To allow key scope
determination, the lower layer SHOULD provide a mechanism by which
the peer can determine mutually prove possession of keying material during the scope
Secure Association Protocol exchange need not be grounds for deletion
of the AAA-Key cache on each
authenticator, and keying material by which the authenticator can determine the
scope of the AAA-Key cache on both parties; rate-limiting Secure
Association Protocol exchanges could be used to prevent a peer.

4.1. brute force
attack.

3.3. Local Key Caching

In existing implementations, key caching may be supported on Lifetimes

The Transient EAP Keys (TEKs) are session keys used to protect the
EAP
peer conversation. The TEKs are internal to the EAP method and authenticator but are
not on the backend server. Where
explicitly supported by exported. TEKs are typically created during an EAP conversation,
used until the lower layer, end of the conversation and then discarded. However,
methods may re-key TEKs during a conversation.

When using TEKs within an EAP peer conversation or across conversations,
it is necessary to ensure that replay protection and
authenticator MAY cache key separation
requirements are fulfilled. For instance, if a replay counter is
used, TEK re-key MUST occur prior to wrapping of the AAA-Key and/or TSKs. The structure counter.
Similarly, TSKs MUST remain cryptographically separate from TEKs
despite TEK re-keying or caching. This prevents TEK compromise from
leading directly to compromise of the key TSKs and vice versa.

EAP methods may cache local keying material which may persist for
multiple EAP conversations when fast reconnect is used [RFC 3748].
For example, EAP methods based on the peer TLS (such as EAP-TLS [RFC2716])
derive and authenticator cache the TLS Master Secret, typically for substantial
time periods. The lifetime of other local keying material calculated
within the EAP method is defined by the lower
layer. Unless specified by the lower layer, the EAP peer and
authenticator MUST assume method. Note that peers and authenticators do not cache
the AAA-Key or TSKs.

In existing AAA server implementations, all keys exported in
general, when using fast reconnect, there is no guarantee to that the
original long-term credentials are still in the possession of the
peer. For instance, a card hold holding the private key for EAP-TLS
may have been removed. EAP servers SHOULD also verify that the long-
term credentials are still valid, such as by checking that
certificate used in the original authentication has not yet expired.

3.4. Exported and Calculated Key Lifetimes

All EAP methods (including generating keys are required to generate the MSK, EMSK MSK and IV)
EMSK, and calculated keys (e.g.
AAA-Key) are may optionally generate the IV. However, EAP, defined in
[RFC3748], does not cached support the negotiation of lifetimes for exported
keying material such as the MSK, EMSK and are lost after EAP authentication IV.

Aboba, et al. Standards Track [Page 31] 25]

INTERNET-DRAFT EAP Key Management Framework 17 July 23 October 2005

completes:

[1] In order to avoid

Several mechanisms exist for managing key reuse, on the EAP server, transported keys
are deleted once they are sent. An EAP server MUST NOT retain keys
that it has previously sent to lifetimes:

[a] AAA attributes. AAA protocols such as RADIUS [RFC2865] and
Diameter [RFC4072] support the authenticator. For example, an
EAP server that has transported a AAA-Key based on Session-Timeout attribute. The
Session-Timeout value represents the MSK MUST
delete maximum lifetime of the MSK,
exported keys, and no all keys may be derived from the MSK calculated from that
point forward by the server.

[2] Keys which are not transported, such as it, on the EMSK, are also deleted
by
authenticator. Since existing implementations.

4.2. Parent-Child Relationships

When keying material AAA servers do not cache keys
exported by EAP methods expires, all keying
material derived methods, or keys calculated from the exported keying material expires, including keys, the AAA-Key and TSKs.

When an
value of the Session-Timeout attribute has no bearing on the key
lifetime within the AAA server.

On the authenticator, where EAP reauthentication takes place, new keying material is
derived and exported by used for authentication, the
Session-Timeout value represents the maximum session time prior to
re-authentication, as described in [RFC3580]. Where EAP method, is used
for pre-authentication, the session may not start until some future
time, or may never occur. Nevertheless, the Session-Timeout value
represents the time after which eventually results in
replacement of transported EAP keying material,
and all keys calculated keys, including from it, will have expired on the AAA-Key and TSKs.

As a result, while
authenticator. If the lifetime of calculated keys can session subsequently starts, re-
authentication will be less than
or equal that of initiated once the exported Session-Time has expired.
If the session never started, or started and ended, by default keys they are derived from, it cannot
transported by AAA and all keys calculated from them will be greater. For example, TSK rekey may occur
expired by the authenticator prior to EAP
reauthentication.

Failure to mutually prove possession of the AAA-Key during future time indicated by
Session-Timeout.

Since the Secure
Association Protocol exchange need TSK lifetime is often determined by authenticator
resources, the AAA server has no insight into the TSK derivation
process, and by the principle of ciphersuite independence, it is
not be grounds appropriate for deletion of the
AAA-Key by both parties; rate-limiting Secure Association Protocol
exchanges could be used AAA server to prevent a brute force attack.

4.3. Local Key Lifetimes

The Transient EAP Keys (TEKs) are session keys used to protect manage any aspect of the
EAP conversation. The TEKs are internal TSK
derivation process, including the TSK lifetime.

[b] Lower layer mechanisms. While AAA attributes can communicate the
maximum exported key lifetime, this only serves to synchronize the EAP method
key lifetime between the backend authentication server and are
not exported. TEKs are typically created during an EAP conversation, the
authenticator. Lower layer mechanisms such as the Secure
Association Protocol can then be used until to enable the end lifetime of
exported and calculated keys to be negotiated between the conversation peer and then discarded. However,
methods may rekey TEKs during
authenticator.

Where TSKs are established as the result of a conversation.

When using TEKs within an EAP conversation or across conversations, Secure Association
Protocol exchange, it is necessary to ensure RECOMMENDED that replay protection and key separation
requirements are fulfilled. For instance, if a replay counter the Secure Association
Protocol include support for TSK resynchronization. Where the TSK
is
used, TEK rekey MUST occur prior taken from the MSK, there is no need to wrapping of manage the counter.
Similarly, TSKs MUST remain cryptographically TSK lifetime
as a separate from TEKs
despite TEK rekeying or caching. This prevents TEK compromise from
leading directly to compromise parameter, since the TSK lifetime and MSK lifetime
are identical.

[c] System defaults. Where the EAP method does not support the
negotiation of the TSKs exported key lifetime, and vice versa. a key lifetime

Aboba, et al. Standards Track [Page 32] 26]

INTERNET-DRAFT EAP Key Management Framework 17 July 23 October 2005

EAP methods may cache local keying material which may persist for
multiple EAP conversations when fast reconnect

negotiation mechanism is used [RFC 3748].
For example, EAP methods based on TLS (such as EAP-TLS [RFC2716])
derive and cache the TLS Master Secret, typically for substantial
time periods. The lifetime of other local keying material calculated
within the EAP method is defined not provided by the method. Note that in
general, when using fast reconnect, lower lower, there is may
be no guarantee to that way for the
original long-term credentials are still in peer to learn the possession of exported key lifetime. In this
case it is RECOMMENDED that the
peer. For instance, peer assume a card hold holding default value of the private
exported key for EAP-TLS
may have been removed. EAP servers SHOULD also verify that lifetime; 8 hours is recommended. Similarly, the long-
term credentials are still valid, such
lifetime of calculated keys can also be managed as by checking that
certificate used in a system
parameter on the original authentication has not yet expired.

4.4. Exported and Calculated Key Lifetimes

All authenticator.

[d] Method specific negotiation within EAP. While EAP methods generating keys are required to generate the MSK and
EMSK, and may optionally generate the IV. However, EAP, defined in
[RFC3748], itself does not
support the lifetime negotiation, it would be possible to specify
methods that do. However, systems that rely on such negotiation of lifetimes
for exported
keying material such keys would only function with these methods. As a
result, it is NOT RECOMMENDED to use this approach as the MSK, EMSK sole way
to determine key lifetimes.

3.5. Key cache synchronization

Issues arise when attempting to synchronize the key cache on the peer
and IV.

Several mechanisms exist for managing authenticator. Lifetime negotiation alone cannot guarantee key lifetimes:

[a] AAA attributes.
cache synchronization.

One problem is that the AAA protocols such as RADIUS [RFC2865] and
Diameter [I-D.ietf-aaa-eap] support protocol cannot guarantee synchronization
of key lifetimes between the Session-Timeout attribute.
The Session-Timeout value represents peer and authenticator. Where the maximum lifetime of
Secure Association Protocol is not run immediately after EAP
authentication, the exported keys, and all keys calculated from it, on the
authenticator. Since existing AAA servers do key lifetimes will not cache keys
exported be
known by EAP methods, or keys calculated from exported keys, the
value of the Session-Timeout attribute has no bearing on peer during the key
lifetime within hiatus. Where EAP pre-authentication
occurs, this can leave the AAA server.

On peer uncertain whether a subsequent
attempt to use the authenticator, exported keys will prove successful.

However, even where EAP the Secure Association Protocol is used run
immediately after EAP, it is still possible for authentication, the
Session-Timeout value represents the maximum session time prior authenticator to
re-authentication, as described in [RFC3580]. Where EAP is used
for pre-authentication,
reclaim resources if the session may created key state is not start until some future
time, or immediately
utilized.

The lower layer may never occur. Nevertheless, utilize Discovery mechanisms to assist in this.
For example, the Session-Timeout value
represents authenticator manages the time after which key cache by deleting the AAA-Key, and all keys
calculated from it, will have expired on
oldest key first (LIFO), the authenticator. If relative creation time of the
session subsequently starts, re-authentication will last key
to be initiated
once the Session-Time has expired. If deleted could be advertised with the session never started,
or started and ended, Discovery phase, enabling
the AAA-Key and all keys calculated from it
will be peer to determine whether a given key had been expired by from the
authenticator prior key cache prematurely.

3.6. Key Strength

In order to the future time
indicated by Session-Timeout.

Since the TSK lifetime is often determined by authenticator
resources, the AAA server has no insight into the TSK derivation
process, and by the principle guard against brute force attacks, EAP methods deriving
keys need to be capable of ciphersuite independence, it generating keys with an appropriate
effective symmetric key strength. In order to ensure that key
generation is not appropriate for the AAA server to manage any aspect of weakest link, it is RECOMMENDED that EAP
methods utilizing public key cryptography choose a public key that
has a cryptographic strength meeting the TSK symmetric key strength

Aboba, et al. Standards Track [Page 33] 27]

INTERNET-DRAFT EAP Key Management Framework 17 July 23 October 2005

derivation process, including the TSK lifetime.

[b] Lower layer mechanisms. While AAA attributes can communicate the
maximum exported key lifetime,

requirement.

As noted in [RFC3766] Section 5, this only serves to synchronize the
key lifetime between results in the backend authentication server following
required RSA or DH module and DSA subgroup size in bits, for a given
level of attack resistance in bits:

Attack Resistance RSA or DH Modulus DSA subgroup
(bits) size (bits) size (bits)
----------------- ----------------- ------------
70 947 128
80 1228 145
90 1553 153
100 1926 184
150 4575 279
200 8719 373
250 14596 475

3.7. Key Wrap

As described in [RFC3579] Section 4.3, known problems exist in the
authenticator. Lower layer mechanisms such as
key wrap specified in [RFC2548]. Where the Secure
Association Protocol can then be same RADIUS shared secret
is used to enable the lifetime of
exported and calculated keys to be negotiated between the peer and
authenticator.

Where TSKs are established as the result of by a Secure Association
Protocol exchange, it PAP authenticator and an EAP authenticator, there is RECOMMENDED that a
vulnerability to known plaintext attack. Since RADIUS uses the Secure Association
Protocol include support
shared secret for TSK resynchronization. Where the TSK multiple purposes, including per-packet
authentication, attribute hiding, considerable information is taken from exposed
about the AAA-Key, there shared secret with each packet. This exposes the shared
secret to dictionary attacks. MD5 is no need used both to manage the TSK
lifetime as a separate parameter, since compute the TSK lifetime RADIUS
Response Authenticator and AAA-
Key lifetime are identical.

[c] System defaults. Where the EAP method does not support Message-Authenticator attribute, and
some concerns exist relating to the
negotiation security of this hash
[MD5Attack].

As discussed in [RFC3579] Section 4.3, the exported key lifetime, security vulnerabilities
of RADIUS are extensive, and therefore development of an alternative
key wrap technique based on the RADIUS shared secret would not
substantially improve security. As a result, [RFC3759] Section 4.2
recommends running RADIUS over IPsec. The same approach is taken in
Diameter EAP [RFC4072], which defines cleartext key lifetime
negotiation mechanism attributes, to be
protected by IPsec or TLS.

Where an untrusted AAA intermediary is present (such as a RADIUS
proxy or a Diameter agent), and data object security is not provided by the lower lower, there used,
transported keying material may be no way for recovered by an attacker in
control of the untrusted intermediary. Possession of transported
keying material enables decryption of data traffic sent between the
peer to learn the exported key lifetime. In this
case it is RECOMMENDED that the peer assume a default value of the
exported key lifetime; 8 hours is recommended. Similarly, the
lifetime of calculated keys can also be managed as and a system
parameter on the authenticator.

[d] Method specific negotiation within EAP. While EAP itself does not
support lifetime negotiation, it would be possible to specify
methods that do. authenticator. However, systems that rely on such negotiation
for exported as long as EAP keying
material or keys would only function with these methods. As a
result, derived from it is NOT RECOMMENDED to use this approach as the sole way
to determine key lifetimes.

4.5. Key cache synchronization

Issues arise when attempting to synchronize the key cache on the peer
and authenticator. Lifetime negotiation alone cannot guarantee key
cache synchronization.

One problem is that the AAA protocol cannot guarantee synchronization only utilized by a single
authenticator, compromise of key lifetimes between the peer and authenticator. Where the
Secure Association Protocol is not run immediately after EAP
authentication, the exported and calculated key lifetimes will transported keying material does not be
known by the peer during the hiatus. Where EAP pre-authentication
occurs, this can leave
enable an attacker to impersonate the peer uncertain whether a subsequent
attempt to use the exported keys will prove successful.

However, even where the Secure Association Protocol is run another authenticator.

Aboba, et al. Standards Track [Page 34] 28]

INTERNET-DRAFT EAP Key Management Framework 17 July 23 October 2005

immediately after EAP, it is still possible for the authenticator to
reclaim resources if the created key state is not immediately
utilized.

The lower layer may utilize Discovery mechanisms

Vulnerability to assist in this.
For example, the authenticator manages the AAA-Key cache an untrusted AAA intermediary can be mitigated by deleting
the oldest AAA-Key first (LIFO), the relative creation time
implementation of the
last AAA-Key to be deleted could be advertised with the Discovery
phase, enabling the peer to determine whether a given AAA-Key had
been expired from the authenticator key cache prematurely.

4.6. Key Scope

As redirect functionality, as described in Section 2.5, [RFC3588]
and [RFC4072].

4. Handoff Vulnerabilities

With EAP, a number of mechanisms are be utilized in existing applications order to reduce
the AAA-Key latency of handoff between authenticators. One such mechanism is
derived from the MSK by
EAP pre-authentication, in which EAP is utilized to pre-establish EAP
keying material on an authenticator prior to arrival of the peer.
Another such mechanism is key caching, in which an EAP peer and server, and can re-
attach to an authenticator without having to re-authenticate using
EAP. Yet another mechanism is used context transfer, such as is defined
in [IEEE-802.11F] and [CTP]. These mechanisms introduce new security
vulnerabilities, as discussed in the
root of the ciphersuite-specific key hierarchy. Where sections that follow.

4.1. Authorization

In a backend typical network access scenario (dial-in, wireless LAN, etc.)
access control mechanisms are typically applied. These mechanisms
include user authentication server is present, the AAA-Key is transported from as well as authorization for the
EAP server to offered
service.

As a part of the authenticator; where it is not present, authentication process, the AAA-Key
is calculated on AAA network determines
the authenticator.

Regardless of how many sessions user's authorization profile. The user authorizations are initiated using it,
transmitted by the AAA-Key
scope is between backend authentication server to the EAP peer that calculates it, and the
authenticator that either calculates it (where no backend
authenticator is present) or receives it from the server (where a
backend authenticator server is present).

It should be understood that an authenticator or peer:

[a] may contain multiple physical ports;
[b] may advertise itself as multiple "virtual" authenticators
or peers;
[c] may utilize multiple CPUs;
[d] may support clustering services for load balancing or failover.

As illustrated in Figure 1, an EAP peer with multiple ports may be
attached to one or more authenticators, each with multiple ports.
Where the peer and
authenticator identify themselves using a port
identifier such (also known as a link layer address, it may not be obvious to the
peer which authenticator ports are associated Network Access Server or
authenticator) included with which
authenticators. Similarly, it may not be obvious to the
authenticator which peer ports are associated with AAA-Token, which peers. As a
result, the peer and authenticator may not be able to determine also contains the
scope
transported EAP keying material, in Phase 1b 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 conversation.
Typically, the scope of profile is determined based on the AAA-Key, creating user identity, but
a security
vulnerability. For example, certificate presented by the peer user may assume that the "virtual

Aboba, et al. Standards Track [Page 35]

INTERNET-DRAFT EAP Key Management Framework 17 July 2005

authenticators" are distinct and do not share also provide authorization
information.

The backend authentication server is responsible for making a key cache, whereas,
depending on user
authorization decision, answering the architecture 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 physical AP, a shared key cache
may subscription rules regarding time of day?

[e] Is this user within his limits for concurrent sessions?

Aboba, et al. Standards Track [Page 29]

INTERNET-DRAFT EAP Key Management Framework 23 October 2005

[f] Are there any fraud, credit limit, or may not other concerns that indicate
that access should be implemented.

Where denied?

While the AAA-Key authorization decision is shared between "virtual authenticators" an
attacker acting as a peer could authenticate with in principle simple, the "Guest"
"virtual authenticator" and derive a AAA-Key. If process
is complicated by the virtual
authenticators share a key cache, then distributed nature of AAA decision making.
Where brokering entities or proxies are involved, all of the peer can utilize AAA
devices in the AAA-
Key derived for chain from the "Guest" network to obtain access authenticator to the
"Corporate Intranet" virtual authenticator.

Several measures are recommended to address these issues:

[a] Authenticators home AAA server
are REQUIRED to cache associated authorizations
along with involved in the AAA-Key and apply authorizations consistently. This
ensures that an attacker cannot obtain elevated privileges decision. For instance, a broker can disallow
access 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 if the home AAA server, such 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 utilizing a distinct NAS-
identifier attribute. This enables the AAA server to utilize a
separate credential chain, parameters or constraints can be communicated 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 authenticator.

The AAA server and authenticator MAY implement additional
attributes in order criteria for Accept/Reject decisions or the reasons for choosing
particular authorizations are typically not communicated to further restrict the AAA-Key scope. For
example, in 802.11,
authenticator, only the AAA server may provide final result. As a result, the authenticator
with
has no way to know what the decision was based on. Was a list set of authorized Called
authorization parameters sent because this service is always provided
to the user, or Calling-Station-Ids and/or
SSIDs for which was the AAA-Key is valid.

[f] Where decision based on the AAA server provides attributes restricting time/day and the key scope,
it is RECOMMENDED that restrictions be securely communicated by
capabilities of the requesting authenticator to the peer. This can be accomplished using device?

4.2. Correctness

When the
Secure Association Protocol, but also can be accomplished AAA exchange is bypassed via use of techniques such as key
caching, this creates challenges in ensuring that authorization is
properly handled. These include:

[a] Consistent application of session time limits. Bypassing AAA
should not automatically increase the
EAP method or the lower layer.

4.7. Key Strength

In order available session time,
allowing a user to guard against brute force attacks, EAP methods deriving
keys need endlessly extend their network access by
changing the point of attachment.

[b] Avoidance of privilege elevation. Bypassing AAA 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 capable possible to take this state into
account either before or after access is granted. Note that
consideration of generating keys with an appropriate network-wide state such as simultaneous session
limits can typically only be taken into account by the backend
authentication server.

Aboba, et al. Standards Track [Page 36] 30]

INTERNET-DRAFT EAP Key Management Framework 17 July 23 October 2005

effective symmetric key strength. In order to ensure that key
generation is

[d] Encoding of restrictions. Since a authenticator may not be aware
of the weakest link, it is RECOMMENDED that EAP
methods utilizing public key cryptography choose criteria considered by a public key that
has backend authentication server when
allowing access, in order to ensure consistent authorization during
a cryptographic strength meeting fast handoff it may be necessary to explicitly encode the symmetric key strength
requirement.

As noted in [RFC3766] Section 5, this results in
restrictions within the following
required RSA or DH module and DSA subgroup size in bits, for a given
level of attack resistance in bits:

4.8. Key Wrap

As described in [RFC3579] Section 4.3, known problems exist authorizations provided in the
key wrap specified in [RFC2548]. Where AAA-Token.

[e] State validity. The introduction of fast handoff should not render
the same RADIUS shared secret authentication server incapable of keeping track of network-
wide state.

A handoff mechanism capable of addressing these concerns is used by a PAP authenticator and an EAP authenticator, there said to
be "correct". One condition for correctness is as follows: For a
vulnerability
handoff to known plaintext attack. Since RADIUS uses be "correct" it MUST establish on the
shared secret for multiple purposes, including per-packet
authentication, attribute hiding, considerable information is exposed
about new device the shared secret same
context as would have been created had the new device completed a AAA
conversation with each packet. This exposes the shared
secret to dictionary attacks. MD5 authentication server.

A properly designed handoff scheme will only succeed if it is used both to compute the RADIUS
Response Authenticator and the Message-Authenticator attribute, and
some concerns exist relating to the security of
"correct" in this hash
[MD5Attack].

As discussed way. If a successful handoff would establish
"incorrect" state, it is preferable for it to fail, in [RFC3579] Section 4.3, the security vulnerabilities order to avoid
creation of RADIUS are extensive, incorrect context.

Some backend authentication server and therefore development authenticator configurations
are incapable of an alternative
key wrap technique based on meeting this definition of "correctness". For
example, if the RADIUS shared secret would not
substantially improve security. As old and new device differ in their capabilities, it
may be difficult to meet this definition of correctness in a result, [RFC3759] Section 4.2
recommends running RADIUS over IPsec. The same approach is taken handoff
mechanism that bypasses AAA. Backend authentication servers often
perform conditional evaluation, in
Diameter EAP [I-D.ietf-aaa-eap], which defines cleartext key
attributes, to be protected by IPsec or TLS.

Where the authorizations returned
in an untrusted AAA intermediary is present (such Access-Accept message are contingent on the authenticator or on
dynamic state such as a RADIUS
proxy the time of day or number of simultaneous
sessions. For example, in a Diameter agent), and data object security is not used, heterogeneous deployment, the
AAA-Key may be recovered by an attacker backend
authentication server might return different authorizations depending
on the authenticator making the request, in control of order to make sure that
the untrusted
intermediary. Possession of requested service is consistent with the AAA-Key enables decryption of data
traffic sent authenticator
capabilities.

If differences between the peer new and old device would result in the
backend authentication server sending a specific authenticator. However,

Aboba, et al. Standards Track [Page 37]

INTERNET-DRAFT EAP Key Management Framework 17 July 2005

as long as a AAA-Key or keys derived from it is only utilized by a
single authenticator, compromise different set of the AAA-Key does not enable an
attacker messages to impersonate
the peer to another authenticator.
Vulnerability new device than were sent to an untrusted AAA intermediary can be mitigated by
implementation of redirect functionality, as described in [RFC3588]
and [I-D.ietf-aaa-eap].

5. Handoff Vulnerabilities

With EAP, a number of mechanisms are be utilized in order to reduce the latency of old device, then if the handoff between authenticators. One such
mechanism is
EAP pre-authentication, in which EAP is utilized to pre-establish a
AAA-Key on an authenticator prior to arrival of bypasses AAA, then the peer. Another
such mechanism is AAA-Key caching, in which an EAP peer can re-attach
to an handoff cannot be carried out
correctly.

For example, if some authenticator without having to re-authenticate using EAP. Yet
another mechanism is context transfer, such as is defined devices within a deployment
support dynamic VLANs while others do not, then attributes present in
[IEEE-802.11F] and [CTP]. These mechanisms introduce new security
vulnerabilities,
the Access-Request (such as discussed in the sections that follow.

5.1. Authorization

In a typical network access scenario (dial-in, wireless LAN, authenticator-IP-Address,
authenticator-Identifier, Vendor-Identifier, etc.)
access control mechanisms are typically applied. These mechanisms
include user authentication as well could be examined
to determine when VLAN attributes will be returned, as authorization for the offered
service.

As described in
[RFC3580]. VLAN support is defined in [IEEE-802.1Q]. If a part of the authentication process, the AAA network determines
the user's authorization profile. The user authorizations are
transmitted by handoff
bypassing the backend authentication server were to the occur between a

Aboba, et al. Standards Track [Page 31]

INTERNET-DRAFT EAP Key Management Framework 23 October 2005

authenticator supporting dynamic VLANs and another 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 does not, then a certificate presented
by the guest user may also provide authorization information.

The backend authentication server is responsible for making with access restricted to a user
authorization decision, answering guest
VLAN could be given unrestricted access to the following questions:

[a] Is this network.

Similarly, in a legitimate user for this particular network?

[b] Is this user allowed the type of network where access he or she is requesting?

[c] Are there any specific parameters (mandatory tunneling, bandwidth,
filters, restricted based on the day
and so on) that time, Service Set Identifier (SSID), Calling-Station-Id or other
factors, unless the access network should be aware of for
this user?

[d] Is this user restrictions are encoded within the subscription rules regarding time of day?

Aboba, et al. Standards Track [Page 38]

INTERNET-DRAFT EAP Key Management Framework 17 July 2005

[e] Is this user within his limits for concurrent sessions?

[f] Are there any fraud, credit limit,
authorizations, or other concerns that indicate
that access should be denied?

While the authorization decision a partial AAA conversation is included, then a
handoff could result in principle simple, the process
is complicated by user bypassing the distributed nature of restrictions.

In practice, these considerations limit the situations in which fast
handoff mechanisms bypassing AAA decision making. can be expected to be successful.
Where brokering entities or proxies are involved, all of the AAA deployed devices in the chain from implement the authenticator same set of services, it may
be possible to do successful handoffs within such mechanisms.
However, where the home AAA server
are involved in supported services differ between devices, the decision. For instance,
handoff may not succeed. For example, [RFC2865] section 1.1 states:

"A authenticator that does not implement a broker can disallow
access even if given service MUST NOT
implement the home AAA server would allow it, or RADIUS attributes for that service. For example, 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
authenticator that is unable to offer ARAP service MUST NOT
implement the authenticator.

The criteria for Accept/Reject decisions or the reasons RADIUS attributes for choosing
particular authorizations 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 typically known,
but not communicated 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 the
authenticator, only the final result. As perform a result, correct handoff, if a new device is provided
with RADIUS context for a known but unavailable service, then it MUST
process this context the authenticator
has no same way to know what it would handle a RADIUS Access-
Accept requesting an unavailable service. This MUST cause the decision was based on. Was
handoff to fail. However, if a set of
authorization parameters sent because this service new device is always provided
to the user, or was the decision based on the time/day and the
capabilities of the requesting authenticator device?

5.2. Correctness

When the AAA exchange is bypassed via use of techniques such as AAA-
Key caching, this creates challenges in ensuring with RADIUS
context that authorization indicates an unknown attribute, then this attribute MAY
be ignored.

Although it may seem somewhat counter-intuitive, failure is properly handled. These include:

[a] Consistent application of session time limits. Bypassing AAA
should not automatically increase indeed
the available session time,
allowing "correct" result where a user to endlessly extend their network access by
changing the point of attachment.

[b] Avoidance of privilege elevation. Bypassing AAA should known but unsupported service is
requested. Presumably a correctly configured backend authentication
server would not result
in request that a user being granted access to services which they are device carry out a service that it
does not
entitled to.

[c] Consideration of dynamic state. In situations in which dynamic
state is involved in implement. This implies that if the access decision (day/time, simultaneous
session limit) new device were to
complete a AAA conversation that it should would be possible likely to take this state into
account either before or after access is granted. Note that
consideration of network-wide state receive
different service instructions. In such as simultaneous session
limits can typically only be taken into account by a case, failure of the backend
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

Aboba, et al. Standards Track [Page 39] 32]

INTERNET-DRAFT EAP Key Management Framework 17 July 23 October 2005

authentication server.

[d] Encoding of restrictions. Since a authenticator may not

definition.

In practice, this implies that handoff mechanisms which bypass AAA
are most likely to be aware
of the criteria considered by successful within a backend authentication server when
allowing access, in order to ensure consistent authorization during homogeneous device
deployment within a fast handoff single administrative domain. For example, it may
would not be necessary advisable to explicitly encode the
restrictions within the authorizations provided in the AAA-Token.

[e] State validity. The introduction of carry out a fast handoff should bypassing AAA
between a authenticator providing confidentiality and another
authenticator that does not render
the authentication server incapable of keeping track of network-
wide state.

A handoff mechanism capable support this service. The correct result
of addressing these concerns is said to
be "correct". One condition for correctness is as follows: For such a handoff to would be "correct" it MUST establish on a failure, since if the new device handoff were
blindly carried out, then the same
context as user would have been created had the new device completed be moved from a AAA
conversation with secure to an
insecure channel without permission from the backend authentication
server.

A properly designed handoff scheme will only succeed if it is
"correct" in this way. If Thus the definition of a successful handoff would establish
"incorrect" state, it is preferable "known but unsupported service"
MUST encompass requests for it unavailable security services. This
includes vendor-specific attributes related to fail, security, such as
those described in [RFC2548].

5. Security Considerations

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 analyze whether the old and new device differ in their capabilities, EAP conversation achieves it
may be difficult security
goals, it is first necessary to meet this definition state those goals as well as the
underlying security assumptions.

The overall goal of correctness in a handoff
mechanism that bypasses AAA. Backend authentication servers often
perform conditional evaluation, in which the authorizations returned
in an Access-Accept message EAP conversation is to derive fresh session
keys between the EAP peer and authenticator that are contingent on known only to
those parties, and for both the EAP peer and authenticator to
demonstrate that they are authorized to perform their roles either by
each other or on
dynamic state such as the time by a trusted third party (the AAA server).

The principals of day or number the authentication phase are the EAP peer and
server. Completion of simultaneous
sessions. For example, an EAP method exchange supporting key
derivation results in a heterogeneous deployment, the backend
authentication derivation of EAP keying material (MSK,
EMSK, TEKs) known only to the EAP peer (identified by the Peer-ID)
and server might return different authorizations depending
on (identified by the authenticator making Server-ID). Both the request, in order EAP peer and EAP
server know the exported keying material to make sure that be fresh.

The principals of the requested service is consistent with AAA Key transport exchange are the EAP
authenticator
capabilities.

If differences between the new and old device would result the EAP server. Completion of the AAA exchange
results in the
backend authentication server sending a different set transport of messages to EAP keying material from the new device than were sent EAP server
(identified by the Server-ID) to the old device, then if EAP authenticator (identified by
the handoff
mechanism bypasses AAA, then NAS-Identifier) without disclosure to any other party. Both the handoff cannot be carried out
correctly.

For example, if some
EAP server and EAP authenticator devices within a deployment
support dynamic VLANs while others do not, then attributes present know this keying material to be
fresh.

The principals of the Secure Association Protocol are the EAP peer
(identified by the Peer-ID) and authenticator (identified by the NAS-
Identifier). Completion of the Secure Association Protocol results
in the Access-Request (such as derivation of TSKs known only to the authenticator-IP-Address,
authenticator-Identifier, Vendor-Identifier, etc.) could be examined EAP peer and
authenticator. Both the EAP peer and authenticator know the TSKs to determine when VLAN attributes will be returned, as described in

Aboba, et al. Standards Track [Page 40] 33]

INTERNET-DRAFT EAP Key Management Framework 17 July 23 October 2005

[RFC3580]. VLAN support is defined in [IEEE-802.1Q]. If a 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, fresh.

5.1. Terminology

"Cryptographic binding", "Cryptographic separation", "Key strength"
and "Mutual authentication" are defined in a network where access is restricted based on the day [RFC3748] and time, Service Set Identifier (SSID), Calling-Station-Id or other
factors, unless the restrictions are encoded within used
with the
authorizations, or a partial AAA conversation same meaning here.

5.2. Threat Model

The EAP threat model is included, then a
handoff could result described in the user bypassing the restrictions.

In practice, [RFC3748] Section 7.1. The
security properties of EAP methods (known as "security claims",
described in [RFC3784] Section 7.2.1), address these considerations limit the situations threats. EAP
method requirements for applications such as Wireless LAN
authentication are described in which fast
handoff mechanisms bypassing AAA can be expected [RFC4017]. The RADIUS threat model
is described in [RFC3579] Section 4.1, and responses to be successful.
Where the deployed devices implement the same set of services, it these threats
are described in [RFC3579] Sections 4.2 and 4.3.

However, in addition to threats against EAP and AAA, there are other
system-level threats worth discussing. These include:

[1] An attacker may
be possible compromise or steal an EAP authenticator, in an
attempt to do successful handoffs within such mechanisms.
However, where the supported services differ between devices, the
handoff gain access to other EAP authenticators or obtain long-
term secrets.

[2] An attacker may not succeed. For example, [RFC2865] section 1.1 states:

"A compromise an EAP authenticator that does not implement a given service MUST NOT
implement the RADIUS attributes for that service. in an effort to
commit fraud. For example, a compromised authenticator that is unable may provide
incorrect information to offer ARAP service MUST NOT
implement the RADIUS attributes for ARAP. A authenticator MUST
treat EAP peer and/or server via out-of-band
mechanisms (such as via a RADIUS access-accept authorizing AAA or lower layer protocol). This
includes impersonating another authenticator, or providing
inconsistent information to the peer and EAP server.

[3] An attacker may try to modify or spoof packets, including Discovery
or Secure Association Protocol frames, EAP or AAA packets.

[4] An attacker may attempt a downgrade attack in order to exploit
known weaknesses in an unavailable service as authentication method or cryptographic
transform.

[5] An attacker may attempt to induce an access-reject instead."

Note that this behavior only applies EAP peer, authenticator or
server 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 disclose keying material to perform a correct 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 unauthorized party, or
utilize keying material outside the
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 was intended
for.

[6] An attacker 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 replay packets.

[7] An attacker may cause an EAP peer, authenticator or 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 reuse
an stale key. Use of the stale keys may also occur unintentionally.

Aboba, et al. Standards Track [Page 41] 34]

INTERNET-DRAFT EAP Key Management Framework 17 July 23 October 2005

handoff is the desired result. This will cause the new device to go
back to the

For example, a poorly implemented AAA server may provide stale
keying material to an authenticator, or a poorly implemented
authenticator may reuse nonces.

[8] An authenticated attacker may attempt to obtain elevated privilege
in order to receive the appropriate service
definition.

In practice, this implies access information that 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 does not be advisable have rights to.

In order to carry out a fast handoff bypassing AAA
between address these threats, [Housley] provides a description
of mandatory system security properties. Issues relating system
security requirements are discussed in the sections that follow.

5.3. Authenticator Compromise

In the event that an authenticator providing confidentiality and another
authenticator is compromised or stolen, an
attacker may gain access to the network via that does not support authenticator, or
may obtain the credentials required for that authenticator/AAA client
to communicate with one or more AAA servers. However, this service. should
not allow the attacker to compromise other authenticators or the AAA
server, or obtain long-term user credentials.

The correct result implications of such a handoff would be a failure, this requirement are many, but some of the more
important are as follows:

No Key Sharing
An EAP authenticator MUST NOT share any keying material with
another EAP authenticator, since if the handoff one EAP authenticator were
blindly carried out, then the user
compromised, this would enable the compromise of keying material on
another authenticator. In order to be moved from a secure able to an
insecure channel without permission from the backend authentication
server. Thus determine whether
keying material has been shared, it is necessary for the definition identity
of a "known but unsupported service"
MUST encompass requests for unavailable security services. This
includes vendor-specific attributes related the EAP authenticator to security, such as
those described in [RFC2548].

6. Security Considerations

6.1. Security Terminology

"Cryptographic binding", "Cryptographic separation", "Key strength"
and "Mutual authentication" are be defined in [RFC3748] and are used understood by all
parties that communicate with the same meaning here.

6.2. Threat Model

The EAP threat model is described in [RFC3748] Section 7.1. In order
to address these threats, EAP relies on the security properties of
EAP methods (known as "security claims", described in [RFC3784]
Section 7.2.1). EAP method requirements for application such it.

No AAA Credential Sharing
AAA credentials (such as
Wireless LAN authentication are described in [RFC4017].

The RADIUS threat model is described in [RFC3579] Section 4.1, and
responses shared secrets, IPsec pre-shared
keys or certificates) MUST NOT be shared between AAA clients, since
if one AAA client were compromised, this would enable an attacker
to these threats are described in [RFC3579] Sections 4.2
and 4.3. Among impersonate other things, [RFC3579] Section 4.2 recommends the
use of IPsec ESP with non-null transform AAA clients to provide per-packet
authentication and confidentiality, integrity and replay protection
for RADIUS/EAP.

Given the existing documentation of EAP and AAA threat models and
responses, there is no need server, or even to
impersonate a AAA server to duplicate that material here.
However, there are many other system-level threats no covered in
these document which have not been described AAA clients.

No Compromise of Long-Term Credentials
An attacker obtaining TSKs, TEKs or analyzed elsewhere.
These include: EAP keying material such as the
MSK MUST NOT be able to obtain long-term user credentials such as
pre-shared keys, passwords or private-keys without breaking a
fundamental cryptographic assumption.

Aboba, et al. Standards Track [Page 42] 35]

INTERNET-DRAFT EAP Key Management Framework 17 July 23 October 2005

[1] An attacker may try to modify

5.4. Spoofing

The use of per-packet authentication and integrity protection
provides protection against spoofing attacks. Diameter [RFC3588]
provides support for per-packet authentication and integrity
protection via use of IPsec or spoof Secure Association Protocol
packets.

[2] An attacker compromising an authenticator may provide incorrect
information to the EAP peer and/or server via out-of-band
mechanisms (such as TLS. RADIUS/EAP [RFC3579] provides
for per-packet authentication and integrity protection via a AAA or lower layer protocol). This
includes impersonating another authenticator, or providing
inconsistent information to use of the peer
Message-Authenticator attribute.

[RFC3748] Section 7.2.1 describes the "integrity protection" security
claim and [RFC4017] requires use of EAP server.

[3] An attacker may attempt methods supporting this
claim.

In order to perform downgrading attacks on the
ciphersuite negotiation within the prevent forgery of Secure Association Protocol in
order to ensure that a weaker ciphersuite frames,
per-frame authentication and integrity protection is used to protect data.

Depending RECOMMENDED on
all messages. [IEEE-802.11i] supports per-frame integrity protection
and authentication on all messages within the lower layer, these attacks may be carried out
without requiring physical proximity.

In order to address these threats, [Housley] describes the mandatory
system security properties:

Algorithm independence
Wherever cryptographic algorithms are chosen, 4-way handshake except
the algorithms must
be negotiable, first message. An attack leveraging this ommission is described
in order [Analysis].

5.5. Downgrade Attacks

The ability to provide resilient negotiate the use of a particular cryptographic
algorithm provides resilience against compromise of a particular
cryptographic algorithm. Algorithm independence must be
demonstrated within all aspects of the system, This is usually accomplished by including within
EAP, AAA and
an algorithm identifier in the Secure Association Protocol. However, for
interoperability, at least one suite of algorithms MUST be
implemented.

Strong, fresh session keys
Session keys must be demonstrated to be strong protocol, and fresh in all
circumstances, while at by specifying the same time retaining
algorithm
independence.

Replay protection
All protocol exchanges must be replay protected. This includes
exchanges within EAP, AAA, and requirements in the Secure Association Protocol.

Authentication
All parties need protocol specification. In order to be authenticated. The confidentiality
prevent downgrade attacks, secure confirmation of the
authenticator must be maintained. No plaintext passwords are
allowed.

Authorization "best"
ciphersuite is required.

[RFC3748] Section 7.2.1 describes the "protected ciphersuite
negotiation" security claim that refers to the ability of an EAP peer
method to negotiate the ciphersuite used to protect the EAP
conversation, as well as to integrity protect the negotiation.
[RFC4017] requires EAP methods satisfying this security claim.

Diameter [RFC3588] provides support for cryptographic algorithm
negotiation via use of IPsec or TLS. RADIUS [RFC3579] does not
support the negotiation of cryptographic algorithms, and authenticator authorization must relies on
MD5 for integrity protection, authentication and confidentiality,
despite known weaknesses in the algorithm [MD5Attack]. This issue
can be performed.

Session keys
Confidentiality addressed via use of session keys must be maintained. RADIUS over IPsec, as described in
[RFC3579] Section 4.2.

As a result, EAP methods and AAA protocols are capable of addressing
downgrade attacks. To ensure against downgrade attacks within lower
layer protocols, algorithm independence is REQUIRED with lower layers
using EAP for key derivation. For interoperability, at least one

Aboba, et al. Standards Track [Page 43] 36]

INTERNET-DRAFT EAP Key Management Framework 17 July 23 October 2005

Ciphersuite negotiation
The selection

suite of the "best" ciphersuite must be securely confirmed.

Unique naming
Session keys must mandatory-to-implement algorithm MUST be uniquely named.

Domino effect
Compromise selected. Lower
layer protocols supporting EAP for key derivation SHOULD also support
secure ciphersuite negotiation. As described in [RFC1968], PPP ECP
does not provide support for secure ciphersuite negotiation.
However, [IEEE-802.11i] does support secure ciphersuite negotiation.

5.6. Unauthorized Disclosure

While preserving algorithm independence, confidentiality of a single authenticator cannot compromise any other
part all
keying material MUST be maintained. To prevent unauthorized disclose
of keys, each party in the system, including session keys and long-term secrets.

Key binding
The key must EAP conversation MUST be bound authenticated to
the other parties with whom it communicates. Keying material MUST be
bound to the appropriate context.

6.3. Security Analysis

Figure 8 illustrates the relationship between

[RFC3748] Section 7.2.1 describes the peer, authenticator "mutual authentication" and backend
"dictionary attack resistance" claims, and [RFC4017] requires EAP
methods satisfying these claims. EAP methods complying with
[RFC4017] therefore provide for mutual authentication server. between the EAP
peer
/\
/ \
Protocol: EAP / \ Protocol: Secure Association
Auth: Mutual / \ Auth: Mutual
Unique keys: / \ Unique keys: TSKs
TEKs,EMSK / \
/ \ and server. Binding of EAP keying material (MSK, EMSK) to the
appropriate context is provided by the Peer-ID and Server-ID which
are exported along with the keying material.

Diameter [RFC3588] provides for per-packet authentication and
integrity protection via IPsec or TLS, and RADIUS/EAP [RFC3579] also
provides for per-packet authentication and integrity protection.
Where the NAS/authenticator and AAA server +--------------+ Authenticator
Protocol: communicate directly and
credible keywrap is used (see Section 3.7), this ensures that the AAA
Auth: Mutual
Unique key:
Key Transport phase achieves its security objectives: mutually
authenticating the AAA session key

Figure 8: Relationship between peer, authenticator client/authenticator and auth. AAA server

The peer and
providing EAP server communicate using EAP [RFC3748]. The
security properties of this communication are largely determined by keying material to the chosen EAP method. Method security claims are described in
[RFC3748] Section 7.2. These include the key strength, protected
ciphersuite negotiation, mutual authentication, integrity protection,
replay protection, confidentiality, key derivation, key strength,
dictionary attack resistance, fast reconnect, cryptographic binding,
session independence, fragmentation authenticator and channel binding claims. At a
minimum, methods claiming to support key derivation must also support
mutual authentication. no
other party.

As noted in [RFC3748] Section 7.10:

EAP Methods deriving keys MUST 3.1, the Secure Association Protocol does not by
itself provide for mutual authentication between the EAP peer and the
authenticator, even if mutual possession of EAP Server.

Ciphersuite independence keying material is also required:

Aboba, et al. Standards Track [Page 44]

INTERNET-DRAFT EAP Key Management Framework 17 July 2005

Keying material exported by EAP methods MUST be independent of
proven. However, where the
ciphersuite negotiated to protect data.

In terms of key strength NAS/authenticator and freshness, [RFC3748] Section 10 says:

EAP methods SHOULD ensure AAA server
communicate directly, the freshness AAA server can verify the correspondence
between NAS identification attributes, the source address of packets
sent by the MSK NAS, and EMSK even
in cases where one party may the AAA credentials. As long as the NAS has not have a high quality random number
generator.... In order
shared its AAA credentials with another NAS, this allows the AAA
server to preserve algorithm independence, authenticate the NAS. Using Channel Bindings, the EAP
methods deriving keys SHOULD support (and document) peer
can then determine whether the protected
negotiation of NAS/authenticator has provided the ciphersuite used
same identifying information to protect the EAP
conversation between the peer and server... In order to enable
deployments requiring strong keys, EAP methods supporting key
derivation SHOULD be capable of generating an MSK AAA server.

Peer and EMSK, each
with an effective key strength of at least 128 bits.

The authenticator and backend authentication server communicate using
a AAA protocol such as RADIUS [RFC3579] or Diameter [I-D.ietf-aaa-
eap]. As noted in [RFC3588] Section 13, Diameter must authorization MUST be protected
by either IPsec ESP with non-null transform or TLS. As performed.
Authorization is REQUIRED whenever a result,
Diameter requires per-packet integrity and confidentiality. Replay
protection must be supported. For RADIUS, [RFC3579] Section 4.2
recommends that RADIUS be protected by IPsec ESP peer associates with a non-null
transform, new
authenticator. Authorization checking prevents an elevation of
privilege attack, and where IPsec ensures that an unauthorized authenticator is implemented replay protection must

Aboba, et al. Standards Track [Page 37]

INTERNET-DRAFT EAP Key Management Framework 23 October 2005

detected. Authorizations SHOULD be
supported.

The peer and authenticator communicate using synchronized between the Secure Association
Protocol.

As noted in EAP
peer, server, authenticator. Once the figure, each party in EAP conversation exchanges are
complete, all of these parties should hold the exchange mutually
authenticates with each same view of the
authorizations associated the other parties, and derives a unique
key. All parties in parties. If peer authorization
is restricted, then the diagram have access to peer SHOULD be made aware of the AAA-Key. restriction.

The AAA exchange provides the EAP peer and backend authentication server mutually authenticate
via authenticator with authorizations
relating to the EAP method, and derive peer. However, neither the TEKs and EMSK which are known only EAP nor AAA exchanges
provides authorizations to them. The TEKs are used the EAP peer. In order to protect some or ensure that all
parties hold the same view of the EAP
conversation authorizations it is RECOMMENDED
that the Secure Association Protocol enable communication of
authorizations between the peer EAP authenticator and authenticator, so as peer.

In order to guard
against modification or insertion enable key binding and authorization of EAP packets by an attacker. The
degree all parties, it
is RECOMMENDED that the parties use a set of protection afforded by identities that are
consistent between the TEKs is determined conversation phases. RADIUS [RFC2865] and
Diameter NASREQ [RFC4005] require that the NAS/EAP authenticator
identify itself by including one or more identification attributes
within an Access-Request packet (NAS-Identifier, NAS-IP-Address, NAS-
IPv6-Address).

Since the AAA server provides EAP
method; some methods may protect keying material for use by the entire EAP packet, including the
authenticator as identified by these attributes, where an EAP header, while other methods
authenticator may only protect the contents of the
Type-Data field, defined in [RFC3748].

Since EAP have multiple ports, it is spoken only between RECOMMENDED for the EAP peer and server, if a
backend authentication server is present then
authenticator to identify itself using NAS identification attributes
during the Secure Association Protocol exchange with the EAP conversation
does not provide mutual authentication between peer.
This enables the EAP peer and
authenticator, only to determine whether EAP keying material
has been shared between EAP authenticators as well as to confirm with
the AAA server that an EAP peer and authenticator proving possession of EAP server (backend
authentication server). As
keying material during the Secure Association Protocol was authorized
to obtain it. Typically, the NAS-Identifier attribute is most
convenient for this purpose, since a result, mutual NAS/authenticator may have
multiple IP addresses.

Similarly, the AAA server authorizes the EAP authenticator to provide
access to the EAP peer identified by the Peer-ID, securely verified
during the EAP authentication exchange. In order to determine
whether EAP keying material has been shared between EAP peers, where
the EAP peer has multiple ports it is RECOMMENDED for the EAP peer and authenticator only occurs where a to
identify itself using the Peer-ID during the Secure Association
Protocol exchange with the EAP authenticator.

5.7. Replay Protection

Replay protection allows a protocol message recipient to discard any
message that was recorded during a previous legitimate dialogue and
presented as though it belonged to the current dialogue.

Aboba, et al. Standards Track [Page 45] 38]

INTERNET-DRAFT EAP Key Management Framework 17 July 23 October 2005

protocol is used, such

[RFC3748] Section 7.2.1 describes the unicast "replay protection" security
claim and group key derivation handshake
supported in [IEEE-802.11i]. This means that absent [RFC4017] requires use of a secure
Association Protocol, from the point EAP methods supporting this
claim.

Diameter [RFC3588] provides support for replay protection via use of view
IPsec or TLS. RADIUS/EAP [RFC3579] protects against replay of keying
material via the peer, EAP mutual
authentication only proves that Request Authenticator. However, some RADIUS packets
are not replay protected. In Accounting, Disconnect and CoA-Request
packets the authenticator is trusted by the
backend authentication server; the identity of the authenticator is Request Authenticator contains a keyed MAC rather than a
Nonce. The Response Authenticator in Accounting, Disconnect and CoA
Response packets also contains a keyed MAC whose calculation does not confirmed.

Utilizing the AAA protocol,
depend on a Nonce in either the authenticator and backend
authentication server mutually authenticate and derive session keys
known only to them, used to provide per-packet integrity and replay
protection, authentication and confidentiality. The AAA-Key Request or Response packets.
Therefore unless an Event-Timestamp attribute is
distributed by included or IPsec is
used, the backend authentication server recipient may not be able to the authenticator
over this channel, bound determine whether these
packets have been replayed.

In order to attributes constraining its usage, as
part of the AAA-Token. The binding prevent replay of attributes to the AAA-Key
within a protected package Secure Association Protocol frames,
replay protection is important so the authenticator
receiving REQUIRED on all messages. [IEEE-802.11i]
supports replay protection on all messages within the AAA-Token can determine that 4-way
handshake.

5.8. Key Freshness

A session key should be considered compromised if it has not been
compromised, remains in use
too long. As noted in [Housley], session keys MUST be strong and
fresh, while preserving algorithm independence. A fresh
cryptographic key is one that is generated specifically for the keying material has not been replayed, or
mis-directed in some way.

The security properties
intended use. Each session deserves an independent session key;
disclosure of one session key MUST NOT aid the EAP exchange attacker in
discovering any other session keys.

Fresh keys are dependent on each leg required even when a long replay counter (that is, one
that "will never wrap") is used to ensure that loss of state does not
cause the triangle: the selected EAP method, AAA protocol and the Secure
Association Protocol.

Assuming that same counter value to be used more than once with the same
session key.

EAP, AAA protocol provides protection against rogue
authenticators forging their identity, then the AAA-Token can be
assumed to be sent to the correct authenticator, and where it is
wrapped appropriately, it can be assumed to be immune to compromise
by a snooping attacker.

Where an untrusted AAA intermediary is present, the AAA-Token must
not be provided to the intermediary so as to avoid compromise of lower layer each bear responsibility for ensuring
the
AAA-Token. This can be avoided by use of re-direct as defined in
[RFC3588].

When fresh, strong session keys:

EAP is used for authentication on PPP or wired IEEE 802
networks, it is typically assumed that the link is physically secure,
so that an attacker cannot gain access to the link, or insert a rogue
device. EAP methods defined in [RFC3748] reflect this usage model.
These include need to ensure the freshness and strength of EAP MD5, as well keying
material provided as One-Time Password (OTP) and Generic
Token Card. These methods support one-way authentication (from EAP
peer an input to authenticator) but not mutual authentication or session key derivation. As a result, these [RFC3748]
Section 7.10 states that "EAP methods do not bind SHOULD ensure the initial
authentication freshness
of the MSK and subsequent data traffic, EMSK, even when in cases where one party may not have a
high quality random number generator. A RECOMMENDED method is for
each party to provide a nonce of at least 128 bits, used in the
derivation of the
ciphersuite used to protect data supports per-packet authentication MSK and integrity protection. As a result, EMSK." The contribution of nonces
enables the EAP methods not supporting
mutual authentication are vulnerable peer and server to session hijacking as well as
attacks by rogue devices. ensure that exported EAP keying
material is fresh.

Aboba, et al. Standards Track [Page 46] 39]

INTERNET-DRAFT EAP Key Management Framework 17 July 23 October 2005

On wireless networks such as IEEE 802.11 [IEEE-802.11], these attacks
become easy to mount, since any attacker within range can access

[RFC3748] Section 7.2.1 describes the
wireless medium, or act as an access point. As a result, new
ciphersuites have been proposed for use with wireless LANs
[IEEE-802.11i] which provide per-packet authentication, integrity "key strength" and
replay protection. In addition, mutual authentication "session
independence" security claims, and key
derivation, provided by and [RFC4017] requires use of
EAP methods such supporting these claims as EAP-TLS [RFC2716] are
required [IEEE-802.11i], so well as to address the threat being capable of rogue
devices, and provide
providing an equivalent key strength of 128 bits or greater.

AAA The AAA protocol needs to ensure that transported keying material to bind the initial
authentication to subsequent data traffic.

If
is fresh and is not utilized outside its recommended lifetime.
Replay protection is necessary for key freshness, but an attacker
can deliver a stale (and therefore potentially compromised) key in
a replay-protected message, so replay protection is not sufficient.

The EAP Session-ID, derived from the selected EAP method does not support mutual authentication,
then Type and Method-ID (based
on the peer will be vulnerable to attack nonces contributed by rogue authenticators
and backend authentication servers. If the EAP method does not derive
keys, then TSKs will not be available for use with a negotiated
ciphersuite, peer and there will be no binding between server) enables the initial EAP
authentication
peer, authenticator and subsequent data traffic, leaving the session
vulnerable server to hijack.

If distinguish EAP conversations.
However, unless the backend authentication server does not protect against authenticator masquerade, or provide the proper binding keeps track of EAP Session-IDs,
the AAA-
Key to authenticator cannot use the session within Session-ID to guarantee the AAA-Token, then one or more AAA-Keys
may be
freshness of EAP keying material.

As described in [RFC3580] Section 3.17, When sent to in an unauthorized party, and an attacker may be able to
gain access to Access-
Accept along with a Termination-Action value of RADIUS-Request, the network. If
Session-Timeout attribute specifies the AAA-Token is maximum number of seconds
of service provided prior to an
untrusted AAA intermediary, then re-authentication. [IEEE-802.11i]
also utilizes the Session-Timeout attribute to limit the maximum
time that intermediary EAP keying material may be able to
modify cache. Therefore the AAA-Key, or use of
the attributes associated with it, as
described in [RFC2607].

If Session-Timeout attribute enables the AAA server to limit the
exposure of EAP keying material.

Lower Layer
The lower layer Secure Association Protocol does not provide mutual proof of
possession of MUST generate a fresh
session key for each session, even if the AAA-Key material, then keying material and
parameters provided by EAP methods are cached, or the peer will not or
authenticator lacks a high entropy random number generator. A
RECOMMENDED method is for the peer and authenticator to each
provide a nonce or counter of at least 128 bits, used in session
key derivation.

5.9. Elevation of Privilege

Parties MUST NOT have
assurance access to keying material that is not needed to
perform their own role. A party has access to a particular key if it
has access to all of the secret information needed to derive it. If
a post-EAP handshake is connected used to establish session keys, the correct authenticator, only
that post-EAP
handshake MUST specify the scope for session keys.

Transported EAP keying material is permitted to be accessed by the
EAP peer, authenticator and backend authentication server. The EAP peer and server share a
trust relationship (since AAA protocols support mutual
authentication). This distinction can become important when multiple
authenticators receive AAA-Keys from derive
the backend authentication
server, such as where fast handoff is supported. If transported keying material during the TSK
derivation does not provide for protected ciphersuite process of mutually
authenticating each other using the selected EAP method. During the

Aboba, et al. Standards Track [Page 40]

INTERNET-DRAFT EAP Key Management Framework 23 October 2005

Secure Association Protocol, the EAP peer utilizes the transported
EAP keying material to demonstrate to the authenticator that it is
the same party that authenticated to the EAP server and
capabilities negotiation, then downgrade attacks was
authorized by it. The EAP authenticator utilizes the transported EAP
keying material to prove to the peer not only that the EAP
conversation was transported through it (this could be demonstrated
by a man-in-the-middle), but that it was uniquely authorized by the
EAP server to provide the peer with access to the network. Unique
authorization can only be demonstrated if the EAP authenticator does
not share the transported keying material with a party other than the
EAP peer and server.

TSKs are possible.

6.4. permitted to be accessed only by the EAP peer and
authenticator. Since the TSKs can be determined from the transported
EAP keying material and the cleartext of the Secure Association
Protocol exchange, the AAA server will have access to the TSKs unless
it deletes the transported EAP keying material after sending it.

5.10. Man-in-the-middle Attacks

As described in [I-D.puthenkulam-eap-binding], EAP method sequences
and compound authentication mechanisms may be subject to man-in-the-
middle attacks. When such attacks are successfully carried out, the
attacker acts as an intermediary between a victim and a legitimate
authenticator. This allows the attacker to authenticate successfully
to the authenticator, as well as to obtain access to the network.

Aboba, et al. Standards Track [Page 47]

INTERNET-DRAFT EAP Key Management Framework 17 July 2005

In order to prevent these attacks, [I-D.puthenkulam-eap-binding]
recommends derivation of a compound key by which the EAP peer and
server can prove that they have participated in the entire EAP
exchange. Since the compound key must not be known to an attacker
posing as an authenticator, and yet must be derived from quantities
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
key hygiene, it is recommended that the compound key used for man-in-
the-middle protection be cryptographically separate from other keys
derived from the EMSK, such as fast handoff keys, discussed in
Section 2.3.

6.5. EMSK.

5.11. Denial of Service Attacks

The

Key caching of security associations may result in vulnerability to 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
implicitly delete a previous EAP SA,
For example, EAP methods that result in
creation of create persistent state may be
vulnerable to denial of service attacks by on the EAP server by a rogue
EAP peer.

As a result,

To address this vulnerability, EAP methods creating persistent state
may wish to limit the number of cached EAP SAs (Phase 1a) corresponding to persistent state created by an EAP peer. For
example, for each peer an EAP server may choose to only retain limit persistent

Aboba, et al. Standards Track [Page 41]

INTERNET-DRAFT EAP Key Management Framework 23 October 2005

state to a few EAP SAs
for each peer. conversations, distinguished by the EAP Session-
ID. This prevents a rogue peer from denying access to other peers.

Similarly, an authenticator may have multiple AAA-Key SAs
corresponding to a given EAP peer; to conserve resources an authenticator may choose to limit
the number of cached AAA-Key (Phase
1 b) SAs for persistent state corresponding to each peer. This can be
accomplished by limiting each peer to persistent sttate corresponding
to a few EAP converations, distinguished by the EAP Session-ID.

Depending on the media, creation of a new unicast Secure Association
SA TSKs may or may not imply
deletion of a previous unicast secure
association SA. previously derived TSKs. Where there is no implied
deletion, the authenticator may choose to limit Phase 2 (unicast the number of TSKs
and multicast)
Secure Association SAs associated state that can be stored for each peer.

6.6.

5.12. Impersonation

Both the RADIUS and Diameter protocols are potentially vulnerable to
impersonation by a rogue authenticator.

While AAA protocols such as RADIUS [RFC2865] or Diameter [RFC3588]
support mutual authentication between the authenticator (known as the
AAA client) and the backend authentication server (known as the AAA
server), the security mechanisms vary according to the AAA protocol.

Aboba, et al. Standards Track [Page 48]

INTERNET-DRAFT EAP Key Management Framework 17 July 2005

In RADIUS, the shared secret used for authentication is determined by
the source address of the RADIUS packet. As noted in [RFC3579]
Section 4.3.7, it is highly desirable that the source address be
checked against one or more NAS identification attributes so as to
detect and prevent impersonation attacks.

When RADIUS requests are forwarded by a proxy, the NAS-IP-Address or
NAS-IPv6-Address attributes may not correspond to the source address.
Since the NAS-Identifier attribute need not contain an FQDN, it also
may not correspond to the source address, even indirectly. [RFC2865]
Section 3 states:

A RADIUS server MUST use the source IP address of the RADIUS
UDP packet to decide which shared secret to use, so that
RADIUS requests can be proxied.

This implies that it is possible for a rogue authenticator to forge
NAS-IP-Address, NAS-IPv6-Address or NAS-Identifier attributes within
a RADIUS Access-Request in order to impersonate another
authenticator. Among other things, this can result in messages (and
MSKs)
transorted keying material) being sent to the wrong authenticator.
Since the rogue authenticator is authenticated by the RADIUS proxy or
server purely based on the source address, other mechanisms are
required to detect the forgery. In addition, it is possible for
attributes such as the Called-Station-Id and Calling-Station-Id to be

Aboba, et al. Standards Track [Page 42]

INTERNET-DRAFT EAP Key Management Framework 23 October 2005

forged as well.

As recommended in [RFC3579], [RFC3579] Section 4.3.7, this vulnerability can be
mitigated by having RADIUS proxies check authenticator NAS identification
attributes against the source address.

To allow verification of session parameters such as the Called-
Station- Id and Calling-Station-Id, these can be sent by the EAP peer
to the server, protected by the TEKs. The RADIUS server can then
check the parameters sent by the EAP peer against those claimed by
the authenticator. If a discrepancy is found, an error can be
logged.

While [RFC3588] requires use of the Route-Record AVP, this utilizes
FQDNs, so that impersonation detection requires DNS A/AAAA and PTR
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 this vulnerability, it is necessary to allow the backend
authentication server to communicate with the authenticator directly,
such as via the redirect functionality supported in [RFC3588].

Aboba, et al. Standards Track [Page 49]

INTERNET-DRAFT EAP Key Management Framework 17 July 2005

6.7.

5.13. Channel binding Binding

It is possible for a compromised or poorly implemented EAP
authenticator to communicate incorrect information to the EAP peer
and/or server. This may enable an authenticator to impersonate
another authenticator or communicate incorrect information via out-
of-band mechanisms (such as via AAA or the lower layer protocol). layer).

Where EAP is used in pass-through mode, the EAP peer typically does not verify
the identity of the pass-through authenticator, it only
verifies that authenticator. Within the pass-through Secure
Association Protocol, the EAP peer and authenticator is trusted by only demonstrate
mutual possession of the transported EAP
server. keying material. This
creates a potential security vulnerability, described in [RFC3748]
Section 7.15.

[RFC3579] Section 4.3.7 describes how an EAP pass-through
authenticator acting as a AAA client can be detected if it attempts
to impersonate another authenticator (such by sending incorrect NAS-
Identifier
Called-Station-ID [RFC2865], NAS-Identifier [RFC2865], NAS-IP-Address
[RFC2865] or NAS-IPv6-Address [RFC3162] attributes via the AAA
protocol). However, it is possible for a pass-through authenticator
acting as a AAA client to provide correct information to the AAA
server while communicating misleading information to the EAP peer via a
the lower layer protocol. layer.

For example, it is possible for a compromised authenticator to can utilize another
authenticator's Called-Station-Id or NAS-Identifier in communicating
with the EAP peer via a the lower layer protocol, layer, or for a pass-through
authenticator acting as a AAA client to provide an incorrect peer
Calling-Station-Id [RFC2865][RFC3580] to the AAA server via the AAA
protocol.

As noted in [RFC3748] Section 7.15, this vulnerability can be
addressed by use of EAP methods that support a protected exchange of channel

Aboba, et al. Standards Track [Page 43]

INTERNET-DRAFT EAP Key Management Framework 23 October 2005

properties such as endpoint identifiers, including (but not limited
to): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id
[RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address
[RFC2865], and NAS-IPv6-Address [RFC3162].

Using such a protected exchange, it is possible to match the channel
properties provided by the authenticator via out-of-band mechanisms
against those exchanged within the EAP method. For example, see
[ServiceIdent].

7. Security Requirements

This section summarizes the security requirements that must be met by
EAP methods, AAA protocols, Secure Association Protocols and
Ciphersuites in order [I-
D.arkko-eap-service-identity-auth].

It is also possible to address the security threats described in achieve Channel Bindings without transporting
data over EAP. For example, see [draft-ohba-eap-aaakey-binding]. In
this document. These requirements MUST be met by specifications

Aboba, et al. Standards Track [Page 50]

INTERNET-DRAFT EAP Key Management Framework 17 July 2005

requesting publication as an RFC. Each requirement provides a
pointer to approach the sections of this document describing authenticator informs the threat that
it mitigates.

7.1. EAP Method Requirements

It is possible for backend server about the peer
Channel Binding parameters using AAA, and EAP the backend server to mutually authenticate
and derive keys. In order to provide
calculates transported keying material based on this parameter set,
making it impossible for use in the peer and authenticator to complete the
Secure Association Protocol if there was a
subsequently negotiated ciphersuite, mismatch in the
parameters.

The main difference between these approaches is that Channel Binding
support within an EAP method supporting key
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. EAP Methods deriving keys MUST provide for mutual
authentication between may require upgrading or changing the
EAP method, impacting both the peer and the EAP Server.

The MSK server. Where Channel
Bindings are implemented in AAA, the peer, authenticator and EMSK MUST NOT be used directly the
backend server need to protect data; however,
they are of sufficient size to enable derivation of a AAA-Key
subsequently used to derive Transient Session Keys (TSKs) for use
with the selected ciphersuite. Each ciphersuite is responsible for
specifying how to derive the TSKs from the AAA-Key.

The AAA-Key is derived from the keying material exported by be upgraded, but the EAP method (MSK and EMSK). need not be
modified.

6. IANA Considerations

This derivation occurs on the AAA server. In
many existing protocols that use EAP, the AAA-Key and MSK are
equivalent, but more complicated mechanisms are possible.

EAP methods SHOULD ensure the freshness of the MSK and EMSK even in
cases where one party may document does not have a high quality random number
generator. A RECOMMENDED method is create any new name spaces nor does it
allocate any protocol parameters.

7. References

7.1. Normative References

[RFC2119] Bradner, S., "Key words for each party to provide a nonce
of at least 128 bits, used use in the derivation of the MSK and EMSK.

EAP methods export the MSK RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2434] Narten, T. and EMSK H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October
1998.

[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and not Transient Session Keys so
as to allow H.
Lefkowetz, "Extensible Authentication Protocol (EAP)", RFC
3748, June 2004.

Aboba, et al. Standards Track [Page 44]

INTERNET-DRAFT EAP methods to be ciphersuite Key Management Framework 23 October 2005

7.2. Informative References

[Analysis]
He, C. and media independent.
Keying material exported by EAP methods MUST be independent J. Mitchell, "Analysis of the
ciphersuite negotiated to protect data.

Depending on 802.11i 4-Way
Handshake", Proceedings of the lower layer, EAP methods may run before or after
ciphersuite negotiation, so that the selected ciphersuite may not be
known to the EAP method. By providing keying material usable with
any ciphersuite, EAP methods can used with a wide range 2004 ACM Workshop on Wireless
Security, pp. 43-50, ISBN: 1-58113-925-X.

[CTP] Loughney, J., Nakhjiri, M., Perkins, C. and R. Koodli,
"Context Transfer Protocol", draft-ietf-seamoby-ctp-11.txt,
Internet draft (work in progress), August 2004.

[DESMODES]
National Institute of
ciphersuites Standards and media.

It is RECOMMENDED that methods providing integrity protection Technology, "DES Modes of EAP
packets include coverage
Operation", FIPS PUB 81, December 1980, <http://
www.itl.nist.gov/fipspubs/fip81.htm>.

[FIPSDES] National Institute of all the EAP header fields, including the
Code, Identifier, Length, Type Standards and Type-Data fields.

In order to preserve algorithm independence, EAP methods deriving
keys SHOULD support (and document) the protected negotiation of the
ciphersuite used to protect the EAP conversation between the peer Technology, "Data
Encryption Standard", FIPS PUB 46, January 1977.

[Housley] Housley, R. and B. Aboba, et al. Standards Track [Page 51]

INTERNET-DRAFT EAP "AAA Key Management Framework 17 July 2005

server. This is distinct from the ciphersuite negotiated between the
peer Management", draft-housley-
aaa-key-mgmt-00.txt, Internet draft (work in progress), June
2005.

[IEEE-802]
Institute of Electrical and authenticator, used to protect data.

The strength Electronics Engineers, "IEEE
Standards for Local and Metropolitan Area Networks: Overview
and Architecture", ANSI/IEEE Standard 802, 1990.

[IEEE-802.11]
Institute of Transient Session Keys (TSKs) used to protect data is
ultimately dependent on the strength Electrical and Electronics Engineers,
"Information technology - Telecommunications and information
exchange between systems - Local and metropolitan area
networks - Specific Requirements Part 11: Wireless LAN Medium
Access Control (MAC) and Physical Layer (PHY) Specifications",
IEEE IEEE Standard 802.11-2003, 2003.

[IEEE-802.1X]
Institute of keys generated by the EAP
method. If an EAP method cannot produce keying material of
sufficient strength, then the TSKs may be subject to brute force
attack. In order to enable deployments requiring strong keys, EAP
methods supporting key derivation SHOULD be capable of generating an
MSK Electrical and EMSK, each with an effective key strength of at least 128
bits.

Methods supporting key derivation MUST demonstrate cryptographic
separation between the MSK Electronics Engineers, "Local and EMSK branches of the EAP key
hierarchy. Without violating a fundamental cryptographic assumption
(such as the non-invertibility of a one-way function) an attacker
recovering the MSK or EMSK MUST NOT be able to recover the other
quantity with a level of effort less than brute force.

Non-overlapping substrings of the MSK MUST be cryptographically
separate from each other. That is, knowledge of one substring MUST
NOT help in recovering some other non-overlapping substring without
breaking some hard cryptographic assumption. This is required
because some existing ciphersuites form TSKs by simply splitting the
AAA-Key to pieces of appropriate length. Likewise, non-overlapping
substrings
Metropolitan Area Networks: Port-Based Network Access
Control", IEEE Standard 802.1X-2004, December 2004.

[IEEE-802.1Q]
Institute of the EMSK MUST be cryptographically separate from each
other, Electrical and from substrings of the MSK. The EMSK MUST NOT be
transported to, or shared with, additional parties.

Since EAP does not provide Electronics Engineers, "IEEE
Standards for explicit key lifetime negotiation, EAP
peers, authenticators Local and authentication servers MUST be prepared Metropolitan Area Networks: Draft
Standard for
situations in which one Virtual Bridged Local Area Networks", IEEE
Standard 802.1Q/D8, January 1998.

Aboba, et al. Standards Track [Page 45]

INTERNET-DRAFT EAP Key Management Framework 23 October 2005

[IEEE-802.11i]
Institute of the parties discards key state which
remains valid on another party.

The development Electrical and validation of key derivation algorithms is
difficult, Electronics Engineers, "Supplement
to STANDARD FOR Telecommunications and as a result EAP methods SHOULD reuse well established Information Exchange
between Systems - LAN/MAN Specific Requirements - Part 11:
Wireless Medium Access Control (MAC) and analyzed mechanisms physical layer (PHY)
specifications: Specification for MSK Enhanced Security", IEEE
802.11i, December 2004.

[IEEE-802.11F]
Institute of Electrical and EMSK key derivation (such as
those specified in IKE [RFC2409] or TLS [RFC2246]), rather than
inventing new ones.

7.1.1. Requirements for EAP methods

In order Electronics Engineers,
"Recommended Practice for Multi-Vendor Access Point
Interoperability via an EAP method to meet the guidelines Inter-Access Point Protocol Across
Distribution Systems Supporting IEEE 802.11 Operation", IEEE
802.11F, July 2003.

[IEEE-02-758]
Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang,
"Proactive Caching Strategies for EMSK usage it
must meet the following requirements:

o It MUST specify how IAPP Latency Improvement
during 802.11 Handoff", IEEE 802.11 Working Group,
IEEE-02-758r1-F Draft 802.11I/D5.0, November 2002.

[IEEE-03-084]
Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang,
"Proactive Key Distribution to derive the EMSK

o The key material used for the EMSK MUST be support fast and secure
roaming", IEEE 802.11 Working Group, IEEE-03-084r1-I,
http://www.ieee802.org/11/Documents/DocumentHolder/ 3-084.zip,
January 2003.

[IEEE-03-155]
Aboba, B., "Fast Handoff Issues", IEEE 802.11 Working Group,
IEEE-03-155r0-I, http://www.ieee802.org/11/
Documents/DocumentHolder/3-155.zip, March 2003.

[I-D.ietf-roamops-cert]
Aboba, B., "Certificate-Based Roaming", draft-ietf-roamops-
cert-02 (work in progress), April 1999.

[I-D.puthenkulam-eap-binding]
Puthenkulam, J., "The Compound Authentication Binding
Problem", draft-puthenkulam-eap-binding-04 (work in progress),
October 2003.

[I-D.arkko-pppext-eap-aka]
Arkko, J. and H. Haverinen, "EAP AKA Authentication", draft-
arkko-pppext-eap-aka-15.txt (work in progress), December 2004.

[I-D.arkko-eap-service-identity-auth]
Arkko, J. and P. Eronen, "Authenticated Service Information

Aboba, et al. Standards Track [Page 52] 46]

INTERNET-DRAFT EAP Key Management Framework 17 July 23 October 2005

computationally independent of

for the MSK and TEKs.

o The EMSK MUST NOT be used for any other purpose than the key
derivation described in this document.

o The EMSK MUST be secret and not known to someone observing
the authentication mechanism protocol exchange.

o The EMSK MUST NOT be exported from the EAP server.

o The EMSK MUST be unique for each session.

o The EAP mechanism SHOULD a unique identifier suitable for naming the EMSK.

7.1.2. Requirements for EAP applications

In order for an application to meet the guidelines for EMSK usage it
must meet the following requirements:

o New applications following this specification SHOULD NOT use the
MSK. If more than one application uses the MSK, then the
cryptographic separation is not achieved. Implementations SHOULD
prevent such combinations.

o A peer MUST NOT use the EMSK directly for cryptographic
protection of data.

7.2. AAA Extensible Authentication Protocol Requirements

AAA protocols suitable for use in transporting EAP MUST provide the
following facilities:

Security services
AAA protocols used for transport of EAP keying material MUST
implement and SHOULD use per-packet integrity and authentication,
replay protection and confidentiality. These requirements are met
by Diameter EAP [I-D.ietf-aaa-eap], as well as RADIUS over IPsec
[RFC3579].

Session Keys
AAA protocols used for transport of EAP keying material MUST
implement and SHOULD use dynamic key management in order to derive
fresh session keys, as (EAP)", draft-
arkko-eap-service-identity-auth-02.txt (work in Diameter EAP [I-D.ietf-aaa-eap] and
RADIUS over IPsec [RFC3579], rather than using a static key, as
originally defined progress), May
2005.

[I-D.ohba-eap-aaakey-binding]
Ohba, Y., "AAA-Key Derivation with Channel Binding", draft-
ohba-eap-aaakey-binding-00.txt (work in RADIUS [RFC2865].

Mutual authentication
AAA protocols used for transport of EAP keying material MUST

Aboba, et al. Standards Track [Page 53]

INTERNET-DRAFT EAP progress), May 2005.

[IKEv2] Kaufman, C., "Internet Key Management Framework 17 July 2005

provide for mutual authentication between the authenticator and
backend authentication server. These requirements are met by
Diameter EAP [I-D.ietf-aaa-eap] as well as by RADIUS EAP [RFC3579].

Authorization
AAA protocols used for transport of EAP keying material SHOULD
provide protection against rogue authenticators masquerading as
other authenticators. This can be accomplished, for example, by
requiring that AAA agents check the source address of packets
against the origin attributes (Origin-Host AVP in Diameter, NAS-IP-
Address, NAS-IPv6-Address, NAS-Identifier in RADIUS). For details,
see [RFC3579] Section 4.3.7.

Key transport
Since EAP methods do not export Transient Session Keys (TSKs) in
order to maintain media and ciphersuite independence, the AAA
server MUST NOT transport TSKs from the backend authentication
server to authenticator.

Key transport specification
In order to enable backend authentication servers to provide keying
material to the authenticator in a well defined format, AAA
protocols suitable for use with EAP MUST define the format and
wrapping of the AAA-Token.

EMSK transport
Since the EMSK is a secret known only to the backend authentication
server and peer, the AAA-Token MUST NOT transport the EMSK from the
backend authentication server to the authenticator.

AAA-Token protection
To ensure against compromise, the AAA-Token MUST be integrity
protected, authenticated, replay protected and encrypted in
transit, using well-established cryptographic algorithms.

Session Keys
The AAA-Token SHOULD be protected with session keys as in Diameter
[RFC3588] or RADIUS over IPsec [RFC3579] rather than static keys,
as in [RFC2548].

Key naming
In order to ensure against confusion between the appropriate keying
material to be used in a given Secure Association Protocol
exchange, the AAA-Token SHOULD include explicit key names and
context appropriate for informing the authenticator how the keying
material is to be used.

Aboba, et al. Standards Track [Page 54]

INTERNET-DRAFT EAP Key Management Framework 17 July 2005

Key Compromise
Where untrusted intermediaries are present, the AAA-Token SHOULD
NOT be provided to the intermediaries. In Diameter, handling of
keys by intermediaries can be avoided using Redirect functionality
[RFC3588].

7.3. Secure Association Protocol Requirements

The Secure Association Protocol supports the following:

Entity Naming
The peer and authenticator SHOULD identify themselves in a manner
that is independent of their attached ports.

Mutual proof of possession
The peer and authenticator MUST each demonstrate possession of the
keying material transported between the backend authentication
server and authenticator (AAA-Key).

Key Naming
The Secure Association Protocol MUST explicitly name the keys used
in the proof of possession exchange, so as to prevent confusion
when more than one set of keying material could potentially be used
as the basis for the exchange.

Creation and Deletion
In order to support the correct processing of phase 2 security
associations, the Secure Association (phase 2) protocol MUST
support the naming of phase 2 security associations and associated
transient session keys, so that the correct set of transient
session keys can be identified for processing a given packet. The
phase 2 Secure Association Protocol also MUST support transient
session key activation and SHOULD support deletion, so that
establishment and re-establishment of transient session keys can be
synchronized between the parties.

Integrity and Replay Protection
The Secure Association Protocol MUST support integrity and replay
protection of all messages.

Direct operation
Since the phase 2 Secure Association Protocol is concerned with the
establishment of security associations between the EAP peer and
authenticator, including the derivation of transient session keys,
only those parties have "a need to know" the transient session
keys. The Secure Association Protocol MUST operate directly between
the peer and authenticator, and MUST NOT be passed-through to the
backend authentication server, or include additional parties.

Aboba, et al. Standards Track [Page 55]

INTERNET-DRAFT EAP Key Management Framework 17 July 2005

Derivation of transient session keys
The Secure Association Protocol negotiation MUST support derivation
of unicast and multicast transient session keys suitable for use
with the negotiated ciphersuite.

TSK freshness
The Secure Association (phase 2) Protocol MUST support the
derivation of fresh unicast and multicast transient session keys,
even when the keying material provided by the backend
authentication server is not fresh. This is typically supported by
including an exchange of nonces within the Secure Association
Protocol.

Bi-directional operation
While some ciphersuites only require a single set of transient
session keys to protect traffic in both directions, other
ciphersuites require a unique set of transient session keys in each
direction. The phase 2 Secure Association Protocol SHOULD provide
for the derivation of unicast and multicast keys in each direction,
so as not to require two separate phase 2 exchanges in order to
create a bi-directional phase 2 security association.

Secure capabilities negotiation
The Secure Association Protocol MUST support secure capabilities
negotiation. This includes security parameters such as the
security association identifier (SAID) and ciphersuites, as well as
negotiation of the lifetime of the TSKs, AAA-Key and exported EAP
keys. Secure capabilities negotiation also includes confirmation
of the capabilities discovered during the discovery phase (phase
0), so as to ensure that the announced capabilities have not been
forged.

Key Scoping
The Secure Association Protocol MUST ensure the synchronization of
key scope between the peer and authenticator. This includes
negotiation of restrictions on key usage.

7.4. Ciphersuite Requirements

Ciphersuites suitable for keying by EAP methods MUST provide the
following facilities:

TSK derivation
In order to allow a ciphersuite to be usable within the EAP keying
framework, a specification MUST be provided describing how
transient session keys suitable for use with the ciphersuite are
derived from the AAA-Key.

Aboba, et al. Standards Track [Page 56]

INTERNET-DRAFT EAP Key Management Framework 17 July 2005

EAP method independence
Algorithms for deriving transient session keys from the AAA-Key
MUST NOT depend on the EAP method. However, algorithms for
deriving TEKs MAY be specific to the EAP method.

Cryptographic separation
The TSKs derived from the AAA-Key MUST be cryptographically
separate from each other. Similarly, TEKs MUST be
cryptographically separate from each other. In addition, the TSKs
MUST be cryptographically separate from the TEKs.

8. IANA Considerations

This document does not create any new name spaces nor does it
allocate any protocol parameters.

9. References

9.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October
1998.

[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H.
Lefkowetz, "Extensible Authentication Protocol (EAP)", RFC
3748, June 2004.

9.2. Informative References

[CTP] Loughney, J., Nakhjiri, M., Perkins, C. and R. Koodli,
"Context Transfer Protocol", draft-ietf-seamoby-ctp-11.txt,
Internet draft (work in progress), August 2004.

[DESMODES]
National Institute of Standards and Technology, "DES Modes of
Operation", FIPS PUB 81, December 1980, <http://
www.itl.nist.gov/fipspubs/fip81.htm>.

[FIPSDES] National Institute of Standards and Technology, "Data
Encryption Standard", FIPS PUB 46, January 1977.

[Housley] Housley, R. and B. Aboba, "AAA Key Management", draft-housley-
aaa-key-mgmt-00.txt, Internet draft (work in progress), June
2005..IP [IEEE-802] Institute of Electrical and Electronics

Aboba, et al. Standards Track [Page 57]

INTERNET-DRAFT EAP Key Management Framework 17 July 2005

Engineers, "IEEE Standards for Local and Metropolitan Area
Networks: Overview and Architecture", ANSI/IEEE Standard 802,
1990.

[IEEE-802.11]
Institute of Electrical and Electronics Engineers,
"Information technology - Telecommunications and information
exchange between systems - Local and metropolitan area
networks - Specific Requirements Part 11: Wireless LAN Medium
Access Control (MAC) and Physical Layer (PHY) Specifications",
IEEE IEEE Standard 802.11-2003, 2003.

[IEEE-802.1X]
Institute of Electrical and Electronics Engineers, "Local and
Metropolitan Area Networks: Port-Based Network Access
Control", IEEE Standard 802.1X-2004, December 2004.

[IEEE-802.1Q]
Institute of Electrical and Electronics Engineers, "IEEE
Standards for Local and Metropolitan Area Networks: Draft
Standard for Virtual Bridged Local Area Networks", IEEE
Standard 802.1Q/D8, January 1998.

[IEEE-802.11i]
Institute of Electrical and Electronics Engineers, "Supplement
to STANDARD FOR Telecommunications and Information Exchange
between Systems - LAN/MAN Specific Requirements - Part 11:
Wireless Medium Access Control (MAC) and physical layer (PHY)
specifications: Specification for Enhanced Security", IEEE
802.11i, December 2004.

[IEEE-802.11F]
Institute of Electrical and Electronics Engineers,
"Recommended Practice for Multi-Vendor Access Point
Interoperability via an Inter-Access Point Protocol Across
Distribution Systems Supporting IEEE 802.11 Operation", IEEE
802.11F, July 2003.

[IEEE-02-758]
Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang,
"Proactive Caching Strategies for IAPP Latency Improvement
during 802.11 Handoff", IEEE 802.11 Working Group,
IEEE-02-758r1-F Draft 802.11I/D5.0, November 2002.

[IEEE-03-084]
Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang,
"Proactive Key Distribution to support fast and secure
roaming", IEEE 802.11 Working Group, IEEE-03-084r1-I,

Aboba, et al. Standards Track [Page 58]

INTERNET-DRAFT EAP Key Management Framework 17 July 2005

http://www.ieee802.org/11/Documents/DocumentHolder/ 3-084.zip,
January 2003.

[IEEE-03-155]
Aboba, B., "Fast Handoff Issues", IEEE 802.11 Working Group,
IEEE-03-155r0-I, http://www.ieee802.org/11/
Documents/DocumentHolder/3-155.zip, March 2003.

[I-D.ietf-roamops-cert]
Aboba, B., "Certificate-Based Roaming", draft-ietf-roamops-
cert-02 (work in progress), April 1999.

[I-D.ietf-aaa-eap]
Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application", draft-ietf-aaa-
eap-10 (work in progress), November 2004.

[I-D.puthenkulam-eap-binding]
Puthenkulam, J., "The Compound Authentication Binding
Problem", draft-puthenkulam-eap-binding-04 (work in progress),
October 2003.

[I-D.arkko-pppext-eap-aka]
Arkko, J. and H. Haverinen, "EAP AKA Authentication", draft-
arkko-pppext-eap-aka-15.txt (work in progress), December 2004.

[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", draft-
ietf-ipsec-ikev2-17 (work in progress), September 2004.

[MD5Attack]
Dobbertin, H., "The Status of MD5 After a Recent Attack",
CryptoBytes, Vol.2 No.2, 1996.

[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.

[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
1661, July 1994.

[RFC1968] Meyer, G. and K. Fox, "The PPP Encryption Control Protocol
(ECP)", RFC 1968, June 1996.

[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997.

[RFC2246] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A.
and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246,
January 1999.

Aboba, et al. Standards Track [Page 59]

INTERNET-DRAFT EAP Key Management Framework 17 July 2005

[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.

[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.

[RFC2419] Sklower, K. and G. Meyer, "The PPP DES Encryption Protocol,
Version 2 (DESE-bis)", RFC 2419, September 1998.

[RFC2420] Kummert, H., "The PPP Triple-DES Encryption Protocol (3DESE)",
RFC 2420, September 1998.

[RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D. and
R. Wheeler, "A Method for Transmitting PPP Over Ethernet
(PPPoE)", RFC 2516, February 1999.

[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC
2548, March 1999.

[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
Implementation in Roaming", RFC 2607, June 1999.

[RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol",
RFC 2716, October 1999.

[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, June
2000.

[RFC3078] Pall, G. and G. Zorn, "Microsoft Point-To-Point Encryption
(MPPE) Protocol", RFC 3078, March 2001.

[RFC3079] Zorn, G., "Deriving Keys for use with Microsoft Point-to-Point
Encryption (MPPE)", RFC 3079, March 2001.

[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial
In User Service) Support For Extensible Authentication
Protocol (EAP)", RFC 3579, September 2003.

[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese,
"IEEE 802.1X Remote Authentication Dial In User Service
(RADIUS) Usage Guidelines", RFC 3580, September 2003.

[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.

[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public
Keys Used For Exchanging Symmetric Keys", RFC 3766, April

Aboba, et al. Standards Track [Page 60]

INTERNET-DRAFT EAP Key Management Framework 17 July 2005

2004.

[RFC4017] Stanley, D., Walker, J. and B. Aboba, "EAP Method Requirements
for Wireless LANs", RFC 4017, March 2005.

[8021XHandoff]
Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff in a
Public Wireless LAN Based on IEEE 802.1X Model", School of
Computer Science and Engineering, Seoul National University,
Seoul, Korea, 2002.

Acknowledgments

Thanks to Arun Ayyagari, Ashwin Palekar, and Tim Moore of Microsoft,
Dorothy Stanley of Agere, Bob Moskowitz of TruSecure, Jesse Walker of
Intel, Joe Salowey of Cisco and Russ Housley of Vigil Security for
useful feedback.

Author Addresses

Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052

EMail: bernarda@microsoft.com
Phone: +1 425 706 6605
Fax: +1 425 936 7329

Dan Simon
Microsoft Research
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052

EMail: dansimon@microsoft.com
Phone: +1 425 706 6711
Fax: +1 425 936 7329

Jari Arkko
Ericsson
Jorvas 02420
Finland

Phone:
EMail: jari.arkko@ericsson.com

Pasi Eronen

Aboba, et al. Standards Track [Page 61]

INTERNET-DRAFT EAP Key Management Framework 17 July 2005

Nokia Research Center
P.O. Box 407
FIN-00045 Nokia Group
Finland

EMail: pasi.eronen@nokia.com

Henrik Levkowetz (editor)
ipUnplugged AB
Arenavagen 27
Stockholm S-121 28
SWEDEN

Phone: +46 708 32 16 08
EMail: henrik@levkowetz.com

Aboba, et al. Standards Track [Page 62]

INTERNET-DRAFT EAP Key Management Framework 17 July 2005

Appendix A - Ciphersuite Keying Requirements

To date, PPP and IEEE 802.11 ciphersuites are suitable for keying by
EAP. This Appendix describes the keying requirements of common PPP
and 802.11 ciphersuites.

PPP ciphersuites include DESEbis [RFC2419], 3DES [RFC2420], and MPPE
[RFC3078]. The DES algorithm is described in [FIPSDES], and DES
modes (such as CBC, used in [RFC2419] and DES-EDE3-CBC, used in
[RFC2420]) are described in [DESMODES]. For PPP DESEbis, a single
56-bit encryption key is required, used in both directions. For PPP
3DES, a 168-bit encryption key is needed, used in both directions. As
described in [RFC2419] for DESEbis and [RFC2420] for 3DES, the IV,
which is different in each direction, is "deduced from an explicit
64-bit nonce, which is exchanged in the clear during the [ECP]
negotiation phase." There is therefore no need for the IV to be
provided by EAP.

For MPPE, 40-bit, 56-bit or 128-bit encryption keys are required in
each direction, as described in [RFC3078]. No initialization vector
is required.

While these PPP ciphersuites provide encryption, they do not provide
per-packet authentication or integrity protection, so an
authentication key is not required in either direction.

Within [IEEE-802.11], Transient Session Keys (TSKs) are required both
for unicast traffic as well as for multicast traffic, and therefore
separate key hierarchies are required for unicast keys and multicast
keys. IEEE 802.11 ciphersuites include WEP-40, described in
[IEEE-802.11], which requires a 40-bit encryption key, the same in
either direction; and WEP-128, which requires a 104-bit encryption
key, the same in either direction. These ciphersuites also do not
support per-packet authentication and integrity protection. In
addition to these unicast keys, authentication and encryption keys
are required to wrap the multicast encryption key.

Recently, new ciphersuites have been proposed for use with IEEE
802.11 that provide per-packet authentication and integrity
protection as well as encryption [IEEE-802.11i]. These include TKIP,
which requires a single 128-bit encryption key and two 64-bit
authentication keys (one for each direction); and AES CCMP, which
requires a single 128-bit key (used in both directions) in order to
authenticate and encrypt data.

As with WEP, authentication and encryption keys are also required to
wrap the multicast encryption (and possibly, authentication) keys.

Aboba, et al. Standards Track [Page 63]

INTERNET-DRAFT EAP Key Management Framework 17 July 2005

Appendix B - Transient EAP Key (TEK) Hierarchy

Figure B-1 illustrates the TEK key hierarchy for EAP-TLS [RFC2716],
which is based on the TLS key hierarchy described in [RFC2246]. The
TLS-negotiated ciphersuite is used to set up a protected channel for
use in protecting the EAP conversation, keyed by the derived TEKs.
The TEK derivation proceeds as follows:

master_secret = TLS-PRF-48(pre_master_secret, "master secret",
client.random || server.random)
TEK = TLS-PRF-X(master_secret, "key expansion",
server.random || client.random)
Where:
TLS-PRF-X = TLS pseudo-random function defined in [RFC2246],
computed to X octets.

| | |
| | pre_master_secret |
server| | | client
Random| V | Random
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| | | |
+---->| master_secret |<------+
| | (TMS) | |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | |
| | |
| | |
V V V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| Key Block |
| (TEKs) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| client | server | client | server | client | server
| MAC | MAC | write | write | IV | IV
| | | | | |
V V V V V V

Figure B-1 - TLS [RFC2246] Key Hierarchy

Aboba, et al. Standards Track [Page 64]

INTERNET-DRAFT EAP Key Management Framework 17 July 2005

Appendix C - EAP-TLS Key Hierarchy

In EAP-TLS [RFC2716], the MSK is divided into two halves,
corresponding to the "Peer to Authenticator Encryption Key" (Enc-
RECV-Key, 32 octets, also known as the PMK) and "Authenticator to
Peer Encryption Key" (Enc-SEND-Key, 32 octets). In [RFC2548], the
Enc-RECV-Key (the PMK) is transported in the MS-MPPE-Recv-Key
attribute, and the Enc-SEND-Key is transported in the MS-MPPE-Send-
Key attribute.

The EMSK is also divided into two halves, corresponding to the "Peer
to Authenticator Authentication Key" (Auth-RECV-Key, 32 octets) and
"Authenticator to Peer Authentication Key" (Auth-SEND-Key, 32
octets). The IV is a 64 octet quantity that is a known value; octets
0-31 are known as the "Peer to Authenticator IV" or RECV-IV, and
Octets 32-63 are known as the "Authenticator to Peer IV", or SEND-IV.

In EAP-TLS, the MSK, EMSK and IV are derived from the TLS master
secret via a one-way function. This ensures that the TLS master
secret cannot be derived from the MSK, EMSK or IV unless the one-way
function (TLS PRF) is broken. Since the MSK is derived from the the
TLS master secret, if the TLS master secret is compromised then the
MSK is also compromised.

The key derivation scheme specified in RFC 2716 that was specified
prior to the introduction of the terminology MSK and EMSK MUST be
interpreted as follows:

MSK = TLS-PRF-64(TMS, "client EAP encryption",
client.random || server.random)
EMSK = second 64 octets of:
TLS-PRF-128(TMS, "client EAP encryption",
client.random || server.random)
IV = TLS-PRF-64("", "client EAP encryption",
client.random || server.random)

AAA-Key(0,31) = Peer to Authenticator Encryption Key (Enc-RECV-Key)
(MS-MPPE-Recv-Key in [RFC2548]). Also known as the
PMK.
AAA-Key(32,63)= Authenticator to Peer Encryption Key (Enc-SEND-Key)
(MS-MPPE-Send-Key in [RFC2548])
EMSK(0,31) = Peer to Authenticator Authentication Key (Auth-RECV-Key)
EMSK(32,63) = Authenticator to Peer Authentication Key (Auth-Send-Key)
IV(0,31) = Peer to Authenticator Initialization Vector (RECV-IV)
IV(32,63) = Authenticator to Peer Initialization vector (SEND-IV)

Where:

Aboba, et al. Standards Track [Page 65]

INTERNET-DRAFT EAP Key Management Framework 17 July 2005

AAA-Key(W,Z) = Octets W through Z includes of the AAA-Key.
IV(W,Z) = Octets W through Z inclusive of the IV.
MSK(W,Z) = Octets W through Z inclusive of the MSK.
EMSK(W,Z) = Octets W through Z inclusive of the EMSK.
TMS = TLS master_secret
TLS-PRF-X = TLS PRF function defined in [RFC2246] computed to X octets
client.random = Nonce generated by the TLS client.
server.random = Nonce generated by the TLS server.

Figure C-1 describes the process by which the MSK,EMSK,IV and
ultimately the TSKs, are derived from the TLS Master Secret.

---+
| ^
| TLS Master Secret (TMS) |
| |
V |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | EAP |
| Master Session Key (MSK) | Method |
| Derivation | |
| | V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ EAP ---+
| | | API ^
| MSK | EMSK | IV |
| | | |
V V V v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | |
| | |
| backend authentication server | |
| | |
| | V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | ^
| AAA-Key(0,31) | AAA-Key(32,63) |
| (PMK) | Transported |
| | via AAA |
| | |
V V V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | ^
| Ciphersuite-Specific Transient Session | Auth.|
| Key Derivation | |
| | V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+

Figure C-1 - EAP TLS [RFC2716] Key hierarchy

Aboba, et al. Standards Track [Page 66]

INTERNET-DRAFT EAP Key Management Framework 17 July 2005

Appendix D - Example Transient Session Key (TSK) Derivation

Within IEEE 802.11 RSN, the Pairwise Transient Key (PTK), a transient
session key used to protect unicast traffic, is derived from the PMK
(octets 0-31 of the MSK), known in [RFC2716] as the Peer to
Authenticator Encryption Key. In [IEEE-802.11i], the PTK is derived
from the PMK via the following formula:

PTK = EAPOL-PRF-X(PMK, "Pairwise key expansion", Min(AA,SA) ||
Max(AA, SA) || Min(ANonce,SNonce) || Max(ANonce,SNonce))

Where:

PMK = AAA-Key(0,31)
SA = Station MAC address (Calling-Station-Id)
AA = Access Point MAC address (Called-Station-Id)
ANonce = Access Point Nonce
SNonce = Station Nonce
EAPOL-PRF-X = Pseudo-Random Function based on HMAC-SHA1, generating
a PTK of size X octets.

TKIP uses X = 64, while CCMP, WRAP, and WEP use X = 48.

The EAPOL-Key Confirmation Key (KCK) is used to provide data origin
authenticity in the TSK derivation. It utilizes the first 128 bits
(bits 0-127) of the PTK. The EAPOL-Key Encryption Key (KEK) provides
confidentiality Exchange (IKEv2) Protocol", draft-
ietf-ipsec-ikev2-17 (work in the TSK derivation. It utilizes bits 128-255 of
the PTK. Bits 256-383 progress), September 2004.

[MD5Attack]
Dobbertin, H., "The Status of MD5 After a Recent Attack",
CryptoBytes, Vol.2 No.2, 1996.

[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.

[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
1661, July 1994.

[RFC1968] Meyer, G. and K. Fox, "The PPP Encryption Control Protocol
(ECP)", RFC 1968, June 1996.

[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997.

[RFC2246] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A.
and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246,
January 1999.

[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the PTK are used by Temporal Key 1,
Internet Protocol", RFC 2401, November 1998.

[RFC2409] Harkins, D. and Bits
384-511 are used by Temporal D. Carrel, "The Internet Key 2. Usage of TK1 Exchange (IKE)",
RFC 2409, November 1998.

[RFC2419] Sklower, K. and TK2 is
ciphersuite specific. Details are available in [IEEE-802.11i]. G. Meyer, "The PPP DES Encryption Protocol,
Version 2 (DESE-bis)", RFC 2419, September 1998.

[RFC2420] Kummert, H., "The PPP Triple-DES Encryption Protocol (3DESE)",
RFC 2420, September 1998.

[RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D. and
R. Wheeler, "A Method for Transmitting PPP Over Ethernet
(PPPoE)", RFC 2516, February 1999.

Aboba, et al. Standards Track [Page 67] 47]

INTERNET-DRAFT EAP Key Management Framework 17 July 2005

Appendix E - Exported Parameters in Existing Methods

[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC
2548, March 1999.

[RFC2607] Aboba, B. and Server-ID (could be the
empty string) J. Vollbrecht, "Proxy Chaining and MAY also define the Key-Lifetime (assumed to be
indeterminate if not described).

EAP-Identity

The EAP-Identity method does not derive keys, Policy
Implementation in Roaming", RFC 2607, June 1999.

[RFC2716] Aboba, B. and therefore does
not define the Key-Lifetime or Method-ID. The Peer-ID exported by
the Identity method is determined by the octets included within
the EAP- Response/Identity. The Server-ID is the empty string
(zero length).

EAP-Notification

The EAP-Notification method does not derive keys D. Simon, "PPP EAP TLS Authentication Protocol",
RFC 2716, October 1999.

[RFC2865] Rigney, C., Willens, S., Rubens, A. and therefore
does not define the Key-Lifetime W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, June
2000.

[RFC3078] Pall, G. and Method-ID. The Peer-ID G. Zorn, "Microsoft Point-To-Point Encryption
(MPPE) Protocol", RFC 3078, March 2001.

[RFC3079] Zorn, G., "Deriving Keys for use with Microsoft Point-to-Point
Encryption (MPPE)", RFC 3079, March 2001.

[RFC3579] Aboba, B. and
Server-ID are the empty string (zero length).

EAP-GTC

The EAP-GTC method does not derive keys P. Calhoun, "RADIUS (Remote Authentication Dial
In User Service) Support For Extensible Authentication
Protocol (EAP)", RFC 3579, September 2003.

[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and therefore does not
define the Key-Lifetime J. Roese,
"IEEE 802.1X Remote Authentication Dial In User Service
(RADIUS) Usage Guidelines", RFC 3580, September 2003.

[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.

[RFC3766] Orman, H. and Method-ID. The Peer-ID P. Hoffman, "Determining Strengths For Public
Keys Used For Exchanging Symmetric Keys", RFC 3766, April
2004.

[RFC4005] Calhoun, P., Zorn, G., Spence, D. and Server-ID
are the empty string.

EAP-OTP

The EAP-OTP method does not derive keys D. Mitton, "Diameter
Network Access Server Application", RFC 4005, August 2005.

[RFC4017] Stanley, D., Walker, J. and therefore does not
define the Key-Lifetime B. Aboba, "EAP Method Requirements
for Wireless LANs", RFC 4017, March 2005.

[RFC4072] Eronen, P., Hiller, T. and Method-ID. The Peer-ID G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application", RFC 4072, August
2005.

[8021XHandoff]
Pack, S. and Server-ID
are the empty string.

EAP-TLS

The EAP-TLS Method-Id is the concatenation Y. Choi, "Pre-Authenticated Fast Handoff in a
Public Wireless LAN Based on IEEE 802.1X Model", School of the peer
Computer Science and server
nonces.

The Peer-ID Engineering, Seoul National University,

Aboba, et al. Standards Track [Page 48]

INTERNET-DRAFT EAP Key Management Framework 23 October 2005

Seoul, Korea, 2002.

Acknowledgments

Thanks to Arun Ayyagari, Ashwin Palekar, and Server-ID are the contents Tim Moore of the altSubjectName
in the peer Microsoft,
Dorothy Stanley of Agere, Bob Moskowitz of TruSecure, Jesse Walker of
Intel, Joe Salowey of Cisco and server certificates.

EAP-TLS does not negotiate a Key-Lifetime.

EAP-AKA

The EAP-AKA Method-Id is the contents Russ Housley of the RAND field from the Vigil Security for
useful feedback.

Author Addresses

Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052

EMail: bernarda@microsoft.com
Phone: +1 425 706 6605
Fax: +1 425 936 7329

Dan Simon
Microsoft Research
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052

EMail: dansimon@microsoft.com
Phone: +1 425 706 6711
Fax: +1 425 936 7329

Jari Arkko
Ericsson
Jorvas 02420
Finland

Phone:
EMail: jari.arkko@ericsson.com

Pasi Eronen
Nokia Research Center
P.O. Box 407
FIN-00045 Nokia Group
Finland

EMail: pasi.eronen@nokia.com

Henrik Levkowetz (editor)
ipUnplugged AB

Aboba, et al. Standards Track [Page 68] 49]

INTERNET-DRAFT EAP Key Management Framework 17 July 23 October 2005

AT_RAND attribute, followed by

Arenavagen 27
Stockholm S-121 28
SWEDEN

Phone: +46 708 32 16 08
EMail: henrik@levkowetz.com

Aboba, et al. Standards Track [Page 50]

INTERNET-DRAFT EAP Key Management Framework 23 October 2005

Appendix A - EAP-TLS Key Hierarchy

EAP-TLS [RFC 2716] was documented prior to the contents development of EAP key
management terminology [RFC3748], and therefore does not explicitly
define the AUTN field in MSK and EMSK.

In EAP-TLS, the AT_AUTN attribute.

The Peer-ID is MSK, EMSK and IV are derived from the contents of TLS master
secret via a one-way function. This ensures that the Identity field TLS master
secret cannot be derived from the
AT_IDENTITY attribute, using only MSK, EMSK or IV unless the Actual Identity Length
octets one-way
function (TLS PRF) is broken. Since the MSK is derived from the beginning, however. Note that the contents are
used as they are transmitted, regardless of whether
TLS master secret, if the
transmitted identity was a permanent, pseudonym, or fast
reauthentication identity. The Server- ID TLS master secret is an empty string.
EAP-AKA does not negotiate a key lifetime.

EAP-SIM

The Method-Id compromised then the
MSK is also compromised.

[RFC2716] specifies that the contents of MSK is divided into two halves,
corresponding to the RAND field from "Peer to Authenticator Encryption Key" (Enc-
RECV-Key, 32 octets, also known as the AT_RAND
attribute, followed by PMK) and "Authenticator to
Peer Encryption Key" (Enc-SEND-Key, 32 octets). In [RFC2548], the
Enc-RECV-Key (the PMK) is transported in the contents of MS-MPPE-Recv-Key
attribute, and the NONCE_MT field Enc-SEND-Key is transported in the
AT_NONCE_MT MS-MPPE-Send-
Key attribute.

The Peer-ID EMSK is also divided into two halves, corresponding to the contents of the Identity field from the
AT_IDENTITY attribute, using only the Actual Identity Length
octets from the beginning, however. Note "Peer
to Authenticator Authentication Key" (Auth-RECV-Key, 32 octets) and
"Authenticator to Peer Authentication Key" (Auth-SEND-Key, 32
octets). The IV is a 64 octet quantity that the contents is a known value; octets
0-31 are
used known as they the "Peer to Authenticator IV" or RECV-IV, and
Octets 32-63 are transmitted, regardless of whether known as the
transmitted identity was a permanent, pseudonym, "Authenticator to Peer IV", or fast
reauthentication identity. SEND-IV.

The Server- ID is an empty string.
EAP-SIM does not negotiate a key lifetime. derivation scheme MUST be interpreted as follows:

MSK(0,31) = Peer to Authenticator Encryption Key (Enc-RECV-Key)
(MS-MPPE-Recv-Key in [RFC2548]). Also known as the
PMK.
MSK(32,63) = Authenticator to Peer Encryption Key (Enc-SEND-Key)
(MS-MPPE-Send-Key in [RFC2548])
EMSK(0,31) = Peer to Authenticator Authentication Key (Auth-RECV-Key)
EMSK(32,63) = Authenticator to Peer Authentication Key (Auth-Send-Key)
IV(0,31) = Peer to Authenticator Initialization Vector (RECV-IV)
IV(32,63) = Authenticator to Peer Initialization vector (SEND-IV)

Aboba, et al. Standards Track [Page 69] 51]

INTERNET-DRAFT EAP Key Management Framework 17 July 2005

Appendix F - Security Association Examples

EAP Method SA Example: EAP-TLS

In EAP-TLS [RFC2716], after the EAP authentication the client (peer)
and server can store the following information:

o Implicitly, the EAP method this SA refers to (EAP-TLS)
o Session identifier (a value selected by 23 October 2005

Where:

IV(W,Z) = Octets W through Z inclusive of the server)
o Certificate IV.
MSK(W,Z) = Octets W through Z inclusive of the other party (server stores MSK.
EMSK(W,Z) = Octets W through Z inclusive of the client's
certificate and vice versa)
o Ciphersuite and compression method
o EMSK.
TMS = TLS Master secret (known as the EAP-TLS Master Key)
o SA lifetime (ensuring that the SA is not stored forever)
o If the client has multiple different credentials (certificates
and corresponding private keys), a pointer master_secret
TLS-PRF-X = TLS PRF function defined in [RFC2246] computed to those credentials

When X octets
client.random = Nonce generated by the server initiates EAP-TLS, TLS client.
server.random = Nonce generated by the client can look up TLS server.

Figure A-1 illustrates the TEK key hierarchy for EAP-TLS
SA [RFC2716],
which is based on the credentials it was going to use (certificate and
private key), and the expected credentials (certificate or name) of
the server. If an EAP-TLS SA exists, and it is not too old, the
client informs the server about the existence of this SA by including
its Session-Id in the TLS ClientHello message. key hierarchy described in [RFC2246]. The server then looks
TLS-negotiated ciphersuite is used to set up a protected channel for
use in protecting the correct SA based on the Session-Id (or detects that it doesn't
yet have one).

EAP Method SA Example: EAP-AKA

In EAP-AKA [I-D.arkko-pppext-eap-aka], after EAP authentication the
client and server can store the following information:

o Implicitly, conversation, keyed by the EAP method this SA refers to (EAP-AKA)
o A re-authentication pseudonym
o derived TEKs.
The client's permanent identity (IMSI)
o Replay protection counter
o Authentication key (K_aut)
o Encryption key (K_encr)
o Original Master TEK derivation proceeds as follows:

master_secret = TLS-PRF-48(pre_master_secret, "master secret",
client.random || server.random)
TEK = TLS-PRF-X(master_secret, "key expansion",
server.random || client.random)
Where:

TLS-PRF-X = TLS pseudo-random function defined in [RFC2246],
computed to X octets.

| | pre_master_secret |
server| | | client
Random| V | Random
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
+---->| master_secret |<------+
| | (TMS) | |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | |
V V V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Key (MK)
o SA lifetime (ensuring that the SA is not stored forever)

Figure A-1 - TLS [RFC2246] Key Hierarchy

Aboba, et al. Standards Track [Page 70] 52]

INTERNET-DRAFT EAP Key Management Framework 17 July 23 October 2005

AAA SA Example: RADIUS

In RADIUS, where shared secret authentication is used,

Appendix B - Exported Parameters in Existing Methods

This Appendix specifies Method-ID, Peer-ID, Server-ID and Key-
Lifetime for EAP methods that have been published prior to this
specification. Future EAP method specifications MUST include a
definition of the client Method-ID, Peer-ID, and
server store each other's IP address Server-ID (could be the
empty string) and MAY also define the Key-Lifetime (assumed to be
indeterminate if not described).

EAP-Identity

The EAP-Identity method does not derive keys, and therefore does
not define the Key-Lifetime or Method-ID. The Peer-ID exported by
the shared secret, which Identity method is
used to calculate determined by the Response Authenticator [RFC2865] and Message-
Authenticator [RFC3579] values, and to encrypt some attributes (such
as octets included within
the AAA-Key, see [RFC3580] Section 3.16).

Where IPsec is used to protect RADIUS [RFC3579] and IKE EAP- Response/Identity. The Server-ID is used for
key management, the parties store information necessary to
authenticate empty string
(zero length).

EAP-Notification

The EAP-Notification method does not derive keys and authorize therefore
does not define the other party (e.g. certificates, trust
anchors Key-Lifetime and names). Method-ID. The IKE exchange results in IKE Phase 1 Peer-ID and Phase
2 SAs containing information used to protect the conversation
(session keys, selected ciphersuite, etc.)

AAA SA Example: Diameter with TLS

When using Diameter protected by TLS,
Server-ID are the parties store information
necessary to authenticate empty string (zero length).

EAP-GTC

The EAP-GTC method does not derive keys and authorize therefore does not
define the other party (e.g.
certificates, trust anchors Key-Lifetime and names). Method-ID. The TLS handshake results in
a short-term TLS SA that contains information used to protect the
actual communications (session keys, selected TLS ciphersuite, etc.).

Service SA Example: 802.11i

[IEEE802.11i] Section 8.4.1.1 defines Peer-ID and Server-ID
are the security associations used
within IEEE 802.11. A summary follows; empty string.

EAP-OTP

The EAP-OTP method does not derive keys and therefore does not
define the standard should be
consulted for details.

o Pairwise Master Key Security Association (PMKSA) Key-Lifetime and Method-ID. The PMKSA is a bi-directional SA, used by both parties for sending Peer-ID and receiving. Server-ID
are the empty string.

EAP-TLS

The PMKSA EAP-TLS Method-Id is the Root Service SA. It is created
on concatenation of the peer when EAP authentication completes successfully or a
pre-shared key is configured. and server
nonces.

The PMKSA is created on Peer-ID and Server-ID are the
authenticator when contents of the PMK is received or created on altSubjectName
in the
authenticator or peer and server certificates.

EAP-TLS does not negotiate a pre-shared key is configured. Key-Lifetime.

EAP-AKA

The PMKSA EAP-AKA Method-Id is
used to create the PTKSA. PMKSAs are cached for their lifetimes.
The PMKSA consists contents of the following elements:

- PMKID (security association identifier)
- Authenticator MAC address
- PMK
- Lifetime
- Authenticated Key Management Protocol (AKMP)
- Authorization parameters specified by the AAA server or
by local configuration. This can include
parameters such as RAND field from the peer's authorized SSID.

Aboba, et al. Standards Track [Page 71] 53]

INTERNET-DRAFT EAP Key Management Framework 17 July 23 October 2005

On the peer, this information can be locally
configured.
- Key replay counters (for EAPOL-Key messages)
- Reference to PTKSA (if any), needed to:
o delete it (e.g. AAA server-initiated disconnect)
o replace it when a new four-way handshake is done
- Reference to accounting context,

AT_RAND attribute, followed by the details contents of which depend
on the accounting protocol used, the implementation
and administrative details. In RADIUS, this could include
(e.g. packet and octet counters, and Acct-Multi-Session-Id).

o Pairwise Transient Key Security Association (PTKSA)

The PTKSA is a bi-directional SA created as AUTN field in
the result of a
successful four-way handshake. AT_AUTN attribute.

The PTKSA Peer-ID is a unicast service SA.
There may only be one PTKSA between a pair of peer and
authenticator MAC addresses. PTKSAs are cached for the lifetime contents of the PMKSA. Since the PTKSA is tied to Identity field from the PMKSA, it
AT_IDENTITY attribute, using only has the additional information Actual Identity Length
octets from the 4-way handshake. The PTKSA
consists of beginning, however. Note that the following:

- Key (PTK)
- Selected ciphersuite
- MAC addresses contents are
used as they are transmitted, regardless of whether the parties
- Replay counters, and ciphersuite specific state
- Reference to PMKSA: This is needed when:
o A new four-way handshake is needed (lifetime, TKIP
countermeasures), and we need to know which PMKSA to use

o Group Transient Key Security Association (GTKSA)
transmitted identity was a permanent, pseudonym, or fast re-
authentication identity. The GTKSA Server-ID is an empty string. EAP-
AKA does not negotiate a uni-directional SA created based on the four-way
handshake or the group key handshake. lifetime.

EAP-SIM

The GTKSA Method-Id is a multicast
service SA. A GTKSA consists the contents of the following:

- Direction vector (whether RAND field from the GTK is used for transmit or receive)
- Group cipher suite selector
- Key (GTK)
- Authenticator MAC address
- Via reference to PMKSA, or copied here:
o Authorization parameters
o Reference to accounting context

Service SA Example: IKEv2/IPsec

Note that this example AT_RAND
attribute, followed by the contents of the NONCE_MT field in the
AT_NONCE_MT attribute.

The Peer-ID is intended to be informative, and it does
not necessarily include all information stored.

Aboba, et al. Standards Track [Page 72]

INTERNET-DRAFT EAP Key Management Framework 17 July 2005

o IKEv2 SA

- Protocol version
- Identities the contents of the parties
- IKEv2 SPIs
- Selected ciphersuite
- Replay protection counters (Message ID)
- Keys for protecting IKEv2 messages (SK_ai/SK_ar/SK_ei/SK_er)
- Key for deriving keys for IPsec SAs (SK_d)
- Lifetime information
- On Identity field from the authenticator, service authorization information
received
AT_IDENTITY attribute, using only the Actual Identity Length
octets from the backend authentication server.

When processing an incoming message, beginning, however. Note that the correct SA is looked up
based on contents are
used as they are transmitted, regardless of whether the SPIs.

o IPsec SAs/SPD

- Traffic selectors
- Replay protection counters
- Selected ciphersuite
- IPsec SPI
- Keys
- Lifetime information
- Protocol mode (tunnel
transmitted identity was a permanent, pseudonym, or transport) fast re-
authentication identity. The correct SA Server-ID is looked up based on SPI (for inbound packets), or
SPD traffic selectors (for outbound traffic). A separate IPsec SA
exists for each direction. an empty string. EAP-
SIM does not negotiate a key lifetime.

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.

Aboba, et al. Standards Track [Page 73]

INTERNET-DRAFT EAP Key Management Framework 17 July 2005

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.

Aboba, et al. Standards Track [Page 54]

INTERNET-DRAFT EAP Key Management Framework 23 October 2005

Disclaimer of Validity

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.

Acknowledgment

Funding for the RFC Editor function is currently provided by the
Internet Society.

Open Issues

Open issues relating to this specification are tracked on the
following web site:

http://www.drizzle.com/~aboba/EAP/eapissues.html

Aboba, et al. Standards Track [Page 74] 55]

----