WDIFF

draft-ietf-eap-keying-04.txt --> draft-ietf-eap-keying-05.txt

EAP Working Group Bernard Aboba
INTERNET-DRAFT Dan Simon
Category: Informational Standards Track Microsoft
<draft-ietf-eap-keying-04.txt>
<draft-ietf-eap-keying-05.txt> J. Arkko
14 November 2004
18 February 2005 Ericsson
P. Eronen
Nokia
H. Levkowetz, Ed.
ipUnplugged

Extensible Authentication Protocol (EAP) Key Management Framework

By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.

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 May August 22, 2005.

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. Informational Standards Track [Page 1]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004 18 February 2005

Table of Contents

1. Introduction .......................................... 4
1.1 Requirements Language ........................... 4
1.2 Terminology ..................................... 4
1.3 Overview ........................................ 5
1.4 EAP Invariants .................................. 11
2. EAP Key Hierarchy ..................................... 13 Derivation ........................................ 14
2.1 Key Terminology ................................. 13 14
2.2 Key Hierarchy ................................... 15
2.3 Key Lifetimes ................................... 17
2.4 Key Names and Scopes ............................ 24
2.5 AAA-Key Derivation .............................. 27
2.6 21
2.4 AMSK Key Derivation ............................. 28
2.7 22
2.5 Key Scope Issues ................................ 29 Naming ...................................... 23
3. Security associations ................................. 30 26
3.1 EAP Method SA ................................... 31 26
3.2 EAP-Key SA ...................................... 33 27
3.3 AAA SA(s) ....................................... 33 28
3.4 Service SA(s) ................................... 34 28
4. Key Management ........................................ 30
4.1 Key Caching ..................................... 31
4.2 Parent-Child Relationships ...................... 32
4.3 Local Key Lifetimes ............................. 32
4.4 Exported and Calculated Key Lifetimes ........... 33
4.5 Key Cache Synchronization ....................... 34
4.6 Key Scope ....................................... 35
4.7 Key Strength .................................... 36
4.8 Key Wrap ........................................ 37
5. Handoff Support ....................................... 39
4.1 38
5.1 Authorization Issues ............................ 39
4.2 ................................... 38
5.2 Correctness Issues .............................. 41
5. ..................................... 39
6. Security Considerations .............................. 44
5.1 42
6.1 Security Terminology ............................ 44
5.2 42
6.2 Threat Model .................................... 44
5.3 42
6.3 Security Analysis ............................... 45
5.4 44
6.4 Man-in-the-middle Attacks ....................... 49
5.5 48
6.5 Denial of Service Attacks ....................... 49
5.6 48
6.6 Impersonation ................................... 50
5.7 49
6.7 Channel Binding ................................. 51
5.8 Key Strength .................................... 52
5.9 Key Wrap ........................................ 53 50

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

INTERNET-DRAFT EAP Key Management Framework 14 November 2004

6. 18 February 2005

7. Security Requirements ................................. 53
6.1 51
7.1 EAP Method Requirements ......................... 53
6.2 51
7.2 AAA Protocol Requirements ....................... 56
6.3 54
7.3 Secure Association Protocol Requirements ........ 58
6.4 55
7.4 Ciphersuite Requirements ........................ 60
7. 57
8. IANA Considerations ................................... 60
8. 57
9. References ............................................ 61
8.1 58
9.1 Normative References ............................ 61
8.2 58
9.2 Informative References .......................... 61 59
Acknowledgments .............................................. 65 62
Author's Addresses ........................................... 65 63
Appendix A - Ciphersuite Keying Requirements ................. 67 64
Appendix B - Example Transient EAP Key (TEK) Hierarchy ....... 68 65
Appendix C - EAP-TLS Key Hierarchy ........................... 69 66
Appendix D - Example Transient Session Key (TSK) Derivation .. 71 68
Appendix E - Key Names and Scope in Existing Methods ......... 72 69
Appendix F - Security Association Examples ................... 70
Intellectual Property Statement .............................. 73
Disclaimer of Validity ....................................... 73 74
Copyright Statement .......................................... 73 74

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

INTERNET-DRAFT EAP Key Management Framework 14 November 2004 18 February 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 [IEEE8021X].

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:

auth
enticator

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. Informational Standards Track [Page 4]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004 18 February 2005

AAA Authentication, Authorization and Accounting. AAA protocols with
EAP support include RADIUS [RFC3579] and Diameter [I-D.ietf-aaa-
eap]. 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.

1.3. Overview

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 1.

Where authenticators are deployed standalone, the EAP conversation
occurs between the peer and authenticator, and the authenticator must
locally implement an EAP method acceptable to the peer. However, one
of the advantages of EAP is that it enables deployment of new
authentication methods without requiring development of new code on
the authenticator. While the authenticator may implement some EAP
methods locally and use those methods to authenticate local users, it
may at the same time act as a pass-through for other users and
methods, forwarding EAP packets back and forth between the backend
authentication server and the peer.

This is accomplished by encapsulating EAP packets within the
Authentication, Authorization and Accounting (AAA) protocol, spoken
between the authenticator and backend authentication server. AAA
protocols supporting EAP include RADIUS [RFC3579] and Diameter [I-
D.ietf-aaa-eap].

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

INTERNET-DRAFT EAP Key Management Framework 14 November 2004 18 February 2005

+-+-+-+-+
| |
| EAP |
| Peer |
| |
+-+-+-+-+
| | | Peer Ports
/ | \
/ | \
/ | \
/ | \
/ | \
/ | \
/ | \
/ | \
| | | | | | | | | Authenticator Ports
+-+-+-+-+ +-+-+-+-+ +-+-+-+-+
| | | | | |
| Auth. | | Auth. | | Auth. |
| | | | | |
+-+-+-+-+ +-+-+-+-+ +-+-+-+-+
\ | /
\ | /
\ | /
EAP over AAA \ | /
(optional) \ | /
\ | /
\ | /
\ | /
+-+-+-+-+
| |
| AAA |
|Server |
| |
+-+-+-+-+

Figure 1: Relationship between peer, authenticator and backend server

Where EAP key derivation is supported, the conversation between the
peer and the authenticator 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. Informational Standards Track [Page 6]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004 18 February 2005

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 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 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 of the EAP conversation and subsequent
data exchanges.

An additional step (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 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 associations
between the peer and authenticator.

EAP may be used in the following scenarios:

[a] Stationary peer. Where

The conversation phases and relationship between the peer parties is stationary it will establish
communications with one or more authenticators while remaining shown
in
one location. In this scenario, EAP authentication typically
represents only a small fraction of the total session time, so that
it is acceptable for EAP authentication to occur each time the peer
wishes to access the network. In this scenario, the Secure
Association Protocol (Phase 2) MAY be ommitted.

[b] Mobile peer. Where the peer is mobile, it may move its point of
attachment from one authenticator to another, or between points of
attachment on a single authenticator. In this scenario, it is
often desirable to minimize the handoff latency, so that it is
desirable to avoid EAP authentication each time the peer changes
its point of attachment. In this scenario, the Secure Association
Protocol (Phase 2) is REQUIRED.

The conversation phases and relationship between the parties is
shown in Figure 2.

Abo
ba, et al. Informational [Page 7]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004 Figure 2.

Figure 2: Conversation Overview

Aboba, et al. Standards Track [Page 7]

INTERNET-DRAFT EAP Key Management Framework 18 February 2005

1.3.1. Discovery Phase

In the discovery phase (phase 0), the EAP peer and authenticator
locate each other and discover each other's capabilities. Discovery
can occur manually or automatically, depending on the lower layer
over which EAP runs. Since authenticator discovery is handled
outside of EAP, there is no need to provide this functionality within
EAP.

For example, where EAP runs over PPP, the EAP peer might be
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 peer to identify the Ethernet MAC address of one or more
authenticators and establish a PPPoE SESSION_ID.

IEEE 802.11 [IEEE80211] also provides integrated discovery support
utilizing Beacon and/or Probe Request/Response frames, allowing the
peer (known as the station or STA) to determine the MAC address and
capabilities of one or more authenticators (known as Access Point or
APs).

Aboba, et al. Informational [Page 8]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004

1.3.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 the network can be provided 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 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 the EAP exchange occurs between the EAP peer and a
backend authenticator server, with the authenticator forwarding EAP
packets between the two. The entity which terminates EAP
authentication 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, the EAP server
is the authenticator. Where a backend authentication server is
present, at the successful completion of an authentication exchange,
the AAA-Key is transported to the authenticator (phase 1b).

EAP may also be used when it is desired for two network devices (e.g.
two switches or routers) to authenticate each other, or where two

Aboba, et al. Standards Track [Page 8]

INTERNET-DRAFT EAP Key Management Framework 18 February 2005

peers desire to authenticate each other and set up a secure
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 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 the peer, and a Secure Association has been
negotiated.

Since EAP is a peer-to-peer protocol, an independent and simultaneous
authentication may take place in the reverse direction. Both peers
may act as authenticators and authenticatees at the same time.

Successful completion of EAP authentication and key derivation by a
peer and EAP server does not necessarily imply that the peer is
committed to joining the network associated with an EAP server.
Rather, this commitment is implied by the creation of a security
association between the EAP peer and authenticator, as part of the
Secure Association Protocol (phase 2). As a result, EAP may be used
for "pre-authentication" in situations where it is necessary to pre-

Aboba, et al. Informational [Page 9]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004
establish EAP security associations in order to decrease handoff or
roaming latency.

1.3.3. Secure Association Phase

The Secure Association phase (phase 2), if it occurs, begins after
the completion of EAP authentication (phase 1a) and key transport
(phase 1b), and typically supports 1b). EAP may be used in the following features:

[1] Generation of fresh transient session keys (TSKs). scenarios:

[a] Stationary peer. Where AAA-Key
caching is supported, the EAP peer may initiate is stationary it will establish
communications with one or more authenticators while remaining in
one location. In this scenario, EAP authentication typically
represents only a new small fraction of the total session using
a AAA-Key time, so that was used in a previous session. Were
it is acceptable for EAP authentication to occur each time the TSKs peer
wishes to be
derived from a portion of access the AAA-Key, network. In this would result in reuse
of scenario, the session keys which could expose Secure
Association Protocol phase may be omitted.

[b] Mobile peer. Where the underlying ciphersuite
to attack.

As a result, where AAA-Key peer is mobile, it may move its point of
attachment from one authenticator to another, or between points of
attachment on a single authenticator. In this scenario, it is
often desirable to minimize the handoff latency, so that it is
desirable to avoid EAP authentication each time the peer changes
its point of attachment. In this scenario, caching of the AAA-Key
be supported on the EAP peer and authenticator. In this, a Secure

Aboba, et al. Standards Track [Page 9]

INTERNET-DRAFT EAP Key Management Framework 18 February 2005

Assocation Protocol phase is required to allow EAP to be used
securely.

A Secure Association Protocol used with EAP typically supports the
following features:

[1] Generation of fresh transient session keys (TSKs). Where AAA-Key
caching is supported, freshness of the EAP peer may initiate a new session using
a AAA-Key that was used in a previous session. Were the TSKs
MUST to be provided by mechanisms outside
derived from a portion of EAP. This the AAA-Key, this would result in reuse
of the session keys which could expose the underlying ciphersuite
to attack.

As a result, where AAA-Key caching is typically
handled within supported, the Secure
Association protocol Protocol phase is REQUIRED, and MUST provide for
freshness of the TSKs. This is typically handled via the exchange
of nonces or counters, which are then mixed with the AAA-Key in
order to generate fresh unicast (phase 2a) and possibly multicast
(phase 2b) session keys. By not using the AAA-Key directly to
protect data, the secure Secure Association Protocol protects against
compromise of the AAA-Key.

[2] Entity Naming. A basic feature of a Secure Association Protocol is
the explicit naming of the parties engaged in the exchange.
Explicit identification of the parties is critical, since without
this the parties engaged in the exchange are not identified and the
scope of the transient session keys (TSKs) generated during the
exchange is undefined. As illustrated in Figure 1, both the peer
and NAS may have more than one physical or virtual port, so that
port identifiers are typically inappropriate as not recommended a naming mechanism.

[3] Secure capabilities negotiation. This provides for includes the secure
negotiation of usage modes, session parameters (such as key
lifetimes), ciphersuites, ciphersuites and required filters, including
confirmation of the capabilities discovered during phase 0. By
securely negotiating session parameters, It is
RECOMMENDED that the secure Secure Association Protocol protects support secure
capabilities negotiation, in order to protect against spoofing
during the discovery phase phase, and
ensures that to ensure agreement between the
peer and authenticator are in agreement about how data is to be secured.

[4] Key
activation and deletion. In order for the peer and
authenticator to communicate securely, it is necessary for both
sides to derive the same session keys, and remain management. EAP as defined in sync with
respect to [RFC3748] supports key state going forward. One of
derivation, but not key management. While EAP methods may derive
keying material, EAP does provide for the functions management of exported or
derived keys. For example, EAP does not support negotiation of the
Secure Association Protocol is
key lifetime 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 synchronize the activation and provide method

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

INTERNET-DRAFT EAP Key Management Framework 14 November 2004 18 February 2005

independence, key management of exported or derived keys SHOULD NOT
be provided within EAP methods.

Since neither EAP nor 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 of the installation and
deletion of keys so as to enable seamless rekey, or recovery from partial or complete
loss of key state by the peer or authenticator. Since key
management requires a key naming scheme, Secure Association
Protocols supporting key management support MUST also support key
naming.

[5] Mutual proof of possession of the AAA-Key. This demonstrates The Secure Association
Protocol MUST demonstrate mutual proof of posession of the AAA-Key,
in order to show that both the peer and authenticator have been
authenticated and authorized by the backend authentication server.
Since mutual proof of possession is not the same as mutual
authentication, the peer cannot verify authenticator assertions
(including the authenticator identity) as a result of this
exchange.

1.4. EAP Invariants

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

Media independence
Method independence
Ciphersuite independence

1.4.1. Media Independence

One of the goals of EAP is to allow EAP methods to function on any
lower layer meeting the criteria outlined in [RFC3748], Section 3.1.
For example, as described in [RFC3748], EAP authentication can be run
over PPP [RFC1661], IEEE 802 wired networks [IEEE8021X], and IEEE
802.11 wireless LANs [IEEE80211i].

In order to maintain media independence, it is necessary for EAP to
avoid inclusion of media-specific elements. For example, EAP methods
cannot be assumed to have knowledge of the lower layer over which
they are transported, and cannot utilize identifiers associated with
a particular usage environment (e.g. MAC addresses).

The need for media independence has also motivated the development of
the three phase exchange. Since discovery is typically media-

Aboba, et al. Standards Track [Page 11]

INTERNET-DRAFT EAP Key Management Framework 18 February 2005

specific, this function is handled outside of EAP, rather than being
incorporated within it. Similarly, the Secure Association Protocol
often contains media dependencies such as negotiation of media-
specific ciphersuites or session parameters, and as a result this
functionality also cannot be incorporated within EAP.

Note that media independence may be retained within EAP methods that
support channel binding or method-specific identification. An EAP
method need not be aware of the content of an identifier in order to
use it. This enables an EAP method to use media-specific identifiers
such as MAC addresses without compromising media independence. To
support channel binding, an EAP method can pass binding parameters to
the AAA server in the form of an opaque blob, and receive

Aboba, et al. Informational [Page 11]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004
confirmation of whether the parameters match, without requiring
media-specific knowledge.

1.4.2. 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 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 method. Since the Discovery and Secure
Association exchanges are also method independent, an authenticator
can carry out the three phase exchange without having an EAP method
in common with the peer.

This is useful where there is no single EAP method that is both
mandatory-to-implement and offers acceptable security for the media
in use. For example, the [RFC3748] mandatory-to-implement EAP method
(MD5-Challenge) does not provide dictionary attack resistance, mutual
authentication or key derivation, and as a result is not appropriate
for use in wireless LAN authentication [WLANREQ]. However, despite
this it is possible for the peer and authenticator to interoperate as
long as a suitable EAP method is supported on the EAP server.

1.4.3. Ciphersuite Independence

While EAP methods may negotiate the ciphersuite used in protection 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 out-of-band of EAP. Since
ciphersuite negotiation is assumed to occur out-of-band, there is no
need for ciphersuite negotiation within EAP. Since ciphersuite

Aboba, et al. Standards Track [Page 12]

INTERNET-DRAFT EAP Key Management Framework 18 February 2005

negotiation occurs outside of EAP, EAP methods generate keying
material that is ciphersuite-independent.

For example, within PPP, the ciphersuite is negotiated within the
Encryption Control Protocol (ECP) defined in [RFC1968], after EAP
authentication is completed. Within [IEEE80211i], the AP
ciphersuites are advertised in the Beacon and Probe Responses prior
to EAP authentication, and are securely verified during a 4-way
handshake exchange after EAP authentication has completed.

Advantages of ciphersuite-independence include:

Aboba, et al. Informational [Page 12]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004

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 a new
ciphersuite is developed. In addition, backend authentication
servers might not be usable with all EAP-capable authenticators,
since the backend authentication server would also need to be
updated each time support for a new ciphersuite is added to the
authenticator.

Reduced EAP method complexity
Requiring each EAP method to include ciphersuite-specific code for
transient session key derivation would increase method complexity
and result in duplicated effort.

Simplified configuration
The ciphersuite is negotiated between the peer and authenticator
out-of-band of EAP. The backend authentication server is neither a
party to this negotiation, nor is it an intermediary in the data
flow between the EAP peer and authenticator. The backend
authentication server may not have knowledge of the ciphersuites
and negotiation policies implemented by the peer and authenticator,
or be aware of the ciphersuite negotiated between them. This
simplifies the configuration of the backend authentication server.

For example, since ECP negotiation occurs after authentication,
when run over PPP, the EAP peer, authenticator and backend
authentication server may not anticipate the negotiated ciphersuite
and therefore this information cannot be provided to the EAP
method.

Aboba, et al. Standards Track [Page 13]

INTERNET-DRAFT EAP Key Hierarchy Management Framework 18 February 2005

2. Key Derivation

2.1. Key Terminology

The EAP Key Hierarchy makes use of the following types of keys:

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.

Aboba, et al. Informational [Page 13]

INTERNET-DRAFT EAP
Key Management Framework 14 November 2004

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.

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; 2.3; in existing implementations the MSK is
used as the AAA-Key.

Application-specific Master Session Keys (AMSKs)
Keys derived from the EMSK which are cryptographically separate
from each other and may be subsequently used in the derivation of
Transient Session Keys (TSKs) for extended uses. AMSK derivation
is discussed in Section 2.6. 2.4.

AAA-Token
Where a backend server is present, the AAA-Key and one or more
attributes is transported between the backend authentication server
and the authenticator within a package known as the AAA-Token. The
format and wrapping of the AAA-Token, which is intended to be
accessible only to the backend authentication server and

Aboba, et al. Standards Track [Page 14]

INTERNET-DRAFT EAP Key Management Framework 18 February 2005

authenticator, is defined by the AAA protocol. Examples include
RADIUS [RFC2548] and Diameter [I-D.ietf-aaa-eap].

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 is divided into two halves, the "Peer to Authenticator
Encryption Key" (Enc-RECV-Key) and "Authenticator to Peer
Encryption Key" (Enc-SEND-Key) (reception is defined from the point
of view of the authenticator). Within [IEEE80211i] Octets 0-31 of
the AAA-Key (Enc-RECV-Key) are known as the Pairwise Master Key
(PMK). In [IEEE80211i] the TKIP and AES CCMP ciphersuites derive

Aboba, et al. Informational [Page 14]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004
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.

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. 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.

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

2.2. Key Hierarchy

The EAP Key Hierarchy, illustrated in Figure 3, has at the 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

Aboba, et al. Standards Track [Page 15]

INTERNET-DRAFT EAP Key Management Framework 18 February 2005

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 derives two types of keys:

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

Aboba, et al. Informational [Page 15]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004

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

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

In order to protect the EAP conversation, methods supporting key
derivation typically negotiate a ciphersuite and derive Transient EAP
Keys (TEKs) for use with that ciphersuite. The TEKs are stored
locally by the EAP method and are 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 the IV;
however, the use of the IV is deprecated. On both the peer and EAP
server, the exported MSK and keys derived from the AMSK are utilized
in order to calculate the AAA-Key, as described in Section 2.5. 2.3.

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 EAP authentication completes and is successful, the peer and
authenticator obtain the AAA-Key and the Secure Association Protocol
is run between the peer and authenticator in order to securely
negotiate the ciphersuite, derive fresh TSKs used to protect data,
and provide mutual proof of possession of the AAA-Key.

Aboba, et al. Standards Track [Page 16]

INTERNET-DRAFT EAP Key Management Framework 18 February 2005

When the authenticator acts as an endpoint of the EAP conversation
rather than a pass-through, EAP methods are implemented on the
authenticator 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) and Extended
Master Session Key (EMSK) are derived on the EAP peer and
authenticator and exported by the EAP method. In this case, the MSK
and EMSK are known only 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 4. 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 a backend authentication server is utilized, the situation is
illustrated in Figure 5. Here the authenticator acts as a pass-
through between the EAP peer and a backend authentication server. In
this model, the authenticator delegates the access control decision

