view Side-By-Side changes

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



                          EAP Key Management Guidelines 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).  All Rights Reserved.

Abstract

This document describes the issues involved in framework for key derivation by EAP methods
and provides guidelines for generation and usage of keys derived by EAP keys.
methods requesting publication as an RFC.  Algorithms for key derivation
or mechanisms for key transport are not specified in this document.
Rather, this document lays out provides a framework within which EAP key
management derivation
algorithms and transport mechanisms can be discussed and evaluated.









Aboba & Simon                Informational                      [Page 1]





INTERNET-DRAFT            EAP Key Mgmt.              6 Keying Framework          21 December 2002


Table of Contents

1.     Introduction ..........................................    3
   1.1       Requirements language ...........................    4
   1.2       Terminology .....................................    4
2.     EAP architecture overview .............................    5    7
   2.1       Implications of the architecture ................    8
   2.2       Ciphersuite independence ........................   10
3.     EAP Exchanges .........................................   12
   3.1       Two-party exchange ..............................   12
   3.2       Three-party exchange ............................   14
   3.3       EAP key hierarchy ...............................    9
3.     EAP Keying Requirements   17
4.     Security considerations ...............................   10
   3.1   17
   4.1       Three-party exchange ............................   17
   4.2       EAP method requirements .........................   10
   3.2   18
   4.3       AAA protocol requirements .......................   19
   4.4       Ciphersuite requirements ........................   13
4.     Security considerations ...............................   14   20
5.     Normative references ..................................   14   21
6.     Informative references ................................   14   21
Appendix A - Ciphersuite keying requirements .................   24
Appendix B - Example EMK hierarchy ...........................   25
Appendix C - Example MSK hierarchy ...........................   27
Acknowledgments ..............................................   16   29
Author's Addresses ...........................................   16   29
Intellectual Property Statement ..............................   16   30
Full Copyright Statement .....................................   17   30


























Aboba & Simon                Informational                      [Page 2]





INTERNET-DRAFT            EAP Key Mgmt.              6 Keying Framework          21 December 2002


1.  Introduction

The Extensible Authentication Protocol (EAP), defined in [RFC2284], [RFC2284bis],
was originally developed to provide extensible authentication for use
with PPP [RFC1661]. Since then, new applications of EAP have emerged,
including IEEE 802.1X network port authentication [IEEE8021X], and PIC [PIC]. [IEEE8021X].

The primary purpose of EAP is to authenticate an EAP Client to a Network
Access Server (NAS), an EAP
Server, as well as to provide keys for use with a
ciphersuite. link layer ciphersuite
negotiated between an EAP presumes that prior to authentication, Client and a Network Access Server (NAS).  EAP
can be deployed in configurations where the EAP Client Server and NAS have located each other via some out-of-band mechanism. For
example, for use with PPP, the Client might contain are co-
located, supporting a phone book that
would provide phone numbers of NASes used with the selected service. In
IEEE 802.11, two-party exchange; alternatively, it can be
deployed in configurations where the Client (also EAP Server is located on a separate
entity, known as an Authentication Server. In this case, EAP supports a Station) may locate NAS devices
(also known
three-party exchange, where the Authentication Server acts as Access Points) using a Key
Distribution Center (KDC), and the IEEE 802.11 Beacon Authentication Server and Probe
Request/Response frames. NAS
communicate using a AAA protocol supporting EAP also assumes that ciphersuite negotiation as well as key wrap.
Examples of AAA protocols supporting EAP include RADIUS [RFC2869bis],
and selection is done out-of-band, Diameter [DiamEAP]; examples of AAA key wrap specifications include
[RFC2548] and therefore need not be handled
within [DiamCMS].

EAP itself. For example, a Client might be preconfigured with the
ciphersuite to be used in communicating with a given NAS, or
alternatively, the ciphersuite may be negotiated out-of-band. For
example, within PPP, the ciphersuite is negotiated within the Encryption
Control Protocol (ECP) after EAP authentication is completed. Within
IEEE 802.11i, the AP capabilities (including ciphersuite) are advertised
in the Beacon and Probe Responses, and are verified during a 4-way
exchange after EAP authentication has completed. The desired ciphersuite
is indicated within the Association/Reassociation Request/Response
exchange.

EAP methods defined methods defined in [RFC2284bis] include EAP MD5, as well as One-Time
Password (OTP) and Generic Token Card methods. Each of these methods
supports one-way authentication only (EAP Client to EAP Server) but not
key derivation.  However, 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 to be physically
secure. Where this is not the case, a session established over the link
subsequent to authentication would be subject to hijacking, since
without 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 method specifications methods such as EAP
TLS [RFC2716], EAP SRP
[EAPSRP], EAP GSS [EAPGSS] and EAP AKA [EAPAKA] have provided for [RFC2716] that support mutual authentication, as well as key
derivation.

The ciphersuites

In order for which EAP may methods to provide appropriate keying material have also
grown in number.  With for link
layer ciphersuites, the keying requirements of the increase ciphersuites need to
be understood and provided for. These requirements are discussed in
Appendix A.  With the number increasing deployment of EAP methods and
applicable link layer ciphersuites,
particularly with wireless networks, there is a need for defining how transient
session keys are derived from the master secrets produced by a clear
specification of what is expected of EAP
methods, and how keys are used to provide cryptographic binding between methods used 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 Section 2.1, a sequence or tunnel.  Allowing each discussion of the implications for EAP method to
handle this in its own way is likely to produce unacceptable results.

This document reviews methods
generating keys.  Section 3 describes both the issues involved in EAP key derivation two-party (Section 3.1)
and
provides guidelines for the generation of keys by three-party (Section 3.2) exchanges. An introduction to the EAP methods.
key hierarchy is provided in Section 3.3.



Aboba & Simon                Informational                      [Page 3]





INTERNET-DRAFT            EAP Key Mgmt.              6 Keying Framework          21 December 2002


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

Appendix A provides a summary of the keying requirements of link layer
ciphersuites supported on PPP and IEEE 802.11. Appendix B provides an
example EAP Master Key (EMK) hierarchy. Appendix C provides an example
Master Session Key (MSK) hierarchy.

1.1.  Requirements language

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

1.2.  Terminology

This document frequently uses the following terms:

Authentication Server
          An Authentication Server

Client-Server Token (CS-Token)
     The package within which the MSK is an entity that provides an
          Authentication Service to a Network Access transported between the EAP
     Server (NAS). This
          service verifies and the EAP Client.  The package MUST be integrity
     protected, authenticated and encrypted, so as to protect the MSK
     from compromise. In addition to the credentials provided by MSK, the Client, CS-Token MAY include
     one or more attributes providing information on MSK usage.
     Attributes may include the claim NAS layer 2 and layer 3 addresses, MSK
     lifetime, etc. The format of identity made by the Client. Where an
          Authentication Server CS-Token is provided, it acts as defined by the EAP server,
          terminating EAP conversation with
     method. Support for the CS-Token is optional and most current EAP Client.

