view Side-By-Side changes

EAP Working Group                                          Bernard Aboba
INTERNET-DRAFT                                                 Dan Simon
Category: Informational                                        Microsoft
<draft-aboba-pppext-key-problem-06.txt>
2 March
<draft-aboba-pppext-key-problem-07.txt>
9 August 2003



                      EAP Keying Key Management Framework

Status of this Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026.

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.

Copyright Notice

Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

This document describes the provides a framework for EAP key derivation, management, including a
statement of applicability and
provides guidelines for generation generation, transport and
usage of EAP keys by EAP methods
and AAA protocols. keying material.  Algorithms for key derivation or
mechanisms for key transport are not specified in this document.
Rather, this document provides a framework within which derivation algorithms and
transport mechanisms can be discussed and evaluated.









Aboba & Simon                Informational                      [Page 1]





INTERNET-DRAFT           EAP Keying Key Mgmt. Framework              2 March           9 August 2003


Table of Contents

1.     Introduction ..........................................    3
   1.1       Requirements language Language ...........................    3
   1.2       Terminology .....................................    4
2.     EAP overview ..........................................    3
   1.3       Conversation Overview ...........................    5
   2.1       Invariants ......................................    7
3.
2.     EAP key hierarchy .....................................    8
   3.1    9
   2.1       EAP Invariants ..................................    9
   2.2       Key Hierarchy ...................................   11
   2.3       Exchanges .......................................   11
4.     Security properties ...................................   14
   4.1       EAP method requirements .........................   14
   4.2       AAA protocol requirements .......................   17
   4.3       TSK derivation requirements .....................
   2.4       Security Relationships ..........................   18
   4.4       Ciphersuite requirements ........................   19
   4.5
3.     Security properties ............................. associations .................................   19
   3.1       EAP SA ..........................................   19
   3.2       AAA-Key SA ......................................   20
   3.3       Unicast Secure Association SA ...................   21
   3.4       Multicast Secure Association SA .................   22
   3.5       Key Naming ......................................   23
4.     Threat model ..........................................   25
   4.1       Security Assumptions ............................   25
   4.2       Security Requirements ...........................   26
5.     IANA Considerations ...................................   32
6.     Security considerations Considerations ...............................   21
   5.1       Assumptions .....................................   21
   5.2       Key binding  ....................................   22
   5.3   32
   6.1       Key strength Strength ....................................   23
   5.4   32
   6.2       Key wrap Wrap ........................................   23
   5.5   32
   6.3       Man-in-the-middle attacks Attacks .......................   24
6.     Normative references ..................................   24   33
   6.4       Impersonation ...................................   33
7.     References ............................................   34
   7.1       Normative References ............................   34
   7.2       Informative references ................................   25 References ..........................   35
Appendix A - Ciphersuite independence ........................   29
Appendix B - Ciphersuite keying requirements Keying Requirements .................   30   39
Appendix C B - Example TEK hierarchy ...........................   31 Hierarchy ...................................   40
Appendix D C - Example MSK, EMSK MSK and IV hierarchy ..............   32 EMSK Hierarchy ..........................   41
Appendix E D - Example TSK derivation ..........................   34 Derivation ..................................   43
Appendix F E - Example PMK derivation AAA-Key Key Derivation ..........................   35   44
Acknowledgments ..............................................   35   44
Author's Addresses ...........................................   35   44
Intellectual Property Statement ..............................   36   45
Full Copyright Statement .....................................   36   45













Aboba & Simon                Informational                      [Page 2]





INTERNET-DRAFT           EAP Keying Key Mgmt. Framework              2 March           9 August 2003


1.  Introduction

The Extensible Authentication Protocol (EAP), defined in [RFC2284bis],
was originally developed designed to provide enable extensible authentication for network access in
situations in which the IP protocol is not available.  Originally
developed for use with PPP [RFC1661]. Since then, [RFC1661], it has subsequently also been
applied to IEEE 802 wired networks [IEEE8021X].  When EAP is used

This document provides a framework for authentication on PPP
or wired IEEE 802 networks, it is typically assumed that the link generation, transport and
usage of keying material generated by EAP authentication algorithms,
known as "methods".   Since in EAP keying material is
physically secure, so that an attacker cannot gain access to the link,
or insert a rogue device.

EAP methods defined in [RFC2284bis] 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 generated by EAP peer to
authenticator) but not mutual authentication or key derivation. As a
result, these methods do not bind the initial authentication
methods, transported by AAA protocols, transformed into session keys by
secure association protocols and
subsequent data traffic, even when the the ciphersuite used to protect
data supports per-packet authentication and integrity protection.  This
leaves these methods vulnerable to hijacking as well as attacks by rogue
devices.

On wireless networks such as IEEE 802.11 [IEEE80211], these attacks
become much easier to mount, since any attacker within range link layer ciphersuites,  it is capable
of accessing the wireless medium, or acting as an access point. As 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 methods such as EAP TLS [RFC2716] are required
[IEEE80211i], so as
necessary to address the threat describe each of rogue devices, these elements and provide
keying material to bind the initial authentication to subsequent data
traffic. a system-level
security analysis.

The document is organized as follows:

Section 2 1 provides an overview of EAP. introduction and defines terminology.
Section 3 2 describes the EAP key
hierarchy. hierarchy and exchanges.
Section 4 3 describes requirements EAP security associations and key naming.
Section 4 describes the resulting threat model and security
properties. requirements.
Section 5 discusses additional describes the IANA considerations.
Section 6 describes security considerations.
Section 7 provides references.
Appendix A discusses the principle of ciphersuite independence. Appendix
B provides a summary of summarizes the keying requirements of for link layer
ciphersuites supported on PPP and IEEE 802.11. ciphersuites.
Appendix C B provides an example transient EAP Master Key (MK) key (TEK) hierarchy.
Appendix D C provides an example
Master Session Key (MSK) MSK and EMSK hierarchy.
Appendix E D provides an example Transient Session Key (TSK) derivation.
Appendix F provides an example
of PMK derivation in Fast Handoff. E describes AAA-Key derivation, including fast handoff.

1.1.  Requirements language Language

In this document, several words are used to signify the requirements of
the specification.  These words are often capitalized.  The key words
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD



Aboba & Simon                Informational                      [Page 3]





INTERNET-DRAFT            EAP Keying Framework              2 March 2003
NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this document are to be
interpreted as described in BCP 14 [RFC2119].

1.2.  Terminology

This document frequently uses the following terms:

authenticator
     The end of the EAP link initiating EAP authentication.  Where no
     backend authentication server is present, the authenticator acts as
     the EAP server, terminating the EAP conversation with the peer.
     Where a backend authentication server is present, the authenticator
     MAY



Aboba & Simon                Informational                      [Page 3]





INTERNET-DRAFT           EAP Key Mgmt. Framework           9 August 2003


     may act as a pass-through for one or more authentication methods
     and for non-local users.  This terminology is also used in
     [IEEE8021X], and has the same meaning in this document.

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

AN-Token

AAA-Token
     The package within which the Master Session Key (MSK) keying material and one or more attributes
     is transported between the backend authentication server and the
     authenticator.  The attributes provide the authenticator with information on MSK usage. usage
     context and key names suitable to bind the key to the appropriate
     context.  For example, attributes might include the peer layer 2 address,
     address (Calling-Station-Id), the authenticator layer 2 address
     (Called-Station-Id) and IP addresses, address (NAS-IP-Address), the MSK lifetime, key name,
     etc.  The format and wrapping of the AN-Token, AAA-Token, which is intended
     to be accessible only to the backend authentication server and
     authenticator, is defined by the AAA key distribution
     specification. protocol.

Cryptographic binding
     The demonstration of the EAP peer to the EAP server that a single
     entity has acted as the EAP peer for all methods executed within a
     sequence or tunnel.  Binding MAY also imply that the EAP server
     demonstrates to the peer that a single entity has acted as the EAP
     server for all methods executed within a sequence or tunnel.  If
     executed correctly, binding serves to mitigate man-in-the-middle
     vulnerabilities.

Cryptographic separation
     Two keys (x and y) are "cryptographically separate" if an adversary
     that knows all messages exchanged in the protocol cannot compute x
     from y or y from x without "breaking" some cryptographic
     assumption.  In particular, this definition allows that the



Aboba & Simon                Informational                      [Page 4]





INTERNET-DRAFT            EAP Keying Framework              2 March 2003
     adversary has the knowledge of all nonces sent in cleartext as well
     as all predictable counter values used in the protocol.  Breaking a
     cryptographic assumption would typically require inverting a one-
     way function or predicting the outcome of a cryptographic pseudo-
     random number generator without knowledge of the secret state.  In
     other words, if the keys are cryptographically separate, there is
     no shortcut to compute x from y or y from x, but the work an
     adversary must do to perform this computation is equivalent to
     performing exhaustive search for the secret state value.

EAP server
     The entity which terminates EAP authentication with the peer is



Aboba & Simon                Informational                      [Page 4]





INTERNET-DRAFT           EAP Key Mgmt. Framework           9 August 2003


     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.

Key derivation
     This refers to the ability of the EAP method to derive a Master Key
     (MK) which is not exported, as well as export a ciphersuite- independent
     ciphersuite-independent Master Session Key (MSK), Extended Master
     Session Key (EMSK) (EMSK), and (optionally) an Initialization Vector (IV).  The MSK, EMSK and IV are used only for
     further key derivation, not directly for protection of the EAP
     conversation or subsequent data.

Key strength
     If the effective key strength is N bits, the best currently known
     methods to recover the key (with non-negligible probability)
     require an effort comparable to 2^N operations of a typical block
     cipher.

EAP server
     The entity that terminates the EAP authentication with the peer.
     In the case where there is no backend authentication server, this
     term refers to the authenticator. Where the authenticator operates
     in pass-through, it refers to the backend authentication server.

Mutual authentication
     This refers to an EAP method in which, within an interlocked
     exchange, the authenticator authenticates the peer and the peer
     authenticates the authenticator.  Two one-way conversations,
     running in opposite directions do not provide mutual authentication
     as defined here.

peer The end of the EAP Link link that responds to the authenticator.  In
     [IEEE8021X], this end is known as the Supplicant.

2.

1.3.  Conversation Overview

Where EAP overview

The key derivation is supported, EAP authentication process involves is typically a peer, authenticator and
(optionally)
component of a backend authentication server. Typically, the peer
desires access to the network, three phase exchange:

    Discovery phase (phase 0)
    EAP authentication, key derivation and transport (phase 1)
    Unicast and multicast secure association establishment (phase 2)

In the discovery phase (phase 0),  the authenticator is a Network Access
Server (NAS) providing that access. However, EAP may also be used in peers locate each other situations, such as when it is desired and
discover their capabilities.  This can include an EAP peer locating
an authenticator suitable for two network devices
(e.g. two switches or routers) access to authenticate each other.  Since EAP is



Aboba & Simon                Informational                      [Page 5]





INTERNET-DRAFT            EAP Keying Framework              2 March 2003 a peer-to-peer protocol, particular network, or
it could involve an independent and simultaneous authentication
may take EAP peer locating an authenticator behind
a bridge with which it desires to establish a secure association.  Typically
the discovery phase takes place in between the reverse direction. Both peers may act as
authenticators EAP peer and authenticatees at authenticator.

Once the same time.

An important goal of EAP is to enable peer and authenticator discover each other, they
authenticate using EAP (phase 1a).  EAP 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



Aboba & Simon                Informational                      [Page 5]





INTERNET-DRAFT           EAP Key Mgmt. Framework           9 August 2003


the peer.

EAP presumes that prior

As described in Section 2,  in addition to initiation of supporting authentication, the
EAP peer
has located the authenticator, using an out-of-band mechanism. For
example, for use with PPP, the client might be configured with a phone
book providing phone numbers methods may also support derivation of keying material for accessing purposes
including protection of the selected service. For use
with IEEE 802.11 wireless LANs, EAP conversation and subsequent data
exchanges.  EAP key derivation takes place between the EAP peer (a Station (STA) in IEEE 802.11
terminology) may locate and EAP
server, and methods supporting key derivation MUST also support mutual
authentication.  Where an authenticator (an Access Point (AP) in IEEE
802.l1 terminology) using server is present,  it acts as
the IEEE 802.11 Beacon and Probe
Request/Response frames. Since service location is handled out of band,
this functionality is not provided within EAP. EAP supports either one-way authentication (in which server and transports derived keying material (known as the peer
authenticates AAA-
Key) to the EAP server), or mutual authentication (in which authenticator (phase 1b).  In 802.11 terminology, the
peer and first
32 octets of the AAA-Key is known as the Pairwise Master Key (PMK).

While EAP server mutually authenticate). In either case, it can methods may be
assumed that the parties do based on key management protocols, EAP itself
is not enable the link unless their
authentication requirements have been met. For example, a peer
completing key management protocol.  Thus, while EAP may provide for
mutual authentication with an authenticator will not enable
its link until the authenticator has authenticated successfully to the
peer.

As described in Section 3, EAP methods MAY support and derivation of keying
material used material, it does not
provide for purposes including protection the derivation or naming of transient session keys, the EAP conversation
and subsequent data exchanges, man-in-the-middle detection,
selection of traffic modes such as transport or tunnel mode, the secure
negotiation of capabilities such as ciphersuites or filters,  or fast
handoff. EAP methods supporting key derivation must also support mutual
authentication.
for key activation.  As a result, where EAP assumes that ciphersuite negotiation, if it occurs, is handled out
of band. For example, the peer might used for key derivation,
a secure association protocol (phase 2) should be preconfigured with policy
indicating provided, supporting
the ciphersuite to be creation and deletion of unicast (phase 2a) and multicast (phase 2b)
security associations used in communicating with a given
authenticator, or alternatively, for the link layer protocol may support
ciphersuite negotiation.  Within PPP, protection of data.

The phases and the ciphersuite is negotiated
within relationship between the Encryption Control Protocol (ECP), after EAP authentication parties is completed. Within [IEEE80211i], the AP capabilities (including
ciphersuite) are advertised in illustrated
below.

EAP peer                 Authenticator              Auth. Server
--------                 -------------              ------------
 <----------------------------->
       Discovery (phase 0)
 <-----------------------------><------------------------------->
      EAP auth (phase 1a)          AAA pass-through (optional)
                                <--------------------------------
                                   AAA-Key transport (phase 1b)
 <----------------------------->
  Unicast Secure association (phase 2a)
 <----------------------------->
  Multicast Secure association (phase 2b)

Figure 1 - Conversation Overview

1.3.1.  Discovery Phase

