view Side-By-Side changes

EAP Working Group                                          Bernard Aboba
INTERNET-DRAFT                                                 Dan Simon
Category: Informational                                        Microsoft
<draft-aboba-pppext-key-problem-05.txt>
21 December 2002
<draft-aboba-pppext-key-problem-06.txt>
2 March 2003



                          EAP Keying 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 (2002). (2003).  All Rights Reserved.

Abstract

This document describes the framework for key derivation by EAP methods key derivation, and
provides guidelines for generation and usage of EAP keys derived by EAP methods requesting publication as an RFC.
and AAA protocols.  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 Framework          21 December 2002              2 March 2003


Table of Contents

1.     Introduction ..........................................    3
   1.1       Requirements language ...........................    4    3
   1.2       Terminology .....................................    4
2.     EAP architecture overview .............................    7 ..........................................    5
   2.1       Ciphersuite independence ........................   10       Invariants ......................................    7
3.     EAP Exchanges .........................................   12
   3.1       Two-party exchange ..............................   12
   3.2       Three-party exchange ............................   14
   3.3       EAP key hierarchy ...............................   17 .....................................    8
   3.1       Exchanges .......................................   11
4.     Security considerations ...............................   17 properties ...................................   14
   4.1       Three-party exchange ............................   17
   4.2       EAP method requirements .........................   18
   4.3   14
   4.2       AAA protocol requirements .......................   19   17
   4.3       TSK derivation requirements .....................   18
   4.4       Ciphersuite requirements ........................   20   19
   4.5       Security properties .............................   19
5.     Security considerations ...............................   21
   5.1       Assumptions .....................................   21
   5.2       Key binding  ....................................   22
   5.3       Key strength ....................................   23
   5.4       Key wrap ........................................   23
   5.5       Man-in-the-middle attacks .......................   24
6.     Normative references ..................................   21
6.   24
7.     Informative references ................................   21   25
Appendix A - Ciphersuite independence ........................   29
Appendix B - Ciphersuite keying requirements .................   24   30
Appendix B C - Example EMK TEK hierarchy ...........................   25   31
Appendix C D - Example MSK MSK, EMSK and IV hierarchy ...........................   27 ..............   32
Appendix E - Example TSK derivation ..........................   34
Appendix F - Example PMK derivation ..........................   35
Acknowledgments ..............................................   29   35
Author's Addresses ...........................................   29   35
Intellectual Property Statement ..............................   30   36
Full Copyright Statement .....................................   30   36


















Aboba & Simon                Informational                      [Page 2]





INTERNET-DRAFT            EAP Keying Framework          21 December 2002              2 March 2003


1.  Introduction

The Extensible Authentication Protocol (EAP), defined in [RFC2284bis],
was originally developed to provide extensible authentication for use
with PPP [RFC1661]. Since then, new applications of EAP have emerged,
including it has also been applied to IEEE 802.1X network port authentication 802
wired networks [IEEE8021X].

The primary purpose of  When EAP is to authenticate used for authentication on PPP
or wired IEEE 802 networks, it is typically assumed that the link is
physically secure, so that an EAP Client attacker cannot gain access to an the link,
or insert a rogue device.

EAP methods defined in [RFC2284bis] reflect this usage model. These
include EAP
Server, MD5, as well as to provide keys for use with a link layer ciphersuite
negotiated between an EAP Client One-Time Password (OTP) and a Network Access Server (NAS). Generic Token
Card. These methods support one-way authentication (from EAP
can be deployed in configurations where peer to
authenticator) but not mutual authentication or key derivation. As a
result, these methods do not bind the EAP Server initial authentication and NAS are co-
located, supporting a two-party exchange; alternatively, it can be
deployed in configurations where
subsequent data traffic, even when the EAP Server is located on a separate
entity, known as an Authentication Server. In this case, EAP supports a
three-party exchange, where the Authentication Server acts as a Key
Distribution Center (KDC), and the Authentication Server and NAS
communicate using a AAA protocol supporting EAP as well as key wrap.
Examples of AAA protocols supporting EAP include RADIUS [RFC2869bis],
and Diameter [DiamEAP]; examples of AAA key wrap specifications include
[RFC2548] ciphersuite used to protect
data supports per-packet authentication and [DiamCMS].

EAP integrity protection.  This
leaves these methods defined in [RFC2284bis] include EAP MD5, vulnerable to hijacking as well as One-Time
Password (OTP) and Generic Token Card methods. Each of attacks by rogue
devices.

On wireless networks such as IEEE 802.11 [IEEE80211], these methods
supports one-way authentication only (EAP Client to EAP Server) but not
key derivation. Since those methods do not support key derivation and do
not provide for mutual authentication, they are only appropriate for use
in situations where the link layer can be assumed attacks
become much easier to be physically
secure. Where this mount, since any attacker within range is not capable
of accessing the case, wireless medium, or acting as an access point. As a session established over the link
subsequent to
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 would be subject to hijacking, since
without and key
derivation, it is not possible to tie the initial
authentication to subsequent data traffic on a per-packet basis.  These
limitations can be overcome via negotiation of EAP provided by methods such as EAP TLS [RFC2716] that support mutual authentication, as well are required
[IEEE80211i], so as key
derivation.

In order for EAP methods to address the threat of rogue devices, and provide appropriate
keying material for link
layer ciphersuites, the keying requirements of to bind the ciphersuites need initial authentication to
be understood and provided for. These requirements are discussed in
Appendix A.  With the increasing deployment of link layer ciphersuites,
particularly with wireless networks, there is a need for a clear
specification of what is expected of EAP methods deriving keys, as well
as of ciphersuites utilizing keying material provided by EAP methods.

An overview of the EAP architecture is provided in Section 2, including
in subsequent data
traffic.

Section 2.1, a discussion 2 provides an overview of the implications for EAP methods
generating keys. EAP.  Section 3 describes both the two-party (Section 3.1)
and the three-party (Section 3.2) exchanges. An introduction to the EAP key hierarchy is provided in Section 3.3.



Aboba & Simon                Informational                      [Page 3]





INTERNET-DRAFT            EAP Keying Framework          21 December 2002


Keying requirements are discussed in
hierarchy.  Section 4. This includes 4 describes requirements for the EAP methods themselves (Section 4.1), the AAA
protocols (Section 4.2), and the link layer ciphersuites (Section 4.3). resulting security
properties.  Section 5 analyzes the discusses additional security properties of both the two-way and
three-way exchanges. considerations.

Appendix A discusses the principle of ciphersuite independence. Appendix
B provides a summary of the keying requirements of link layer
ciphersuites supported on PPP and IEEE 802.11. Appendix B C provides an
example EAP Master Key (EMK) (MK) hierarchy. Appendix C D provides an example
Master Session Key (MSK) hierarchy.  Appendix E provides an example
Transient Session Key (TSK) derivation. Appendix F provides an example
of PMK derivation in Fast Handoff.

1.1.  Requirements 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:

Client-Server Token (CS-Token)

authenticator
     The package within which end of the MSK EAP link initiating EAP authentication.  Where no
     backend authentication server is transported between present, the EAP
     Server and authenticator acts as
     the EAP Client.  The package MUST be integrity
     protected, authenticated and encrypted, so as to protect server, terminating the MSK
     from compromise. In addition to EAP conversation with the MSK, peer.
     Where a backend authentication server is present, the CS-Token authenticator
     MAY include act as a pass-through for one or more attributes providing information on MSK usage.
     Attributes may include the NAS layer 2 authentication methods
     and layer 3 addresses, MSK
     lifetime, etc. The format of the CS-Token for non-local users.  This terminology is defined by the EAP
     method. Support for the CS-Token is optional also used in
     [IEEE8021X], and most current EAP
     methods do not support it, since they derive the MSK as part of has the
     EMK key hierarchy, and thus do not need to transport it separately.
     However, same meaning in the case where an EAP Client needs to handle multiple
     MSKs, such as when it this document.

backend authentication server
     A backend authentication server is connected an entity that provides an
     authentication service to multiple NASes
     simultaneously, or where an Authentication Server authenticator.  When used, this server
     typically executes EAP Methods for the authenticator.  This
     terminology is sending MSKs
     to multiple NASes also used in order to support fast handoff, use of methods
     supporting the CS-Token may be desirable.

AAA-NAS Token (AN-Token) [IEEE8021X].

AN-Token
     The package within which the Master Session Keys (MSKs) Key (MSK) and one or
     more AAA attributes is transported between the Authentication
     Server backend authentication
     server and NAS. the authenticator. The AAA attributes provide the NAS
     authenticator with information on MSK usage.  For example, AAA
     attributes might include the Client peer layer 2 address, the NAS
     authenticator layer 2 and layer 3 IP addresses, the MSK lifetime, etc.  The
     format and wrapping of the AN-Token, which is intended to be
     accessible only to the Authentication Server backend authentication server and
     NAS,
     authenticator, is defined by the AAA key distribution
     specification.




Aboba & Simon                Informational                      [Page 4]





INTERNET-DRAFT            EAP Keying Framework          21 December 2002


Authentication Server
     An Authentication Server is an entity that provides an
     Authentication Service to a Network Access Server (NAS). This
     service verifies from the credentials provided by the Client, the
     claim of identity made by the Client. Where an Authentication
     Server is provided, it acts as the EAP Server, terminating EAP
     conversation with the EAP Client.  In the EAP Keying architecture
     the Authentication Server acts as a KDC, distributing the Master
     Session Keys (MSKs) to the EAP Client and NAS.

Cryptographic binding
     The demonstration of the EAP Client peer to the EAP Server server that a single
     entity has acted as the EAP Client peer for all methods executed within a
     sequence or tunnel. Binding MAY also imply that the EAP Server server
     demonstrates to the Client peer that a single entity has acted as the EAP Server
     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 Master key (EMK)
     The key derived between

