WDIFF

draft-aboba-pppext-key-problem-00.txt --> draft-aboba-pppext-key-problem-01.txt

PPPEXT Working Group Bernard Aboba
INTERNET-DRAFT Dan Simon
Category: Informational Microsoft
<draft-aboba-pppext-key-problem-00.txt>
4 November 2001
<draft-aboba-pppext-key-problem-01.txt>
13 February 2002

The EAP Session Key Keying Problem

Status of this Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. 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.

Abstract

This document makes the case for standardizing the algorithms used to
derive authentication and encryption transient session keys from describes the
master keying material derived issues involved in key derivation by EAP methods. As EAP
methods
proliferate, allowing each EAP method to define its own ciphersuite-
specific key derivation algorithms will compromise the security and
generality that provides guidelines for generation and usage of EAP was intended to provide. keys.

Aboba & Simon Informational [Page 1]

INTERNET-DRAFT The EAP Session Key Keying Problem 4 November 2001 13 February 2002

Table of Contents

1. Introduction .......................................... 3
1.1 Requirements language ........................... 3
1.2 Terminology ..................................... 3
1.3 EAP overview .................................... 3
1.4 Problem overview ................................ 4
2. Proposed EAP architecture ................................ 6 overview ............................. 4
2.1 Solution requirements ........................... 8 Implications of the architecture ................ 7
3. EAP Keying Requirements ............................... 8
4. Security considerations ............................... 10
4. References ............................................ 10 12
5. Normative references .................................. 13
6. Informative references ................................ 13
Acknowledgments .............................................. 13 14
Author's Addresses ........................................... 14 15
Intellectual Property Statement .............................. 14 15
Full Copyright Statement ..................................... 14 15

Aboba & Simon Informational [Page 2]

INTERNET-DRAFT The EAP Session Key Keying Problem 4 November 2001 13 February 2002

1. Introduction

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

1.2. Terminology

This document frequently uses the following terms:

Authentication Server
An Authentication Server is an entity that provides an Extensible Authentication Service Protocol (EAP), defined in [RFC2284], was
developed to an NAS. This service verifies from
the credentials provided by the peer, the claim provide extensible authentication for use with PPP
[RFC1661]. Since then, new applications of identity
made by the peer.

Master key
The session key derived between the EAP client and EAP server
during the EAP have emerged, including
IEEE 802.1X network port authentication process.

Master session key
The keys derived from [IEEE8021X], and PIC [PIC].

Although the master key that are subsequently
used in generation initial focus of the transient session keys for EAP was authentication, encryption, and IV-generation. So that the
master session it can also
provide keys are to be usable with any ciphersuite,
they are longer than is necessary, and are truncated to fit.

Transient session keys
The chosen ciphersuites 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 a ciphersuite.

1.3. EAP overview

The Extensible Authentication Protocol (EAP), methods defined in RFC 2284 [9],
was developed to provide extensible authentication for use with PPP [1].
Since then, new applications of
[RFC2284] include EAP have emerged, including IEEE 802.1X
network port authentication, defined in [21], MD5, as well as One-Time Password (OTP) and provisioning of
certificates based
Generic Token Card methods. Each of legacy authentication these methods via PIC, defined in
[38].

EAP was developed in part to enable deployment of new supports one-way
authentication
methods without requiring deployment of new code on the NAS. As a
result, the NAS acts as a "passthrough", and does only but not need to understand

Aboba & Simon Informational [Page 3]

INTERNET-DRAFT The EAP Session Key Problem 4 November 2001

specific key derivation. However, subsequent EAP methods. Among other things, this implies that a NAS cannot
be assumed to contain code specific to any
method specifications such as EAP method.

Instead of requiring new code to be installed on the NAS in order to
support a new TLS [RFC2716], EAP method, SRP [EAPSRP], EAP method support is added to the client
GSS [EAPGSS] and
backend authentication server. EAP method support is typically AKA [EAPAKA] have provided
via an EAP API, such for mutual
authentication, as that described well as key derivation.