Cryptographic binding
          The demonstration
     methods do not support it, since they derive the MSK as part of the EAP Client
     EMK key hierarchy, and thus do not need to transport it separately.
     However, in the EAP Server that a
          single entity has acted as the case where an EAP Client for all methods
          executed within a sequence or tunnel. Binding MAY also imply
          that the EAP Server demonstrates needs to the Client that a single
          entity has acted handle multiple
     MSKs, such as the EAP when it is connected to multiple NASes
     simultaneously, or where an Authentication Server for all is sending MSKs
     to multiple NASes in order to support fast handoff, use of methods executed
     supporting the CS-Token may be desirable.

AAA-NAS Token (AN-Token)
     The package within a sequence or tunnel. If executed correctly, binding
          serves to mitigate man-in-the-middle vulnerabilities. which the Master key (MK)
          The key derived Session Keys (MSKs) and one or
     more AAA attributes is transported between the EAP Authentication
     Server and NAS. The AAA attributes provide the NAS with information
     on MSK usage.  For example, AAA attributes might include the Client
     layer 2 address, the NAS layer 2 and layer 3 addresses, MSK
     lifetime, etc.  The format and wrapping of the AN-Token, which is
     intended to be accessible only to the Authentication Server during and
     NAS, is defined by the AAA key distribution specification.




Aboba & Simon                Informational                      [Page 4]





INTERNET-DRAFT            EAP authentication process.

Network Access Keying Framework          21 December 2002


Authentication Server (NAS)
          The device
     An Authentication Server is an entity that provides access an
     Authentication Service to a Network Access Server (NAS). This
     service verifies from the network. credentials provided by the Client, the
     claim of identity made by the Client. Where no an Authentication
     Server is present, the NAS provided, it acts as the EAP Server, terminating the EAP
     conversation with the EAP Client.
          Where an  In the EAP Keying architecture
     the Authentication Server is present, the NAS may act acts as a passthrough for one or more authentication methods and for
          non-local users.

Pairwise Master Key (PMK)
          Pairwise Master Keys (PMKs) are derived from KDC, distributing the Master Key
          (MK) and are subsequently used in generation of Transient
     Session Keys (TSKs) for use in the selected ciphersuite.  So
          that (MSKs) to the PMKs are usable with any ciphersuite, they are longer
          than is necessary, EAP Client and are truncated to fit.

Transient Session Keys (TSKs) NAS.

Cryptographic binding
     The demonstration of the EAP Client and NAS derive to the TSKs from EAP Server that a single
     entity has acted as the PMKs. These



Aboba & Simon                Informational                      [Page 4]





INTERNET-DRAFT EAP Key Mgmt.              6 December 2002


          are of appropriate size Client for use with all methods executed within
     a sequence or tunnel. Binding MAY also imply that the chosen ciphersuite.

2. EAP architecture overview Server
     demonstrates to the Client that a single entity has acted as the
     EAP authentication involves Server for all methods executed within a Client, NAS sequence or tunnel. If
     executed correctly, binding serves to mitigate man-in-the-middle
     vulnerabilities.

Cryptographic separation
     Two keys (x and (optionally) y) are "cryptographically separate" if an
Authentication Server.  One of adversary
     that knows all messages exchanged in the goals of EAP is to enable development
of new authentication methods protocol cannot compute x
     from y or y from x without requiring deployment of new code
on the NAS. While the NAS may implement "breaking" some methods locally and use
those methods to authenticate local users, it may at cryptographic
     assumption.  In particular, this definition allows that the same time act
     adversary has the knowledge of all nonces sent in cleartext as well
     as all predictable counter values used in the protocol. Breaking a "passthrough" for other users and methods. Supporting "passthrough"
     cryptographic assumption would typically require inverting a one-
     way function or predicting the outcome of a cryptographic pseudo-
     random number generator without knowledge of authentication to the Authentication Server enables secret state. In
     other words, if the NAS keys are cryptographically separate, there is
     no shortcut to
support additional non-locally implemented methods. Among other things, compute x from y or y from x, but the work an
     adversary must do to perform this implies that a NAS need not implement code computation is equivalent to
     performing exhaustive search for each the secret state value.

EAP method
required by authenticating Clients.

Figure 1 illustrates Master key (EMK)
     The key derived between the EAP authentication process in Client and Server during the case where EAP
     authentication process. The EMK is unique to the EAP Client and
     Server, and is authenticated locally by the NAS using a locally installed
authentication method. In this case, the not shared with any other parties.

Master Session Key (MK) and Pairwise
Master Keys (PMKs) are derived on (MSK)
     Keying material provided to the EAP Client and NAS by the NAS, which acts AAA
     Server, acting as a Key Distribution Center (KDC).  The MSK is used
     in derivation of Transient Session Keys for the EAP server during ciphersuite
     negotiated between the EAP authentication exchange. The Client and
NAS then use the PMK to derive the transient session keys used with NAS.  So that the
selected ciphersuite. It MSK is assumed that ciphersuite negotiation
     usable with any ciphersuite, it is
handled out of band, rather longer than within EAP.

If necessary, and is
     truncated to fit.





Aboba & Simon                Informational                      [Page 5]





INTERNET-DRAFT            EAP Keying Framework          21 December 2002


Note that an Authentication Server may simultaneously provide the authentication occurs EAP
Client with a method not implemented on the NAS,
or involves a non-local user whose credentials MSKs suitable for use with multiple APs, so as to enable
fast handoff. Similarly the AAA Server is unable may send MSKs to
validate, then multiple APs
simultaneously. Note that where the NAS functions as a "passthrough".  For passthrough
authentication methods, instead AP supports transport of requiring code on the NAS, multiple
MSK sets to the NAS
delegates EAP Client and NASes, the authentication to an Authentication Server. MSKs MUST be kept
cryptographically separate from each other.

Network Access Server (NAS)
     The device that provides access to the network. Where no
     Authentication Server installs is present, the NAS acts as the desired EAP methods, typically by
interfacing with Server,
     terminating the operating system via an EAP API, such as that
described in [EAPAPI].

In order to allow conversation with the Client and Client. Where an
     Authentication Server to install new
EAP is present, the NAS may act as a pass-through
     for one or more authentication methods without requiring an operating system upgrade, operating
systems isolate EAP method-specific code within the installed EAP
methods, and thus largely operate for non-local users.

Pairwise Master Key (PMK)
     As defined in [RFC2716], the MSK is 192 octets (1536 bits) in
     length.  Octets 0-31 of the MSK are known as "passthrough" entities with respect the "Peer to EAP.

Figure 2 describes
     Authenticator Encryption Key" or Enc-RECV-Key (reception is defined
     from the relationship between point of view of the EAP Client, NAS and
Authentication Server, for authentications which occur in "passthrough"
mode. As described in Authenticator or NAS).  Within
     IEEE 802.11, the figure, Enc-RECV-Key is also known as the EAP conversation may "pass