In the Beacon peer discovery exchange (phase 0),  the EAP peer and Probe Responses,
authenticator locate each other and are
securely verified during discover each other's capabilities.
For example, PPPoE [RFC2516] includes support for a 4-way exchange after EAP authentication has
completed. The desired ciphersuite is indicated within Discovery Stage to
allow a peer to identify the Ethernet MAC address of one or more
authenticators and establish a PPPoE SESSION_ID.  In [IEEE 80211], the
Association/Reassociation Request/Response exchange.



Aboba & Simon                Informational                      [Page 6]





INTERNET-DRAFT           EAP Keying Key Mgmt. Framework              2 March           9 August 2003


2.1.  Invariants

Several basic principles govern the design of the


EAP keying framework.
These are peer (also known as the "EAP Invariants":

Media independence
     As described in [RFC2284bis], EAP authentication is supported on
     lower layers, including PPP [RFC1661] Station or STA) discovers the authenticator
(Access Point or AP) and IEEE 802 wired networks
     [IEEE8021X]. Use with IEEE 802.11 wireless LANs is also
     contemplated [IEEE80211i]. determines its capabilities using Beacon or
Probe Request/Response frames.  Since EAP methods cannot be assumed to
     have knowledge device discovery is handled
outside of EAP, there is no need to provide this functionality within
EAP.

Device discovery can occur manually or automatically.  In EAP
implementations running over PPP, the lower layer on which they are being run, EAP
     methods MUST peer might be designed to function on any lower layer meeting the
     criteria outlined in [RFC2284bis], Section 3.1.

Ciphersuite independence
     Since ciphersuite negotiation occurs out-of-band configured with
a phone book providing phone numbers of EAP, authenticators and may associated
capabilities such as supported rates, authentication protocols or
ciphersuites.

Since device discovery can occur after EAP prior to authentication and key derivation is complete, EAP
     methods deriving keys MUST provide
derivation, it may not be possible for the discovery phase to be
protected using keying material that is
     independent of the ciphersuite subsequently negotiated for
     protection of data.

     Since it is the peer and authenticator that negotiate and implement
     the ciphersuite, knowledge of the ciphersuite is restricted to
     those entities.  The backend derived during an authentication server is not
exchange.  As a party result, device discovery protocols may be insecure,
leaving them vulnerable to spoofing unless the ciphersuite negotiation nor is it an intermediary in discovered parameters can
subsequently be securely verified.

1.3.2.  Authentication Phase

Once the
     data flow between EAP peer and authenticator discover each other, they
authenticate using EAP (phase 1a).  Typically, the peer desires access
to the network, and authenticator. As the authenticators are Network Access Servers
(NASes) providing that access.  In such a result, it
     cannot be assumed situation, access to have knowledge of the ciphersuites implemented
network can be provided by any authenticator attaching to the peer desired
network, and authenticator, the EAP peer is typically willing to send data traffic
through any authenticator that can demonstrate that it is authorized to
provide access to be aware of the ciphersuite
     negotiated between them, desired network.

An EAP authenticator may handle the authentication locally, or it may
act as a pass-through to implement ciphersuite-specific code.

     Since the a backend authentication server may not know server.  In the
     ciphersuite negotiated latter
case the EAP exchange occurs between the EAP peer and authenticator, it
     cannot make this information available to a resident backend
authenticator server, with the authenticator forwarding EAP method.
     This means that ciphersuite-specific key generation, if implemented
     within an packets
between the two.  The entity which terminates EAP method, will not function correctly on every authentication with
the peer is known as the EAP
     implementation. The advantages of ciphersuite independence are
     discussed in Appendix A.

Method independence
     Supporting server.  Where pass-through of authentication to is supported,
the backend authentication server enables functions as the authenticator to support any EAP server; where
authentication method implemented on occurs locally, the backend authentication EAP server and peer, not just locally implemented methods.  This
     implies that is the authenticator need not implement code for each EAP
     method required by authenticating peers; in fact authenticator.
Where a backend authentication server is present, at the authenticator successful
completion of an authentication exchange, the AAA-Key is not required transported to implement any
the authenticator (phase 1b).

EAP methods at all, nor cannot it may also be assumed used when it is desired for two network devices (e.g.
two switches or routers) to implement code specific authenticate each other, or where two peers
desire to any EAP method. authenticate each other and set up a secure association
suitable for protecting data traffic.





Aboba & Simon                Informational                      [Page 7]





INTERNET-DRAFT           EAP Keying Key Mgmt. Framework              2 March           9 August 2003


     This is useful where there is no single


EAP method that is both
     mandatory-to-implement and offers acceptable security for supports either one-way authentication (in which the media
     in use. For example, peer
authenticates to the [RFC2284bis] mandatory-to-implement EAP
     method (MD5-Challenge) does not provide dictionary attack
     resistance, server), or mutual authentication or key derivation, (in which the
peer and as a
     result is not appropriate for use with IEEE 802.11 wireless LANs.

3.  EAP key hierarchy

The EAP keying hierarchy, illustrated in Figure 1, makes use of server mutually authenticate).  In either case, it can be
assumed that the
following types of keys:

EAP Master key (MK)
     A key derived between 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 client and server during will
not send data traffic over the link until the EAP
     authentication process that is purely local server has
authenticated successfully to the peer, and a secure association has
been negotiated.

Since EAP method. The
     MK MUST NOT be exported from the EAP method or be made available to
     a third party.  Since derivation of the MK is a residue of peer-to-peer protocol, an independent and simultaneous
authentication may take place in the
     successful reverse direction.  Both peers may
act as authenticators and authenticatees at the same time.

Successful completion of the EAP authentication exchange, proof of
     MK possession may be used to shorten future EAP exchanges between
     the same and key derivation by an EAP client
peer and server, a technique known as "fast resume".

Master Session Key (MSK)
     Keying material (64 octets) EAP server does not necessarily imply that the peer is derived between
committed to joining the network associated with an EAP client
     and server. The MSK  Rather,
this commitment is used in implied by the derivation creation of Transient Session
     Keys (TSKs) for the ciphersuite negotiated a security association
between the EAP peer and
     authenticator. Where a backend authentication server is present,
     acting authenticator, as an EAP server, it will typically transport the MSK to the
     authenticator.

     The MSK differs from part of the MK secure
association protocol (phase 2).  As a result, EAP may be used for "pre-
authentication" in that situations where it not assumed to remain local is necessary to the pre-establish EAP method, and is known by all parties
security associations in the EAP exchange:
     the peer, authenticator and the authentication server (if present).
     The MSK MAY be derived from the MK via a one-way function, order to decrease handoff or it roaming latency.

1.3.3.  Secure Association Phase

While EAP methods may be an independent quantity.  However possession based on key management protocols, EAP itself
is not a protocol for negotiation of the MSK MUST
     NOT provide any information useful in determining the MK. An
     example, MSK, EMSK and IV security associations.  While EAP
methods supporting key derivation is given in Appendix D.

Extended Master Session Key (EMSK)
     Additional keying material (64 octets) derived between the EAP
     client provide for mutual authentication and server that is not assumed to remain local
creation of EAP (phase 1) security associations, in order to preserve
media independence, they typically do not support generation of
transient session keys or negotiation of ciphersuites used in the
protection of data.  As a result, where EAP
     method.  However, unlike is used for key derivation,
a secure association protocol (phase 2) should be provided, supporting
the MSK, creation and deletion of phase 2 security associations used for the EMSK is known only to
protection of data.

The secure association phase (phase 2) always occurs after the
completion of EAP
     client authentication (phase 1a) and server key transport (phase
1b), and MUST NOT be provided to a third party. typically supports the following features:

[1]  The
     EMSK therefore MUST NOT be transported by secure negotiation of capabilities.  This includes usage modes,
     session parameters and ciphersuites, and required filters,
     including confirmation of the backend
     authentication server to capabilities discovered during phase
     0.  By securely negotiating session parameters, the authenticator. The EMSK is reserved
     for future uses secure
     association protocol protects against spoofing during the discovery
     phase and ensures that the peer and authenticator are not defined yet. For example, it could be
     used to derive additional keying material for purposes such as fast
     handoff, man-in-the-middle vulnerability protection, etc. An
     example of fast handoff key derivation is given in Appendix F. agreement
     about how data is to be secured.




Aboba & Simon                Informational                      [Page 8]





INTERNET-DRAFT           EAP Keying Key Mgmt. Framework              2 March           9 August 2003


Initialization Vector (IV)
     A 64 octet quantity suitable for use in an initialization vector
     field, that


[2]  Generation of fresh transient session keys.  This is derived between typically
     accomplished via the EAP client exchange of nonces within the secure
     association protocol, and server. Since includes generation of both unicast
     (phase 2a) and multicast (phase 2b) session keys.  While multicast
     traffic may only pass in
     some EAP methods such one direction in certain cases (such as [RFC2716] the IV is a known value, the IV
     MUST NOT be used in computation of any quantity that needs to
     remain secret.

Pairwise Master Key (PMK)
     In [RFC2716], the MSK is divided into two halves, corresponding to
     the "Peer to Authenticator Encryption Key" (Enc-RECV-Key, 32
     octets) and "Authenticator to Peer Encryption Key" (Enc-SEND-Key,
     32 octets) (reception is defined from the point of view of the
     authenticator).  Within [IEEE80211i] Octets 0-31 of
     IEEE 802.11 infrastructure mode, where only the MSK (Enc-
     RECV-Key) are also known Access Point sends
     multicast traffic), in other cases (such as IEEE 802.11 adhoc
     mode), both endpoints may send multicast traffic.  By not using the Pairwise Master Key (PMK).

     [IEEE80211i] ciphersuites derive their Transient Session Keys
     (TSKs) solely from the PMK, whereas
     AAA-Key directly to protect data, the WEP ciphersuite, when used
     with [IEEE8021X], as noted in [Congdon], derives its TSKs from both
     halves secure association protocol
     protects against compromise of the MSK, the Enc-RECV-Key AAA-Key, and by guaranteeing the Enc-SEND-Key.

Transient EAP Keys (TEKs)
     Session
     freshness of transient session key, assures that session keys which are used to establish a protected channel
     between the EAP peer
     not reused.

[3]  Key activation and server during deletion.

[4]  Mutual proof of possession of the keying material generated during
     EAP authentication
     exchange.  The TEKs are typically derived from (phase 1).  By requiring a mutual proof of
     possession of the MK, and are
     appropriate for use with AAA-Key, the secure association protocol
     demonstrates that both the ciphersuite negotiated between EAP peer and server as part authenticator have been
     authenticated and authorized by the EAP authentication exchange. AAA server.  Note that mutual
     proof of possession is not the ciphersuite used to set up the protected channel between same thing as mutual authentication.
     For example, as a result of a secure association protocol exchange,
     the EAP peer and server during EAP authentication is unrelated may not be able to confirm the
     ciphersuite used to subsequently protect data sent between identity of the EAP
     peer and
     authenticator.  In particular, the TEKs used to protect
     the

2.  EAP Key Hierarchy

2.1.  EAP Invariants

The EAP exchange MUST be cryptographically separate from TSKs used
     to protect data. An example TEK key hierarchy is management framework assumes that certain basic
characteristics, known as the "EAP Invariants" hold true for all
implementations of EAP.  These include:

   Media independence
   Method independence
   Ciphersuite independence

2.1.1.  Media Independence

As described in
     Appendix C.

Transient Session Keys (TSKs)
     Session keys used to protect data which are appropriate for the
     ciphersuite negotiated between the [RFC2284bis], EAP peer authentication can run over multiple
lower layers, including PPP [RFC1661] and authenticator. The
     TSKs are derived from the MSK by a process which is link layer
     specific.  In the case of IEEE 802.11, TSK derivation 802 wired networks
[IEEE8021X].  Use with IEEE 802.11 wireless LANs is supported
     via a 4-way handshake that supports mutual authentication between
     the EAP peer and authenticator. The 4-handshake also confirms
     mutual possession contemplated
[IEEE80211i].  Since EAP methods cannot be assumed to have knowledge of
the PMK as well as supporting protected
     ciphersuite negotiation. An example TSK derivation is given lower layer over which they are transported, EAP methods can
function on any lower layer meeting the criteria outlined in
     Appendix E.
[RFC2284bis], Section 3.1.





Aboba & Simon                Informational                      [Page 9]





INTERNET-DRAFT           EAP Keying Key Mgmt. Framework              2 March           9 August 2003


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         ---+
|                                                         |            ^
|                EAP


2.1.2.  Method                               |            |
|                                                         |            |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |            |
| |                                       |               |            |
| |                                       |               |            |
| |                                       |               |            |
| |        EAP Master Key (MK)            |               |            |
| |             Derivation                |               |            |
| |                                       |               |   Local to |
| |                                       |               |       EAP  |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |     Method |
|   |             |               |                       |            |
|   |                                                     |            |
|   | MK          |               |                       |            |
|   |                                                     |            |
|   V             |               |                       |            |
| +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ |            |
| |  TEK      | | MSK       | |EMSK       | |IV         | |            |
| |Derivation | |Derivation | |Derivation | |Derivation | |            |
| +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ |            |
|                 |               |                 |     |            |
|                 |               |                 |     |            V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         ---+
                  |               |                 |                  ^
                  |               |                 |                  |
                  | MSK (64B)     | EMSK (64B)      | IV (64B)         |
                  |               |                 |          Exported|
                  |               |                 |              by  |
                  |               V                 V              EAP |
                  |         +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+  Method|
                  |         |     Reserved    | | Known       |        |
                  |         |                 | |(Not Secret) |        |
                  |         +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+        V
                  |                                                 ---+
                  |                                        Transported |
                  |                                             by AAA |
                  |                                           Protocol |
                  V                                                    V
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                    ---+
   |                           |                                       ^
   |            TSK            |                           Ciphersuite |
   |        Derivation         |                              Specific |
   |                           |                                       V
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                    ---+

Figure 1 - EAP Key Hierarchy



Aboba & Simon                Informational                     [Page 10]





INTERNET-DRAFT            EAP Keying Framework              2 March 2003


3.1.  Exchanges

Figure 2 illustrates Independence

Supporting pass-through of authentication to the EAP exchange in backend authentication
server enables the authenticator to support any authentication method
implemented on the case where no backend authentication server is present. Here and peer, not just
locally implemented methods.