Aboba, et al. Informational [Page 16]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004
to the backend authentication server, which acts as a Key
Distribution Center (KDC). In this case, the authenticator
encapsulates EAP packet with a AAA protocol such as RADIUS [RFC3579]
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 authenticator acts as a pass-through, EAP methods reside only on
the peer and 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.

2.3. Key Lifetimes

Key lifetime issues are discussed in the sections that follow.
Issues include:

[a]

Aboba, et al. Standards Track [Page 17]

INTERNET-DRAFT EAP Key lifetime negotiation. Where key lifetimes cannot be assumed,
it may be necessary to negotiate them. Where negotiation is
supported, it is RECOMMENDED that the negotiation be secured. Note
that key lifetime negotiation may not always be required. A
difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes
were negotiated. In IKEv2, each end of the SA is responsible for
enforcing its own lifetime policy on the SA and rekeying the SA
when necessary.

[b] Management Framework 18 February 2005

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | ^
| EAP Method | |
| | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | |
| | | | | | |
| | EAP Method Key resynchronization. It is possible for the peer or
authenticator to reboot or reclaim resources, clearing portions or
all of the key cache. Therefore, key lifetime negotiation cannot
guarantee that the key cache will remain synchronized, and the peer
may not be able to determine before attempting to use it whether a
particular key exists within the authenticator cache. It is
therefore RECOMMENDED for the lower layer to provide a mechanism
for key state resynchronization. Since in this situation one or
more of the parties initially do not possess a key with which to
protect the resynchronization exchange, securing this mechanism may
be difficult.

Aboba, et al. Informational [Page 17]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | ^
| EAP Method | |
| | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | |
| | | | | | |
| | EAP Method Key |<->| Long-Term | | |
| | Derivation | | Credential | | |
| | | | | | |
| | | +-+-+-+-+-+-+-+ | Local |<->| Long-Term | | |
| | Derivation | | Credential | | |
| | | | | | |
| | | +-+-+-+-+-+-+-+ | Local to |
| | | | EAP |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Method |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| V | | | |
| +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | |
| | TEK | | MSK | |EMSK | |IV | | |
| |Derivation | |Derivation | |Derivation | |Derivation | | |
| +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | |
| | | | | |
| | | | | V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | | ^
| | | |
| MSK (64B) | EMSK (64B) | IV (64B) |
| | | Exported|
| | | by |
V V V EAP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ Method|
| AAA Key Derivation, | | Known | |
| Naming & Binding | |(Not Secret) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ V
| ---+
| AAA-Key/ Transported |
| Name by AAA |
| Protocol |
V V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | ^
| TSK Derivation | Lower layer |
| [AAA-Key Cache] | Specific |
| | V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+

Figure 3: EAP Key Hierarchy

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

INTERNET-DRAFT EAP Key Management Framework 14 November 2004 18 February 2005

Figure 4: Relationship between EAP peer and authenticator (acting as
an EAP server), where no backend authentication server is present.

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

INTERNET-DRAFT EAP Key Management Framework 14 November 2004 18 February 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 | | | | |
| AAA-Key/| | AAA-Key/| |MSK,EMSK,|
| Name | | Name | | AAA-Key/|
| (TSKs) | | (TSKs) | | Name |
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
^ ^
| |
| MSK, EMSK | MSK, EMSK
| |
| |
+-+-+-+-+-+ +-+-+-+-+-+
| | | |
| EAP | | EAP |
| Method | | Method |
| | | |
| (TEKs) | | (TEKs) |
| | | |
+-+-+-+-+-+ +-+-+-+-+-+

Figure 5: Pass-through relationship between EAP peer, authenticator
and backend authentication server.

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

INTERNET-DRAFT EAP Key Management Framework 14 November 2004

2.3.1. Parent-child relationships

When keying material exported by 18 February 2005

2.3. AAA-Key Derivation

Where a AAA-Key is generated as the result of a successful EAP methods expires, all keying
material derived from
authentication with the exported keying material, (including authenticator A, the
AAA-Key, AMSKs AAA-Key is based on the
MSK: AAA-Key = MSK(0,63).

As discussed in [I-D.irtf-aaaarch-handoff], [IEEE-02-758],
[IEEE-03-084], and TSKs) also expires.

Similarly, when an EAP reauthentication takes place, new [8021XHandoff], keying material is derived and exported by the EAP method, which eventually
results may be required
for use in replacement of calculated keys, including fast handoff between authenticators. Where the AAA-Key,
AMSKs, and TSKs.

As a result, the lifetime of keys calculated from the exported backend
authentication server provides keying material can be no longer than the lifetime of to additional
authenticators in order to facilitate fast handoff, it is highly
desirable for the exported keying material itself. However, the lifetime of calculated keys can be
less than that of the exported keys. For example, TSK rekey may
occur prior used on different authenticators B,
C to EAP reauthentication.

Note be cryptographically separate, so that deletion of the AAA-Key if one authenticator is
compromised, it does not necessarily imply deletion
of lead to the corresponding TSKs. Replacement or deletion of TSKs only
implies replacement compromise of other
authenticators. Where keying material is provided by the AAA-Key when the TSKs are taken from backend
authentication server, a
portion of the AAA-Key.

Failure to mutually prove possession of the AAA-Key during the Secure
Association Protocol exchange need not be grounds for deletion of key hierarchy derived from the
AAA-Key by both parties; rate-limiting Secure Association Protocol
exchanges could AMSK can be
used to prevent a brute force attack.

2.3.2. Local Key Lifetimes

The Transient EAP Keys (TEKs) are session keys used to protect the
EAP conversation. The TEKs are internal to the EAP method and are
not exported. TEKs are typically created during an EAP conversation,
used until the end provide cryptographically separate keying material for use in
fast handoff. Instead of the conversation and then discarded. However,
methods may rekey TEKs during a conversation.

When using TEKs within the EMSK directly an EAP conversation or across conversations,
it is necessary to ensure that replay protection and application
specific key separation
requirements are fulfilled. For instance, if a replay counter (AMSK) is
used, TEK rekey MUST occur prior to wrapping derived as described in Section 2.4:

AAA-Key = MSK(0,63)

AMSK = KDF(EMSK, "EAP AAA-Key derivation for multiple attachments",
length)

AAA-Key-B = prf(AMSK(0,63),"EAP AAA-Key derivation for
multiple attachments", AAA-Key, B-Called-Station-Id,
Calling-Station-Id,length)

AAA-Key-C = prf(AMSK(0,63),"EAP AAA-Key derivation for
multiple attachments",AAA-Key, C-Called-Station-Id,
Calling-Station-Id, length)

Where:
Calling-Station-Id = STA MAC address
B-Called-Station-Id = AP B MAC address
C-Called-Station-Id = AP C MAC address
prf = HMAC-SHA1
KDF = defined in Section 2.4
length = length of derived key material

Here AAA-Key is derived during the counter.
Similarly, TSKs MUST remain cryptographically separate from TEKs
despite TEK rekeying or caching. This prevents TEK compromise from
leading directly to compromise of initial EAP authentication between
the TSKs peer and vice versa. authenticator A. Based on this initial EAP methods may cache local keying material
authentication, an AMSK is also derived, which may persist can be used to derive
AAA-Keys for
multiple EAP conversations when fast reconnect is used [RFC 3748].
For example, authentication between the EAP methods based on TLS (such as EAP-TLS [RFC2716])
derive peer and cache
authenticators B and C. Since the TLS Master Secret, typically for substantial
time periods. The lifetime AMSK is cryptographically separate
from the MSK, each of other local keying material calculated these AAA-Keys is cryptographically separate
from each other, and are guaranteed to be unique between the EAP peer

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

INTERNET-DRAFT EAP Key Management Framework 14 November 2004

within 18 February 2005

(also known as the EAP method is defined by STA) and the method. Note that in
general, when using fast reconnect, there is no guarantee to that authenticator (also known as the
original long-term credentials AP).

2.4. AMSK Key Derivation

The EAP AMSK key derivation function (KDF) derives an AMSK from the
Extended Master Session Key (EMSK), an application key label,
optional application data, and output length.

AMSK = KDF(EMSK, key label, optional application data, length)

The key labels are still in printable ASCII strings unique for each
application (see Section 8 for IANA Considerations).

Additional ciphering keys (TSKs) can be derived from the possession of AMSK using
an application specific key derivation mechanism. In many cases,
this AMSK->TSK derivation can simply split the
peer. For instance, AMSK to pieces of
correct length. In particular, it is not necessary to use a card hold holding
cryptographic one-way function. The length of the private AMSK MUST be
specified by the application.

The AMSK key for EAP-TLS
may have been removed. EAP servers should verify that derivation function is taken from the long-term
credentials are still valid, such PRF+ key expansion
PRF from [IKEv2]. This KDF takes 4 parameters as by checking that certificate
used in the original authentication has not yet expired.

2.3.3. Exported input: secret,
label, application data, and Calculated Key Lifetimes

All EAP methods generating keys are required output length. It is only defined for
255 iterations so it may produce up to generate 5100 bytes of key material.

For the purposes of this specification the secret is taken as the MSK and
EMSK, and may optionally generate the IV. Existing EAP methods do
not negotiate label is the lifetime of key label described above concatenated with a
NUL byte, the exported keys. EAP, defined in
[RFC3748], application data is also does not support the negotiation of lifetimes for
exported keying material such as described above and the MSK, output
length is two bytes. Application data MAY be an empty string. The
KDF is based on HMAC-SHA1 [RFC2104] [SHA1]. For this specification we
have:

KDF (K,L,D,O) = T1 | T2 | T3 | T4 | ...

where:
T1 = prf (K, S | 0x01)
T2 = prf (K, T1 | S | 0x02)
T3 = prf (K, T2 | S | 0x03)
T4 = prf (K, T3 | S | 0x04)

prf = HMAC-SHA1
K = EMSK and IV.

Several mechanisms exist for managing
L = key lifetimes:

[a] AAA attributes. AAA protocols label
D = application data
O = OutputLength (2 bytes)
S = L | " " | D | O

The prf+ construction was chosen because of its simplicity and

Aboba, et al. Standards Track [Page 22]

INTERNET-DRAFT EAP Key Management Framework 18 February 2005

efficiency over other PRFs such as RADIUS [RFC2865] and
Diameter [DiamEAP] support the Session-Timeout attribute. those used in [TLS]. The
Session-Timeout value represents
motivation for the maximum lifetime design of the
exported keys, and all keys calculated from it, this PRF is described in all
circumstances. [SIGMA].

The AAA server MUST expire the exported keys, and
all keys calculated from them, prior to the future time indicated
by Session-Timeout. On NUL byte after the authenticator, where EAP key label is used for
authentication, the Session-Timeout value represents the maximum
session time prior to re-authentication, as described in [RFC3580].
Where EAP avoid collisions if one
key label is used for pre-authentication, the session may not start
until some future time, or may never occur. Nevertheless, the
Session-Timeout value represents the time after which the AAA-Key, a prefix of another label (e.g. "foobar" and all keys calculated
"foobarExtendedV2"). This is considered a simpler solution than
requiring a key label assignment policy that prevents prefixes from it, will have expired on the
authenticator. If the session subsequently starts, re-
authentication will
occurring.

Where another prf needs to be initiated once the Session-Time has expired.
If negotiated, this can be handled within
the session never started, or started and ended, EAP method.

2.5. Key Naming

Each key created within the AAA-Key and
all keys calculated from it will be expired EAP key management framework has a name
(the identifier by which the authenticator
prior key can be identified), as well as a
scope (the parties to whom the future time indicated by Session-Timeout.

Since the TSK lifetime key is often determined by authenticator
resources, available). This section
describes how keys are named, and the AAA server has no insight into scope within which that name
applies.

Session-Id

EAP methods supporting key naming MUST specify a temporally unique
method identifier known as the TSK derivation
process, EAP Method-Id, which is typically
constructed from nonces or counters used within the exchange. Since
multiple EAP sessions may exist between an EAP peer and by EAP server,
the principle Method-Id allows MSKs to be differentiated.

The concatenation of ciphersuite independence, it the EAP Type (expressed in ASCII text), ":" and
the Method-Id (also expressed in ASCII text) is
not appropriate for known as the AAA server to manage any aspect EAP
Session-Id. The inclusion of the TSK
derivation process, including Type in the TSK lifetime.

[b] Lower layer mechanisms. While AAA attributes can communicate EAP Session-Id ensures
that each EAP method has a distinct name space.

The EAP Session-Id uniquely identifies the
maximum exported key lifetime, this only serves EAP session to synchronize the
key lifetime between the backend authentication server EAP
peer and server terminating the
authenticator. Lower layer mechanisms can then EAP conversation. However, suitable
EAP peer and server names may not always be used to enable available. As described
in [RFC3748] Section 7.3, the lifetime of exported and calculated keys to identity provided in the EAP-
Response/Identity, may be negotiated

Aboba, et al. Informational [Page 22]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004

between different from the peer identity authenticated
by the EAP method, and authenticator.

Where TSKs are established as the a result the EAP-Response/Identity is
unsuitable for determination of the peer identity. As a Secure Association
Protocol exchange, it result, the
Session-Id scope is RECOMMENDED that defined by the Secure Association
Protocol include secure negotiation of EAP peer name (if securely
exchanged within the TSK lifetime between method) concatenated with the
peer and authenticator. EAP server name
(also only if securely exchanged). Where the TSK a peer or server name is taken from
missing the AAA-Key,
there null string is no need used. Since an EAP session is not bound
to manage the TSK lifetime as a separate
parameter, since particular authentication or specific ports on the TSK lifetime peer and AAA-Key lifetime
authenticator, the authenticator port or identity are
identical.

[c] System defaults. Where not included in
the Session-Id scope.

Aboba, et al. Standards Track [Page 23]

INTERNET-DRAFT EAP method does not support Key Management Framework 18 February 2005

The EAP Session-Id is exported by the
negotiation of EAP method along with the exported key lifetime,
Session-Id scope, if available, and a negotiation
mechanism is not provided by the lower lower, there may be no way
for the peer used to learn knowledge of the exported key liftime. In
this case it is RECOMMENDED construct names for
other EAP keys. Note that the peer assume EAP Session-Id and scope are only
known by the EAP method. As a default value result, the format of the exported key lifetime; 8 hours is suggested. Similarly, EAP Session-
Id and the
lifetime definition of calculated keys can also be managed as a system
parameter on the authenticator.

2.3.4. Key cache synchronization

Issues arise when attempting Session-Id scope needs to synchronize be specified
within the key cache on method. Appendix E defines the peer EAP Session-Id and authenticator. Lifetime negotiation alone cannot guarantee scope
provided by existing methods.

MSK Name

This key
cache synchronization.

One problem is that the AAA protocol cannot guarantee synchronization
of key lifetimes created between the EAP peer and authenticator. Where the
Secure Association Protocol is not run immediately after EAP
authentication, the exported server, and calculated key lifetimes will not can be
known by
referred to using the peer during string "MSK:", concatenated with the hiatus. Where EAP pre-authentication
occurs, this can leave the peer uncertain whether a subsequent
attempt to use
Session-Id. As with the exported keys will prove successful.

However, even where EAP Session-Id, the Secure Association Protocol is run
immediately after EAP, it MSK scope is still possible for defined by
the authenticator to
reclaim resources EAP peer name (if securely exchanged within the method) and the
EAP server name (also only if securely exchanged). Where a peer or
server name is missing the created key state null string is not immediately
utilized. used.

EMSK Name

The lower layer may utilize Discovery mechanisms EMSK can be referred to assist in this.
For example, the authenticator manages the AAA-Key cache by deleting
the oldest AAA-Key first (LIFO), using the relative creation time of string "EMSK:", concatenated
with the
last AAA-Key to be deleted could be advertised EAP Session-Id.

As with the Discovery
phase, enabling EAP Session-Id, the peer to determine whether a given AAA-Key had
been expired from EMSK scope is defined by the authenticator key cache prematurely.

Aboba, et al. Informational [Page 23]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004

2.4. Key Names and Scopes

Each key created peer
name (if securely exchanged within the method) and the EAP key management framework has server
name (also only if securely exchanged). Where a peer or server name
(the identifier by which
is missing the key null string is used.

AMSK Name

AMSKs, if any, can be identified), as well as a
scope (the parties referred to whom using the string "AMSK:", the key is available). This section
describes how keys are named,
label, ":", application data (see Section 2.4), ":", and the scope within which that name
applies.

Session-Id EAP methods supporting key naming MUST specify a temporally unique
method identifier known as
Session-Id.

As with the EAP Method-Id, which Session-Id, the AMSK scope is typically
constructed from nonces or counters used within defined by the exchange. Since
multiple EAP sessions may exist between an EAP peer and EAP server,
the Method-Id allows MSKs to be differentiated.

The combination of
name (if securely exchanged within the EAP Type method), ":" and the Method-Id EAP
server name (also only if securely exchanged). Where a peer or
server name is known as missing the EAP
Session-Id. null string is used.

AAA-Key Name

The inclusion of the Type in AAA-Key is derived from either the EAP Session-Id ensures
that each EAP method has a distinct name space. MSK or AMSK and so can be
referred to using the MSK or AMSK names.

The EAP Session-Id uniquely identifies AAA-Key scope is provided by the EAP session to concatenation of the EAP peer
name (if securely provided to the authenticator), and server terminating the
authenticator name (if securely provided to the peer).

For the purpose of identifying the authenticator to the peer, the

Aboba, et al. Standards Track [Page 24]

INTERNET-DRAFT EAP conversation. However, suitable
EAP peer and server names Key Management Framework 18 February 2005

value of the NAS-Identifier attribute is recommended. The
authenticator may not always be available. As described
in [RFC3748] Section 7.3, include the identity provided NAS-Identifier attribute to the AAA
server in an Access-Request, and the EAP-
Response/Identity, authenticator may be different from provide the identity authenticated
by
NAS-Identifier (unsecured) to the EAP method, and as peer in the EAP-
Request/Identity or via a result lower layer mechanism (such as the EAP-Response/Identity 802.11
Beacon/Probe Response). Where the NAS-Identifier is
unsuitable for determination of provided by the
authenticator to the peer identity. As a result, the
Session-Id scope secure mechanism is defined by RECOMMENDED.

For the purpose of identifying the EAP peer name (if securely
exchanged within to the method) concatenated with authenticator, the EAP server name
(also only if securely exchanged). Where a
peer or server name is
missing identifier provided within the null string is used. Since an EAP session method is not bound
to a particular authentication or specific ports on the peer and
authenticator, recommended. It
cannot be assumed that the authenticator port or identity are not included in is aware of the Session-Id scope.

The EAP Session-Id is exported by the EAP method along with the
Session-Id scope, if available, and is peer
name used to construct names for
other EAP keys. Note that the EAP Session-Id and scope are only
known by within the EAP method. As a result, the format of the EAP Session-
Id and the definition of the Session-Id scope needs Therefore alternatives mechanisms need
to be specified
within the method. Appendix E defines the EAP Session-Id and scope
provided by existing methods.

MSK Name

This key is created between used to provide the EAP peer and EAP server, and can be
referred name to using the string "MSK" and authenticator. For
example, the EAP Session-Id. As with AAA server may include the EAP Session-Id, peer name in the MSK scope is defined by User-
Name attribute of the Access-Accept or the EAP peer may provide the
authenticator with its name (if

Aboba, et al. Informational [Page 24]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004

securely exchanged via a lower layer mechanism.

Absent an explicit binding step within the method) and Secure Association
Protocol, the EAP server name (also
only if securely exchanged). Where AAA-Key is not bound to a specific peer or server name is missing
the null string is used.

EMSK Name

The EMSK can be referred to using
authenticator port. As a result, the string "EMSK" and peer or authenticator port over
which the EAP
Session-Id.

As with conversation takes place is not included in the EAP Session-Id, AAA-Key
scope.

PMK Name

This document does not specify a naming scheme for the EMSK scope PMK. The PMK
is defined only identified by the EAP peer
name (if securely exchanged within the method) and AAA-Key from which it is derived.
Similarly, the EAP server
name (also only if securely exchanged). Where a peer or server name PMK scope is missing the null string is used.

AMSK Name

AMSKs, if any, can be referred same as the AAA-Key scope.

Note: IEEE 802.11i names the PMKID for the purposes of being able to using
refer to it in the string "AMSK", Secure Association protocol; this naming is based
on a hash of the key
label, application data PMK itself as well as some other parameters (see
Section 2.6) and the EAP Session-Id.

As with 8.5.1.2 [IEEE80211i]).

TEKs

The TEKs may or may not be named. Their naming is specified in the
EAP Session-Id, method. Since the AMSK scope is defined TEKs are only known by the EAP peer
name (if securely exchanged within the method) and
server, the EAP server
name (also only if securely exchanged). Where a peer or server name TEK scope is missing the null string is used.

AAA-Key Name same as the Session-Id scope.

TSKs

The AAA-Key TSKs are typically named. Their naming is derived from either specified in the MSK or AMSK and Secure
Association (phase 2) protocol, so that the correct set of transient
session keys can be
referred to using the MSK or AMSK names. identified for processing a given packet. The AAA-Key
scope is provided by the concatenation of the EAP peer
name (if securely provided to TSKs is negotiated within the authenticator), Secure Association
Protocol.

Aboba, et al. Standards Track [Page 25]

INTERNET-DRAFT EAP Key Management Framework 18 February 2005