Key derivation
     This refers to the EAP Client and Server during ability of the EAP
     authentication process. The EMK is unique method to the EAP Client and
     Server, and derive a Master Key
     (MK) which is not shared with any other parties. exported, as well as a ciphersuite- independent
     Master Session Key (MSK)
     Keying material provided to the EAP Client and NAS by the AAA
     Server, acting as a (MSK), Extended Master Session Key Distribution Center (KDC). (EMSK) and
     Initialization Vector (IV).  The MSK is MSK, EMSK and IV are used
     in derivation of Transient Session Keys only for the ciphersuite
     negotiated between
     further key derivation, not directly for protection of the EAP Client and NAS.  So that
     conversation or subsequent data.

Key strength
     If the MSK is
     usable with any ciphersuite, it is longer than necessary, and effective key strength is
     truncated N bits, the best currently known
     methods to fit.





Aboba & Simon                Informational                      [Page 5]





INTERNET-DRAFT recover the key (with non-negligible probability)
     require an effort comparable to 2^N operations of a typical block
     cipher.

EAP Keying Framework          21 December 2002


Note server
     The entity that an Authentication Server may simultaneously provide terminates the EAP
Client with MSKs suitable for use authentication with multiple APs, so as to enable
fast handoff. Similarly the AAA Server may send MSKs to multiple APs
simultaneously. Note that peer.
     In the case where there is no backend authentication server, this
     term refers to the AP supports transport of multiple
MSK sets authenticator. Where the authenticator operates
     in pass-through, it refers to the backend authentication server.

Mutual authentication
     This refers to an EAP Client method in which, within an interlocked
     exchange, the authenticator authenticates the peer and NASes, the MSKs MUST be kept
cryptographically separate from each other.

Network Access Server (NAS) peer
     authenticates the authenticator. Two one-way conversations, running
     in opposite directions do not provide mutual authentication as
     defined here.

peer The device end of the EAP Link that provides access responds to the network. Where no
     Authentication Server authenticator.  In
     [IEEE8021X], this end is present, the NAS acts known as the Supplicant.

2.  EAP Server,
     terminating the overview

The EAP conversation with the Client. Where an
     Authentication Server is present, the NAS may act as authentication process involves a pass-through
     for one or more peer, authenticator and
(optionally) a backend authentication methods server. Typically, the peer
desires access to the network, and for non-local users.

Pairwise Master Key (PMK)
     As defined in [RFC2716], the MSK authenticator is 192 octets (1536 bits) a Network Access
Server (NAS) providing that access. However, EAP may also be used in
     length.  Octets 0-31 of the MSK are known
other situations, such as the "Peer to
     Authenticator Encryption Key" when it is desired for two network devices
(e.g. two switches or Enc-RECV-Key (reception routers) to authenticate each other.  Since EAP is defined
     from



Aboba & Simon                Informational                      [Page 5]





INTERNET-DRAFT            EAP Keying Framework              2 March 2003


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

An important goal of view EAP is to enable deployment of new methods without
requiring development of new code on the authenticator.  While the
authenticator may implement some EAP Authenticator or NAS).  Within
     IEEE 802.11, methods locally and use those
methods to authenticate local users, it may at the Enc-RECV-Key is also known same time act as a
pass-through for other users and methods, forwarding EAP packets back
and forth between the Pairwise Master
     Key (PMK). IEEE 802.11 ciphersuites such as TKIP, WRAP backend authentication server and CCMP
     derive their Transient Session Keys (TSKs) solely from the PMK,
     whereas peer.

EAP presumes that prior to initiation of authentication, the WEP ciphersuite, when used 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 for accessing the selected service. For use
with IEEE 802.1X-2002,
     derives its TSKs from both 802.11 wireless LANs, the Enc-RECV-Key and peer (a Station (STA) in IEEE 802.11
terminology) may locate an authenticator (an Access Point (AP) in IEEE
802.l1 terminology) using the Enc-SEND-Key.
     Octets 32-63 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 the MSK are known as the "Authenticator peer
authenticates to Peer
     Encryption Key" the EAP server), or End-SEND-Key. Octets 64-95 are known as the
     "Peer to Authenticator Authentication Key" or Auth-RECV-Key.
     Octets 96-127 are known as the "Authenticator to Peer
     Authentication Key" or Auth-SEND-Key. Octets 128-159 are known as mutual authentication (in which the "Peer to Authenticator IV" or RECV-IV,
peer and Octets 160-191 are
     known as the "Authenticator to Peer IV", or SEND-IV.

     Within [IEEE80211i], EAP server mutually authenticate). In either case, it can be
assumed that the Enc-RECV-Key is also known as parties do not enable the Pairwise
     Master Key (PMK). IEEE 802.11 ciphersuites such as TKIP, WRAP and
     CCMP derive link unless their Transient Session Keys (TSKs) solely from the
     PMK, whereas the WEP ciphersuite, when used
authentication requirements have been met. For example, a peer
completing mutual authentication with IEEE 802.1X-2002,
     derives its TSKs from both the Enc-RECV-Key and the Enc-SEND-Key.
     IEEE 802.11 ciphersuites do an authenticator will not utilize enable
its link until the Auth-RECV-Key, Auth-
     SEND-Key, RECV-IV or SEND-IV, largely because attributes supporting
     transport of these portions of authenticator has authenticated successfully to the MSK were not defined
peer.

As described in
     [RFC2548].

Transient Section 3, EAP Keys (TEKs)
     Session keys which are methods MAY support derivation of keying
material used to establish a protected channel
     between for purposes including protection of the EAP Client conversation
and Server during the subsequent data exchanges, man-in-the-middle detection, or fast
handoff. EAP authentication
     exchange.  The TEKs are derived from methods supporting key derivation must also support mutual
authentication.

EAP assumes that ciphersuite negotiation, if it occurs, is handled out
of band. For example, the EMK, and are appropriate
     for use peer might be preconfigured with policy
indicating the ciphersuite to be used in communicating with a given
authenticator, or alternatively, the link layer protocol may support
ciphersuite negotiation.  Within PPP, the ciphersuite is negotiated between EAP Client and
     Server as part
within the Encryption Control Protocol (ECP), after EAP authentication exchange. Note that the
is completed. Within [IEEE80211i], the AP capabilities (including
ciphersuite) are advertised in the Beacon and Probe Responses, and are
securely verified during a 4-way exchange after EAP authentication has
completed. The desired ciphersuite is indicated within the
Association/Reassociation Request/Response exchange.




Aboba & Simon                Informational                      [Page 6]





INTERNET-DRAFT            EAP Keying Framework          21 December 2002


     ciphersuite used to set up              2 March 2003


2.1.  Invariants

Several basic principles govern the protected channel between design of the EAP
     Client and Server during keying framework.
These are known as the "EAP Invariants":

Media independence
     As described in [RFC2284bis], EAP authentication is unrelated to the
     ciphersuite used to subsequently protect data sent between the EAP
     Client supported on
     lower layers, including PPP [RFC1661] and NAS.  In particular, the TEKs used IEEE 802 wired networks
     [IEEE8021X]. Use with IEEE 802.11 wireless LANs is also
     contemplated [IEEE80211i]. Since EAP methods cannot be assumed to protect
     have knowledge of the lower layer on which they are being run, EAP
     exchange
     methods MUST be cryptographically separate from TSKs used to
     protect data.

Transient Session Keys (TSKs)
     Session keys used designed to protect data which are appropriate for function on any lower layer meeting the
     criteria outlined in [RFC2284bis], Section 3.1.

Ciphersuite independence
     Since ciphersuite negotiated between the negotiation occurs out-of-band of EAP, and may
     occur after EAP Client authentication and NAS. The TSKs are
     derived from the MSK by a process defined by the link layer.  In
     the case of IEEE 802.11, TSK key derivation is supported via a 4-way
     handshake that supports mutual authentication between the complete, EAP
     Client and NAS. The 4-handshake also confirms mutual possession
     methods deriving keys MUST provide keying material that is
     independent of the PMK as well as supporting protected ciphersuite negotiation.

2.  EAP architecture overview

EAP authentication involves a Client, NAS and (optionally) an
Authentication Server. One subsequently negotiated for
     protection of data.

     Since it is the peer and authenticator that negotiate and implement
     the goals ciphersuite, knowledge of EAP the ciphersuite is restricted to enable development
of new authentication methods without requiring deployment
     those entities.  The backend authentication server is not a party
     to the ciphersuite negotiation nor is it an intermediary in the
     data flow between the peer and authenticator. As a result, it
     cannot be assumed to have knowledge of new code
on the NAS. While ciphersuites implemented
     by the NAS may implement some methods locally peer and use
those methods authenticator, to authenticate local users, it be aware of the ciphersuite
     negotiated between them, or to implement ciphersuite-specific code.

     Since the backend authentication server may at not know the same time act
as a pass-through for other users
     ciphersuite negotiated between the peer and methods. authenticator, it
     cannot make this information available to a resident EAP method.
     This means that ciphersuite-specific key generation, if implemented
     within an EAP method, will not function correctly on every EAP
     implementation. The advantages of ciphersuite independence are
     discussed in Appendix A.

Method independence
     Supporting pass-through of authentication to the Authentication Server backend
     authentication server enables the NAS authenticator to support any
     authentication method implemented on the Authentication
Server backend authentication
     server and EAP Client, peer, not just locally implemented methods.  This
     implies that the NAS authenticator need not implement code for each EAP
     method required by authenticating Clients. peers; in fact the authenticator
     is not required to implement any EAP presumes that prior methods at all, nor cannot it
     be assumed to authentication, the implement code specific to any EAP Client has located method.




Aboba & Simon                Informational                      [Page 7]





INTERNET-DRAFT            EAP Keying Framework              2 March 2003


     This is useful where there is no single EAP method that is both
     mandatory-to-implement and offers acceptable security for the NAS, using an out-of-band mechanism. media
     in use. For example, for use with PPP, the Client might be configured with [RFC2284bis] mandatory-to-implement EAP
     method (MD5-Challenge) does not provide dictionary attack
     resistance, mutual authentication or key derivation, and as a phone book providing phone numbers
     result is not appropriate for accessing the selected service. For use with IEEE 802.11 wireless
