One document matched: draft-salowey-eap-key-deriv-02.txt
Differences from draft-salowey-eap-key-deriv-01.txt
Network Working Group
INTERNET-DRAFT J. Salowey
Document: draft-salowey-eap-key-deriv-02.txt Cisco
P. Eronen
Nokia
Expires: June 2004 November 2003
Guidelines for using the EAP Extended Master Session Key (EMSK)
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. EAP defines an
Extended Master Session Key (EMSK) that is reserved. This document
provides guidelines for using the EMSK to avoid conflicts between
applications requiring different key material. 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..............3
1.2 Cryptographic separation between devices...................3
1.3 Use cases..................................................3
INTERNET-DRAFT EAP EMSK Usage Guidelines October 2003
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 AMSK Key Derivation Framework..............................6
3.1 The EAP AMSK Key Derivation Function.......................7
3.2 Naming the EMSK............................................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.............................................9
5. IANA Considerations............................................9
Normative References..............................................9
Informative References............................................9
Acknowledgments..................................................11
Author's Addresses...............................................11
Appendix A: Test vectors for KDF.................................11
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 provides guidelines on how to use this key to
derive keys for specific applications.
Salowey and Eronen Expires June 2004 [Page 2]
INTERNET-DRAFT EAP EMSK Usage Guidelines October 2003
1.1 Cryptographic separation between applications
If the keying material is used to provide keys for multiple
applications, it is desired that the keys will be cryptographically
separate. Cryptographic separation means that knowledge of one key
does not provide an easy way to determine another key derived from
the same key material. This is also known as computationally
independent.
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. Specifications such as
[802.11i] and [MPPE] specify such functions.
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 Not EAP methods. The methods should be independent of the
applications their keys will be used for.
o Not the application specifications. All applications would have
to know what other current and future applications could be used
together.
This document provides guidelines for a mechanism, which can be used
with existing and new EAP methods and applications to provide
cryptographic separation between applications.
1.2 Cryptographic separation between devices
A related issue is that the keys could be used by separate devices.
In this case, it is desirable that their knowledge is
cryptographically separate.
This implies that some key derivation must be done at the EAP server
instead of the authenticator and that authenticator should be sent
only keys derived that are derived for it. This means that the EAP
server has to know what the keys will be used for, which is a change
from the current practice.
This document attempts to specify a mechanism that allows the EAP
server to derive cryptographically separate keys from the EMSK
1.3 Use cases
There are several applications for ciphering keys outside of link
layer protection as in 802.11 already being defined. This
specification could derive keys to protect credentials distributed to
Salowey and Eronen Expires June 2004 [Page 3]
INTERNET-DRAFT EAP EMSK Usage Guidelines October 2003
an EAP peer in a protected TLV [PRO-TLV]. A recent proposals for
802.11 handoff in [I-D.irtf-aaaarch-handoff], [IEEE-02-758],[IEEE-03-
084], and [IEEE-03-155] provide examples where cryptographic
separation between different devices was required. To derive
cryptographically separate keys for different WLAN access points some
of the specifications specify the use of the EMSK.
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
A consumer of EAP keying material. Examples include link layer
encryption such as 802.11i encryption, MPPE, etc.
Master Session Key (MSK)
Salowey and Eronen Expires June 2004 [Page 4]
INTERNET-DRAFT EAP EMSK Usage Guidelines October 2003
Keying material exported by an EAP method. Usually sent to the
NAS.
Extended Master Session Key (EMSK)
Keying material exported by an EAP method for use in deriving keys
used by other applications.
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 derived from the EMSK for a particular application
as specified in this document. It is 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. This is also known as “computationally independent.”
2. Requirements for EAP methods and applications
2.1 Requirements for EAP methods
In order for an EAP method to meet the guidelines for EMSK usage 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
MSK and TEKs.
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.
Salowey and Eronen Expires June 2004 [Page 5]
INTERNET-DRAFT EAP EMSK Usage Guidelines October 2003
o The EMSK MSUT be maintained within the EAP server. Only keys
(AMSKs) derived according to this specification may be exported
from the EAP server.
o The EMSK MUST be unique for each session.
o The EAP mechanism SHOULD provide a way of naming the EMSK.
2.2 Requirements for EAP applications
In order for an application to meet the guidelines for EMSK usage it
must meet the following,
o The application MAY use the MSK transmitted to the NAS in any
way it chooses. This is required for backward compatibility. New
applications following this specification SHOULD NOT use the
MSK. If more than one application uses the MSK, then the
cryptographic separation is not achieved. Implementations SHOULD
prevent such combinations.
o The application MUST NOT use the EMSK in any other way except to
derive Application Master Session Keys (AMSK) using the key
derivation specified in section 3 this document. They MUST NOT
use the EMSK directly.
o Applications MUST define distinct key labels and application
specific data used in the key derivation described in section 3.
o Applications MUST define how they use their AMSK to derive TSKs
for their use.
3. EAP AMSK Key Derivation Framework
The EAP EMSK usage guidelines provide 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 EMSK usage guidelines AMSK key derivation function (KDF)
derives an AMSK from the Extended Master Session Key (EMSK) described
above, an application key label, optional application data, and
output length.
AMSK = KDF(EMSK, key label, optional application data, length)
Salowey and Eronen Expires June 2004 [Page 6]
INTERNET-DRAFT EAP EMSK Usage Guidelines October 2003
The key labels are printable ASCII strings unique for each
application (see Section 5 for IANA Considerations).
Additional ciphering keys (TSKs) can be derived from the AMSK using
an application specific key derivation mechanism. In many cases, this
AMSK->TSK derivation can simply split the AMSK to pieces of correct
length. In particular, it is not necessary to use a cryptographic
one-way function. Note that the length of the AMSK must be specified
by the application.
3.1 The EAP AMSK Key Derivation Function
The EAP key derivation function is taken from the PRF+ key expansion
PRF from [IKEv2]. This KDF takes 4 parameters as input: secret,
label, application data, and output length. It is only defined for
255 iterations so it may produce up to 5100 bytes of key 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, the application data is also described above and the output
length is two bytes. The application data is optional and may not be
used by some applications. The KDF is based on HMAC-SHA1 [RFC2104]
[SHA1]. For this specification we have:
KDF (K,L,D,O) = T1 | T2 | T3 | T4 | ...
where:
T1 = prf (K, S | 0x01)
T2 = prf (K, T1 | S | 0x02)
T3 = prf (K, T2 | S | 0x03)
T4 = prf (K, T3 | S | 0x04)
prf = HMAC-SHA1
K = EMSK
L = key label
D = application data
O = OutputLength (2 bytes)
S = L | "\0" | D | O
The prf+ construction was chosen because of its simplicity and
efficiency over other PRFs such as those used in [TLS]. The
motivation for the design of this PRF is described in [SIGMA].
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 June 2004 [Page 7]
INTERNET-DRAFT EAP EMSK Usage Guidelines October 2003
3.2 Naming the EMSK
The EAP mechanism should provide a name for the context that contains
the EMSK key material so it can be referenced if needed. If a name
is not provided by the mechanism, then a name may be derived from the
EMSK using the KDF defined above:
EMSK name = KDF(EMSK, "EAP-EMSK-Key name", "", 128 bits)
If the name needs to be represented as a string then it should be
converted to a lowercase ASCII representation of the hex values of
each byte.
<This needs a bit more analysis since the name will be public. If
the KDF is sound perhaps this shouldn’t lead to vulnerabilities, but
perhaps it would be better if the name somehow was not a static
function of the key. Salt perhaps?>
<Maybe this name should be broader than the EMSK, perhaps identifying
the whole EAP-MSK.>
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.
Salowey and Eronen Expires June 2004 [Page 8]
INTERNET-DRAFT EAP EMSK Usage Guidelines October 2003
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.
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 reference 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.
The String "EAP-EMSK-Key name" is reserved for key naming in section
3.2.
Normative References
[EAP]
Blunk, L., J. Vollbrecht, B. Aboba, J. Carlson, "Extensible
Authentication Protocol (EAP)", draft-ietf-eap-rfc2284bis-06,
September 2003 (work in progress).
[RFC2119]
Bradner, S., "Key words for use in RFCs to indicate
Requirement Levels", RFC 2119, March 1997.
[SHA1]
NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.
http://csrc.nist.gov/fips/fip180-1.txt (ascii)
http://csrc.nist.gov/fips/fip180-1.ps (postscript)
[RFC2104]
Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997.
Informative References
[IKEv2]
Salowey and Eronen Expires June 2004 [Page 9]
INTERNET-DRAFT EAP EMSK Usage Guidelines October 2003
C. Kaufman, "Internet Key Exchange (IKEv2) Protocol", <draft-
ietf-ipsec-ikev2-06.txt>, 2003
[SIGMA]
Krawczyk, H., "SIGMA: the `SIGn-and-MAc' Approach to
Authenticated Diffie-Hellman and its Use in the IKE
Protocols", in Advances in Cryptography - CRYPTO 2003
Proceedings, LNCS 2729, Springer, 2003. Available at:
http://www.ee.technion.ac.il/~hugo/sigma.html
[EAP-Key]
Aboba, B. et. al., "EAP Key Management Framework", draft-ietf-
eap-keying-00.txt, October 2003 (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.
[RFC2246]
Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[RFC2434]
Narten, T., and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434, October 1998.
[MPPE]
Zorn, G., "Deriving Keys for use with Microsoft-to-Point
Encryption (MPPE)", RFC 3079, March 2001.
[80211i]
Institute of Electrical and Electronics Engineers, "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", IEEE Draft 802.11I/
D6.1, August 2003.
Salowey and Eronen Expires June 2004 [Page 10]
INTERNET-DRAFT EAP EMSK Usage Guidelines October 2003
[I-D.irtf-aaaarch-handoff]
Arbaugh, W. and B. Aboba, "Experimental Handoff Extension to
RADIUS", draft-irtf-aaaarch-handoff-03 (work in progress),
October 2003.
[IEEE-03-155]
Aboba, B., "Fast Handoff Issues", IEEE 802.11 Working Group,
IEEE-03-155r0-I,
http://www.ieee802.org/11/Documents/DocumentHolder/3-155.zip,
March 2003.
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>
Salowey and Eronen Expires June 2004 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-23 20:17:24 |