Internet Draft J. Salowey
Document: draft-salowey-eap-key-deriv-00.txt Cisco
P. Eronen
Nokia
Expires: August 2003 February 2003
EAP Key Derivation for Multiple Applications
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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
The Extensible Authentication Protocol (EAP) provides an extensible
interface to various authentication mechanisms. Some EAP methods
derive cryptographic material between the EAP peers; these keys can
be used, for instance, with IEEE 802.11i encryption. This document
proposes a mechanism that can be used to derive cryptographically
separate keys for more than one cryptographic application, such as
protecting subsequent EAP messages, distributing credentials for re-
authentication, or handoff mechanisms involving multiple WLAN access
points.
Table of Contents
1. Introduction...................................................2
1.1 Cryptographic separation between applications..............2
Salowey and Eronen Expires August 2003 [Page 1]
INTERNET-DRAFT EAP Key Derivation February 2003
1.2 Cryptographic separation between devices...................3
1.3 Use cases..................................................3
1.4 Motivation.................................................4
1.5 Terminology................................................4
2. Requirements for EAP methods and applications..................5
2.1 Requirements for EAP methods...............................5
2.2 Requirements for EAP applications..........................6
3. EAP Key Derivation Framework...................................6
3.1 The EAP Key Derivation Function............................7
3.2 Multiple EAP mechanism keys................................7
4. Security Considerations........................................8
4.1 Key strength...............................................8
4.2 Cryptographic separation of keys...........................8
4.3 Implementation.............................................8
5. IANA Considerations............................................8
References........................................................9
Acknowledgments...................................................9
Author's Addresses...............................................10
Appendix A: Test vectors for KDF.................................10
1. Introduction
EAP provides a consistent interface for exchanging authentication
messages. It is also possible for some EAP methods to generate
keying material that will be used to protect some subsequent
application (e.g. 802.11i encryption).
Typically, an EAP method produces a Master Session Key (MSK), which
is sent by the EAP server to the authenticator (e.g. NAS, WLAN access
point). The authenticator then uses the MSK to derive Transient
Session Keys (TSKs), which are used to protect the actual
communication. This derivation is specific to the particular
application (e.g. MPPE, 802.11i encryption) and cipher suites used.
The derivation is done by the authenticator, so the EAP server does
not have to know about the applications and cipher suites.
In addition, an EAP method may internally use some keys (Transient
EAP Keys or TEKs) to protect its communication. In this document, we
are not interested in these keys, only keys that are used after an
EAP method has finished and exported some keying material.
The current EAP specifications implicitly assume that the keying
material produced by EAP will be used for a single application at a
single device.
1.1 Cryptographic separation between applications
Salowey and Eronen Expires August 2003 [Page 2]
INTERNET-DRAFT EAP Key Derivation February 2003
If the keying material is used to provide keys for multiple
applications, it is often desired that the keys will be
cryptographically separate.
This separation currently depends on the individual key derivation
functions (KDF) and protocols (which take the MSK and possibly via
some intermediate steps, produce TSKs); for instance, 802.11 and MPPE
specify such functions [references].
If multiple applications are used, it is important that these KDFs
actually provide separate keys. How should this be done, i.e., who
should coordinate that these KDFs actually achieve this?
o Certainly not EAP methods; the methods should be independent of
the applications their keys will be used for.
o Probably not the application specifications, since otherwise all
applications have to know what other applications (current and
future) could be used together.
This document attempts to specify such a mechanism, which can be used
with existing and new EAP methods, and existing and new applications
for these keys, in a way that provides cryptographic separation.
1.2 Cryptographic separation between devices
A related issue is that the keys could be used by separate devices.
In this case, it may be desirable that their knowledge is
cryptographically separate.
This implies that some key derivation must be done at the EAP server
(which knows everything exported by the EAP method) instead of the
authenticator, and that authenticator should be sent only keys
derived from the MSK. This changes one of the traditional assumptions
in EAP: that the EAP server should not know what the keys will be
used for. Changing this assumption should not be taken lightly:
alternative ways to achieving a particular goal should be
investigated.
This document attempts to specify a mechanism that allows the EAP
server to derive cryptographically separate keys from the MSK. The
mechanism is backward-compatible with existing application specs and
authenticators.
1.3 Use cases
There are several applications for ciphering keys outside of link
layer protection as in 802.11. This specification could derive keys
to protect sensitive authorization information requested from an EAP
Salowey and Eronen Expires August 2003 [Page 3]
INTERNET-DRAFT EAP Key Derivation February 2003
peer by and EAP server [EAP-AUTH]. In another example the EAP server
may wish to issue credentials to an EAP peer in a protected TLV [PRO-
TLV]. Many other applications can be found for keys derived from EAP-
mechanisms.
A recent proposal for 802.11 handoff by Mishra et al. [IEEE-03-084]
provides another example where cryptographic separation between
different devices was required. To derive cryptographically separate
keys for different WLAN access points, their proposal uses a value
internal to a particular EAP method (TLS master secret in EAP-TLS),
making it difficult to use for other EAP methods.
1.4 Motivation
<Why current specs fall short.>
Cryptographic separation between devices within a single application
can be addressed by existing specs, simply by considering the device-
specific master keys to be just one kind of TSK. Cryptographic
separation between different applications CANNOT be addressed by
existing solutions UNLESS we require that the derivation of TSKs is
somehow coordinated. This document specifies a way of coordinating
these.
We want to have a mechanism for deriving independent keys which (1)
does not depend on a single EAP method, and (2) allows development of
new applications without cumbersome coordination between different
application specifications.
1.5 Terminology
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 [RFC2119].
Some of the following terms are taken from RFC 2284bis:
EAP Peer
The end of the EAP Link that responds to the authenticator.
EAP server
The entity that terminates the EAP authentication with the peer.
In the case where there is no backend authentication server, this
term refers to the authenticator. Where the authenticator operates
in pass-through, it refers to the backend authentication server.
EAP application
Salowey and Eronen Expires August 2003 [Page 4]
INTERNET-DRAFT EAP Key Derivation February 2003
A consumer of EAP keying material. Examples include link layer
encryption such as 802.11i encryption, MPPE, etc.
Master Session Key (MSK)
Keying material exported by an EAP method.
Extended Master Session Key (EMSK)
Keying material taken from a specific portion of the MSK that is
not used for any other purpose than the key derivation described
in this document. Usually bytes 64..N of MSK.
Transient Session Key (TSK)
Session keys used to protect communication in some particular
application. They are derived from MSK(0,63) or an AMSK in an
application-specific way.
Application Master Session Key (AMSK)
Keying material used to derive TSKs for the application in an
application specific way.
Cryptographic separation
Two keys (X and Y) are "cryptographically separate" (or
"independent") if an adversary that knows all messages exchanged
in the protocol (and other public information) cannot compute X
from Y or Y from X without "breaking" some cryptographic
assumption. (definition borrowed from [EAP-Key])
2. Requirements for EAP methods and applications
2.1 Requirements for EAP methods
In order for an EAP method to participate in the EAP key derivation
it must meet the following requirements.
o It must specify how to obtain an EMSK from the MSK exported by
the method. Unless otherwise specified, the first 64 bytes of
the MSK are used for backward-compatibility, and rest of the MSK
is EMSK.
o The key material used for the EMSK MUST be independent of the
backward-compatibility part (first 64 bytes) and TEKs.
Salowey and Eronen Expires August 2003 [Page 5]
INTERNET-DRAFT EAP Key Derivation February 2003
o The EMSK MUST NOT be used for any other purpose than the key
derivation described in this document.
o The EMSK MUST be secret and not known to someone observing the
authentication mechanism protocol exchange.
o The EMSK MUST be unique for each session.
2.2 Requirements for EAP applications
To be compatible with this spec,
o The application MAY use the first 64 bytes of the MSK in any way
it chooses. This is required for backward compatibility. New
applications following this specification SHOULD NOT use the
first 64 bytes.
o The application MUST NOT use MSK bytes 65..N or EMSK in any
other way except the key derivation specified in this document.
o Applications MUST use distinct key labels.
o If more than one application uses the first 64 bytes of the MSK,
then the cryptographic separation is not achieved.
Implementations SHOULD prevent such combinations.
Most (all?) existing EAP applications use only the first 64 bytes of
the MSK (and only 32 or 64 bytes is usually sent to the
authenticator), and thus are compatible with this scheme. <is e.g.
802.11i is compatible?>
3. EAP Key Derivation Framework
The EAP key derivation framework provides a means for generating
multiple application-specific master keys (AMSKs). These AMSKs are
then used to derive transient session keys (TSKs), which are used as
actual ciphering keys.
This allows multiple applications to use keys independently derived
from the EAP method. The EAP key derivation framework provides a key
derivation function (KDF) which takes the Extended Master Session Key
(EMSK) described above, an application key label, and optional
application data, and returns an application master session key
(AMSK).
AMSK = KDF(EMSK, key label, optional application data)
Salowey and Eronen Expires August 2003 [Page 6]
INTERNET-DRAFT EAP Key Derivation February 2003
The key labels are unique printable ASCII strings (see Section 5 for
IANA Considerations).
Additional ciphering keys (TSKs) can be derived from the AMSK using
an application specific key derivation mechanism. In most cases, this
AMSK->TSK derivation can simply split the AMSK to pieces of correct
length. In particular, it not necessary to use a cryptographic one-
way function.
Note that the length of the AMSK is not fixed, since the KDF can
produce a (practically) unlimited amount of keying material. If the
AMSK is, for instance, sent to another device, the EAP application
MUST specify how many bytes must be sent. Unless otherwise specified,
128 bytes is recommended.
3.1 The EAP Key Derivation Function
The EAP key derivation function is taken from the TLS pseudo-random
function [RFC2246]. The TLS PRF takes three parameters as input:
secret, label, and seed, and produces an arbitrary amount of keying
material.
For the purposes of this specification the secret is taken as the
EMSK, the label is the key label described above concatenated with a
NUL byte, and the seed is the application data. The seed is
optional. For this specification we have:
KDF = PRF(EMSK, key label + "\0", application data)
TLS-PRF was chosen because it offers a suitable interface, and
implementations are readily available. IKE uses a very similar PRF
[RFC2409], but it does not include label and seed fields.
The NUL byte after the key label is used to avoid collisions if one
key label is a prefix of another label (e.g. "foobar" and
"foobarExtendedV2"). This is considered a simpler solution than
requiring a key label assignment policy that prevents prefixes from
occurring.
3.2 Multiple EAP mechanism keys
It is possible that multiple EAP mechanisms may be chained or nested
and the more than one of these mechanisms may generate keys. In this
case it is desirable to combine the entropy of these keys. In this
case an EAP combined master key (EAP-CMSK) is derived as follows.
EAP-CMSK_0 = EMSK_0
EAP-CMSK_n =
PRF(EAP-CMSK_n-1, "combined master session key", EMSK_n)
Salowey and Eronen Expires August 2003 [Page 7]
INTERNET-DRAFT EAP Key Derivation February 2003
The EAP-CMSK is used instead of EMSK for cases where multiple
mechanisms generate keys.
<To be determined: Is the mechanism above cryptographically sound? Is
EAP-CMSK_n = PRF(EAP-CMSK_n-1 + EMSK_n, "combined master session
key") better?>
<To be determined: Is the specification clear enough? At what point
exactly is a key produced, especially for nested mechanisms?>
In the case of nested EAP mechanisms (that is, tunneling), the outer
(tunneling) mechanism MAY define its own way to combine the keys.
4. Security Considerations
4.1 Key strength
The effective key strength of the derived keys will never be greater
than the strength of the EMSK (or a master key internal to an EAP
mechanism).
<An EAP mechanism should export at least 64 + N bytes of secret key
material as the master key where N is the estimated strength of the
master key internal to the EAP mechanism.>
4.2 Cryptographic separation of keys
The intent of the KDF is to derive keys that are cryptographically
separate: the compromise of one of the application master keys
(AMSKs) should not compromise the security of other AMSKs or the
EMSK. It is believed that the KDF chosen provides the desired
separation.
4.3 Implementation
An implementation of an EAP framework may choose to keep the EMSK
internally and only provide an interface to KDF for applications to
obtain derived keys. It may also choose to restrict which callers
have access to which keys.
5. IANA Considerations
This specification introduces a new name space for "key labels". In
addition to defining a label an application must specify if and how
application data will be used in the key derivation. <insert text
Salowey and Eronen Expires August 2003 [Page 8]
INTERNET-DRAFT EAP Key Derivation February 2003
describing how they are allocated by IANA, and refer to [RFC2434] as
necessary>
References
[EAP]
Blunk, L., J. Vollbrecht, B. Aboba, J. Carlson, "Extensible
Authentication Protocol (EAP)", draft-ietf-eap-rfc2284bis-01,
February 2003 (work in progress).
[EAP-Auth]
Grayson, M. and J. Salowey, "EAP Authorization", draft-
grayson-eap-authorisation-00, January 2003 (work in progress).
[EAP-Key]
Aboba, B. and D. Simon, "EAP Keying Framework", draft-aboba-
pppext-key-problem-05, December 2002 (work in progress).
[PRO-TLV]
Salowey, J., "Protected EAP TLV", draft-salowey-eap-
protectedtlv-00.txt, January 2003 (work in progress)
[IEEE-03-084]
Mishra, A., M. Shin, W. Arbaugh, I. Lee, and K. Jang,
"Proactive Key Distribution to support fast and secure
roaming", IEEE 802.11 Working Group, IEEE-03-84r1-I,
http://www.ieee802.org/11/Documents/DocumentHolder/3-084.zip,
January 2003.
[RFC2119]
Bradner, S., "Key words for use in RFCs to indicate
Requirement Levels", RFC 2119, March 1997.
[RFC2246]
Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[RFC2409]
Harkins, D., and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[RFC2434]
Narten, T., and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434, October 1998.
Acknowledgments
Salowey and Eronen Expires August 2003 [Page 9]
INTERNET-DRAFT EAP Key Derivation February 2003
This document expands upon ideas from conversations with Bernard
Aboba, Jari Arkko, and Henry Haverinen.
Author's Addresses
Joseph Salowey
Cisco Systems
2901 3rd Ave
Seattle, WA 98121
US
Phone: +1 206 256 3380
Email: jsalowey@cisco.com
Pasi Eronen
Nokia Research Center
P.O. Box 407
FIN-00045 Nokia Group
Finland
Email: pasi.eronen@nokia.com
Appendix A: Test vectors for KDF
<insert test vectors for the KDF here; unfortunately, TLS spec
does not include these>
Salowey and Eronen Expires August 2003 [Page 10]