This implies that the authenticator need not implement code for each EAP is spoken between the peer
and authenticator, encapsulated within a lower layer protocol, such as
PPP, defined in [RFC1661] and IEEE 802, defined in [IEEE802].  Since
method required by authenticating peers.  In fact, the authenticator acts as an endpoint of the EAP conversation rather than a
pass-through, is
not required to implement any EAP methods are implemented on the authenticator as well
as the peer. If the at all, nor cannot it be
assumed to implement code specific to any EAP method.

This is useful where there is no single EAP method negotiated between that is both
mandatory-to-implement and offers acceptable security for the media in
use.  For example, the [RFC2284bis] mandatory-to-implement EAP peer and
authenticator supports method
(MD5-Challenge) does not provide dictionary attack resistance, mutual
authentication and or key derivation, an EAP
Master Key (MK) is derived on the EAP peer and authenticator and stored
locally within the as a result is not appropriate for
use in wireless authentication.

2.1.3.  Ciphersuite Independence

While EAP method. The MK methods may then be negotiate the ciphersuite used to derive
Transient in protection of
the EAP Keys (TEKs) conversation, the ciphersuite used to protect some or all for the protection of data is
negotiated within the EAP
exchange. secure association protocol, out-of-band of EAP.
The TEKs are also stored locally within backend authentication server is not a party to this negotiation nor
is it an intermediary in the data flow between the EAP method peer and are
not exported.

Once mutual
authenticator.  The backend authentication completes and is successful, server may not even have
knowledge of the ciphersuites implemented by the peer and
authenticator exchange data, which may authenticator,
or be protected using a ciphersuite.
In order to provide keys for aware of the ciphersuite, Transient Session Keys
(TSKs) are required. On completion of a successful authentication, EAP
methods on the peer ciphersuite negotiated between them, and authenticator export therefore
does not implement ciphersuite-specific code.

Since ciphersuite negotiation occurs in the Master Session Key
(MSK), Extended Master Session Key (EMSK) and IV. Of these quantities,
only secure association protocol,
not in EAP, ciphersuite-specific key generation, if implemented within
an EAP method, would potentially conflict with the MSK is used today, for transient session key
derivation of occurring in the TSKs. The mechanism
for this secure association protocol.  As a result,
EAP methods generate keying material that is specific ciphersuite-independent.
Additional advantages of ciphersuite-independence include:

Update requirements
     If EAP methods were to the ciphersuite; specify how to derive transient session keys
     for example, in [IEEE80211i],
the 4-way handshake each ciphersuite, they would need to be updated each time a new
     ciphersuite is used.

Where no 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 present, added to the MSK and EMSK are
known only
     authenticator.





Aboba & Simon                Informational                     [Page 10]





INTERNET-DRAFT           EAP Key Mgmt. Framework           9 August 2003


EAP method complexity
     Requiring each EAP method to include ciphersuite-specific code for
     transient session key derivation would increase the peer and authenticator complexity of
     each EAP method and neither is transported to a
third party.  As demonstrated would result in [RoamCERT], despite the absence duplicated effort.

Ciphersuite negotiation
     In practice, an EAP method may not have knowledge of a
backend authentication server, such exchanges can support roaming the
     ciphersuite that has been negotiated between providers; it is even possible to support fast handoff
[IEEE80211f] without re-authentication. However, this is typically only
possible where both the EAP peer and authenticator support certificate-
based authentication, or where
     authenticator. In PPP, ciphersuite negotiation occurs in the user base
     Encryption Control Protocol (ECP) [RFC1968].  Since ECP negotiation
     occurs after authentication, unless an EAP method is sufficiently small utilized that
EAP authentication can occur locally.

Where these conditions cannot be met, a
     supports ciphersuite negotiation, the peer, authenticator and
     backend authentication server is
typically required.  In may not be able to anticipate the
     negotiated ciphersuite and therefore this exchange, as described information cannot be
     provided to the EAP method. Since ciphersuite negotiation is
     assumed to occur out-of-band, there is no need for ciphersuite
     negotiation within EAP.

2.2.  Key Hierarchy

The EAP keying hierarchy, illustrated in [RFC2869bis], Figure 2, makes use of the
authenticator acts as a pass-through
following types of keys:

EAP Master key (MK)
     A key derived between the EAP peer client and a backend
authentication server. In this model, server during the authenticator delegates EAP
     authentication process, and that is kept local to the
access control decision EAP method
     and not exported or made available to a third party.  Since the backend MK
     is a residue of a successful EAP authentication server, which acts
as exchange, it is
     possible to shorten future EAP exchanges between an EAP peer and
     server by providing proof of MK possesion, a technique known as
     "fast resume".

Master Session Key Distribution Center (KDC), supplying keying (MSK)
     Keying material to both (at least 64 octets) that is derived between the
     EAP peer client and authenticator.








Aboba & Simon                Informational                     [Page 11]





INTERNET-DRAFT server and exported by the EAP Keying Framework              2 March 2003


+-+-+-+-+-+               +-+-+-+-+-+
|         |               |         |
|         |               |         |
| Cipher- |               | Cipher- |
| Suite   |               | Suite   |
|         |               |         |
+-+-+-+-+-+               +-+-+-+-+-+
    ^                         ^
    |                         |
    |                         |
    |                         |
    V                         V
+-+-+-+-+-+               +-+-+-+-+-+
|         |               |         |
|         |===============|         |
|         |EAP, TEK Deriv.|Authenti-|
|         |<------------->| cator   |
|         |               |         |
|         |  TSK Deriv.   |         |
| peer    |<------------->| (EAP    |
|         |===============| server) |
|         | Link layer    |         |
|         | (PPP,IEEE802) |         |
|         |               |         |
|MSK,EMSK |               |MSK,EMSK |
| (TSKs)  |               |  (TSKs) |
|         |               |         |
+-+-+-+-+-+               +-+-+-+-+-+
    ^                         ^
    |                         |
    | MSK, EMSK, IV           | MSK, EMSK, IV
    |                         |
    |                         |
+-+-+-+-+-+               +-+-+-+-+-+
|         |               |         |
| method.  Whenever a
     full EAP    |               | authentication is performed (not fast handoff), the MSK is
     chosen as the AAA-Key (see Appendix E for details).

AAA-Key
     Where a backend authentication server is present, acting as an EAP    |
|  Method |               |  Method |
|         |               |         |
|(MK,TEKs)|               |(MK,TEKs)|
|         |               |         |
+-+-+-+-+-+               +-+-+-+-+-+

Figure 2 - Relationship between
     server,  keying material known as the AAA-Key is transported from
     the authentication server to the authenticator wrapped within the
     AAA-Token.  The AAA-Key is used by the EAP peer and authenticator
           (acting as an
     in the derivation of Transient Session Keys (TSKs) for the
     ciphersuite negotiated between the EAP server), where no backend peer and authenticator.  As
     a result, the AAA-Key is typically known by all parties in the EAP
     exchange: the peer, authenticator and the authentication server (if
     present).  AAA-Key derivation is present. discussed in Appendix E.



Aboba & Simon                Informational                     [Page 12] 11]





INTERNET-DRAFT           EAP Keying Key Mgmt. Framework              2 March           9 August 2003


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

Figure 3 - Pass-through relationship


Extended Master Session Key (EMSK)
     Additional keying material (64 octets) derived between the EAP peer,
           authenticator
     client and backend authentication server.








Aboba & Simon                Informational                     [Page 13]





INTERNET-DRAFT            EAP Keying Framework              2 March 2003


Figure 3 illustrates server that is exported by the EAP method.  Unlike the
     MSK which is transported from the authentication process in server to the case where
     authenticator, the authenticator acts as a pass-through.  Here EAP EMSK is spoken between known only to the EAP peer and authenticator as before. The authenticator then
encapsulates EAP packets within a AAA protocol such as RADIUS
[RFC2869bis] or Diameter [DiamEAP], server
     and forwards packets is not provided to and from the
backend authentication server, which acts as the EAP server.  Since the
authenticator acts as a pass-through, EAP methods (as well as the
derived EAP Master Key, and TEKs) reside only on the peer and backend
authentication server.

Once mutual authentication completes and third party. The EMSK therefore is successful, the EAP method
present on the peer and authenticator export not
     transported by the MSK, EMSK and IV. The backend authentication server then sends a message to the authenticator
indicating that authentication has been successful, providing the MSK
within a protected package known
     authenticator, although quantities derived from it may be used as
     the AN-Token. Along with the MSK,
the AN-Token contains attributes indicating AAA-Key in situations in which EAP authentication is bypassed
     (e.g. fast handoff).

     Currently the parameters of key usage.
The MSK EMSK is then reserved for future uses that are not defined
     yet.  For example, it could be used by the authenticator and peer to derive Transient
Session Keys (TSKs) required additional keying
     material for the negotiated ciphersuite.

The TSKs are known only to the peer and authenticator, and purposes such as noted
earlier, the TSK derivation process varies by ciphersuite.  For example,
within the 4-way handshake described fast handoff, man-in-the-middle
     vulnerability protection, etc.

Initialization Vector (IV)
     A quantity of at least 64 octets, suitable for use in [IEEE80211i], an
     initialization vector field, that is derived between the peer EAP client
     and
authenticator confirm mutual possession of server. Since the MSK, demonstrate
liveness, IV is a known value in methods such as EAP-
     TLS [RFC2716] it cannot be used in computation of any quantity that
     needs to remain secret, and do is not used with any known ciphersuite.
     As a protected ciphersuite result, its use has been deprecated and capabilities negotiation.

4.  Security properties

This section describes the security requirements for EAP methods, AAA
protocols, TSK derivation mechanisms and Ciphersuites. These
requirements MUST be met by specifications requesting publication as an
RFC. Based on these requirements, the security properties of EAP
exchanges methods are analyzed.

4.1.  EAP method requirements

Mutual authentication
     Methods deriving keys MUST support mutual authentication. not
     required to generate it.

Pairwise Master Key
     Methods deriving keys MUST support derivation (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 EAP authenticator).  Within [IEEE80211i] Octets 0-31 of
     the AAA-Key (Enc-RECV-Key) are known as the Pairwise Master Key
     (MK), as well
     (PMK).  [IEEE80211i] ciphersuites derive their Transient Session
     Keys (TSKs) solely from the PMK, whereas the WEP ciphersuite, when
     used with [IEEE8021X], as specifying how noted in [RFC3580], derives its TSKs from
     both halves of the AAA-Key, the Enc-RECV-Key and the Enc-SEND-Key.

Transient EAP Keys (TEKs)
     Session keys which are
     derived from used to establish a protected channel
     between the MK.

     The MK is EAP peer and server during the root of EAP authentication
     exchange.  The TEKs are appropriate for use with the ciphersuite
     negotiated between EAP key hierarchy. As a result,
     compromise of MK must be avoided if at all possible, since an
     attacker peer and server for use in possession of protecting the MK will be able
     EAP conversation.  Note that the ciphersuite used to derive all set up the
     other keys in
     protected channel between the hierarchy. This would provide an attacker with EAP peer and server during EAP
     authentication is unrelated to the ability not only ciphersuite used to decrypt and insert subsequently
     protect data sent between a



Aboba & Simon                Informational                     [Page 14]





INTERNET-DRAFT            EAP Keying Framework              2 March 2003


     particular EAP peer and authenticator, but also potentially to
     decrypt future data as well and to subsequently access the network
     using authentication mechanisms such as fast resume or fast
     handoff.

     Since the MK is known only to the EAP peer and server, and only
     mutually authenticating EAP methods may distribute keys, possession
     of the MK authenticator.  An
     example TEK key hierarchy is proof of a completed mutual authentication.  In order
     to protect against compromise of the MK, which could be used to
     impersonate the described in Appendix C.





Aboba & Simon                Informational                     [Page 12]





INTERNET-DRAFT           EAP peer or server the MK and TEKs MUST remain
     local to the Key Mgmt. Framework           9 August 2003


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         ---+
|                                                         |            ^
|                EAP method and MUST NOT be provided to third parties.
     In addition, the MK MUST NOT be derivable from material exported
     from the Method                               |            |
|                                                         |            |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |            |
| |                                       |               |            |
| |           EAP method, such as the MSK, EMSK or IV.  The MK MUST NOT
     be directly used Method Key              |               |            |
| |             Derivation                |               |            |
| |                                       |               |  Local to protect data; rather the TEKs and TSKs are used
     for this purpose.

MSK, EMSK and IV  |
| |                                       |               |       EAP methods supporting key derivation MUST export two 64 octet
     quantities, known as the Master Session Key (MSK), and the Extended
     Master Session Key (EMSK) and MAY export a 64 octet quantity known
     as the IV. It must be demonstrated that possession of the MSK, EMSK
     or IV does not provide information useful in determining the MK.

Cryptographic separation
     Methods supporting key derivation MUST demonstrate cryptographic
     separation between the TEK, MSK,  |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |     Method |
|   |             |               |                       |            |
|                                                         |            |
|   |             |               |                       |            |
|                                                         |            |
|   V             |               |                       |            |
| +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ |            |
| |  TEK      | | MSK       | |EMSK       | |IV         | |            |
| |Derivation | |Derivation | |Derivation | |Derivation | |            |
| +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ |            |
|                 |               |                 |     |            |
|                 |               |                 |     |            V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         ---+
                  |               |                 |                  ^
                  |               |                 |                  |
                  | MSK (64B)     | EMSK and (64B)      | IV branches of the (64B)         |
                  |               |                 |          Exported|
                  |               |                 |              by  |
                  V               V                 V              EAP
     key hierarchy.  Without violating a fundamental cryptographic
     assumption (such as the non-invertibility of a one-way function) an
     attacker recovering the TEK, MSK, EMSK or IV MUST NOT be able to
     recover the other quantities with a level of effort less than brute
     force.  Since |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+  Method|
          |          AAA  Key Derivation,     | | Known       |        |
          |          Naming & Binding         | |(Not Secret) |        |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+        V
                  |                                                 ---+
                  |                                        Transported |
                  | AAA-Key                                     by AAA |
                  |                                           Protocol |
                  V                                                    V
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                    ---+
   |                           |                                       ^
   |            TSK            |                           Ciphersuite |
   |        Derivation         |                              Specific |
   |                           |                                       V
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                    ---+

Figure 2 - EAP Key Hierarchy





Aboba & Simon                Informational                     [Page 13]





INTERNET-DRAFT           EAP Key Mgmt. Framework           9 August 2003


Transient Session Keys (TSKs)
     Session keys used to protect data which are derived from appropriate for the
     MSK, if branch independence holds, then it is also true that
     ciphersuite negotiated between the EAP peer and authenticator. The
     TSKs are cryptographically separate derived from the EMSK, IV and TEKs.