through" Pairwise Master
     Key (PMK). IEEE 802.11 ciphersuites such as TKIP, WRAP and CCMP
     derive their Transient Session Keys (TSKs) solely from the NAS on PMK,
     whereas the WEP ciphersuite, when used with IEEE 802.1X-2002,
     derives its way between TSKs from both the Client Enc-RECV-Key and the Authentication
Server (which acts as Enc-SEND-Key.
     Octets 32-63 of the EAP Server in this case).  As a result, MSK are known as the
NAS does not have knowledge of "Authenticator to Peer
     Encryption Key" or End-SEND-Key. Octets 64-95 are known as the keys that
     "Peer to Authenticator Authentication Key" or Auth-RECV-Key.
     Octets 96-127 are derived between known as the "Authenticator to Peer
     Authentication Server Key" or Auth-SEND-Key. Octets 128-159 are known as
     the "Peer to Authenticator IV" or RECV-IV, and Octets 160-191 are
     known as the Client, "Authenticator to Peer IV", or SEND-IV.

     Within [IEEE80211i], the Enc-RECV-Key is also known as the Pairwise
     Master Key (PMK). IEEE 802.11 ciphersuites such as TKIP, WRAP and
     CCMP derive their Transient Session Keys (TSKs) solely from the
     PMK, whereas the WEP ciphersuite, when used with IEEE 802.1X-2002,
     derives its TSKs from both the Enc-RECV-Key and the Enc-SEND-Key.
     IEEE 802.11 ciphersuites do not utilize the Auth-RECV-Key, Auth-
     SEND-Key, RECV-IV or SEND-IV, largely because attributes supporting
     transport of these portions of the MSK were not defined in
     [RFC2548].

Transient EAP Keys (TEKs)
     Session keys need which are used to be
transmitted from establish a protected channel
     between the Authentication EAP Client and Server to during the NAS.




Aboba & Simon                Informational                      [Page 5]





INTERNET-DRAFT EAP Key Mgmt.              6 December 2002


+-+-+-+-+-+               +-+-+-+-+-+
|         |               |         |
|         |               |         |
| Cipher- |               | Cipher- |
| Suite   |               | Suite   |
|         |               |         |
+-+-+-+-+-+               +-+-+-+-+-+
    ^                         ^
    |                         |
    |                         |
    |                         |
    V                         V
+-+-+-+-+-+               +-+-+-+-+-+
|         |  EAP          |         |
|         |  Conversation |         |
|         |<=============>|   NAS   |
| Client  |               | (EAP    |
|         |               | Server) |
|         |               |         |
|         |               |         |
+-+-+-+-+-+               +-+-+-+-+-+
    ^                         ^
    |                         |
    | EAP API                 | EAP API
    |                         |
    V                         V
+-+-+-+-+-+               +-+-+-+-+-+
|         |               |         |
|         |               |         |
|  EAP    |               |  EAP    |
|  Method |               |  Method |
|         |               |         |
+-+-+-+-+-+               +-+-+-+-+-+

Figure 1 - Relationship authentication
     exchange.  The TEKs are derived from the EMK, and are appropriate
     for use with the ciphersuite negotiated between EAP Client and
           NAS (acting
     Server as an part the EAP Server) where no
           Authentication Server is present authentication exchange. Note that the



Aboba & Simon                Informational                      [Page 6]





INTERNET-DRAFT            EAP Key Mgmt.              6 Keying Framework          21 December 2002


+-+-+-+-+-+               +-+-+-+-+-+
|         |               |         |
|         |               |         |
| Cipher- |               | Cipher- |
| Suite   |               | Suite   |
|         |               |         |
+-+-+-+-+-+               +-+-+-+-+-+
    ^                         ^
    |                         |
    |                         |
    |                         |
    V                         V
+-+-+-+-+-+               +-+-+-+-+-+        +-+-+-+-+-+
|         |


     ciphersuite used to set up the protected channel between the EAP          |         |        |         |
|         |  Conversation |         |        |         |
|         |<================================>| Authent.|
|
     Client  |               |   NAS   |        | and Server |
|         |               |         |<=======|         |
|         |               |         | PMK(s) | (EAP    |
|         |               |         |        | Server) |
+-+-+-+-+-+               +-+-+-+-+-+        +-+-+-+-+-+
    ^                                            ^
    |                                            |
    | during EAP API                                    | EAP API
    |                                            |
    V                                            V
+-+-+-+-+-+                                  +-+-+-+-+-+
|         |                                  |         |
|         |                                  |         |
|  EAP    |                                  |  EAP    |
|  Method |                                  |  Method |
|         |                                  |         |
+-+-+-+-+-+                                  +-+-+-+-+-+

Figure 2 - "Passthrough" relationship authentication is unrelated to the
     ciphersuite used to subsequently protect data sent between the EAP Client,
           NAS
     Client and Authentication Server. NAS.  In particular, the TEKs used to protect the EAP methods
     exchange MUST be cryptographically separate from TSKs used to
     protect data.

Transient Session Keys (TSKs)
     Session keys used to protect data which are installed on appropriate for the
     ciphersuite negotiated between the EAP Client and NAS. The TSKs are
     derived from the Authentication
Server, typically communicating MSK by a process defined by the link layer.  In
     the case of IEEE 802.11, TSK derivation is supported via an EAP API, so a 4-way
     handshake that supports mutual authentication between the main EAP
     Client and NAS. The 4-handshake also confirms mutual possession 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 code does not need to be modified to add new
methods. Among Server. One of the results that are passed back by goals of EAP is to enable development
of new authentication methods via without requiring deployment of new code
on the
APIs are NAS. While the PMK(s) NAS may implement some methods locally and use
those methods to authenticate local users, it may at the same time act
as a pass-through for other users and methods. Supporting pass-through
of authentication to be communicated from the Authentication Server to enables the NAS.  Ciphersuites are installed NAS to
support any authentication method implemented on the NAS Authentication
Server and the Client.








Aboba & Simon                Informational                      [Page 7]





INTERNET-DRAFT EAP Key Mgmt.              6 December 2002


2.1.  Implications of the architecture

While EAP methods which derive keys can be used to provide automated
keying for a ciphersuite, this does Client, not imply just locally implemented methods. This
implies that the EAP method need
contain ciphersuite-specific code.  Since the Client and NAS need to not implement a given ciphersuite, ciphersuite-specific code is expected for each EAP method
required by authenticating Clients.

EAP presumes that prior to
exist on authentication, the EAP Client and NAS.  However, since the Authentication Server
is not involved in has located
the protection of data traffic, and may not even be
aware of NAS, using an out-of-band mechanism. For example, for use with PPP,
the negotiated ciphersuite, it cannot Client might be assumed to implement
ciphersuite-specific code, and the backend Authentication Server will
not necessarily have knowledge of configured with a phone book providing phone numbers
for accessing the ciphersuites available on selected service. For use with IEEE 802.11 wireless
LANs, the Client (a Station (STA) in IEEE 802.11 terminology) may locate
NAS devices (an Access Point (AP) in IEEE 802.l1 terminology) using the
IEEE 802.11 Beacon and Client.

Since Probe Request/Response frames.

