One document matched: draft-aboba-pppext-key-problem-06.txt
Differences from draft-aboba-pppext-key-problem-05.txt
EAP Working Group Bernard Aboba
INTERNET-DRAFT Dan Simon
Category: Informational Microsoft
<draft-aboba-pppext-key-problem-06.txt>
2 March 2003
EAP Keying Framework
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet- Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document describes the framework for EAP key derivation, and
provides guidelines for generation and usage of EAP keys by EAP methods
and AAA protocols. Algorithms for key derivation or mechanisms for key
transport are not specified in this document. Rather, this document
provides a framework within which derivation algorithms and transport
mechanisms can be discussed and evaluated.
Aboba & Simon Informational [Page 1]
INTERNET-DRAFT EAP Keying Framework 2 March 2003
Table of Contents
1. Introduction .......................................... 3
1.1 Requirements language ........................... 3
1.2 Terminology ..................................... 4
2. EAP overview .......................................... 5
2.1 Invariants ...................................... 7
3. EAP key hierarchy ..................................... 8
3.1 Exchanges ....................................... 11
4. Security properties ................................... 14
4.1 EAP method requirements ......................... 14
4.2 AAA protocol requirements ....................... 17
4.3 TSK derivation requirements ..................... 18
4.4 Ciphersuite requirements ........................ 19
4.5 Security properties ............................. 19
5. Security considerations ............................... 21
5.1 Assumptions ..................................... 21
5.2 Key binding .................................... 22
5.3 Key strength .................................... 23
5.4 Key wrap ........................................ 23
5.5 Man-in-the-middle attacks ....................... 24
6. Normative references .................................. 24
7. Informative references ................................ 25
Appendix A - Ciphersuite independence ........................ 29
Appendix B - Ciphersuite keying requirements ................. 30
Appendix C - Example TEK hierarchy ........................... 31
Appendix D - Example MSK, EMSK and IV hierarchy .............. 32
Appendix E - Example TSK derivation .......................... 34
Appendix F - Example PMK derivation .......................... 35
Acknowledgments .............................................. 35
Author's Addresses ........................................... 35
Intellectual Property Statement .............................. 36
Full Copyright Statement ..................................... 36
Aboba & Simon Informational [Page 2]
INTERNET-DRAFT EAP Keying Framework 2 March 2003
1. Introduction
The Extensible Authentication Protocol (EAP), defined in [RFC2284bis],
was originally developed to provide extensible authentication for use
with PPP [RFC1661]. Since then, it has also been applied to IEEE 802
wired networks [IEEE8021X]. When EAP is used for authentication on PPP
or wired IEEE 802 networks, it is typically assumed that the link is
physically secure, so that an attacker cannot gain access to the link,
or insert a rogue device.
EAP methods defined in [RFC2284bis] reflect this usage model. These
include EAP MD5, as well as One-Time Password (OTP) and Generic Token
Card. These methods support one-way authentication (from EAP peer to
authenticator) but not mutual authentication or key derivation. As a
result, these methods do not bind the initial authentication and
subsequent data traffic, even when the the ciphersuite used to protect
data supports per-packet authentication and integrity protection. This
leaves these methods vulnerable to hijacking as well as attacks by rogue
devices.
On wireless networks such as IEEE 802.11 [IEEE80211], these attacks
become much easier to mount, since any attacker within range is capable
of accessing the wireless medium, or acting as an access point. As a
result, new ciphersuites have been proposed for use with wireless LANs
[IEEE80211i] which provide per-packet authentication, integrity and
replay protection. In addition, mutual authentication and key
derivation, provided by methods such as EAP TLS [RFC2716] are required
[IEEE80211i], so as to address the threat of rogue devices, and provide
keying material to bind the initial authentication to subsequent data
traffic.
Section 2 provides an overview of EAP. Section 3 describes the EAP key
hierarchy. Section 4 describes requirements and the resulting security
properties. Section 5 discusses additional security considerations.
Appendix A discusses the principle of ciphersuite independence. Appendix
B provides a summary of the keying requirements of link layer
ciphersuites supported on PPP and IEEE 802.11. Appendix C provides an
example EAP Master Key (MK) hierarchy. Appendix D provides an example
Master Session Key (MSK) hierarchy. Appendix E provides an example
Transient Session Key (TSK) derivation. Appendix F provides an example
of PMK derivation in Fast Handoff.
1.1. Requirements language
In this document, several words are used to signify the requirements of
the specification. These words are often capitalized. The key words
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD
Aboba & Simon Informational [Page 3]
INTERNET-DRAFT EAP Keying Framework 2 March 2003
NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in BCP 14 [RFC2119].
1.2. Terminology
This document frequently uses the following terms:
authenticator
The end of the EAP link initiating EAP authentication. Where no
backend authentication server is present, the authenticator acts as
the EAP server, terminating the EAP conversation with the peer.
Where a backend authentication server is present, the authenticator
MAY act as a pass-through for one or more authentication methods
and for non-local users. This terminology is also used in
[IEEE8021X], and has the same meaning in this document.
backend authentication server
A backend authentication server is an entity that provides an
authentication service to an authenticator. When used, this server
typically executes EAP Methods for the authenticator. This
terminology is also used in [IEEE8021X].
AN-Token
The package within which the Master Session Key (MSK) and one or
more attributes is transported between the backend authentication
server and the authenticator. The attributes provide the
authenticator with information on MSK usage. For example,
attributes might include the peer layer 2 address, the
authenticator layer 2 and IP addresses, the MSK lifetime, etc. The
format and wrapping of the AN-Token, which is intended to be
accessible only to the backend authentication server and
authenticator, is defined by the AAA key distribution
specification.
Cryptographic binding
The demonstration of the EAP peer to the EAP server that a single
entity has acted as the EAP peer for all methods executed within a
sequence or tunnel. Binding MAY also imply that the EAP server
demonstrates to the peer that a single entity has acted as the EAP
server for all methods executed within a sequence or tunnel. If
executed correctly, binding serves to mitigate man-in-the-middle
vulnerabilities.
Cryptographic separation
Two keys (x and y) are "cryptographically separate" if an adversary
that knows all messages exchanged in the protocol cannot compute x
from y or y from x without "breaking" some cryptographic
assumption. In particular, this definition allows that the
Aboba & Simon Informational [Page 4]
INTERNET-DRAFT EAP Keying Framework 2 March 2003
adversary has the knowledge of all nonces sent in cleartext as well
as all predictable counter values used in the protocol. Breaking a
cryptographic assumption would typically require inverting a one-
way function or predicting the outcome of a cryptographic pseudo-
random number generator without knowledge of the secret state. In
other words, if the keys are cryptographically separate, there is
no shortcut to compute x from y or y from x, but the work an
adversary must do to perform this computation is equivalent to
performing exhaustive search for the secret state value.
Key derivation
This refers to the ability of the EAP method to derive a Master Key
(MK) which is not exported, as well as a ciphersuite- independent
Master Session Key (MSK), Extended Master Session Key (EMSK) and
Initialization Vector (IV). The MSK, EMSK and IV are used only for
further key derivation, not directly for protection of the EAP
conversation or subsequent data.
Key strength
If the effective key strength is N bits, the best currently known
methods to recover the key (with non-negligible probability)
require an effort comparable to 2^N operations of a typical block
cipher.
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.
Mutual authentication
This refers to an EAP method in which, within an interlocked
exchange, the authenticator authenticates the peer and the peer
authenticates the authenticator. Two one-way conversations, running
in opposite directions do not provide mutual authentication as
defined here.
peer The end of the EAP Link that responds to the authenticator. In
[IEEE8021X], this end is known as the Supplicant.
2. EAP overview
The EAP authentication process involves a peer, authenticator and
(optionally) a backend authentication server. Typically, the peer
desires access to the network, and the authenticator is a Network Access
Server (NAS) providing that access. However, EAP may also be used in
other situations, such as when it is desired for two network devices
(e.g. two switches or routers) to authenticate each other. Since EAP is
Aboba & Simon Informational [Page 5]
INTERNET-DRAFT EAP Keying Framework 2 March 2003
a peer-to-peer protocol, an independent and simultaneous authentication
may take place in the reverse direction. Both peers may act as
authenticators and authenticatees at the same time.
An important goal of EAP is to enable deployment of new methods without
requiring development of new code on the authenticator. While the
authenticator may implement some EAP methods locally and use those
methods to authenticate local users, it may at the same time act as a
pass-through for other users and methods, forwarding EAP packets back
and forth between the backend authentication server and the peer.
EAP presumes that prior to initiation of authentication, the EAP peer
has located the authenticator, using an out-of-band mechanism. For
example, for use with PPP, the client might be configured with a phone
book providing phone numbers for accessing the selected service. For use
with IEEE 802.11 wireless LANs, the peer (a Station (STA) in IEEE 802.11
terminology) may locate an authenticator (an Access Point (AP) in IEEE
802.l1 terminology) using the IEEE 802.11 Beacon and Probe
Request/Response frames. Since service location is handled out of band,
this functionality is not provided within EAP.
EAP supports either one-way authentication (in which the peer
authenticates to the EAP server), or mutual authentication (in which the
peer and EAP server mutually authenticate). In either case, it can be
assumed that the parties do not enable the link unless their
authentication requirements have been met. For example, a peer
completing mutual authentication with an authenticator will not enable
its link until the authenticator has authenticated successfully to the
peer.
As described in Section 3, EAP methods MAY support derivation of keying
material used for purposes including protection of the EAP conversation
and subsequent data exchanges, man-in-the-middle detection, or fast
handoff. EAP methods supporting key derivation must also support mutual
authentication.
EAP assumes that ciphersuite negotiation, if it occurs, is handled out
of band. For example, the peer might be preconfigured with policy
indicating the ciphersuite to be used in communicating with a given
authenticator, or alternatively, the link layer protocol may support
ciphersuite negotiation. Within PPP, the ciphersuite is negotiated
within the Encryption Control Protocol (ECP), after EAP authentication
is completed. Within [IEEE80211i], the AP capabilities (including
ciphersuite) are advertised in the Beacon and Probe Responses, and are
securely verified during a 4-way exchange after EAP authentication has
completed. The desired ciphersuite is indicated within the
Association/Reassociation Request/Response exchange.
Aboba & Simon Informational [Page 6]
INTERNET-DRAFT EAP Keying Framework 2 March 2003
2.1. Invariants
Several basic principles govern the design of the EAP keying framework.
These are known as the "EAP Invariants":
Media independence
As described in [RFC2284bis], EAP authentication is supported on
lower layers, including PPP [RFC1661] and IEEE 802 wired networks
[IEEE8021X]. Use with IEEE 802.11 wireless LANs is also
contemplated [IEEE80211i]. Since EAP methods cannot be assumed to
have knowledge of the lower layer on which they are being run, EAP
methods MUST be designed to function on any lower layer meeting the
criteria outlined in [RFC2284bis], Section 3.1.
Ciphersuite independence
Since ciphersuite negotiation occurs out-of-band of EAP, and may
occur after EAP authentication and key derivation is complete, EAP
methods deriving keys MUST provide keying material that is
independent of the ciphersuite subsequently negotiated for
protection of data.
Since it is the peer and authenticator that negotiate and implement
the ciphersuite, knowledge of the ciphersuite is restricted to
those entities. The backend authentication server is not a party
to the ciphersuite negotiation nor is it an intermediary in the
data flow between the peer and authenticator. As a result, it
cannot be assumed to have knowledge of the ciphersuites implemented
by the peer and authenticator, to be aware of the ciphersuite
negotiated between them, or to implement ciphersuite-specific code.
Since the backend authentication server may not know the
ciphersuite negotiated between the peer and authenticator, it
cannot make this information available to a resident EAP method.
This means that ciphersuite-specific key generation, if implemented
within an EAP method, will not function correctly on every EAP
implementation. The advantages of ciphersuite independence are
discussed in Appendix A.
Method independence
Supporting pass-through of authentication to the backend
authentication server enables the authenticator to support any
authentication method implemented on the backend authentication
server and peer, not just locally implemented methods. This
implies that the authenticator need not implement code for each EAP
method required by authenticating peers; in fact the authenticator
is not required to implement any EAP methods at all, nor cannot it
be assumed to implement code specific to any EAP method.
Aboba & Simon Informational [Page 7]
INTERNET-DRAFT EAP Keying Framework 2 March 2003
This is useful where there is no single EAP method that is both
mandatory-to-implement and offers acceptable security for the media
in use. For example, the [RFC2284bis] mandatory-to-implement EAP
method (MD5-Challenge) does not provide dictionary attack
resistance, mutual authentication or key derivation, and as a
result is not appropriate for use with IEEE 802.11 wireless LANs.
3. EAP key hierarchy
The EAP keying hierarchy, illustrated in Figure 1, makes use of the
following types of keys:
EAP Master key (MK)
A key derived between the EAP client and server during the EAP
authentication process that is purely local to the EAP method. The
MK MUST NOT be exported from the EAP method or be made available to
a third party. Since derivation of the MK is a residue of the
successful completion of the EAP authentication exchange, proof of
MK possession may be used to shorten future EAP exchanges between
the same EAP client and server, a technique known as "fast resume".
Master Session Key (MSK)
Keying material (64 octets) that is derived between the EAP client
and server. The MSK is used in the derivation of Transient Session
Keys (TSKs) for the ciphersuite negotiated between the EAP peer and
authenticator. Where a backend authentication server is present,
acting as an EAP server, it will typically transport the MSK to the
authenticator.
The MSK differs from the MK in that it not assumed to remain local
to the EAP method, and is known by all parties in the EAP exchange:
the peer, authenticator and the authentication server (if present).
The MSK MAY be derived from the MK via a one-way function, or it
may be an independent quantity. However possession of the MSK MUST
NOT provide any information useful in determining the MK. An
example, MSK, EMSK and IV key derivation is given in Appendix D.
Extended Master Session Key (EMSK)
Additional keying material (64 octets) derived between the EAP
client and server that is not assumed to remain local to the EAP
method. However, unlike the MSK, the EMSK is known only to the EAP
client and server and MUST NOT be provided to a third party. The
EMSK therefore MUST NOT be transported by the backend
authentication server to the authenticator. The EMSK is reserved
for future uses that are not defined yet. For example, it could be
used to derive additional keying material for purposes such as fast
handoff, man-in-the-middle vulnerability protection, etc. An
example of fast handoff key derivation is given in Appendix F.
Aboba & Simon Informational [Page 8]
INTERNET-DRAFT EAP Keying Framework 2 March 2003
Initialization Vector (IV)
A 64 octet quantity suitable for use in an initialization vector
field, that is derived between the EAP client and server. Since in
some EAP methods such as [RFC2716] the IV is a known value, the IV
MUST NOT be used in computation of any quantity that needs to
remain secret.
Pairwise Master Key (PMK)
In [RFC2716], the MSK is divided into two halves, corresponding to
the "Peer to Authenticator Encryption Key" (Enc-RECV-Key, 32
octets) and "Authenticator to Peer Encryption Key" (Enc-SEND-Key,
32 octets) (reception is defined from the point of view of the
authenticator). Within [IEEE80211i] Octets 0-31 of the MSK (Enc-
RECV-Key) are also known as the Pairwise Master Key (PMK).
[IEEE80211i] ciphersuites derive their Transient Session Keys
(TSKs) solely from the PMK, whereas the WEP ciphersuite, when used
with [IEEE8021X], as noted in [Congdon], derives its TSKs from both
halves of the MSK, the Enc-RECV-Key and the Enc-SEND-Key.
Transient EAP Keys (TEKs)
Session keys which are used to establish a protected channel
between the EAP peer and server during the EAP authentication
exchange. The TEKs are typically derived from the MK, and are
appropriate for use with the ciphersuite negotiated between EAP
peer and server as part the EAP authentication exchange. Note that
the ciphersuite used to set up the protected channel between the
EAP peer and server during EAP authentication is unrelated to the
ciphersuite used to subsequently protect data sent between the EAP
peer and authenticator. In particular, the TEKs used to protect
the EAP exchange MUST be cryptographically separate from TSKs used
to protect data. An example TEK key hierarchy is described in
Appendix C.
Transient Session Keys (TSKs)
Session keys used to protect data which are appropriate for the
ciphersuite negotiated between the EAP peer and authenticator. The
TSKs are derived from the MSK by a process which is link layer
specific. In the case of IEEE 802.11, TSK derivation is supported
via a 4-way handshake that supports mutual authentication between
the EAP peer and authenticator. The 4-handshake also confirms
mutual possession of the PMK as well as supporting protected
ciphersuite negotiation. An example TSK derivation is given in
Appendix E.
Aboba & Simon Informational [Page 9]
INTERNET-DRAFT EAP Keying Framework 2 March 2003
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | ^
| EAP Method | |
| | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | | | |
| | | | |
| | | | |
| | EAP Master Key (MK) | | |
| | Derivation | | |
| | | | Local to |
| | | | EAP |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Method |
| | | | | |
| | | |
| | MK | | | |
| | | |
| V | | | |
| +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | |
| | TEK | | MSK | |EMSK | |IV | | |
| |Derivation | |Derivation | |Derivation | |Derivation | | |
| +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | |
| | | | | |
| | | | | V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | | ^
| | | |
| MSK (64B) | EMSK (64B) | IV (64B) |
| | | Exported|
| | | by |
| V V EAP |
| +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ Method|
| | Reserved | | Known | |
| | | |(Not Secret) | |
| +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ V
| ---+
| Transported |
| by AAA |
| Protocol |
V V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | ^
| TSK | Ciphersuite |
| Derivation | Specific |
| | V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
Figure 1 - EAP Key Hierarchy
Aboba & Simon Informational [Page 10]
INTERNET-DRAFT EAP Keying Framework 2 March 2003
3.1. Exchanges
Figure 2 illustrates the EAP exchange in the case where no backend
authentication server is present. Here EAP is spoken between the peer
and authenticator, encapsulated within a lower layer protocol, such as
PPP, defined in [RFC1661] and IEEE 802, defined in [IEEE802]. Since the
authenticator acts as an endpoint of the EAP conversation rather than a
pass-through, EAP methods are implemented on the authenticator as well
as the peer. If the EAP method negotiated between the EAP peer and
authenticator supports mutual authentication and key derivation, an EAP
Master Key (MK) is derived on the EAP peer and authenticator and stored
locally within the EAP method. The MK may then be used to derive
Transient EAP Keys (TEKs) used to protect some or all of the EAP
exchange. The TEKs are also stored locally within the EAP method and are
not exported.
Once mutual authentication completes and is successful, the peer and
authenticator exchange data, which may be protected using a ciphersuite.
In order to provide keys for the ciphersuite, Transient Session Keys
(TSKs) are required. On completion of a successful authentication, EAP
methods on the peer and authenticator export the Master Session Key
(MSK), Extended Master Session Key (EMSK) and IV. Of these quantities,
only the MSK is used today, for derivation of the TSKs. The mechanism
for this is specific to the ciphersuite; for example, in [IEEE80211i],
the 4-way handshake is used.
Where no backend authentication server is present, the MSK and EMSK are
known only to the peer and authenticator and neither is transported to a
third party. As demonstrated in [RoamCERT], despite the absence of a
backend authentication server, such exchanges can support roaming
between providers; it is even possible to support fast handoff
[IEEE80211f] without re-authentication. However, this is typically only
possible where both the EAP peer and authenticator support certificate-
based authentication, or where the user base is sufficiently small that
EAP authentication can occur locally.
Where these conditions cannot be met, a backend authentication server is
typically required. In this exchange, as described in [RFC2869bis], the
authenticator acts as a pass-through between the EAP peer and a backend
authentication server. In this model, the authenticator delegates the
access control decision to the backend authentication server, which acts
as a Key Distribution Center (KDC), supplying keying material to both
the EAP peer and authenticator.
Aboba & Simon Informational [Page 11]
INTERNET-DRAFT EAP Keying Framework 2 March 2003
+-+-+-+-+-+ +-+-+-+-+-+
| | | |
| | | |
| Cipher- | | Cipher- |
| Suite | | Suite |
| | | |
+-+-+-+-+-+ +-+-+-+-+-+
^ ^
| |
| |
| |
V V
+-+-+-+-+-+ +-+-+-+-+-+
| | | |
| |===============| |
| |EAP, TEK Deriv.|Authenti-|
| |<------------->| cator |
| | | |
| | TSK Deriv. | |
| peer |<------------->| (EAP |
| |===============| server) |
| | Link layer | |
| | (PPP,IEEE802) | |
| | | |
|MSK,EMSK | |MSK,EMSK |
| (TSKs) | | (TSKs) |
| | | |
+-+-+-+-+-+ +-+-+-+-+-+
^ ^
| |
| MSK, EMSK, IV | MSK, EMSK, IV
| |
| |
+-+-+-+-+-+ +-+-+-+-+-+
| | | |
| EAP | | EAP |
| Method | | Method |
| | | |
|(MK,TEKs)| |(MK,TEKs)|
| | | |
+-+-+-+-+-+ +-+-+-+-+-+
Figure 2 - Relationship between EAP peer and authenticator
(acting as an EAP server), where no backend
authentication server is present.
Aboba & Simon Informational [Page 12]
INTERNET-DRAFT EAP Keying Framework 2 March 2003
+-+-+-+-+-+ +-+-+-+-+-+
| | | |
| | | |
| Cipher- | | Cipher- |
| Suite | | Suite |
| | | |
+-+-+-+-+-+ +-+-+-+-+-+
^ ^
| |
| |
| |
V V
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
| |===============| |========| |
| |EAP, TEK Deriv.| | | |
| |<-------------------------------->| backend |
| | | | | |
| | TSK Deriv. | | MSK | |
| peer |<------------->|Authenti-|<-------| auth |
| |===============| cator |========| server |
| | Link Layer | | AAA | (EAP |
| | (PPP,IEEE 802)| |Protocol| server) |
| | | | | |
|MSK,EMSK | | MSK | |MSK,EMSK |
| (TSKs) | | (TSKs) | | |
| | | | | |
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
^ ^
| |
| MSK, EMSK, IV | MSK, EMSK, IV
| |
| |
+-+-+-+-+-+ +-+-+-+-+-+
| | | |
| EAP | | EAP |
| Method | | Method |
| | | |
|(MK,TEKs)| |(MK,TEKs)|
| | | |
+-+-+-+-+-+ +-+-+-+-+-+
Figure 3 - Pass-through relationship between EAP peer,
authenticator and backend authentication server.
Aboba & Simon Informational [Page 13]
INTERNET-DRAFT EAP Keying Framework 2 March 2003
Figure 3 illustrates the EAP authentication process in the case where
the authenticator acts as a pass-through. Here EAP is spoken between
the peer and authenticator as before. The authenticator then
encapsulates EAP packets within a AAA protocol such as RADIUS
[RFC2869bis] or Diameter [DiamEAP], and forwards packets to and from the
backend authentication server, which acts as the EAP server. Since the
authenticator acts as a pass-through, EAP methods (as well as the
derived EAP Master Key, and TEKs) reside only on the peer and backend
authentication server.
Once mutual authentication completes and is successful, the EAP method
present on the peer and authenticator export the MSK, EMSK and IV. The
backend authentication server then sends a message to the authenticator
indicating that authentication has been successful, providing the MSK
within a protected package known as the AN-Token. Along with the MSK,
the AN-Token contains attributes indicating the parameters of key usage.
The MSK is then used by the authenticator and peer to derive Transient
Session Keys (TSKs) required for the negotiated ciphersuite.
The TSKs are known only to the peer and authenticator, and as noted
earlier, the TSK derivation process varies by ciphersuite. For example,
within the 4-way handshake described in [IEEE80211i], the peer and
authenticator confirm mutual possession of the MSK, demonstrate
liveness, and do a protected ciphersuite and capabilities negotiation.
4. Security properties
This section describes the security requirements for EAP methods, AAA
protocols, TSK derivation mechanisms and Ciphersuites. These
requirements MUST be met by specifications requesting publication as an
RFC. Based on these requirements, the security properties of EAP
exchanges are analyzed.
4.1. EAP method requirements
Mutual authentication
Methods deriving keys MUST support mutual authentication.
Master Key
Methods deriving keys MUST support derivation of the EAP Master Key
(MK), as well as specifying how Transient EAP Keys (TEKs) are
derived from the MK.
The MK is the root of the EAP key hierarchy. As a result,
compromise of MK must be avoided if at all possible, since an
attacker in possession of the MK will be able to derive all the
other keys in the hierarchy. This would provide an attacker with
the ability not only to decrypt and insert data sent between a
Aboba & Simon Informational [Page 14]
INTERNET-DRAFT EAP Keying Framework 2 March 2003
particular EAP peer and authenticator, but also potentially to
decrypt future data as well and to subsequently access the network
using authentication mechanisms such as fast resume or fast
handoff.
Since the MK is known only to the EAP peer and server, and only
mutually authenticating EAP methods may distribute keys, possession
of the MK is proof of a completed mutual authentication. In order
to protect against compromise of the MK, which could be used to
impersonate the EAP peer or server the MK and TEKs MUST remain
local to the EAP method and MUST NOT be provided to third parties.
In addition, the MK MUST NOT be derivable from material exported
from the EAP method, such as the MSK, EMSK or IV. The MK MUST NOT
be directly used to protect data; rather the TEKs and TSKs are used
for this purpose.
MSK, EMSK and IV
EAP methods supporting key derivation MUST export two 64 octet
quantities, known as the Master Session Key (MSK), and the Extended
Master Session Key (EMSK) and MAY export a 64 octet quantity known
as the IV. It must be demonstrated that possession of the MSK, EMSK
or IV does not provide information useful in determining the MK.
Cryptographic separation
Methods supporting key derivation MUST demonstrate cryptographic
separation between the TEK, MSK, EMSK and IV branches of the EAP
key hierarchy. Without violating a fundamental cryptographic
assumption (such as the non-invertibility of a one-way function) an
attacker recovering the TEK, MSK, EMSK or IV MUST NOT be able to
recover the other quantities with a level of effort less than brute
force. Since Transient Session Keys (TSKs) are derived from the
MSK, if branch independence holds, then it is also true that the
TSKs are cryptographically separate from the EMSK, IV and TEKs.
EMSK reservation
While the EMSK is exported by the EAP method, its use is reserved,
and as a result it MUST remain known only to the EAP peer and
server and MUST NOT be provided to third parties. Since the EMSK is
the only keying material exported by an EAP method that is neither
provided to a third party nor a known quantity, it is attractive
for use in future applications such as fast handoff or man-in-the-
middle detection. Given its potential future uses, damage due to
EMSK compromise is second only in effect to compromise of the MK,
yielding an attacker the ability to access the network at will, and
to decrypt past and future data traffic.
Ciphersuite Independence
The MK, MSK, EMSK and IV derivations MUST be independent of the
Aboba & Simon Informational [Page 15]
INTERNET-DRAFT EAP Keying Framework 2 March 2003
selected ciphersuite.
Key Strength
The strength of Transient Session Keys (TSKs) and Transient EAP
Keys (TEKs) used to protect data is ultimately dependent on the
strength of the MK, MSK and EMSK generated by the EAP method. If
EAP method does not produce an MK, MSK and EMSK of sufficient
strength, then the TSKs and TEKs may be subject to brute force
attack. EAP methods supporting key derivation MUST be capable of
generating a MK, MSK and EMSK, each with an effective key strength
of at least 128 bits. More details on key strength are provided in
Section 5.3.
Perfect Forward Secrecy
An EAP peer and server may simultaneously derive MSKs suitable for
use with several authenticators, so as to enable fast handoff
between them. Similarly an EAP server may transport MSKs to
multiple authenticators as the result of a single authentication.
Where no backend authentication server is present, transport
typically occurs via an Inter-Access Point Protocol (IAPP), such as
[IEEE80211f]. Where a backend authentication server is present, key
transport is provided by the AAA protocol, such as Diameter
[DiamEAP] or RADIUS [RFC2869bis]. Key wrap mechanisms for Diameter
are specified in [DIAMCMS], and for RADIUS in [RFC2548].
In order to protect against compromise of an individual MSK,
Perfect Forward Secrecy (PFS) SHOULD be supported, so that
compromise of one MSK does not enable compromise of subsequent or
prior MSKs.
Uniqueness
In order to assure non-repetition of TSKs even in cases where one
party may not have a high quality random number generator, the MSK
derivation SHOULD include a two-way nonce exchange, using nonces of
at least 128-bits. Note although the [IEEE80211i] 4-way handshake
includes a nonce exchange, this is not the case for all
ciphersuites and media, so that to provide media independence, an
EAP method cannot assume that a nonce exchange is guaranteed to
occur as part of TSK derivation. A nonce exchange SHOULD also be
included in the derivation of the TEKs from the MK.
Known-good algorithms
The development and validation of key derivation algorithms is
difficult, and as a result EAP methods SHOULD reuse existing key
derivation algorithms, rather than inventing new ones. EAP methods
requesting publication as an RFC MUST provide citations to
literature justifying the security of the chosen algorithms. EAP
methods SHOULD utilize well established and analyzed mechanisms for
Aboba & Simon Informational [Page 16]
INTERNET-DRAFT EAP Keying Framework 2 March 2003
MK, MSK, EMSK and IV derivation.
4.2. AAA protocol requirements
AAA protocols suitable for use in transporting EAP MUST provide the
following facilities:
Security services
AAA protocols used for transport of EAP MUST support per-packet
integrity and authentication and SHOULD support replay protection
and confidentiality. These requirements are met by Diameter EAP
[DiamEAP], as well as RADIUS over IPsec [RFC2869bis].
Session Keys
AAA protocols used for transport of EAP SHOULD provide per-packet
security services using session keys, as in Diameter EAP [DiamEAP]
and RADIUS over IPsec [RFC3162], rather than using a static key, as
in RADIUS [RFC2865].
Mutual authentication
AAA protocols used for transport of EAP MUST support mutual
authentication between the authenticator and backend authentication
server. These requirements are met by Diameter EAP [DiamEAP] as
well as by RADIUS [RFC2865].
Forgery protection
AAA protocols used for transport of EAP SHOULD provide protection
against rogue authenticators masquerading as other authenticators.
This can be accomplished, for example, by requiring that AAA agents
to check the source address of packets against the origin
attributes (Origin-Host AVP in Diameter, NAS-IP-Address, NAS-
IPv6-Address, NAS-Identifier in RADIUS).
MSKs vs. TSKs
Since EAP methods do not export Transient Session Keys (TSKs) in
order to maintain media and ciphersuite independence, the AAA
protocol MUST NOT transport TSKs from the backend authentication
server to authenticator.
Key transport specification
In order to enable backend authentication servers to provide keying
material to the authenticator in a well defined format, AAA
protocols suitable for use with EAP MUST define the format and
wrapping of the package within which the MSK is transported, known
as the AN-Token. The definition of the AN-Token MUST include the
definition of attributes binding the key to the appropriate
session, and providing limitations on key usage, such as the
indicated key lifetime.
Aboba & Simon Informational [Page 17]
INTERNET-DRAFT EAP Keying Framework 2 March 2003
EMSK exposure
Since the EMSK is a secret known only to the backend authentication
server and peer, the AAA protocol MUST NOT transport the EMSK from
the backend authentication server to the authenticator.
AN-Token protection
To ensure against compromise, the AN-Token MUST be integrity
protected, authenticated, replay protected and encrypted in
transit, using well-established cryptographic algorithms. For
example, the AN-Token SHOULD be protected with session keys as in
Diameter CMS Security [DiamCMS] (a work in progress) or RADIUS over
IPsec [RFC2869bis] rather than static keys, as in [RFC2548].
Where untrusted intermediaries are present, the AN-Token SHOULD be
protected by data object security mechanisms, such as Diameter CMS
Security [DiamCMS] (a work in progress).
4.3. TSK derivation requirements
The Transient Session Key (TSK) derivation process is assumed to provide
for the following:
Direct operation
The TSK derivation process MUST operate directly between the peer
and authenticator, and MUST NOT be passed-through to the backend
authentication server.
Mutual authentication
Where EAP is used on link layers which cannot be assumed to be
physically secure (e.g. wireless, the Internet), the TSK
derivation process MUST provide for mutual authentication between
the authenticator and peer.
Protected negotiation
Where EAP is used on link layers which cannot be assumed to be
physically secure (e.g. wireless, the Internet), the TSK derivation
process SHOULD support protected ciphersuite and capabilities
negotiation.
Uniqueness
Where MSKs may be cached on the authenticator and peer, the TSK
derivation process MUST provide unique TSKs for each session, even
where the MSK is unchanged.
Aboba & Simon Informational [Page 18]
INTERNET-DRAFT EAP Keying Framework 2 March 2003
4.4. Ciphersuite requirements
Ciphersuites suitable for keying by EAP methods MUST provide the
following facilities:
TSK derivation
In order to key a ciphersuite with EAP, it is necessary to specify
how the TSKs required by the ciphersuite are derived from the MSK.
Derivation of the TSKs from the MSK requires knowledge of the
negotiated ciphersuite.
TEK derivation
In order to establish a protected channel between the EAP peer and
server as part of the EAP exchange, a ciphersuite needs to be
negotiated and keyed, using TEKs derived from the MK. The
ciphersuite used to protect the EAP exchange between the peer and
server is distinct from the ciphersuite negotiated between the peer
and authenticator, used to protect data. Where a protected channel
is established within the EAP method, the method specification MUST
specify the mechanism by which the EAP ciphersuite is negotiated,
as well as the algorithms for derivation of TEKs from the MK during
the EAP authentication exchange.
EAP method independence
Algorithms for deriving TSKs from the MSK MUST NOT depend on the
EAP method. However, algorithms for deriving TEKs from the MK MAY
be specific to the EAP method.
Cryptographic separation
The TSKs derived from the MSK MUST be cryptographically separate
from each other. Similarly, TEKs MUST be cryptographically separate
from each other. In addition, the TSKs MUST be cryptographically
separate from the TEKs.
4.5. Security properties
Given the requirements described in the previous sections, Figure 4
illustrates the relationship between the peer, authenticator and backend
authentication server.
As noted in the figure, each party in the exchange mutually
authenticates with each of the other parties, and derives a unique key.
All parties in the diagram have access to the MSK.
Aboba & Simon Informational [Page 19]
INTERNET-DRAFT EAP Keying Framework 2 March 2003
EAP peer
/\
/ \
Protocol: EAP / \ Protocol: TSK derivation
Auth: Mutual / \ Auth: Mutual
Unique keys: MK, / \ Unique keys: TSKs
TEKs,EMSK / \
/ \
Auth. server +--------------+ Authenticator
Protocol: AAA
Auth: Mutual
Unique key: AAA session key
Figure 4: Three-party EAP key distribution
The EAP peer and backend authentication server mutually authenticate via
the EAP method, and derive the MK, TEKs and EMSK which are known only to
them. The TEKs are used to protect some or all of the EAP conversation
between the peer and authenticator, so as to guard against modification
or insertion of EAP packets by an attacker. The degree of protection
afforded by the TEKs is determined by the EAP method; some methods may
protect the entire EAP packet, including the EAP header, while other
methods may only protect the contents of the Type-Data field, defined in
[RFC2284bis].
Since EAP is spoken only between the peer and server, if a backend
authentication server is present then the EAP conversation does not
provide mutual authentication between the peer and authenticator, only
between the peer and backend authentication server. As a result, mutual
authentication between the peer and authenticator only occurs where a
separate TSK derivation step is carried out, such as in [IEEE80211i].
This means that absent the TSK derivation step, from the point of view
of the peer, EAP mutual authentication only proves that the
authenticator is trusted by the backend authentication server; the
identity of the authenticator is not confirmed.
Utilizing the AAA protocol, the authenticator and backend authentication
server mutually authenticate and derive session keys known only to them,
used to provide per-packet integrity and replay protection,
authentication and confidentiality. The MSK is distributed by the
backend authentication server to the authenticator over this channel,
bound to attributes constraining its usage, as part of the AN-Token. The
binding of attributes to the MSK within a protected package is important
so the authenticator receiving the AN-Token can determine that it has
not been compromised, and that the keying material has not been
replayed, or mis-directed in some way.
Aboba & Simon Informational [Page 20]
INTERNET-DRAFT EAP Keying Framework 2 March 2003
Assuming that the AAA protocol provides protection against rogue
authenticators forging their identity, then the AN-Token can be assumed
to be sent to the correct authenticator, and where it is wrapped
appropriately, it can be assumed to be immune to compromise by a
snooping attacker.
Where an untrusted AAA intermediary is present, data object security
SHOULD be used to encrypt, authenticate, integrity and replay protect
the AN-Token, so that it cannot be compromised or modified by the
intermediary.
The TSK derivation step varies by ciphersuite. On link layers that
cannot be assumed to be physically secure, the peer and authenticator
SHOULD mutually authenticate by proving mutual possession of all or a
portion of the MSK. It is also advisable for the TSK derivation step to
support protected ciphersuite and capabilities negotiation, and derive
TSKs which are guaranteed to be unique for each session. This provides
assurance to the peer that it is connecting to the correct
authenticator, that the capabilities and offered ciphersuites have not
been forged, and that the TSKs are fresh.
5. Security considerations
5.1. Assumptions
The security properties of the EAP exchange are dependent on each leg of
the triangle: the selected EAP method, AAA protocol and TSK derivation
mechanism.
If the selected EAP method does not support mutual authentication, then
the peer will be vulnerable to attack by rogue authenticators and
backend authentication servers. If the EAP method does not derive keys,
then TSKs will not be available for use with a negotiated ciphersuite,
and there will be no binding between the initial EAP authentication and
subsequent data traffic, leaving the session vulnerable to hijack.
If the authenticator and backend authentication server do not mutually
authenticate, then the peer will be vulnerable to rogue backend
authentication servers, authenticators, or both. If there is no per-
packet authentication, integrity and replay protection between the
authenticator and backend authentication server, then an attacker can
spoof or modify packets in transit. If the backend authentication
server does not protect against authenticator masquerade, or provide the
proper binding of the MSK to the session within the AN-Token, then one
or more MSKs may be sent to an unauthorized party, and an attacker may
be able to gain access to the network. If the AN-Token is not opaque to
an untrusted AAA intermediary, then that intermediary may be able to
modify the MSK, or the attributes associated with it, as described in
Aboba & Simon Informational [Page 21]
INTERNET-DRAFT EAP Keying Framework 2 March 2003
[RFC2607].
If the TSK derivation algorithm does not support mutual authentication,
then the peer will not have assurance that it is connected to the
correct authenticator, only that the authenticator and backend
authentication server share a trust relationship (assuming that the AAA
protocol supports mutual authentication). This distinction can become
important when multiple authenticators receive MSKs from the backend
authentication server, such as where fast handoff is supported. If the
TSK derivation does not provide for protected ciphersuite and
capabilities negotiation, then downgrade attacks are possible.
5.2. Key binding
Both the RADIUS and Diameter protocols are potentially vulnerable to
impersonation by a rogue authenticator.
When RADIUS requests are forwarded by a proxy, the NAS-IP-Address or
NAS-IPv6-Address attributes may not correspond to the source address.
Since the NAS-Identifier attribute need not contain an FQDN, it also may
not correspond to the source address, even indirectly. [RFC2865]
Section 3 states:
A RADIUS server MUST use the source IP address of the RADIUS
UDP packet to decide which shared secret to use, so that
RADIUS requests can be proxied.
This implies that it is possible for a rogue authenticator to forge NAS-
IP-Address, NAS-IPv6-Address or NAS-Identifier attributes within a
RADIUS Access-Request in order to impersonate another authenticator.
Among other things, this can result in messages (and MSKs) being sent to
the wrong authenticator. Since the rogue authenticator is authenticated
by the RADIUS proxy or server purely based on the source address, other
mechanisms are required to detect the forgery. In addition, it is
possible for attributes such as the Called-Station-Id and Calling-
Station-Id to be forged as well.
As recommended in [RFC2869bis], this vulnerability can be mitigated by
having RADIUS proxies check authenticator identification attributes
against the source address.
To allow verification of session parameters such as the Called-Station-
Id and Calling-Station-Id, they can be sent by the EAP peer to the
server, and protected by TEKs. The RADIUS server can then check the
parameters sent by the EAP peer against those claimed by the
authenticator. If a discrepancy is found, an error can be logged.
While [DiamBASE] requires use of the Route-Record AVP, this utilizes
Aboba & Simon Informational [Page 22]
INTERNET-DRAFT EAP Keying Framework 2 March 2003
FQDNs, so that impersonation detection requires DNS A/AAAA and PTR RRs
to be properly configured. As a result, it appears that Diameter is as
vulnerable to this attack as RADIUS, if not more so.
To address this vulnerability, it is necessary to utilize data object
security to protect the AN-Token, and allow the backend authentication
server to authenticate the authenticator directly. This requires the
authenticator to provide proof of its identity, ensuring that the MSK is
being provided to the correct entity.
5.3. Key strength
In order to guard against brute force attacks, EAP methods deriving keys
need to be capable of generating an MK, MSK and EMSK with an appropriate
effective symmetric key strength. In order to ensure that key generation
is not the weakest link, it is necessary for EAP methods utilizing
public key cryptography to choose a public key that has a cryptographic
strength meeting the symmetric key strength requirement.
As noted in Section 5 of [KeyLen], this results in the following
required RSA or DH module and DSA subgroup size in bits, for a given
level of attack resistance in bits:
Attack Resistance RSA or DH Modulus DSA subgroup
(bits) size (bits) size (bits)
----------------- ----------------- ------------
70 947 128
80 1228 145
90 1553 153
100 1926 184
150 4575 279
200 8719 373
250 14596 475
5.4. Key wrap
As described in [RFC2869bis], Section 4.3, known problems exist in the
key wrap specified in [RFC2548]. Where the same RADIUS shared secret is
used by a PAP authenticator and an EAP authenticator, there is a
vulnerability to known plaintext attack. Since RADIUS uses the shared
secret for multiple purposes, including per-packet authentication,
attribute hiding, considerable information is exposed about the shared
secret with each packet. This exposes the shared secret to dictionary
attacks. MD5 is used both to compute the RADIUS Response Authenticator
and the Message-Authenticator attribute, and some concerns exist
relating to the security of this hash [MD5Attack]. As discussed in
[RFC2869bis], Section 4.2, these and other RADIUS vulnerabilities may be
addressed by running RADIUS over IPsec.
Aboba & Simon Informational [Page 23]
INTERNET-DRAFT EAP Keying Framework 2 March 2003
Where an untrusted AAA intermediary is present (such as a RADIUS proxy
or a Diameter agent), and data object security is not used, the MSK may
be recovered by an attacker in control of the untrusted intermediary.
Possession of the MSK enables decryption of data traffic sent between
the peer and a specific authenticator; however where Perfect Forward
Secrecy (PFS) is implemented, compromise of the MSK does enable an
attacker to impersonate the peer to another authenticator, since that
requires possession of the MK or EMSK, which are not transported by the
AAA protocol. This vulnerability may be mitigated by implementation of
data object security techniques such as [DiamCMS], a work in progress.
5.5. Man-in-the-middle attacks
As described in [MiTM], EAP method sequences and compound authentication
mechanisms may be subject to man-in-the-middle attacks. When such
attacks are successfully carried out, the attacker acts as an
intermediary between a victim and a legitimate authenticator. This
allows the attacker to authenticate successfully to the authenticator,
as well as to obtain access to the network.
In order to prevent these attacks, [MiTM] recommends derivation of a
compound key by which the EAP peer and authenticator can prove that they
have participated in the entire EAP exchange. Since the compound key
must not be known to an attacker posing as an authenticator, and yet
must be derived from quantities that are exported by EAP methods, it may
be desirable to derive the compound key from a portion of the EMSK. In
order to provide proper key hygiene, it is recommended that the compound
key used for man-in-the-middle protection be cryptographically separate
from other keys derived from the EMSK, such as fast handoff keys,
discussed in Appendix F.
6. Normative References
[RFC1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)",
STD 51, RFC 1661, July 1994.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2284bis] Blunk, L., Vollbrecht, J., Aboba, B., "Extensible
Authentication Protocol (EAP)", Internet draft (work in
progress), draft-ietf-pppext-rfc2284bis-08.txt, December
2002.
Aboba & Simon Informational [Page 24]
INTERNET-DRAFT EAP Keying Framework 2 March 2003
[IEEE802] IEEE Standards for Local and Metropolitan Area Networks:
Overview and Architecture, ANSI/IEEE Std 802, 1990.
[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.
[IEEE8021X] IEEE Standards for Local and Metropolitan Area Networks:
Port based Network Access Control, IEEE Std 802.1X-2001,
June 2002.
7. Informative References
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[RFC1968] Meyer, G., "The PPP Encryption Protocol (ECP)", RFC 1968,
June 1996.
[RFC2104] Krawczyk, et al, "HMAC: Keyed-Hashing for Message
Authentication", RFC 2104, February 1997.
[RFC2246] Dierks, T. and Allen, C. "The TLS Protocol Version 1.0",
RFC 2246, November 1998.
[RFC2409] Harkins, D., Carrel, D., "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2419] Sklower, K., Meyer, G., "The PPP DES Encryption Protocol,
Version 2 (DESE-bis)", RFC 2419, September 1998.
[RFC2420] Hummert, K., "The PPP Triple-DES Encryption Protocol
(3DESE)", RFC 2420, September 1998.
[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2548] Zorn, G., "Microsoft Vendor-Specific RADIUS Attributes",
RFC 2548, March 1999.
[RFC2607] Aboba, B., Vollbrecht, J., "Proxy Chaining and Policy
Implementation in Roaming", RFC 2607, June 1999.
Aboba & Simon Informational [Page 25]
INTERNET-DRAFT EAP Keying Framework 2 March 2003
[RFC2716] Aboba, B., Simon, D.,"PPP EAP TLS Authentication
Protocol", RFC 2716, October 1999.
[RFC2865] Rigney, C., Willens, S., Rubens, A., Simpson, W., "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865,
June 2000.
[RFC3078] Pall, G. and Zorn, G. "Microsoft Point-to-Point
Encryption (MPPE) RFC 3078, March 2001.
[RFC3079] Zorn, G. "Deriving Keys for use with Microsoft Point-to-
Point Encryption (MPPE)," RFC 3079, March 2001.
[RFC3394] R. Housley, "Advance Encryption Standard (AES) Key Wrap
Algorithm", RFC 3394, September 2002.
[Congdon] Congdon, P., et al., "IEEE 802.1X RADIUS Usage
Guidelines", Internet draft (work in progress), draft-
congdon-radius-8021x-23.txt, February 2003.
[FIPSDES] National Bureau of Standards, "Data Encryption Standard",
FIPS PUB 46 (January 1977).
[DESMODES] National Bureau of Standards, "DES Modes of Operation",
FIPS PUB 81 (December 1980).
[FIPS197] FIPS PUB 197, Advanced Encryption Standard (AES), 2001
November 26H.
[SHA] National Institute of Standards and Technology (NIST),
"Announcing the Secure Hash Standard," FIPS 180-1, U.S.
Department of Commerce, 04/1995
[IEEE80211f] IEEE Draft 802.11F/D5, "Draft Recommended Practice for
Multi-Vendor Access Point Interoperability via an Inter-
Access Point Protocol Across Distribution Systems
Supporting IEEE 802.11 Operation", January 2003.
[IEEE80211i] IEEE Draft 802.11I/D3.1, "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", February 2003.
[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
Aboba & Simon Informational [Page 26]
INTERNET-DRAFT EAP Keying Framework 2 March 2003
[RFC2869bis] Aboba, B., Calhoun, P., "RADIUS Support For Extensible
Authentication Protocol (EAP)", Internet draft (work in
progress), draft-aboba-radius-rfc2869bis-09.txt, February
2003.
[RoamCERT] Aboba, B., "Certificate-Based Roaming", Internet draft
(work in progress), draft-ietf-roamops-cert-02.txt, April
1999.
[DiamBASE] Calhoun, P., et al., "Diameter Base Protocol", Internet
draft (work in progress), draft-ietf-aaa-diameter-17.txt,
December 2002.
[DiamCMS] Calhoun, P., Farrell, S., Bulley, W., "Diameter CMS
Security Application", Internet draft (work in progress),
draft-ietf-aaa-diameter-cms-sec-04.txt, March 2002.
[DiamEAP] Hiller, T., Zorn, G., "Diameter Extensible Authentication
Protocol (EAP) Application", Internet draft (work in
progress), draft-ietf-aaa-eap-00.txt, June 2002.
[Handoff] Arbaugh, B., "Experimental Handoff Extension to RADIUS",
Internet draft (work in progress), draft-irtf-aaaarch-
handoff-00.txt, February 2003.
[IEEE-02-758] Mishra, A., Shin, M., Arbaugh, W., Lee, I., Jang, K.,
"Proactive Caching Strategies for IAPP Latency
Improvement during 802.11 Handoff", IEEE 802.11 Working
Group, IEEE-02-758r1-F, November 2002.
[IEEE-03-084] Mishra, A., Shin, M., Arbaugh, W., Lee, I., Jang, K.,
"Proactive Key Distribution to support fast and secure
roaming", IEEE 802.11 Working Group, IEEE-03-084r1-I,
http://www.ieee802.org/11/Documents/DocumentHolder/3-084.zip,
January 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.
[KeyLen] Orman, H., Hoffman, P., "Determining Strengths For Public
Keys Used For Exchanging Symmetric Keys", Internet draft
(work in progress), draft-orman-public-key-
lengths-05.txt, December 2001.
[8021XHandoff] Pack, S., Choi, Y., "Pre-Authenticated Fast Handoff in a
Public Wireless LAN Based on IEEE 802.1X Model", School
Aboba & Simon Informational [Page 27]
INTERNET-DRAFT EAP Keying Framework 2 March 2003
of Computer Science and Engineering, Seoul National
University, Seoul, Korea, 2002.
[MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent Attack",
CryptoBytes Vol.2 No.2, Summer 1996.
[MiTM] Puthenkulam, J., et al, "The Compound Authentication
Binding Problem", Internet draft (work in progress),
draft-puthekulam-eap-binding-02.txt, March 2003.
Aboba & Simon Informational [Page 28]
INTERNET-DRAFT EAP Keying Framework 2 March 2003
Appendix A - Ciphersuite independence
The Master Session Key (MSK), Extended Master Session Key (EMSK) and IV
exported by EAP methods MUST be ciphersuite independent. This confers
several advantages:
Ciphersuite negotiation
Enabling derivation of the TSK(s) in a separate step provides
improved security. For example, the TSK derivation algorithm
supported within [IEEE80211i] enables the EAP peer and
authenticator to mutually authenticate and conduct a protected
ciphersuite and capabilities negotiation. If the MSK is used
directly as a TSK, then the EAP peer and authenticator may not
mutually authenticate each other, and a protected ciphersuite
negotiation, if it occurs at all, would typically need to be
supported within EAP itself. Since the ciphersuite negotiation
mechanisms are link-layer specific, this would introduce media and
ciphersuite dependencies into EAP.
Document Revision
If an EAP method specifies how to derive transient session keys for
each ciphersuite, the specification will need to be revised each
time a new ciphersuite is developed. This also implies that a
backend authentication server supporting an EAP method would not be
usable with all EAP-capable authenticators, if the backend
authentication server were not upgraded to support a new
ciphersuite implemented on the authenticator.
EAP method complexity
Requiring EAP methods to include ciphersuite-specific code for TSK
derivation increases the complexity of the EAP method.
Knowledge asymmetry
In practice, an EAP method may not have knowledge of the
ciphersuite that has been negotiated between the peer and
authenticator. In PPP, ciphersuite negotiation occurs 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, the peer,
authenticator and backend authentication server may not be able to
anticipate the negotiated ciphersuite and therefore this
information cannot be provided to the EAP method. Since ciphersuite
negotiation is assumed to occur out-of-band, there is no need for
ciphersuite negotiation within EAP.
Aboba & Simon Informational [Page 29]
INTERNET-DRAFT EAP Keying Framework 2 March 2003
Appendix B - Ciphersuite keying requirements
To date, PPP and IEEE 802.11 ciphersuites are suitable for keying by
EAP. This Appendix describes the keying requirements of common PPP and
802.11 ciphersuites.
PPP ciphersuites include DESEbis [RFC2419], 3DES [RFC2420], and MPPE
[RFC3078]. The DES algorithm is described in [FIPSDES], and DES modes
(such as CBC, used in [RFC2419] and DES-EDE3-CBC, used in [RFC2420]) are
described in [DESMODES]. For PPP DESEbis, a single 56-bit encryption
key is required, used in both directions. For PPP 3DES, a 168-bit
encryption key is needed, used in both directions. As described in
[RFC2419] for DESEbis and [RFC2420] for 3DES, the IV, which is different
in each direction, is "deduced from an explicit 64-bit nonce, which is
exchanged in the clear during the [ECP] negotiation phase." There is
therefore no need for the IV to be provided by EAP.
For MPPE, 40-bit, 56-bit or 128-bit encryption keys are required in each
direction, as described in [RFC3078]. No initialization vector is
required.
While these PPP ciphersuites provide encryption, they do not provide
per-packet authentication or integrity protection, so an authentication
key is not required in either direction.
Within [IEEE80211], Transient Session Keys (TSKs) are required both for
unicast traffic as well as for multicast traffic, and therefore separate
key hierarchies are required for unicast keys and multicast keys. IEEE
802.11 ciphersuites include WEP-40, described in [IEEE80211], which
requires a 40-bit encryption key, 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 support per-packet
authentication and integrity protection. In addition to these unicast
keys, authentication and encryption keys are required to wrap the
multicast encryption key.
Recently, new ciphersuites have been proposed for use with IEEE 802.11
that provide per-packet authentication and integrity protection as well
as encryption [IEEE80211i]. These include TKIP, which requires a single
128-bit encryption key and a 128-bit authentication key (used in both
directions); AES CCMP, which requires a single 128-bit key (used in both
directions) in order to authenticate and encrypt data; and WRAP, which
requires a single 128-bit key (used in both directions).
As with WEP, authentication and encryption keys are also required to
wrap the multicast encryption (and possibly, authentication) keys.
Aboba & Simon Informational [Page 30]
INTERNET-DRAFT EAP Keying Framework 2 March 2003
Appendix C - Example TEK Hierarchy
Figure C-1 illustrates the TEK key hierarchy for EAP-TLS [RFC2716],
which is based on the TLS key hierarchy described in [RFC2246]. The
TLS-negotiated ciphersuite is used to set up a protected channel for use
in protecting the EAP conversation, keyed by the derived TEKs. The TEK
derivation proceeds as follows:
master_secret = TLS-PRF-48(pre_master_secret, "master secret",
client.random || server.random)
TEK = TLS-PRF-X(master_secret, "key expansion",
server.random || client.random)
Where:
TLS-PRF-X = TLS pseudo-random function defined in [RFC2246],
computed to X octets.
master_secret = TLS term for the MK.
| | |
| | pre_master_secret |
server| | | client
Random| V | Random
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| | | |
+---->| master_secret |<------+
| | (MK) | |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | |
| | |
| | |
V V V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| Key Block |
| (TEKs) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| client | server | client | server | client | server
| MAC | MAC | write | write | IV | IV
| | | | | |
V V V V V V
Figure C-1 - TLS [RFC2246] Key Hierarchy
Aboba & Simon Informational [Page 31]
INTERNET-DRAFT EAP Keying Framework 2 March 2003
Appendix D - Example MSK, EMSK and IV Hierarchy
In EAP-TLS [RFC2716], the MSK is divided into two halves, corresponding
to the "Peer to Authenticator Encryption Key" (Enc-RECV-Key, 32 octets,
also known as the PMK) and "Authenticator to Peer Encryption Key" (Enc-
SEND-Key, 32 octets). In [RFC2548], the Enc-RECV-Key (the PMK) is
transported in the MS-MPPE-Recv-Key attribute, and the Enc-SEND-Key is
transported in the MS-MPPE-Send-Key attribute.
The EMSK is also divided into two halves, corresponding to the "Peer to
Authenticator Authentication Key" (Auth-RECV-Key, 32 octets) and
"Authenticator to Peer Authentication Key" (Auth-SEND-Key, 32 octets).
The IV is a 64 octet quantity that is a known value; octets 0-31 are
known as the "Peer to Authenticator IV" or RECV-IV, and Octets 32-63 are
known as the "Authenticator to Peer IV", or SEND-IV.
In EAP-TLS, the MSK, EMSK and IV are derived from the MK via a one-way
function. This ensures that the MK cannot be derived from the MSK, EMSK
or IV unless the one-way function (TLS PRF) is broken. Since the MSK is
derived from the MK, if the MK is compromised then the MSK is also
compromised.
As described in [RFC2716], the formula for the derivation of the MSK,
EMSK and IV from the MK is as follows:
MSK = TLS-PRF-64(MK, "client EAP encryption", client.random || server.random)
EMSK = second 64 octets of:
TLS-PRF-128(MK, "client EAP encryption", client.random || server.random)
IV = TLS-PRF-64("", "client EAP encryption", client.random || server.random)
MSK(0,31) = Peer to Authenticator Encryption Key (Enc-RECV-Key)
(MS-MPPE-Recv-Key in [RFC2548])
MSK(32,63) = Authenticator to Peer Encryption Key (Enc-SEND-Key)
(MS-MPPE-Send-Key in [RFC2548])
EMSK(0,31) = Peer to Authenticator Authentication Key (Auth-RECV-Key)
EMSK(32,63) = Authenticator to Peer Authentication Key (Auth-Send-Key)
IV(0,31) = Peer to Authenticator Initialization Vector (RECV-IV)
IV(32,63) = Authenticator to Peer Initialization vector (SEND-IV)
Where:
IV(W,Z) = Octets W through Z inclusive of the IV.
MSK(W,Z) = Octets W through Z inclusive of the MSK.
EMSK(W,Z) = Octets W through Z inclusive of the EMSK.
MK = TLS master_secret
TLS-PRF-X = TLS PRF function defined in [RFC2246] computed to X octets
client.random = Nonce generated by the TLS client.
server.random = Nonce generated by the TLS server.
Aboba & Simon Informational [Page 32]
INTERNET-DRAFT EAP Keying Framework 2 March 2003
Figure D-1 describes the process by which the MSK,EMSK,IV and ultimately
the TSKs, are derived from the MK. Note that in [RFC2716], the MK is
referred to as the "TLS Master Secret".
---+
| ^
| TLS Master Secret (MK) |
| |
V |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | EAP |
| Master Session Key (MSK) | Method |
| Derivation | |
| | V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ EAP ---+
| | | API ^
| MSK | EMSK | IV |
| | | |
V V V v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | |
| | |
| AAA server | |
| | |
| | V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | ^
| MSK(0,31) | MSK(32,63) |
| (PMK) | Transported |
| | via AAA |
| | |
V V V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | ^
| Ciphersuite-Specific Transient Session | Auth.|
| Key Derivation | |
| | V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
Figure D-1 - EAP TLS [RFC2716] MSK, EMSK and IV hierarchy
Aboba & Simon Informational [Page 33]
INTERNET-DRAFT EAP Keying Framework 2 March 2003
Appendix E - Example Transient Session Key (TSK) Derivation
Within IEEE 802.11 RSN, the Pairwise Transient Key (PTK), a transient
session key used to protect unicast traffic, is derived from the PMK
(octets 0-31 of the MSK), known in [RFC2716] as the Peer to
Authenticator Encryption Key. In [IEEE80211i], the PTK is derived from
the PMK via the following formula:
PTK = EAPOL-PRF-X(PMK, "Pairwise key expansion", Min(AA,SA) ||
Max(AA, SA) || Min(ANonce,SNonce) || Max(ANonce,SNonce))
Where:
PMK = MSK(0,31)
SA = Station MAC address
AA = Access Point MAC address
ANonce = Access Point Nonce
SNonce = Station Nonce
EAPOL-PRF-X = Pseudo-Random Function based on HMAC-SHA1, generating
a PTK of size X octets.
TKIP uses X = 64, while CCMP, WRAP, and WEP use X = 48.
The EAPOL-Key Confirmation Key (KCK) is used to provide data origin
authenticity in the TSK derivation. It utilizes the first 128 bits (bits
0-127) of the PTK. The EAPOL-Key Encryption Key (KEK) provides
confidentiality in the TSK derivation. It utilizes bits 128-255 of the
PTK. Bits 256-383 of the PTK are used by Temporal Key 1, and Bits
384-511 are used by Temporal Key 2. Usage of TK1 and TK2 is ciphersuite
specific. Details are available in [IEEE80211i].
Aboba & Simon Informational [Page 34]
INTERNET-DRAFT EAP Keying Framework 2 March 2003
Appendix F - Example PMK Derivation
As discussed in [Handoff], [IEEE-02-758], [IEEE-03-084], and
[8021XHandoff], keying material may be required for use in fast handoff
between IEEE 802.11 authenticators. Where the backend authentication
server provides keying material to multiple authenticators in order to
fascilitate fast handoff, it is highly desirable for the keying material
used on different authenticators to be cryptographically separate, so
that if one authenticator is compromised, it does not lead to the
compromise of other authenticators. Where keying material is provided
by the backend authentication server, a key hierarchy derived from the
EMSK, as suggested in [IEEE-03-155] can be used to provide
cryptographically separate keying material for use in fast handoff:
PMK0-A = MSK(0,31)
PMK1-B = PRF(EMSK(0,31),PMK0-A,APB-MAC-Addr,STA-MAC-Addr)
PMK1-E = PRF(EMSK(0,31),PMK0-A,APE-MAC-Addr,STA-MAC-Addr)
Here PMK0-A is the Pairwise Master Key derived during the initial EAP
authentication between the peer and authenticator A. Based on this
initial EAP authentication, the EMSK is also derived, the first 32
octets of which can be used to derive PMKs for fast authentication
between the EAP peer and authenticators B and E. Since the EMSK is
cryptographically separate from the MSK, each of these PMKs is
cryptographically separate from each other, and are guaranteed to be
unique between the EAP peer (also known as the STA) and the
authenticator (also known as the AP).
Acknowledgments
Thanks to Arun Ayyagari, Ashwin Palekar, and Tim Moore of Microsoft,
Dorothy Stanley of Agere, Dave Halasz of Cisco Systems, and Russ Housley
of RSA Security for useful feedback.
Author Addresses
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
EMail: bernarda@microsoft.com
Phone: +1 425 706 6605
Fax: +1 425 936 7329
Dan Simon
Microsoft Research
Microsoft Corporation
Aboba & Simon Informational [Page 35]
INTERNET-DRAFT EAP Keying Framework 2 March 2003
One Microsoft Way
Redmond, WA 98052
EMail: dansimon@microsoft.com
Phone: +1 425 706 6711
Fax: +1 425 936 7329
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to pertain
to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or
might not be available; neither does it represent that it has made any
effort to identify any such rights. Information on the IETF's
procedures with respect to rights in standards-track and standards-
related documentation can be found in BCP-11. Copies of claims of
rights made available for publication and any assurances of licenses to
be made available, or the result of an attempt made to obtain a general
license or permission for the use of such proprietary rights by
implementors or users of this specification can be obtained from the
IETF Secretariat.
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 (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into
languages other than English. The limited permissions granted above are
perpetual and will not be revoked by the Internet Society or its
successors or assigns. This document and the information contained
herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
Aboba & Simon Informational [Page 36]
INTERNET-DRAFT EAP Keying Framework 2 March 2003
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."
Open issues
Open issues relating to this specification are tracked on the following
web site:
http://www.drizzle.com/~aboba/EAP/eapissues.html
Expiration Date
This memo is filed as <draft-aboba-pppext-key-problem-06.txt>, and
expires August 22, 2003.
Aboba & Simon Informational [Page 37]
| PAFTECH AB 2003-2026 | 2026-04-21 17:41:52 |