view Side-By-Side changes

PPPEXT





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



                         The



                     EAP Keying Problem 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
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 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           The                EAP Keying Problem          22 October Key Mgmt.              6 December 2002


Table of Contents

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

































Aboba & Simon                Informational                      [Page 2]





INTERNET-DRAFT           The                EAP Keying Problem          22 October 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].

Although the initial focus

The primary purpose of EAP was authentication, it can also is to authenticate an EAP Client to a Network
Access Server (NAS), as well as to provide keys for use with a ciphersuite,
ciphersuite.  EAP presumes that prior to authentication, the EAP Client
and binding 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 methods 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
sequence Client might be preconfigured with the
ciphersuite to be used in communicating with a given NAS, or tunnel.
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 in [RFC2284] [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.  PPP ciphersuites include DESEbis [RFC2419], 3DES
[RFC2420],  With the increase in the number of EAP methods and MPPE [RFC3078].  The DES algorithm
applicable ciphersuites, there is described in
[FIPSDES], a need for defining how transient
session keys are derived from the master secrets produced by EAP
methods, and DES modes (such as CBC, how keys are used to provide cryptographic binding between
methods 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 sequence or 128-bit encryption keys can be required in tunnel.  Allowing each direction, as described EAP method to
handle this 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 its own way is not
required in either direction.

Within 802.11, ciphersuites include WEP-40, described in [IEEE80211],
which requires a 40-bit encryption key, likely to produce unacceptable results.

This document reviews the same issues involved in either direction; EAP key derivation and WEP-128, which requires a 104-bit encryption key, the same in either
direction.  These ciphersuites also do not include a keyed MIC.

Recently, new ciphersuites have been proposed
provides guidelines 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.

With the increase in the number generation 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 methods.






Aboba & Simon                Informational                      [Page 3]





INTERNET-DRAFT           The                EAP Keying Problem          22 October Key Mgmt.              6 December 2002


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.


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 is an entity that provides an
          Authentication Service to an NAS. a Network Access Server (NAS). This
          service verifies from the credentials provided by the peer, Client,
          the claim of identity made by the peer. 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 peer Client to the authenticator EAP Server that a
          single entity has acted as the EAP peer Client for all methods
          executed within a sequence or tunnel. Binding MAY also imply
          that the EAP authenticator Server demonstrates to the peer Client that a single
          entity has acted as the EAP authenticator 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 Client and EAP server 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 session key Key (PMK)
          Pairwise Master session keys Keys (PMKs) are derived from the master key, Master Key
          (MK) and are subsequently used in generation of transient session keys Transient
          Session Keys (TSKs) for
          authentication, encryption and IV-generation.  Since the
          transient session keys may be different in each direction,
          master session keys are also required use in each direction, and
          are therefore referred to as "asymmetrical". the selected ciphersuite.  So
          that the
          master session keys PMKs are to be 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           The                EAP Keying Problem          22 October Key Mgmt.              6 December 2002


Transient session keys
          The chosen ciphersuite uses transient session keys for
          authentication and encryption as well as IVs (if required).
          The transient session keys are derived from the master session
          keys, and


          are of the appropriate size for use with the chosen ciphersuite. Depending on the ciphersuite, the transient
          session keys may be different in each direction.

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. As a
result, While the NAS acts may implement some methods locally and use
those methods to authenticate local users, it may at the same time act
as a "passthrough", "passthrough" for other users and need not understand
specific EAP 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 contain implement code specific to 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

Instead 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 new code on the NAS, EAP methods are installed on the client and backend NAS
delegates the authentication server, 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 Client and backend server 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 1 2 describes the relationship between the EAP peer, Client, NAS and AAA
server.
Authentication Server, for authentications which occur in "passthrough"
mode. As described in the figure, the EAP conversation "passes may "pass
through" the NAS on its way between the client Client and the AAA server 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 AAA server and the client, 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 these keys need to be
transmitted from the AAA server to the NAS. Authentication Server.

EAP methods are installed on the the client Client and the AAA server, Authentication
Server, typically communicating via an EAP API, so that the main client Client
and AAA
server 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 keys PMK(s) to be communicated from the AAA server Authentication Server to
the NAS.  Ciphersuites are installed on the NAS and the client. 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 Client and NAS need to
implement a given ciphersuite, ciphersuite-specific code is expected to
exist on the client Client and NAS.  However, since the backend authentication
server 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 Authentication Server will
not necessarily have knowledge of the ciphersuites available on the NAS
and client.



Aboba & Simon                Informational                      [Page 5]





INTERNET-DRAFT           The EAP Keying Problem          22 October 2002


+-+-+-+-+-+               +-+-+-+-+-+
|         |               |         |
|         |               |         |
| Cipher- |               | Cipher- |
| Suite   |               | Suite   |
|         |               |         |
+-+-+-+-+-+               +-+-+-+-+-+
    ^                         ^
    |                         |
    |                         |
    |                         |
    V                         V
+-+-+-+-+-+               +-+-+-+-+-+        +-+-+-+-+-+
|         |  EAP          |         |        |         |
|         |  Conversation |         |        |         |
|         |<================================>|   AAA   |
| Client  |               |   NAS/  |        |  Server |
|         |               |         |<=======|         |
|         |               |         |  Keys  |         |
|         |               |         |        |         |
+-+-+-+-+-+               +-+-+-+-+-+        +-+-+-+-+-+
    ^                                            ^
    |                                            |
    | EAP API                                    | EAP API
    |                                            |
    V                                            V
+-+-+-+-+-+                                  +-+-+-+-+-+
|         |                                  |         |
|         |                                  |         |
|  EAP    |                                  |  EAP    |
|  Method |                                  |  Method |
|         |                                  |         |
+-+-+-+-+-+                                  +-+-+-+-+-+

Figure 1 - Relationship between EAP client, AAA server and NAS.
















Aboba & Simon                Informational                      [Page 6]





INTERNET-DRAFT           The EAP Keying Problem          22 October 2002


2.1.  Implications of the architecture Client.

Since the backend authentication server 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 is
inappropriate. 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 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
               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.  This
               is antithetical to  Since
               the EAP architecture, which conceives
               of architecture enables the NAS as a "pass through" device "passthrough" EAP
               methods that it does not need
               to understand EAP, and which therefore implement, a  NAS implementing
               EAP can work with be used to implement any
               EAP authentication method
               supported by the authentication server. 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 Client
               and authentication server 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, Client, NAS
               and backend authentication server Authentication Server may not be able to
               anticipate the ciphersuite that will be used and
               therefore this information cannot be provided to the EAP
               method.





Aboba & Simon                Informational                      [Page 7]





INTERNET-DRAFT           The EAP Keying Problem          22 October 2002


3.

2.2.  EAP keying requirements Key hierarchy

In the most general case, authentication and encryption ciphersuite-specific keys as well as
initialization vectors must be derived for each direction from
the master secret K (K) derived by the EAP method.  This can is accomplished via
the specification of
in two classes of algorithms: steps.

[1]  Algorithms for the derivation  Derivation of "master session keys" the PMK from the Master Key.  Using a one-way
     function, the EAP method derives the Pairwise Master Keys (PMKs)
     from the
     negotiated master key.  The "master session keys" are derived from Since any entity possessing the master key derived by can
     impersonate the EAP method, but are never directly
     used by ciphersuites; they are only used in client and authentication server, the derivation of
     transient session keys.  These "master session keys" are derived on master key
     MUST be kept local to the client and the backend authentication server. The backend authentication server then transmits the "master session keys" and MUST
     NOT be provided to the NAS.

[2]  Algorithms for the derivation of "transient session keys" from However, the
     "master session keys". The "transient session keys" are used for
     encryption, authentication and IV-generation in each direction, client and
     are derived by the NAS and client, based on the negotiated
     ciphersuite.

Depending on the negotiated ciphersuite and media, a different set of
"transient session keys" may be required; for example 802.11 WEP does
not provide a keyed message integrity check, and typically uses only need to
     share a
single encryption key in both directions.

The algorithm for deriving in order to subsequently derive ciphersuite-specific
     keys to protect subsequent data communications. Deriving the "master session keys" PMK
     from the "master
key" is designed to be ciphersuite-independent, and is specific to master key via a one-way function enables the
EAP method. The goal of this algorithm is
     Authentication Server to provide the PMK(s) to the NAS without
     compromising the master session keys key.  Note that the PMK(s) are never
     directly used by the ciphersuitesw; they are only used in a well defined format, suitable for passage between the AAA server
     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 master session key Pairwise Master Key (PMK) derivation algorithms are
     provided in Section 3.5 of EAP TLS [RFC2716], [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.  Examples of AAA master session key  RADIUS attributes for PMK transport are provided in
     [RFC2548].

Note that because the derivation and validation

[2]  Derivation of these algorithms is
difficult, it is highly desirable to reuse existing algorithms if at all
possible.  This enables the security community to carefully analyze "transient session keys" from the PMK(s).  The
     "transient session keys" are used by the ciphersuite negotiated
     between the
proposed algorithm. Such an analysis would be difficult were multiple
algorithms to proliferate. However, since each EAP method is different,
it is also true that existing client and NAS.  Depending on the negotiated
     ciphersuite and media, the algorithms may not fit all situations. for "transient session key"



Aboba & Simon                Informational                      [Page 8] 9]





INTERNET-DRAFT           The                EAP Keying Problem          22 October 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 master
session keys from the TLS master secret, and uses those master session
keys to derive derives PMKs
from the required session keys. TLS master secret.

Since EAP TLS [RFC2716] does not assume knowledge of the negotiated
ciphersuite, it provides keys PMKs large enough for use with any ciphersuite,
assuming that these will be truncated for use within the client 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
master session keys from the master key, rather than operating on the
master key directly.

By specifying the algorithm by which master session keys are derived
within each EAP method, as well as the format by which the master
session keys are transmitted from the AAA server to the NAS, the NAS can
be assured of obtaining master session keys for each EAP method, in a
well-defined format.  Since it is assumed that the backend
authentication server will perform the required calculations and will
supply the NAS with the master session keys, the master session key
algorithm need not be implemented on the  NAS.

Rather, the NAS will only need code for the second algorithm, namely for
the derivation of ciphersuite-specific "transient session keys" from
"master session keys".

The derivation of ciphersuite-specific "transient session keys" from
"master session keys" occurs after the ciphersuite has been determined,
and provides for the derivation of the keys required within the
ciphersuite-specific key hierarchy.  The algorithm for deriving
"transient session keys" from the "master session keys" is designed to
be EAP-method independent, but is dependent on the negotiated
ciphersuite and media.

Since each ciphersuite and media may have different needs, the
algorithms for transient session key derivation will vary according to
the ciphersuite and media. Nevertheless, as with master session key
derivation algorithms, it is desirable if commonalities can be found, so
that the correctness and security of the algorithms can be more easily
analyzed.



Aboba & Simon                Informational                      [Page 9]





INTERNET-DRAFT           The EAP Keying Problem          22 October 2002


Figure 2
to generate authentication tokens based on the next page describes the overall logic of how master
session keys and transient session keys are derived secret.  EAP GSS
implementations will therefore need to use GSS-API calls to derive
PMK(s) from the master key
negotiated within an EAP method.

The key, rather than operating on the master key K may be of varying length, and as described earlier, may
not be directly available to the EAP method.
directly.

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

In order to enable interoperability between backend authentication
servers, NASen and EAP clients implementing EAP methods that derive
keys,

The steps by which the following is required: Transient Session Keys (TSKs) are derived from
the Master Key hierarchy
     In order to enable (MK) are illustrated in Figure 3 on the keys derived within next page.

3.  EAP Keying requirements

This section describes the keying requirements of EAP methods to that MUST
be used
     within any ciphersuite, met by method specifications requesting publication as an RFC.

3.1.  EAP methods deriving keys need to specify method requirements


Key derivation
     Methods listing IEEE 802.11 WLANs as the algorithms for master session intended medium MUST
     support key derivation. If possible, it
     is desirable to reuse existing key derivation techniques, rather
     than inventing new ones.

Ciphersuite keys
     In order to use the master session keys provided by EAP methods,
     ciphersuites keyed via EAP need to define how ciphersuite-specific
     keys are derived from the master session keys provided by EAP
     methods, based on the ciphersuite-specific

Algorithm specification
     Methods supporting key hierarchy.

Keying AVPs
     In order to enable backend authentication servers to provide keying
     material to the NAS in a well defined format, it is necessary to
     standardize the attributes used to transmit keys from the backend
     authentication server to the NAS.

The algorithms for derivation of "master session keys" from the master
key, and MUST include a specification for
     the derivation of "transient session keys" from the "master
session keys" are not specified in this document. Rather, PMK from the purpose of
this document is to lay out a framework within which algorithms can be
discussed and evaluated. Master Key.



Aboba & Simon                Informational                     [Page 10]





INTERNET-DRAFT           The                EAP Keying Problem          22 October 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                      |
                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                    |
                  |                                     |            EAP                    |
                  |          Pairwise Master Session Key        |           Method             EAP    |
                  |              Derivation             |             Method |
                  |                                     |                    |
                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                    |
               |                                 |                      |
               | Master Session Key Outputs      |                      |
               |                                 |                      |
               V                                 V                      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+        |
 |                                                             |        |
 |                 Key and 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     |       Pairwise Master Key(s)    |                ^                      |
                    |                                 |                      |
                    |                                 |               AAA    |
                    |                                 |         |         |         |         |               Keys    V
     V         V         V         V         V         V             ---+---
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      ^
 |                                                               |      |
 |                Ciphersuite-Specific Key Hierarchy             |  NAS |
 |                                                               |      |
 |                                                               |      V
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   ---+---

  Figure 2 - Architecture for derivation of ciphersuite-specific key
             hierarchy from the EAP method master key K.










Aboba & Simon                Informational                     [Page 11]





INTERNET-DRAFT           The EAP Keying Problem          22 October 2002


For a proposed "master session key" derivation algorithm to be
satisfactory, it needs to fulfill several requirements:

Ciphersuite-independence
          A satisfactory "master session key" derivation algorithm MUST
          NOT require ciphersuite-specific code to be implemented within
          an EAP method. In practice, this implies that the master
          session keys MUST enable derivation of authentication and
          encryption keys and IVs in both directions.

Generality
          A satisfactory "master session key" derivation algorithm MUST
          provide master session keys appropriate for use with a wide
          range of ciphersuites. Among other things, this implies that
          the master session keys MUST contain sufficient entropy to be
          usable with existing and future ciphersuites. At a minimum,
          master session keys SHOULD be at least 256 octets in length.

Direct   V
                    V                                 V                   ---+---
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      ^
      |                                                               |      |
      |                Ciphersuite-Specific Key Hierarchy             |  NAS |
      |                       and Indirect Access
          Satisfactory "master session key" Derivation                          |      |
      |                                                               |      V
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   ---+---

       Figure 3 - Architecture for derivation algorithms MUST
          be applicable to EAP methods where of ciphersuite-specific
       session key from the EAP master key is not
          directly accessible. These include TLS and GSS-API methods.

Generality
          It is likely that each K.



















Aboba & Simon                Informational                     [Page 11]





INTERNET-DRAFT                EAP method will handle Key Mgmt.              6 December 2002


Ciphersuite independence
     The algorithm for deriving the derivation
          of "master session keys" PMK(s) from the "master keys" in a different
          manner. However, wherever possible, well known algorithms
          SHOULD be reused, and customized to fit, rather than
          developing entirely new algorithms.

Algorithms for "transient session key" derivation also needs to fulfill
several requirements:
     provided by the EAP method independence
          Algorithms for deriving "transient session keys" from "master
          session keys" MUST be ciphersuite-independent. The
     algorithm MUST NOT depend on the require ciphersuite-specific code to be
     implemented within an EAP method.  Derivation
          of "transient session keys" is expected to occur on the NAS,
          which acts as a "passthrough" for EAP. Therefore

One-way function
     Given the NAS
          cannot PMK, it MUST NOT be expected possible to have knowledge of derive the Master Key.

Key size
     An EAP method that
          has been negotiated.

Sufficient keying material
          Algorithms for derivation of "transient session keys" from
          "master session keys" will typically be dependent on the supporting key
          hierarchy of the given ciphersuite and media.  However,
          regardless derivation SHOULD generate a PMK of the specific key hierarchy, the derived "master
          session key" MUST provide sufficient entropy at
     least 512 bits in length.

Standard Keying AVPs
     In order to enable
          "transient session keys" 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 be securely derived. For example,



Aboba & Simon                Informational                     [Page 12]





INTERNET-DRAFT           The EAP Keying Problem          22 October 2002


          an EAP method the NAS.  Since it is assumed
     that generates a "master session key" with only
          56 bits of entropy the Authentication Server will perform the required
     calculations to compute the PMK(s), the PMK derivation algorithm
     need not be adequate.

4.  Security considerations


4.1. implemented on the NAS.

Key strength Entropy
     The strength of the session keys is dependent upon the security of
     the EAP method providing the master 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.

4.2.  Man-in-the-middle attacks

Since  An EAP is widely implemented on multiple media, man-in-the-middle
attacks are a fundamental concern. Where methods are used within a
sequence or tunnel, cryptographic binding between 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 methods and (if
present) PMK, the tunnel, is required so that PMK derivation
     SHOULD include a single peer two-way nonce exchange, using nonces of at least
     128-bits.

Known-good algorithms
     The derivation and validation of key derivation algorithms is
     difficult, and authenticator
can be demonstrated to have taken part in the entire exchange.

Without cryptographic binding, a man-in-the-middle attack may be enabled
as described in Figure 3.

+-+-+-+-+-+               +-+-+-+-+-+        +-+-+-+-+-+
|         |               |         |        |         |
|         |               |         |        |         |
|         |  EAP          |         +--------+         |
| Client  |  Conversation |Attacker | Tunnel |         |
|         |<================================>|   NAS   |
|         |               |         |        |         |
|         |               |         +--------+         |
|         |               |         |        |         |
|         |               |         |        |         |
+-+-+-+-+-+               +-+-+-+-+-+        +-+-+-+-+-+

Figure 3 - Man-in-the-middle attack on EAP tunnel

In the figure, the NAS (otherwise known as the EAP authenticator)
supports authentication via tunneled EAP. If the EAP tunneling mechanism
does not require client authentication, then an attacker can establish a
tunnel result it is highly desirable to reuse existing
     algorithms. This enables the NAS without having security community to authenticate itself. The attacker
can then induce carefully
     analyze the proposed algorithm; such an unsuspecting client to authenticate analysis would be difficult
     were multiple algorithms to it. The
attacker then tunnels proliferate. As a result, EAP packets from the client to methods
     SHOULD utilize well established and analyzed mechanisms for
     deriving the NAS,
authenticating itself to PMK from the NAS. Master Key.








Aboba & Simon                Informational                     [Page 13] 12]





INTERNET-DRAFT           The                EAP Keying Problem          22 October Key Mgmt.              6 December 2002


This would not constitute a true man-in-the-middle attack however,
unless the attacker were also able to obtain the


3.2.  Ciphersuite requirements

The derivation of transient session keys used to encrypt
data between the client and the NAS. Since the EAP conversation from PMK(s) occurs
between the client and the NAS, a well designed EAP method would not
permit the attacker to obtain the key derived between the client and
NAS. However, if after the key were
ciphersuite has been determined.  Ciphersuites looking to be derived solely from the tunnel setup
between the attacker and NAS, then the attacker obtains the key without
having to execute a man-in-the-middle attack on the EAP method itself.
EAP tunneling protocols MUST demonstrate how they protect against this
attack, keyed by allowing the client
EAP methods need to provide the authenticator with a
cryptographic binding between the tunnel and following facilities:

TSK specification
     In order to use the encapsulated methods.

Another variety of attack is illustrated in Figure 4.

+-+-+-+-+-+               +-+-+-+-+-+        +-+-+-+-+-+
|         |               |         |        |         |
|         |               |         |        |         |
|         |               |         |        |         |
| Client  | EAP Method 2  | NAS 1   |        |  NAS 2  |
|         |<================================>|         |
|         | PMK(s) provided by EAP Method 1  |         |        |         |
|         |<=============>|         |        |         |
|         |               |         |        |         |
|         |               |         |        |         |
+-+-+-+-+-+               +-+-+-+-+-+        +-+-+-+-+-+

Figure 4. Man-in-the-middle attack on methods, ciphersuites
     keyed via EAP sequence

In this attack, need to define how transient session keys are derived
     from the PMK(s) provided by EAP method 1 is terminated on NAS 1, but methods.

EAP method 2 is
proxied by NAS 1 to NAS 2. If independence
          Algorithms for deriving transient session keys from PMK(s)
          MUST NOT depend on the intent EAP method.  Derivation of transient
          session keys occurs on the client is to require as well as on the NAS, which
          acts as a
single "passthrough" for EAP. Therefore the NAS cannot be
          expected to authenticate via two factors (say, a password/cert and a
token) then this will not have been demonstrated.

In order to provide the client with knowledge of the assurance EAP method that a single NAS has
acted as the authenticator for all methods within been
          negotiated.

Cryptographic separation
          The transient session keys derived from the sequence, PMK(s) MUST be
          cryptographically independent. That is, given one of the
authenticator needs to demonstrate
          transient session keys it MUST NOT be possible to the client a cryptographic binding
between the sequence of EAP methods. derive other
          transient session key(s).

PPP ciphersuites include DESEbis [RFC2419], 3DES [RFC2420], and MPPE
[RFC3078].  The cryptographic binding may be demonstrated via 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 computation
involving 168-bit
encryption key is needed, used in both directions. As described in
[RFC2419] and [RFC2420] for both protocols, the keys generated IV, which is different
in each direction, is "deduced from an explicit 64-bit nonce, which is
exchanged in the clear during the EAP method sequence, as well as negotiation phase."

For MPPE, 40-bit, 56-bit or 128-bit encryption keys derived during tunnel setup. Where this can be required in
each direction, as described in [RFC3078]. Since MPPE is based on the case, it
RC4 algorithm, no initialization vector is not
possible to bind EAP methods which required. While these PPP
ciphersuites provide encryption, they do not derive keys.

For provide a per-packet keyed
message integrity check (MIC). Thus, an EAP method which does authentication key is not derive keys to demonstrate
cryptographic binding, the method as well as the EAP implementation
would need to to support method-specific binding --
required in either direction.

Within 802.11, ciphersuites include WEP-40, described in [IEEE80211],
which existing
methods and EAP implementations typically do not. For example, to allow requires a 40-bit encryption key, the EAP method to incorporate keys derived by other methods, same in either direction;
and WEP-128, which requires a 104-bit encryption key, the EAP same in either
direction.  These ciphersuites also do not include a keyed MIC.





Aboba & Simon                Informational                     [Page 14] 13]