EMSK reservation
     While keying material included in the EMSK AAA-Token
     via the secure association protocol.  In the case of IEEE 802.11,
     the role of the secure association protocol is exported handled by the 4-way
     handshake and group key derivation.  An example TSK derivation is
     provided in Appendix D.

2.3.  Exchanges

EAP supports both a two party exchange between an EAP peer and an
authenticator, as well as a three party exchange between an EAP peer, an
authenticator and an EAP server.

Figure 3 illustrates the two party exchange. Here EAP method, its use is reserved, spoken between
the peer and authenticator, encapsulated within a lower layer protocol,
such as PPP, defined in [RFC1661] or IEEE 802, defined in [IEEE802].

Since the authenticator acts as an endpoint of the EAP conversation
rather than a result it MUST remain known only to pass-through, EAP methods are implemented on the
authenticator as well as the peer.  If the EAP method negotiated between
the EAP peer and
     server authenticator supports mutual authentication and MUST NOT be provided to third parties. Since key
derivation, the EMSK is EAP Master Session Key (MSK) and Extended Master Session
Key (EMSK) are derived on the only keying material EAP peer and authenticator and exported by an
the EAP method that method.

Where no backend authentication server is present, the MSK and EMSK are
known only to the peer and authenticator and neither
     provided is transported to a
third party nor a known quantity, it is attractive
     for use party.  As demonstrated in future applications such as [RoamCERT], despite the absence of a
backend authentication server, such exchanges can support roaming
between providers; it is even possible to support fast handoff or man-in-the-
     middle detection. Given its potential future uses, damage due to
     EMSK compromise without
re-authentication.  However, this is second typically only in effect to compromise of possible where both
the MK,
     yielding an attacker EAP peer and authenticator support certificate-based authentication,
or where the ability user base is sufficiently small that EAP authentication can
occur locally.

In order to access protect the network at will, and
     to decrypt past and future data traffic.

Ciphersuite Independence
     The MK, MSK, EMSK and IV derivations MUST be independent of EAP conversation, the



Aboba & Simon                Informational                     [Page 15]





INTERNET-DRAFT EAP Keying Framework              2 March 2003


     selected ciphersuite.

Key Strength
     The strength of Transient Session Keys (TSKs) method may negotiate a
ciphersuite and derive Transient EAP Keys (TEKs) used to provide keys for
that ciphersuite in order to protect data is ultimately dependent on the
     strength some or all of the MK, MSK and EMSK generated by the EAP method.  If exchange.
The TEKs are stored locally within the EAP method does and are not produce an MK, MSK exported.

Once EAP mutual authentication completes and EMSK of sufficient
     strength, then is successful, the TSKs secure
association protocol is run between the peer and TEKs may be subject to brute force
     attack.  EAP methods supporting key derivation MUST be capable authenticator.  This
derives fresh transient session keys (TSKs), provides for the secure
negotiation of
     generating a MK, MSK the ciphersuite used to protect data, and EMSK, each with an effective key strength supports mutual
proof of at least 128 bits. More details on key strength are provided in
     Section 5.3.

Perfect Forward Secrecy
     An possession of the AAA-Key.




Aboba & Simon                Informational                     [Page 14]





INTERNET-DRAFT           EAP Key Mgmt. Framework           9 August 2003


+-+-+-+-+-+               +-+-+-+-+-+
|         |               |         |
|         |               |         |
| Cipher- |               | Cipher- |
| Suite   |               | Suite   |
|         |               |         |
+-+-+-+-+-+               +-+-+-+-+-+
    ^                         ^
    |                         |
    |                         |
    |                         |
    V                         V
+-+-+-+-+-+               +-+-+-+-+-+
|         |               |         |
|         |===============|         |
|         |EAP, TEK Deriv.|Authenti-|
|         |<------------->| cator   |
|         |               |         |
|         | Secure Assoc. |         |
| peer    |<------------->| (EAP    |
|         |===============| server) |
|         | Link layer    |         |
|         | (PPP,IEEE802) |         |
|         |               |         |
|MSK,EMSK |               |MSK,EMSK |
| (TSKs)  |               |  (TSKs) |
|         |               |         |
+-+-+-+-+-+               +-+-+-+-+-+
    ^                         ^
    |                         |
    | MSK, EMSK               | MSK, EMSK
    |                         |
    |                         |
+-+-+-+-+-+               +-+-+-+-+-+
|         |               |         |
|  EAP    |               |  EAP    |
|  Method |               |  Method |
|         |               |         |
|(MK,TEKs)|               |(MK,TEKs)|
|         |               |         |
+-+-+-+-+-+               +-+-+-+-+-+

Figure 3 - Relationship between EAP peer and server may simultaneously derive MSKs suitable for
     use with several authenticators, so authenticator
           (acting as to enable fast handoff
     between them.  Similarly an EAP server may transport MSKs to
     multiple authenticators as the result of a single authentication.
     Where server), where no backend
           authentication server is present, transport
     typically occurs via an Inter-Access Point Protocol (IAPP), such as
     [IEEE80211f]. Where a backend authentication server is present, key
     transport is provided by the AAA protocol, such as Diameter
     [DiamEAP] or RADIUS [RFC2869bis]. present.






Aboba & Simon                Informational                     [Page 15]





INTERNET-DRAFT           EAP Key wrap mechanisms for Diameter
     are specified in [DIAMCMS], and Mgmt. Framework           9 August 2003


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

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








Aboba & Simon                Informational                     [Page 16]





INTERNET-DRAFT           EAP Key Mgmt. Framework           9 August 2003


Where these conditions cannot be met, a backend authentication server is
typically required.  In this exchange, as described in [RFC3579], 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 to the backend authentication server, which acts
as a Key Distribution Center (KDC), supplying keying material to both
the EAP peer and authenticator.

Figure 4 illustrates the case where the authenticator acts as a pass-
through.  Here EAP is spoken between the peer and authenticator as
before.  The authenticator then encapsulates EAP packets within a AAA
protocol such as RADIUS [RFC3579] or Diameter [DiamEAP], 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
(as well as the derived EAP Master Key, and TEKs) reside only on the
peer and backend authentication server.

On completion of a successful authentication, EAP methods on the EAP
peer and EAP server export the Master Session Key (MSK) and Extended
Master Session Key (EMSK).  The backend authentication server then sends
a message to the authenticator indicating that authentication has been
successful, providing the AAA-Key within a protected package known as
the AAA-Token.  Along with the keying material, the AAA-Token contains
attributes naming the enclosed keys and providing context.

The MSK and EMSK are used to derive the AAA-Key and key name which are
enclosed within the AAA-Token, transported to the  NAS by the AAA
server, and used within the secure association protocol for derivation
of Transient Session Keys (TSKs) required for the negotiated
ciphersuite.  The TSKs are known only to the peer and authenticator.





















Aboba & Simon                Informational                     [Page 17]





INTERNET-DRAFT           EAP Key Mgmt. Framework           9 August 2003


2.4.  Security Relationships

Figure 5 illustrates the relationship between the peer, authenticator
and backend authentication server.  As noted in the figure, each party
in the exchange mutually authenticates with each of the other parties,
and derives a unique key. All parties in the diagram have access to the
AAA-Key.

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

Figure 5:  Three-party EAP key distribution

The EAP peer and backend authentication server mutually authenticate via
the EAP method, and derive the MK, TEKs and EMSK which are known only to
them.  The TEKs are used to protect some or all of the EAP conversation
between the peer and authenticator, so as to guard against modification
or insertion of EAP packets by an attacker. The degree of protection
afforded by the TEKs is determined by the EAP method; some methods may
protect the entire EAP packet, including the EAP header, while other
methods may only protect the contents of the Type-Data field, defined in
[RFC2284bis].

Since EAP is spoken only between the EAP peer and server, if a backend
authentication server is present then the EAP conversation does not
provide mutual authentication between the peer and authenticator, only
between the EAP peer 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
of the peer, EAP mutual authentication only proves that the
authenticator is trusted by the backend authentication server; the
identity 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,



Aboba & Simon                Informational                     [Page 18]





INTERNET-DRAFT           EAP Key Mgmt. Framework           9 August 2003


authentication and confidentiality. The MSK is distributed by the
backend authentication server to the authenticator over this channel,
bound to attributes constraining its usage, as part of the AAA-Token.
The binding of attributes to the MSK within a protected package is
important so the authenticator receiving the AAA-Token can determine
that it has not been compromised, and that the keying material has not
been replayed, or mis-directed in some way.

3.  Security Associations

The EAP model has four types of security associations (SAs):

[1]  An EAP SA.  This is an SA between the EAP peer and the EAP server,
     created as the result of an EAP authentication exchange (phase 1a).
     This is a bi-directional SA; that is, both parties use the
     information in the SA for both sending and receiving.

[2]  A AAA-Key SA, known in [IEEE80211i] as a PMK SA.  This is a bi-
     directional SA between the EAP peer and authenticator.  The keying
     material for the AAA-Key SA (known as the AAA-Key) is derived on
     the EAP peer and server, and transported by the EAP server to the
     authenticator (phase 1b).  The choice of keying material is
     proposed by the EAP peer and confirmed by the EAP authenticator
     during the unicast secure association protocol (phase 2a).

[3]  A unicast secure association SA.  This is a bi-directional SA
     created  as the result of a successful unicast secure association
     exchange (phase 2a). A unicast secure association SA is bound to a
     single EAP SA and a single AAA-Key SA.

[4]  A multicast secure association SA (phase 2b).  This SA is created
     as the result of a successful multicast secure association
     exchange.  This SA may be uni-directional (e.g. 802.11 group-key
     exchange) or bi-directional depending on the design of the
     multicast secure association protocol, and can be created either
     from the unicast secure association SA (phase 2a) or directly as
     the result of a multicast secure association exchange (phase 2b).

3.1.  EAP SA

An EAP SA includes:

   the EAP peer and EAP server identities
   the EAP method type
   the EAP peer and server nonces
   the Transient EAP Keys (TEKs)
   the Master Session Key (MSK)
   the Extended Master Session Key (EMSK)



Aboba & Simon                Informational                     [Page 19]





INTERNET-DRAFT           EAP Key Mgmt. Framework           9 August 2003


The EAP SA is not explicitly bound to a particular port on the EAP peer.
An EAP peer with multiple ports may create an EAP SA on one port and
then choose to use that SA to subsequently create a phase 2 SA on
another port.

It cannot be assumed that the EAP SA expires after the EAP
authentication and key derivation is complete.  Some methods may be
support "fast resume" by caching EAP SA state on the EAP peer and
server.

EAP does not support SA lifetime negotiation or an SA "delete"
operation, although some EAP methods may support this.  Either the EAP
peer or EAP server may delete an EAP SA at any time, and methods which
allow an EAP SA to persist need to permit the EAP peer and server to
recognize when they have gotten out of sync with respect to the EAP SA
state.

For example, EAP TLS [RFC 2716] supports "fast resume" (TLS session
resumption), which assumes that both the EAP peer and server cache EAP
master keys (the TLS master secret).  An EAP peer attempting a fast
resume provides the session-id identifying the session that it wishes to
resume.  If the EAP server retains the master key corresponding to this
session in its cache, then the "fast resume" can proceed; otherwise a
full TLS exchange ensues.

An EAP peer may negotiate EAP SAs with one or more EAP servers as the
result of pre-authentication or AAA load balancing and failover effects.
For example, an EAP peer may pre-authenticate to one or more EAP
servers, or may be directed to more than one EAP server as the result of
an authentication server becoming unreachable.  In general, EAP servers
cannot be assumed to be synchronized with respect to EAP SA state,
particularly since they may not exist within the same administrative
domain.  Since an EAP SA is typically created prior to secure
association, the EAP SA is not bound to a particular target network.

3.2.  AAA-Key SA

An AAA-Key SA includes:

   the EAP peer (Calling-Station-Id) identifier
   the EAP authenticator (Called-Station-Id) identifier
   the AAA-Key
   the AAA-Key maximum lifetime (if known)
   the advertised peer and authenticator capabilities

The AAA-Key SA is created as the result of the transport of the AAA-
Token from the authentication server to the NAS/authenticator.  The AAA-
Key SA is distinct from the EAP SA in that it is bound to the EAP peer



Aboba & Simon                Informational                     [Page 20]





INTERNET-DRAFT           EAP Key Mgmt. Framework           9 August 2003


and authenticator ports.  This binding occurs during the unicast secure
association protocol (phase 2a) when the EAP peer and authenticator
prove possession of the AAA-Key, which is transported from the
authentication server to the NAS/EAP authenticator after completion of
EAP authentication.

Since the AAA-Key SA is bound to a particular authenticator port, a
NAS/authenticator that operates on a shared use network will share the
AAA-Key SA between multiple virtual NAS devices unless a separate port
(as identified by the Called-Station-Id) is used for each virtual NAS.
This would represent a security vulnerability.

In fast handoff, a single EAP SA may be used to establish multiple AAA-
Key SAs (see Appendix E for details).  Although a AAA-Key SA may not
persist longer than the maximum SA lifetime negotiated for an EAP SA
(for methods that support such a negotiation), if an EAP SA is deleted
by an EAP peer or authenticator, this does not necessarily imply
deletion of the child AAA-Key SA.  For example, fast handoff keying
material provided by an authentication server may continue to be cached
by NASes/authenticators after the corresponding EAP SA has been deleted
by the authentication server and/or peer.

3.3.  Unicast Secure Association SA

The unicast secure association SA includes:

   the EAP peer (Calling-Station-Id) identifier
   the EAP authenticator (Called-Station-Id) identifier
   the unicast Transient Session Keys (TSKs)
   the unicast secure association peer nonce
   the unicast secure association authenticator nonce
   the negotiated unicast capabilities and unicast ciphersuite.

During the phase 2a exchange, the EAP peer and authenticator demonstrate
mutual possession of the AAA-Key derived and transported in phase 1;
securely negotiate the session capabilities (including unicast
ciphersuites), and derive fresh unicast transient session keys.  The
AAA-Key SA (phase 1b) is therefore used to create the unicast secure
association SA (phase 2a), and in the process the phase 2a unicast
secure association SA is bound to ports on the EAP peer and
authenticator.  However in order for a phase 2a security association to
be established, it is not necessary for the phase 1a exchange to be
rerun each time.  This enables the EAP exchange to be bypassed when fast
handoff support is desired.

Since both peer and authenticator nonces are used in the creation of the
unicast secure association SA,  the transient session keys (TSKs) are
guaranteed to be fresh, even if the AAA-Key is not.  As a result one or



Aboba & Simon                Informational                     [Page 21]