EAP also assumes that link layer ciphersuite negotiation is handled
within the Authentication Server may not have knowledge of link layer.  For example, the
ciphersuite that has been negotiated, it may not EAP Client might be possible for this
information
preconfigured with policy indicating the ciphersuite to be passed to the EAP method via the EAP APIs.  As used in
communicating with a
result, inclusion of ciphersuite-specific code within an EAP method given NAS, or alternatively, the link layer
protocol may
not be possible.

Similarly, because support ciphersuite negotiation.  Within PPP, the NAS
ciphersuite is assumed to not have knowledge of
individual EAP methods, it cannot be assumed to include code specific to
an negotiated within the Encryption Control Protocol (ECP),
after EAP method.  Moreover, since operating systems provide EAP APIs in
order to remain "EAP-Method Agnostic", EAP method-specific code authentication is best
kept out of the EAP APIs as well.

Drawbacks to allowing EAP methods to specify session key derivation
mechanisms for individual ciphersuites include:

Document Revision
               If an EAP method specifies how to derive transient
               session keys on a per-ciphersuite basis, then this
               document will need to be revised each time a new
               ciphersuite comes out.  This would also imply that an
               Authentication Server supporting an EAP method might not
               be usable with a NAS supporting EAP, due to lack of
               support for a ciphersuite implemented on the NAS.  Since completed. Within IEEE 802.11i, the EAP architecture enables AP
capabilities (including ciphersuite) are advertised in the NAS "passthrough" EAP
               methods that it does not implement, Beacon and
Probe Responses, and are verified during a  NAS implementing 4-way exchange after EAP can be used to implement any
authentication method
               supported by the Authentication Server and Client, not
               just locally implemented methods.

EAP method complexity
               Forcing the EAP method to include ciphersuite-specific
               code for transient session key derivation increases the
               complexity of EAP method development, as well as Client
               and Authentication Server implementations. has completed. The desired ciphersuite is indicated



Aboba & Simon                Informational                      [Page 8] 7]





INTERNET-DRAFT            EAP Key Mgmt.              6 Keying Framework          21 December 2002


Knowledge asymmetry
               In practice, an EAP method may not have knowledge of


within the
               ciphersuite that has been negotiated. In PPP, negotiation
               of Association/Reassociation Request/Response exchange.

Figure 1 illustrates the ciphersuite is accomplished via relationship between the Encryption
               Control Protocol (ECP), described in [RFC1968].  Since
               ECP negotiation occurs after authentication, unless an EAP method is utilized that supports ciphersuite
               negotiation (such as EAP-TLS [RFC2716]), the Client, NAS and backend
Authentication Server may not be able to
               anticipate (EAP Server) for the ciphersuite that will be used case where the NAS and
Authentication Server are located on separate hosts, and
               therefore this information cannot be provided to the NAS acts as
a pass-through.

+-+-+-+-+-+               +-+-+-+-+-+
|         |               |         |
|         |               |         |
| Cipher- |               | Cipher- |
| Suite   |               | Suite   |
|         |               |         |
+-+-+-+-+-+               +-+-+-+-+-+
    ^                         ^
    |                         |
    |                         |
    |                         |
    V                         V
+-+-+-+-+-+               +-+-+-+-+-+        +-+-+-+-+-+
|         |===============|         |========|         |
|         |      EAP
               method.

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

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

In the most general case, ciphersuite-specific keys must be derived from
the master secret (K) derived by the illustration, EAP method.  This is accomplished spoken between the Client and NAS,
encapsulated within a link layer protocol, such as PPP, defined in two steps.

[1]  Derivation of
[RFC1661] and IEEE 802, defined in [IEEE802].  The NAS then encapsulates



Aboba & Simon                Informational                      [Page 8]





INTERNET-DRAFT            EAP Keying Framework          21 December 2002


EAP within a AAA protocol such as RADIUS [RFC2869bis] or Diameter
[DiamEAP], and transports this back and forth to the PMK from AAA Server, which
acts as an EAP Server.  Since the Master Key.  Using NAS acts as a one-way
     function, pass-through, EAP
methods reside only on the EAP method derives the Pairwise Master Keys (PMKs)
     from the master key. Since any entity possessing the master key can
     impersonate the client Client and authentication server, the master key
     MUST be kept local Server, interfacing to the client
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 and
           NAS (acting as an EAP Server) where no
           Authentication Server is present






Aboba & Simon                Informational                      [Page 9]





INTERNET-DRAFT            EAP Keying Framework          21 December 2002


Once EAP authentication server and MUST
     NOT be provided to the NAS. However, is complete, the client EAP Client and NAS need to
     share a key in pass data
between each other, encapsulated within the link layer protocol. In
order to subsequently derive ciphersuite-specific
     keys to protect subsequent data communications. Deriving the PMK
     from data, the master key via Client and NAS may negotiate and
subsequently implement a one-way function enables the ciphersuite.

While pass-through operation is common with EAP, it is optional, so that
EAP may also be implemented in situations where no Authentication Server to provide
is present. This is illustrated in Figure 2.

In Figure 2, EAP is spoken between the PMK(s) to Client and NAS, encapsulated
within a link layer protocol, such as PPP or IEEE 802. Since the NAS without
     compromising the master key.  Note that
terminates the PMK(s) EAP conversation rather than acting as a pass-through,
EAP methods are never
     directly used by implemented on the ciphersuitesw; they are only used in NAS, as well as on the
     derivation of transient session keys. The EAP Client,
interfacing to the  operating system via an EAP API.

Once EAP authentication is complete, the EAP Client and Authentication
     Server compute the PMK(s) NAS pass data,
encapsulated within the EAP method; link layer protocol. In order to protect the Authentication
     Server then transmits
data, the PMK(s) to Client and NAS may negotiate and subsequently implement a
ciphersuite.

2.1.  Ciphersuite independence

Within the NAS.

     Examples of Pairwise Master Key (PMK) derivation algorithms are
     provided in Section 3.5 of EAP TLS [RFC2716]. In authentication model, it is assumed that document, the
     PMK(s) are referred to as "Master Session Keys", ciphersuite
is negotiated between the EAP Client and are derived
     based on NAS using link layer
mechanisms.  While EAP methods which derive keys can be used to provide
automated keying, the Pseudo-Random Function (PRF) defined in TLS [RFC2246].
     Equivalent algorithms are provided in IKE [RFC2409] for EAP method SHOULD NOT generate ciphersuite-
specific keys or even contain ciphersuite-specific code.  Since it is
the
     derivation of SKEYID_d, SKEYID_a Client and SKEYID_e from NAS that negotiate and implement the master key
     SKEYID.  RADIUS attributes for PMK transport are provided in
     [RFC2548].

[2]  Derivation ciphersuite,
knowledge of the "transient session keys" from ciphersusite is restricted to those entities.

Within the PMK(s).  The
     "transient session keys" are used by EAP 3-party model, the Authentication Server is not a party
to the ciphersuite negotiated negotiation that occurs between the EAP client Client and NAS.  Depending on the negotiated
     ciphersuite