INTERNET-DRAFT           The                EAP Keying Problem          22 October Key Mgmt.              6 December 2002


implementation would need to support passing of keys between methods and
the method would need to be able to make


Recently, new ciphersuites have been proposed for use of the passed keys. Such a
method would not be implementable within an EAP implementation with 802.11 that did
not support a
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 passing facility. hierarchy.

4.  Security considerations

The result subject of this document is that typically only EAP methods that derive keys can be
cryptographically bound in an interoperable way. 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.

[RFC2284]

[RFC2284bis]
          Blunk, L., Vollbrecht, J., "PPP Extensible Aboba, B., "Extensible
          Authentication Protocol (EAP)", RFC 2284, March 1998. 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.

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





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.





Aboba & Simon                Informational                     [Page 15]





INTERNET-DRAFT           The EAP Keying Problem          22 October 2002

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

[DESMODES]
          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

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

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



Aboba & Simon                Informational                     [Page 16] 15]





INTERNET-DRAFT           The                EAP Keying Problem          22 October 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/
          default.asp?url=/library/en-us/eap/eapport_0fj9.asp

Acknowledgments

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

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 17] 16]





INTERNET-DRAFT           The                EAP Keying Problem          22 October 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."

Expiration Date

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


















Aboba & Simon                Informational                     [Page 18] 17]


----