The ciphersuites for which EAP may provide keying material have also
grown in [42]. In order to allow the
client number. PPP ciphersuites include DESEbis [RFC2419], 3DES
[RFC2420], and backend 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 also operate as
"passthrough" entities with respect to EAP.

Since the client and NAS will need to contain code to implement any
particular ciphersuite, it is reasonable to assume that ciphersuite-
specific code exists on these entities. However, just as the NAS should
not need to be updated to support a new EAP method, the backend
authentication server should not need to be updated to support a new
ciphersuite on the NAS. Since the backend authentication server MPPE [RFC3078]. The DES algorithm is not
involved described in the protection of data traffic, there is no intrinsic reason
that it should need to implement ciphersuite-specific code.

These restrictions, when put together, imply that including ciphersuite-
specific code within an EAP method is inappropriate,
[FIPSDES], and DES modes (such as is including
code specific to an EAP-method within the NAS. Moreover, since operating
systems provide EAP APIs CBC, used in order to remain "EAP-Method Agnostic", EAP
method-specific code is best kept out of the EAP APIs as well.

1.4. Problem overview RFC 2284 defined the EAP-MD5, as well as One-Time Password (OTP) and
Generic Token Card methods. Since then, the development of additional
EAP methods has accelerated. These include EAP-TLS [32], EAP-SRP [37],
EAP-GSS [39] 2419 and EAP-AKA [40]. Each of these methods is capable of
deriving keys, as well as providing for mutual authentication.

The ciphersuites for which EAP may provide keying material have also
grown DES-
EDE3-CBC, used in number. Within PPP, ciphersuites include DESEbis [16], 3DES
[17], and MPPE [36]. RFC 2420) are described in [DESMODES]. For PPP
DESEbis, a single 56-bit encryption key is
required required, used in each direction; both
directions; for PPP 3DES, a 168-bit encryption key is
needed needed, used in each direction;
both directions. As described in [RFC2419] and [RFC2420] for MPPE, 40-bit, 56-bit or 128-bit encryption
keys 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 [35],[36]. [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 [24], [IEEE80211],
which requires a 40-bit encryption key, which is 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 4]

INTERNET-DRAFT The EAP Session Key Problem 4 November 2001

Recently, new ciphersuites have been proposed for use with 802.11 that
do provide per-packet authentication as well as encryption. encryption
[IEEE80211Tgi]. These
methods, described in [41], require ciphersuites use either 104-bit or 128-bit authentication and
encryption keys in each direction, and are based on AES [43]-[46]. keys.

With the increase in the number of EAP methods and applicable
ciphersuites, there is a growing need for supplying algorithms to derive defining how transient session keys
are derived from the master keys secrets produced by EAP methods. To
date, this need has been filled on a piece-meal basis, with EAP methods
such as EAP SRP [37], defining transient session key derivation
mechanisms for each ciphersuite.

There are significant drawbacks to allowing Allowing
each EAP method to specify
session handle this in its own way is likely to produce

Aboba & Simon Informational [Page 3]

INTERNET-DRAFT The EAP Keying Problem 13 February 2002

unacceptable results.

This document reviews the issues involved in EAP key derivation mechanisms and
provides guidelines for individual ciphersuites. These
include:

Document Revision
If an EAP method specifies how to derive transient
session the generation of keys on a per-ciphersuite basis, then 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 will need are to be revised each time a new
ciphersuite comes out. interpreted as described in BCP 14 [RFC2119].

1.2. Terminology

This would also imply that document frequently uses the following terms:

Authentication Server
An Authentication Server is an
authentication server supporting entity that provides an EAP method might not
be usable with a NAS supporting EAP, due
Authentication Service to lack of
support for a ciphersuite implemented on the an NAS. This is
antithetical to the EAP architecture, which conceives of service verifies from
the NAS as a "pass through" device that does not need to
understand EAP, and which therefore can work with any EAP
method supported credentials provided by the authentication server.

