EAP Working Group                                          Bernard Aboba
INTERNET-DRAFT                                                 Dan Simon
Category: Informational                                        Microsoft
6 December 2002

                     EAP Key Management Guidelines

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

The list of Internet-Draft Shadow Directories can be accessed at

Copyright Notice

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


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

Aboba & Simon                Informational                      [Page 1]

INTERNET-DRAFT                EAP Key Mgmt.              6 December 2002

Table of Contents

1.     Introduction ..........................................    3
   1.1       Requirements language ...........................    4
   1.2       Terminology .....................................    4
2.     EAP architecture overview .............................    5
   2.1       Implications of the architecture ................    8
   2.2       EAP key hierarchy ...............................    9
3.     EAP Keying Requirements ...............................   10
   3.1       EAP method requirements .........................   10
   3.2       Ciphersuite requirements ........................   13
4.     Security considerations ...............................   14
5.     Normative references ..................................   14
6.     Informative references ................................   14
Acknowledgments ..............................................   16
Author's Addresses ...........................................   16
Intellectual Property Statement ..............................   16
Full Copyright Statement .....................................   17

Aboba & Simon                Informational                      [Page 2]

INTERNET-DRAFT                EAP Key Mgmt.              6 December 2002

1.  Introduction

The Extensible Authentication Protocol (EAP), defined in [RFC2284], was
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].

The primary purpose of EAP is to authenticate an EAP Client to a Network
Access Server (NAS), as well as to provide keys for use with a
ciphersuite.  EAP presumes that prior to authentication, the EAP Client
and NAS have located each other via some out-of-band mechanism. For
example, for use with PPP, the Client might contain a phone book that
would provide phone numbers of NASes used with the selected service. In
IEEE 802.11, the Client (also known as a Station) may locate NAS devices
(also known as Access Points) using the IEEE 802.11 Beacon and Probe
Request/Response frames. EAP also assumes that ciphersuite negotiation
and selection is done out-of-band, and therefore need not be handled
within 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

EAP 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 but not key derivation.  However,
subsequent EAP method specifications such as EAP TLS [RFC2716], EAP SRP
[EAPSRP], EAP GSS [EAPGSS] and EAP AKA [EAPAKA] have provided for mutual
authentication, as well as key derivation.

The ciphersuites for which EAP may provide keying material have also
grown in number.  With the increase in the number of EAP methods and
applicable ciphersuites, there is a need for defining how transient
session keys are derived from the master secrets produced by EAP
methods, and how keys are used to provide cryptographic binding between
methods used in a sequence or tunnel.  Allowing each EAP method to
handle this in its own way is likely to produce unacceptable results.

This document reviews the issues involved in EAP key derivation and
provides guidelines for the generation of keys by EAP methods.

Aboba & Simon                Informational                      [Page 3]

INTERNET-DRAFT                EAP Key Mgmt.              6 December 2002

1.1.  Requirements language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
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 is an entity that provides an
          Authentication Service to a Network Access Server (NAS). This
          service verifies from the credentials provided by the Client,
          the claim of identity made by the Client. Where an
          Authentication Server is provided, it acts as the EAP server,
          terminating EAP conversation with the EAP Client.

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

Master key (MK)
          The key derived between the EAP Client and Server during the
          EAP authentication process.

Network Access Server (NAS)
          The device that provides access to the network. Where no
          Authentication Server is present, the NAS acts as the EAP
          Server, terminating the EAP conversation with the Client.
          Where an Authentication Server is present, the NAS may act 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 the Master Key
          (MK) and are subsequently used in generation of Transient
          Session Keys (TSKs) for use in the selected ciphersuite.  So
          that the PMKs are usable with any ciphersuite, they are longer
          than is necessary, and are truncated to fit.

Transient Session Keys (TSKs)
          The EAP Client and NAS derive the TSKs from the PMKs. These

Aboba & Simon                Informational                      [Page 4]

INTERNET-DRAFT                EAP Key Mgmt.              6 December 2002

          are of appropriate size for use with the chosen ciphersuite.

2.  EAP architecture overview