LANs, the Client (a Station (STA) LANs.

3.  EAP key hierarchy

The EAP keying hierarchy, illustrated in IEEE 802.11 terminology) may locate
NAS devices (an Access Point (AP) in IEEE 802.l1 terminology) using Figure 1, makes use of the
IEEE 802.11 Beacon
following types of keys:

EAP Master key (MK)
     A key derived between the EAP client and Probe Request/Response frames. server during the EAP also assumes
     authentication process that link layer ciphersuite negotiation is handled
within the link layer.  For example, purely local to the EAP Client might method. The
     MK MUST NOT be
preconfigured with policy indicating exported from the ciphersuite to EAP method or be used in
communicating with made available to
     a given NAS, or alternatively, the link layer
protocol may support ciphersuite negotiation.  Within PPP, third party.  Since derivation of the
ciphersuite MK is negotiated within a residue of the
     successful completion of the Encryption Control Protocol (ECP),
after EAP authentication exchange, proof of
     MK possession may be used to shorten future EAP exchanges between
     the same EAP client and server, a technique known as "fast resume".

Master Session Key (MSK)
     Keying material (64 octets) that is completed. Within IEEE 802.11i, derived between the AP
capabilities (including ciphersuite) are advertised EAP client
     and server. The MSK is used in the Beacon and
Probe Responses, derivation of Transient Session
     Keys (TSKs) for the ciphersuite negotiated between the EAP peer and are verified during
     authenticator. Where a 4-way exchange after EAP backend authentication has completed. The desired ciphersuite server is indicated



Aboba & Simon                Informational                      [Page 7]





INTERNET-DRAFT present,
     acting as an EAP Keying Framework          21 December 2002


within server, it will typically transport the Association/Reassociation Request/Response exchange.

Figure 1 illustrates MSK to the relationship between
     authenticator.

     The MSK differs from the MK in that it not assumed to remain local
     to the EAP Client, NAS method, and
Authentication Server (EAP Server) for is known by all parties in the case where EAP exchange:
     the NAS and
Authentication Server are located on separate hosts, peer, authenticator and the NAS acts as authentication server (if present).
     The MSK MAY be derived from the MK via a pass-through.

+-+-+-+-+-+               +-+-+-+-+-+
|         |               |         |
|         |               |         |
| Cipher- |               | Cipher- |
| Suite   |               | Suite   |
|         |               |         |
+-+-+-+-+-+               +-+-+-+-+-+
    ^                         ^
    |                         |
    |                         |
    |                         |
    V                         V
+-+-+-+-+-+               +-+-+-+-+-+        +-+-+-+-+-+
|         |===============|         |========|         |
|         |      EAP      |         |        |         |
|         |<-------------------------------->| Authent.|
| Client  |               |   NAS   |        |  Server |
|         |===============|         |========|         |
|         |  Link Layer   |         |  AAA   | (EAP    |
|         | (PPP,IEEE 802)|         |        | Server) |
|         |               |         |        |         |
+-+-+-+-+-+               +-+-+-+-+-+        +-+-+-+-+-+
    ^                                            ^
    |                                            |
    | EAP API                                    | EAP API
    |                                            |
    V                                            V
+-+-+-+-+-+                                  +-+-+-+-+-+
|         |                                  |         |
|         |                                  |         |
|  EAP    |                                  |  EAP    |
|  Method |                                  |  Method |
|         |                                  |         |
+-+-+-+-+-+                                  +-+-+-+-+-+

Figure 1 - Pass-through relationship between EAP Client,
           NAS and Authentication Server.

In the illustration, EAP is spoken between one-way function, or it
     may be an independent quantity.  However possession of the Client and NAS,
encapsulated within a link layer protocol, such as PPP, defined MSK MUST
     NOT provide any information useful in
[RFC1661] determining the MK. An
     example, MSK, EMSK and IEEE 802, defined IV key derivation is given in [IEEE802].  The NAS then encapsulates



Aboba & Simon                Informational                      [Page 8]





INTERNET-DRAFT            EAP Keying Framework          21 December 2002 Appendix D.

Extended Master Session Key (EMSK)
     Additional keying material (64 octets) derived between the EAP within a AAA protocol such as RADIUS [RFC2869bis] or Diameter
[DiamEAP], and transports this back
     client and forth server that is not assumed to remain local to the AAA Server, which
acts as an EAP Server.  Since
     method.  However, unlike the NAS acts as a pass-through, EAP
methods reside only on MSK, the EAP Client and Server, interfacing EMSK is known only to the
operating system via an EAP API.

+-+-+-+-+-+               +-+-+-+-+-+
|         |               |         |
|         |               |         |
| Cipher- |               | Cipher- |
| Suite   |               | Suite   |
|         |               |         |
+-+-+-+-+-+               +-+-+-+-+-+
    ^                         ^
    |                         |
    |                         |
    |                         |
    V                         V
+-+-+-+-+-+               +-+-+-+-+-+
|         |               |         |
|         |===============|         |
|         |     EAP       |         |
|         |<------------->|   NAS   |
| Client  |               | (EAP    |
|         |===============| Server) |
|         | Link layer    |         |
|         | (PPP,IEEE802) |         |
|         |               |         |
+-+-+-+-+-+               +-+-+-+-+-+
    ^                         ^
    |                         |
    | EAP API                 | EAP API
    |                         |
    V                         V
+-+-+-+-+-+               +-+-+-+-+-+
|         |               |         |
|         |               |         |
|  EAP    |               |  EAP    |
|  Method |               |  Method |
|         |               |         |
+-+-+-+-+-+               +-+-+-+-+-+

Figure 2 - Relationship between EAP Client
     client and
           NAS (acting server and MUST NOT be provided to a third party. The
     EMSK therefore MUST NOT be transported by the backend
     authentication server to the authenticator. The EMSK is reserved
     for future uses that are not defined yet. For example, it could be
     used to derive additional keying material for purposes such as an EAP Server) where no
           Authentication Server fast
     handoff, man-in-the-middle vulnerability protection, etc. An
     example of fast handoff key derivation is present given in Appendix F.



Aboba & Simon                Informational                      [Page 9] 8]





INTERNET-DRAFT            EAP Keying Framework          21 December 2002


Once EAP authentication              2 March 2003


Initialization Vector (IV)
     A 64 octet quantity suitable for use in an initialization vector
     field, that is complete, derived between the EAP Client client and NAS pass data
between each other, encapsulated within the link layer protocol. In
order to protect server. Since in
     some EAP methods such as [RFC2716] the data, IV is a known value, the Client and NAS may negotiate and
subsequently implement a ciphersuite.

While pass-through operation is common with EAP, it is optional, so that
EAP may also IV
     MUST NOT be implemented in situations where no Authentication Server
is present. This is illustrated used in Figure 2. computation of any quantity that needs to
     remain secret.

Pairwise Master Key (PMK)
     In Figure 2, EAP [RFC2716], the MSK is spoken between divided into two halves, corresponding to
     the Client "Peer to Authenticator Encryption Key" (Enc-RECV-Key, 32
     octets) and NAS, encapsulated
within a link layer protocol, such as PPP or IEEE 802. Since "Authenticator to Peer Encryption Key" (Enc-SEND-Key,
     32 octets) (reception is defined from the NAS
terminates point of view of the EAP conversation rather than acting as a pass-through,
EAP methods are implemented on
     authenticator).  Within [IEEE80211i] Octets 0-31 of the NAS, MSK (Enc-
     RECV-Key) are also known as well the Pairwise Master Key (PMK).

     [IEEE80211i] ciphersuites derive their Transient Session Keys
     (TSKs) solely from the PMK, whereas the WEP ciphersuite, when used
     with [IEEE8021X], as on noted in [Congdon], derives its TSKs from both
     halves of the MSK, the Enc-RECV-Key and the Enc-SEND-Key.

Transient EAP Client,
interfacing Keys (TEKs)
     Session keys which are used to establish a protected channel
     between the  operating system via an EAP API.

Once peer and server during the EAP authentication is complete,
     exchange.  The TEKs are typically derived from the EAP Client MK, and NAS pass data,
encapsulated within the link layer protocol. In order to protect the
data, are
     appropriate for use with the Client and NAS may negotiate ciphersuite negotiated between EAP
     peer and subsequently implement a
ciphersuite.

2.1.  Ciphersuite independence

Within server as part the EAP authentication model, it is assumed exchange. Note that
     the ciphersuite
is negotiated used to set up the protected channel between the
     EAP Client peer and NAS using link layer
mechanisms.  While server during EAP methods which derive keys can be authentication is unrelated to the
     ciphersuite used to provide
automated keying, subsequently protect data sent between the EAP method SHOULD NOT generate ciphersuite-
specific keys or even contain ciphersuite-specific code.  Since it is
the Client and NAS that negotiate
     peer and implement the ciphersuite,
knowledge of authenticator.  In particular, the ciphersusite is restricted TEKs used to those entities.

Within protect
     the EAP 3-party model, the Authentication Server is not a party exchange MUST be cryptographically separate from TSKs used
     to the ciphersuite negotiation that occurs between the EAP Client and
NAS, and neither protect data. An example TEK key hierarchy is the Authentication Server involved described in the passing of
     Appendix C.

Transient Session Keys (TSKs)
     Session keys used to protect data which are appropriate for the
     ciphersuite negotiated between the EAP Client peer and NAS. Since authenticator. The
     TSKs are derived from the Authentication Server MSK by a process which is
not involved in link layer
     specific.  In the handling of data traffic, and may not even be aware case of the ciphersuite negotiated IEEE 802.11, TSK derivation is supported
     via a 4-way handshake that supports mutual authentication between
     the EAP Client peer and NAS, it cannot
be assumed to implement ciphersuite-specific code. In fact, the
Authentication Server cannot even be assumed to have knowledge authenticator. The 4-handshake also confirms
     mutual possession of the
ciphersuites available on the NAS and EAP Client.

Since the Authentication Server may not know the PMK as well as supporting protected
     ciphersuite negotiated
between EAP Client and NAS, it will not necessarily be able to make this
information available to a resident EAP method via the EAP APIs. As a
result, ciphersuite-specific key generation implemented within an EAP
method might not function correctly on every implementation.