EAP method complexity
Forcing peer, the EAP method to include ciphersuite-specific
code for transient session claim of identity
made by the peer.

Master key derivation increases
The key derived between the
complexity of EAP method development, as well as client and authentication server implementations.

Knowledge assymmetry
In practice, an EAP method may not have knowledge of the
ciphersuite that has been negotiated. In PPP, negotiation
of server during
the ciphersuite is accomplished via EAP authentication process.

Master session key
Master session keys are derived from the Encryption
Control Protocol (ECP), described master key, and are
subsequently used in [10]. Since ECP
negotiation occurs after generation of transient session keys for
authentication, unless an EAP
method is utilized that supports ciphersuite negotiation
(such as EAP-TLS [32]), the client, NAS encryption and backend
authentication server may not be able to anticipate IV-generation. Since the
ciphersuite that will
transient session keys may be used different in each direction,
master session keys are also required in each direction, and
are therefore this
information cannot be provided to the EAP method.

Aboba & Simon Informational [Page 5]

INTERNET-DRAFT The EAP Session Key Problem 4 November 2001

Similarly, it is also desirable referred to avoid proliferation of EAP method-
specific master session key derivation algorithms. Aside from the
duplication of effort this would imply, the deployment of many
algorithms, as opposed to a single well-analyzed one, is more likely to
create security vulnerabilities.

2. Proposed architecture

This document proposes an architecture "asymmetrical". So that avoids the proliferation of
EAP method-specific
master session key algorithms, as well as
ciphersuite-specific keys are to be usable with any ciphersuite,
they are longer than is necessary, and are truncated to fit.

Transient session keys
The chosen ciphersuite uses transient session key algorithms.

In the most general case, keys for
authentication and encryption keys as well as
initialization vectors must be derived for each direction from the
master key K derived by the EAP method. This is accomplished by the
adoption of two standard algorithms:

[1] An algorithm for the derivation of "master session keys" from the
negotiated master key. IVs (if required).
The "master transient session keys" keys are derived from the master key derived by the EAP method, but are never directly
used by ciphersuites; they are only used in the derivation of
transient session keys. These "master session keys" are derived on
the client
keys, and the backend authentication server. The backend
authentication server then transmits the "master session keys" to
the NAS.

[2] An algorithm for the derivation are of "transient session keys" from the "master session keys". The "transient session keys" are used appropriate size for encryption, authentication and IV-generation in each direction,
and are derived by the NAS and client, based on use with the negotiated chosen
ciphersuite. Depending on the negotiated ciphersuite, not all of the "transient transient
session keys" will keys may be required; for example 802.11 WEP does not provide
a keyed message integrity check, and typically uses only a single
encryption key different in both directions. each direction.

Aboba & Simon Informational [Page 4]

INTERNET-DRAFT The algorithm for deriving the "master session keys" from EAP Keying Problem 13 February 2002

2. EAP architecture overview

One of the "master
key" goals of EAP is designed to be ciphersuite-independent, and to apply across a
wide range enable development of EAP methods. This enables new authentication
methods without requiring deployment of new code on the security community to
carefully analyze NAS. As a
result, the proposed algorithm. Such an analysis would be
difficult were multiple algorithms to proliferate.

The specification of NAS acts as a universal algorithm for master session key
derivation also enables development of libraries that can be called by "passthrough", and need not understand
specific EAP method developers, who otherwise would have to methods. Among other things, this implies that a NAS need
not contain code algorithms
independently within specific to each EAP method. This also avoids having to upgrade
AAA servers and EAP methods every time a

Instead of requiring new ciphersuite is developed,

Aboba & Simon Informational [Page 6]

INTERNET-DRAFT The EAP Session Key Problem 4 November 2001