EAP authentication involves a Client, NAS and (optionally) an
Authentication Server.  One of the goals of EAP is to enable development
of new authentication methods without requiring deployment of new code
on the NAS. While the NAS may implement some methods locally and use
those methods to authenticate local users, it may at the same time act
as a "passthrough" for other users and methods. Supporting "passthrough"
of authentication to the Authentication Server enables the NAS to
support additional non-locally implemented methods. Among other things,
this implies that a NAS need not implement code for each EAP method
required by authenticating Clients.

Figure 1 illustrates the EAP authentication process in the case where
the Client is authenticated locally by the NAS using a locally installed
authentication method. In this case, the Master Key (MK) and Pairwise
Master Keys (PMKs) are derived on the Client and the NAS, which acts as
the EAP server during the EAP authentication exchange. The Client and
NAS then use the PMK to derive the transient session keys used with the
selected ciphersuite. It is assumed that ciphersuite negotiation is
handled out of band, rather than within EAP.

If the authentication occurs with a method not implemented on the NAS,
or involves a non-local user whose credentials the Server is unable to
validate, then the NAS functions as a "passthrough".  For passthrough
authentication methods, instead of requiring code on the NAS, the NAS
delegates the authentication to an Authentication Server. The
Authentication Server installs the desired EAP methods, typically by
interfacing with the operating system via an EAP API, such as that
described in [EAPAPI].

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

Figure 2 describes the relationship between the EAP Client, NAS and
Authentication Server, for authentications which occur in "passthrough"
mode. As described in the figure, the EAP conversation may "pass
through" the NAS on its way between the Client and the Authentication
Server (which acts as the EAP Server in this case).  As a result, the
NAS does not have knowledge of the keys that are derived between the
Authentication Server and the Client, and these keys need to be
transmitted from the Authentication Server to 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 between EAP Client and
           NAS (acting as an EAP Server) where no
           Authentication Server is present

Aboba & Simon                Informational                      [Page 6]

INTERNET-DRAFT                EAP Key Mgmt.              6 December 2002

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

Figure 2 - "Passthrough" relationship between EAP Client,
           NAS and Authentication Server.

EAP methods are installed on the the Client and the Authentication
Server, typically communicating via an EAP API, so that the main Client
and Authentication Server code does not need to be modified to add new
methods. Among the results that are passed back by EAP methods via the
APIs are the PMK(s) to be communicated from the Authentication Server to
the NAS.  Ciphersuites are installed on the NAS 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 not imply that the EAP method need
contain ciphersuite-specific code.  Since the Client and NAS need to
implement a given ciphersuite, ciphersuite-specific code is expected to
exist on the Client and NAS.  However, since the Authentication Server
is not involved in the protection of data traffic, and may not even be
aware of the negotiated ciphersuite, it cannot be assumed to implement
ciphersuite-specific code, and the backend Authentication Server will
not necessarily have knowledge of the ciphersuites available on the NAS
and Client.

Since the Authentication Server may not have knowledge of the
ciphersuite that has been negotiated, it may not be possible for this
information to be passed to the EAP method via the EAP APIs.  As a
result, inclusion of ciphersuite-specific code within an EAP method may
not be possible.

Similarly, because the NAS is assumed to not have knowledge of
individual EAP methods, it cannot be assumed to include code specific to
an EAP method.  Moreover, since operating systems provide EAP APIs in
order to remain "EAP-Method Agnostic", EAP method-specific code 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
               the EAP architecture enables the NAS "passthrough" EAP
               methods that it does not implement, a  NAS implementing
               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.

Aboba & Simon                Informational                      [Page 8]

INTERNET-DRAFT                EAP Key Mgmt.              6 December 2002

Knowledge asymmetry
               In practice, an EAP method may not have knowledge of the
               ciphersuite that has been negotiated. In PPP, negotiation
               of the ciphersuite is accomplished via the Encryption
               Control Protocol (ECP), described in [RFC1968].  Since
               ECP negotiation occurs after authentication, unless an
               EAP method is utilized that supports ciphersuite
               negotiation (such as EAP-TLS [RFC2716]), the Client, NAS
               and backend Authentication Server may not be able to
               anticipate the ciphersuite that will be used and
               therefore this information cannot be provided to the EAP