INTERNET-DRAFT           EAP Key Mgmt. Framework           9 August 2003


more unicast secure association SAs (phase 2a) may be derived from a
single AAA-Key SA (phase 1b).  The phase 2a security associations may
utilize the same security parameters (e.g. mode, ciphersuite, etc.) or
they may utilize different parameters.

A unicast secure association SA (phase 2a) may not persist longer than
the maximum lifetime of its parent AAA-Key SA (if known). However, the
deletion of a parent EAP or AAA-Key SA does not necessarily imply
deletion of the corresponding unicast secure association SA.  Similarly,
the deletion of a unicast secure association protocol SA does not imply
the deletion of the parent AAA-key SA or EAP SA.  However, the failure
to mutually prove possession of the AAA-Key during the unicast secure
association protocol exchange (phase 2a) is grounds for removal of a
AAA-Key SA by both parties.

An EAP peer may be able to negotiate multiple phase 2a SAs with a single
EAP authenticator, or may be able to maintain multiple phase 2a SAs with
multiple authenticators, based on a single EAP SA derived in phase 1a.
For example, during a re-key of the secure association protocol SA, it
is possible for two phase 2a SAs to exist during the period between when
the new phase 2a SA parameters (such as the TSKs) are calculated and
when they are installed. Except where explicitly specified by the
semantics of the unicast secure association protocol, it should not be
assumed that the installation of a new phase 2a SA necessarily implies
deletion of the old phase 2a SA.

On some media (e.g. 802.11) a port on an EAP peer may only establish
phase 2a and 2b SAs with a single port of an authenticator within a
given Local Area Network (LAN).  This implies that the successful
negotiation of phase 2a and/or 2b SAs between an EAP peer port and a new
authentiator port within a given LAN implies the deletion of existing
phase 2a and 2b SAs with authenticators offering access to that Local
Area Network (LAN).  However, since a given IEEE 820.11 SSID may be
comprised of multiple LANs, this does not imply an implicit binding of
phase 2a and 2b SAs to an SSID.

3.4.  Multicast Secure Association SA

The multicast secure association SA includes:

   the multicast Transient Session Keys
   the direction vector (for a uni-directional SA)
   the negotiated multicast capabilities and multicast ciphersuite

It is possible for more than one multicast secure association SA to be
derived from a single unicast secure association SA.   However, a
multicast secure association SA is bound to a single EAP SA and a single
AAA-Key SA.



Aboba & Simon                Informational                     [Page 22]





INTERNET-DRAFT           EAP Key Mgmt. Framework           9 August 2003


During a re-key of the multicast secure association protocol SA, it is
possible for RADIUS in [RFC2548]. two phase 2b SAs to exist during the period between when
the new phase 2b SA parameters (such as the multicast TSKs) are
calculated and when they are installed. Except where explicitly
specified by the semantics of the multicast secure association protocol,
it should not be assumed that the installation of a new phase 2b SA
necessarily implies deletion of the old phase 2b SA.

A multicast secure association SA (phase 2b) may not persist longer than
the maximum lifetime of its parent AAA-Key or unicast secure association
SA.  However, the deletion of a parent EAP, AAA-Key or unicast secure
association SA does not necessarily imply deletion of the corresponding
multicast secure association SA.  For example, a unicast secure
association SA may be rekeyed without implying a rekey of the multicast
secure association SA.

Similarly, the deletion of a multicast secure association protocol SA
does not imply the deletion of the parent EAP, AAA-Key or unicast secure
association SA.  However, the failure to mutually prove possession of
the AAA-Key during the unicast secure association protocol exchange
(phase 2a) is grounds for removal of the AAA-Key, unicast secure
association and multicast secure association SAs.

3.5.  Key Naming

In order to support the correct processing of phase 2 security
associations, the secure association (phase 2) protocol supports the
naming of phase 2 security associations and associated transient session
keys, so that the correct set of transient session keys can be
identified for processing a given packet.  Explicit creation and
deletion operations are also typically supported so that establishment
and re-establishment of transient session keys can be synchronized
between the parties.

In order to securely bind the EAP security association (phase 1) to its
child phase 2 security association, the phase 2 secure association
protocol allows the EAP peer and authenticator to mutually prove
possession of the EAP (phase 1) keying material derived during the EAP
exchange (phase 1).  In order to protect against compromise avoid confusion in the case where an
EAP peer has more than one EAP security association (phase 1) applicable
to establishment of a given phase 2 security association, the secure
association protocol (phase 2) supports key naming so that the
appropriate phase 1 keying material can be utilized by both parties in
the secure association protocol exchange.

As noted earlier, the discovery phase (phase 0) may be insecure so that
in order to prevent spoofing of discovery packets, the secure
association (phase 2) protocol should support the secure verification of



Aboba & Simon                Informational                     [Page 23]





INTERNET-DRAFT           EAP Key Mgmt. Framework           9 August 2003


discovered capabilities, including ciphersuites and other security
parameters.  This is more scalable than attempting to configure the
supported capabilities on each peer and authenticator and more secure
than unprotected capabilities negotiation.

For example, a peer might be pre-configured with policy indicating the
ciphersuite to be used in communicating with a given authenticator.
Within PPP, the ciphersuite is negotiated within the Encryption Control
Protocol (ECP), after EAP authentication is completed. Within
[IEEE80211i], the AP ciphersuites are advertised in the Beacon and Probe
Responses, and are securely verified during a 4-way exchange after EAP
authentication has completed.

As part of the secure association protocol (phase 2), it is necessary to
bind the Transient Session Keys (TSKs) to the keying material provided
in the AAA-Token.  This ensures that the EAP peer and authenticator are
both clear about what key to use to provide mutual proof of possession.
Keys within the EAP key hierarchy are named as follows:

EAP SA name
     The EAP security association is negotiated between the EAP peer and
     EAP server, and is uniquely named as follows <EAP peer name, EAP
     server name, EAP Method Type, EAP peer nonce, EAP server nonce>.
     Here the EAP peer name and EAP server name are the identifiers
     securely exchanged within the EAP method.  Since multiple EAP SAs
     may exist between an individual MSK,
     Perfect Forward Secrecy (PFS) SHOULD EAP peer and EAP server, the EAP peer nonce
     and EAP server nonce allow EAP SAs to be supported, so differentiated.  The
     inclusion of the Method Type in the EAP SA name ensures that
     compromise each
     EAP method has a distinct EAP SA space.

MK Name
     The EAP Master Key, if supported by an EAP method, is named by the
     concatenation of one the EAP SA name and a method-specific session-id.

MSK does not enable compromise Name
     The MSK is named by the concatenation of subsequent or
     prior MSKs.

Uniqueness
     In order the EAP SA name, "MSK" and
     the authenticator name, since the MSK may only be bound to assure non-repetition a single
     authenticator.  While the AAA server has several potentially unique
     authenticator identifiers (including the NAS-Identifier, NAS-IP-
     Address, and NAS-IPv6-Address attributes), only the Called-Station-
     Id is guaranteed to be known by the EAP peer, EAP server and
     authenticator and as a result, this is used as the NAS name.

EMSK Name
     The EMSK is named by the concatenation of TSKs even in cases the EAP SA name and
     "EMSK".





Aboba & Simon                Informational                     [Page 24]





INTERNET-DRAFT           EAP Key Mgmt. Framework           9 August 2003


4.  Threat Model

4.1.  Security Assumptions

The security properties of the EAP exchange are dependent on each leg of
the triangle: the selected EAP method, AAA protocol and the secure
association protocol.

Assuming that the 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 one
     party may it is wrapped
appropriately, it can be assumed to be immune to compromise by a
snooping attacker.

Where an untrusted AAA intermediary is present,  the AAA-Token must not have a high quality random number generator,
be provided to the MSK
     derivation SHOULD include a two-way nonce exchange, using nonces intermediary so as to avoid compromise of
     at least 128-bits. Note although the [IEEE80211i] 4-way handshake
     includes a nonce exchange, this AAA-
Token.  This can be avoided by use of re-direct as defined in
[DiamBase].

When EAP is not the case used for all
     ciphersuites and media, authentication on PPP or wired IEEE 802 networks,
it is typically assumed that the link is physically secure, so that to provide media independence, an
     EAP method
attacker cannot assume that a nonce exchange is guaranteed gain access to
     occur the link, or insert a rogue device.  EAP
methods defined in [RFC2284bis] reflect this usage model.  These include
EAP MD5, as part of TSK well as One-Time Password (OTP) and Generic Token Card.
These methods support one-way authentication (from EAP peer to
authenticator) but not mutual authentication or key derivation.  A nonce exchange SHOULD also be
     included in  As a
result, these methods do not bind the derivation of initial authentication and
subsequent data traffic, even when the TEKs from the MK.

Known-good algorithms
     The development ciphersuite used to protect
data supports per-packet authentication and integrity protection.  As a
result, 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 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 and replay
protection.  In addition, mutual authentication and validation of key derivation algorithms is
     difficult, and as a result EAP derivation,
provided by methods SHOULD reuse existing key
     derivation algorithms, rather than inventing new ones. such as EAP methods
     requesting publication TLS [RFC2716] are required [IEEE80211i],
so as an RFC MUST provide citations to
     literature justifying address the security threat of rogue devices, and provide keying
material to bind the chosen algorithms. initial authentication to subsequent data traffic.

If the selected EAP
     methods SHOULD utilize well established method does not support mutual authentication, then
the peer will be vulnerable to attack by rogue authenticators and analyzed mechanisms
backend authentication servers.  If the EAP method does not derive keys,
then TSKs will not be available for use with a negotiated ciphersuite,
and there will be no binding between the initial EAP authentication and
subsequent data traffic, leaving the session vulnerable to hijack.



Aboba & Simon                Informational                     [Page 16] 25]





INTERNET-DRAFT           EAP Keying Key Mgmt. Framework              2 March           9 August 2003


     MK, MSK, EMSK and IV derivation.

4.2.  AAA protocol requirements

AAA protocols suitable for use in transporting EAP MUST provide


If the
following facilities:

Security services
     AAA protocols used for transport of EAP MUST support per-packet
     integrity and authentication and SHOULD support replay protection
     and confidentiality.  These requirements are met by Diameter EAP
     [DiamEAP], as well as RADIUS over IPsec [RFC2869bis].

Session Keys
     AAA protocols used for transport of EAP SHOULD provide per-packet
     security services using session keys, as in Diameter EAP [DiamEAP] authenticator and RADIUS over IPsec [RFC3162], rather than using a static key, as
     in RADIUS [RFC2865].

Mutual backend authentication
     AAA protocols used for transport of EAP MUST support mutual server do not mutually
authenticate, then the peer will be vulnerable to rogue backend
authentication servers, authenticators, or both.  If there is no per-
packet authentication, integrity and replay protection between the
authenticator and backend authentication
     server. These requirements are met by Diameter EAP [DiamEAP] as
     well as by RADIUS [RFC2865].

Forgery protection
     AAA protocols used for transport of EAP SHOULD provide protection
     against rogue authenticators masquerading as other authenticators.
     This server, then an attacker can be accomplished, for example, by requiring that AAA agents
     to check the source address of
spoof or modify packets against the origin
     attributes (Origin-Host AVP in Diameter, NAS-IP-Address, NAS-
     IPv6-Address, NAS-Identifier in RADIUS).

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

Key transport specification
     In order to enable backend authentication servers to does not protect against authenticator masquerade, or provide keying
     material the
proper binding of the AAA-Key to the authenticator in a well defined format, AAA
     protocols suitable for use with EAP MUST define session within the format AAA-Token, then
one or more AAA-Keys may be sent to an unauthorized party, and
     wrapping of an
attacker may be able to gain access to the package within which network. If the MSK AAA-Token is transported, known
     as the AN-Token. The definition of
provided to an untrusted AAA intermediary, then that intermediary may be
able to modify the AN-Token MUST include AAA-Key, or the
     definition of attributes binding the key to the appropriate
     session, and providing limitations on key usage, such associated with it, as
described in [RFC2607].

If the
     indicated key lifetime.



Aboba & Simon                Informational                     [Page 17]





INTERNET-DRAFT            EAP Keying Framework              2 March 2003


EMSK exposure
     Since secure association protocol does not provide mutual proof of
possession of the EMSK AAA-Key material, then the peer will not have
assurance that it is a secret known only connected to the correct authenticator, only that
the authenticator and backend authentication server and peer, the share a trust
relationship (since AAA protocol MUST NOT transport the EMSK protocols support mutual authentication). This
distinction can become important when multiple authenticators receive
AAA-Keys from the backend authentication server to the authenticator.

AN-Token protection
     To ensure against compromise, server, such as where fast
handoff is supported. If the AN-Token MUST be integrity
     protected, authenticated, replay TSK derivation does not provide for
protected ciphersuite and encrypted in
     transit, using well-established cryptographic algorithms.  For
     example, the AN-Token SHOULD be protected with session keys as in
     Diameter CMS Security [DiamCMS] (a work in progress) or RADIUS over
     IPsec [RFC2869bis] rather than static keys, as in [RFC2548].

     Where untrusted intermediaries capabilities negotiation, then downgrade
attacks are present, possible.

4.2.  Security Requirements

This section describes the AN-Token SHOULD security requirements for EAP methods, AAA
protocols, secure association protocols and Ciphersuites. These
requirements MUST be
     protected met by data object security mechanisms, such specifications requesting publication as Diameter CMS
     Security [DiamCMS] (a work in progress).

4.3.  TSK derivation an
RFC. Based on these requirements, the security properties of EAP
exchanges are analyzed.

4.2.1.  EAP method requirements

The Transient Session

Key (TSK) derivation process is assumed usage
     Key material exported by EAP methods MUST NOT be used directly to
     protect data.

Mutual authentication
     EAP Methods deriving keys MUST provide for mutual authentication
     between the following:

Direct operation
     The TSK EAP peer and EAP Server.

State synchronization
     EAP peers, authenticators and authentication servers MUST be
     prepared for situations in which one or more of the parties have
     discarded an EAP SA (phase 1), which is still valid on another
     party.



Aboba & Simon                Informational                     [Page 26]





INTERNET-DRAFT           EAP Key Mgmt. Framework           9 August 2003


TEK derivation process
     Methods deriving keys MUST operate directly between specify how Transient EAP Keys (TEKs)
     are derived. TEKs MUST remain local to the peer
     and authenticator, EAP method and MUST NOT
     be passed-through provided to the backend
     authentication server.

Mutual authentication
     Where third parties.