By standardizing code on the master session key derivation within NAS, EAP methods
and are installed on
the AAA client and backend authentication server, typically interfacing with
the NAS can be assured of obtaining master
session keys in a well-defined format. Since it is assumed operating system via an EAP API, such as that described in [EAPAPI].
In order to allow the client and backend authentication server will perform to install new EAP
methods without requiring an operating system upgrade, operating systems
isolate EAP method-specific code within the required calculations installed EAP methods, and
will supply the NAS
thus largely operate as "passthrough" entities with respect to EAP.

Figure 1 describes the master session keys, relationship between the algorithm need not
be implemented on EAP peer, NAS and AAA
server. As described in the NAS.

Rather, figure, the EAP conversation "passes
through" the NAS will only need code for on its way between the second algorithm, namely for client and the derivation AAA server As a
result, the NAS does not have knowledge of ciphersuite-specific "transient session keys" from
"master session keys". Although the NAS needs keys that are derived
between the AAA server and the client, and these keys need to be upgraded to support
additional ciphersuites, it is best if the code for generation of
"transient session keys"
transmitted from "master session keys" is as ciphersuite-
independent as possible, so as the AAA server to avoid requiring constant maintenance
of the algorithm.

The derivation of ciphersuite-specific "transient session keys" from
"master session keys" occurs after NAS.

EAP methods are installed on the ciphersuite has been determined,
and provides for authentication the client and encryption keys as well as IV-
generation. Within the proposed architecture, this conversion is also
carried out according to a standardized algorithm.

The algorithm for deriving "transient session keys" from AAA server,
typically communicating via an EAP API, so that the "master
session keys" is designed main client and AAA
server code does not need to be EAP-method independent, and modified to apply
across a wide range of ciphersuites. This enables its security also add new methods. Among the
results that are passed back by EAP methods via the APIs are the keys to
be thoroughly analyzed and for communicated from the code AAA server to the NAS. Ciphersuites are
installed on the NAS and the client.

While EAP methods which derive keys can be reused within 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
where it need to
implement a given ciphersuite, ciphersuite-specific code is expected to reside.

Note that
exist on the master key client and NAS. However, since the backend authentication
server is not involved in the protection of data traffic, and may not
even be directly available within all EAP
methods. For security reasons, aware of the TLS master key is typically not
directly available via TLS APIs. As a result, RFC 2716 [32] derives
master session keys from the TLS master key, and uses those master
session keys negotiated ciphersuite, it cannot be assumed to derive
implement ciphersuite-specific code, and the required session keys. Since RFC 2716 does backend authentication
server will not assume necessarily have knowledge of the negotiated ciphersuite, it provides keys
large enough for use with any ciphersuite, assuming that these will be
truncated for use within ciphersuites available
on the client NAS and client.

Aboba & Simon Informational [Page 5]

INTERNET-DRAFT The EAP Keying Problem 13 February 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 13 February 2002

2.1. Implications of the architecture

Since the raw master key
is typically backend authentication server may not available in to EAP-TLS implementations, when have knowledge of the
ciphersuite that has been negotiated, it may not be possible for this
information to be passed to the EAP method is used, via the TLS PRF function is needed to derive keying material
from it.

Other EAP methods may also encounter similar issues. For example, APIs. As a
result, inclusion of ciphersuite-specific code within an EAP
GSS implementations will typically method is
inappropriate. Similarly, because the NAS is assumed to not have
knowledge of individual EAP methods, it cannot be able assumed to access 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 master keys
directly, but can call GSS_Wrap() EAP APIs as well.

Drawbacks to encrypted tokens and GSS_GetMIC() allowing EAP methods to generate 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 tokens based 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 master key. NAS. This is
antithetical to the EAP GSS
implementations will therefore architecture, which conceives of
the NAS as a "pass through" device that does not need to use GSS-API calls
understand EAP, and which therefore can work with any EAP
method supported by the authentication server.

EAP method complexity
Forcing the EAP method to derive
master include ciphersuite-specific
code for transient session key derivation increases the
complexity of EAP method development, as well as client
and authentication server implementations.

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

Aboba & Simon Informational [Page 7]