Similarly, because the NAS negotiation. An example TSK derivation is not required to implement any EAP methods,
the NAS cannot be assumed to implement code specific to any EAP method. given in
     Appendix E.







Aboba & Simon                Informational                      [Page 10] 9]





INTERNET-DRAFT            EAP Keying Framework          21 December 2002


Since operating systems provide              2 March 2003


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         ---+
|                                                         |            ^
|                EAP APIs in order to remain "EAP-Method
Agnostic", Method                               |            |
|                                                         |            |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |            |
| |                                       |               |            |
| |                                       |               |            |
| |                                       |               |            |
| |        EAP APIs cannot be assumed Master Key (MK)            |               |            |
| |             Derivation                |               |            |
| |                                       |               |   Local to implement |
| |                                       |               |       EAP method-specific
code either.  |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |     Method |
|   |             |               |                       |            |
|   |                                                     |            |
|   | MK          |               |                       |            |
|   |                                                     |            |
|   V             |               |                       |            |
| +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ |            |
| |  TEK      | | MSK       | |EMSK       | |IV         | |            |
| |Derivation | |Derivation | |Derivation | |Derivation | |            |
| +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ |            |
|                 |               |                 |     |            |
|                 |               |                 |     |            V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         ---+
                  |               |                 |                  ^
                  |               |                 |                  |
                  | MSK (64B)     | EMSK (64B)      | IV (64B)         |
                  |               |                 |          Exported|
                  |               |                 |              by  |
                  |               V                 V              EAP methods deriving keys MUST support mutual authentication and provide
for the derivation of an |
                  |         +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+  Method|
                  |         |     Reserved    | | Known       |        |
                  |         |                 | |(Not Secret) |        |
                  |         +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+        V
                  |                                                 ---+
                  |                                        Transported |
                  |                                             by AAA |
                  |                                           Protocol |
                  V                                                    V
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                    ---+
   |                           |                                       ^
   |            TSK            |                           Ciphersuite |
   |        Derivation         |                              Specific |
   |                           |                                       V
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                    ---+

Figure 1 - EAP Master Key (EMK), known only to the Hierarchy



Aboba & Simon                Informational                     [Page 10]





INTERNET-DRAFT            EAP
Client and Server. Keying Framework              2 March 2003


3.1.  Exchanges

Figure 2 illustrates the EAP methods deriving keys also MUST provide for exchange in the
distribution of the CS-Token between the AAA Server and case where no backend
authentication server is present. Here EAP Client, and
the AN-Token is spoken between the AAA server peer
and NAS.  The MSK contained authenticator, encapsulated within
the CS-Token and AN-Tokens is suitable for use with any negotiated
ciphersuite, a lower layer protocol, such as
PPP, defined in [RFC1661] and therefore an EAP method MUST NOT directly use IEEE 802, defined in [IEEE802].  Since the MSK
authenticator acts as a Transient Session Key (TSK).  Rather, the TSK(s) are derived from an endpoint of the MSK in EAP conversation rather than a separate step, once the negotiated ciphersuite is known.

Drawbacks to utilizing
pass-through, EAP methods are implemented on the MSK authenticator as well
as a transient session key include:

Ciphersuite negotiation
               Enabling derivation of the TSK(s) in a separate step
               provides for additional security. For example, peer. If the TSK
               derivation supported within IEEE 802.11i enables EAP method negotiated between the EAP
               Client peer and NAS to mutually authenticate
authenticator supports mutual authentication and conduct a
               protected ciphersuite negotiation.  If the MSK key derivation, an EAP
Master Key (MK) is used
               directly as a TSK, then derived on the EAP Client peer and NAS may not
               mutually authenticate each other, authenticator and a protected
               ciphersuite negotiation, if it occurs at all, would
               typically need to be supported stored
locally within EAP itself. Since the ciphersuite negotiation mechanisms are typically
               particular to a given link layer, carrying this out
               within EAP method. The MK may not then be appropriate.

Document Revision
               If an EAP method specifies how used to derive transient
               session keys on a per-ciphersuite basis, the
               specification will need
Transient EAP Keys (TEKs) used to be revised each time a new
               ciphersuite is developed.  This would protect some or all of the EAP
exchange. The TEKs are also imply that an
               Authentication Server supporting an stored locally within the EAP method might and are
not
               be usable with all NASes supporting EAP, due exported.

Once mutual authentication completes and is successful, the peer and
authenticator exchange data, which may be protected using a ciphersuite.
In order to lack of
               support provide keys for the ciphersuite, Transient Session Keys
(TSKs) are required. On completion of a new ciphersuite implemented on a NAS. successful authentication, EAP method complexity
               Requiring
methods on the EAP method to include ciphersuite-specific
               code peer and authenticator export the Master Session Key
(MSK), Extended Master Session Key (EMSK) and IV. Of these quantities,
only the MSK is used today, for transient session key derivation increases of the
               complexity TSKs. The mechanism
for this is specific to the ciphersuite; for example, in [IEEE80211i],
the 4-way handshake is used.

Where no backend authentication server is present, the MSK and EMSK are
known only to the peer and authenticator and neither is transported to a
third party.  As demonstrated in [RoamCERT], despite the absence of a
backend authentication server, such exchanges can support roaming
between providers; it is even possible to support fast handoff
[IEEE80211f] without re-authentication. However, this is typically only
possible where both the EAP method, peer and authenticator support certificate-
based authentication, or where the user base is sufficiently small that
EAP authentication can occur locally.

Where these conditions cannot be met, a backend authentication server is
typically required.  In this exchange, as well described in [RFC2869bis], the
authenticator acts as Client a pass-through between the EAP peer and
               Authentication Server implementations.

Knowledge asymmetry a backend
authentication server. In practice, an EAP method may not have knowledge of this model, the
               ciphersuite that has been negotiated between 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.








Aboba & Simon                Informational                     [Page 11]





INTERNET-DRAFT            EAP Keying Framework          21 December 2002


               Client and NAS. In PPP, ciphersuite negotiation occurs
               via the Encryption Control Protocol (ECP), described in
               [RFC1968].  Since ECP negotiation occurs after
               authentication, unless an EAP method is utilized that
               supports ciphersuite negotiation, the Client, NAS and
               Authentication Server may not be able to anticipate the
               negotiated ciphersuite and therefore this information
               cannot be provided to the EAP method. Since ciphersuite
               negotiation is assumed to occur out-of-band of EAP, there
               is no need for ciphersuite negotiation within EAP.

3.              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
    |                         |
    |                         |
+-+-+-+-+-+               +-+-+-+-+-+
|         |               |         |
|  EAP Exchanges    |               |  EAP supports two modes of exchange:

[a]  Two-party exchange. The two-party exchange occurs where the    |
|  Method |               |  Method |
|         |               |         |
|(MK,TEKs)|               |(MK,TEKs)|
|         |               |         |
+-+-+-+-+-+               +-+-+-+-+-+

Figure 2 - Relationship between EAP
     Client peer and NAS act authenticator
           (acting as the endpoints of the an EAP conversation, and server), where no
     Authentication Server backend
           authentication server is present. Here the NAS implements the EAP
     method locally, rather than acting as a pass-through. In this mode,
     the EAP method used between the EAP Client and NAS (EAP Server)
     derives the EMK, as well as providing for the distribution of the
     Client-Server token containing the MSK.

[b]  Three-party exchange. This mode is used where the NAS acts as a
     pass-through and an Authentication Server (acting as an EAP Server)
     is present. In this mode, the EAP Server and Client derive the EMK,
     and the Authentication Server distributes to the CS-Token to the
     EAP Client and the AN-Token to the NAS.  Both the CS-Token and AN-
     Token contain the embedded MSK.

3.1.  Two-party exchange

Figure 3 illustrates the two-party exchange, where the Client is
authenticated locally by the NAS using a locally implemented
authentication method. In this case, the EAP Master Key (EMK) is derived
on the Client and the NAS, which acts as the EAP Server during the EAP
authentication exchange, and the Client-Server token is transported by
the NAS to the EAP Client.  The Client and NAS then use the MSK
contained with the CS-Token to derive the transient session keys used
with the selected ciphersuite. It is assumed that ciphersuite
negotiation is handled out of band, rather than within EAP. For example,
Within an IEEE 802.11 Reliable Secure Network (RSN), the TSK derivation
occurs using the RSN 4-way handshake.

If the authentication occurs with a method not implemented on the NAS,
or involves a non-local user whose credentials the Server is unable to
validate, then the NAS functions as a "pass-through".  For pass-through
authentication methods, instead of implementing the authentication



Aboba & Simon                Informational                     [Page 12]





INTERNET-DRAFT






Aboba & Simon                Informational                     [Page 12]





INTERNET-DRAFT            EAP Keying Framework          21 December 2002


method locally, the NAS delegates the authentication to an
Authentication Server. The Authentication Server installs the desired
EAP method, typically by interfacing with the operating system via an
EAP API, such as that described in [EAPAPI].

In order to allow the Client and Authentication Server to install new
EAP methods without requiring an operating system upgrade, operating
systems isolate EAP method-specific code within the installed EAP
methods, and thus largely operate as pass-through entities with respect
to EAP.              2 March 2003


+-+-+-+-+-+               +-+-+-+-+-+
|         |               |         |
|         |               |         |
| Cipher- |               | Cipher- |
| Suite   |               | Suite   |
|         |               |         |
+-+-+-+-+-+               +-+-+-+-+-+
    ^                         ^
    |                         |
    |                         |
    V                         V
+-+-+-+-+-+               +-+-+-+-+-+
|         |      EMK      |         |
|         |<=============>|   NAS   |
| Client  |               | (EAP    |
|         |   CS-Token    | Server) |
|         |<==============|         |
|         |               |         |
|         |   TSK Deriv.  |         |
|         |<=============>|         |
+-+-+-+-+-+               +-+-+-+-+-+
    ^                         ^
    |                         |
    | EAP API                 | EAP API
    |                         |
    V                         V
