One document matched: draft-vidya-eap-keying-gap-analysis-00.txt
Network Working Group V. Narayanan
Internet-Draft L. Dondeti
Expires: October 22, 2006 QUALCOMM, Inc.
April 20, 2006
Gap analysis on the EAP keying hierarchy
draft-vidya-eap-keying-gap-analysis-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on October 22, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The extensible authentication protocol (EAP) keying framework [1]
leaves out guidelines for using the extended master session key
(EMSK) for future discussion and specification. While the keying
framework does provide guidance for EAP master session key (MSK)
usage, some SDOs use that key in a non-compliant manner. This
document provides a description and analysis of MSK and EMSK usage
and provides an outline for a discussion on these topics.
Narayanan & Dondeti Expires October 22, 2006 [Page 1]
Internet-Draft EAP Keying Gap Analysis April 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Summary of EAP keying hierarchy . . . . . . . . . . . . . . . 4
4. Gap analysis . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. EAP Architecture Models . . . . . . . . . . . . . . . . . 5
4.1.1. Basic EAP Model . . . . . . . . . . . . . . . . . . . 5
4.1.2. Distinct Authenticator and EP Entities . . . . . . . . 6
4.1.3. Distinct EAP Server and AAA Server . . . . . . . . . . 8
4.2. Authenticator-EP Interface . . . . . . . . . . . . . . . . 8
4.3. Handoffs and Authentication . . . . . . . . . . . . . . . 9
4.3.1. EAP-Based Pre-authentication . . . . . . . . . . . . . 9
4.3.2. Fast Re-authentication in EAP . . . . . . . . . . . . 10
4.3.3. Pro-Active Key Distribution . . . . . . . . . . . . . 10
4.4. On MSKs . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.4.1. MSK key hierarchy . . . . . . . . . . . . . . . . . . 11
4.5. On the extended MSK (EMSK) . . . . . . . . . . . . . . . . 12
4.5.1. EMSK derivation from EAP methods . . . . . . . . . . . 13
4.5.2. EMSK handling at the peer and the server . . . . . . . 15
4.5.3. EMSK lifetime and replacement . . . . . . . . . . . . 15
4.6. Key naming . . . . . . . . . . . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 20
Narayanan & Dondeti Expires October 22, 2006 [Page 2]
Internet-Draft EAP Keying Gap Analysis April 2006
1. Introduction
The EAP Keying Framework [1] and the EAP Keying Extensions [4]
documents explain the EAP keying hierarchy and the uses of the
various keying materials derived as a result of EAP method execution.
However, there are some gaps in the key derivation and usage
guidelines specified in these two documents. The goal of this
document is to identify those gaps and provide an analysis to help
adequately specify the key hierarchy and guidelines.
There are some gray areas in the manner in which other SDOs have used
EAP keying to create session keys for the peer. For example, in IEEE
802.11 networks, the use of 802.11i [5] often follows the model where
the EAP peer is in the STA and the EAP authenticator is in a Wireless
LAN switch. In this model, the Enforcement Point (defined below) is
often in the 802.11 Access Point to which the STA associates. The
TSKs are used to establish a mutually authenticated secure channel
between the AP and the peer. The secure channel's primary purpose is
link layer access control. Given that the authenticator is in the
switch, the MSK from the EAP exchange arrives at the switch. TSK
derivation from the MSK when the Authenticator is separate from the
EP(s) is not specified in any IETF documents. Proprietary protocols
and other SDO specifications (e.g., IEEE 802.11r, IEEE 802.16e,
etc.), completed or in progress, fill the gap currently.
The EAP keying documents [1], [4], also explain the keys derived by
EAP methods (MSK, EMSK) and explain the usage of each of those keys.
However, EMSK and AMSK usage remain undefined at this point. This
document provides an analysis on what remains to be specified and
outlines some of the approaches considered by other documents.
2. 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 RFC-2119 [2].
This document follows the terminology that has been defined in
RFC3748 [3] and the EAP Keying I-D. In addition, this document uses
the following terms:
Enforcement Point (EP)
A logical entity that shares the TSK with the EAP peer and is
responsible for port control. Examples of EP include specific
ports on an authenticator or Layer2 devices such as WLAN APs or
cellular base stations, etc.
Narayanan & Dondeti Expires October 22, 2006 [Page 3]
Internet-Draft EAP Keying Gap Analysis April 2006
3. Summary of EAP keying hierarchy
This section captures in a brief description, a summary of the EAP
keying framework [1] as well as the current snapshot of the EAP
keying extensions [4]. The EAP keying framework [1] describes the
creation of the MSK and EMSK and the usage of the MSK. The three
phases in authentication and key derivation of the peer have been
identified as the discovery phase, where the EAP peer discovers a
valid authenticator, followed by an authentication phase, where the
EAP authentication is performed and key material (e.g., MSK) is
derived and transported, followed by a secure association
establishment phase, where the session keys are derived. Of these,
[1] identifies the EAP authentication and the key derivation as being
within the scope of EAP.
In a nutshell, EAP keying framework [1] requires key generating EAP
methods to derive an MSK and an EMSK. The MSK is then exported to
the AAA layer of the server, which then transports the key to the
authenticator. The AAA layer of the authenticator passes the MSK on
to the EAP lower layer that would eventually derive the TSKs from it.
The EMSK is derived by the EAP method in the peer and server and
exported to the EAP layer. In accordance with the current status of
the EAP keying framework [1], it is never transported out of the EAP
layer and specifically, never shared with a third party.
RFC3748 [3] and the EAP keying framework [1] provide some detail on
channel binding that can be used to ensure that the EAP server and
peer are communicating with the same and a valid authenticator.
Here, the channel binding information is seen as an opaque blob by
the EAP layer and may be carried in the EAP method. It is only
interpreted by the lower layer. Channel binding allows the peer and
the server to unambiguously identify the authenticator's architecture
to cover cases such as that of virtual authenticators, multiple ports
of an authenticator, or a cluster of authenticators. The peer may
end up participating in a security association protocol with one of
the ports of an authenticator or one of the authenticators among the
cluster of authenticators, etc. In addition to carrying channel
binding information via EAP methods, other proposals have been made
to incorporate channel binding information into EAP keying framework:
[6] proposes a method by which channel binding can be done without a
need to carry the service information in EAP methods. Here, keys are
derived by the method layer for channel binding purposes.
Aside from an in-depth description of the lower layer behavior and
EAP key management, the EAP keying framework [1] also explains some
guidelines with respect to handoffs that do not result in a full EAP
re-authentication. The description alludes to the fact that it may
be acceptable to perform such faster hanodffs when the respective
Narayanan & Dondeti Expires October 22, 2006 [Page 4]
Internet-Draft EAP Keying Gap Analysis April 2006
authenticators or ports/SSIDs within the authenticator have similar
policies and are within the same administrative domain. Again, this
points to the case where the authenticator that shares the MSK with
the peer and the EP that shares the TSK with the peer may potentially
be logically or physically different entities.
There is an EAP keying extensions [4] document that was separated
from an originally published EAP keying framework [1] that provides
some insight into EMSK usage and AMSK derivations. However, that
document is currently expired and needs to be updated in light of
some of the changes adopted in the EAP keying frameworkre.
4. Gap analysis
The goal of this section is to analyze the missing pieces in the
currently available documentation on EAP keying and propose some next
steps to bridge the gap. For the purpose of discussion within this
document, only the pass-through mode of the authenticator will be
considered. However, the multiplexing mode works very similarly and
the behavior of the authenticator portion remains unchanged.
4.1. EAP Architecture Models
4.1.1. Basic EAP Model
In the simplest case, the EP is collocated with the authenticator as
shown in the figure below.
+-+-+-+-+ +-+-+-+-+ +-+-+-+-+
| | | | | |
| EAP |--------| Auth/ |--------| EAP |
| Peer | | EP | |Server |
+-+-+-+-+ +-+-+-+-+ +-+-+-+-+
Figure 1: EAP Authenticator Collocated with the Enforcement Point
The key distribution described in the EAP keying framework [1] is
adequate to describe this case. For reference, the transport of the
EAP keying material (i.e., MSK) from the EAP server to the
authenticator is shown below.
Narayanan & Dondeti Expires October 22, 2006 [Page 5]
Internet-Draft EAP Keying Gap Analysis April 2006
Peer Pass-through Authenticator Authentication
Server
+-+-+-+-+-+-+ +-+-+-+-+-+-+
| | | |
|EAP method | |EAP method |
| V | | V |
+-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+
| ! | |EAP | EAP | | | ! |
| ! | |Peer | Auth.| EAP Auth. | | ! |
|EAP ! peer| | | +-----------+ | |EAP !Auth.|
| ! | | | ! | ! | | ! |
+-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+
| ! | | ! | ! | | ! |
|EAP !layer| | EAP !layer| EAP !layer | |EAP !layer|
| ! | | ! | ! | | ! |
+-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+
| V | | V | ! | | ! |
|Lower layer| | Lower layer| AAA ! /IP | | AAA ! /IP |
| | | | ! | | ! |
+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+
! !
! !
+---------<-------+
Figure 2: EAP MSK Transport in Pass-Through Model
4.1.2. Distinct Authenticator and EP Entities
In other EAP architecture models, the authenticator and the EP are
not logically and/or physically collocated. This may be the case
when there are multiple ports on an authenticator or multiple
physical EPs (e.g., 802.11 APs) connected to an authenticator (e.g.,
WLAN switch).
The following figure illustrates this case of separated authenticator
and EPs.
Narayanan & Dondeti Expires October 22, 2006 [Page 6]
Internet-Draft EAP Keying Gap Analysis April 2006
+-+-+-+-+
| |
| EAP |
|Server |
+-+-+-+-+
|
|
|
+-+-+-+-+
| |
| Auth |
| |
+-+-+-+-+
| | |
/ | \
/ | \
/ | \
/ | \
/ | \
/ | \
+-+-+-+ +-+-+-+ +-+-+-+
| EP1 | | EP2 |..| EPn |
+-+-+-+ +-+-+-+ +-+-+-+
|
|
|
+-+-+-+-+
| |
| EAP |
| Peer |
+-+-+-+-+
Figure 3: EAP Authenticator Not Collocated with the Enforcement Point
In a case like this, the EAP authenticator is not the entity sharing
the TSK with the EAP peer. In accordance with EAP, the MSK will be
delivered to the authenticator. However, the TSK generated is shared
by say, EP1 and the peer in the figure above. In many
implementations available today, the interface between the
Authenticator and the EPs remains either proprietary or different in
various SDOs.
When the authenticator and the EPs are devices employing the same
Narayanan & Dondeti Expires October 22, 2006 [Page 7]
Internet-Draft EAP Keying Gap Analysis April 2006
access technology (such as 802.11, 3GPP2 L2 technologies, 802.16e),
it can be concluded that the interface under question is not within
the scope of the IETF. However, when the authenticator and EP do not
map to the same access technology, the definition of the interface
between them in the IETF might become important.
The analysis on handovers, re-authentication and pre-authentication
done further in this document indicates that there is not a practical
need for the case where the authenticator and EP do not map to the
access technology.
4.1.3. Distinct EAP Server and AAA Server
Another possible architecture that would be compliant with EAP is the
case where the EAP and AAA servers are separate entities. Even
though the EAP architecture allows for this, existing documentation
is insufficient to clearly define this model. For instance, the
function of the AAA layer in the EAP server and its interactions with
the AAA layer in the AAA server in this case, although can be
extracted, is not explicitly clear.
The presence of distinct EAP and AAA servers does not have any
advantages to it. Hence, this case of distinct EAP and AAA servers
is considered not a practical use case and will not be explored
further in this document.
4.2. Authenticator-EP Interface
As mentioned earlier, the interface between the authenticator and the
EP is not currently defined in the IETF, in a generic sense (the
CAPWAP [7] protocol is currently 802.11 specific, and does not quite
cover the use case being discussed here). Other SDOs have defined
this interface in some cases. For instance, IEEE 802.11r specifies a
two-level key holder hierarchy for fast BSS transition. However,
there are some other cases that remain proprietary - for instance,
the interface between a WLAN switch and an Access Point.
One question in this case is this - when the authenticator and EP are
not collocated, how does the MSK delivered to the authenticator
enable the establishment of a TSK between the peer and the EP? In
many implementations today, one of the following three approaches are
taken. In one approach, the authenticator provides the MSK to every
EP that the peer attaches to and the EP establish the TSK with the
peer via Secure Association Protocol. In this case, all EPs under
the authenticator share the same MSK. In another approach, the
authenticator provides the MSK to the first EP and the MSK is
transferred via EP-to-EP context transfer mechanisms to the other EPs
as needed. The EPs share the same MSK in this case as well. In a
Narayanan & Dondeti Expires October 22, 2006 [Page 8]
Internet-Draft EAP Keying Gap Analysis April 2006
third approach, the authenticator derives an EP-specific key to hand
to each EP as needed and that key is used to derive the TSK. The
first two approaches are the commonly used ones, since in those
cases, the peer does not have to even know that the authenticator and
EP are not collocated. In the third approach, the peer would have to
know to derive an EP specific key to use for the Secure Association
Protocol.
If the interface between the authenticator and the EP does not need
to be defined in the IETF (i.e., if the authenticator and the EPs
associated with each other always belong to the same access
technology), then, effectively, there is not an open issue here.
Currently, this is considered to be true and hence, we conclude that
the A-EP interface is, in fact, outside the scope of the IETF.
4.3. Handoffs and Authentication
The EAP keying framework [1] identifies some vulnerabilities that may
arise during handoffs due to the ways in which the EAP keying is used
today. Many of the concerns relate to the above mentioned use of
mechanisms that share the MSK or perform some faster re-
authentication without performing a new EAP authentication. The EAP
keying framework [1] acknowledges these approaches and provides some
guidelines for the correct usage of the MSK.
While referring to handoffs, roundtrip latency to the AAA server
incurred while employing certain EAP methods may be undesirable.
Some EAP methods such as EAP-PSK only incur a maximum of two
roundtrips to the AAA server and could be viewed as being acceptable.
However, there may be reasons why optimizations need to be considered
in the case of handoffs.
The following sections discuss concepts that relate to secure handoff
optimizations. Some of these concepts have been worked on and
analyzed in other documents written in the past.
4.3.1. EAP-Based Pre-authentication
Several lower layers support the concept of pre-authentication, where
the EAP peer can authenticate with a target authenticator prior to
actually needing to run the secure association protocol on the new
link. As RFC 3748 [3] points out, the MSK derived as a result of
pre-authentication may or may not even be used to create session
keys. If the EAP peer pre-authenticates with an authenticator and
does not move to that authenticator, the MSK will be unused.
There are some questions on the behavior of pre-authentication that
remain unanswered. For now, since the pre-authentication is not
Narayanan & Dondeti Expires October 22, 2006 [Page 9]
Internet-Draft EAP Keying Gap Analysis April 2006
signaled in EAP (it is only signaled in lower layers like IEEE
802.11i for appropriate routing of the EAP frames to the correct
authenticator), the EAP server is unaware of whether a certain EAP
exchange is for pre-authentication or regular authentication. AAA
servers need to understand pre-authentication so that appropriate
state (e.g., the NAS ID of the authenticator with which the peer has
pre-authenticated) and accounting information can be maintained for
the peer.
If pre-authentication could be signaled in EAP itself, then the EAP
server would be able to distinguish between a normal authentication
and a pre-authentication. While this may be difficult given the
legacy implementations of EAP and EAP methods, this could be signaled
at the AAA layer at a minimum, so that the server can adequately
distinguish between the two.
It should be noted that pre-authentication is no different from
regular EAP authentication, except that the EAP signaling between the
peer and the authenticator is exchanged via the current EP or
authenticator. Pre-authentication still results in execution of the
EAP method as in the case of regular authentication.
4.3.2. Fast Re-authentication in EAP
EAP does not have a means for fast re-authentication. When the peer
needs to obtain a new MSK, it needs to perform a full EAP exchange
today. With other techniques such as pre-authentication, pro-active
key distribution, etc., available, there is no need for EAP to deal
with re-authentication in any different manner. Depending on the EAP
method used, even the full authentication may not be that disruptive,
at least in the case where the peer is accessing its home domain (in
the non-roaming case).
4.3.3. Pro-Active Key Distribution
The AAA Architecture document [8] describes a method of pro-actively
distributing keys to neighboring authenticators based on
authentication at a current authenticator. The EAP keying extensions
[4] document summarizes the pro-active key distribution mechanism.
In this case, the AAA server is said to learn about the neighboring
authenticators by observing a node's movement pattern. Hence, the
AAA server creates a neighbor graph for the node and creates a key
for each neighboring authenticator. The authenticator may then
request the key from the AAA server to obtain it.
This method of pro-active key generation and distribution has its
advantages and issues. It may be impractical for the AAA server to
know or learn the network topology and identify the neighboring
Narayanan & Dondeti Expires October 22, 2006 [Page 10]
Internet-Draft EAP Keying Gap Analysis April 2006
authenticators correctly. On the other hand, this mechanism clearly
avoids having to authenticate the peer again and hence, could be
significantly faster.
Another point to be noted that the AAA architecture work is agnostic
to the type of authentication and does not directly apply to EAP.
Hence, it must be studied to see if the keying framework [1] in EAP
brings any additional considerations.
When EAP is used for authentication and key derivation, the EAP
method layer is the one deriving the MSK. In accordance with EAP
behavior, the EAP method must derive subsequent MSKs. Pro-active key
distribution should be done without requiring changes to EAP methods
in order to be widely adopted. EAP methods currently only derive one
MSK and EMSK as a result of one method exchange and hence, pro-active
derivation of multiple MSKs for other authenticators does not fit
this model.
Pro-active key distribution itself is somewhat of a misleading
concept in the sense that AAA protocols do not particularly allow for
unsolicited signaling from the server to the NAS needed for such
distribution. However, pro-active key generation itself may have its
place in speeding up handoffs. In addition to being pro-active about
MSK generation for target authenticators, it could also be derived
on-demand when requested from a target authenticator. This, in fact,
fits well with today's AAA model, which is always client initiated.
When a given network allows for both pre-authentication and proactive
key distribution, both may in fact be performed. Keys derived from
pre-authentication must override any keys obtained via proactive key
derivation methods. If an MSK is available at an authenticator via
EAP pre-authentication, any key (MSK) obtained via proactive
distribution must be deleted and the MSK received from the pre-
authentication must be used to derive TSKs.
4.4. On MSKs
The EAP keying framework [1] clearly explains the fact that the MSK
is derived by the EAP method and transported to the authenticator.
The AAA layer of the authenticator receives it from the AAA layer of
the Authentication Server (AS) and transports it typically to another
lower layer. The sections below analyze two separate cases,
depending on the relative location of the authenticator and EP.
4.4.1. MSK key hierarchy
Narayanan & Dondeti Expires October 22, 2006 [Page 11]
Internet-Draft EAP Keying Gap Analysis April 2006
Keys Entity(ies) that hold(s) the key
-------- ----------------------------------
MSK Virtual authenticator & peer
|
+--------------------------+
| | |
EP1MSK EP2MSK EP3MSK EPi holds EPiMSK & peer
^ ^ ^
| | |
| | |
v v v
TSK1 TSK2 TSK3 Peer & EP1 derive TSK1
Figure 4: MSK key hierarchy
Figure 4 above shows the MSK Key Hierarchy in the case where the
authenticator and the EP are distinct entities. As seen, there is
potentially an EPiMSK that is derived from the MSK to provide an EP
specific key. As described earlier, these keys are currently either
defined by lower layers or in other cases, the EPiMSK is the same as
the MSK. In either case, channel binding must be clearly specified
so that the peer and the server have the same understanding of the
scope of the key.
4.5. On the extended MSK (EMSK)
The EAP specification [3] defines the EMSK as follows:
The extended master key (EMSK) is additional keying material -- in
addition to the TEK and the MSK -- derived between the EAP client and
server that is exported by the EAP method. It is at least 64 octets
in length and is not shared with the authenticator or any other third
party.
The EMSK must be cryptographically separate from the MSK. The MSK
and the keys derived from the EMSK are used for different purposes
and may be provided to entities that do not trust each other. Thus
it must not be possible to derive the MSK from the EMSK or vice
versa, without breaking cryptographic assumptions such as reversing a
one-way function.
The EMSK must not be used directly to protect data. The EMSK is
exported from the EAP method layer to the EAP layer, but never
transported out of the EAP server. The EMSK MUST NOT be transported
Narayanan & Dondeti Expires October 22, 2006 [Page 12]
Internet-Draft EAP Keying Gap Analysis April 2006
by the AAA layer. RFC3748 specifies that the EMSK is reserved for
future use and MUST remain on the EAP peer and EAP server where it is
derived; it MUST NOT be transported to, or shared with, additional
parties, or used to derive any other keys. The eventual intent is to
use the EMSK to derive keys; RFC3748 postpones that discussion to a
future IETF specification.
4.5.1. EMSK derivation from EAP methods
Guidelines for the derivation of EMSK within a method are adapted
from the previous work of Salowey et. al. [9]. Some of the following
rules have been stated earlier, but included below for completeness:
o The EAP method must specify how to derive the EMSK.
o The EMSK must be unique for each session.
o The EAP mechanism should provide a way of naming the EMSK.
o EAP methods should ensure the freshness of the MSK and EMSK, even
in cases where one party may not have a high quality random number
generator. A recommended method is for each party to provide a
nonce of at least 64 octets, used in the derivation of the MSK and
EMSK.
o The EMSK must be cryptographically independent of the MSK and
TEKs.
o The EMSK must be secret and not known to someone observing the
authentication mechanism protocol exchange.
o The EMSK must be maintained within the EAP server. Only keys
derived from the EMSK may be exported from the EAP server.
o The use of EMSK and key derivation thereof must be defined in one
document, and the EMSK must not be used for any other purpose.
Application-level key material requests must be fulfilled with the
keys derived from the EMSK.
4.5.1.1. Examples of EMSK derivation in EAP methods
Examples of EMSK derivation in various EAP methods are described
below for reference (copied from various EAP method specifications):
Narayanan & Dondeti Expires October 22, 2006 [Page 13]
Internet-Draft EAP Keying Gap Analysis April 2006
EAP-FAST MSK and EMSK derivation
The session_key_seed derived as part of EAP-FAST phase 2 is used
in EAP-FAST phase 2 to generate an Intermediate Compound Key
(IMCK) used to verify the integrity of the TLS tunnel after each
successful inner authentication and in the generation of Master
Session Key (MSK) and Extended Master Session Key (EMSK) defined
in [RFC3748]. EAP-FAST Authentication assures the master session
key (MSK) and Extended Master Session Key (EMSK) output from the
EAP method are the result of all authentication conversations by
generating an intermediate compound session key (IMCK). The IMCK
is mutually derived by the peer and the server as described in
Section 5.2 by combining the MSKs from inner EAP methods with key
material from EAP-FAST phase 1. The resulting MSK and EMSK are
generated as part of the IMCKn key hierarchy as follows:
MSK = T-PRF(S-IMCK[j], "Session Key Generating Function", 64)
EMSK = T-PRF(S-IMCK[j],"Extended Session Key Generating Function", 64)
where j is the number of the last successfully executed inner EAP
method. If no EAP methods have been negotiated inside the tunnel
or no EAP methods have been successfully completed inside the
tunnel, the MSK and EMSK will be generated directly from the
session_key_seed meaning S-IMCK = session_key_seed.
PEAPv2 MSK and EMSK derivation
PEAPv2 derives an Extended Master Session Key (EMSK) which is
reserved for use in deriving keys in other ciphering applications.
The compound session key (CSK) is derived on both the peer and EAP
server.
CSK = PRF+(S-IPMKn, "Session Key Generating Function", OutputLength)
where, IPMKj = PRF+(S-IPMK(j-1),"Inner Methods Compound Keys " | ISKj, 60);
Where S-IPMKj are the first 40 octets of IPMKj and CMKj are the
last 20 octets of IPMKj used to generate the intermediate Compound
MACs. ISK1..ISKn are the MSK portion of the EAP keying material
obtained from methods 1 to n. The ISKj shall be the first 32
octets of the generated MSK of the jth EAP method. The output
length of the CSK must be at least 128 bytes. The first 64 octets
are taken as the MSK and the second 64 octets are taken as the
EMSK.
Narayanan & Dondeti Expires October 22, 2006 [Page 14]
Internet-Draft EAP Keying Gap Analysis April 2006
TTLS MSK and EMSK derivation
Upon successful conclusion of an EAP-TTLSv1 negotiation, a 64-
octet MSK (Master Session Key) is generated and exported for use
in securing the data connection between client and access point.
The MSK is generated using the TLS PRF function [RFC2246], with
inputs consisting of the inner secret exported by TLS/IA, the
ASCII- encoded constant string "ttls v1 keying material", the TLS
client random, and the TLS server random. The constant string is
not null- terminated. The TLS/IA inner secret, rather than the
TLS master secret, is used because it binds session keys from
inner authentications with the TLS master secret and therefore
provides greater security in the (unlikely) case that an adversary
is able to compromise the master secret.
MSK = PRF(inner_secret,
"ttls v1 keying material",
SecurityParameters.client_random +
SecurityParameters.server_random) [0..63]
TTLS does not specify the derivation of EMSK.
4.5.2. EMSK handling at the peer and the server
EMSK handling itself is specified in the EAP keying document [1] and
there are ongoing discussions on the handling of that key.
Section 7.10 of RFC 3748 [3] notes that the EMSK is reserved for
future use and MUST remain on the EAP peer and EAP server where it is
derived; it MUST NOT be transported to, or shared with, additional
parties, or used to derive any other keys. (This restriction will be
relaxed in a future document that specifies how the EMSK can be
used.)
The EAP keying framework states that the EMSK MUST NOT be provided to
an entity outside the EAP server or peer, nor is it permitted to pass
any quantity to an entity outside the EAP server or peer from which
the EMSK could be computed without breaking some cryptographic
assumption, such as inverting a one-way function.
4.5.3. EMSK lifetime and replacement
The EMSK is associated with a lifetime parameter. When the lifetime
expires, the EMSK must be deleted and no further keys can be derived
from it. When a peer reauthenticates, a new MSK and EMSK will be
generated. An AS maintains a single EMSK per peer, and thus the new
EMSK will replace the old EMSK.
Narayanan & Dondeti Expires October 22, 2006 [Page 15]
Internet-Draft EAP Keying Gap Analysis April 2006
4.6. Key naming
MSK and EMSK names are among the parameters exported by the EAP peer
and EAP server, and can be referred to using the EAP Session-ID and a
binary or textual indication of the parameter being referred to. The
EAP method layer exports the MSK and EMSK name to the peer or the
authenticator layers. The EAP Session-ID is defined as the
concatenation of the EAP Expanded Type with the Method-ID.
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 a KDF with the EMSK, peer and server IDs and an
identifying string as the inputs.
5. Security Considerations
This draft provides an analysis of EAP MSK and EMSK derivation, usage
and handling. [10] specifies detailed guidelines for AAA key
management. Those criteria are all applicable in handling MSKs and
EMSKs. In the following, we will briefly describe the salient
requirements:
Algorithm independence: Key derivation from the MSK and EMSK must
be specified in an algorithm independent fashion. HMAC-SHA-1 as a
PRF is common in many EAP methods, but future proofing just in
case there are vulnerabilities found in the HMAC construction or
even to allow using cipher-based PRFs would be a desirable
feature. Note further that in future, longer keys may be
required. The MSK and the EMSK are already required to be 64
octets or more in length, which allows easy accommodation of SHA-
256 or other cryptographic functions requiring the use of long
keys.
Strong, fresh keys: It is important that EAP methods include
nonces and other session specific random information to derive the
MSK and EMSK. These rules apply to keys derived from the MSK and
the EMSK also.
Limiting key scope: Section Section 4.2 discusses how in certain
cases, the MSK may be shared between multiple entities. That is
in general not a recommended practice. Note that compromise of
any of the entities that hold the MSK results in compromise of the
MSK and requires re-authentication. It is also plausible that the
compromise is not easily detectable since the peer may not be
involved in any communication with some of the entities that may
hold the MSK. Similar rules apply to EMSK. EMSK handling
Narayanan & Dondeti Expires October 22, 2006 [Page 16]
Internet-Draft EAP Keying Gap Analysis April 2006
guidelines are quite strict in that the EMSK itself is not
transported to any third party entity. It is also prudent to
limit the delivery of any derived keys from the MSK or the EMSK to
entities that absolutely require that key. It is also prudent to
deliver a separate key for each third party entity to limit any
key exposure.
Key naming and binding: It is important to name the MSK, EMSK and
derived keys thereof to easily and unambiguously identify the
keys. Similarly, it is important to bind the keys to the context,
including the identities of the parties that use the key,
lifetime, key length etc.
6. IANA Considerations
No IANA registrations are required for this document.
7. Acknowledgments
The authors would like to thank AC Mahendran for helping out with
discussions on the topic. Note that the text in this draft in
certain places has been liberally borrowed from other EAP keying
related drafts.
8. References
8.1. Normative References
[1] Aboba, B., "Extensible Authentication Protocol (EAP) Key
Management Framework", draft-ietf-eap-keying-12 (work in
progress), April 2006.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748,
June 2004.
8.2. Informative References
[4] Aboba, B., "EAP Key Management Extensions",
draft-aboba-eap-keying-extens-00 (work in progress),
April 2005.
Narayanan & Dondeti Expires October 22, 2006 [Page 17]
Internet-Draft EAP Keying Gap Analysis April 2006
[5] Institute of Electrical and Electronics Engineers, "Supplement
to Standard for Telecommunications and
Information Exchange Between Systems - LAN/MAN
Specific Requirements - Part 11: Wireless LAN Medium
Access Control (MAC) and Physical Layer (PHY)
Specifications: Specification for Enhanced Security, IEEE
802.11i", July 2004.
[6] Ohba, Y., "Channel Binding Mechanism based on Parameter Binding
in Key Derivation", draft-ohba-eap-channel-binding-00 (work in
progress), January 2006.
[7] Calhoun, P., "CAPWAP Protocol Specification",
draft-ietf-capwap-protocol-specification-00 (work in progress),
March 2006.
[8] Arbaugh, W. and B. Aboba, "Experimental Handoff Extension to
RADIUS", draft-irtf-aaaarch-handoff-04 (work in progress),
November 2003.
[9] Salowey, J. and P. Eronen, "EAP Key Derivation for Multiple
Applications", draft-salowey-eap-key-deriv-02 (work in
progress), October 2003.
[10] Housley, R. and B. Aboba, "Guidance for AAA Key Management",
draft-housley-aaa-key-mgmt-02 (work in progress), March 2006.
[11] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba, "State
Machines for Extensible Authentication Protocol (EAP) Peer and
Authenticator", RFC 4137, August 2005.
[12] Chowdhury, K., "Problem Statement for the AMSK",
draft-chowdhury-hoakey-amsk-ps-00 (work in progress),
February 2006.
[13] Nakhjiri, M., "AAA based Keying for Wireless Handovers: Problem
Statement", draft-nakhjiri-aaa-hokey-ps-01 (work in progress),
January 2006.
[14] Giaretta, G., "Application Master Session Key (AMSK) for Mobile
IPv6", draft-giaretta-mip6-amsk-01 (work in progress),
March 2006.
[15] Institute of Electrical and Electronics Engineers, "IEEE
Standards for Local and Metropolitan Area
Networks: Port based Network Access Control, IEEE Std
802.1X-2004", Dec 2004.
Narayanan & Dondeti Expires October 22, 2006 [Page 18]
Internet-Draft EAP Keying Gap Analysis April 2006
Authors' Addresses
Vidya Narayanan
QUALCOMM, Inc.
5775 Morehouse Dr
San Diego, CA
USA
Phone: +1 858-845-2483
Email: vidyan@qualcomm.com
Lakshminath Dondeti
QUALCOMM, Inc.
5775 Morehouse Dr
San Diego, CA
USA
Phone: +1 858-845-1267
Email: ldondeti@qualcomm.com
Narayanan & Dondeti Expires October 22, 2006 [Page 19]
Internet-Draft EAP Keying Gap Analysis April 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Narayanan & Dondeti Expires October 22, 2006 [Page 20]
| PAFTECH AB 2003-2026 | 2026-04-23 08:36:35 |