INTERNET-DRAFT The EAP Keying Problem 13 February 2002

3. EAP keying requirements

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

[1] Algorithms for the derivation of "master session keys" from the
negotiated master key. The "master session keys" are derived from
the master key derived by the EAP method, but are never directly
used by ciphersuites; they are only used in the derivation of
transient session keys. These "master session keys" are derived on
the client and the backend authentication server. The backend
authentication server then transmits the "master session keys" to
the NAS.

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

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

The algorithm for deriving the "master session keys" from the "master
key" is designed to be ciphersuite-independent, and is specific to the
EAP method. The goal of this algorithm is to provide master session keys
in a well defined format, suitable for passage between the AAA server
and the NAS.

Examples of master session key derivation algorithms are provided in
Section 3.5 of EAP TLS [RFC2716], 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 attributes
are provided in [RFC2548].

Note that because the derivation and validation 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 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 algorithms may not fit all situations.

Aboba & Simon Informational [Page 8]

INTERNET-DRAFT The EAP Keying Problem 13 February 2002

For example, 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 the required session keys. Since EAP TLS [RFC2716] does
not assume knowledge of the negotiated ciphersuite, it provides keys
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
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 authentication and encryption keys as well as IV-
generation. The algorithm for deriving "transient session keys" from
the "master session keys" is designed to be EAP-method independent.
Since each ciphersuite will have different needs, the algorithms for
transient session key derivation will vary from ciphersuite to
ciphersuite. 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.

Figure 2 on the next page describes the overall logic of how master
session keys and transient session keys are derived from the master key
negotiated within an EAP method.

Aboba & Simon Informational [Page 9]

INTERNET-DRAFT The EAP Keying Problem 13 February 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 |
| Master Session Key | Method |
| Derivation | |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | |
| Master Session Key Outputs | |
| | |
V V |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | |
| Key and IV Derivation | |
| 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 | | ^
| | | | | | AAA |
| | | | | | Keys V
V V V V V V ---+---
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^
| | |
| Ciphersuite-Specific Truncation & | NAS |
| Key utilization | |
| | V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+---

Figure 2 - Architecture for derivation of session keys from the master key, rather than operating on the
EAP method master key directly. K.

Aboba & Simon Informational [Page 7] 10]

INTERNET-DRAFT The EAP Session Key Keying Problem 4 November 2001

While method-specific algorithms may be required in some methods, for
other methods, the master key is directly available, and so the
algorithm used to derive master sesion keys from it can be designed in
complete freedom. However, even where such freedom is available, the
proliferation of EAP method-specific key derivation algorithms is
undesirable.

Figure 1 on the next page describes the overall logic of how master
session keys and transient session keys are derived from the master key
negotiated with an EAP method. 13 February 2002

The master key K may be of varying length, and as described earlier, may
not be directly available to the EAP method. 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 EAP GSS, as described
in [39], [EAPGSS], a "Pseudo-Master Key", K' is derived via GSS-API calls, and
is used instead.

2.1. Solution requirements

In order to enable interoperability between backend authentication
servers, NASen and EAP clients implementing EAP methods that derive
keys, the following is required:

Key hierarchy
In order to enable the keys derived within EAP methods to be used
within any ciphersuite, EAP methods deriving keys need to specify
the algorithms for master session 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.

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 uses to transmit keys from the backend
authentication server to the NAS.

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

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 need to 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.

Direct and Indirect Access
A satisfactory "master session key" derivation algorithm MUST
be applicable to EAP methods where the master key is not
directly accessible. These include TLS and GSS-API methods.

Aboba & Simon Informational [Page 8] 11]

INTERNET-DRAFT The EAP Session Key Keying Problem 4 November 2001

