One document matched: draft-salowey-eap-key-deriv-01.txt
Differences from draft-salowey-eap-key-deriv-00.txt
Network Working Group
INTERNET-DRAFT J. Salowey
Document: draft-salowey-eap-key-deriv-01.txt Cisco
P. Eronen
Nokia
Expires: December 2003 June 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
1.2 Cryptographic separation between devices...................3
1.3 Use cases..................................................3
1.4 Motivation.................................................4
1.5 Terminology................................................4
INTERNET-DRAFT EAP Key Derivation June 2003
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................................8
3.3 Obtaining Keys.............................................8
4. Security Considerations........................................8
4.1 Key strength...............................................8
4.2 Cryptographic separation of keys...........................8
4.3 Implementation.............................................8
5. IANA Considerations............................................9
References........................................................9
Acknowledgments..................................................10
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, however it does define an Extended Master Session Key
(EMSK). This document describes how to use this key to derive keys
for specific applications.
1.1 Cryptographic separation between applications
Salowey and Eronen Expires December 2003 [Page 2]
INTERNET-DRAFT EAP Key Derivation June 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 December 2003 [Page 3]
INTERNET-DRAFT EAP Key Derivation June 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
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 December 2003 [Page 4]
INTERNET-DRAFT EAP Key Derivation June 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 derive the EMSK
o The key material used for the EMSK MUST be independent of the
backward-compatibility part (first 64 bytes) and TEKs.
o The EMSK MUST NOT be used for any other purpose than the key
derivation described in this document.
Salowey and Eronen Expires December 2003 [Page 5]
INTERNET-DRAFT EAP Key Derivation June 2003
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 MSK in any way it chooses. This is
required for backward compatibility. New applications following
this specification SHOULD NOT use the MSK.
o The application MUST NOT use the 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 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
their generated key stream as the MSK. One suggestion is to define
the EMSK as the next 64 bytes of the generated key stream. This may
not be possible for every mechanism so other techniques are possible.
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)
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
Salowey and Eronen Expires December 2003 [Page 6]
INTERNET-DRAFT EAP Key Derivation June 2003
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 P_SHA1 key
expansion PRF [RFC2246]. This 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)
PRF(secret, seed) = HMAC_hash(secret, A(1) + seed) +
HMAC_hash(secret, A(2) + seed) +
HMAC_hash(secret, A(3) + seed) + ...
Where
+ indicates concatenation.
Secret is EMSK
Seed = key label + "\0" + application data
A() is defined as:
A(0) = seed
A(i) = HMAC_hash(secret, A(i-1))
The P_SHA1 component of the TLS PRF was chosen over the TLS PRF
because it does not split the secret before processing. 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.
Salowey and Eronen Expires December 2003 [Page 7]
INTERNET-DRAFT EAP Key Derivation June 2003
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. Since
chaining requires an encapsulating method to control the EAP
communication it is this layer that is responsible for combining
keys. Since an EAP-Server may choose not to export the EMSK it is
recommended that the AMSKs be combined instead. In this case each
mechanism that generates keys must export the appropriate AMSKs. A
possible approach to combining AMSKs into a combined application
master session key is as follows:
EAP-CAMSK_0 = AMSK_0
EAP-CAMSK_n =
PRF(EAP-CAMSK_n-1 + AMSK_n, key-label, n)
3.3 Obtaining Keys
Implementations of EAP frameworks on the EAP-Peer and EAP-Server MUST
provide an interface to obtain AMSKs. The implementation MAY
restrict which callers can obtain which 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).
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 SHOULD 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.
Salowey and Eronen Expires December 2003 [Page 8]
INTERNET-DRAFT EAP Key Derivation June 2003
5. IANA Considerations
This specification introduces a new name space for "key labels". Key
labels are ASCII strings and are assigned on a first come first
served basis. It is RECOMMENDED that a referene to a specification
that provides the following information
o A description of the application
o The key label to be used
o How TSKs will be derived from the AMSK and how they will be used
o If application specific data is used, what it is and how it is
maintained
o Where the AMSKs or TSKs will be used and how they are
communicated if necessary.
References
[EAP]
Blunk, L., J. Vollbrecht, B. Aboba, J. Carlson, "Extensible
Authentication Protocol (EAP)", draft-ietf-eap-rfc2284bis-04,
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-06, December 2002 (work in progress).
[PRO-TLV]
Salowey, J., "Protected EAP TLV", draft-salowey-eap-
protectedtlv-02.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.
Salowey and Eronen Expires December 2003 [Page 9]
INTERNET-DRAFT EAP Key Derivation June 2003
[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
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 December 2003 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-24 01:15:08 |