TSK creation and the
authenticator name (if securely provided to the peer).

For the purpose deletion operations are typically supported so that
establishment and re-establishment of identifying TSKs can be synchronized
between the authenticator parties.

In order to the peer, the
value of the NAS-Identifier attribute is recommended. The
authenticator may include the NAS-Identifier attribute to the AAA
server avoid confusion in an Access-Request, and the authenticator may provide the
NAS-Identifier (unsecured) to the case where an EAP peer in the EAP-
Request/Identity or via a lower layer mechanism (such as the 802.11
Beacon/Probe Response). Where the NAS-Identifier is provided by the
authenticator has more
than one AAA-Key (phase 1b) applicable to the peer a secure mechanism is RECOMMENDED.

For the purpose establishment of identifying a phase 2
security association, the peer secure Association protocol needs to
utilize the authenticator, AAA-Key name so that the EAP
peer identifier provided within appropriate phase 1b keying
material can be identified for use in the Secure Association Protocol
exchange.

3. Security Associations

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

[1] EAP method SA. This SA is recommended. It
cannot be assumed that the authenticator is aware of between the EAP peer
name used within
the method. Therefore alternatives mechanisms need
to and EAP server. It
stores state that can be used to provide the 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 the peer name and EAP server, which
is used to store the authenticator. For
example, keying material exported by the AAA EAP method.
Current EAP server may include implementations do not retain this SA after the
EAP peer name in conversation completes, but proposals such as [IEEE-03-084] and
[I-D.irtf-aaaarch-handoff] use this SA for purposes such as pre-
emptive key distribution.

[3] AAA SA(s). These SAs are between the User- authenticator and the backend
authentication server. They permit the parties to mutually
authenticate each other and protect the communications between
them.

[4] Service SA(s). These SAs are between the peer and authenticator,
and they are created as a result of phases 1-2 of the conversation
(see Section 1.3).

Examples 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 EAP server even
after phase 1a has completed.

Typically, this is used for "fast reconnect": the peer and EAP server
can confirm that they are still talking to the same party, perhaps
using fewer round-trips or less computational power. In this case,
the EAP method SA is essentially a cache for performance

Aboba, et al. Informational Standards Track [Page 25] 26]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004

Name attribute of the Access-Accept or the peer 18 February 2005

optimization, and either party may provide remove the
authenticator with SA from its name via cache at
any point.

An EAP method may also keep state in order to support pseudonym-based
identity protection. This is typically a lower layer mechanism.

Absent an explicit binding step within the Secure Association
Protocol, cache as well (the
information can be recreated if the AAA-Key original EAP method SA is lost),
but may be stored for longer periods of time.

The EAP method SA is not bound restricted to a specific peer particular service or
authenticator port. As a result, and is most useful when the peer or authenticator port over
which the accesses many
different authenticators. An EAP conversation takes place method is not included in responsible for
specifying how the AAA-Key
scope.

PMK Name

This document does 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 specify a naming scheme for typically synchronized
between them.

EAP method implementations should consider the PMK. The PMK
is only identified by appropriate lifetime
for the AAA-Key from which it is derived.
Similarly, EAP method SA. "Fast reconnect" assumes that the PMK scope is information
required (primarily the same as keys in the AAA-Key scope.

Note: IEEE 802.11i names EAP method SA) hasn't been
compromised. In case the PMKID original authentication was carried out
using, for the purposes of being able to
refer to it in the Secure Association protocol; this naming is based
on instance, a hash of the PMK itself as well as some other parameters (see
Section 8.5.1.2 [IEEE80211i]).

TEKs

The TEKs may or smart card, it may not be named. Their naming is specified in easier to compromise the
EAP method. Since method SA (stored on the TEKs are only known by PC, for instance), so typically the EAP
method SAs have a limited lifetime.

Contents:

o Implicitly, 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 is an SA between the peer and EAP server, the TEK scope which is used to store
the same as the Session-Id scope.

TSKs

The TSKs are typically named. Their naming is specified in keying material exported by the Secure
Association (phase 2) protocol, so that EAP method. Current EAP server
implementations do not retain this SA after the correct set of transient
session keys can be identified EAP conversation
completes, but future implementations could use this SA for processing a given packet. The
scope of the TSKs is negotiated within the Secure Association
Protocol.

TSK creation pre-
emptive key distribution.

Contents:

o MSK and deletion operations are typically supported so that
establishment EMSK names
o MSK and re-establishment of TSKs can be synchronized
between the parties.

In order to avoid confusion in the case where an EAP peer has more
than one AAA-Key (phase 1b) applicable to establishment of a phase 2
security association, the secure Association protocol needs to
utilize the AAA-Key name so that the appropriate phase 1b keying
material can be identified for use in the Secure Association Protocol
exchange. EMSK
o SA lifetime

Aboba, et al. Informational Standards Track [Page 26] 27]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004

2.5. AAA-Key Derivation

Where a AAA-Key is generated as the result of a successful EAP 18 February 2005

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

In order for the authenticator A, the AAA-Key is based on the
MSK: AAA-Key = MSK(0,63).

As discussed in [I-D.irtf-aaaarch-handoff], [IEEE-02-758],
[IEEE-03-084], and [8021XHandoff], keying material may be required
for use in fast handoff between authenticators. Where the backend authentication server provides keying material to additional
authenticators in order
authenticate each other, they need to facilitate fast handoff, it is highly
desirable for store some information.

In case the keying material used on different authenticators B,
C to be cryptographically separate, so that if one authenticator is
compromised, it does not lead to the compromise of other
authenticators. Where keying material is provided by the and backend authentication server, a key hierarchy derived from the AMSK can be
used to provide cryptographically separate keying material for use in
fast handoff. Instead of server are
colocated, and they communicate using local procedure calls or shared
memory, this SA need not necessarily contain any information.

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

The service SAs store information about the EMSK directly an application
specific key (AMSK) is derived as described in Section 2.6:

AAA-Key = MSK(0,63)

AMSK = KDF(EMSK, "EAP AAA-Key derivation for multiple attachments",
length)

AAA-Key-B = prf(AMSK(0,63),"EAP AAA-Key derivation for
multiple attachments", AAA-Key, B-Called-Station-Id,
Calling-Station-Id,length)

AAA-Key-C = prf(AMSK(0,63),"EAP AAA-Key derivation for
multiple attachments",AAA-Key, C-Called-Station-Id,
Calling-Station-Id, length)

Where:
Calling-Station-Id = STA MAC address
B-Called-Station-Id = AP B MAC address
C-Called-Station-Id = AP C MAC address
prf = HMAC-SHA1
KDF = defined in Section 2.6
length = length of service being provided.
These include the Root service SA and derived key material

Here AAA-Key unicast and multicast
service SAs.

The Root service SA is derived during established as the initial EAP authentication between result of the peer and authenticator A. Based on this initial completion of
EAP
authentication, an AMSK is also derived, which can be used to derive
AAA-Keys for fast authentication between the EAP peer and
authenticators B (phase 1a) and C. Since AAA-Key derivation or transport
(phase 1b). It includes:

o Service parameters (or at least those parameters
that are still needed)
o On the AMSK is cryptographically separate authenticator, service authorization
information received from the MSK, each backend authentication
server (or necessary parts of these AAA-Keys is cryptographically separate
from each other, and are guaranteed to be unique between it)
o On the EAP peer

Aboba, et al. Informational [Page 27]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004

(also known as the STA) and the authenticator (also known as the AP).

2.6. AMSK Key Derivation

The EAP AMSK key derivation function (KDF) derives an AMSK from the
Extended Master Session Key (EMSK), an application key label,
optional application data, and output length.

AMSK = KDF(EMSK, key label, optional application data, length) peer, usually locally configured service
authorization information.
o The key labels are printable ASCII strings unique for each
application (see Section 7 for IANA Considerations).

Additional ciphering keys (TSKs) AAA-Key, if it can be needed again (to refresh
and/or resynchronize other keys or for another reason)
o AAA-Key lifetime

Unicast and (optionally) multicast service SAs are derived from the AMSK using
an application specific key derivation mechanism. In many cases,
this AMSK->TSK derivation can simply split
Root service SA, via the AMSK to pieces of
correct length. Secure Association Protocol. In particular, order for
unicast and multicast service SAs and associated TSKs to be
established, it is not necessary for EAP authentication (phase 1a) to use a
cryptographic one-way function. The length
be rerun each time. Instead, the Secure Association Protocol can be
used to mutually prove possession of the AMSK MUST AAA-Key and create
associated unicast (phase 2a) and multicast (phase 2b) service SAs
and TSKs, enabling the EAP exchange to be
specified bypassed. Unicast and
multicast service SAs include:

o Service parameters negotiated by the application.

The AMSK key derivation Secure Association Protocol.
o Endpoint identifiers.
o Transient Session Keys used to protect the communication.
o Transient Session Key lifetime.

One function is taken from of the PRF+ key expansion
PRF from [IKEv2]. This KDF takes 4 parameters as input: secret,
label, application data, and output length. It Secure Association Protocol is only defined for
255 iterations so it may produce up to 5100 bytes of key material.

For the purposes of this specification the secret is taken as the
EMSK, the label is bind the key label described above concatenated with a
NUL byte, the application data is also described above
unicast and the output
length is two bytes. Application data MAY be an empty string. The
KDF is based on HMAC-SHA1 [RFC2104] [SHA1]. For this specification we
have:

KDF (K,L,D,O) = T1 | T2 | T3 | T4 | ...

where:
T1 = prf (K, S | 0x01)
T2 = prf (K, T1 | S | 0x02)
T3 = prf (K, T2 | S | 0x03)
T4 = prf (K, T3 | S | 0x04)

prf = HMAC-SHA1
K = EMSK
L = key label
D = application data
O = OutputLength (2 bytes)
S = L | " " | D | O

The prf+ construction was chosen because of its simplicity multicast service SAs and TSKs to endpoint identifiers.
For example, within [IEEE802.11i], the 4-way handshake binds the TSKs

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

INTERNET-DRAFT EAP Key Management Framework 14 November 2004

efficiency over other PRFs such as those used in [TLS]. The
motivation for 18 February 2005

to the design MAC addresses of this PRF is described the endpoints; in [SIGMA].

The NUL byte after [IKEv2], the key label is used TSKs are bound
to avoid collisions if one
key label is a prefix the IP addresses of another label (e.g. "foobar" the endpoints and
"foobarExtendedV2"). This the negotiated SPI.

It is considered a simpler solution possible for more than
requiring a key label assignment policy that prevents prefixes from
occurring.

Where another prf needs one unicast or multicast service SA to
be negotiated, this can be handled within
the EAP method.

2.7. Key Scope Issues

As described in Section 2.5, the AAA-Key is calculated derived from the EMSK
and MSK by the EAP peer and server, and is used as the root of the
ciphersuite-specific key hierarchy. Where a backend authentication
server is present, the AAA-Key single Root service SA. However, a unicast or
multicast service SA is transported always descended from the EAP server to
the authenticator; where it is not present, the AAA-Key is calculated
on the authenticator.

Regardless of how many sessions are initiated using it, the AAA-Key
scope is between the EAP peer that calculates it, and the
authenticator
that either calculates it (where no backend
authenticator is present) only one Root service
SA. Unicast or receives it multicast service SAs descended 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] same Root
service SA may advertise itself as multiple "virtual" authenticators utilize the same security parameters (e.g. mode,
ciphersuite, etc.) or peers;
[c] they may utilize multiple CPUs;
[d] may support clustering services for load balancing or failover.

As illustrated in Figure 1, an different parameters.

An EAP peer with may be able to negotiate multiple ports service SAs with a
given authenticator, or may be
attached able to maintain one or more authenticators, each service
SAs with multiple ports.
Where authenticators, depending on the peer and authenticator identify themselves using a port
identifier such as a link layer address, properties of the
media.

Except where explicitly specified by the Secure Association Protocol,
it may should not be obvious assumed that the installation of new service SAs
implies deletion of old service SAs. It is possible for multicast
Root service SAs to between the same EAP peer which authenticator ports are associated with which
authenticators. Similarly, and authenticator;
during a re-key of a unicast or multicast service SA it may not be obvious is possible
for two service SAs to exist during the
authenticator which peer ports are associated with which peers. As a
result, period between when the peer new
service SA and authenticator may not be able to determine the
scope corresponding TSKs are calculated and when they are
installed.

Similarly, deletion or creation of the AAA-Key.

When a single physical authenticator advertises itself as multiple
"virtual authenticators", the EAP peer and authenticator also may unicast or multicast service SA
does not
be able to agree on the scope necessarily imply deletion or creation of related unicast or
multicast service SAs, unless specified by the AAA-Key, creating a security

Aboba, et al. Informational [Page 29]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004

vulnerability. Secure Association
protocol. For example, the peer a unicast service SA may assume that the "virtual
authenticators" are distinct and do not share be rekeyed without
implying a key cache, whereas,
depending on rekey of the architecture multicast service SA.

The deletion of the physical AP, a shared key cache
may or may Root service SA does not be implemented.

Where necessarily imply the AAA-Key is shared between "virtual authenticators" an
attacker acting as a peer could authenticate with the "Guest"
"virtual authenticator" and derive a AAA-Key. If the virtual
authenticators share a key cache, then the peer can utilize
deletion of the AAA-
Key derived for the "Guest" network to obtain access to the
"Corporate Intranet" virtual authenticator.

Several measures are recommended to address these issues:

[a] Authenticators are REQUIRED to cache unicast and multicast service SAs and
associated authorizations
along with TSKs. Failure to mutually prove possession of the AAA-Key and apply authorizations consistently. This
ensures that an attacker cannot obtain elevated privileges even
where
during the AAA-Key cache is shared between "virtual authenticators".

[b] It is RECOMMENDED that physical authenticators maintain separate
AAA-Key caches Secure Association Protocol exchange need not be grounds
for each "virtual authenticator".

[c] It is RECOMMENDED that each "virtual authenticator" identify itself
distinctly to deletion of the AAA server, such as AAA-Key by utilizing a distinct NAS-
identifier attribute. This enables both parties; the AAA server to utilize a
separate credential action to authenticate each "virtual authenticator".

[d] It be taken
is RECOMMENDED that defined by the 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 Protocol.

3.4.1. Sharing service SAs

A single service may support be provided by multiple ports.

[e] The AAA server and authenticator MAY implement additional
attributes in order to further restrict the AAA-Key scope. For
example, in 802.11, the AAA server may provide the authenticator
with a list of authorized Called logical or Calling-Station-Ids and/or
SSIDs for which the AAA-Key physical
service elements. Each service is valid.

[f] Where the AAA server provides attributes restricting the key scope,
it responsible for specifying how
changing service elements is RECOMMENDED that restrictions be securely communicated by handled. Some approaches include:

Transparent sharing
If the
authenticator service parameters visible to the peer. This is typically accomplished using other party (either peer
or authenticator) do not change, the Secure Association Protocol, but also service can be accomplished via
the EAP method or moved without
requiring cooperation from the lower layer. other party.

Aboba, et al. Informational Standards Track [Page 30] 29]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004

3. Security Associations

During EAP authentication 18 February 2005

Whether such a move should be supported or used depends on
implementation and subsequent exchanges, four types administrative considerations. For instance, an
administrator may decide to configure a group of
security associations (SAs) are created:

[1] EAP method SA. This SA is between IKEv2/IPsec
gateways in a cluster for high-availability purposes, if the
implementation used supports this. The peer does not necessarily
have any way of knowing when the change occurs.

No sharing
If the service parameters require changing, some changes may
require terminating the old service, and EAP server. It
stores state that can be starting a new
conversation from phase 0. This approach is used by all services
for "fast reconnect" or other
functionality in at least some EAP methods. Not all EAP methods create such
an SA.

[2] EAP-Key SA. This is an parameters, and it doesn't require any protocol
for transferring the service SA between the peer and EAP server, which
is used service elements.

The service may support keeping the old service element active
while the new conversation takes phase, to store decrease the keying material exported by time the EAP method.
Current EAP server implementations do
service is not retain this SA after available.

Some sharing
The service may allow changing some parameters by simply agreeing
about the
EAP conversation completes, but proposals such new values. This may involve a similar exchange as [IEEE-03-084] and
[I-D.irtf-aaaarch-handoff] use this SA in
phase 2, or perhaps a shorter conversation.

This option usually requires some protocol for purposes such as pre-
emptive key distribution.

[3] AAA SA(s). These SAs are between the authenticator and the backend
authentication server. They permit the parties to mutually
authenticate each other and protect transferring the communications between
them.

[4] Service SA(s). These SAs are
service SA between the peer and authenticator,
and they are created as a result of phases 1-2 of the conversation
(see Section 1.3).

3.1. EAP Method SA (peer - EAP server) elements. An EAP method administrator may store decide not to
enable this feature at all, and typically the sharing is restricted
to some state on particular service elements (defined either by a service
parameter, or simple administrative decision). If the peer old and EAP server even
after phase 1a has completed.

Typically, new
service element do not support such "context transfer", this is used for "fast reconnect":
approach falls back to the peer and EAP previous option (no transfer).

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

Note that they these considerations are still talking not limited to service
parameters related to the same party, perhaps
using fewer round-trips or less computational power. In this case,
the EAP method SA is essentially a cache for performance
optimization, and either party may remove the SA from its cache at
any point.

An EAP method may also keep state in order authenticator--they apply to support pseudonym-based
identity protection. This is typically a cache peer
parameters as well (the
information can be recreated if the original EAP method SA is lost),
but may be stored for longer periods of time. well.

4. Key Management

The EAP method SA is not restricted to a particular service or peer, authenticator and is most useful when the peer accesses many
different authenticators. An backend server may support key
caching. Since EAP method is responsible for
specifying how supports key derivation, but not key management,
this functionality needs to be provided by the parties select if an existing Secure Association
Protocol. Key management support includes:

[a] Key lifetime determination. EAP method SA should
be used, and if so, which one. Where multiple backend authentication does not support negotiation of
key lifetimes, nor does it support rekey without reauthentication.

Aboba, et al. Informational Standards Track [Page 31] 30]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004

servers are used, EAP method SAs are not typically synchronized
between them.

EAP method implementations should consider 18 February 2005

As a result, the appropriate lifetime Secure Association Protocol is responsible for
rekey and determination of the EAP method SA. "Fast reconnect" assumes key lifetime. Where key caching is
supported, secure negotiation of key lifetimes is RECOMMENDED.
Lower layers that support rekey, but not key caching may not
require key lifetime negotiation. To take an example from IKE, the information
required (primarily the keys
difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes
were negotiated. In IKEv2, each end of the EAP method SA) hasn't been
compromised. In case SA is responsible for
enforcing its own lifetime policy on the original authentication was carried out
using, SA and rekeying the SA
when necessary.

[b] Key resynchronization. It is possible for instance, a smart card, it the peer or
authenticator to reboot or reclaim resources, clearing portions or
all of the key cache. Therefore, key lifetime negotiation cannot
guarantee that the key cache will remain synchronized, and the peer
may not be easier able to compromise determine before attempting to use a AAA-Key
whether it exists within the
EAP method SA (stored on authenticator cache. It is therefore
RECOMMENDED for the PC, Secure Association Protocol to provide a
mechanism for instance), so typically key state resynchronization. Since in this situation
one or more of the EAP
method SAs have parties initially do not possess a limited lifetime.

Contents:

o Implicitly, key with
which to protect the EAP method resynchronization exchange, securing this SA refers to
o Internal (non-exported) cryptographic state
o EAP method SA name
o SA lifetime

3.1.1. Example: EAP-TLS

In EAP-TLS [RFC2716], after
mechanism may be difficult.

[c] Key selection. Where key caching is supported, it may be possible
for the EAP authentication the client (peer) peer and server can store authenticator to share more than one key of a
given type. As a result, the following information:

o Implicitly, Secure Association Protocol needs to
support key selection, using the EAP method Key Naming scheme described in
this SA refers to (EAP-TLS)
o Session identifier (a value selected document.

[d] Key scope determination. Since the Discovery phase is handled out-
of-band, EAP does not provide a mechanism by which the server)
o Certificate of peer can
determine the other party (server stores authenticator identity. As a result, where the client's
certificate and vice versa)
o Ciphersuite
authenticator has multiple ports and compression method
o TLS Master secret (known as the EAP-TLS Master Key)
o SA lifetime (ensuring that the SA AAA-Key caching is supported,
the EAP peer may not stored forever)
o If be able to determine the client scope of validity of
a AAA-Key. Similarly, where the EAP peer has multiple different credentials (certificates
and corresponding private keys), ports, the
authenticator may not be able to determine whether a pointer peer has
authorization to those credentials

When use a particular AAA-Key. To allow key scope
determination, the server initiates EAP-TLS, lower layer SHOULD provide a mechanism by which
the client peer can look up determine the EAP-TLS
SA based on scope of the credentials it was going to use (certificate and
private key), AAA-Key cache on each
authenticator, and by which the expected credentials (certificate or name) authenticator can determine the
scope of the server. If an EAP-TLS SA exists, and it is not too old, AAA-Key cache on a peer.

4.1. Key Caching