NAS, and media, neither is the Authentication Server involved in the passing of
data between the algorithms for "transient session key"



Aboba & Simon                Informational                      [Page 9]





INTERNET-DRAFT EAP Key Mgmt.              6 December 2002


     derivation may differ. For example, 802.11 WEP does not provide a
     keyed message integrity check, Client and typically uses only a single
     encryption key in both directions.  On NAS. Since the hand, PPP MPPE [RFC3079]
     requires encryption keys Authentication Server is
not involved in both directions.

Note that the master key handling of data traffic, and may not even be directly available within all EAP
methods.  For security reasons, aware
of the TLS master secret is typically not
directly available via TLS APIs. As a result, [RFC2716] derives PMKs
from ciphersuite negotiated between the TLS master secret.

Since EAP TLS [RFC2716] does not assume Client and NAS, it cannot
be assumed to implement ciphersuite-specific code. In fact, the
Authentication Server cannot even be assumed to have knowledge of the negotiated
ciphersuite, it provides PMKs large enough for use with any ciphersuite,
assuming that these will be truncated for use within
ciphersuites available on the Client NAS and NAS. EAP Client.

Since the raw master secret is typically Authentication Server may not available in to EAP-TLS
implementations, when this EAP method is used, know the TLS PRF function is
needed to derive keying material from it.

Other EAP methods may also encounter similar issues. For example, ciphersuite negotiated
between EAP
GSS implementations Client and NAS, it will typically not necessarily be able to access the master keys
directly, but can call GSS_Wrap() to encrypted tokens and GSS_GetMIC() make this
information available to generate authentication tokens based on the master secret. a resident EAP GSS
implementations will therefore need to use GSS-API calls to derive
PMK(s) from the master key, rather than operating on method via the master EAP APIs. As a
result, ciphersuite-specific key
directly.

Where generation implemented within an EAP
method might not function correctly on every implementation.

Similarly, because the master key K NAS is not exportable, an intermediate step is required to generate a "Pseudo-Master Key" from implement any EAP methods,
the master key. For
example, in [EAPGSS], a "Pseudo-Master Key", K' is derived via GSS-API
calls, and is used instead.

The steps by which the Transient Session Keys (TSKs) are derived from NAS cannot be assumed to implement code specific to any EAP method.



Aboba & Simon                Informational                     [Page 10]





INTERNET-DRAFT            EAP Keying Framework          21 December 2002


Since operating systems provide EAP APIs in order to remain "EAP-Method
Agnostic", EAP APIs cannot be assumed to implement EAP method-specific
code either.

EAP methods deriving keys MUST support mutual authentication and provide
for the derivation of an EAP Master Key (MK) are illustrated in Figure 3 on (EMK), known only to the next page.

3. EAP Keying requirements

This section describes the keying requirements of
Client and Server. EAP methods that deriving keys also MUST
be met by method specifications requesting publication as provide for the
distribution of the CS-Token between the AAA Server and EAP Client, and
the AN-Token between the AAA server and NAS.  The MSK contained within
the CS-Token and AN-Tokens is suitable for use with any negotiated
ciphersuite, and therefore an RFC.

3.1. EAP method requirements


Key derivation
     Methods listing IEEE 802.11 WLANs MUST NOT directly use the MSK
as a Transient Session Key (TSK).  Rather, the intended medium MUST
     support key derivation.

Algorithm specification
     Methods supporting TSK(s) are derived from
the MSK in a separate step, once the negotiated ciphersuite is known.

Drawbacks to utilizing the MSK as a transient session key include:

Ciphersuite negotiation
               Enabling derivation MUST include of the TSK(s) in a specification separate step
               provides for additional security. For example, the TSK
               derivation of the PMK from supported within IEEE 802.11i enables the Master Key.



Aboba & Simon                Informational                     [Page 10]





INTERNET-DRAFT EAP Key Mgmt.              6 December 2002


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+     ---+---
      |                             |   |                           |        ^
      |    Is a raw master key      |   |  Can
               Client and NAS to mutually authenticate and conduct a pseudo-master key  |        |
      |     available or can        |   |       be derived from     |        |
      |
               protected ciphersuite negotiation.  If the PRF operate on it?     |   | MSK is used
               directly as a TSK, then the master key?     |        |
      |                             |   |                           |        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+        |
                    |                                 |                      |
                    | K                               | K'                   |
                    |                                 |                      |
                    V                                 V                      |
                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                    |
                  |                                     |                    |
                  |          Pairwise Master Key        |             EAP    |
                  |              Derivation             |             Method |
                  |                                     |                    |
                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ EAP    V
                    |                                 |               API ---+---
                    |       Pairwise Master Key(s)    |                      |
                    |                                 |                      |
                    |                                 |               AAA    |
                    |                                 |               Keys   V
                    V                                 V                   ---+---
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      ^
      |                                                               |      |
      |                Ciphersuite-Specific Key Hierarchy             | Client and NAS |
      | may not
               mutually authenticate each other, and Derivation                          |      |
      |                                                               |      V
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   ---+---

       Figure 3 - Architecture for derivation a protected
               ciphersuite negotiation, if it occurs at all, would
               typically need to be supported within EAP itself. Since
               the ciphersuite negotiation mechanisms are typically
               particular to a given link layer, carrying this out
               within EAP may not be appropriate.

Document Revision
               If an EAP method specifies how to derive transient
               session keys on a per-ciphersuite basis, the
               specification will need to be revised each time a new
               ciphersuite is developed.  This would also imply that an
               Authentication Server supporting an EAP method might not
               be usable with all NASes supporting EAP, due to lack of
               support for a new ciphersuite implemented on a NAS.

EAP method complexity
               Requiring the EAP method to include ciphersuite-specific
               code for transient session key from derivation increases the
               complexity of the EAP method, as well as Client and
               Authentication Server implementations.

Knowledge asymmetry
               In practice, an EAP method may not have knowledge of the
               ciphersuite that has been negotiated between the EAP master key K.



Aboba & Simon                Informational                     [Page 11]





INTERNET-DRAFT            EAP Key Mgmt.              6 Keying Framework          21 December 2002


Ciphersuite independence
     The algorithm for deriving the PMK(s) from the "master key"
     provided by


               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 MUST is utilized that
               supports ciphersuite negotiation, the Client, NAS and
               Authentication Server may not be ciphersuite-independent. The
     algorithm MUST NOT require ciphersuite-specific code able to anticipate the
               negotiated ciphersuite and therefore this information
               cannot be
     implemented within an provided to the EAP method.

One-way function
     Given the PMK, it MUST NOT be possible Since ciphersuite
               negotiation is assumed to derive occur out-of-band of EAP, there
               is no need for ciphersuite negotiation within EAP.

3.  EAP Exchanges

EAP supports two modes of exchange:

[a]  Two-party exchange. The two-party exchange occurs where the Master Key.

Key size
     An EAP method supporting key derivation SHOULD generate a PMK
     Client and NAS act as the endpoints of at
     least 512 bits in length.