provide master key? |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| K | K'
| |
V V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Master Session Key |
| Derivation |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Master Session Key Outputs |
| |
V V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Key and IV Derivation |
| Derivation |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P->A | A->P | P->A | A->P | P->A | A->P
| Enc. | Enc. | Auth. | Auth. | IV | IV
| Key | Key | Key | Key | |
| | | | | |
| | | | | |
V V V V V V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Ciphersuite-Specific Truncation & |
| Key utilization |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1 - Architecture session keys appropriate for derivation use with a wide
range of ciphersuites. Among other things, this implies that
the master session keys from the 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 and Indirect Access
Satisfactory "master session key" derivation algorithm MUST be
applicable to EAP method methods where the master key K.

Aboba & Simon Informational [Page 9]

INTERNET-DRAFT The is not directly
accessible. These include TLS and GSS-API methods.

Generality
It is likely that each EAP Session Key Problem 4 November 2001

The algorithm method will handle the derivation
of "master session keys" from "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:

EAP method independence
The algorithm
Algorithms for deriving "transient session keys" from "master
session keys" MUST NOT depend on the EAP method. Derivation
of "transient session keys" is expected to occur 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 negotiated.

Generality
The algorithm
More than one algorithm(s) for derivation of "transient
session keys" from "master session keys" MUST MAY be suitable for use with a wide required, in
order to cover the full range of ciphersuites. In practice, this means that the
algorithm must ciphersuites, but algorithms
SHOULD be usable with existing and future
ciphersuites.

3. reused where possible, so that they do not
proliferate unnecessarily.

4. Security considerations

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.

Aboba & Simon Informational [Page 12]

INTERNET-DRAFT The EAP Keying Problem 13 February 2002

5. Normative References

[1]

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

[2] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T. Coradetti,
"The PPP Multilink Protocol (MP)", RFC 1990, August 1996.

[3] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, January 1994.

[4] Lloyd, B., Simpson, W., "PPP Authentication Protocols," RFC 1334,
October 1992.

[5] Simpson, W., "PPP Challenge Handshake Authentication Protocol
(CHAP)," RFC 1994, August 1996.

[6] Zorn, G., Cobb,

[RFC2119] Bradner, S., "Microsoft PPP CHAP Extensions," RFC 2433,
October 1998.

[7] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2," "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2759,
January 2000.

Aboba & Simon Informational [Page 10]

INTERNET-DRAFT The EAP Session Key Problem 4 November 2001

[8] Rivest, R., Dusse, S., 2119, March 1997.

[RFC2246] Dierks, T. and Allen, C. "The MD5 Message-Digest Algorithm", TLS Protocol Version 1.0", RFC
1321, April 1992.

[9]
2246, November 1998.

[RFC2284] Blunk, L., Vollbrecht, J., "PPP Extensible Authentication
Protocol (EAP)", RFC 2284, March 1998.

[10]

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

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

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

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

[14] Daemen, Joan and Vincent Rijmen, "AES Proposal: Rijndael",
September 1999, <http://www.esat.kuleuven.ac.be/~rijmen/rijndael/>.

[15] National Institute of Standards and Technology, "Rijndael: NIST's
Selection for the AES", December 2000,
<http://csrc.nist.gov/encryption/aes/rijndael/Rijndael.pdf>.

[16]

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

[17]

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

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

[19] D. Rand. "The PPP Compression Control Protocol", RFC 1962, Novell,
June 1996.

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

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

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

Aboba & Simon Informational [Page 11]

INTERNET-DRAFT The EAP Session Key Problem 4 November 2001

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

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

[25] Wu, T., "The Secure Remote Password Protocol", in Proceedings of
the 1998 Internet Society Symposium on Network and Distributed
Systems Security, San Diego, CA, pp. 97-111

[26] Wu, T., "The Secure Remote Password Protocol", March 1998,
<http://srp.stanford.edu/srp/ndss.html>.

[27] Wu, T., "The SRP Authentication and Key Exchange System," RFC 2945,
September 2000.

[28] Wu, T., "SRP: The Open Source Password Authentication Standard",
March 1998, <http://srp.stanford.edu/srp/>.