Key caching may be supported on the
client informs EAP peer, authenticator and
backend server. Where explicitly supported by the server about lower layer, the existence of this SA by including
its Session-Id in
EAP peer and authenticator MAY cache the TLS ClientHello message. AAA-Key and/or TSKs. The server then looks
up
structure of the correct SA based key cache on the Session-Id (or detects that it doesn't
yet have one).

3.1.2. Example: EAP-AKA

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

o Implicitly, authenticator is defined
by the EAP method this SA refers to (EAP-AKA) lower layer. Unless specified by the lower layer, the EAP

Aboba, et al. Informational Standards Track [Page 32] 31]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004

o A re-authentication pseudonym
o The client's permanent identity (IMSI)
o Replay protection counter
o Authentication key (K_aut)
o Encryption key (K_encr)
o Original Master Key (MK)
o SA lifetime (ensuring 18 February 2005

peer, authenticator and server MUST assume that the SA is peers and
authenticators do not stored forever)

When cache the AAA-Key or TSKs.

The EAP peer and server initiates EAP-AKA, MAY cache keys exported by the client can look up EAP method as
well as keys derived from them, subject to the EAP-AKA
SA based following
restrictions:

[1] In order to avoid key reuse, on the credentials EAP server, transported keys
are deleted once they are sent. An EAP server MUST NOT retain keys
that it was going has previously sent to use (permanent identity).
If the authenticator. For example, an EAP-AKA SA exists,
EAP server that has transported a AAA-Key based on the MSK MUST
delete both the AAA-Key and it is not too old, the client informs MSK, and no keys may be derived
from either the server about AAA-Key or the existence of this SA MSK from that point forward by sending its re-
authentication pseudonym the
server.

[2] Keys which are not transported, such as its identity in EAP Identity Response
message, instead of its permanent identity. The server then looks up the correct SA based EMSK, MAY be cached on this identity.

3.2. EAP-Key SA

This is an SA between
the peer and EAP server, which is used to store server. While AMSKs calculated from the keying material exported by EMSK MUST be
deleted from the EAP method. Current EAP server
implementations do not retain this SA after once they are transported, the EAP conversation
completes, but future implementations could use this SA for pre-
emptive key distribution.

Contents:

o MSK and parent
EMSK names
o MSK and EMSK
o SA lifetime

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

In order for may remain in the authenticator and backend authentication EAP server to
authenticate each other, they need to store some information.

In case cache.

4.2. Parent-Child Relationships

When keying material exported by EAP methods expires, all keying
material derived from the authenticator and backend authentication server are
colocated, and they communicate using local procedure calls or shared
memory, this SA need not necessarily contain any information.

3.3.1. Example: RADIUS

In RADIUS, where shared secret authentication is used, exported keying material expires, including
the client AAA-Key, AMSKs and
server store each other's IP address TSKs.

When an EAP reauthentication takes place, new keying material is
derived and exported by the shared secret, EAP method, which is
used to calculate eventually results in
replacement of calculated keys, including the Response Authenticator [RFC2865] and Message-
Authenticator [RFC3579] values, AAA-Key, AMSKs, and to encrypt some attributes (such
as
TSKs.

As a result, while the AAA-Key, see [RFC3580] Section 3.16).

Where IPsec is used lifetime of calculated keys can be less than
or equal that of the exported keys they are derived from, it cannot
be greater. For example, TSK rekey may occur prior to protect RADIUS [RFC3579] and IKE is used for

Aboba, et al. Informational [Page 33]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004

key management, the parties store information necessary
reauthentication.

Failure to
authenticate and authorize the other party (e.g. certificates, trust
anchors and names). The IKE mutually prove possession of the AAA-Key during the Secure
Association Protocol exchange results in IKE Phase 1 and Phase
2 SAs containing information used to protect need not be grounds for deletion of the conversation
(session keys, selected ciphersuite, etc.)

3.3.2. Example: Diameter with TLS

When using Diameter protected
AAA-Key by TLS, the parties store information
necessary both parties; rate-limiting Secure Association Protocol
exchanges could be used to authenticate and authorize the other party (e.g.
certificates, trust anchors and names). The TLS handshake results in prevent a short-term TLS SA that contains information brute force attack.

4.3. Local Key Lifetimes

The Transient EAP Keys (TEKs) are session keys used to protect the
actual communications (session keys, selected TLS ciphersuite, etc.).

3.4. Service SA(s) (peer - authenticator)
EAP conversation. The service SAs store information about the service being provided.
These include TEKs are internal to the Root service SA and derived unicast EAP method and multicast
service SAs.

The Root service SA is established as are
not exported. TEKs are typically created during an EAP conversation,
used until the result end of the completion of
EAP authentication (phase 1a) conversation and AAA-Key derivation then discarded. However,
methods may rekey TEKs during a conversation.

Aboba, et al. Standards Track [Page 32]

INTERNET-DRAFT EAP Key Management Framework 18 February 2005

When using TEKs within an EAP conversation or transport
(phase 1b). It includes:

o Service parameters (or at least those parameters across conversations,
it is necessary to ensure that replay protection and key separation
requirements are still needed)
o On the authenticator, service authorization
information received from the backend authentication
server (or necessary parts fulfilled. For instance, if a replay counter is
used, TEK rekey MUST occur prior to wrapping 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 counter.
Similarly, TSKs MUST remain cryptographically separate from TEKs
despite TEK rekeying or for another reason)
o AAA-Key lifetime

Unicast and (optionally) multicast service SAs are derived caching. This prevents TEK compromise from
leading directly to compromise of the
Root service SA, via the Secure Association Protocol. In order for
unicast and multicast service SAs and associated TSKs to be
established, it is not necessary and vice versa.

EAP methods may cache local keying material which may persist for
multiple EAP authentication (phase 1a) to
be rerun each time. Instead, the Secure Association Protocol can be conversations when fast reconnect is used to mutually prove possession of the AAA-Key and create
associated unicast (phase 2a) and multicast (phase 2b) service SAs
and TSKs, enabling the [RFC 3748].
For example, EAP exchange to be bypassed. Unicast methods based on TLS (such as EAP-TLS [RFC2716])
derive and
multicast service SAs include:

o Service parameters negotiated by cache the Secure Association Protocol.
o Endpoint identifiers.
o Transient Session Keys used to protect TLS Master Secret, typically for substantial
time periods. The lifetime of other local keying material calculated
within the communication.

Aboba, et al. Informational [Page 34]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004

o Transient Session Key lifetime.

One function of method is defined by the Secure Association Protocol method. Note that in
general, when using fast reconnect, there is no guarantee to bind that the
original long-term credentials are still in the
unicast and multicast service SAs and TSKs to endpoint identifiers. possession of the
peer. For example, within [IEEE802.11i], instance, a card hold holding the 4-way handshake binds private key for EAP-TLS
may have been removed. EAP servers SHOULD also verify that the TSKs long-
term credentials are still valid, such as by checking that
certificate used in the original authentication has not yet expired.

4.4. Exported and Calculated Key Lifetimes

All EAP methods generating keys are required to generate the MAC addresses of MSK and
EMSK, and may optionally generate the endpoints; IV. However, EAP, defined in [IKEv2],
[RFC3748], does not support the TSKs are bound
to negotiation of lifetimes for exported
keying material such as the IP addresses MSK, EMSK and IV.

Several mechanisms exist for managing key lifetimes:

[a] AAA attributes. AAA protocols such as RADIUS [RFC2865] and
Diameter [DiamEAP] support the Session-Timeout attribute. The
Session-Timeout value represents the maximum lifetime of the endpoints
exported keys, and all keys calculated from it. If the negotiated SPI.

It AAA server
caches exported keys, then it MUST expire the exported keys and all
keys calculated from them, no later than the future time indicated
by Session-Timeout.

On the authenticator, where EAP is possible used for more than one unicast or multicast service SA authentication, the
Session-Timeout value represents the maximum session time prior to
be derived from a single Root service SA. However, a unicast or
multicast service SA
re-authentication, as described in [RFC3580]. Where EAP is always descended from only one Root service
SA. Unicast or multicast service SAs descended from used
for pre-authentication, the same Root
service SA may utilize the same security parameters (e.g. mode,
ciphersuite, etc.) or they may utilize different parameters.

An EAP peer session may be able to negotiate multiple service SAs with a
given authenticator, not start until some future
time, or may be able to maintain one or more service
SAs with multiple authenticators, depending never occur. Nevertheless, the Session-Timeout value
represents the time after which the AAA-Key, and all keys
calculated from it, will have expired on the properties of authenticator. If the
media.

Except where explicitly specified by
session subsequently starts, re-authentication will be initiated
once the Secure Association Protocol, Session-Time has expired. If the session never started,
or started and ended, the AAA-Key and all keys calculated from it should not

Aboba, et al. Standards Track [Page 33]

INTERNET-DRAFT EAP Key Management Framework 18 February 2005

will be assumed that expired by the installation of new service SAs
implies deletion of old service SAs. It is possible for multicast
Root service SAs authenticator prior to between the same EAP peer 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 authenticator;
during a re-key by the principle of a unicast or multicast service SA ciphersuite independence, it is possible
not appropriate for two service SAs the AAA server to exist during manage any aspect of the period TSK
derivation process, including the TSK lifetime.

[b] Lower layer mechanisms. While AAA attributes can communicate the
maximum exported key lifetime, this only serves to synchronize the
key lifetime between when the new
service SA and corresponding TSKs are calculated backend authentication server and when they are
installed.

Similarly, deletion or creation of a unicast or multicast service SA
does not necessarily imply deletion or creation of related unicast or
multicast service SAs, unless specified by the Secure Association
protocol. For example, a unicast service SA may
authenticator. Lower layer mechanisms can then be rekeyed without
implying a rekey of the multicast service SA.

The deletion of the Root service SA does not necessarily imply used to enable
the
deletion lifetime of the derived unicast and multicast service SAs exported and
associated TSKs. Failure calculated keys to mutually prove possession of be negotiated
between the AAA-Key
during peer and authenticator.

Where TSKs are established as the result of a Secure Association
Protocol exchange need not be grounds
for deletion of the AAA-Key by both parties; the action to be taken exchange, it is defined by RECOMMENDED that the Secure Association Protocol.

3.4.1. Example: 802.11i

[IEEE802.11i] Section 8.4.1.1 defines
Protocol include support for TSK resynchronization. Where the security associations used
within IEEE 802.11. A summary follows; TSK
is taken from the standard should be
consulted for details.

Aboba, et al. Informational [Page 35]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004

o Pairwise Master Key Security Association (PMKSA)

The PMKSA AAA-Key, there is no need to manage the TSK
lifetime as a bi-directional SA, used
by both parties for sending
and receiving. The PMKSA is separate parameter, since the Root Service SA. It is created
on TSK lifetime and AAA-
Key lifetime are identical.

[c] System defaults. Where the peer when EAP authentication completes successfully or method does not support the
negotiation of the exported key lifetime, and a
pre-shared key lifetime
negotiation mechanism is configured. The PMKSA is created on not provided by the
authenticator when lower lower, there may
be no way for the PMK is received or created on peer to learn the
authenticator or a pre-shared exported key liftime. In this
case it is configured. The PMKSA is
used to create RECOMMENDED that the PTKSA. PMKSAs are cached for their lifetimes.
The PMKSA consists peer assume a default value of the following elements:

- PMKID (security association identifier)
- Authenticator MAC address
- PMK
- Lifetime
- Authenticated Key Management Protocol (AKMP)
- Authorization parameters specified by
exported key lifetime; 8 hours is suggested. Similarly, the AAA server or
by local configuration. This
lifetime of calculated keys can include
parameters such also be managed as a system
parameter on the peer's authorized SSID.
On the peer, this information can be locally
configured.
- authenticator.

4.5. 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 cache synchronization

Issues arise when a new four-way handshake is done
- Reference attempting to accounting context, synchronize the details of which depend key cache on the accounting protocol used, the implementation
and administrative details. In RADIUS, this could include
(e.g. packet and octet counters, peer
and Acct-Multi-Session-Id).

o Pairwise Transient Key Security Association (PTKSA)

The PTKSA authenticator. Lifetime negotiation alone cannot guarantee key
cache synchronization.

One problem is a bi-directional SA created as that the result AAA protocol cannot guarantee synchronization
of a
successful four-way handshake. The PTKSA is a unicast service SA.
There may only be one PTKSA key lifetimes between a pair of the peer and
authenticator MAC addresses. PTKSAs are cached for authenticator. Where the lifetime
of the PMKSA. Since the PTKSA
Secure Association Protocol is tied to the PMKSA, it only has not run immediately after EAP
authentication, the additional information from exported and calculated key lifetimes will not be
known by the 4-way handshake. The PTKSA
consists of peer during the following:

- Key (PTK)
- Selected ciphersuite
- MAC addresses of hiatus. Where EAP pre-authentication
occurs, this can leave the parties
- Replay counters, and ciphersuite specific state
- Reference peer uncertain whether a subsequent
attempt to PMKSA: This use the exported keys will prove successful.

However, even where the Secure Association Protocol is needed when:
o A new four-way handshake run
immediately after EAP, it is needed (lifetime, TKIP
countermeasures), and we need to know which PMKSA still possible for the authenticator to use

Aboba, et al. Informational Standards Track [Page 36] 34]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004

o Group Transient Key Security Association (GTKSA)

The GTKSA is a uni-directional SA 18 February 2005

reclaim resources if the created based on key state is not immediately
utilized.

The lower layer may utilize Discovery mechanisms to assist in this.
For example, the four-way
handshake or authenticator manages the group AAA-Key cache by deleting
the oldest AAA-Key first (LIFO), the relative creation time of the
last AAA-Key to be deleted could be advertised with the Discovery
phase, enabling the peer to determine whether a given AAA-Key had
been expired from the authenticator key handshake. The GTKSA cache prematurely.

4.6. Key Scope Issues

As described in Section 2.3, the AAA-Key is a multicast
service SA. A GTKSA consists of calculated from the following:

- Direction vector (whether EMSK
and MSK by the GTK EAP peer and server, and is used for transmit or receive)
- Group cipher suite selector
- Key (GTK)
- Authenticator MAC address
- Via reference to PMKSA, or copied here:
o Authorization parameters
o Reference to accounting context

3.4.2. Example: IKEv2/IPsec

Note that this example is intended to be informative, and it does not
necessarily include all information stored.

o IKEv2 SA

- Protocol version
- Identities as the root 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
ciphersuite-specific key hierarchy. Where a backend authentication
server is present, the authenticator, service authorization information
received AAA-Key is transported from the backend authentication server.

When processing an incoming message, EAP server to
the correct SA authenticator; where it is looked up based
on not present, the SPIs.

o IPsec SAs/SPD

- Traffic selectors
- Replay protection counters
- Selected ciphersuite
- IPsec SPI
- Keys
- Lifetime information
- Protocol mode (tunnel or transport)

The correct SA AAA-Key is looked up based calculated
on SPI (for inbound packets), or
SPD traffic selectors (for outbound traffic). A separate IPsec SA
exists for each direction.

Aboba, et al. Informational [Page 37]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004

3.4.3. Sharing service SAs

A single service may be provided by multiple logical or physical
service elements. Each service is responsible for specifying the authenticator.

Regardless of how
changing service elements is handled. Some approaches include:

Transparent sharing
If many sessions are initiated using it, the service parameters visible to AAA-Key
scope is between the other party (either EAP peer
or authenticator) do not change, that calculates it, and the service can be moved without
requiring cooperation
authenticator that either calculates it (where no backend
authenticator is present) or receives it from the other party.

Whether such server (where a move
backend authenticator server is present).

It should be supported understood that an authenticator or used depends on
implementation and administrative considerations. For instance, 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
administrator EAP peer with multiple ports may decide be
attached to configure one or more authenticators, each with multiple ports.
Where the peer and authenticator identify themselves using a group port
identifier such as a link layer address, it may not be obvious to the
peer which authenticator ports are associated with which
authenticators. Similarly, it may not be obvious to the
authenticator which peer ports are associated with which peers. As a
result, the peer and authenticator may not be able to determine the
scope of IKEv2/IPsec
gateways in the AAA-Key.

When a cluster for high-availability purposes, if single physical authenticator advertises itself as multiple
"virtual authenticators", the
implementation used supports this. The EAP peer does and authenticator also may not necessarily
have any way
be able to agree on the scope of knowing when the change occurs.

No sharing
If AAA-Key, creating a security
vulnerability. For example, the service parameters require changing, some changes peer may
require terminating assume that the old service, "virtual
authenticators" are distinct and starting do not share a new
conversation from phase 0. This approach is used by all services
for at least some parameters, and it doesn't require any protocol
for transferring key cache, whereas,

Aboba, et al. Standards Track [Page 35]

INTERNET-DRAFT EAP Key Management Framework 18 February 2005

depending on the service SA between architecture of the service elements.

The service physical AP, a shared key cache
may support keeping the old service element active
while the new conversation takes phase, to decrease the time the
service is not available.

Some sharing
The service or may allow changing some parameters by simply agreeing
about not be implemented.

Where the new values. This may involve a similar exchange AAA-Key is shared between "virtual authenticators" an
attacker acting as in
phase 2, or perhaps a shorter conversation.

This option usually requires some protocol for transferring the
service SA between peer could authenticate with the elements. An administrator may decide not to
enable this feature at all, "Guest"
"virtual authenticator" and typically the sharing is restricted
to some particular service elements (defined either by derive a service
parameter, or simple administrative decision). AAA-Key. If the old and new
service element do not support such "context transfer", this
approach falls back to virtual
authenticators share a key cache, then the previous option (no transfer).

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

Note that these considerations are not limited AAA-
Key derived for the "Guest" network to service
parameters related obtain access to the authenticator--they apply
"Corporate Intranet" virtual authenticator.

Several measures are recommended to peer's

Aboba, et al. Informational [Page 38]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004

parameters as well.

4. Handoff Support

With EAP, a number of mechanisms may be utilized in order address these issues:

[a] Authenticators are REQUIRED to reduce cache associated authorizations
along with the latency of handoff between authenticators. One such mechanism AAA-Key and apply authorizations consistently. This
ensures that an attacker cannot obtain elevated privileges even
where the AAA-Key cache is
EAP pre-authentication, in which EAP shared between "virtual authenticators".

[b] It is utilized to pre-establish a RECOMMENDED that physical authenticators maintain separate
AAA-Key on an authenticator prior caches for each "virtual authenticator".

[c] It is RECOMMENDED that each "virtual authenticator" identify itself
distinctly to arrival of the peer.

"Fast Handoff" is defined AAA server, such as by utilizing a conversation in which EAP exchange
(phase 1a) and associated distinct NAS-
identifier attribute. This enables the AAA pass-through server to utilize a
separate credential to authenticate each "virtual authenticator".

[d] It is bypassed, so 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 to
reduce latency. Unlike EAP pre-authentication, "Fast Handoff"
mechanisms do not result in additional identifiers is NOT RECOMMENDED where
peers and authenticators may support multiple ports.

[e] The AAA server load. Fast handoff
mechanisms include:

[a] Pre-emptive handoff. In this technique, and authenticator MAY implement additional
attributes in order to further restrict the AAA-Key scope. For
example, in 802.11, the AAA server pre-
establishes key state on may provide the authenticator prior to arrival
with a list of authorized Called or Calling-Station-Ids and/or
SSIDs for which the
peer, without completion of EAP authentication. As described in
[IEEE-03-084] and [I.D.irtf-aaaarch-handoff], this technique
includes conventional AAA-Key transport, but without an EAP
authentication.

[b] Context transfer. In this technique, the old authenticator
transfers is valid.

[f] Where the session text to AAA server provides attributes restricting the new authenticator, either prior
to, or after key scope,
it is RECOMMENDED that restrictions be securely communicated by the arrival of
authenticator to the peer. As a result, AAA-Key
transport (phase 1b) This is bypassed.

Regardless of how typically accomplished using
the AAA-Key is provisioned on a given
authenticator, AAA-Key caching may Secure Association Protocol, but also can be utilized in accomplished via
the EAP method or the lower layer.

4.7. Key Strength

In order to enable a
peer guard against brute force attacks, EAP methods deriving
keys need to quickly re-esta
blish a session be capable of generating keys with an authenticator.

Where appropriate
effective symmetric key caching is supported, once the AAA-Key is derived and/or
transported to the authenticator, it may remain cached on the peer
and authenticator, even after a subsequent session terminates. To
initiate a subsequent session with the same authenticator, the peer
may utilize the Secure Association Protocol strength. In order to confirm mutual
possession of the AAA-Key by the peer and authenticator, thereby re-
activating the AAA-Key for use in a subsequent session.

The introduction of handoff support introduces new security
vulnerabilities as well as requirements for the secure handling of
authorization context. These issues are discussed in the sections ensure that follow.

4.1. Authorization Issues

In a typical network access scenario (dial-in, wireless LAN, etc.)
access control mechanisms are typically applied. These mechanisms key

Aboba, et al. Informational Standards Track [Page 39] 36]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004

include user authentication as well as authorization for 18 February 2005

generation is not the offered
service. weakest link, it is RECOMMENDED that EAP
methods utilizing public key cryptography choose a public key that
has a cryptographic strength meeting the symmetric key strength
requirement.

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

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

4.8. Key Wrap