Standard Keying AVPs
     In order to enable the EAP conversation, and no
     Authentication Servers to provide keying
     material to Server is present. Here the NAS in 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 defined format, AAA servers SHOULD
     use ciphersuite-independent AAA attributes to transmit as providing for the PMK(s)
     from 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 to the NAS.  Since it (acting as an EAP Server)
     is assumed
     that present. In this mode, the EAP Server and Client derive the EMK,
     and the Authentication Server will perform distributes to the required
     calculations CS-Token to compute the PMK(s),
     EAP Client and the PMK derivation algorithm
     need not be implemented on AN-Token to the NAS.

Key Entropy
     The strength of  Both the session keys is dependent upon CS-Token and AN-
     Token contain the security of 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 method providing Master Key (EMK) is derived
on the keying material. If Client and the NAS, which acts as the chosen EAP
     method has security vulnerabilities, or does not produce a key of
     sufficient entropy then it Server during the EAP
authentication exchange, and the Client-Server token is possible that weak session keys may
     be produced.  An transported by
the NAS to the EAP method supporting key derivation SHOULD
     generate PMK(s) Client.  The Client and NAS then use the MSK
contained with at least 128 bits of entropy.

Nonce exchange
     In order the CS-Token to assure non-repetition of derive the PMK, transient session keys used
with the PMK derivation
     SHOULD include a two-way nonce exchange, using nonces of at least
     128-bits.

Known-good algorithms
     The derivation and validation selected ciphersuite. It is assumed that ciphersuite
negotiation is handled out of key band, rather than within EAP. For example,
Within an IEEE 802.11 Reliable Secure Network (RSN), the TSK derivation algorithms is
     difficult, and as
occurs using the RSN 4-way handshake.

If the authentication occurs with a result it is highly desirable to reuse existing
     algorithms. This enables method not implemented on the security community to carefully
     analyze NAS,
or involves a non-local user whose credentials the proposed algorithm; such an analysis would be difficult
     were multiple algorithms Server is unable to proliferate. As a result, EAP methods
     SHOULD utilize well established and analyzed mechanisms for
     deriving
validate, then the PMK from NAS functions as a "pass-through".  For pass-through
authentication methods, instead of implementing the Master Key. authentication



Aboba & Simon                Informational                     [Page 12]





INTERNET-DRAFT            EAP Key Mgmt.              6 Keying Framework          21 December 2002


3.2.  Ciphersuite requirements

The derivation of transient session keys from PMK(s) occurs after


method locally, the
ciphersuite has been determined.  Ciphersuites looking to be keyed by
EAP methods need to provide NAS delegates the following facilities:

TSK specification
     In order authentication to use an
Authentication Server. The Authentication Server installs the PMK(s) provided by desired
EAP methods, ciphersuites
     keyed method, typically by interfacing with the operating system via an
EAP need API, such as that described in [EAPAPI].

In order to define how transient session keys are derived
     from allow the PMK(s) provided by Client and Authentication Server to install new
EAP methods. methods without requiring an operating system upgrade, operating
systems isolate EAP method independence
          Algorithms for deriving transient session keys from PMK(s)
          MUST NOT depend on method-specific code within the installed EAP method.  Derivation of transient
          session keys occurs on the client as well as on the NAS, which
          acts
methods, and thus largely operate as a "passthrough" for pass-through entities with respect
to EAP. Therefore the

+-+-+-+-+-+               +-+-+-+-+-+
|         |               |         |
|         |               |         |
| Cipher- |               | Cipher- |
| Suite   |               | Suite   |
|         |               |         |
+-+-+-+-+-+               +-+-+-+-+-+
    ^                         ^
    |                         |
    |                         |
    V                         V
+-+-+-+-+-+               +-+-+-+-+-+
|         |      EMK      |         |
|         |<=============>|   NAS cannot be
          expected to have knowledge of the   |
| Client  |               | (EAP    |
|         |   CS-Token    | Server) |
|         |<==============|         |
|         |               |         |
|         |   TSK Deriv.  |         |
|         |<=============>|         |
+-+-+-+-+-+               +-+-+-+-+-+
    ^                         ^
    |                         |
    | EAP method that has been
          negotiated.

Cryptographic separation
          The transient session keys derived from the PMK(s) MUST be
          cryptographically independent. That is, given one of the
          transient session keys it MUST NOT be possible to derive other
          transient session key(s).

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 and DES-EDE3-CBC, used in RFC 2420) are
described in [DESMODES].  For PPP DESEbis, 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 single 56-bit encryption
key is required, used in both directions; for PPP 3DES, three-party exchange where the NAS acts as a 168-bit
encryption key is needed, used in both directions.
pass-through. As described in
[RFC2419] and [RFC2420] for both protocols, the IV, which is different
in each direction, is "deduced from an explicit 64-bit nonce, which is
exchanged in figure, the clear during EAP conversation "passes
through" the negotiation phase."

For MPPE, 40-bit, 56-bit or 128-bit encryption keys can be required in
each direction, as described in [RFC3078]. Since MPPE is based NAS on its way between the
RC4 algorithm, no initialization vector is required. While these PPP
ciphersuites provide encryption, they do not provide a per-packet keyed
message integrity check (MIC). Thus, an authentication key is not
required in either direction.

Within 802.11, ciphersuites include WEP-40, described in [IEEE80211],
which requires a 40-bit encryption key, the same in either direction; Client and WEP-128, which requires a 104-bit encryption key, the same in either
direction.  These ciphersuites also do not include a keyed MIC.





Aboba & Simon                Informational                     [Page 13]





INTERNET-DRAFT Authentication
Server (which acts as the EAP Key Mgmt.              6 December 2002 Server).

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

Figure 4 - Three-way exchange







Aboba & Simon                Informational                     [Page 14]





INTERNET-DRAFT            EAP Keying Framework          21 December 2002


The three-way EAP exchange takes part in several phases:

[a]  EAP authentication. During this phase, the EAP Client and Server
     mutually authenticate and derive the EMK, which is known only to
     the EAP Client and Server. Since possession of the EMK would enable
     a third party to impersonate the EAP Client or Server, the EMK MUST
     NOT be shared with any other party.  Where the NAS acts as a pass-
     through, it does not participate in the EAP conversation, except to
     forward packets between the EAP Client and the Authentication
     Server. As a result, the NAS does not possess the EMK and MUST NOT
     be able to derive it, based on observing the EAP conversation, or
     obtaining the MSK.

[b]  Token distribution. During this phase, the AAA Server acts as a Key
     Distribution Center (KDC), distributing the CS-Token to the EAP
     Client and the AN-Token to the NAS.  These tokens, which are
     defined in the EAP Method and AAA key distribution specifications,
     respectively, contain the MSK.

[c]  TSK derivation. During this phase, the EAP Client and NAS confirm
     mutual possession of the MSK, and derive the Transient Session Keys
     used in the negotiated ciphersuite. TSK derivation occurs out of
     band of EAP; an example is the 4-way handshake provided in IEEE
     802.11 RSN.