+-+-+-+-+-+               +-+-+-+-+-+
|         |               |         |
|         |               |         |
|  EAP    |               |  EAP    |
|  Method |               |  Method |
|         |               |         |
+-+-+-+-+-+               +-+-+-+-+-+

Figure 3 - Two-party exchange





Aboba & Simon                Informational                     [Page 13]





INTERNET-DRAFT            EAP Keying Framework          21 December 2002


3.2.  Three-party exchange

Figure 4 illustrates a three-party exchange where the NAS acts as a
pass-through. As described in the figure, the EAP conversation "passes
through" the NAS on its way between the Client and the Authentication
Server (which acts as the EAP Server).

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

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








Aboba & Simon                Informational                     [Page 14] 13]





INTERNET-DRAFT            EAP Keying Framework          21 December 2002


The three-way              2 March 2003


Figure 3 illustrates the EAP exchange takes part authentication process in several phases:

[a]  EAP authentication. During this phase, the EAP Client and Server
     mutually authenticate and derive case where
the EMK, which authenticator acts as a pass-through.  Here EAP is known only to spoken between
the EAP Client peer and Server. Since possession of the EMK would enable
     a third party to impersonate the authenticator as before. The authenticator then
encapsulates EAP Client packets within a AAA protocol such as RADIUS
[RFC2869bis] or Server, Diameter [DiamEAP], and forwards packets to and from the EMK MUST
     NOT be shared with any other party.  Where
backend authentication server, which acts as the EAP server.  Since the NAS
authenticator acts as a pass-
     through, it does not participate in the pass-through, EAP conversation, except to
     forward packets between methods (as well as the
derived EAP Client Master Key, and TEKs) reside only on the Authentication
     Server. As a result, the NAS does not possess the EMK peer and MUST NOT
     be able to derive it, based on observing backend
authentication server.

Once mutual authentication completes and is successful, the EAP conversation, or
     obtaining method
present on the MSK.

[b]  Token distribution. During this phase, peer and authenticator export the AAA Server acts as MSK, EMSK and IV. The
backend authentication server then sends a Key
     Distribution Center (KDC), distributing the CS-Token message to the EAP
     Client and authenticator
indicating that authentication has been successful, providing the AN-Token to MSK
within a protected package known as the NAS.  These tokens, which are
     defined in AN-Token. Along with the EAP Method and AAA key distribution specifications,
     respectively, contain MSK,
the MSK.

[c]  TSK derivation. During this phase, AN-Token contains attributes indicating the EAP Client and NAS confirm
     mutual possession parameters of key usage.
The MSK is then used by the MSK, authenticator and peer to derive the Transient
Session Keys
     used in (TSKs) required for the negotiated ciphersuite.

The TSKs are known only to the peer and authenticator, and as noted
earlier, the TSK derivation occurs out of
     band of EAP; an example is process varies by ciphersuite.  For example,
within the 4-way handshake provided described in IEEE
     802.11 RSN.

Figure 5 below illustrates [IEEE80211i], the relationship between peer and
authenticator confirm mutual possession of the parties in MSK, demonstrate
liveness, and do a protected ciphersuite and capabilities negotiation.

4.  Security properties

This section describes the
three-way exchange.

                   EAP Client
                      /\
                     /  \
 Protocol: security requirements for EAP      /    \   Protocol: methods, AAA
protocols, TSK derivation
 Auth: Mutual      /      \  Auth: Mutual
 Unique key: EMK  /        \ Unique key: TSK
 Token: CS-Token /          \
                /            \
    AAA Server +--------------+ NAS
                Protocol: AAA
                Auth: Mutual
             Unique key: AAA session key
                Token: AN-Token

Figure 5:  Three-party EAP key distribution

Where key distribution is supported, the EAP Client mechanisms and Authentication
Server (EAP Server) Ciphersuites. These
requirements MUST mutually authenticate via be met by specifications requesting publication as an
RFC. Based on these requirements, the negotiated security properties of EAP
method, and derive
exchanges are analyzed.

4.1.  EAP method requirements

Mutual authentication
     Methods deriving keys only known between MUST support mutual authentication.

Master Key
     Methods deriving keys MUST support derivation of the EAP Client and Server,
known Master Key
     (MK), as well as specifying how Transient EAP Keys (TEKs) are
     derived from the MK.

     The MK is the root of the EMK.  During EAP authentication, key hierarchy. As a result,
     compromise of MK must be avoided if at all possible, since an
     attacker in possession of the CS-Token MAY MK will be able to derive all the
     other keys in the hierarchy. This would provide an attacker with
     the ability not only to decrypt and insert data sent between a



Aboba & Simon                Informational                     [Page 15] 14]





INTERNET-DRAFT            EAP Keying Framework          21 December 2002


transported from the              2 March 2003


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

     Since the MSK MAY be derived from MK is known only to the EMK, via a
one-way function. Whether EAP peer and server, and only
     mutually authenticating EAP methods may distribute keys, possession
     of the MSK MK is derived or transported, possession proof of a completed mutual authentication.  In order
     to protect against compromise of the MSK MUST NOT provide information useful in determining MK, which could be used to
     impersonate the EMK.

Utilizing EAP peer or server the AAA protocol, MK and TEKs MUST remain
     local to the Authentication Server EAP method and NAS MUST
mutually authenticate, and derive a protected channel which MUST provide
per-packet integrity protection, authentication and confidentiality. The
AN-Token is distributed by the Authentication Server NOT be provided to third parties.
     In addition, the NAS over
this channel. Where possible, MK MUST NOT be derivable from material exported
     from the channel between EAP method, such as the Authentication
Server and NAS SHOULD MSK, EMSK or IV.  The MK MUST NOT
     be protected using a session key, as in [DiamEAP]
and RADIUS over IPsec [RFC3162], directly used to protect data; rather than using a static key, as in
RADIUS [RFC2865].

During the (optional) TSK TEKs and TSKs are used
     for this purpose.

MSK, EMSK and IV
     EAP methods supporting key derivation step, MUST export two 64 octet
     quantities, known as the EAP Client Master Session Key (MSK), and NAS MUST
mutually authenticate by providing mutual posession of the portion 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 used MSK, EMSK
     or IV does not provide information useful in determining the derivation.  The TSK MK.

Cryptographic separation
     Methods supporting key derivation step SHOULD also
provide for a protected ciphersuite negotiation MUST demonstrate cryptographic
     separation between the EAP Client TEK, MSK, EMSK and NAS.

The security IV branches of the three-party exchange is highly dependent on EAP
     key hierarchy.  Without violating a fundamental cryptographic
     assumption (such as the
security properties non-invertibility of a one-way function) an
     attacker recovering the algorithms chosen.  For example, TEK, MSK, EMSK or IV MUST NOT be able to
     recover the other quantities with a level of effort less than brute
     force.  Since Transient Session Keys (TSKs) are derived from the
     MSK, if mutual
authentication branch independence holds, then it is not completed between also true that the EAP Client and
Authentication server, then
     TSKs are cryptographically separate from the Client will be vulnerable to rogue
Authentication Servers EMSK, IV and NASes. If TEKs.

EMSK reservation
     While the EMK EMSK is not derived between exported by the
Client and Authentication Server, then there will be no binding between
the authentication EAP method, its use is reserved,
     and subsequent data traffic, leaving the session
vulnerable as a result it MUST remain known only to hijack.

If the Authentication Server and NAS do not mutually authenticate, then
the the EAP Client will once again be vulnerable to rogue Authentication
Servers, NASes or both. If there is no per-packet authentication,
integrity peer and replay protection between the Authentication Server
     server and
NAS, then the EAP conversation could MUST NOT be modified in transit, or packets
can spoofed.

If provided to third parties. Since the TSK derivation does not support mutual authentication, then EMSK is
     the only keying material exported by an EAP Client will not have assurance method that is neither
     provided to a third party nor a known quantity, it is connected attractive
     for use in future applications such as fast handoff or man-in-the-
     middle detection. Given its potential future uses, damage due to the right
NAS,
     EMSK compromise is second only that in effect to compromise of the NAS and AAA server share a trust relationship
(assuming that MK,
     yielding an attacker the AAA protocol supports mutual authentication). This
distinction can become important when multiple NASes receive MSKs from ability to access the Authentication Server, as may network at will, and
     to decrypt past and future data traffic.

Ciphersuite Independence
     The MK, MSK, EMSK and IV derivations MUST be independent of the case where fast handoff is
supported. If the TSK derivation does not provide for protected
ciphersuite negotiation, then downgrade attacks are possible.



Aboba & Simon                Informational                     [Page 16] 15]





INTERNET-DRAFT            EAP Keying Framework          21 December 2002


3.3.  EAP              2 March 2003


     selected ciphersuite.

Key hierarchy Strength
     The strength of Transient Session Keys (TSKs) and Transient EAP key hierarchy depends on two branches:

[a]  EAP Master Key (EMK) branch. The EMK
     Keys (TEKs) used to protect data is derived during ultimately dependent on the EAP
     conversation between
     strength of the MK, MSK and EMSK generated by the EAP Client method.  If
     EAP method does not produce an MK, MSK and Server, EMSK of sufficient
     strength, then the TSKs and TEKs derived
     from it are used may be subject to establish a protected channel between the EAP
     Client and Server.  Therefore, the EMK branch of the brute force
     attack.  EAP methods supporting key
     hierarchy describes the derivation MUST be capable of keys used to protect the EAP
     exchange itself.

     Since the EMK is uniquely held by the EAP Client
     generating a MK, MSK and Server, EMSK, each with an effective key strength
     of at least 128 bits. More details on key strength are provided in
     Section 5.3.