As described in [RFC3579] Section 4.3, known problems exist in the authentication process, the AAA network determines
key wrap specified in [RFC2548]. Where the user's authorization profile. The user authorizations are
transmitted same RADIUS shared secret
is used by the backend authentication server to the EAP a PAP authenticator (also and an EAP authenticator, there is a
vulnerability to known as plaintext attack. Since RADIUS uses the Network Access Server or
authenticator) included
shared secret for multiple purposes, including per-packet
authentication, attribute hiding, considerable information is exposed
about the shared secret with each packet. This exposes the AAA-Token, which also contains shared
secret to dictionary attacks. MD5 is used both to compute the
AAA-Key, in Phase 1b of RADIUS
Response Authenticator and the EAP conversation. Typically, Message-Authenticator attribute, and
some concerns exist relating to the profile
is determined security of this hash
[MD5Attack].

As discussed in [RFC3579] Section 4.3, the security vulnerabilities
of RADIUS are extensive, and therefore development of an alternative
key wrap technique based on the user identity, but RADIUS shared secret would not
substantially improve security. As a certificate presented
by the user may also provide authorization information. result, [RFC3759] Section 4.2
recommends running RADIUS over IPsec. The backend authentication server same approach is responsible for making a user
authorization decision, answering the following questions:

[a] Is this a legitimate user for this particular network?

[b] Is this user allowed the type of access he taken in
Diameter EAP [I-D.ietf-aaa-eap], which defines cleartext key
attributes, to be protected by IPsec or she TLS.

Where an untrusted AAA intermediary is requesting?

[c] Are there any specific parameters (mandatory tunneling, bandwidth,
filters, present (such as a RADIUS
proxy or a Diameter agent), and so on) that data object security is not used, the access network should
AAA-Key may be aware recovered by an attacker in control of for
this user?

[d] Is this user within the subscription rules regarding time untrusted
intermediary. Possession of day?

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

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

While the authorization decision is in principle simple, AAA-Key enables decryption of data
traffic sent between the process peer and a specific authenticator; however
where key separation is complicated by the distributed nature of AAA decision making.
Where brokering entities or proxies are involved, all implemented, compromise of the AAA
devices in the chain from AAA-Key does

Aboba, et al. Standards Track [Page 37]

INTERNET-DRAFT EAP Key Management Framework 18 February 2005

not enable an attacker to impersonate the authenticator peer to another
authenticator, since that requires possession of the home AAA server
are involved in the decision. For instance, a broker can disallow
access even if EMSK, which is
not transported by the home AAA server would allow it, or a proxy can add
authorizations (e.g., bandwidth limits).

Decisions can protocol. This vulnerability may be based on static policy definitions and profiles as
well as dynamic state (e.g. time
mitigated by implementation of day or limits on the redirect functionality, as provided in
[RFC3588].

5. Handoff Support

With EAP, a number of
concurrent sessions). In addition to the Accept/Reject decision made
by the AAA chain, parameters or constraints can mechanisms may be communicated utilized in order to reduce
the authenticator.

The criteria for Accept/Reject decisions or the reasons for choosing
particular authorizations are typically not communicated latency of handoff between authenticators. One such mechanism is
EAP pre-authentication, in which EAP is utilized to the
authenticator, only the final result. As pre-establish a result, the
AAA-Key on an authenticator
has no way prior to know what arrival of the decision was based on. Was peer.

"Fast Handoff" is defined as a set of

Aboba, et al. Informational [Page 40]

INTERNET-DRAFT conversation in which the EAP Key Management Framework 14 November 2004

authorization parameters sent because this service exchange
(phase 1a) and associated AAA pass-through is always provided bypassed, so as to
reduce latency. Fast handoff mechanisms include:

[a] Pre-emptive handoff. In this technique, the user, or was the decision based AAA server pre-
establishes key state on the time/day and the
capabilities of the requesting authenticator device?

4.2. Correctness Issues

Bypassing all or portions prior to arrival of the AAA conversation creates challenges
peer, without completion of EAP authentication. As described in ensuring that authorization is properly handled. These include:

[a] Consistent application of session time limits. A fast handoff
should not automatically increase
[IEEE-03-084] and [I.D.irtf-aaaarch-handoff], this technique
includes conventional AAA-Key transport, but without an EAP
authentication.

[b] Context transfer. In this technique, the old authenticator
transfers the available session time,
allowing a user text to endlessly extend their network access by
changing the point of attachment.

[b] Avoidance new authenticator, either prior
to, or after the arrival of privilege elevation. A fast handoff should not result
in the peer. As a user being granted access to services which they are not
entitled to. result, AAA-Key
transport (phase 1b) is bypassed.

[c] Consideration of dynamic state. Key Request. In situations this technique, the peer requests that the new
authenticator retrieve a named key from the EAP server for
potential use in which dynamic
state a forthcoming session. In this technique, EAP
authentication (phase 1a) is involved in the bypassed, but AAA-Key transport (phase
1b) is not.

5.1. Authorization

In a typical network access decision (day/time, simultaneous
session limit) it should be possible to take this state into
account either before or after scenario (dial-in, wireless LAN, etc.)
access is granted. Note that
consideration of network-wide state such as simultaneous session
limits can control mechanisms are typically only be taken into account by the backend applied. These mechanisms
include user authentication server.

[d] Encoding of restrictions. Since as well as authorization for the offered
service.

As a authenticator may not be aware part of the criteria considered authentication process, the AAA network determines
the user's authorization profile. The user authorizations are
transmitted by a the backend authentication server when
allowing access, in order to ensure consistent authorization during
a fast handoff it may be necessary to explicitly encode the
restrictions within the authorizations provided in the AAA-Token.

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

A fast handoff mechanism capable of addressing these concerns is said
to be "correct". One condition for correctness is as follows: For a
fast handoff to be "correct" it MUST establish on the new device the
same context EAP
authenticator (also known as would have been created had the new device completed
a AAA conversation Network Access Server or
authenticator) included with the authentication server.

A properly designed fast handoff scheme will only succeed if it is
"correct" in this way. If a successful fast handoff would establish
"incorrect" state, it is preferable for it to fail, AAA-Token, which also contains the
AAA-Key, in order to avoid
creation Phase 1b of incorrect context.

Some backend authentication server and authenticator configurations the EAP conversation. Typically, the profile

Aboba, et al. Informational Standards Track [Page 41] 38]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004

are incapable of meeting this definition of "correctness". For
example, if 18 February 2005

is determined based on the old and new device differ in their capabilities, it user identity, but a certificate presented
by the user may be difficult to meet also provide authorization information.

The backend authentication server is responsible for making a user
authorization decision, answering the following questions:

[a] Is this definition of correctness in a fast
handoff mechanism that bypasses AAA. Backend authentication servers
often perform conditional evaluation, in which legitimate user for this particular network?

[b] Is this user allowed the authorizations
returned in an Access-Accept message are contingent on the
authenticator type of access he or on dynamic state such as she is requesting?

[c] Are there any specific parameters (mandatory tunneling, bandwidth,
filters, and so on) that the access network should be aware of for
this user?

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

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

[f] Are there any fraud, credit limit, or number
of simultaneous sessions. For example, other concerns that indicate
that access should be denied?

While the authorization decision is in a heterogeneous
deployment, principle simple, the backend authentication server might return different
authorizations depending on process
is complicated by the authenticator making distributed nature of AAA decision making.
Where brokering entities or proxies are involved, all of the request, AAA
devices in
order to make sure that the requested service is consistent with chain from the authenticator capabilities.

If differences between to the new and old device would result home AAA server
are involved in the
backend authentication decision. For instance, a broker can disallow
access even if the home AAA server sending would allow it, or a different set 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 messages to day or limits on the new device than were sent number of
concurrent sessions). In addition to the old device, then if the fast
handoff mechanism bypasses AAA, then Accept/Reject decision made
by the fast handoff cannot AAA chain, parameters or constraints can be
carried out correctly.

For example, if some authenticator devices within a deployment
support dynamic VLANs while others do not, then attributes present in communicated to
the Access-Request (such as authenticator.

The criteria for Accept/Reject decisions or the authenticator-IP-Address,
authenticator-Identifier, Vendor-Identifier, etc.) could be examined reasons for choosing
particular authorizations are typically not communicated to determine when VLAN attributes will be returned, as described in
[RFC3580]. VLAN support is defined in [IEEE8021Q]. If a fast
handoff bypassing the backend authentication server were to occur
between
authenticator, only the final result. As a result, the 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
has no way to know what the
network.

Similarly, in decision was based on. Was a network where access set of
authorization parameters sent because this service is restricted always provided
to the user, or was the decision based on the day time/day and time, Service Set Identifier (SSID), Calling-Sta
tion-Id or other
factors, unless the restrictions are encoded within
capabilities of the
authorizations, requesting authenticator device?

5.2. Correctness

Bypassing all or a partial portions of the AAA conversation creates challenges
in ensuring that authorization is included, then a properly handled. These include:

Aboba, et al. Standards Track [Page 39]

INTERNET-DRAFT EAP Key Management Framework 18 February 2005

[a] Consistent application of session time limits. A fast handoff could result in
should not automatically increase the available session time,
allowing a user bypassing the restrictions.

In practice, these considerations limit to endlessly extend their network access by
changing the situations in which point of attachment.

[b] Avoidance of privilege elevation. A fast handoff mechanisms bypassing AAA can be expected should not result
in a user being granted access to be successful.
Where services which they are not
entitled to.

[c] Consideration of dynamic state. In situations in which dynamic
state is involved in the deployed devices implement access decision (day/time, simultaneous
session limit) it should be possible to take this state into
account either before or after access is granted. Note that
consideration of network-wide state such as simultaneous session
limits can typically only be taken into account by the same set backend
authentication server.

[d] Encoding of services, it restrictions. Since a authenticator may not be possible aware
of the criteria considered by a backend authentication server when
allowing access, in order to do successful ensure consistent authorization during
a fast handoffs handoff it may be necessary to explicitly encode the
restrictions within such mechanisms.
However, where the supported services differ between devices, authorizations provided in the AAA-Token.

[e] State validity. The introduction of fast handoff may not succeed. For example, [RFC2865] section 1.1
states:

"A authenticator that does should not implement a given service MUST NOT
implement render
the RADIUS attributes authentication server incapable of keeping track of network-
wide state.

A fast handoff mechanism capable of addressing these concerns is said
to be "correct". One condition for that service. correctness is as follows: For example, a
authenticator that is unable
fast handoff to offer ARAP service be "correct" it MUST NOT

Aboba, et al. Informational [Page 42]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004

implement establish on the RADIUS attributes for ARAP. A authenticator MUST
treat a RADIUS access-accept authorizing an unavailable service new device the
same context as
an access-reject instead."

Note that this behavior only applies to attributes that are known,
but not implemented. For attributes that are unknown, [RFC2865]
Section 5 states:

"A RADIUS server MAY ignore Attributes with an unknown Type. A
RADIUS client MAY ignore Attributes with an unknown Type."

In order to perform a correct fast handoff, if a would have been created had the 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 completed
a
RADIUS Access-Accept requesting an unavailable service. This MUST
cause AAA conversation with the authentication server.

A properly designed fast handoff to fail. However, scheme will only succeed if a new device is provided
with RADIUS context that indicates an unknown attribute, then this
attribute MAY be ignored.

Although it may seem somewhat counter-intuitive, failure is indeed
the
"correct" result where in this way. If a known but unsupported service successful fast handoff would establish
"incorrect" state, it is
requested. Presumably a correctly configured preferable for it to fail, in order to avoid
creation of incorrect context.

Some backend authentication server would not request that a device carry out a service that it
does not implement. This implies that and authenticator configurations
are incapable of meeting this definition of "correctness". For
example, if the old and new device were to
complete a AAA conversation that differ in their capabilities, it would
may be likely difficult to receive
different service instructions. In such a case, failure meet this definition of the correctness in a fast
handoff is the desired result. This will cause the new device to go
back to the AAA server mechanism that bypasses AAA. Backend authentication servers
often perform conditional evaluation, in order to receive which the appropriate service
definition.

In practice, this implies that fast handoff mechanisms which bypass
AAA authorizations
returned in an Access-Accept message are most likely to be successful within a homogeneous device
deployment within a single administrative domain. For example, it
would not be advisable to carry out a fast handoff bypassing AAA
between a authenticator providing confidentiality and another contingent on the
authenticator that does not support this service. The correct result
of or on dynamic state such a fast handoff would be a failure, since if the handoff were
blindly carried out, then as the user would be moved from time of day or number
of simultaneous sessions. For example, in a secure to an
insecure channel without permission from heterogeneous
deployment, the backend authentication
server. Thus the definition of a "known but unsupported service"
MUST encompass requests for unavailable security services. This
includes vendor-specific attributes related to security, such as
those described in [RFC2548]. server might return different

Aboba, et al. Informational Standards Track [Page 43] 40]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004

5. Security Considerations

5.1. Security Terminology

"Cryptographic binding", "Cryptographic separation", "Key strength"
and "Mutual authentication" are defined in [RFC3748] and are used
with 18 February 2005

authorizations depending on the same meaning here.

5.2. Threat Model

The EAP threat model is described authenticator making the request, in [RFC3748] Section 7.1. In
order to address these threats, EAP relies on make sure that the security properties of
EAP methods (known as "security claims", described requested service is consistent with the
authenticator capabilities.

If differences between the new and old device would result in [RFC3784]
Section 7.2.1). EAP method requirements for application such as
Wireless LAN the
backend authentication are described in [WLANREQ].

The RADIUS threat model is described server sending a different set of messages to
the new device than were sent to the old device, then if the fast
handoff mechanism bypasses AAA, then the fast handoff cannot be
carried out correctly.

For example, if some authenticator devices within a deployment
support dynamic VLANs while others do not, then attributes present in [RFC3579] Section 4.1, and
responses
the Access-Request (such as the authenticator-IP-Address,
authenticator-Identifier, Vendor-Identifier, etc.) could be examined
to these threats are determine when VLAN attributes will be returned, as described in [RFC3579] Sections 4.2
and 4.3. Among other things, [RFC3579] Section 4.2 recommends
[RFC3580]. VLAN support is defined in [IEEE8021Q]. If a fast
handoff bypassing the
use of IPsec ESP with non-null transform to provide per-packet backend authentication server were to occur
between a authenticator supporting dynamic VLANs and confidentiality, integrity and replay protection
for RADIUS/EAP.

Given another
authenticator which does not, then a guest user with access
restricted to a guest VLAN could be given unrestricted access to the existing documentation of EAP
network.

Similarly, in a network where access is restricted based on the day
and time, Service Set Identifier (SSID), Calling-Station-Id or other
factors, unless the restrictions are encoded within the
authorizations, or a partial AAA threat models and
responses, there conversation is no need to duplicate that material here.
However, there are many other system-level threats no covered included, then a
fast handoff could result in the user bypassing the restrictions.

In practice, these document considerations limit the situations in which have not been described or analyzed elsewhere.
These include:

[1] An attacker may try to modify 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 fast
handoff mechanisms (such as via a bypassing AAA or lower layer protocol). This
includes impersonating another authenticator, or providing
inconsistent information can be expected to be successful.
Where the peer and EAP server.

[3] An attacker deployed devices implement the same set of services, it may attempt
be possible to perform downgrading attacks on the
ciphersuite negotiation do successful fast handoffs within such mechanisms.
However, where the Secure Association Protocol in
order to ensure supported services differ between devices, the
fast handoff may not succeed. For example, [RFC2865] section 1.1
states:

"A authenticator that does not implement a weaker ciphersuite given service MUST NOT
implement the RADIUS attributes for that service. For example, a
authenticator that is used unable to protect data.

Depending on offer ARAP service MUST NOT
implement the lower layer, these attacks may be carried out
without requiring physical proximity.

In order RADIUS attributes for ARAP. A authenticator MUST
treat a RADIUS access-accept authorizing an unavailable service as
an access-reject instead."

Note that this behavior only applies to address these threats, [Housley56] describes the
mandatory system security properties: 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

Aboba, et al. Informational Standards Track [Page 44] 41]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004

Algorithm independence
Wherever cryptographic algorithms are chosen, the algorithms must
be negotiable, in 18 February 2005

RADIUS client MAY ignore Attributes with an unknown Type."

In order to provide resilient against compromise of perform a particular algorithm. Algorithm independence must be
demonstrated within all aspects of the system, including within
EAP, AAA and the Secure Association Protocol. However, correct fast handoff, if a new device is
provided with RADIUS context for
interoperability, at least one suite of algorithms a known but unavailable service,
then it MUST be
implemented.

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

Replay protection
All protocol exchanges must be replay protected. way it would handle a
RADIUS Access-Accept requesting an unavailable service. This includes
exchanges within EAP, AAA, and MUST
cause the Secure Association Protocol.

Authentication
All parties need fast handoff to be authenticated. The confidentiality of the
authenticator must be maintained. No plaintext passwords are
allowed.

Authorization
EAP peer and authenticator authorization must be performed.

Session keys
Confidentiality of session keys must be maintained.

Ciphersuite negotiation
The selection of the "best" ciphersuite must be securely confirmed.

Unique naming
Session keys must be uniquely named.

Domino effect
Compromise of fail. However, if a single authenticator cannot compromise any other
part of the system, including session keys and long-term secrets.

Key binding
The key must new device is provided
with RADIUS context that indicates an unknown attribute, then this
attribute MAY be bound to the appropriate context.

5.3. Security Analysis

Figure 6 illustrates the relationship between ignored.

Although it may seem somewhat counter-intuitive, failure is indeed
the peer, authenticator
and "correct" result where a known but unsupported service is
requested. Presumably a correctly configured backend authentication server.

Aboba, et al. Informational [Page 45]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004

EAP peer
/\
/ \
Protocol: EAP / \ Protocol: Secure Association
Auth: Mutual / \ Auth: Mutual
Unique keys: / \ Unique keys: TSKs
TEKs,EMSK / \
/
\
EAP server +--------------+ Authenticator
Protocol: AAA
Auth: Mutual
Unique key: AAA session key

Figure 6: Relationship between peer, authenticator and auth. server

The peer and EAP
server communicate using EAP [RFC3748]. The
security properties of this communication are largely determined by
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 and channel binding claims. At would not request that a
minimum, methods claiming to support key derivation must also support
mutual authentication. As noted in [RFC3748] Section 7.10:

EAP Methods deriving keys MUST provide for mutual authentication
between the EAP peer and device carry out a service that it
does not implement. This implies that if the EAP Server.

Ciphersuite independence is also required:

Keying material exported by EAP methods MUST new device were to
complete a AAA conversation that it would be independent of the
ciphersuite negotiated likely to protect data. receive
different service instructions. In terms such a case, failure of key strength and freshness, [RFC3748] Section 10 says:

EAP methods SHOULD ensure the freshness of fast
handoff is the MSK and EMSK even desired result. This will cause the new device to go
back to the AAA server in cases where one party may not have a high quality random number
generator.... In order to preserve algorithm independence, EAP
methods deriving keys SHOULD support (and document) receive the protected
negotiation appropriate service
definition.

In practice, this implies that fast handoff mechanisms which bypass
AAA are most likely to be successful within a homogeneous device
deployment within a single administrative domain. For example, it
would not be advisable to carry out a fast handoff bypassing AAA
between a authenticator providing confidentiality and another
authenticator that does not support this service. The correct result
of such a fast handoff would be a failure, since if the ciphersuite used handoff were
blindly carried out, then the user would be moved from a secure to protect an
insecure channel without permission from the EAP
conversation between backend authentication
server. Thus the peer definition of a "known but unsupported service"
MUST encompass requests for unavailable security services. This
includes vendor-specific attributes related to security, such as
those described in [RFC2548].

6. Security Considerations

6.1. Security Terminology

"Cryptographic binding", "Cryptographic separation", "Key strength"
and server... "Mutual authentication" are defined in [RFC3748] and are used
with the same meaning here.

6.2. Threat Model

The EAP threat model is described in [RFC3748] Section 7.1. In order
to enable
deployments requiring strong keys, address these threats, EAP methods supporting key
derivation SHOULD be capable of generating an MSK and EMSK, each
with an effective key strength relies on the security properties of at least 128 bits.

The authenticator and backend authentication server communicate using
a AAA protocol such
EAP methods (known as RADIUS [RFC3579] or Diameter [I-D.ietf-aaa- "security claims", described in [RFC3784]

Aboba, et al. Informational Standards Track [Page 46] 42]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004

eap]. As noted 18 February 2005

Section 7.2.1). EAP method requirements for application such as
Wireless LAN authentication are described in [RFC3588] [WLANREQ].

The RADIUS threat model is described in [RFC3579] Section 13, Diameter must be protected
by either IPsec ESP with non-null transform or TLS. As a result,
Diameter requires per-packet integrity 4.1, and confidentiality. Replay
protection must be supported. For RADIUS,
responses to these threats are described in [RFC3579] Sections 4.2
and 4.3. Among other things, [RFC3579] Section 4.2 recommends that RADIUS be protected by the
use of IPsec ESP with a non-null
transform, transform to provide per-packet
authentication and confidentiality, integrity and where IPsec is implemented replay protection must be
supported.

The peer and authenticator communicate using the Secure Association
Protocol.

As noted in the figure, each party in
for RADIUS/EAP.

Given the exchange mutually
authenticates with each existing documentation of the other parties, EAP and derives a unique
key. All parties AAA threat models and
responses, there is no need to duplicate that material here.
However, there are many other system-level threats no covered in the diagram
these document which have access not been described or analyzed elsewhere.
These include:

[1] An attacker may try to modify or spoof Secure Association Protocol
packets.

[2] An attacker compromising an authenticator may provide incorrect
information to the AAA-Key.

The EAP peer and backend authentication and/or server mutually authenticate via the EAP method, and derive the TEKs and EMSK which are known only
to them. The TEKs are used to protect some out-of-band
mechanisms (such as via a AAA or all of the EAP
conversation between lower layer protocol). This
includes impersonating another authenticator, or providing
inconsistent information to the peer and authenticator, so as to guard
against modification or insertion of EAP packets by an attacker. The
degree of protection afforded by server.

[3] An attacker may attempt to perform downgrading attacks on the TEKs is determined by
ciphersuite negotiation within the EAP
method; some methods may Secure Association Protocol in
order to ensure that a weaker ciphersuite is used to protect data.

Depending on the entire EAP packet, including the
EAP header, while other methods lower layer, these attacks may only protect be carried out
without requiring physical proximity.

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

Algorithm independence
Wherever cryptographic algorithms are chosen, the
Type-Data field, defined algorithms must
be negotiable, in [RFC3748].

Since EAP is spoken only between the EAP peer and server, if order to provide resilient against compromise of
a
backend authentication server is present then particular algorithm. Algorithm independence must be
demonstrated within all aspects of the EAP conversation
does not provide mutual authentication between system, including within
EAP, AAA and the peer 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 and
authenticator, only between fresh in all
circumstances, while at the same time retaining algorithm
independence.

Aboba, et al. Standards Track [Page 43]

INTERNET-DRAFT EAP peer Key Management Framework 18 February 2005

Replay protection
All protocol exchanges must be replay protected. This includes
exchanges within EAP, AAA, and EAP server (backend
authentication server). As a result, mutual authentication between the peer and authenticator only occurs where a Secure Association
protocol is used, such the unicast and group key derivation handshake
supported in [IEEE80211i]. This means that absent use of a secure
Association Protocol, from the point of view Protocol.

Authentication
All parties need to be authenticated. The confidentiality of the peer,
authenticator must be maintained. No plaintext passwords are
allowed.

Authorization
EAP mutual
authentication only proves that the peer and authenticator is trusted by the
backend authentication server; the identity authorization must be performed.

Session keys
Confidentiality of the authenticator is
not confirmed.

Utilizing the AAA protocol, 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. must be maintained.

Ciphersuite negotiation
The AAA-Key is
distributed by the backend authentication server to the authenticator
over this channel, bound to attributes constraining its usage, as
part selection of the AAA-Token. The binding "best" ciphersuite must be securely confirmed.

Unique naming
Session keys must be uniquely named.

Domino effect
Compromise of attributes to the AAA-Key
within a protected package is important so the single authenticator
receiving cannot compromise any other
part of the AAA-Token can determine that it has not been
compromised, system, including session keys and that the keying material has not been replayed, or

Aboba, et al. Informational [Page 47]

INTERNET-DRAFT EAP long-term secrets.

Key Management Framework 14 November 2004

mis-directed in some way. binding
The security properties of key must be bound to the EAP exchange are dependent on each leg
of appropriate context.

6.3. Security Analysis

Figure 6 illustrates the triangle: relationship between the selected EAP method, AAA protocol peer, authenticator
and the backend authentication server.

EAP peer
/\
/ \
Protocol: EAP / \ Protocol: Secure Association Protocol.

Assuming that the
Auth: Mutual / \ Auth: Mutual
Unique keys: / \ Unique keys: TSKs
TEKs,EMSK / \
/ \
EAP server +--------------+ Authenticator
Protocol: 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
Auth: Mutual
Unique key: AAA intermediary is present, the AAA-Token must
not be provided to the intermediary so as to avoid compromise session key

Figure 6: Relationship between peer, authenticator and auth. server

Aboba, et al. Standards Track [Page 44]

INTERNET-DRAFT EAP Key Management Framework 18 February 2005

The peer and EAP server communicate using EAP [RFC3748]. The
security properties of the
AAA-Token. This can be avoided this communication are largely determined by use of re-direct as defined in
[RFC3588].

When 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. chosen EAP methods defined method. Method security claims are described in
[RFC3748] reflect this usage model. Section 7.2. These include EAP MD5, as well as One-Time Password (OTP) 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 and Generic
Token Card. These channel binding claims. At a
minimum, methods support one-way authentication (from EAP
peer claiming to authenticator) but not mutual authentication or support key
derivation. derivation must also support
mutual authentication. As a result, these methods do not bind the initial noted in [RFC3748] Section 7.10:

EAP Methods deriving keys MUST provide for mutual authentication
between the EAP peer and subsequent data traffic, even when the EAP Server.

Ciphersuite independence is also required:

Keying material exported by EAP methods MUST be independent of the
ciphersuite used negotiated to protect data supports per-packet authentication data.

In terms of key strength and integrity protection. As a result, freshness, [RFC3748] Section 10 says:

EAP methods not supporting
mutual authentication are vulnerable to session hijacking as well as
attacks by rogue devices.

On wireless networks such as IEEE 802.11 [IEEE80211], these attacks
become easy to mount, since any attacker within range can access SHOULD ensure the
wireless medium, or act as an access point. As a result, new
ciphersuites have been proposed for use with wireless LANs
[IEEE80211i] which provide per-packet authentication, integrity freshness of the MSK and
replay protection. EMSK even
in cases where one party may not have a high quality random number
generator.... In addition, mutual authentication and key
derivation, provided by methods such as EAP-TLS [RFC2716] are
required [IEEE80211i], so as order to address preserve algorithm independence, EAP
methods deriving keys SHOULD support (and document) the threat protected
negotiation of rogue devices,
and provide keying material to bind the initial authentication ciphersuite used to
subsequent data traffic.

If protect the selected EAP method does not support mutual authentication,
then
conversation between the peer will be vulnerable to attack by rogue authenticators and backend authentication servers. If the EAP method does not derive server... In order to enable
deployments requiring strong keys, then TSKs will not EAP methods supporting key
derivation SHOULD be available for use capable of generating an MSK and EMSK, each
with an effective key strength of at least 128 bits.

The authenticator and backend authentication server communicate using
a negotiated
ciphersuite, AAA protocol such as RADIUS [RFC3579] or Diameter [I-D.ietf-aaa-
eap]. As noted in [RFC3588] Section 13, Diameter must be protected
by either IPsec ESP with non-null transform or TLS. As a result,
Diameter requires per-packet integrity and there will confidentiality. Replay
protection must be no binding between supported. For RADIUS, [RFC3579] Section 4.2
recommends that RADIUS be protected by IPsec ESP with a non-null
transform, and where IPsec is implemented replay protection must be
supported.

The peer and authenticator communicate using the initial EAP
authentication Secure Association
Protocol.

As noted in the figure, each party in the exchange mutually
authenticates with each of the other parties, and subsequent data traffic, leaving derives a unique
key. All parties in the session diagram have access to the AAA-Key.

Aboba, et al. Informational Standards Track [Page 48] 45]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004

vulnerable to hijac
k.

If the 18 February 2005

The EAP peer and backend authentication server does not protect against
authenticator masquerade, or provide the proper binding of the AAA-
Key to mutually authenticate
via the session within EAP method, and derive the AAA-Token, then one or more AAA-Keys
may be sent to an unauthorized party, TEKs and an attacker may be able EMSK which are known only
to
gain access them. The TEKs are used to protect some or all of the network. If EAP
conversation between the AAA-Token is provided peer and authenticator, so as to guard
against modification or insertion of EAP packets by an
untrusted AAA intermediary, then that intermediary attacker. The
degree of protection afforded by the TEKs is determined by the EAP
method; some methods may be able to
modify protect the AAA-Key, or entire EAP packet, including the attributes associated with it, as
described in [RFC2607].

If
EAP header, while other methods may only protect the Secure Association Protocol does not provide mutual proof of
possession contents of the AAA-Key material, then the peer will not have
assurance that it
Type-Data field, defined in [RFC3748].

Since EAP is connected to the correct authenticator, spoken only
that between the authenticator EAP peer and backend authentication server share server, if a
trust relationship (since AAA protocols support mutual
authentication). This distinction can become important when multiple
authenticators receive AAA-Keys from the
backend authentication
server, such as where fast handoff server is supported. If present then the TSK
derivation EAP conversation
does not provide for protected ciphersuite and
capabilities negotiation, then downgrade attacks are possible.

5.4. Man-in-the-middle Attacks

As described in [I-D.puthenkulam-eap-binding], EAP method sequences
and compound mutual 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 peer and
authenticator, as well as to obtain access to the network.

In order to prevent these attacks, [I-D.puthenkulam-eap-binding]
recommends derivation of a compound key by which only between the EAP peer and EAP server can prove that they have participated in (backend
authentication server). As a result, mutual authentication between
the entire EAP
exchange. Since peer and authenticator only occurs where a Secure Association
protocol is used, such the compound unicast and group key must not be known to an attacker
posing as an authenticator, and yet must be derived derivation handshake
supported in [IEEE80211i]. This means that absent use of a secure
Association Protocol, from quantities the point of view of the peer, EAP mutual
authentication only proves that are exported the authenticator is trusted by EAP methods, it may be desirable to derive the
compound key from a portion
backend authentication server; the identity of the EMSK. In order authenticator is
not confirmed.

Utilizing the AAA protocol, the authenticator and backend
authentication server mutually authenticate and derive session keys
known only to them, used to provide proper
key hygiene, it per-packet integrity and replay
protection, authentication and confidentiality. The AAA-Key is recommended that
distributed by the compound key used for man-in-
the-middle protection be cryptographically separate from other keys
derived from backend authentication server to the EMSK, such authenticator
over this channel, bound to attributes constraining its usage, as fast handoff keys, discussed in
Section 2.5.

5.5. Denial
part of Service Attacks the AAA-Token. The caching binding of security associations may result in vulnerability attributes to
denial of service attacks. Since an EAP peer may derive multiple EAP
SAs with a given EAP server, and creation of the AAA-Key
within a new EAP SA does protected package is important so the authenticator
receiving the AAA-Token can determine that it has not

Aboba, et al. Informational [Page 49]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004

implicitly delete a previous EAP SA, EAP methods been
compromised, and that result the keying material has not been replayed, or
mis-directed in
creation of persistent state may be vulnerable to denial some way.

The security properties of service
attacks by a rogue EAP peer.

As a result, EAP methods creating persistent state may wish to limit the number of cached EAP SAs (Phase 1a) corresponding to an EAP peer.
For example, an EAP server may choose to only retain a few EAP SAs
for exchange are dependent on each peer. 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 leg
of cached AAA-Key (Phase
1 b) SAs for each peer.

Depending on the media, creation of a new unicast Secure Association
SA may or may not imply deletion of a previous unicast secure
association SA. Where there is no implied deletion, triangle: the
authenticator may choose to limit Phase 2 (unicast selected EAP method, AAA protocol and multicast) the Secure
Association SAs for each peer.

5.6. Impersonation

Both Protocol.

Assuming that the RADIUS 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 Diameter protocols are potentially vulnerable where it is
wrapped appropriately, it can be assumed to
impersonation be immune to compromise
by a rogue authenticator.

While snooping attacker.

Where an untrusted AAA protocols such as RADIUS [RFC2865] or Diameter [RFC3588]
support mutual authentication between the authenticator (known as intermediary is present, the
AAA client) and AAA-Token must
not be provided to the backend authentication server (known intermediary so as the AAA
server), the security mechanisms vary according to avoid compromise of the AAA protocol.

In RADIUS, the shared secret used for authentication is determined
AAA-Token. This can be avoided by
the source address use of the RADIUS packet. As noted re-direct as defined in [RFC3579]
Section 4.3.7,

Aboba, et al. Standards Track [Page 46]

INTERNET-DRAFT EAP Key Management Framework 18 February 2005

[RFC3588].

When EAP is used for authentication on PPP or wired IEEE 802
networks, it is highly desirable typically assumed that the source address be
checked against one or more NAS identification attributes link is physically secure,
so as that an attacker cannot gain access to
detect and prevent impersonation attacks.

When RADIUS requests are forwarded by a proxy, the NAS-IP-Address link, or
NAS-IPv6-Address attributes may not correspond insert a rogue
device. EAP methods defined in [RFC3748] reflect this usage model.
These include EAP MD5, as well as One-Time Password (OTP) and Generic
Token Card. These methods support one-way authentication (from EAP
peer to the source address.
Since the NAS-Identifier attribute need authenticator) but not contain an FQDN, it also
may mutual authentication or key
derivation. As a result, these methods do not correspond to bind the source address, initial
authentication and subsequent data traffic, even indirectly. [RFC2865]
Section 3 states:

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

This implies that it is possible for protect data supports per-packet authentication
and integrity protection. As a rogue authenticator to forge

Aboba, et al. Informational [Page 50]

INTERNET-DRAFT result, EAP Key Management Framework 14 November 2004

NAS-IP-Address, NAS-IPv6-Address or NAS-Identifier attributes within
a RADIUS Access-Request in order methods not supporting
mutual authentication are vulnerable to impersonate another
authenticator. Among other things, this can result in messages (and
MSKs) being sent to the wrong authenticator. Since the rogue
authenticator is authenticated session hijacking as well as
attacks 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 rogue devices.

On wireless networks such as the
Called-Station-Id and Calling-Station-Id IEEE 802.11 [IEEE80211], these attacks
become easy to be forged mount, since any attacker within range can access the
wireless medium, or act as well. an access point. As recommended in [RFC3579], this vulnerability can be mitigated a result, new
ciphersuites have been proposed for use with wireless LANs
[IEEE80211i] which provide per-packet authentication, integrity and
replay protection. In addition, mutual authentication and key
derivation, provided by
having RADIUS proxies check authenticator identification attributes
against the source address.

To allow verification of session parameters methods such as EAP-TLS [RFC2716] are
required [IEEE80211i], so as to address the Called-
Station- Id threat of rogue devices,
and Calling-Station-Id, these can be sent by the EAP peer provide keying material to bind the server, protected by initial authentication to
subsequent data traffic.

If the TEKs. The RADIUS server can selected EAP method does not support mutual authentication,
then
check the parameters sent by the EAP peer against those claimed will be vulnerable to attack by
the authenticator. rogue authenticators
and backend authentication servers. If a discrepancy is found, an error can the EAP method does not derive
keys, then TSKs will not be
logged.

While [RFC3588] requires available for use of with a negotiated
ciphersuite, and there will be no binding between the Route-Record AVP, this utilizes
FQDNs, so that impersonation detection requires DNS A/AAAA initial EAP
authentication and PTR
RRs to be properly configured. As a result, it appears that Diameter
is as subsequent data traffic, leaving the session
vulnerable to this attack as RADIUS, if not more so. To address
this vulnerability, it is necessary to allow hijack.

If the backend authentication server to communicate with the does not protect against
authenticator directly,
such as via masquerade, or provide the redirect functionality supported in [RFC3588].

5.7. Channel proper binding

It is possible for a compromised or poorly implemented EAP
authenticator to communicate incorrect information of the AAA-
Key to the EAP peer
and/or server. This session within the AAA-Token, then one or more AAA-Keys
may enable be sent to an authenticator unauthorized party, and an attacker may be able to impersonate
another authenticator or communicate incorrect information via out-
of-band mechanisms (such as via
gain access to the network. If the AAA-Token is provided to an
untrusted AAA intermediary, then that intermediary may be able to
modify the AAA-Key, or the lower layer protocol).

Where EAP is used attributes associated with it, as
described in pass-through mode, [RFC2607].

If the EAP peer typically Secure Association Protocol does not verify the identity provide mutual proof of
possession of the pass-through authenticator, AAA-Key material, then the peer will not have
assurance that it is connected to the correct authenticator, only
verifies
that the pass-through authenticator is trusted by the EAP
server. This creates and backend authentication server share a potential security vulnerability, described in
[RFC3748] Section 7.15.

[RFC3579] Section 4.3.7 describes how an

Aboba, et al. Standards Track [Page 47]

INTERNET-DRAFT EAP pass-through
authenticator acting as a Key Management Framework 18 February 2005

trust relationship (since AAA client can be detected if it attempts
to impersonate another authenticator (such by sending incorrect NAS-
Identifier [RFC2865], NAS-IP-Address [RFC2865] or NAS-IPv6-Address
[RFC3162] attributes via protocols support mutual
authentication). This distinction can become important when multiple
authenticators receive AAA-Keys from the AAA protocol). However, it backend authentication
server, such as where fast handoff is possible supported. If the TSK
derivation does not provide for a pass-through authenticator acting protected ciphersuite and
capabilities negotiation, then downgrade attacks are possible.

6.4. 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 AAA client victim and a legitimate
authenticator. This allows the attacker to provide

Aboba, et al. Informational [Page 51]

INTERNET-DRAFT EAP Key Management Framework
14 November 2004

correct information authenticate successfully
to the AAA server while communicating misleading
information authenticator, as well as to obtain access to the network.

In order to prevent these attacks, [I-D.puthenkulam-eap-binding]
recommends derivation of a compound key by which the EAP peer via a lower layer protocol.

For example, it is possible for a compromised authenticator to
utilize another authenticator's Called-Station-Id or NAS-Identifier and
server can prove that they have participated in communicating with the entire EAP peer via a lower layer protocol, or for
a pass-through authenticator acting as a AAA client
exchange. Since the compound key must not be known to provide an
incorrect peer Calling-Station-Id [RFC2865][RFC3580] 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 AAA
server via the AAA protocol.

As noted
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 [RFC3748]
Section 7.15, this 2.3.

6.5. Denial of Service Attacks

The caching of security associations may result in vulnerability can be
addressed by use to
denial of service attacks. Since an EAP methods that support peer may derive multiple EAP
SAs with a protected exchange given EAP server, and creation of
channel properties such as endpoint identifiers, including (but a new EAP SA does 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
implicitly delete 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 previous EAP method. For example, see
[ServiceIdent].

5.8. Key Strength

In order to guard against brute force attacks, SA, EAP methods deriving
keys need to that result in
creation of persistent state may be capable vulnerable to denial of generating keys with an appropriate
effective symmetric key strength. In order service
attacks by a rogue EAP peer.

As a result, EAP methods creating persistent state may wish to ensure that key
generation is not limit
the weakest link, it is necessary for number of cached EAP methods
utilizing public key cryptography SAs (Phase 1a) corresponding to an EAP peer.
For example, an EAP server may choose to only retain a public key that has few EAP SAs
for each peer. This prevents a
cryptographic strength meeting the symmetric key strength
requirement.

As noted in [RFC3766] Section 5, this results in the following
required RSA or DH module and DSA subgroup size in bits, for rogue peer from denying access to
other peers.

Similarly, an authenticator may have multiple AAA-Key SAs
corresponding to a given
level EAP peer; to conserve resources an
authenticator may choose to limit the number of attack resistance in bits:

Aboba, et al. Informational Standards Track [Page 52] 48]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004

5.9. Key Wrap

As described in [RFC3579] Section 4.3, known problems exist in 18 February 2005

Depending on the
key wrap specified in [RFC2548]. media, creation of a new unicast Secure Association
SA may or may not imply deletion of a previous unicast secure
association SA. Where there is no implied deletion, the
authenticator may choose to limit Phase 2 (unicast and multicast)
Secure Association SAs for each peer.

6.6. Impersonation

Both the same RADIUS shared secret
is used and Diameter protocols are potentially vulnerable to
impersonation by a PAP rogue authenticator.

While AAA protocols such as RADIUS [RFC2865] or Diameter [RFC3588]
support mutual authentication between the authenticator (known as the
AAA client) and an EAP authenticator, there is a
vulnerability the backend authentication server (known as the AAA
server), the security mechanisms vary according to known plaintext attack. Since RADIUS uses the AAA protocol.

In RADIUS, the shared secret used for multiple purposes, including per-packet
authentication, attribute hiding, considerable information authentication is exposed
about determined by
the shared secret with each source address of the RADIUS packet. This exposes As noted in [RFC3579]
Section 4.3.7, it is highly desirable that the shared
secret source address be
checked against one or more NAS identification attributes so as to dictionary
detect and prevent impersonation attacks. MD5 is used both

When RADIUS requests are forwarded by a proxy, the NAS-IP-Address or
NAS-IPv6-Address attributes may not correspond to compute the RADIUS
Response Authenticator and source address.
Since the Message-Authenticator attribute, and
some concerns exist relating NAS-Identifier attribute need not contain an FQDN, it also
may not correspond to the security of this hash
[MD5Attack].

As discussed in [RFC3579] source address, even indirectly. [RFC2865]
Section 4.3, the security vulnerabilities
of 3 states:

A RADIUS are extensive, and therefore development server MUST use the source IP address of an alternative
key wrap technique based on the RADIUS
UDP packet to decide which shared secret would not
substantially improve security. As a result, [RFC3759] Section 4.2
recommends running RADIUS over IPsec. The same approach is taken in
Diameter EAP [I-D.ietf-aaa-eap], which defines cleartext key
attributes, to use, so that
RADIUS requests can be protected by IPsec or TLS.

Where an untrusted AAA intermediary proxied.