Figure 5 below illustrates the relationship between the parties in the
three-way exchange.

                   EAP Client
                      /\
                     /  \
 Protocol: EAP      /    \   Protocol: 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 and Authentication
Server (EAP Server) MUST mutually authenticate via the negotiated EAP
method, and derive keys only known between the EAP Client and Server,
known as the EMK.  During EAP authentication, the CS-Token MAY be



Aboba & Simon                Informational                     [Page 15]





INTERNET-DRAFT            EAP Keying Framework          21 December 2002


transported from the EAP Server to the EAP Client, providing the Client
with the MSK. Alternatively, the MSK MAY be derived from the EMK, via a
one-way function. Whether the MSK is derived or transported, possession
of the MSK MUST NOT provide information useful in determining the EMK.

Utilizing the AAA protocol, the Authentication Server 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 to the NAS over
this channel. Where possible, the channel between the Authentication
Server and NAS SHOULD be protected using a session key, as in [DiamEAP]
and RADIUS over IPsec [RFC3162], rather than using a static key, as in
RADIUS [RFC2865].

During the (optional) TSK derivation step, the EAP Client and NAS MUST
mutually authenticate by providing mutual posession of the portion of
the MSK used in the derivation.  The TSK derivation step SHOULD also
provide for a protected ciphersuite negotiation between the EAP Client
and NAS.

The security of the three-party exchange is highly dependent on the
security properties of the algorithms chosen.  For example, if mutual
authentication is not completed between the EAP Client and
Authentication server, then the Client will be vulnerable to rogue
Authentication Servers and NASes. If the EMK is not derived between the
Client and Authentication Server, then there will be no binding between
the authentication and subsequent data traffic, leaving the session
vulnerable 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 and replay protection between the Authentication Server and
NAS, then the EAP conversation could be modified in transit, or packets
can spoofed.

If the TSK derivation does not support mutual authentication, then the
EAP Client will not have assurance that it is connected to the right
NAS, only that the NAS and AAA server share 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, as may be 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]





INTERNET-DRAFT            EAP Keying Framework          21 December 2002


3.3.  EAP Key hierarchy

The EAP key hierarchy depends on two branches:

[a]  EAP Master Key (EMK) branch. The EMK is derived during the EAP
     conversation between the EAP Client and Server, and TEKs derived
     from it are used to establish a protected channel between the EAP
     Client and Server.  Therefore, the EMK branch of the EAP key
     hierarchy describes the derivation of keys used to protect the EAP
     exchange itself.

     Since the EMK is uniquely held by the EAP Client and Server, and
     only mutually authenticating EAP methods may distribute keys, proof
     of possession of the EMK is proof of a completed mutual
     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 such as the
     NAS, or be derivable from other keying material such as the MSK.
     In order to protect against compromise of the EMK, the EMK MUST NOT
     be directly used to protect data; rather the TEKs derived from the
     EMK are used for this purpose. Examples of the EMK branch of the
     key hierarchy are given in Appendix A.

[b]  Master Session Key (MSK) branch. 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 the MSK is not ciphersuite-specific, it is larger
     than necessary, and is truncated to fit as part of the Transient
     Session Key (TSK) derivation process. As with the EMK, the MSK MUST
     NOT be directly used to protect data; rather TSKs derived from the
     MSK are used for this purpose. Examples of the MSK hierarchy are
     given in Appendix B.

4.  Security considerations

This section describes the security requirements for EAP methods, AAA
protocols, TSK derivation mechanisms and Ciphersuites involved in three-
party EAP exchanges. These requirements MUST be met by specifications
requesting publication as an RFC.

4.1.  Three-party exchange

The security of the three-party exchange is highly dependent on the
security properties of the each of the protocols.  For example, if
mutual authentication is not completed between the EAP Client and
Authentication server, then the Client will be vulnerable to rogue
Authentication Servers and NASes. If the EMK is not derived between the



Aboba & Simon                Informational                     [Page 17]





INTERNET-DRAFT            EAP Keying Framework          21 December 2002


Client and Authentication Server, then there will be no binding between
the authentication and subsequent data traffic, leaving the session
vulnerable 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 and replay protection between the Authentication Server and
NAS, then the EAP conversation could be modified in transit, or packets
can spoofed.

If the TSK derivation does not support mutual authentication, then the
EAP Client will not have assurance that it is connected to the right
NAS, only that the NAS and AAA server share 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, as may be the case where fast handoff is
supported. If the TSK derivation does not provide 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.  EAP method requirements

EMK hierarchy
     Methods deriving keys MUST support mutual authentication and
     derivation of the EMK, 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 the format of the
     CS-Token containing the MSK. If no explicit CS-Token format is
     used, then the formulas for derivation of the MSK MUST be provided.

MSK hierarchy
     For a ciphersuite to be 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 the TEKs and TSKs. Also, it must be demonstrated
     that possession of the MSK does not provide information useful in
     determining the EMK.

Ciphersuite Independence
     The MSK derivation SHOULD be ciphersuite-independent and the EAP
     method SHOULD NOT assume knowledge of the ciphersuite.



Aboba & Simon                Informational                     [Page 18]





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 the
     EAP method. If the chosen EAP method has security vulnerabilities,
     or does not produce an EMK and MSK of sufficient entropy then 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 the NAS in a well defined format, AAA protocols
     suitable for use with EAP MUST define the format and wrapping of
     the AN-Token.

AN-Token protection
     To ensure against compromise, the AN-Token MUST be integrity
     protected, authenticated and encrypted in transit, using well-
     established cryptographic algorithms. In order to protect 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 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] rather than static keys,
     as in [RFC2548].

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 MSK requires knowledge of the
     negotiated ciphersuite.

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










Aboba & Simon                Informational                     [Page 20]





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 use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

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

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

6.  Informative References

[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 26, RFC 2434,
               October 1998.




Aboba & Simon                Informational                     [Page 21]





INTERNET-DRAFT            EAP Keying Framework          21 December 2002


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

[RFC2716]      Aboba, B., 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.

[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

[IEEE80211i]   IEEE Draft 802.11i/D3, "Draft Supplement to STANDARD FOR
               Telecommunications and Information Exchange between
               Systems - LAN/MAN Specific Requirements - Part 11:
               Wireless Medium Access Control (MAC) and physical layer
               (PHY) specifications: Specification for Enhanced
               Security", 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.




Aboba & Simon                Informational                     [Page 22]





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


Appendix A - 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 and DES-EDE3-CBC, used in RFC 2420) 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."

For MPPE, 40-bit, 56-bit or 128-bit encryption keys can be required in
each direction, as described in [RFC3078]. Since MPPE is based on the
RC4 algorithm, no initialization vector is required.

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

Within 802.11, transient session keys are required both for unicast
traffic as well as for multicast traffic, and therefore separate TSK
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 authentication key is not required in either direction. However, in
order to protect the transport of the multicast keys from the Access
Point to the Station, additional authentication and encryption keys are
required.

Recently, new ciphersuites have been proposed for use with 802.11 that
do
provide per-packet authentication as well as encryption
[IEEE80211Tgi]. These ciphersuites use either 104-bit or [IEEE80211i].
This includes TKIP, which requires a single 128-bit keys, encryption key and include definition 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).