Perfect Forward Secrecy
     An EAP peer and
     only mutually authenticating server may simultaneously derive MSKs suitable for
     use with several authenticators, so as to enable fast handoff
     between them.  Similarly an EAP methods server may distribute keys, proof
     of possession of transport MSKs to
     multiple authenticators as the EMK is proof result of a completed mutual single authentication.  In order to ensure that the NAS does not possess
     the EMK, which could be used to impersonate the EAP Client or EAP
     Server, the EMK MUST NOT be provided to third parties
     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
     NAS, or be derivable from other keying material AAA protocol, such as the MSK. Diameter
     [DiamEAP] or RADIUS [RFC2869bis]. Key wrap mechanisms for Diameter
     are specified in [DIAMCMS], and for RADIUS in [RFC2548].

     In order to protect against compromise of the EMK, the EMK MUST NOT an individual MSK,
     Perfect Forward Secrecy (PFS) SHOULD be directly used to protect data; rather the TEKs derived from the
     EMK are used for this purpose. Examples supported, so that
     compromise of the EMK branch one MSK does not enable compromise of the
     key hierarchy are given subsequent or
     prior MSKs.

Uniqueness
     In order to assure non-repetition of TSKs even in Appendix A.

[b]  Master Session Key (MSK) branch. The cases where one
     party may not have a high quality random number generator, the MSK is (optionally)
     distributed by the Authentication Server to the EAP Client within
     the CS-Token (or alternatively, derived from the EMK). It is
     transported from the Authentication Server to the NAS within the
     AN-Token.  Since
     derivation SHOULD include a two-way nonce exchange, using nonces of
     at least 128-bits. Note although the MSK [IEEE80211i] 4-way handshake
     includes a nonce exchange, this is not ciphersuite-specific, it is larger
     than necessary, the case for all
     ciphersuites and media, so that to provide media independence, an
     EAP method cannot assume that a nonce exchange is truncated guaranteed to fit
     occur as part of TSK derivation.  A nonce exchange SHOULD also be
     included in the Transient
     Session Key (TSK) derivation process. As with the EMK, of the MSK MUST
     NOT be directly used to protect data; rather TSKs derived TEKs from the
     MSK are used for this purpose. Examples MK.

Known-good algorithms
     The development and validation of the MSK hierarchy are
     given in Appendix B.

4.  Security considerations

This section describes the security requirements for EAP methods, AAA
protocols, TSK key derivation mechanisms algorithms is
     difficult, and Ciphersuites involved in three-
party as a result EAP exchanges. These requirements MUST be met by specifications methods SHOULD reuse existing key
     derivation algorithms, rather than inventing new ones. EAP methods
     requesting publication as an RFC.

4.1.  Three-party exchange

The security of the three-party exchange is highly dependent on RFC MUST provide citations to
     literature justifying the security properties of the each of the protocols.  For example, if
mutual authentication is not completed between the chosen algorithms. EAP Client and
Authentication server, then the Client will be vulnerable to rogue
Authentication Servers
     methods SHOULD utilize well established and NASes. If the EMK is not derived between the analyzed mechanisms for



Aboba & Simon                Informational                     [Page 17] 16]





INTERNET-DRAFT            EAP Keying Framework          21 December 2002


Client and Authentication Server, then there will be no binding between
the authentication              2 March 2003


     MK, MSK, EMSK and subsequent data traffic, leaving the session
vulnerable to hijack.

If the Authentication Server and NAS do not mutually authenticate, then
the IV derivation.

4.2.  AAA protocol requirements

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

Security services
     AAA protocols used for transport of EAP Client will once again be vulnerable to rogue Authentication
Servers, NASes or both. If there is no MUST support per-packet authentication,
     integrity and authentication and SHOULD support replay protection between the Authentication Server
     and
NAS, then the confidentiality.  These requirements are met by Diameter EAP conversation could be modified
     [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 transit, or packets
can spoofed.

If the TSK derivation does not support mutual authentication, then the Diameter EAP Client will not have assurance that it is connected to the right
NAS, only that the NAS [DiamEAP]
     and AAA server share RADIUS over IPsec [RFC3162], rather than using a trust relationship
(assuming that the AAA protocol supports mutual authentication). This
distinction can become important when multiple NASes receive MSKs from
the Authentication Server, static key, as may be the case where fast handoff is
supported. If the TSK derivation does not provide
     in RADIUS [RFC2865].

Mutual authentication
     AAA protocols used for protected
ciphersuite negotiation, then downgrade attacks are possible.  As a
result, where physical security cannot be assumed, or roaming is
supported, the TSK derivation step SHOULD NOT be ommitted.

4.2. transport of EAP method requirements

EMK hierarchy
     Methods deriving keys MUST support mutual
     authentication and
     derivation of between the EMK, authenticator and backend authentication
     server. These requirements are met by Diameter EAP [DiamEAP] as
     well as specifying how TEKs are derived
     from the EMK. The EMK MUST NOT be used to directly protect data.

CS-Token specification
     Methods supporting key derivation MUST specify by RADIUS [RFC2865].

Forgery protection
     AAA protocols used for transport of EAP SHOULD provide protection
     against rogue authenticators masquerading as other authenticators.
     This can be accomplished, for example, by requiring that AAA agents
     to check the format source address of packets against the
     CS-Token containing 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 MSK. If no explicit CS-Token format is
     used, then AAA
     protocol MUST NOT transport TSKs from the formulas for derivation of backend authentication
     server to authenticator.

Key transport specification
     In order to enable backend authentication servers to provide keying
     material to the MSK MUST be provided.

MSK hierarchy
     For authenticator in a ciphersuite to be well defined format, AAA
     protocols suitable for use with dynamic keying via EAP a specification MUST be provided describing how TSKs are
     derived from the MSK.

Cryptographic Separation
     Methods supporting key derivation MUST demonstrate cryptographic
     separation between define the TEKs format and TSKs. Also, it must be demonstrated
     that possession
     wrapping of the package within which the MSK does not provide information useful in
     determining is transported, known
     as the EMK.

Ciphersuite Independence AN-Token. The MSK derivation SHOULD be ciphersuite-independent and definition of the EAP
     method SHOULD NOT assume knowledge AN-Token MUST include the
     definition of attributes binding the ciphersuite. key to the appropriate
     session, and providing limitations on key usage, such as the
     indicated key lifetime.



Aboba & Simon                Informational                     [Page 18] 17]





INTERNET-DRAFT            EAP Keying Framework          21 December 2002


Key size
     An EAP method supporting key derivation MUST generate a 192 octet
     MSK.

Key Entropy
     The strength of session keys is dependent upon the security of              2 March 2003


EMSK exposure
     Since the
     EAP method. If EMSK is a secret known only to the chosen EAP method has security vulnerabilities,
     or does not produce an EMK backend authentication
     server and MSK of sufficient entropy then peer, the
     security of the three-party exchange is reduced.  An EAP method
     supporting key derivation SHOULD generate an EMK and MSK with at
     least 128 bits of entropy.

Session Uniqueness
     In order to assure non-repetition of TSKs even in cases where one
     party may not have a high quality random number generator, the MSK
     derivation SHOULD include a two-way nonce exchange, using nonces of
     at least 128-bits. Note although the IEEE 802.11 RSN TSK derivation
     includes a nonce exchange, the TSK derivation step is link layer
     dependent, so that a link layer nonce exchange cannot be guaranteed
     to occur. As a result, a nonce exchange is still needed within the
     EAP method itself. A nonce exchange SHOULD also be included in the
     derivation of the TEKs from the EMK.

Known-good algorithms
     The development and validation of key derivation algorithms is
     difficult, and as a result EAP methods SHOULD reuse existing
     algorithms, rather than inventing new ones. EAP methods requesting
     publication as an RFC MUST provide citations to literature
     justifying the security of the chosen algorithms. EAP methods
     SHOULD utilize well established and analyzed mechanisms for EMK and
     MSK derivation.

4.3. AAA protocol requirements

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

AN-Token specification
     In order to enable Authentication Servers to provide keying
     material to NOT transport the NAS in a well defined format, AAA protocols
     suitable for use with EAP MUST define EMSK from
     the format and wrapping of backend authentication server to the AN-Token. authenticator.

AN-Token protection
     To ensure against compromise, the AN-Token MUST be integrity
     protected, authenticated authenticated, replay protected and encrypted in
     transit, using well-
     established well-established cryptographic algorithms. In order to protect  For
     example, the AN-
     Token from modification by AAA intermediaries, where untrusted



Aboba & Simon                Informational                     [Page 19]





INTERNET-DRAFT            EAP Keying Framework          21 December 2002


     intermediaries are present, it AN-Token SHOULD be protected using well-
     established algorithms, such as is described in Diameter CMS
     Security [DiamCMS], a work in progress. Proper key hygiene is
     critical for protection of the AN-Token, which SHOULD protected with session keys as in
     Diameter CMS Security [DiamCMS] (a work in progress) or RADIUS over
     IPsec [RFC3162] [RFC2869bis] rather than static keys, as in [RFC2548].

     Where untrusted intermediaries are present, the AN-Token SHOULD be
     protected by data object security mechanisms, such as Diameter CMS
     Security [DiamCMS] (a work in progress).

4.3.  TSK derivation requirements

The Transient Session Key (TSK) derivation process is assumed to provide
for the following:

Direct operation
     The TSK derivation process MUST operate directly between the peer
     and authenticator, and MUST NOT be passed-through to the backend
     authentication server.

Mutual authentication
     Where EAP is used on link layers which cannot be assumed to be
     physically secure (e.g.  wireless, the Internet), the TSK
     derivation process MUST provide for mutual authentication between
     the authenticator and peer.

Protected negotiation
     Where EAP is used on link layers which cannot be assumed to be
     physically secure (e.g. wireless, the Internet), the TSK derivation
     process SHOULD support protected ciphersuite and capabilities
     negotiation.

Uniqueness
     Where MSKs may be cached on the authenticator and peer, the TSK
     derivation process MUST provide unique TSKs for each session, even
     where the MSK is unchanged.








Aboba & Simon                Informational                     [Page 18]





INTERNET-DRAFT            EAP Keying Framework              2 March 2003


4.4.  Ciphersuite requirements

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

TSK derivation
     In order to key a ciphersuite with EAP, it is necessary to specify
     how the TSKs required by the ciphersuite are derived from the MSK.
     Derivation of the TSKs keys from the MSK requires knowledge of the
     negotiated ciphersuite.