This implies that it is present (such as possible for a RADIUS
proxy rogue authenticator to forge
NAS-IP-Address, NAS-IPv6-Address or NAS-Identifier attributes within
a Diameter agent), and data object security is not used, the
AAA-Key may be recovered by an attacker RADIUS Access-Request in control of order to impersonate another
authenticator. Among other things, this can result in messages (and
MSKs) being sent to the untrusted
intermediary. Possession of wrong authenticator. Since the AAA-Key enables decryption of data
traffic sent between the peer and a specific authenticator; however
where key separation rogue
authenticator is implemented, compromise of authenticated by the AAA-Key does
not enable an attacker to impersonate RADIUS proxy or server purely
based on the peer source address, other mechanisms are required to another
authenticator, since that requires possession of detect
the EMSK, which forgery. In addition, it is
not transported by possible for attributes such as the AAA protocol. This
Called-Station-Id and Calling-Station-Id to be forged as well.

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

To allow verification of redirect functionality, session parameters such as provided in
[RFC3588].

6. Security Requirements

This section summarizes the security requirements that must be met by
EAP methods, AAA protocols, Secure Association Protocols Called-
Station- Id and
Ciphersuites in order to address the security threats described in
this document. These requirements MUST Calling-Station-Id, these can be met sent by specifications
requesting publication as an RFC. Each requirement provides a
pointer to the sections of this document describing the threat that
it mitigates.

6.1. EAP Method Requirements

It is possible for the peer and EAP server to mutually authenticate
and derive keys. In order to provide keying material for use in a

Aboba, et al. Informational Standards Track [Page 53] 49]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004

subsequently negotiated ciphersuite, an 18 February 2005

to the server, protected by the TEKs. The RADIUS server can then
check the parameters sent by the EAP method supporting key
derivation MUST export peer against those claimed by
the authenticator. If a Master Session Key (MSK) of at least 64
octets, and discrepancy is found, an Extended Master Session Key (EMSK) error can be
logged.

While [RFC3588] requires use of at least 64
octets. EAP Methods deriving keys MUST provide for mutual
authentication between the EAP peer and the EAP Server.

The MSK Route-Record AVP, this utilizes
FQDNs, so that impersonation detection requires DNS A/AAAA and EMSK MUST NOT PTR
RRs to be used directly properly configured. As a result, it appears that Diameter
is as vulnerable to protect data; however,
they are of sufficient size this attack as RADIUS, if not more so. To address
this vulnerability, it is necessary to enable derivation of a AAA-Key
subsequently used allow the backend
authentication server to derive Transient Session Keys (TSKs) for use communicate with the selected ciphersuite. Each ciphersuite authenticator directly,
such as via the redirect functionality supported in [RFC3588].

6.7. Channel binding

It is responsible possible for
specifying how a compromised or poorly implemented EAP
authenticator to communicate incorrect information to derive the TSKs from 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 AAA-Key.

The AAA-Key lower layer protocol).

Where EAP is derived from the keying material exported by used in pass-through mode, the EAP
method (MSK and EMSK). This derivation occurs on peer typically does
not verify the AAA server. In
many existing protocols identity of the pass-through authenticator, it only
verifies that use EAP, the AAA-Key and MSK are
equivalent, but more complicated mechanisms are possible (see pass-through authenticator is trusted by the EAP
server. This creates a potential security vulnerability, described in
[RFC3748] Section
2.5 for details). 7.15.

[RFC3579] Section 4.3.7 describes how an EAP methods SHOULD ensure the freshness of the MSK and EMSK even in
cases where one party may not have pass-through
authenticator acting as a high quality random number
generator. A RECOMMENDED method AAA client can be detected if it attempts
to impersonate another authenticator (such by sending incorrect NAS-
Identifier [RFC2865], NAS-IP-Address [RFC2865] or NAS-IPv6-Address
[RFC3162] attributes via the AAA protocol). However, it is possible
for each party a pass-through authenticator acting as a AAA client to provide a nonce
of at least 128 bits, used in
correct information to the derivation of AAA server while communicating misleading
information to the MSK and EMSK. EAP methods export peer via a lower layer protocol.

For example, it is possible for a compromised authenticator to
utilize another authenticator's Called-Station-Id or NAS-Identifier
in communicating with the MSK and EMSK and not Transient Session Keys so EAP peer via a lower layer protocol, or for
a pass-through authenticator acting as a AAA client to allow EAP methods 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 ciphersuite and media independent.
Keying material exported
addressed by EAP methods MUST be independent use of the
ciphersuite negotiated to protect data.

Depending on 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 support a wide range of
ciphersuites and media.

It is RECOMMENDED that methods providing integrity protection of EAP
packets include coverage protected exchange of all the EAP header fields,
channel properties such as endpoint identifiers, including the
Code, Identifier, Length, Type (but not
limited to): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id
[RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address

Aboba, et al. Standards Track [Page 50]

INTERNET-DRAFT EAP Key Management Framework 18 February 2005

[RFC2865], and Type-Data fields.

In order NAS-IPv6-Address [RFC3162].

Using such a protected exchange, it is possible to preserve algorithm independence, EAP methods deriving
keys SHOULD support (and document) match the protected negotiation of channel
properties provided by the
ciphersuite used to protect authenticator via out-of-band mechanisms
against those exchanged within the EAP conversation between the peer and
server. method. For example, see
[ServiceIdent].

7. Security Requirements

This is distinct from the ciphersuite negotiated between section summarizes the
peer security requirements that must be met by
EAP methods, AAA protocols, Secure Association Protocols and authenticator, used
Ciphersuites in order to protect data.

The strength of Transient Session Keys (TSKs) used address the security threats described in
this document. These requirements MUST be met by specifications
requesting publication as an RFC. Each requirement provides a
pointer to protect data is
ultimately dependent on the strength sections of keys generated by this document describing the threat that
it mitigates.

7.1. EAP
method. If an EAP method cannot produce keying material of
sufficient strength, then Method Requirements

It is possible for the TSKs may be subject to brute force

Aboba, et al. Informational [Page 54]

INTERNET-DRAFT peer and EAP Key Management Framework 14 November 2004

attack. server to mutually authenticate
and derive keys. In order to enable deployments requiring strong keys, provide keying material for use in a
subsequently negotiated ciphersuite, an EAP
methods method supporting key
derivation SHOULD be capable MUST export a Master Session Key (MSK) of generating an
MSK at least 64
octets, and EMSK, each with an effective key strength Extended Master Session Key (EMSK) of at least 128
bits. 64
octets. EAP Methods supporting key derivation deriving keys MUST demonstrate cryptographic
separation provide for mutual
authentication between the MSK EAP peer 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 Server.

The MSK or and EMSK MUST NOT be able used directly to recover the other
quantity with a level protect data; however,
they are of effort less than brute force.

Non-overlapping substrings sufficient size to enable derivation of a AAA-Key
subsequently used to derive Transient Session Keys (TSKs) for use
with 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 selected ciphersuite. Each ciphersuite is required
because some existing ciphersuites form TSKs by simply splitting the
AAA-Key responsible for
specifying how to pieces of appropriate length. Likewise, non-overlapping
substrings of derive the EMSK MUST be cryptographically separate from each
other, and TSKs from substrings of the MSK. AAA-Key.

The EMSK MUST remain on AAA-Key is derived from the keying material exported by the EAP peer
method (MSK and EAP server where it is
derived; it MUST NOT be transported to, or shared with, additional
parties, or used for purposes other than AMSK EMSK). 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 (see Section
2.6).

Since EAP does not provide
2.3 for explicit key lifetime negotiation, details).

EAP
peers, authenticators and authentication servers MUST be prepared for
situations in which one methods SHOULD ensure the freshness of the parties discards key state which
remains valid on another party.

The development MSK and validation EMSK even 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 key at least 128 bits, used in the derivation algorithms is
difficult, of the MSK and as a result EMSK.

EAP methods SHOULD reuse well established
and analyzed mechanisms for export the MSK and EMSK key derivation (such and not Transient Session Keys so
as
those specified in IKE [RFC2409] or TLS [RFC2246]), rather than
inventing new ones.

6.1.1. Requirements for to allow EAP methods

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

o It MUST specify how to derive the EMSK

o The key be ciphersuite and media independent.
Keying material used for the EMSK exported by EAP methods MUST be
computationally independent of the MSK and TEKs.

o The EMSK MUST NOT be used for any other purpose than the key
ciphersuite negotiated to protect data.

Aboba, et al. Informational Standards Track [Page 55] 51]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004

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 18 February 2005

Depending on the lower layer, EAP server.
Only keys (AMSKs) derived according to this specification methods may run before or after
ciphersuite negotiation, so that the selected ciphersuite may not be exported from
known to the EAP server.

o The EMSK MUST be unique for each session.

o The method. By providing keying material usable with
any ciphersuite, EAP mechanism SHOULD methods can used with a unique identifier suitable for naming the EMSK.

Implementations wide range of
ciphersuites and media.

It is RECOMMENDED that methods providing integrity protection of EAP frameworks on
packets include coverage of all the EAP-Peer and EAP-Server
SHOULD provide an interface to obtain AMSKs. The implementation MAY
restrict which callers can obtain which keys.

6.1.2. Requirements for EAP applications header fields, including the
Code, Identifier, Length, Type and Type-Data fields.

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

o New applications following this specification preserve algorithm independence, EAP methods deriving
keys SHOULD NOT use support (and document) the
MSK. If more than one application uses protected negotiation of the MSK, then
ciphersuite used to protect the EAP conversation between the
cryptographic separation is not achieved. Implementations SHOULD
prevent such combinations.

o A peer MUST NOT use and
server. This is distinct from the EMSK in any other way except ciphersuite negotiated between the
peer and authenticator, used to
derive Application Master protect data.

The strength of Transient Session Keys (AMSKs) using (TSKs) used to protect data is
ultimately dependent on the
key derivation specified in Section 2.6. It MUST NOT
use strength of keys generated by the EMSK directly for cryptographic protection EAP
method. If an EAP method cannot produce keying material of data,
and SHOULD provide only
sufficient strength, then the AMSKs TSKs may be subject to applications.

o Applications MUST define distinct brute force
attack. In order to enable deployments requiring strong keys, EAP
methods supporting key labels, application
specific data, and the length of derived derivation SHOULD be capable of generating an
MSK and EMSK, each with an effective key material used in the strength of at least 128
bits.

Methods supporting key derivation described in Section 2.6.

o Applications MUST define how they use their AMSK demonstrate cryptographic
separation between the MSK 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 derive TSKs
for their use.

6.2. AAA Protocol Requirements

AAA protocols suitable for use 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 transporting EAP 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 of the EMSK MUST provide be cryptographically separate from each
other, and from substrings of the
following facilities:

Security services
AAA protocols MSK.

The EMSK MUST remain on the EAP peer and EAP server where it is
derived; it MUST NOT be transported to, or shared with, additional
parties, or used for transport of purposes other than AMSK derivation (see Section
2.4).

Since EAP keying material MUST
implement and SHOULD use per-packet integrity does not provide for explicit key lifetime negotiation, EAP
peers, authenticators and authentication, authentication servers MUST be prepared for

Aboba, et al. Informational Standards Track [Page 56] 52]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004

replay protection and confidentiality. These requirements are met
by Diameter EAP [I-D.ietf-aaa-eap], 18 February 2005

situations in which one of the parties discards key state which
remains valid on another party.

The development and validation of key derivation algorithms is
difficult, and as a result EAP methods SHOULD reuse well as RADIUS over IPsec
[RFC3579].

Session Keys
AAA protocols used established
and analyzed mechanisms for transport of EAP keying material MUST
implement MSK and SHOULD use dynamic EMSK key management in order to derive
fresh session keys, derivation (such as
those specified in Diameter EAP [I-D.ietf-aaa-eap] and
RADIUS over IPsec [RFC3579], IKE [RFC2409] or TLS [RFC2246]), rather than using a static key, as
originally defined in RADIUS [RFC2865].

Mutual authentication
AAA protocols used
inventing new ones.

7.1.1. Requirements for transport of EAP keying material MUST
provide methods

In order 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 an EAP [RFC3579].

Authorization
AAA protocols used method to meet the guidelines for transport of EAP keying EMSK usage it
must meet the following requirements:

o It MUST specify how to derive the EMSK

o The key material SHOULD
provide protection against rogue authenticators masquerading as
other authenticators. This can be accomplished, used for example, by
requiring that AAA agents check the source address EMSK MUST be
computationally independent 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 MSK and ciphersuite independence, the AAA
server TEKs.

o The EMSK MUST NOT transport TSKs from the backend authentication
server to authenticator.

Key transport specification
In order be used for any other purpose than the key
derivation described in this document.

o The EMSK MUST be secret and not known to enable backend someone observing
the authentication servers to provide keying
material mechanism protocol exchange.

o The EMSK MUST NOT be exported from the EAP server.
Only keys (AMSKs) derived according to this specification
may be exported from the authenticator in EAP server.

o The EMSK MUST be unique for each session.

o The EAP mechanism SHOULD a well defined format, AAA
protocols unique identifier suitable for use with naming the EMSK.

Implementations of EAP MUST define frameworks on the format EAP-Peer and
wrapping of EAP-Server
SHOULD provide an interface to obtain AMSKs. The implementation MAY
restrict which callers can obtain which keys.

7.1.2. Requirements for EAP applications

In order for an application to meet the AAA-Token. guidelines for EMSK transport
Since usage it
must meet the EMSK is a secret known only to following requirements:

o New applications following this specification SHOULD NOT use the backend authentication
server and peer,
MSK. If more than one application uses the AAA-Token MSK, then the
cryptographic separation is not achieved. Implementations SHOULD
prevent such combinations.

o A peer MUST NOT transport use 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. any other way except to

Aboba, et al. Informational Standards Track [Page 57] 53]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004 18 February 2005

derive Application Master Session Keys
The AAA-Token SHOULD be protected with session keys as (AMSKs) using the
key derivation specified in Diameter
[RFC3588] or RADIUS over IPsec [RFC3579] rather than static keys,
as in [RFC2548].

Key naming
In order Section 2.4. It MUST NOT
use the EMSK directly for cryptographic protection of data,
and SHOULD provide only the AMSKs to ensure against confusion between applications.

o Applications MUST define distinct key labels, application
specific data, and the appropriate keying length of derived key 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
derivation described in Section 2.4.

o Applications MUST define how the keying
material is to be used.

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

6.3. Secure Association derive TSKs
for their use.

7.2. AAA Protocol Requirements

The Secure Association Protocol supports

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

Entity Naming
The peer
following facilities:

Security services
AAA protocols used for transport of EAP keying material MUST
implement and authenticator SHOULD identify themselves in a manner
that is independent of their attached ports.

Mutual proof of possession
The peer use per-packet integrity and authenticator MUST each demo
nstrate possession 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 the EAP keying material transported between the backend authentication
server and authenticator (AAA-Key).

Key Naming
The Secure Association Protocol MUST explicitly name the keys used
implement and SHOULD use dynamic key management in the proof of possession exchange, so as order to prevent confusion
when more derive
fresh session keys, as in Diameter EAP [I-D.ietf-aaa-eap] and
RADIUS over IPsec [RFC3579], rather than one set of keying material could potentially be used using a static key, as the basis
originally defined in RADIUS [RFC2865].

Mutual authentication
AAA protocols used for the exchange.

Creation and Deletion
In order to support the correct processing transport of phase 2 security
associations, the Secure Association (phase 2) protocol EAP keying material MUST
support
provide for mutual authentication between the naming of phase 2 security associations authenticator and associated
transient session keys, so that the correct set
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 transient
session keys EAP keying material SHOULD
provide protection against rogue authenticators masquerading as
other authenticators. This can be identified accomplished, for processing a given packet. The
phase 2 Secure Association Protocol also MUST support transient
session key activation and SHOULD support deletion, so example, by
requiring that
establishment and re-establishment AAA agents check the source address of transient session keys can be
synchronized between packets
against the parties. 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

Aboba, et al. Informational Standards Track [Page 58] 54]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004

Integrity 18 February 2005

order to maintain media and Replay Protection
The Secure Association Protocol ciphersuite independence, the AAA
server MUST support integrity and replay
protection of all messages.

Direct operation
Since NOT transport TSKs from the phase 2 Secure Association Protocol is concerned 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
establishment format and
wrapping of security associations between the EAP peer and
authenticator, including AAA-Token.

EMSK transport
Since the derivation of transient session keys, EMSK is a secret known only those parties have "a need to know" the transient session
keys. The Secure Association Protocol MUST operate directly between the peer and authenticator, backend authentication
server and peer, the AAA-Token MUST NOT be passed-through to transport the EMSK from the
backend authentication server, or include additional parties.

Derivation of transient session keys
The Secure Association Protocol negotiation server to the authenticator.

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

Session Keys
The AAA-Token SHOULD be protected with session keys suitable for use
with 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 negotiated ciphersuite.

TSK freshness
The appropriate keying
material to be used in a given Secure Association (phase 2) Protocol MUST support
exchange, the
derivation of fresh unicast AAA-Token SHOULD include explicit key names and multicast transient session keys,
even when
context appropriate for informing the authenticator how the keying
material provided by the backend
authentication server is not fresh. This is typically supported by
including an exchange of nonces within to be used.

Key Compromise
Where untrusted intermediaries are present, the Secure Association
Protocol.

Bi-directional operation
While some ciphersuites only require a single set AAA-Token SHOULD
NOT be provided to the intermediaries. In Diameter, handling of transient
session
keys to protect traffic 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 both directions, other
ciphersuites require a unique set manner
that is independent of transient session keys in their attached ports.

Mutual proof of possession
The peer and authenticator MUST each
direction. demonstrate possession of the

Aboba, et al. Standards Track [Page 55]

INTERNET-DRAFT EAP Key Management Framework 18 February 2005

keying material transported between the backend authentication
server and authenticator (AAA-Key).

Key Naming
The phase 2 Secure Association Protocol SHOULD provide
for MUST explicitly name the derivation of unicast and multicast keys used
in each direction, the proof of possession exchange, so as not to require two separate phase 2 exchanges in 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
create a bi-directional support the correct processing of phase 2 security association.

Secure capabilities negotiation
The
associations, the Secure Association Protocol (phase 2) protocol MUST
support secure capabilities
negotiation. This includes security parameters such as the naming of phase 2 security association identifier (SAID) associations and ciphersuites, as well as
negotiation of associated
transient session keys, so that the lifetime correct set of the TSKs, AAA-Key and exported EAP
keys. transient
session keys can be identified for processing a given packet. The
phase 2 Secure capabilities negotiation Association Protocol also includes confirmation
of the capabilities discovered during the discovery phase (phase
0), so as to ensure 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 announced capabilities have not been
forged.

Key Scoping parties.

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

Direct operation
Since the synchronization phase 2 Secure Association Protocol is concerned with the
establishment of
key scope security associations between the EAP peer and authenticator. This includes

Aboba, et al. Informational [Page 59]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004

negotiation of restrictions on key usage.

6.4. Ciphersuite Requirements

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

TSK derivation
In order to allow a ciphersuite of transient session keys,
only those parties have "a need to be usable within know" the EAP keying
framework, a specification transient session
keys. The Secure Association Protocol MUST operate directly between
the peer and authenticator, and MUST NOT be provided describing how passed-through to the
backend authentication server, or include additional parties.

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 ciphersuite are
derived from negotiated ciphersuite.

TSK freshness
The Secure Association (phase 2) Protocol MUST support the AAA-Key.

EAP method independence
Algorithms for deriving
derivation of fresh unicast and multicast transient session keys from the AAA-Key
MUST NOT depend on keys,
even when the EAP method. However, algorithms for
deriving TEKs MAY be specific to keying material provided by the EAP method.

Cryptographic separation
The TSKs derived from backend
authentication server is not fresh. This is typically supported by
including an exchange of nonces within 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.

7. IANA Considerations

This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration Secure Association
Protocol.

Bi-directional operation
While some ciphersuites only require a single set of values related to transient

Aboba, et al. Standards Track [Page 56]

INTERNET-DRAFT EAP key
management, Key Management Framework 18 February 2005

session keys to protect traffic in accordance with BCP 26, [RFC2434].

The following terms are used here with the meanings defined both directions, other
ciphersuites require a unique set of transient session keys in BCP
26: "name space", "assigned value", "registration". each
direction. The following policies are used here with phase 2 Secure Association Protocol SHOULD provide
for the meanings defined derivation of unicast and multicast keys in BCP
26: "Private Use", "First Come First Served", "Expert Review",
"Specification Required", "IETF Consensus", "Standards Action".

For registration requests where a Designated Expert should be
consulted, the responsible IESG area director should appoint the
Designated Expert. The intention is that any allocation will be
accompanied by a published RFC. But each direction,
so as not to require two separate phase 2 exchanges in order to allow for
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
allocation
security association identifier (SAID) and ciphersuites, as well as
negotiation of values prior to the RFC being approved for publication, lifetime of the Designated Expert can approve allocations once it seems clear
that an RFC will be published. 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 Designated expert will post 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
request ciphersuite to be usable within the EAP WG mailing list (or keying
framework, a successor designated by specification MUST be provided describing how
transient session keys suitable for use with the
Area Director) ciphersuite are
derived from the AAA-Key.