2.2.  EAP Key hierarchy

In the most general case, ciphersuite-specific keys must be derived from
the master secret (K) derived by the EAP method.  This is accomplished
in two steps.

[1]  Derivation of the PMK from the Master Key.  Using a one-way
     function, the EAP method derives the Pairwise Master Keys (PMKs)
     from the master key. Since any entity possessing the master key can
     impersonate the client and authentication server, the master key
     MUST be kept local to the client and authentication server and MUST
     NOT be provided to the NAS. However, the client and NAS need to
     share a key in order to subsequently derive ciphersuite-specific
     keys to protect subsequent data communications. Deriving the PMK
     from the master key via a one-way function enables the
     Authentication Server to provide the PMK(s) to the NAS without
     compromising the master key.  Note that the PMK(s) are never
     directly used by the ciphersuitesw; they are only used in the
     derivation of transient session keys. The Client and Authentication
     Server compute the PMK(s) within the EAP method; the Authentication
     Server then transmits the PMK(s) to the NAS.

     Examples of Pairwise Master Key (PMK) derivation algorithms are
     provided in Section 3.5 of EAP TLS [RFC2716]. In that document, the
     PMK(s) are referred to as "Master Session Keys", and are derived
     based on the Pseudo-Random Function (PRF) defined in TLS [RFC2246].
     Equivalent algorithms are provided in IKE [RFC2409] for the
     derivation of SKEYID_d, SKEYID_a and SKEYID_e from the master key
     SKEYID.  RADIUS attributes for PMK transport are provided in

[2]  Derivation of the "transient session keys" from the PMK(s).  The
     "transient session keys" are used by the ciphersuite negotiated
     between the EAP client and NAS.  Depending on the negotiated
     ciphersuite and media, 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, and typically uses only a single
     encryption key in both directions.  On the hand, PPP MPPE [RFC3079]
     requires encryption keys in both directions.

Note that the master key may not be directly available within all EAP
methods.  For security reasons, the TLS master secret is typically not
directly available via TLS APIs. As a result, [RFC2716] derives PMKs
from the TLS master secret.

Since EAP TLS [RFC2716] does not assume knowledge of the negotiated
ciphersuite, it provides PMKs large enough for use with any ciphersuite,
assuming that these will be truncated for use within the Client and NAS.
Since the raw master secret is typically not available in to EAP-TLS
implementations, when this EAP method is used, the TLS PRF function is
needed to derive keying material from it.

Other EAP methods may also encounter similar issues. For example, EAP
GSS implementations will typically not be able to access the master keys
directly, but can call GSS_Wrap() to encrypted tokens and GSS_GetMIC()
to generate authentication tokens based on the master secret.  EAP GSS
implementations will therefore need to use GSS-API calls to derive
PMK(s) from the master key, rather than operating on the master key

Where the master key K is not exportable, an intermediate step is
required to generate a "Pseudo-Master Key" from 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
the Master Key (MK) are illustrated in Figure 3 on the next page.

3.  EAP Keying requirements

This section describes the keying requirements of EAP methods that MUST
be met by method specifications requesting publication as an RFC.

3.1.  EAP method requirements

Key derivation
     Methods listing IEEE 802.11 WLANs as the intended medium MUST
     support key derivation.

Algorithm specification
     Methods supporting key derivation MUST include a specification for
     the derivation of the PMK from the Master Key.

Aboba & Simon                Informational                     [Page 10]

INTERNET-DRAFT                EAP Key Mgmt.              6 December 2002

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+     ---+---
      |                             |   |                           |        ^
      |    Is a raw master key      |   |  Can a pseudo-master key  |        |
      |     available or can        |   |       be derived from     |        |
      |  the PRF operate on it?     |   |       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             |  NAS |
      |                       and Derivation                          |      |
      |                                                               |      V
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   ---+---

       Figure 3 - Architecture for derivation of ciphersuite-specific
       session key from the EAP master key K.

Aboba & Simon                Informational                     [Page 11]