TEK derivation
     In order to establish a protected channel between the EAP Client peer and Server
     server as part of the EAP exchange, a ciphersuite needs to be
     negotiated and keyed, using TEKs derived from the EMK. MK.  The
     ciphersuite used to protect the EAP exchange between the peer and
     server is distinct from the ciphersuite negotiated between the EAP client peer
     and NAS, 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 EMK 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 EMK 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 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 MSK.








Aboba & Simon                Informational                     [Page 20] 19]





INTERNET-DRAFT            EAP Keying Framework          21 December 2002


5.  Normative References

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

[RFC2119]      Bradner, S., "Key words for              2 March 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

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 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 peer and backend authentication server. As a result, mutual
authentication between the peer and authenticator only occurs where a
separate TSK derivation step is carried out, such as 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 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 AN-Token. The
binding of attributes to the MSK within a protected package is important
so the authenticator receiving the AN-Token can determine that it has
not been compromised, and that the keying material has not been
replayed, or mis-directed in some way.





Aboba & Simon                Informational                     [Page 20]





INTERNET-DRAFT            EAP Keying Framework              2 March 2003


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

Where an untrusted AAA intermediary is present, data object security
SHOULD be used to encrypt, authenticate, integrity and 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 and authenticator
SHOULD mutually authenticate by proving mutual possession of all or a
portion of the MSK. It is also advisable for the TSK derivation step to
support protected ciphersuite and capabilities negotiation, and derive
TSKs which are guaranteed to be unique for each session.  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 that the TSKs are fresh.

5.  Security considerations

5.1.  Assumptions

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

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

If the authenticator and backend authentication 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, then an attacker can
spoof or modify packets in transit.  If the backend authentication
server does not protect against authenticator masquerade, or provide the
proper binding of the MSK to the session within the AN-Token, then one
or more MSKs may be sent to an unauthorized party, and an attacker may
be able to gain access to the network. If the AN-Token is not opaque to
an untrusted AAA intermediary, then that intermediary may be able to
modify the MSK, or the attributes associated with it, as described in



Aboba & Simon                Informational                     [Page 21]





INTERNET-DRAFT            EAP Keying Framework              2 March 2003


[RFC2607].

If the TSK derivation algorithm does not support mutual authentication,
then the peer will not have assurance that it is connected to the
correct authenticator, only that the authenticator and backend
authentication server share a trust relationship (assuming that the AAA
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 the
TSK derivation does not provide for protected ciphersuite and
capabilities negotiation, then downgrade attacks are possible.

5.2.  Key binding

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 FQDN, it also may
not correspond to the source address, even indirectly.  [RFC2865]
Section 3 states:

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

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

As recommended in [RFC2869bis], 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, they can be sent by the EAP peer to the
server, and protected by TEKs.  The RADIUS server can then check the
parameters sent by the EAP peer against those claimed by the
authenticator. If a discrepancy is found, an error can be logged.

While [DiamBASE] requires use of the Route-Record AVP, this utilizes



Aboba & Simon                Informational                     [Page 22]





INTERNET-DRAFT            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 the AN-Token, and allow the backend authentication
server to authenticate the authenticator directly. This requires the
authenticator to provide proof of its identity, ensuring that the MSK is
being provided to the correct entity.

5.3.  Key strength

In order to guard against brute force attacks, EAP methods deriving keys
need to be capable of generating an MK, MSK and EMSK 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.  Key wrap

As described in [RFC2869bis], 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], Section 4.2, these and other RADIUS vulnerabilities may be
addressed by running RADIUS over IPsec.



Aboba & Simon                Informational                     [Page 23]





INTERNET-DRAFT            EAP Keying Framework              2 March 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 by which the EAP peer and 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 yet
must be derived from quantities that are exported by EAP methods, it may
be desirable to derive the compound key from a portion of the EMSK. In
order to provide proper key hygiene, it is recommended that the compound
key used for man-in-the-middle protection be cryptographically separate
from other keys derived from the EMSK, such as fast handoff keys,
discussed in 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", RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

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

[RFC2284bis]   Blunk, L., Vollbrecht, J., Aboba, B., "Extensible
               Authentication Protocol (EAP)", Internet draft (work in
               progress), draft-ietf-pppext-rfc2284bis-08.txt, December
               2002.




Aboba & Simon                Informational                     [Page 24]





INTERNET-DRAFT            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 and
               information exchange between systems - Local and
               metropolitan area networks - Specific Requirements Part
               11:  Wireless LAN Medium Access Control (MAC) and
               Physical Layer (PHY) Specifications, IEEE Std.
               802.11-1997, 1997.

[IEEE8021X]    IEEE Standards for Local 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. 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. and T. Narten, "Guidelines for Writing an
               IANA Considerations Section in RFCs", BCP 14, 26, RFC 2119, 2434,
               October 1998.

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

[RFC2284bis]   Blunk, L., 1999.

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





Aboba & Simon                Informational                     [Page 25]





INTERNET-DRAFT            EAP Keying Framework              2 March 2003


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

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

[RFC3078]      Pall, G. and Zorn, G. "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.

[Congdon]      Congdon, P., et al., "IEEE 802.1X RADIUS Usage
               Guidelines", Internet draft (work in progress), draft-
               congdon-radius-8021x-23.txt, February 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]   IEEE Draft 802.11F/D5, "Draft Recommended Practice for
               Multi-Vendor Access Point Interoperability via an Inter-
               Access Point Protocol (EAP)", Internet draft (work in
               progress), draft-ietf-pppext-rfc2284bis-08.txt, December
               2002.

[IEEE80211]    Information technology - Across Distribution Systems
               Supporting IEEE 802.11 Operation", January 2003.

[IEEE80211i]   IEEE Draft 802.11I/D3.1, "Draft Supplement to STANDARD
               FOR Telecommunications and
               information exchange Information Exchange between systems - Local and
               metropolitan area networks
               Systems - LAN/MAN Specific Requirements - Part 11:
               Wireless LAN Medium Access Control (MAC) and
               Physical Layer physical layer
               (PHY) Specifications, 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



Aboba & Simon                Informational                     [Page 26]





INTERNET-DRAFT            EAP Keying Framework              2 March 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 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, G., "Diameter Extensible Authentication
               Protocol (EAP) Application", Internet draft (work in
               progress), draft-ietf-aaa-eap-00.txt, 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 for IAPP Latency
               Improvement during 802.11 Handoff", IEEE Std.
               802.11-1997, 1997.

[IEEE8021X] 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 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., Hoffman, P., "Determining Strengths For Public
               Keys Used For Exchanging Symmetric Keys", Internet draft
               (work in progress), draft-orman-public-key-
               lengths-05.txt, December 2001.

[8021XHandoff] Pack, S., Choi, Y., "Pre-Authenticated Fast Handoff in a
               Public Wireless LAN Based on IEEE Standards for Local 802.1X Model", School



Aboba & Simon                Informational                     [Page 27]





INTERNET-DRAFT            EAP Keying Framework              2 March 2003


               of Computer Science and Metropolitan Area Networks:
               Port based Network Access Control, IEEE Std 802.1X-2001,
               June Engineering, Seoul National
               University, Seoul, Korea, 2002.

6.  Informative References

[RFC1968]      Meyer, G.,

[MD5Attack]    Dobbertin, H., "The PPP Encryption Protocol (ECP)", RFC 1968,
               June Status of MD5 After a Recent Attack",
               CryptoBytes Vol.2 No.2, Summer 1996.

[RFC2104]      Krawczyk,

[MiTM]         Puthenkulam, J., et al, "HMAC: Keyed-Hashing for Message
               Authentication", RFC 2104, February 1997.

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

[RFC2409]      Harkins, D., Carrel, D., "The Compound Authentication
               Binding Problem", 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. and T. Narten, "Guidelines for Writing an
               IANA Considerations Section draft (work in RFCs", BCP 26, RFC 2434,
               October 1998. progress),
               draft-puthekulam-eap-binding-02.txt, March 2003.










































Aboba & Simon                Informational                     [Page 21] 28]





INTERNET-DRAFT            EAP Keying Framework          21 December 2002


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

[RFC2716]      Aboba, B., Simon, D.,"PPP 2003


Appendix A - Ciphersuite independence

The Master Session Key (MSK), Extended Master Session Key (EMSK) and IV
exported by EAP methods MUST be ciphersuite independent. This confers
several advantages:

Ciphersuite negotiation
     Enabling derivation 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 and capabilities negotiation.  If the MSK is used
     directly as a TSK, then the EAP peer and authenticator may not
     mutually authenticate each other, and a protected ciphersuite
     negotiation, if it occurs at all, would typically need to be
     supported within EAP TLS Authentication
               Protocol", RFC 2716, October 1999.

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

[RFC3078]      Pall, G. itself. Since the ciphersuite negotiation
     mechanisms are link-layer specific, this would introduce media and Zorn, G. "Microsoft Point-to-Point
               Encryption (MPPE) RFC 3078, March 2001.

[RFC3079]      Zorn, G. "Deriving Keys
     ciphersuite dependencies into EAP.

Document Revision
     If an EAP method specifies how to derive transient session keys for use
     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 an EAP method would not be
     usable 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.

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

[DESMODES]     National Bureau 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 to include ciphersuite-specific code for TSK
     derivation increases the complexity of Standards, "DES Modes the EAP method.

Knowledge asymmetry
     In practice, an EAP method may not have knowledge of Operation",
               FIPS PUB 81 (December 1980).

[FIPS197]      FIPS PUB 197, Advanced the
     ciphersuite that has been negotiated between the peer and
     authenticator. In PPP, ciphersuite negotiation occurs via the
     Encryption Standard (AES), 2001
               November 26H.

[SHA]          National Institute of Standards Control Protocol (ECP), described in [RFC1968].  Since
     ECP negotiation occurs after authentication, unless an EAP method
     is utilized that supports ciphersuite negotiation, the peer,
     authenticator and backend authentication server may not be able to
     anticipate the negotiated ciphersuite and Technology (NIST),
               "Announcing therefore this
     information cannot be provided to the Secure Hash Standard," FIPS 180-1, U.S.
               Department of Commerce, 04/1995