MSK and EMSK
     EAP is used on link layers which cannot be assumed to be
     physically secure (e.g.  wireless, methods supporting key derivation MUST export two quantities of
     at least 64 octets each, known as the Internet), Master Session Key (MSK), and
     the TSK Extended Master Session Key (EMSK).

Cryptographic separation
     Methods supporting key derivation process MUST provide for mutual authentication demonstrate cryptographic
     separation between the authenticator TEK, MSK and peer.

Protected negotiation
     Where EMSK branches of the EAP is used on link layers which cannot key
     hierarchy.  Without violating a fundamental cryptographic
     assumption (such as the non-invertibility of a one-way function) an
     attacker recovering the TEKs, MSK or EMSK MUST NOT be assumed able to be
     physically secure (e.g. wireless,
     recover the Internet), other quantities with a level of effort less than brute
     force.  Since Transient Session Keys (TSKs) are derived from the TSK derivation
     process SHOULD support protected ciphersuite and capabilities
     negotiation.

Uniqueness
     Where MSKs may be cached on
     MSK, if branch independence holds, then it is also true that the authenticator
     TSKs are cryptographically separate from the EMSK and peer, TEKs.

EMSK reservation
     While the TSK
     derivation process MUST provide unique TSKs for each session, even
     where EMSK is exported by the MSK EAP method, its use is unchanged.








Aboba & Simon                Informational                     [Page 18]





INTERNET-DRAFT reserved,
     and as a result it MUST remain known only to the EAP Keying Framework              2 March 2003


4.4.  Ciphersuite requirements

Ciphersuites suitable for peer and
     server and MUST NOT be provided to third parties. Since the EMSK is
     the only keying material exported by an EAP methods MUST provide the
following facilities:

TSK derivation
     In order method that is neither
     provided to key a ciphersuite with EAP, third party nor a known quantity, it is necessary attractive
     for use in future applications such as fast handoff or man-in-the-
     middle detection.  Given its potential future uses, damage due to specify
     how the TSKs required by the ciphersuite are derived from the MSK.
     Derivation
     EMSK compromise is second only in effect to compromise of the TSKs from MK,
     yielding an attacker the MSK requires knowledge of ability to access the
     negotiated ciphersuite. network at will, and
     to decrypt past and future data traffic.

TEK derivation
     In order to establish a protected channel between the EAP peer and
     server as part of the EAP exchange, a ciphersuite needs to be
     negotiated and keyed, using TEKs derived from suitable keys need to be provided (known as the MK.
     transient EAP keys).  The ciphersuite used to protect the EAP
     exchange between the peer and server is distinct from the ciphersuite negotiated between the peer
     and authenticator, used to protect data.  Where a protected channel
     is established within the EAP method, the method specification MUST
     specify the mechanism by which the EAP ciphersuite is negotiated,
     as well as the algorithms for derivation of TEKs from the MK during
     the EAP authentication exchange.

EAP method independence
     Algorithms for deriving TSKs from the MSK MUST NOT depend on the
     EAP method. However, algorithms for deriving TEKs from the MK MAY
     be specific to the EAP method.

Cryptographic separation
     The TSKs derived from the MSK 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.

4.5.  Security properties

Given the requirements described in the previous sections, Figure 4
illustrates the relationship
     ciphersuite negotiated between the peer, authenticator peer and backend
authentication server.

As noted in authenticator, used to
     protect data.  Where a protected channel is established within the figure, each party in
     EAP method, the exchange mutually
authenticates with each of method specification MUST specify the other parties, and derives a unique key.
All parties in mechanism by
     which the diagram have access to EAP ciphersuite is negotiated, as well as the MSK. algorithms
     for derivation of TEKs.

Ciphersuite Independence
     Keying material exported by EAP methods MUST be independent of the
     ciphersuite negotiated to protect data.



Aboba & Simon                Informational                     [Page 19] 27]





INTERNET-DRAFT           EAP Keying Key Mgmt. Framework              2 March           9 August 2003


                   EAP peer
                      /\
                     /  \
 Protocol: EAP      /    \   Protocol: TSK derivation
 Auth: Mutual      /      \  Auth: Mutual
 Unique keys: MK, /        \ Unique keys: TSKs
  TEKs,EMSK      /          \
                /            \
  Auth. server +--------------+ Authenticator
                Protocol: AAA
                Auth: Mutual
             Unique key: AAA session key

Figure 4:  Three-party EAP key distribution


Key Strength
     The EAP peer strength of Transient Session Keys (TSKs) and backend authentication server mutually authenticate via
the Transient EAP method, and derive the MK, TEKs and EMSK which are known only to
them.  The TEKs are
     Keys (TEKs) used to protect some or all data is ultimately dependent on the
     strength of keys generated by the EAP conversation
between method.  If EAP method does
     not produce keying material of sufficient strength, then the peer TSKs
     and authenticator, so as TEKs may be subject to brute force attack.  EAP methods
     supporting key derivation MUST be capable of generating an MSK and
     EMSK, each with an effective key strength of at least 128 bits.
     More details on key strength are provided in Section 6.1.

Resilience against compromise
     In order to guard protect against modification
or insertion of EAP packets by an attacker. The degree compromise of protection
afforded by the TEKs is determined by the EAP method; some methods may
protect the entire EAP packet, including the AAA-Token, EAP header, while other
     methods may only protect the contents MUST demonstrate that compromise of the Type-Data field, defined in
[RFC2284bis].

Since EAP is spoken only between the peer and server, if MSK or EMSK of a backend
authentication server is present then the
     given EAP conversation security association does not
provide mutual authentication between the peer and authenticator, only enable compromise of
     subsequent or prior MSKs or EMSKs derived between the EAP peer and backend authentication
     EAP server. As a result, mutual
authentication between the peer

Freshness
     In order to support key naming and authenticator only occurs assure freshness of TSKs even in
     cases where one party may not have a
separate TSK derivation step is carried out, such as high quality random number
     generator, EAP methods generating keys MUST support a two-nonce
     exchange in [IEEE80211i].
This means that absent the TSK derivation step, from the point of view of the peer, EAP mutual authentication only proves that the
authenticator is trusted by the backend authentication server; the
identity 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 MSK and confidentiality. EMSK, using nonces of at
     least 128-bits.

Known-good algorithms
     The MSK development and validation of key derivation algorithms is distributed by the
backend authentication server to the authenticator over this channel,
bound to attributes constraining its usage,
     difficult, and as a result EAP methods SHOULD reuse existing key
     derivation algorithms, rather than inventing new ones. EAP methods
     requesting publication as part of the AN-Token. The
binding of attributes an RFC MUST provide citations to
     literature justifying the MSK within a protected package is important
so the authenticator receiving security of the AN-Token can determine that it has
not been compromised, chosen algorithms.  EAP
     methods SHOULD utilize well established and that the keying material has not been
replayed, or mis-directed analyzed mechanisms for
     MSK, EMSK, TSK and TEK derivation.

4.2.2.  AAA Protocol Requirements

AAA protocols suitable for use in some way.





Aboba & Simon                Informational                     [Page 20]





INTERNET-DRAFT transporting EAP Keying Framework              2 March 2003


Assuming that MUST provide the
following facilities:

Security services
     AAA protocol provides protection against rogue
authenticators forging their identity, then the AN-Token can be assumed
to be sent to the correct authenticator, protocols used for transport of EAP keying material MUST
     implement and where it is wrapped
appropriately, it can be assumed to be immune to compromise by a
snooping attacker.

Where an untrusted AAA intermediary is present, data object security SHOULD be used to encrypt, authenticate, use per-packet integrity and authentication,
     replay protect
the AN-Token, so that it cannot be compromised or modified by the
intermediary.

The TSK derivation step varies by ciphersuite. On link layers that
cannot be assumed to be physically secure, the peer protection and authenticator
SHOULD mutually authenticate confidentiality.  These requirements are met
     by proving mutual possession Diameter EAP [DiamEAP], as well as RADIUS over IPsec [RFC3579].

Session Keys
     AAA protocols used for transport of all or EAP keying material MUST
     implement and SHOULD use  session keys, as in Diameter EAP
     [DiamEAP] and RADIUS over IPsec [RFC3579], rather than using a
portion



Aboba & Simon                Informational                     [Page 28]





INTERNET-DRAFT           EAP Key Mgmt. Framework           9 August 2003


     static key, as originally defined in RADIUS [RFC2865].

Mutual authentication
     AAA protocols used for transport of the MSK. It is also advisable EAP keying material MUST
     provide for mutual authentication between the TSK derivation step to
support protected ciphersuite and capabilities negotiation, authenticator and derive
TSKs which
     backend authentication server.  These requirements are guaranteed to be unique met by
     Diameter EAP [DiamEAP] as well as by RADIUS/EAP [RFC3579].

Forgery protection
     AAA protocols used for each session. transport of EAP keying material SHOULD
     provide protection against rogue authenticators masquerading as
     other authenticators.  This provides
assurance to the peer that it is connecting to the correct
authenticator, that the capabilities and offered ciphersuites have not
been forged, and can be accomplished, for example, by
     requiring that AAA agents check the TSKs are fresh.

5.  Security considerations

5.1.  Assumptions

The security properties source address of packets
     against the EAP exchange are dependent on each leg origin attributes (Origin-Host AVP in Diameter, NAS-IP-
     Address, NAS-IPv6-Address, NAS-Identifier in RADIUS).  For details,
     see Section 4.3.7 of
the triangle: the selected [RFC3579].

Key transport
     Since EAP method, AAA protocol methods do not export Transient Session Keys (TSKs) in
     order to maintain media and TSK derivation
mechanism.

If ciphersuite independence, the selected EAP method does not support mutual authentication, then AAA
     server MUST NOT transport TSKs from the peer will be vulnerable backend authentication
     server to attack by rogue authenticators and authenticator.

Key transport specification
     In order to enable backend authentication servers.  If servers to provide keying
     material to the EAP method does not derive keys,
then TSKs will not be available for use with authenticator in a negotiated ciphersuite,
and there will be no binding between the initial well defined format, AAA
     protocols suitable for use with EAP authentication MUST define the format and
subsequent data traffic, leaving
     wrapping of the session vulnerable AAA-Token.

EMSK transport
     Since the EMSK is a secret known only to hijack.

If the authenticator and backend authentication
     server do not mutually
authenticate, then and peer, the AAA-Token MUST NOT transport the EMSK from the peer will be vulnerable to rogue
     backend authentication servers, authenticators, or both.  If there is no per-
packet authentication, server to the authenticator.

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

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

Key naming
     In order to ensure against confusion between the
authenticator appropriate keying
     material to be used in a given secure association protocol
     exchange, the AAA-Token SHOULD include explicit key names and backend authentication server, then an attacker



Aboba & Simon                Informational                     [Page 29]





INTERNET-DRAFT           EAP Key Mgmt. Framework           9 August 2003


     context appropriate for informing the authenticator how the keying
     material is to be used.

Key Compromise
     Where untrusted intermediaries are present, the AAA-Token SHOULD
     NOT be provided to the intermediaries.  In Diameter, handling of
     keys by intermediaries can
spoof or modify packets in transit.  If be avoided using Redirect functionality
     [DiamBASE].

4.2.3.  Secure Association Protocol Requirements

The Secure Association Protocol supports the backend authentication following:

Mutual proof of possession
     The peer and authenticator MUST each demonstrate possession of the
     keying material transported between the AAA server does not protect against and
     authenticator masquerade, or provide (AAA-Key).

Key Naming
     The Secure Association Protocol MUST explicitly name the
proper binding of keys used
     in the MSK proof of possession exchange, so as to the session within the AN-Token, then one
or prevent confusion
     when more MSKs may be sent to an unauthorized party, and an attacker may than one set of keying material could potentially be able to gain access to used
     as the network. If basis for the AN-Token is not opaque to
an untrusted AAA intermediary, then that intermediary may be able exchange.

Creation and Deletion
     In order to
modify the MSK, or support the attributes associated with it, as described in



Aboba & Simon                Informational                     [Page 21]





INTERNET-DRAFT            EAP Keying Framework correct processing of phase 2 March 2003


[RFC2607].

If security
     associations, the TSK derivation algorithm does not secure association (phase 2) protocol MUST
     support mutual authentication,
then the peer will not have assurance naming of phase 2 security associations and associated
     transient session keys, so that it is connected to the correct authenticator, only set of transient
     session keys can be identified for processing a given packet.  The
     phase 2 secure association protocol also MUST support transient
     session key activation and SHOULD support deletion, so that
     establishment and re-establishment of transient session keys can be
     synchronized between the authenticator parties.

Integrity and backend
authentication server share a trust relationship (assuming that Replay Protection
     The Secure Association Protocol MUST support integrity and replay
     protection of all messages.

Direct operation
     Since the AAA phase 2 secure association protocol supports mutual authentication). This distinction can become
important when multiple authenticators receive MSKs from the backend
authentication server, such as where fast handoff is supported. If concerned with the
TSK derivation does not provide for protected ciphersuite and
capabilities negotiation, then downgrade attacks are possible.

5.2.  Key binding

Both
     establishment of security associations between the RADIUS EAP peer and Diameter protocols are potentially vulnerable to
impersonation by a rogue authenticator.

When RADIUS requests are forwarded by a proxy, the NAS-IP-Address or
NAS-IPv6-Address attributes may not correspond
     authenticator, including the derivation of transient session keys,
     only those parties have "a need to know" the source address.
Since transient session
     keys.  The secure association protocol MUST operate directly
     between the NAS-Identifier attribute need not contain an FQDN, it also may
not correspond peer and authenticator, and MUST NOT be passed-through
     to the source address, even indirectly.  [RFC2865]
Section 3 states:

   A RADIUS server backend authentication server, or include additional
     parties.



Aboba & Simon                Informational                     [Page 30]





INTERNET-DRAFT           EAP Key Mgmt. Framework           9 August 2003


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 source IP address negotiated ciphersuite.

TSK freshness
     The secure association (phase 2) protocol MUST support the
     derivation of fresh unicast and multicast transient session keys,
     even when the RADIUS
   UDP packet to decide which shared secret to use, so that
   RADIUS requests can be proxied. keying material provided by the AAA server is not
     fresh.  This implies that it is possible for a rogue authenticator to forge NAS-
IP-Address, NAS-IPv6-Address or NAS-Identifier attributes typically supported by including an exchange of
     nonces within the secure association protocol.

Bi-directional operation
     While some ciphersuites only require a
RADIUS Access-Request in order single set of transient
     session keys to impersonate another authenticator.