INTERNET-DRAFT                EAP Key Mgmt.              6 December 2002

Ciphersuite independence
     The algorithm for deriving the PMK(s) from the "master key"
     provided by the EAP method MUST be ciphersuite-independent. The
     algorithm MUST NOT require ciphersuite-specific code to be
     implemented within an EAP method.

One-way function
     Given the PMK, it MUST NOT be possible to derive the Master Key.

Key size
     An EAP method supporting key derivation SHOULD generate a PMK of at
     least 512 bits in length.

Standard Keying AVPs
     In order to enable Authentication Servers to provide keying
     material to the NAS in a well defined format, AAA servers SHOULD
     use ciphersuite-independent AAA attributes to transmit the PMK(s)
     from the Authentication Server to the NAS.  Since it is assumed
     that the Authentication Server will perform the required
     calculations to compute the PMK(s), the PMK derivation algorithm
     need not be implemented on the NAS.

Key Entropy
     The strength of the session keys is dependent upon the security of
     the EAP method providing the keying material. If the chosen EAP
     method has security vulnerabilities, or does not produce a key of
     sufficient entropy then it is possible that weak session keys may
     be produced.  An EAP method supporting key derivation SHOULD
     generate PMK(s) with at least 128 bits of entropy.

Nonce exchange
     In order to assure non-repetition of the PMK, the PMK derivation
     SHOULD include a two-way nonce exchange, using nonces of at least

Known-good algorithms
     The derivation and validation of key derivation algorithms is
     difficult, and as a result it is highly desirable to reuse existing
     algorithms. This enables the security community to carefully
     analyze the proposed algorithm; such an analysis would be difficult
     were multiple algorithms to proliferate. As a result, EAP methods
     SHOULD utilize well established and analyzed mechanisms for
     deriving the PMK from the Master Key.

Aboba & Simon                Informational                     [Page 12]

INTERNET-DRAFT                EAP Key Mgmt.              6 December 2002

3.2.  Ciphersuite requirements

The derivation of transient session keys from PMK(s) occurs after the
ciphersuite has been determined.  Ciphersuites looking to be keyed by
EAP methods need to provide the following facilities:

TSK specification
     In order to use the PMK(s) provided by EAP methods, ciphersuites
     keyed via EAP need to define how transient session keys are derived
     from the PMK(s) provided by EAP methods.

EAP method independence
          Algorithms for deriving transient session keys from PMK(s)
          MUST NOT depend on the EAP method.  Derivation of transient
          session keys occurs on the client as well as on the NAS, which
          acts as a "passthrough" for EAP. Therefore the NAS cannot be
          expected to have knowledge of the EAP method that has been

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, 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] 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 the clear during 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 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, 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.

Aboba & Simon                Informational                     [Page 13]

INTERNET-DRAFT                EAP Key Mgmt.              6 December 2002

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 128-bit keys,
and include definition of their own ciphersuite-specific key hierarchy.

4.  Security considerations

The subject of this document 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 in RFCs to Indicate
          Requirement Levels", BCP 14, RFC 2119, March 1997.

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

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

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

          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

[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

Aboba & Simon                Informational                     [Page 14]

INTERNET-DRAFT                EAP Key Mgmt.              6 December 2002

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

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

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

[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 in progress),
          draft-ietf-pppext-eap-srp-03.txt, July 2001.

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

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

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

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

          IEEE Draft 802.11i/D2, "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", July 2001.

          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,

Aboba & Simon                Informational                     [Page 15]

INTERNET-DRAFT                EAP Key Mgmt.              6 December 2002

          IEEE Std. 802.11-1997, 1997.

[EAPAPI]  Microsoft Developer Network, "Windows 2000 EAP API", August
          2000, http://msdn.microsoft.com/library/


Thanks to Arun Ayyagari, Ashwin Palekar, and Tim Moore of Microsoft,
Dorothy Stanley of Agerem and Russ Housley of RSA Security for useful

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

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

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

Expiration Date

This memo is filed as <draft-aboba-pppext-key-problem-04.txt>,  and
expires July 22, 2003.

Aboba & Simon                Informational                     [Page 17]