[29] Hopwood, D., "Standard Cryptographic Algorithm Naming", June 2000,
<http://www.eskimo.com/~weidai/scan-mirror/>.

[30] Menezes, A.J., van Oorschot, P.C. and S.A. Vanstone, "Handbook of
Applied Cryptography", CRC Press, Inc., ISBN 0-8493-8523-7, 1997,
<http://www.cacr.math.uwaterloo.ca/hac/about/chap7.ps>.

[31] Krawczyk,
RFC 2420, September 1998.

[RFC2434] Alvestrand, H. et al, "HMAC: Keyed-Hashing and T. Narten, "Guidelines for Message
Authentication", Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2104, February 1997.

[32] 2434, October
1998.

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

[33] Dierks, T.

[RFC3078] Pall, G. and Allen, C. "The TLS Protocol Version 1.0", RFC 2246,
November 1998.

[34] Orman, H., "The Oakley Key Determination Protocol", Zorn, G. "Microsoft Point-to-Point Encryption
(MPPE) RFC 2412,
November 1998.

[35] 3078, March 2001.

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

[36] Pall, G. and Zorn, G. "Microsoft Point-to-Point Encryption (MPPE)
RFC 3078, March 2001.

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

Aboba & Simon Informational [Page 12] 13]

INTERNET-DRAFT The EAP Session Key Keying Problem 4 13 February 2002

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

[37] 2001.

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

[38]

[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-03.txt, July 2001.

[39] Aboba, B., "EAP GSS Authentication Protocol", Internet draft (work
in progress), draft-aboba-pppext-eapgss-08.txt, October 2001.

[40] Arkko, J., Haverinen, H., "EAP AKA Authentication", Internet draft
(work in progress), draft-arkko-pppext-eap-aka-00.txt, December
2001.

[41] draft-ietf-ipsra-pic-05.txt, February 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.

[42]

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

[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

[43] Daemen, J., Rijman, V., "AES Proposal: Rijndael," NIST AES
Proposal, June 1998. http://csrc.nist.gov/encryption/aes/round2/
AESAlgs/Rijndael/Rijndael.pdf

[44] Draft FIPS Publication ZZZZ, "Advanced Encryption Standard (AES)",
U.S. DoC/NIST, summer 2001.

[45] "Symmetric Key Block Cipher Modes of Operation,"
http://www.nist.gov/modes.

[46] "Recommendation for Block Cipher Modes of Operation", National
Institute of Standards and Technology (NIST) Special Publication
800-XX, CODEN: NSPUE2, U.S. Government Printing Office, Washington,
DC, July 2001. 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 Microsoft,
Dorothy Stanley of Agerem and Russ Housley of RSA Security for useful
feedback.

Aboba & Simon Informational [Page 13] 14]

INTERNET-DRAFT The EAP Session Key Keying Problem 4 November 2001 13 February 2002

Author Addresses

Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052

EMail: bernarda@microsoft.com
Phone: +1 425 706 6605
Fax: +1 425 706 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 706 7329

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to pertain
to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or
might not be available; neither does it represent that it has made any
effort to identify any such rights. Information on the IETF's
procedures with respect to rights in standards-track and standards-
related documentation can be found in BCP-11. Copies of claims of
rights made available for publication and any assurances of licenses to
be made available, or the result of an attempt made to obtain a general
license or permission for the use of such proprietary rights by
implementors or users of this specification can be obtained from the
IETF Secretariat.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights
which may cover technology that may be required to practice this
standard. Please address the information to the IETF Executive
Director.

Full Copyright Statement

Copyright (C) The Internet Society (2001). (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

Aboba & Simon Informational [Page 14] 15]

INTERNET-DRAFT The EAP Session Key Keying Problem 4 November 2001 13 February 2002

assist in its implmentation 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 inthe 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-00.txt>, <draft-aboba-pppext-key-problem-01.txt>, and
expires May August 22, 2002.

Aboba & Simon Informational [Page 15] 16]

----