Among other things, this can result protect traffic in messages (and MSKs) being sent to
the wrong authenticator.  Since the rogue authenticator is authenticated
by the RADIUS proxy or server purely based on the source address, both directions, other
mechanisms are required to detect the forgery.  In addition, it is
possible
     ciphersuites require a unique set of transient session keys in each
     direction.  The phase 2 secure association protocol SHOULD provide
     for attributes such as the Called-Station-Id derivation of unicast and Calling-
Station-Id to be forged multicast keys in each direction,
     so as well.

As recommended not to require two separate phase 2 exchanges in [RFC2869bis], this vulnerability can be mitigated by
having RADIUS proxies check authenticator identification attributes
against the source address.

To allow verification of session order to
     create a bi-directional phase 2 security association.

Secure capabilities negotiation
     The Secure Association Protocol MUST support secure capabilities
     negotiation. This includes security parameters such as the Called-Station-
Id security
     association identifier (SAID) and Calling-Station-Id, they can be sent by ciphersuites.  It also includes
     confirmation of the EAP peer capabilities discovered during the discovery
     phase (phase 0), so as to ensure that the
server, and protected announced capabilities
     have not been forged.

4.2.4.  Ciphersuite Requirements

Ciphersuites suitable for keying by TEKs.  The RADIUS server can then check EAP methods MUST provide the
parameters sent by
following facilities:

TSK derivation
     In order to allow a ciphersuite to be usable within the EAP peer against those claimed by the
authenticator. If keying
     framework, a discrepancy is found, an error can specification MUST be logged.

While [DiamBASE] requires provided describing how
     transient session keys suitable for use of with the Route-Record AVP, this utilizes



Aboba & Simon                Informational                     [Page 22]





INTERNET-DRAFT ciphersuite are
     derived from the AAA-Key.

EAP Keying Framework              2 March 2003


FQDNs, so that impersonation detection requires DNS A/AAAA and PTR RRs
to be properly configured. As a result, it appears that Diameter is as
vulnerable to this attack as RADIUS, if not more so.

To address this vulnerability, it is necessary to utilize data object
security to protect method independence
     Algorithms for deriving transient session keys from the AN-Token, and allow AAA-Key
     MUST NOT depend on the backend authentication
server EAP method.  However, algorithms for
     deriving TEKs MAY be specific to authenticate the authenticator directly. This requires EAP method.

Cryptographic separation
     The TSKs derived from the
authenticator to provide proof of its identity, ensuring that AAA-Key MUST be cryptographically
     separate from each other.  Similarly, TEKs MUST be



Aboba & Simon                Informational                     [Page 31]





INTERNET-DRAFT           EAP Key Mgmt. Framework           9 August 2003


     cryptographically separate from each other. In addition, the MSK is
being provided to TSKs
     MUST be cryptographically separate from the correct entity.

5.3. TEKs.

5.  IANA Considerations

This specification does not create any new registries, or define any new
EAP codes or types.

6.  Security Considerations

6.1.  Key strength Strength

In order to guard against brute force attacks, EAP methods deriving keys
need to be capable of generating an MK, MSK and EMSK keys with an appropriate effective
symmetric key strength. In order to ensure that key generation is not
the weakest link, it is necessary for EAP methods utilizing public key
cryptography to choose a public key that has a cryptographic strength
meeting the symmetric key strength requirement.

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

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

5.4.

6.2.  Key wrap Wrap

As described in [RFC2869bis], [RFC3579], Section 4.3, known problems exist in the key
wrap specified in [RFC2548]. Where the same RADIUS shared secret is used
by a PAP authenticator and an EAP authenticator, there is a
vulnerability to known plaintext attack.  Since RADIUS uses the shared
secret for multiple purposes, including per-packet authentication,
attribute hiding, considerable information is exposed about the shared
secret with each packet. This exposes the shared secret to dictionary
attacks.  MD5 is used both to compute the RADIUS Response Authenticator
and the Message-Authenticator attribute, and some concerns exist
relating to the security of this hash [MD5Attack].  As discussed in
[RFC2869bis],
[RFC3579], Section 4.2, these and other RADIUS vulnerabilities may be
addressed by running RADIUS over IPsec.



Aboba & Simon                Informational                     [Page 23] 32]





INTERNET-DRAFT           EAP Keying Key Mgmt. Framework              2 March           9 August 2003


Where an untrusted AAA intermediary is present (such as a RADIUS proxy
or a Diameter agent), and data object security is not used, the MSK may
be recovered by an attacker in control of the untrusted intermediary.
Possession of the MSK enables decryption of data traffic sent between
the peer and a specific authenticator; however where Perfect Forward
Secrecy (PFS) is implemented, compromise of the MSK does enable an
attacker to impersonate the peer to another authenticator, since that
requires possession of the MK or EMSK, which are not transported by the
AAA protocol. This vulnerability may be mitigated by implementation of
data object security techniques such as [DiamCMS], a work in progress.

5.5.  Man-in-the-middle attacks

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

In order to prevent these attacks, [MiTM] recommends derivation of a
compound key recovered by which an attacker in control of the untrusted intermediary.
Possession of the MSK enables decryption of data traffic sent between
the EAP peer and authenticator can prove that they
have participated in the entire EAP exchange. Since a specific authenticator; however where Perfect Forward
Secrecy (PFS) is implemented, compromise of the compound key
must not be known to MSK does enable an
attacker posing as an to impersonate the peer to another authenticator, and yet
must be derived from quantities since that
requires possession of the MK or EMSK, which are exported not transported by EAP methods, it the
AAA protocol. This vulnerability may be desirable to derive the compound key from a portion mitigated by implementation 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
redirect functionality, as fast handoff keys,
discussed in Appendix F.

6.  Normative References

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

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

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

[RFC2284bis]   Blunk, L., Vollbrecht, J., Aboba, B., "Extensible
               Authentication Protocol (EAP)", Internet draft (work [DiamBASE].

6.3.  Man-in-the-middle Attacks

As described in
               progress), draft-ietf-pppext-rfc2284bis-08.txt, December
               2002.




Aboba & Simon                Informational                     [Page 24]





INTERNET-DRAFT [MiTM], EAP Keying Framework              2 March 2003


[IEEE802]      IEEE Standards for Local and Metropolitan Area Networks:
               Overview and Architecture, ANSI/IEEE Std 802, 1990.

[IEEE80211]    Information technology - Telecommunications method sequences and
               information exchange 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 systems - Local and
               metropolitan area networks - Specific Requirements Part
               11:  Wireless LAN Medium Access Control (MAC) and
               Physical Layer (PHY) Specifications, IEEE Std.
               802.11-1997, 1997.

[IEEE8021X]    IEEE Standards for Local a victim and Metropolitan Area Networks:
               Port based Network Access Control, IEEE Std 802.1X-2001,
               June 2002.

7.  Informative References

[RFC1321]      Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
               April 1992.

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

[RFC2104]      Krawczyk, et al, "HMAC: Keyed-Hashing for Message
               Authentication", RFC 2104, February 1997.

[RFC2246]      Dierks, T. a legitimate authenticator. This
allows the attacker to authenticate successfully to the authenticator,
as well as to obtain access to the network.

In order to prevent these attacks, [MiTM] recommends derivation of a
compound key by which the EAP peer and Allen, C. "The TLS Protocol Version 1.0",
               RFC 2246, November 1998.

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

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

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

[RFC2434]      Alvestrand, H. authenticator can prove that they
have participated in the entire EAP exchange. Since the compound key
must not be known to an attacker posing as an authenticator, and T. Narten, "Guidelines yet
must be derived from quantities that are exported by EAP methods, it may
be desirable to derive the compound key from a portion of the EMSK. In
order to provide proper key hygiene, it is recommended that the compound
key used for Writing man-in-the-middle protection be cryptographically separate
from other keys derived from the EMSK, such as fast handoff keys,
discussed in Appendix E.

6.4.  Impersonation

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

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

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

This implies that it is possible for a rogue authenticator to forge NAS-
IP-Address, NAS-IPv6-Address or NAS-Identifier attributes within a



Aboba & Simon                Informational                     [Page 33]





INTERNET-DRAFT           EAP Key Mgmt. Framework           9 August 2003


RADIUS Access-Request in RFCs", BCP 26, RFC 2434,
               October 1998.

[RFC2548]      Zorn, G., "Microsoft Vendor-Specific order 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
by the RADIUS Attributes",
               RFC 2548, March 1999.

[RFC2607]      Aboba, B., Vollbrecht, J., "Proxy Chaining proxy or server purely based on the source address, other
mechanisms are required to detect the forgery.  In addition, it is
possible for attributes such as the Called-Station-Id and Policy
               Implementation Calling-
Station-Id to be forged as well.

As recommended in Roaming", RFC 2607, June 1999.





Aboba & Simon                Informational                     [Page 25]





INTERNET-DRAFT [RFC3579], this vulnerability can be mitigated by
having RADIUS proxies check authenticator identification attributes
against the source address.

To allow verification of session parameters such as the Called-Station-
Id and Calling-Station-Id, these can be sent by the EAP Keying Framework              2 March 2003


[RFC2716]      Aboba, B., Simon, D.,"PPP peer to the
server, protected by the TEKs.  The RADIUS server can then check the
parameters sent by the EAP TLS Authentication
               Protocol", RFC 2716, October 1999.

[RFC2865]      Rigney, C., Willens, S., Rubens, A., peer against those claimed by the
authenticator. If a discrepancy is found, an error can be logged.

While [DiamBASE] requires use of the Route-Record AVP, this utilizes
FQDNs, so that impersonation detection requires DNS A/AAAA and PTR RRs
to be properly configured. As a result, it appears that Diameter is as
vulnerable to this attack as RADIUS, if not more so.  To address this
vulnerability, it is necessary to allow the backend authentication
server to communicate with the authenticator directly, such as via the
redirect functionality supported in [DiamBase].

7.  References

7.1.  Normative References

[RFC1661]      Simpson, W., "Remote
               Authentication Dial In User Service (RADIUS)", RFC 2865,
               June 2000.

[RFC3078]      Pall, G. and Zorn, G. "Microsoft Editor, "The Point-to-Point
               Encryption (MPPE) Protocol (PPP)",
               STD 51, RFC 3078, March 2001.

[RFC3079]      Zorn, G. "Deriving Keys 1661, July 1994.

[RFC2119]      Bradner, S., "Key words for use with Microsoft Point-to-
               Point Encryption (MPPE)," in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 3079, 2119, March 2001.

[RFC3394]      R. Housley,  "Advance Encryption Standard (AES) Key Wrap
               Algorithm", 1997.

[RFC2434]      Alvestrand, H. and T. Narten, "Guidelines for Writing an
               IANA Considerations Section in RFCs", BCP 26, RFC 3394, September 2002.

[Congdon]      Congdon, P., 2434,
               October 1998.

[RFC2284bis]   Blunk, L., et al., "IEEE 802.1X RADIUS Usage
               Guidelines", al. "Extensible Authentication Protocol
               (EAP)", Internet draft (work in progress), draft-
               congdon-radius-8021x-23.txt, February draft-ietf-
               eap-rfc2284bis-04.txt, June 2003.

[FIPSDES]      National Bureau of Standards, "Data Encryption Standard",
               FIPS PUB 46 (January 1977).

[DESMODES]     National Bureau of Standards, "DES Modes of Operation",
               FIPS PUB 81 (December 1980).

[FIPS197]      FIPS PUB 197, Advanced Encryption Standard (AES), 2001
               November 26H.

[SHA]          National Institute of Standards and Technology (NIST),
               "Announcing the Secure Hash Standard," FIPS 180-1, U.S.
               Department of Commerce, 04/1995

[IEEE80211f]

[IEEE802]      IEEE Draft 802.11F/D5, "Draft Recommended Practice Standards for
               Multi-Vendor Access Point Interoperability via an Inter-
               Access Point Protocol Across Distribution Systems
               Supporting IEEE 802.11 Operation", January 2003.

[IEEE80211i]   IEEE Draft 802.11I/D3.1, "Draft Supplement to STANDARD
               FOR Telecommunications Local and Information Exchange between
               Systems - LAN/MAN Specific Requirements - Part 11:
               Wireless Medium Access Control (MAC) Metropolitan Area Networks:
               Overview and physical layer
               (PHY) specifications: Specification for Enhanced
               Security", February 2003.

[EAPAPI]       Microsoft Developer Network, "Windows 2000 EAP API",
               August 2000, http://msdn.microsoft.com/library/
               default.asp?url=/library/en-us/eap/eapport_0fj9.asp Architecture, ANSI/IEEE Std 802, 1990.





Aboba & Simon                Informational                     [Page 26] 34]





INTERNET-DRAFT           EAP Keying Key Mgmt. Framework              2 March           9 August 2003


[RFC2869bis]   Aboba, B., Calhoun, P., "RADIUS Support For Extensible
               Authentication Protocol (EAP)", Internet draft (work in
               progress), draft-aboba-radius-rfc2869bis-09.txt, February
               2003.

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

[DiamBASE]     Calhoun, P., et al., "Diameter Base


7.2.  Informative References

[RFC793]       Postel, J., "Transmission Control Protocol", Internet
               draft (work in progress), draft-ietf-aaa-diameter-17.txt,
               December 2002.

[DiamCMS]      Calhoun, P., Farrell, S., Bulley, W., "Diameter CMS
               Security Application", Internet draft (work in progress),
               draft-ietf-aaa-diameter-cms-sec-04.txt, March 2002.

[DiamEAP]      Hiller, T., Zorn, STD 7, RFC
               793, September 1981.

[RFC1321]      Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
               April 1992.

[RFC1968]      Meyer, G., "Diameter Extensible Authentication "The PPP Encryption Protocol (EAP) Application", Internet draft (work in
               progress), draft-ietf-aaa-eap-00.txt, (ECP)", RFC 1968,
               June 2002.

[Handoff]      Arbaugh, B., "Experimental Handoff Extension to RADIUS",
               Internet draft (work in progress), draft-irtf-aaaarch-
               handoff-00.txt, February 2003.

[IEEE-02-758]  Mishra, A., Shin, M., Arbaugh, W., Lee, I., Jang, K.,
               "Proactive Caching Strategies 1996.

[RFC2104]      Krawczyk, et al., "HMAC: Keyed-Hashing for IAPP Latency
               Improvement during 802.11 Handoff", IEEE 802.11 Working
               Group, IEEE-02-758r1-F, Message
               Authentication", RFC 2104, February 1997.

[RFC2246]      Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
               RFC 2246, November 2002.

[IEEE-03-084]  Mishra, A., Shin, M., Arbaugh, W., Lee, I., Jang, K.,
               "Proactive Key Distribution to support fast 1998.