Aboba & Simon                Informational                     [Page 24]





INTERNET-DRAFT            EAP Keying Framework          21 December 2002


Appendix B - Example EMK Hierarchy

In EAP TLS [RFC2716], ciphersuite negotiation and derivation of their own ciphersuite-specific key hierarchy.

4. the TEKs
is provided using the Transport Layer Security considerations (TLS) key hierarchy
specified in [RFC2246].  The subject of this document TLS-negotiated ciphersuite is security.

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 use used to set
up a protected channel, keyed by derived TEKs. The TEK derivations
proceeds as follows:

Master_secret = TLS-PRF(Pre-Master-Secret, "master secret" ||
                server.random || client.random)
TEK = TLS-PRF-X(Master-Secret, "key expansion", server.random || client.random)

Where:
TLS-PRF-X =     TLS pseudo-random function defined in RFCs [RFC2246],
                computed to Indicate
          Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2246] Dierks, T. and Allen, C. "The X octets.
Master-Secret = TLS Protocol Version 1.0", RFC
          2246, November 1998.

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

Figure B-1 illustrates the EMK key hierarchy, which is derived from the
TLS key hierarchy described in
          progress), draft-ietf-pppext-rfc2284bis-08.txt, [RFC2246].
































Aboba & Simon                Informational                     [Page 25]





INTERNET-DRAFT            EAP Keying Framework          21 December 2002.

[RFC2409] Harkins, D., Carrel, D., "The Internet 2002


       |                       |                           |
       |                       | Pre-Master-Secret         |
 Server|                       |                           | Client
 Random|                       V                           | Random
       |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       |
       |     |                                     |       |
       |     |                                     |       |
       +---->|             Master-Secret           |<------+
       |     |               (EMK)                 |       |
       |     |                                     |       |
       |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       |
       |                       |                           |
       |                       |                           |
       |                       |                           |
       V                       V                           V
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 |                                                               |
 |                         Key Block                             |
 |                          (TEKs)                               |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           |           |           |           |           |
   | Client    | Server    | client    | server    | Client    | 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 - TLS [RFC2246] Key Exchange (IKE)",
          RFC 2409, November 1998.

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

6.  Informative References

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

[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 26, RFC 2434, October
          1998. Hierarchy














Aboba & Simon                Informational                     [Page 14] 26]





INTERNET-DRAFT            EAP Key Mgmt.              6 Keying Framework          21 December 2002


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


Appendix C - Example MSK Hierarchy

In EAP TLS Authentication Protocol",
          RFC 2716, October 1999.

[RFC3078] Pall, G. [RFC2716], the MSK is not transported within a CS-Token
package.  Rather, the MSK is derived from the EMK via a one-way
function. This ensures that the EMK cannot be derived from the MSK
unless the one-way function (TLS PRF) is broken.

Since the MSK is derived from the EMK, if the EMK 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 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.

[EAPGSS]  Aboba, B., "EAP GSS Authentication Protocol", Internet draft
          (work in progress), draft-aboba-pppext-eapgss-12.txt, April
          2002.

[EAPAKA]  Arkko, J., Haverinen, H., "EAP AKA Authentication", Internet
          draft (work in progress), draft-arkko-pppext-eap-aka-05.txt,
          October 2002.

[EAPSRP]  Carlson, J., Aboba, B., Haverinen, H., "PPP EAP SRP-SHA1
          Authentication Protocol", Internet-draft (work ultimately
the MSK.

As described in progress),
          draft-ietf-pppext-eap-srp-03.txt, July 2001.

[FIPSDES] National Bureau [RFC2716], the formula for the derivation of Standards, "Data the MSK
from the EMK is as follows:

MSK(0,127)  = TLS-PRF-128(EMK, "client EAP encryption", client.random || server.random)
MSK(128,191)= TLS-PRF-64("", "client EAP encryption", client.random || server.random)

MSK(0,31)   = Peer to Authenticator Encryption Standard", FIPS
          PUB 46 (January 1977).

[PIC]     Sheffer, Y., Krawczyk, H., Aboba, B., "PIC, A Pre-IKE
          Credential Provisioning Protocol", Internet draft (work Key (Enc-RECV-Key)
               (MS-MPPE-Recv-Key in
          progress), draft-ietf-ipsra-pic-06.txt, October 2002.

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

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

Where:

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

Figure C-1 describes the process by which the MSK, and Technology (NIST),
          "Announcing ultimately the
TSKs, are derived from the EMK. Note that in [RFC2716], the EMK 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)                |
                              |                                        |
                              V                                        |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                    |
            |                                     |            EAP     |
            |       Master Session Key (MSK)      |           Method   |
            |              Derivation             |                    |
            |                                     |                    |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                    |
              |                                 |                      |
              | MSK (0,127)                     | MSK (128, 192)       |
              |                                 |                      |
              V                                 V                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+        |
|                               | |                           |        |
|                               | |                           |        |
|          Key   Derivation     | |       IV Derivation       |        |
|                               | |                           |        |
|                               | |                           |        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+        |
  | 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) | (32B) | (32B)     | (32B)         | (32B)   AAA    |
  |       |       |       |           |               |        Keys    V
  V       V       V       V           V               V             ---+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      ^
|                                                               |      |
|                Ciphersuite-Specific Truncation &              |  NAS |
|                       Key utilization                         |      |
|                                                               |      V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   ---+

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

Within IEEE 802.11 RSN, the Secure Hash Standard," FIPS 180-1, U.S.
          Department Pairwise Transient Key (PTK), a transient
session key used to protect unicast traffic, is derived from the PMK
(octets 0-31 of Commerce, 04/1995

[IEEE80211Tgi]
          IEEE Draft 802.11i/D2, "Draft Supplement the MSK), otherwise known as the Peer to STANDARD FOR
          Telecommunications and Information Exchange between Systems -
          LAN/MAN Specific Requirements - Part 11: Wireless Medium
          Access Control (MAC) and physical layer (PHY) specifications:
          Specification for Enhanced Security", July 2001.

[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, Authenticator
Encryption Key. Within [RFC2548], the PMK is transported via the MS-
MPPE-Recv-Key attribute. In IEEE 802.11 RSN, 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 15] 28]





INTERNET-DRAFT            EAP Key Mgmt.              6 Keying Framework          21 December 2002


          IEEE Std. 802.11-1997, 1997.

[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


Where:

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

TKIP uses X = 512, while CCMP, WRAP, and WEP use X = 384.

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. 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 are available in [IEEE80211i].

Acknowledgments

Thanks to Arun Ayyagari, Ashwin Palekar, and Tim Moore of Microsoft,
Dorothy Stanley of Agerem 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
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.



Aboba & Simon                Informational                     [Page 16]





INTERNET-DRAFT                EAP Key Mgmt.              6 December 2002

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








































Aboba & Simon                Informational                     [Page 17] 31]


----