EAP method independence
Algorithms for comment and review, including an Internet-Draft.
Before a period of 30 days has passed, deriving transient session keys from the Designated Expert will
either approve or deny 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 section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration request and publish a notice of values related to EAP key

Aboba, et al. Informational Standards Track [Page 60] 57]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004

of the decision to 18 February 2005

management, in accordance with BCP 26, [RFC2434].

The following terms are used here with the meanings defined in BCP
26: "name space", "assigned value", "registration".

The following policies are used here with the meanings defined in BCP
26: "Private Use", "First Come First Served", "Expert Review",
"Specification Required", "IETF Consensus", "Standards Action".

For registration requests where a Designated Expert should be
consulted, the responsible IESG area director should appoint the
Designated Expert. The intention is that any allocation will be
accompanied by a published RFC. But in order to allow for the
allocation of values prior to the RFC being approved for publication,
the Designated Expert can approve allocations once it seems clear
that an RFC will be published. The Designated expert will post a
request to the EAP WG mailing list (or a successor designated by the
Area Director) for comment and review, including an Internet-Draft.
Before a period of 30 days has passed, the Designated Expert will
either approve or deny the registration request and publish a notice
of the decision to the EAP WG mailing list or its successor, as well
as informing IANA. A denial notice must be justified by an
explanation and, in the cases where it is possible, concrete
suggestions on how the request can be modified so as to become
acceptable.

This document introduces a new name space for "key labels". Key
labels are ASCII strings and are assigned via IETF Consensus. It is
expected that key label specifications will include the following
information:

o A description of the application
o The key label to be used
o How TSKs will be derived from the AMSK and how they will be used
o If application specific data is used, what it is and how it is
maintained
o Where the AMSKs or TSKs will be used and how they are
communicated if necessary.

9. References

8.1.

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

Aboba, et al. Standards Track [Page 58]

INTERNET-DRAFT EAP Key Management Framework 18 February 2005

1998.

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

8.2.

9.2. Informative References

[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.

Aboba, et al. Informational [Page 61]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004

[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
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.

Aboba, et al. Standards Track [Page 59]

INTERNET-DRAFT EAP Key Management Framework 18 February 2005

[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

Aboba, et al. Informational [Page 62]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004
(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
2004.

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

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

[IEEE802] Institute of Electrical and Electronics Engineers, "IEEE
Standards for Local and Metropolitan Area Networks: Overview
and Architecture", ANSI/IEEE Standard 802, 1990.

[IEEE80211]
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-1999, 1999. 802.11-2003, 2003.

[IEEE8021X]
Institute of Electrical and Electronics Engineers, "Local and
Metropolitan Area Networks: Port-Based Network Access

Aboba, et al. Standards Track [Page 60]

INTERNET-DRAFT EAP Key Management Framework 18 February 2005

Control", IEEE Standard 802.1X-2004, September December 2004.

[IEEE8021Q]
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.

[IEEE80211F]
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.

Aboba, et al. Informational [Page 63]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004

[IEEE80211i]
Institute of Electrical and Electronics Engineers, "Draft
Supplement "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 Draft 802.11I/ D8, February
802.11i, December 2004.

[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,
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-08

Aboba, et al. Standards Track [Page 61]

INTERNET-DRAFT EAP Key Management Framework 18 February 2005

eap-10 (work in progress), June November 2004.

[I-D.irtf-aaaarch-handoff]
Arbaugh, W. and B. Aboba, "Handoff Extension to RADIUS",
draft-irtf-aaaarch-handoff-04 (work in progress), October
2003.

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

[I-D.aboba-802-context]
Aboba, B. and T. Moore, "A Model for Context Transfer in IEEE
802", draft-aboba-802-context-03 (work in progress), October

Aboba, et al. Informational [Page 64]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004
2003.

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

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

[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.

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

[WLANREQ] Stanley, D., Walker, J. and B. Aboba, "EAP Method Requirements
for Wireless LANs", draft-walker-ieee802-req-02.txt draft-walker-ieee802-req-04.txt (work in
progress), July August 2004.

[Housley56]
Housley, R., "Key Management in AAA", Presentation to the AAA
WG at IETF 56,
http://www.ietf.org/proceedings/03mar/slides/aaa-5/index.html,
March 2003.

Acknowledgments

Thanks to Arun Ayyagari, Ashwin Palekar, and Tim Moore of Microsoft,
Dorothy Stanley of Agere, Bob Moskowitz of TruSecure, Jesse Walker of

Aboba, et al. Standards Track [Page 62]

INTERNET-DRAFT EAP Key Management Framework 18 February 2005

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 98
052 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
Arenavagen 27
Stockholm S-121 28
SWEDEN

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

Aboba, et al. Informational Standards Track [Page 65] 63]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004

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
Arenavagen 27
Stockholm S-121 28
SWEDEN

Phone: +46 708 32 16 08
EMail: henrik@levkowetz.com Management Framework 18 February 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 [IEEE80211], 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
[IEEE80211], 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 [IEEE80211i]. 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 64]

INTERNET-DRAFT EAP Key Management Framework 18 February 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. Informational Standards Track [Page 66] 65]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004 18 February 2005

Appendix A C - Ciphersuite Keying Requirements

To date, PPP and IEEE 802.11 ciphersuites are suitable for keying by
EAP. This Appendix describes EAP-TLS Key Hierarchy

In EAP-TLS [RFC2716], the keying requirements of common PPP
and 802.11 ciphersuites.

PPP ciphersuites include DESEbis [RFC2419], 3DES [RFC2420], and MPPE
[RFC3078]. The DES algorithm MSK is described in [FIPSDES], and DES
modes (such divided into two halves,
corresponding to the "Peer to Authenticator Encryption Key" (Enc-
RECV-Key, 32 octets, also known 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 the PMK) and [RFC2420] for 3DES, "Authenticator to
Peer Encryption Key" (Enc-SEND-Key, 32 octets). In [RFC2548], the IV,
which is different in each direction, is "deduced from an explicit
64-bit nonce, which
Enc-RECV-Key (the PMK) is exchanged transported in the clear during MS-MPPE-Recv-Key
attribute, and the [ECP]
negotiation phase." There Enc-SEND-Key is therefore no need for transported in the IV MS-MPPE-Send-
Key attribute.

The EMSK is also divided into two halves, corresponding 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 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 required.

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

Within [IEEE80211], Transient Session Keys (TSKs) a known value; octets
0-31 are required both
for unicast traffic as well known 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
[IEEE80211], which requires a 40-bit encryption key, the same in
either direction; "Peer to Authenticator IV" or RECV-IV, and WEP-128, which requires a 104-bit encryption
key,
Octets 32-63 are known as the same in either direction. These ciphersuites also do not
support per-packet authentication and integrity protection. In
addition "Authenticator to these unicast keys, authentication Peer IV", or SEND-IV.

In EAP-TLS, the MSK, EMSK and encryption keys IV are required to wrap 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 multicast encryption key.

Recently, new ciphersuites have been proposed TLS master secret is compromised then the
MSK is also compromised.

As described in [RFC2716], the formula for use with IEEE
802.11 that provide per-packet authentication the derivation of the MSK,
EMSK and integrity
protection as well IV is as encryption [IEEE80211i]. 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 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 both directions) [RFC2548]). Also known as the
PMK.
AAA-Key(32,63)= Authenticator to Peer Encryption Key (Enc-SEND-Key)
(MS-MPPE-Send-Key in order [RFC2548])
EMSK(0,31) = Peer to
authenticate and encrypt data.

As with WEP, authentication and encryption keys are also required Authenticator Authentication Key (Auth-RECV-Key)
EMSK(32,63) = Authenticator to
wrap the multicast encryption (and possibly, authentication) keys. 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. Informational Standards Track [Page 67] 66]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004

Appendix B - Transient EAP Key (TEK) Hierarchy

Figure B-1 illustrates the TEK key hierarchy for EAP-TLS [RFC2716],
which is based on 18 February 2005

AAA-Key(W,Z) = Octets W through Z includes of the TLS key hierarchy described in [RFC2246]. The
TLS-negotiated ciphersuite is used to set up a protected channel for
use in protecting AAA-Key.
IV(W,Z) = Octets W through Z inclusive of the EAP conversation, keyed by IV.
MSK(W,Z) = Octets W through Z inclusive of the derived TEKs.
The TEK derivation proceeds as follows:

master_secret MSK.
EMSK(W,Z) = TLS-PRF-48(pre_master_secret, "master secret",
client.random || server.random)
TEK Octets W through Z inclusive of the EMSK.
TMS = TLS-PRF-X(master_secret, "key expansion",
server.random || client.random)
Where: TLS master_secret
TLS-PRF-X = TLS pseudo-random PRF function defined in [RFC2246], [RFC2246] computed to X octets.

| | | 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.

Figure B-1 C-1 - EAP TLS [RFC2246] [RFC2716] Key Hierarchy hierarchy

Aboba, et al. Informational Standards Track [Page 68] 67]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004 18 February 2005

Appendix C D - EAP-TLS Example Transient Session Key Hierarchy

In EAP-TLS [RFC2716], (TSK) Derivation

Within IEEE 802.11 RSN, the MSK is divided into two halves,
corresponding Pairwise Transient Key (PTK), a transient
session key used to protect unicast traffic, is derived from the "Peer to Authenticator Encryption Key" (Enc-
RECV-Key, 32 octets, also PMK
(octets 0-31 of the MSK), known in [RFC2716] as the PMK) and "Authenticator to Peer to
Authenticator Encryption Key" (Enc-SEND-Key, 32 octets). Key. In [RFC2548], [IEEE80211i], the
Enc-RECV-Key (the PMK) PTK is transported in derived
from the MS-MPPE-Recv-Key
attribute, and PMK via the Enc-SEND-Key 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 transported used to provide data origin
authenticity in the MS-MPPE-Send-
Key attribute. TSK derivation. It utilizes the first 128 bits
(bits 0-127) of the PTK. The EMSK is also divided into two halves, corresponding to EAPOL-Key Encryption Key (KEK) provides
confidentiality in the "Peer
to Authenticator Authentication Key" (Auth-RECV-Key, 32 octets) TSK derivation. It utilizes bits 128-255 of
the PTK. Bits 256-383 of the PTK are used by Temporal Key 1, 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 Bits
384-511 are known as the "Peer to Authenticator IV" or RECV-IV, used by Temporal Key 2. Usage of TK1 and
Octets 32-63 TK2 is
ciphersuite specific. Details are known as the "Authenticator to Peer IV", or SEND-IV.

In EAP-TLS, available in [IEEE80211i].

Aboba, et al. Standards Track [Page 68]

INTERNET-DRAFT EAP Key Management Framework 18 February 2005

Appendix E - Key Names and Scope in Existing Methods

This appendix specifies the MSK, EMSK key names and IV are derived from the TLS master
secret via a one-way function. This ensures scope in methods that have
been published prior to the TLS master
secret cannot be derived from the MSK, EMSK or IV unless the one-way
function (TLS PRF) publication of this RFC. What is broken. Since needed
in addition to the MSK rules in Section 2.4 is derived from the the
TLS master secret, if the TLS master secret definition of what EAP
peer and server names are used, what Method-Id is compromised then the
MSK used, and how these
are encoded.

EAP-TLS

The EAP-TLS Method-Id is also compromised.

As described in [RFC2716], the formula for provided by the derivation concatenation of the MSK,
EMSK peer
and IV server nonces.

Where certificates are used, the Session-Id scope is 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 determined via
the 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 peer and server names, deduced from the
PMK.
AAA-Key(32,63)= Authenticator to Peer Encryption Key (Enc-SEND-Key)
(MS-MPPE-Send-Key altSubjectName 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. Informational [Page 69]

INTERNET-DRAFT the
peer and server certificates.

Issue: What happens if a pre-shaked key ciphersuite is negotiated?
How are the EAP peer and server names determined?

EAP-AKA

The EAP-AKA Method-Id is the contents of the RAND field from the
AT_RAND attribute, followed by the contents of the AUTN field in the
AT_AUTN attribute.

The EAP Key Management Framework 14 November 2004

AAA-Key(W,Z) = Octets W through Z includes peer name is the contents of the AAA-Key.
IV(W,Z) = Octets W through Z inclusive Identity field from the
AT_IDENTITY attribute, using only the Actual Identity Length octets
from the beginning, however. Note that the contents are used as they
are transmitted, regardless of whether the IV.
MSK(W,Z) = Octets W through Z inclusive transmitted identity was a
permanent, pseudonym, or fast reauthentication identity. The EAP
server name is an empty string.

EAP-SIM

The Method-Id is the contents of the MSK.
EMSK(W,Z) = Octets W through Z inclusive RAND field from the AT_RAND
attribute, followed by the contents of the EMSK.
TMS = TLS master_secret
TLS-PRF-X = TLS PRF function defined NONCE_MT field in [RFC2246] computed to X octets
client.random = Nonce generated by the TLS client.
server.random = Nonce generated by
AT_NONCE_MT attribute.

The EAP peer name is the TLS server.

Figure C-1 describes contents of the process by which Identity field from the MSK,EMSK,IV and
ultimately
AT_IDENTITY attribute, using only the TSKs, are derived Actual Identity Length octets
from the TLS Master Secret.

---+
| ^
| TLS Master Secret (TMS) |
| |
V |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | EAP |
| Master Session Key (MSK) | Method |
| Derivation | |
| | V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ beginning, however. Note that the contents are used as they
are transmitted, regardless of whether the transmitted identity was a
permanent, pseudonym, or fast reauthentication identity. The EAP ---+
| | | 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 name is an empty string.

Aboba, et al. Informational Standards Track [Page 70] 69]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004 18 February 2005

Appendix D F - Example Transient 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 Key (TSK) Derivation

Within IEEE 802.11 RSN, identifier (a value selected by the Pairwise Transient Key (PTK), server)
o Certificate of the other party (server stores the client's
certificate and vice versa)
o Ciphersuite and compression method
o TLS Master secret (known as the EAP-TLS Master Key)
o SA lifetime (ensuring that the SA is not stored forever)
o If the client has multiple different credentials (certificates
and corresponding private keys), a transient
session key used pointer to protect unicast traffic, is derived from those credentials

When the server initiates EAP-TLS, the client can look up the EAP-TLS
SA based on the credentials it was going to use (certificate and
private key), and the PMK
(octets 0-31 expected credentials (certificate or name) of
the MSK), known in [RFC2716] as server. If an EAP-TLS SA exists, and it is not too old, the Peer to
Authenticator Encryption Key. In [IEEE80211i],
client informs the PTK is derived
from server about the PMK via existence of this SA by including
its Session-Id in 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) TLS ClientHello message. The server then looks
up the correct 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, 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 WEP use X = 48. server can store the following information:

o Implicitly, the EAP method this SA refers to (EAP-AKA)
o A re-authentication pseudonym
o The EAPOL-Key Confirmation client's permanent identity (IMSI)
o Replay protection counter
o Authentication key (K_aut)
o Encryption key (K_encr)
o Original Master Key (KCK) (MK)
o SA lifetime (ensuring that the SA is used to provide data origin
authenticity in not stored forever)

When the TSK derivation. It utilizes server initiates EAP-AKA, the first 128 bits
(bits 0-127) of client can look up the PTK. The EAPOL-Key Encryption Key (KEK) provides
confidentiality in EAP-AKA
SA based on the credentials it was going to use (permanent identity).
If an EAP-AKA SA exists, and it is not too old, the TSK derivation. It utilizes bits 128-255 of client informs
the PTK. Bits 256-383 of server about the PTK are used by Temporal Key 1, and Bits
384-511 are used by Temporal Key 2. Usage existence of TK1 and TK2 is
ciphersuite specific. Details are available this SA by sending its re-
authentication pseudonym as its identity in [IEEE80211i]. EAP Identity Response
message, instead of its permanent identity. The server then looks up
the correct SA based on this identity.

Aboba, et al. Informational Standards Track [Page 71] 70]

INTERNET-DRAFT EAP Key Management Framework 14 November 2004

Appendix E - Key Names 18 February 2005

AAA SA Example: RADIUS

In RADIUS, where shared secret authentication is used, the client and Scope in Existing Methods

This appendix specifies
server store each other's IP address and the shared secret, which is
used to calculate the Response Authenticator [RFC2865] and Message-
Authenticator [RFC3579] values, and to encrypt some attributes (such
as the AAA-Key, see [RFC3580] Section 3.16).

Where IPsec is used to protect RADIUS [RFC3579] and IKE is used for
key names management, the parties store information necessary to
authenticate and scope authorize the other party (e.g. certificates, trust
anchors and names). The IKE exchange results in methods that have
been published prior IKE Phase 1 and Phase
2 SAs containing information used to protect the publication of this RFC. What is needed conversation
(session keys, selected ciphersuite, etc.)

AAA SA Example: Diameter with TLS

When using Diameter protected by TLS, the parties store information
necessary to authenticate and authorize the other party (e.g.
certificates, trust anchors and names). The TLS handshake results in addition
a short-term TLS SA that contains information used to protect the rules in
actual communications (session keys, selected TLS ciphersuite, etc.).

Service SA Example: 802.11i

[IEEE802.11i] Section 2.4 is 8.4.1.1 defines the definition of what EAP
peer and server names are used, what Method-Id security associations used
within IEEE 802.11. A summary follows; the standard should be
consulted for details.

o Pairwise Master Key Security Association (PMKSA)

The PMKSA is used, a bi-directional SA, used by both parties for sending
and how these
are encoded.

EAP-TLS receiving. The EAP-TLS Method-Id PMKSA is provided by the concatenation of Root Service SA. It is created
on the peer
and server nonces.

Where certificates are used, the Session-Id scope when EAP authentication completes successfully or a
pre-shared key is determined via configured. The PMKSA is created on the EAP peer and server names, deduced from
authenticator when the altSubjectName in PMK is received or created on the
peer and server certificates.

Issue: What happens if
authenticator or a pre-shaked pre-shared key ciphersuite is negotiated?
How configured. The PMKSA is
used to create the PTKSA. PMKSAs are cached for their lifetimes.
The PMKSA consists of the EAP peer and following elements:

EAP-AKA

The EAP-AKA Method-Id or
by local configuration. This can include
parameters such as the peer's authorized SSID.

Aboba, et al. Standards Track [Page 71]

INTERNET-DRAFT EAP Key Management Framework 18 February 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, the contents details of which depend
on the RAND field from accounting protocol used, the
AT_RAND attribute, followed by implementation
and administrative details. In RADIUS, this could include
(e.g. packet and octet counters, and Acct-Multi-Session-Id).

o Pairwise Transient Key Security Association (PTKSA)

The PTKSA is a bi-directional SA created as the contents result of the AUTN field in the
AT_AUTN attribute. a
successful four-way handshake. The EAP peer name PTKSA is a unicast service SA.
There may only be one PTKSA between a pair of peer and
authenticator MAC addresses. PTKSAs are cached for the contents lifetime
of the Identity field from PMKSA. Since the
AT_IDENTITY attribute, using PTKSA is tied to the PMKSA, it only has
the Actual Identity Length octets additional information from the beginning, however. Note that 4-way handshake. The PTKSA
consists of the contents are used as they
are transmitted, regardless following:

- Key (PTK)
- Selected ciphersuite
- MAC addresses of whether the transmitted identity was a
permanent, pseudonym, or fast reauthentication identity. The EAP
server name parties
- Replay counters, and ciphersuite specific state
- Reference to PMKSA: This is an empty string.

EAP-SIM needed when:
o A new four-way handshake is needed (lifetime, TKIP
countermeasures), and we need to know which PMKSA to use

o Group Transient Key Security Association (GTKSA)

The Method-Id GTKSA is a uni-directional SA created based on the contents of the RAND field from the AT_RAND
attribute, followed by the contents of the NONCE_MT field in four-way
handshake or the
AT_NONCE_MT attribute. group key handshake. The EAP peer name GTKSA is the contents a multicast
service SA. A GTKSA consists of the Identity field from the
AT_IDENTITY attribute, using only the Actual Identity Length octets
from the beginning, however. Note that following:

- Direction vector (whether the contents are GTK is used as they
are transmitted, regardless of whether the transmitted identity was a
permanent, pseudonym, for transmit or fast reauthentication identity. The EAP
server name receive)
- Group cipher suite selector
- Key (GTK)
- Authenticator MAC address
- Via reference to PMKSA, or copied here:
o Authorization parameters
o Reference to accounting context

Service SA Example: IKEv2/IPsec

Note that this example is an empty string. intended to be informative, and it does
not necessarily include all information stored.

Aboba, et al. Informational Standards Track [Page 72]

INTERNET-DRAFT EAP Key Manageme
nt Management Framework 14 November 2004 18 February 2005

o IKEv2 SA

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

When processing an incoming message, the correct SA is looked up
based on the SPIs.

o IPsec SAs/SPD

- Traffic selectors
- Replay protection counters
- Selected ciphersuite
- IPsec SPI
- Keys
- Lifetime information
- Protocol mode (tunnel or transport)

The correct SA is looked up based on SPI (for inbound packets), or
SPD traffic selectors (for outbound traffic). A separate IPsec SA
exists for each direction.

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary

Aboba, et al. Standards Track [Page 73]

INTERNET-DRAFT EAP Key Management Framework 18 February 2005

rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.

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 (2004). (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.

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. Informational Standards Track [Page 73] 74]

----