[RFC2409]      Harkins, D. 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.

[KeyLen]       Orman, H., Hoffman, P., "Determining Strengths For Public
               Keys Used For Exchanging Symmetric Keys", D. Carrel, "The Internet draft
               (work 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]      Hummert, K., "The PPP Triple-DES Encryption Protocol
               (3DESE)", RFC 2420, September 1998.

[RFC2434]      Alvestrand, H. and T. Narten, "Guidelines for Writing an
               IANA Considerations Section in progress), draft-orman-public-key-
               lengths-05.txt, December 2001.

[8021XHandoff] Pack, S., Choi, Y., "Pre-Authenticated Fast Handoff RFCs", BCP 26, RFC 2434,
               October 1998.

[RFC2516]      Mamakos, L., "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 a
               Public Wireless LAN Based on IEEE 802.1X Model", School



Aboba & Simon                Informational                     [Page 27]





INTERNET-DRAFT Roaming", RFC 2607, June 1999.

[RFC2716]      Aboba, B. and D. Simon, "PPP EAP Keying Framework              2 March 2003


               of Computer Science TLS Authentication
               Protocol", RFC 2716, October 1999.

[RFC2865]      Rigney, C., Willens, S., Rubens, A. and Engineering, Seoul National
               University, Seoul, Korea, 2002.

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

[MiTM]         Puthenkulam, J., et al, "The Compound W. Simpson,
               "Remote Authentication
               Binding Problem", Internet draft (work in progress),
               draft-puthekulam-eap-binding-02.txt, March 2003. Dial In User Service (RADIUS)",
               RFC 2865, June 2000.





Aboba & Simon                Informational                     [Page 28] 35]





INTERNET-DRAFT           EAP Keying Key Mgmt. Framework              2 March           9 August 2003


Appendix A - Ciphersuite independence

The Master Session Key (MSK), Extended Master Session Key (EMSK)


[RFC2960]      R. Stewart et al., "Stream Control Transmission
               Protocol", RFC 2960, October 2000.

[RFC3078]      Pall, G. and IV
exported by EAP methods MUST be ciphersuite independent. This confers
several advantages:

Ciphersuite negotiation
     Enabling derivation G. Zorn, "Microsoft Point-to-Point
               Encryption (MPPE) RFC 3078, March 2001.

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

[RFC3394]      R. Housley,  "Advance Encryption Standard (AES) Key Wrap
               Algorithm", RFC 3394, September 2002.

[RFC3580]      Congdon, P., et al., "IEEE 802.1X RADIUS Usage
               Guidelines", RFC 3580, August 2003.

[FIPSDES]      National Bureau of the TSK(s) in a separate step provides
     improved security. For example, the TSK derivation algorithm
     supported within [IEEE80211i] enables the EAP peer and
     authenticator to mutually authenticate and conduct a protected
     ciphersuite Standards, "Data Encryption Standard",
               FIPS PUB 46 (January 1977).

[DESMODES]     National Bureau of Standards, "DES Modes of Operation",
               FIPS PUB 81 (December 1980).

[FIPS197]      FIPS PUB 197, Advanced Encryption Standard (AES), 2001
               November 26H.

[SHA]          National Institute of Standards and capabilities negotiation.  If the MSK is used
     directly as a TSK, then Technology (NIST),
               "Announcing the EAP peer Secure Hash Standard," FIPS 180-1, U.S.
               Department of Commerce, 04/1995

[IEEE80211]    Information technology - Telecommunications and authenticator may not
     mutually authenticate each other,
               information exchange between systems - Local and a protected ciphersuite
     negotiation, if it occurs at all, would typically need to be
     supported within EAP itself. Since the ciphersuite negotiation
     mechanisms are link-layer specific, this would introduce media
               metropolitan area networks - Specific Requirements Part
               11:  Wireless LAN Medium Access Control (MAC) and
     ciphersuite dependencies into EAP.

Document Revision
     If an EAP method specifies how to derive transient session keys
               Physical Layer (PHY) Specifications, IEEE Std.
               802.11-1997, 1997.

[IEEE8021X]    IEEE Standards for
     each ciphersuite, the specification will need to be revised each
     time a new ciphersuite is developed.  This also implies that a
     backend authentication server supporting Local and Metropolitan Area Networks:
               Port based Network Access Control, IEEE Std 802.1X-2001,
               June 2002.

[IEEE80211f]   IEEE 802.11F, "Recommended Practice for Multi-Vendor
               Access Point Interoperability via an EAP method would not be
     usable with all EAP-capable authenticators, if the backend
     authentication server were not upgraded to support a new
     ciphersuite implemented on the authenticator.

EAP method complexity
     Requiring EAP methods Inter-Access Point
               Protocol Across Distribution Systems Supporting IEEE
               802.11 Operation", July 2003.

[IEEE80211i]   IEEE Draft 802.11I/D5.0, "Draft Supplement to include ciphersuite-specific code for TSK
     derivation increases the complexity of the STANDARD
               FOR Telecommunications and Information Exchange between
               Systems - LAN/MAN Specific Requirements - Part 11:
               Wireless Medium Access Control (MAC) and physical layer



Aboba & Simon                Informational                     [Page 36]





INTERNET-DRAFT           EAP method.

Knowledge asymmetry
     In practice, an Key Mgmt. Framework           9 August 2003


               (PHY) specifications: Specification for Enhanced
               Security", August 2003.

[EAPAPI]       Microsoft Developer Network, "Windows 2000 EAP method may not have knowledge of the
     ciphersuite that has been negotiated between the peer API",
               August 2000, http://msdn.microsoft.com/library/
               default.asp?url=/library/en-us/eap/eapport_0fj9.asp

[RFC3579]      Aboba, B. and
     authenticator. In PPP, ciphersuite negotiation occurs via the
     Encryption Control P. Calhoun, "RADIUS Support For Extensible
               Authentication Protocol (ECP), described (EAP)", RFC 3579, August 2003.

[RoamCERT]     Aboba, B., "Certificate-Based Roaming", Internet draft
               (work in [RFC1968].  Since
     ECP negotiation occurs after authentication, unless an EAP method
     is utilized that supports ciphersuite negotiation, the peer,
     authenticator progress), draft-ietf-roamops-cert-02.txt, April
               1999.

[DiamBASE]     Calhoun, P., et al., "Diameter Base Protocol", Internet
               draft (work in progress), draft-ietf-aaa-diameter-17.txt,
               December 2002.

[DiamEAP]      Eronen, P., et al., "Diameter Extensible Authentication
               Protocol (EAP) Application", Internet draft (work in
               progress), draft-ietf-aaa-eap-02.txt, June 2003.

[Handoff]      Arbaugh, B. and backend authentication server may not be able B. Aboba, "Experimental Handoff Extension
               to
     anticipate the negotiated ciphersuite and therefore this
     information cannot be provided RADIUS", Internet draft (work in progress), draft-
               irtf-aaaarch-handoff-02.txt, June 2003.

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

[IEEE-03-084]  Mishra, A., Shin, M., Arbaugh, W., Lee, I., Jang, K.,
               "Proactive Key Distribution to the 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.

[KeyLen]       Orman, H., and P. Hoffman, "Determining Strengths For
               Public Keys Used For Exchanging Symmetric Keys", Internet
               draft (work in progress), draft-orman-public-key-
               lengths-05.txt, December 2001.





Aboba & Simon                Informational                     [Page 37]





INTERNET-DRAFT           EAP method. Since ciphersuite
     negotiation is assumed to occur out-of-band, there is no need for
     ciphersuite negotiation within EAP. Key Mgmt. Framework           9 August 2003


[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, Summer 1996.

[MiTM]         Puthenkulam, J., et al, "The Compound Authentication
               Binding Problem", Internet draft (work in progress),
               draft-puthekulam-eap-binding-03.txt, June 2003.








































Aboba & Simon                Informational                     [Page 29] 38]





INTERNET-DRAFT           EAP Keying Key Mgmt. Framework              2 March           9 August 2003


Appendix B A - Ciphersuite keying requirements 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 a 128-bit authentication key (used in both
directions); AES CCMP, which requires a single 128-bit key (used in both
directions) in order to authenticate and encrypt data; and WRAP, which
requires a single 128-bit key (used in both directions).

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





Aboba & Simon                Informational                     [Page 30] 39]





INTERNET-DRAFT           EAP Keying Key Mgmt. Framework              2 March           9 August 2003


Appendix C B - Example TEK Hierarchy

Figure C-1 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.
master_secret = TLS term for the MK.

       |                       |                           |
       |                       | pre_master_secret         |
 server|                       |                           | client
 Random|                       V                           | Random
       |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       |
       |     |                                     |       |
       |     |                                     |       |
       +---->|             master_secret           |<------+
       |     |               (MK)                  |       |
       |     |                                     |       |
       |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       |
       |                       |                           |
       |                       |                           |
       |                       |                           |
       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 C-1 B-1 - TLS [RFC2246] Key Hierarchy





Aboba & Simon                Informational                     [Page 31] 40]





INTERNET-DRAFT           EAP Keying Key Mgmt. Framework              2 March           9 August 2003


Appendix D C - Example MSK, EMSK MSK and IV EMSK Hierarchy

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

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

In EAP-TLS, the MSK, EMSK and IV are derived from the MK via a one-way
function. This ensures that the MK 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 MK, if the MK is compromised then the MSK is also
compromised.

As described in [RFC2716], the formula for the derivation of the MSK,
EMSK and IV from the MK is as follows:

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

MSK(0,31)

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

Where:


AAA-Key(W,Z)  = Octets W through Z includes of the AAA-Key.
IV(W,Z)       = Octets W through Z inclusive of the IV.



Aboba & Simon                Informational                     [Page 41]





INTERNET-DRAFT           EAP Key Mgmt. Framework           9 August 2003


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



Aboba & Simon                Informational                     [Page 32]





INTERNET-DRAFT            EAP Keying Framework              2 March 2003

Figure D-1 C-1 describes the process by which the MSK,EMSK,IV and ultimately
the TSKs, are derived from the MK. Note that in [RFC2716], the MK is
referred to as the "TLS Master Secret".

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

Figure D-1 C-1 - EAP TLS [RFC2716] MSK, EMSK and IV Key hierarchy




Aboba & Simon                Informational                     [Page 33] 42]





INTERNET-DRAFT           EAP Keying Key Mgmt. Framework              2 March           9 August 2003


Appendix E D - Example Transient Session Key (TSK) Derivation

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

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

Where:

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

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

The EAPOL-Key Confirmation Key (KCK) is used to provide data origin
authenticity in the TSK derivation. It utilizes the first 128 bits (bits
0-127) of the PTK.  The EAPOL-Key Encryption Key (KEK) provides
confidentiality in the TSK derivation.  It utilizes bits 128-255 of the
PTK. Bits 256-383 of the PTK are used by Temporal Key 1, and Bits
384-511 are used by Temporal Key 2.  Usage of TK1 and TK2 is ciphersuite
specific. Details are available in [IEEE80211i].





















Aboba & Simon                Informational                     [Page 34] 43]





INTERNET-DRAFT           EAP Keying Key Mgmt. Framework              2 March           9 August 2003


Appendix F E - Example PMK AAA-Key Derivation

As discussed in [Handoff], [IEEE-02-758], [IEEE-03-084], and
[8021XHandoff], keying material may be required for use in fast handoff
between IEEE 802.11 authenticators.  Where the backend authentication
server provides keying material to multiple authenticators in order to
fascilitate fast handoff, it is highly desirable for the keying material
used on different authenticators to be cryptographically separate, so
that if one authenticator is compromised, it does not lead to the
compromise of other authenticators.  Where keying material is provided
by the backend authentication server, a key hierarchy derived from the
EMSK, as suggested in [IEEE-03-155] can be used to provide
cryptographically separate keying material for use in fast handoff:

PMK0-A

AAA-Key-A = MSK(0,63)
AAA-Key-B = MSK(0,31)
PMK1-B PRF(EMSK(0,63),AAA-Key-A,B-Called-Station-Id,Calling-Station-Id)
AAA-Key-E = PRF(EMSK(0,63),AAA-Key-A,E-Called-Station-Id,Calling-Station-Id)

Where:
Calling-Station-Id  = STA MAC address
B-Called-Station-Id = PRF(EMSK(0,31),PMK0-A,APB-MAC-Addr,STA-MAC-Addr)
PMK1-E AP B MAC address
E-Called-Station-Id = PRF(EMSK(0,31),PMK0-A,APE-MAC-Addr,STA-MAC-Addr) AP E MAC address

Here PMK0-A AAA-Key-A is the Pairwise Master Key AAA-Key derived during the initial EAP
authentication between the peer and authenticator A.  Based on this
initial EAP authentication, the EMSK is also derived, the first 32
octets of which can be used
to derive PMKs AAA-Keys for fast authentication between the EAP peer and
authenticators B and E. Since the EMSK is cryptographically separate
from the MSK, each of these PMKs AAA-Keys is cryptographically separate from
each other, and are guaranteed to be unique between the EAP peer (also
known as the STA) and the authenticator (also known as the AP).

Acknowledgments

Thanks to Arun Ayyagari, Ashwin Palekar, and Tim Moore of Microsoft,
Dorothy Stanley of Agere, Dave Halasz Bob Moskowitz of Cisco Systems, TruSecure, and Russ Housley
of RSA Vigil Security for useful feedback.

Author Addresses

Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052

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

Dan Simon
Microsoft Research
Microsoft Corporation



Aboba & Simon                Informational                     [Page 35] 44]





INTERNET-DRAFT           EAP Keying Key Mgmt. Framework              2 March           9 August 2003


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

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 rights
which may cover technology that may be required to practice this
standard.  Please address the information to the IETF Executive
Director.

Full Copyright Statement

Copyright (C) The Internet Society (2003).  All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works.  However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into
languages other than English.  The limited permissions granted above are
perpetual and will not be revoked by the Internet Society or its



Aboba & Simon                Informational                     [Page 45]





INTERNET-DRAFT           EAP Key Mgmt. Framework           9 August 2003


successors or assigns.  This document and the information contained
herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR



Aboba & Simon                Informational                     [Page 36]





INTERNET-DRAFT            EAP Keying Framework              2 March 2003
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."

Open issues

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

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

Expiration Date

This memo is filed as <draft-aboba-pppext-key-problem-06.txt>, <draft-aboba-pppext-key-problem-07.txt>,  and
expires August February 22, 2003. 2004.

































Aboba & Simon                Informational                     [Page 37] 46]


----