[IEEE80211i]   IEEE Draft 802.11i/D3, "Draft Supplement EAP method. Since ciphersuite
     negotiation is assumed to STANDARD FOR
               Telecommunications and Information Exchange between
               Systems - LAN/MAN Specific Requirements - Part 11:
               Wireless Medium Access Control (MAC) and physical layer
               (PHY) specifications: Specification occur out-of-band, there is no need for Enhanced
               Security", November 2002.

[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

[RFC2869bis]   Aboba, B., Calhoun, P., "RADIUS Support For Extensible
               Authentication Protocol (EAP)", Internet draft (work in
               progress), draft-aboba-radius-rfc2869bis-05.txt, December
               2002.
     ciphersuite negotiation within EAP.







Aboba & Simon                Informational                     [Page 22] 29]





INTERNET-DRAFT            EAP Keying Framework          21 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,              2 March 2002.

[DiamEAP]      Hiller, T., Zorn, G., "Diameter Extensible Authentication
               Protocol (EAP) Application", Internet draft (work in
               progress), draft-ietf-aaa-eap-00.txt, June 2002.












































Aboba & Simon                Informational                     [Page 23]





INTERNET-DRAFT            EAP Keying Framework          21 December 2002 2003


Appendix A B - Ciphersuite keying requirements

To date, PPP and IEEE 802.11 ciphersuites are suitable for keying by
EAP.  This Appendix describes the transient session 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 RFC 2419 [RFC2419] and DES-EDE3-CBC, used in RFC 2420) [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 can be are required in each
direction, as described in [RFC3078]. Since MPPE is based on the
RC4 algorithm, no No initialization vector is
required.

While these PPP ciphersuites provide encryption, they do not provide a
per-packet keyed message authentication or integrity check (MIC). Thus, protection, so an authentication
key is not required in either direction.

Within 802.11, transient session keys [IEEE80211], Transient Session Keys (TSKs) are required both for
unicast traffic as well as for multicast traffic, and therefore separate TSK
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 include a keyed MIC, so that
an support per-packet
authentication key is not required in either direction. However, in
order and integrity protection.  In addition to protect the transport of the multicast these unicast
keys, authentication and encryption keys from the Access
Point are required to wrap the Station, additional authentication and
multicast encryption keys are
required. 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].
This includes 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 24] 30]





INTERNET-DRAFT            EAP Keying Framework          21 December 2002              2 March 2003


Appendix B C - Example EMK TEK Hierarchy

In EAP TLS [RFC2716], ciphersuite negotiation and derivation of

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

Master_secret

master_secret = TLS-PRF(Pre-Master-Secret, TLS-PRF-48(pre_master_secret, "master secret" ||
                server.random secret",
                client.random || client.random) server.random)
TEK           = TLS-PRF-X(Master-Secret, 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
master_secret = TLS term for the EMK.

Figure B-1 illustrates the EMK key hierarchy, which is derived from the
TLS key hierarchy described in [RFC2246].
































Aboba & Simon                Informational                     [Page 25]





INTERNET-DRAFT            EAP Keying Framework          21 December 2002 MK.

       |                       |                           |
       |                       | Pre-Master-Secret pre_master_secret         |
 Server|
 server|                       |                           | Client client
 Random|                       V                           | Random
       |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       |
       |     |                                     |       |
       |     |                                     |       |
       +---->|             Master-Secret             master_secret           |<------+
       |     |               (EMK)               (MK)                  |       |
       |     |                                     |       |
       |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       |
       |                       |                           |
       |                       |                           |
       |                       |                           |
       V                       V                           V
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 |                                                               |
 |                         Key Block                             |
 |                          (TEKs)                               |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           |           |           |           |           |
   | Client client    | Server server    | client    | server    | Client client    | Server server
   | MAC       | MAC       | write     | write     | IV        | IV
   |           |           |           |           |           |
   |           |           |           |           |           |
   V           V           V           V           V           V
                       +-+-+-+-+   +-+-+-+-+   +-+-+-+-+   +-+-+-+-+
                       |       |   |       |   |       |   |       |
                       | Final |   | Final |   | Final |   | Final |
       Export -------->| Client|   | Server|   | Client|   | Server|
                       | Write |   | Write |   |  IV   |   |  IV   |
                       |       |   |       |   |       |   |       |
                       +-+-+-+-+   +-+-+-+-+   +-+-+-+-+   +-+-+-+-+

Figure B-1 C-1 - TLS [RFC2246] Key Hierarchy





Aboba & Simon                Informational                     [Page 26] 31]





INTERNET-DRAFT            EAP Keying Framework          21 December 2002              2 March 2003


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

In EAP TLS EAP-TLS [RFC2716], the MSK is not 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 within 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 CS-Token
package.  Rather, 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 is MSK, EMSK and IV are derived from the EMK MK via a one-way
function. This ensures that the EMK MK cannot be derived from the MSK MSK, EMSK
or IV unless the one-way function (TLS PRF) is broken.  Since the MSK is
derived from the EMK, MK, if the EMK MK is compromised then the MSK is also
compromised. However, this would be the case even if the
MSK were cryptographically separate from the EMK, since TEKs derived
from the EMK are used to protect the CS-Token containing the MSK. Thus
if the EMK is compromised, so are the TEKs, the CS-token and ultimately
the MSK.

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

MSK(0,127)

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

MSK(0,31)   = Peer to Authenticator Encryption Key (Enc-RECV-Key)
               (MS-MPPE-Recv-Key in [RFC2548])
MSK(32,63)  = Authenticator to Peer Encryption Key (Enc-SEND-Key)
               (MS-MPPE-Send-Key in [RFC2548])
MSK(64,95)
EMSK(0,31)  = Peer to Authenticator Authentication Key (Auth-RECV-Key)
MSK(96,127)
EMSK(32,63) = Authenticator to Peer Authentication Key (Auth-Send-Key)
MSK(128,159)=
IV(0,31)    = Peer to Authenticator Initialization Vector (RECV-IV)
MSK(160,191)=
IV(32,63)   = Authenticator to Peer Initialization vector (SEND-IV)

Where:

IV(W,Z)       = Octets W through Z inclusive of the IV.
MSK(W,Z)      = Octets W through Z inclusive of the MSK.
EMK
EMSK(W,Z)     = Octets W through Z inclusive of the EMSK.
MK            = TLS master secret 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 C-1 D-1 describes the process by which the MSK, MSK,EMSK,IV and ultimately
the TSKs, are derived from the EMK. MK. Note that in [RFC2716], the EMK MK is
referred to as the "TLS Master Secret".











Aboba & Simon                Informational                     [Page 27]





INTERNET-DRAFT            EAP Keying Framework          21 December 2002

                                                                    ---+
                              |                                        ^
                              | TLS Master Secret (EMK) (MK)                 |
                              |                                        |
                              V                                        |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                    |
            |                                     |            EAP     |
            |       Master Session Key (MSK)      |           Method   |
            |              Derivation             |                    |
            |                                     |                    |                    V
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+             EAP ---+
              |               |                 |                      |
              | MSK (0,127)               API    ^
              | MSK (128, 192)       |
              |                                 |                      |
              V                                 V                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+        |
|                               | |                           |        |
|                               | |                           |        |
|          Key   Derivation           | EMSK            | IV Derivation                   |
              |               |                 |                      |
              V               V                 V                      v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     ---+
|                                                             |        |
|                                                             |        |
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+                       AAA server                            |        | P->A
| A->P                                                             | P->A        | A->P
| P->A                                                             | A->P    EAP        V
  | Enc.  | Enc.  | Auth. | Auth.     | IV            | IV      API
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     ---+
  | Key   | Key   | Key   | Key       |                 |                                                  ^
  | (32B) | (32B) MSK(0,31)       | (32B) MSK(32,63)                                       | (32B)
  | (32B) (PMK)           | (32B)   AAA                                     Transported  |
  |                 |                                        via AAA   |
  |                 |                                                  |        Keys    V
  V       V       V
  V                 V                                                  V             ---+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      ^
|   ---+
|                                                               |      ^
|                Ciphersuite-Specific Truncation &              |  NAS Transient Session         | Auth.|
|                       Key utilization Derivation                          |      |
|                                                               |      V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   ---+

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











Aboba & Simon                Informational                     [Page 33]





INTERNET-DRAFT            EAP Keying Framework              2 March 2003


Appendix E - 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), otherwise known in [RFC2716] as the Peer to
Authenticator Encryption Key. Within [RFC2548], the PMK is transported via the MS-
MPPE-Recv-Key attribute.  In IEEE 802.11 RSN, [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))





Aboba & Simon                Informational                     [Page 28]





INTERNET-DRAFT            EAP Keying Framework          21 December 2002 key expansion", Min(AA,SA) ||
      Max(AA, SA) || Min(ANonce,SNonce) || Max(ANonce,SNonce))

Where:

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

TKIP uses X = 512, 64, while CCMP, WRAP, and WEP use X = 384. 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 Encr. 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. Additional details Details are available in [IEEE80211i].





















Aboba & Simon                Informational                     [Page 34]





INTERNET-DRAFT            EAP Keying Framework              2 March 2003


Appendix F - Example PMK 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 = MSK(0,31)
PMK1-B = PRF(EMSK(0,31),PMK0-A,APB-MAC-Addr,STA-MAC-Addr)
PMK1-E = PRF(EMSK(0,31),PMK0-A,APE-MAC-Addr,STA-MAC-Addr)

Here PMK0-A is the Pairwise Master 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 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 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 of Cisco Systems, and Russ Housley
of RSA 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]





INTERNET-DRAFT            EAP Keying Framework              2 March 2003


One Microsoft Way
Redmond, WA 98052

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





Aboba & Simon                Informational                     [Page 29]





INTERNET-DRAFT            EAP Keying Framework          21 December 2002

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 (2002). (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
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."







Aboba & Simon                Informational                     [Page 30]





INTERNET-DRAFT            EAP Keying Framework          21 December 2002

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-05.txt>, <draft-aboba-pppext-key-problem-06.txt>,  and
expires July August 22, 2003.




































Aboba & Simon                Informational                     [Page 31] 37]


----