< draft-ietf-eap-keying-00.txt   draft-ietf-eap-keying-01.txt >
EAP Working Group B. Aboba EAP Working Group B. Aboba
Internet-Draft D. Simon Internet-Draft D. Simon
Expires: April 9, 2004 Microsoft Expires: April 26, 2004 Microsoft
J. Arkko J. Arkko
Ericsson Ericsson
H. Levkowetz, Ed. H. Levkowetz, Ed.
ipUnplugged ipUnplugged
October 10, 2003 October 27, 2003
EAP Key Management Framework EAP Key Management Framework
<draft-ietf-eap-keying-00.txt> <draft-ietf-eap-keying-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress". material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 9, 2004. This Internet-Draft will expire on April 26, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This document provides a framework for EAP key management, including This document provides a framework for EAP key management, including
a statement of applicability and guidelines for generation, transport a statement of applicability and guidelines for generation, transport
and usage of EAP keying material. Algorithms for key derivation or and usage of EAP keying material. Algorithms for key derivation or
skipping to change at page 2, line 24 skipping to change at page 2, line 24
1.4 Authorization issues . . . . . . . . . . . . . . . . . 9 1.4 Authorization issues . . . . . . . . . . . . . . . . . 9
1.4.1 Correctness in fast handoff . . . . . . . . . . 11 1.4.1 Correctness in fast handoff . . . . . . . . . . 11
2. EAP Key Hierarchy . . . . . . . . . . . . . . . . . . . . . 13 2. EAP Key Hierarchy . . . . . . . . . . . . . . . . . . . . . 13
2.1 EAP Invariants . . . . . . . . . . . . . . . . . . . . 14 2.1 EAP Invariants . . . . . . . . . . . . . . . . . . . . 14
2.1.1 Media Independence . . . . . . . . . . . . . . . 14 2.1.1 Media Independence . . . . . . . . . . . . . . . 14
2.1.2 Method Independence . . . . . . . . . . . . . . 14 2.1.2 Method Independence . . . . . . . . . . . . . . 14
2.1.3 Ciphersuite Independence . . . . . . . . . . . . 14 2.1.3 Ciphersuite Independence . . . . . . . . . . . . 14
2.2 Key Hierarchy . . . . . . . . . . . . . . . . . . . . 15 2.2 Key Hierarchy . . . . . . . . . . . . . . . . . . . . 15
2.3 Exchanges . . . . . . . . . . . . . . . . . . . . . . 19 2.3 Exchanges . . . . . . . . . . . . . . . . . . . . . . 19
3. Security Associations . . . . . . . . . . . . . . . . . . . 22 3. Security Associations . . . . . . . . . . . . . . . . . . . 22
3.1 EAP SA . . . . . . . . . . . . . . . . . . . . . . . . 23 3.1 EAP SA (peer - EAP server) . . . . . . . . . . . . . . 23
3.2 AAA-Key SA . . . . . . . . . . . . . . . . . . . . . . 24 3.2 EAP method SA (peer - EAP server) . . . . . . . . . . 23
3.3 Unicast Secure Association SA . . . . . . . . . . . . 26 3.2.1 Example: EAP-TLS . . . . . . . . . . . . . . . . 24
3.4 Multicast Secure Association SA . . . . . . . . . . . 27 3.2.2 Example: EAP-AKA . . . . . . . . . . . . . . . . 24
3.5 Key Naming . . . . . . . . . . . . . . . . . . . . . . 28 3.3 EAP-key SA . . . . . . . . . . . . . . . . . . . . . . 25
3.4 AAA SA(s) (authenticator - backend auth. server) . . . 25
3.4.1 Example: RADIUS . . . . . . . . . . . . . . . . 25
3.4.2 Example: Diameter with TLS . . . . . . . . . . . 25
3.5 Unicast Secure Association SA . . . . . . . . . . . . 26
3.6 Multicast Secure Association SA . . . . . . . . . . . 27
3.7 Key Naming . . . . . . . . . . . . . . . . . . . . . . 28
4. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 29 4. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 29
4.1 Security Assumptions . . . . . . . . . . . . . . . . . 29 4.1 Security Assumptions . . . . . . . . . . . . . . . . . 29
4.2 Security Requirements . . . . . . . . . . . . . . . . 32 4.2 Security Requirements . . . . . . . . . . . . . . . . 32
4.2.1 EAP method requirements . . . . . . . . . . . . 32 4.2.1 EAP method requirements . . . . . . . . . . . . 32
4.2.2 AAA Protocol Requirements . . . . . . . . . . . 34 4.2.2 AAA Protocol Requirements . . . . . . . . . . . 34
4.2.3 Secure Association Protocol Requirements . . . . 36 4.2.3 Secure Association Protocol Requirements . . . . 36
4.2.4 Ciphersuite Requirements . . . . . . . . . . . . 37 4.2.4 Ciphersuite Requirements . . . . . . . . . . . . 37
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 38 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 38
6. Security Considerations . . . . . . . . . . . . . . . . . . 38 6. Security Considerations . . . . . . . . . . . . . . . . . . 38
6.1 Key Strength . . . . . . . . . . . . . . . . . . . . . 38 6.1 Key Strength . . . . . . . . . . . . . . . . . . . . . 38
skipping to change at page 14, line 39 skipping to change at page 14, line 39
2.1.2 Method Independence 2.1.2 Method Independence
Supporting pass-through of authentication to the backend Supporting pass-through of authentication to the backend
authentication server enables the authenticator to support any authentication server enables the authenticator to support any
authentication method implemented on the backend authentication authentication method implemented on the backend authentication
server and peer, not just locally implemented methods. server and peer, not just locally implemented methods.
This implies that the authenticator need not implement code for each This implies that the authenticator need not implement code for each
EAP method required by authenticating peers. In fact, the EAP method required by authenticating peers. In fact, the
authenticator is not required to implement any EAP methods at all, authenticator is not required to implement any EAP methods at all,
nor cannot it be assumed to implement code specific to any EAP nor can it be assumed to implement code specific to any EAP method.
method.
This is useful where there is no single EAP method that is both This is useful where there is no single EAP method that is both
mandatory-to-implement and offers acceptable security for the media mandatory-to-implement and offers acceptable security for the media
in use. For example, the [I-D.ietf-eap-rfc2284bis] in use. For example, the [I-D.ietf-eap-rfc2284bis]
mandatory-to-implement EAP method (MD5-Challenge) does not provide mandatory-to-implement EAP method (MD5-Challenge) does not provide
dictionary attack resistance, mutual authentication or key dictionary attack resistance, mutual authentication or key
derivation, and as a result is not appropriate for use in wireless derivation, and as a result is not appropriate for use in wireless
authentication. authentication.
2.1.3 Ciphersuite Independence 2.1.3 Ciphersuite Independence
skipping to change at page 22, line 35 skipping to change at page 22, line 35
The MSK and EMSK are used to derive the AAA-Key and key name which The MSK and EMSK are used to derive the AAA-Key and key name which
are enclosed within the AAA-Token, transported to the NAS by the AAA are enclosed within the AAA-Token, transported to the NAS by the AAA
server, and used within the secure association protocol for server, and used within the secure association protocol for
derivation of Transient Session Keys (TSKs) required for the derivation of Transient Session Keys (TSKs) required for the
negotiated ciphersuite. The TSKs are known only to the peer and negotiated ciphersuite. The TSKs are known only to the peer and
authenticator. authenticator.
3. Security Associations 3. Security Associations
The EAP model has four types of security associations (SAs): EAP key management involves four types of security associations
(SAs):
[1] An EAP SA. This is an SA between the EAP peer and the EAP [1] EAP SA. This is an SA between the peer and EAP server, which
server, created as the result of an EAP authentication exchange allows them to authenticate each other.
(phase 1a). This is a bi-directional SA; that is, both parties
use the information in the SA for both sending and receiving.
[2] A AAA-Key SA, known in [IEEE80211i] as a PMK SA. This is a [2] EAP method SA. This SA is also between the peer and EAP server.
bi-directional SA between the EAP peer and authenticator. The It stores state that can be used for "fast resume" or other
keying material for the AAA-Key SA (known as the AAA-Key) is functionality in some EAP methods. Not all EAP methods create
derived on the EAP peer and server, and transported by the EAP such an SA.
server to the authenticator (phase 1b). The choice of keying
material is proposed by the EAP peer and confirmed by the EAP
authenticator during the unicast secure association protocol
(phase 2a).
[3] A unicast secure association SA. This is a bi-directional SA [3] EAP-Key SA. This is an SA between the peer and EAP server, which
created as the result of a successful unicast secure association is used to store the keying material exported by the EAP method.
exchange (phase 2a). A unicast secure association SA is bound to Current EAP server implementations do not retain this SA after
a single EAP SA and a single AAA-Key SA. the EAP conversation completes, but future implementations could
use this SA for pre-emptive key distribution.
[4] A multicast secure association SA (phase 2b). This SA is created [4] AAA SA(s). These SAs are between the authenticator and the
as the result of a successful multicast secure association backend authentication server. They permit the parties to
exchange. This SA may be uni-directional (e.g. 802.11 group-key mutually authenticate each other and protect the communications
exchange) or bi-directional depending on the design of the between them.
multicast secure association protocol, and can be created either
from the unicast secure association SA (phase 2a) or directly as
the result of a multicast secure association exchange (phase 2b).
3.1 EAP SA 3.1 EAP SA (peer - EAP server)
An EAP SA exists between the EAP peer and server. It includes: In order for the peer and EAP server to authenticate each other, they
need to store some information.
the EAP peer identity The authentication can be based on different mechanisms, such as
the EAP server identity shared secrets or certificates. If the authentication is based on a
the EAP method type shared secret key, the parties store the EAP method to be used and
the EAP peer and server nonces the key. The EAP server also stores the peer's identity and/or other
the Transient EAP Keys (TEKs) information necessary to decide whether access to some service should
the Master Session Key (MSK) be granted. The peer stores information necessary to choose which
the Extended Master Session Key (EMSK) secret to use for which service.
The EAP SA is not explicitly bound to a particular port on the EAP 3.2 EAP method SA (peer - EAP server)
peer. An EAP peer with multiple ports may create an EAP SA on one
port and then choose to use that SA to subsequently create a phase 2
SA on another port.
It cannot be assumed that the EAP SA expires after the EAP An EAP method may store some state on the peer and EAP server even
authentication and key derivation is complete. Some methods may be after phase 1a has completed.
support "fast resume" by caching EAP SA state on the EAP peer and
server.
EAP does not support SA lifetime negotiation or an SA "delete" Typically, this is used for "fast resume": the peer and EAP server
operation, although some EAP methods may support this. Either the can confirm that they are still talking to the same party, perhaps
EAP peer or EAP server may delete an EAP SA at any time, and methods using fewer roundtrips or less computational power. In this case,
which allow an EAP SA to persist need to permit the EAP peer and the EAP method SA is essentially a cache for performance
server to recognize when they have gotten out of sync with respect to optimization, and either party may remove the SA from its cache at
the EAP SA state. any point.
For example, EAP-TLS [RFC2716] supports "fast resume" (TLS session An EAP method may also keep state in order to support pseudonym-based
resumption), which assumes that both the EAP peer and server cache identity protection. This is typically a cache as well (the
EAP master keys (the TLS master secret). An EAP peer attempting a information can be recreated if the original EAP method SA is lost),
fast resume provides the session-id identifying the session that it but may be stored for longer periods of time.
wishes to resume. If the EAP server retains the master key
corresponding to this session in its cache, then the "fast resume"
can proceed; otherwise a full TLS exchange ensues.
An EAP peer may negotiate EAP SAs with one or more EAP servers as the The EAP method SA is not restricted to a particular service or
result of pre-authentication or AAA load balancing and failover authenticator and is most useful when the peer accesses many
effects. For example, an EAP peer may pre-authenticate to one or different authenticators.
more EAP servers, or may be directed to more than one EAP server as
the result of an authentication server becoming unreachable. In
general, EAP servers cannot be assumed to be synchronized with
respect to EAP SA state, particularly since they may not exist within
the same administrative domain. Since an EAP SA is typically created
prior to secure association, the EAP SA is not bound to a particular
target network.
3.2 AAA-Key SA An EAP method is responsible for specifying how the parties select if
an existing EAP method SA should be used, and if so, which one.
Where multiple backend authentication servers are used, EAP method
SAs are not typically synchronized between them.
An AAA-Key SA exists between the authenticator and authentication EAP method implementations should consider the appropriate lifetime
server. It includes: for the EAP method SA. "Fast resume" assumes that the information
required (primarily the keys in the EAP method SA) hasn't been
compromised. In case the original authentication was carried out
using, for instance, a smart card, it may be easier to compromise the
EAP method SA (stored on the PC, for instance), so typically the EAP
method SAs have a limited lifetime.
the EAP peer name Contents:
the NAS/authenticator name o Implicitly, the EAP method this SA refers to
the AAA-Key o One or more internal (non-exported) keys
the AAA-Key maximum lifetime (if known) o EAP method SA name
the AAA attributes sent in the Access-Accept o SA lifetime
The AAA-Key SA is created as the result of the transport of the 3.2.1 Example: EAP-TLS
AAA-Token from the authentication server to the NAS/authenticator.
The AAA-Key SA is more specific than the EAP SA in that it is bound
to a particular authenticator, as defined by the NAS identification
attributes included in the AAA request.
For example, within RADIUS the NAS is identified by the In EAP-TLS [RFC2716], after the EAP authentication the client (peer)
NAS-Identifier, NAS-IP-Address and NAS-IPv6-Address attributes. and server can store the following information:
Unless the attributes providing explicit scoping are providing, it is
assumed that the AAA-Key is usable by the NAS to which it is
delivered, without restriction.
Since the AAA-Key SA is bound to the NAS identified in the AAA o Implicitly, the EAP method this SA refers to (EAP-TLS)
Request, a NAS/authenticator that operates on a shared use network o Session identifier (a value selected by the server)
will share the AAA-Key SA between multiple virtual NAS devices. o Certificate of the other party (server stores the clients's
Since these virtual NAS devices might appear to the peer to be certificate and vice versa)
different NASes, a mechanism is needed for the EAP peer to o Ciphersuite and compression method
differentiate them, so that the peer can determine which devices a o TLS Master secret (known as the EAP-TLS Master Key or MK)
AAA-Key can be used with. o SA lifetime (ensuring that the SA is not stored forever)
o If the client has multiple different credentials (certificates and
corresponding private keys), a pointer to those credentials
In the case of IEEE 802.11, it has been proposed that a "Group When the server initiates EAP-TLS, the client can look up the EAP-TLS
Identifier" be added to the Beacon and Probe Response messages, SA based on the credentials it was going to use (certificate and
containing a MAC address uniquely identifying a particular Access private key), and the expected credentials (certificate or name) of
Point. Such a "Group Identifier" could be included in the the server. If an EAP-TLS SA exists, and it is not too old, the
NAS-Identifier attribute so as to uniquely identify a particular NAS client informs the server about the existence of this SA by including
to the AAA server. its Session-Id in the TLS ClientHello message. The server then looks
up the correct SA based on the Session-Id (or detects that it doesn't
yet have one).
Since a AAA-Key SA may be shared between virtual NASes, it is 3.2.2 Example: EAP-AKA
possible for an EAP peer to successfully complete a fast handoff
between virtual NASes operating on the same physical NAS. Since the
virtual NASes may have access to different networks or even exist
within different administrative domains, this creates a security
problem unless the AAA attributes are applied to the new session.
For example, an EAP peer authenticating to a GUEST network could In EAP-AKA [I-D.arkko-pppext-eap-aka], after EAP authentication the
successfully complete a fast handoff to the CORPORATE network. This client and server can store the following information:
would be harmless if it only resulted in the peer receiving the GUEST
service, without obtaining additional time on the network.
Existing RADIUS attributes may not be adequate to this task. For o Implicitly, the EAP method this SA refers to (EAP-AKA)
example, today there are no standard attributes usable to indicate: o A re-authentication pseudonym
o The client's permanent identity (IMSI) (server)
o Replay protection counter
o Authentication key (K_aut)
o Encryption key (K_encr)
o Original Master Key (MK)
o SA lifetime (ensuring that the SA is not stored forever)
[a] Which SSIDs a peer is authorized to attach to. When the server initiates EAP-AKA, the client can look up the EAP-AKA
SA based on the credentials it was going to use (permanent identity).
If an EAP-AKA SA exists, and it is not too old, the client informs
the server about the existence of this SA by sending its
re-authentication pseudonym as its identity in EAP Identity Response
message, instead of its permanent identity. The server then looks up
the correct SA based on this identity.
[b] The absolute time at which a session is to end (as opposed to the 3.3 EAP-key SA
Session-Time attribute which is relative)
[c] The times of day during which access is allowed This is an SA between the peer and EAP server, which is used to store
the keying material exported by the EAP method. Current EAP server
implementations do not retain this SA after the EAP conversation
completes, but future implementations could use this SA for
pre-emptive key distribution.
[d] The Calling-Station-Ids from which a client may access the Contents:
network o Name/identifier for this SA
o Identities of the parties
o MSK and EMSK
[e] Whether fast handoff is permitted. 3.4 AAA SA(s) (authenticator - backend auth. server)
Attribute a) is useful so that when a client attempts a fast handoff In order for the authenticator and backend authentication server to
to the CORPORATE network from the GUEST network, the NAS checking the authenticate each other, they need to store some information.
AAA attributes will discover that the peer is only authorized for
GUEST, not CORPORATE. As a result, the fast handoff attempt will
fail.
Attribute b) can be used to prevent a peer attempting a fast handoff In case the authenticator and backend authentication server are
between the GUEST network and another network from obtaining colocated, and they communicate using local procedure calls or shared
additional session time. memory, this SA need not necessarily contain any information.
Attribute c) can be used to prevent a peer from accessing the network 3.4.1 Example: RADIUS
outside of authorized hours.
Attribute d) can be used to ensure that a peer is accessing the In RADIUS, where shared secret authentication is used, the client and
network only from an administrator-authorized NIC. This might be server store each other's IP address and the shared secret, which is
important in high security installations. used to calculate the Response Authenticator [RFC2865] and
Message-Authenticator [RFC3579] values, and to encrypt some
attributes (such as the AAA-Key [RFC2548]).
Attribute e) might be useful in situations where the administrator Where IPsec is used to protect RADIUS [RFC3579] and IKE is used for
desires to limit deployment of fast handoff. key management, the parties store information necessary to
authenticate and authorize the other party (e.g. certificates, trust
anchors and names). The IKE exchange results in IKE Phase 1 and
Phase 2 SAs containing information used to protect the conversation
(session keys, selected ciphersuite, etc.)
In fast handoff, a single EAP SA may be used to establish multiple 3.4.2 Example: Diameter with TLS
AAA- Key SAs (see Appendix E for details). Although a AAA-Key SA may
not persist longer than the maximum SA lifetime negotiated for an EAP
SA (for methods that support such a negotiation), if an EAP SA is
deleted by an EAP peer or authenticator, this does not necessarily
imply deletion of the child AAA-Key SA. For example, fast handoff
keying material provided by an authentication server may continue to
be cached by NASes/authenticators after the corresponding EAP SA has
been deleted by the authentication server and/or peer.
3.3 Unicast Secure Association SA When using Diameter protected by TLS, the parties store information
necessary to authenticate and authorize the other party (e.g.
certificates, trust anchors and names). The TLS handshake results in
a short-term TLS SA that contains information used to protect the
actual communications (session keys, selected TLS ciphersuite, etc.).
3.5 Unicast Secure Association SA
The unicast secure association SA exists between the EAP peer and The unicast secure association SA exists between the EAP peer and
authenticator. It includes: authenticator. It includes:
the peer port identifier (Calling-Station-Id) the peer port identifier (Calling-Station-Id)
the NAS port identifier (Called-Station-Id) the NAS port identifier (Called-Station-Id)
the unicast Transient Session Keys (TSKs) the unicast Transient Session Keys (TSKs)
the unicast secure association peer nonce the unicast secure association peer nonce
the unicast secure association authenticator nonce the unicast secure association authenticator nonce
the negotiated unicast capabilities and unicast ciphersuite. the negotiated unicast capabilities and unicast ciphersuite.
skipping to change at page 27, line 36 skipping to change at page 27, line 29
On some media (e.g. 802.11) a port on an EAP peer may only establish On some media (e.g. 802.11) a port on an EAP peer may only establish
phase 2a and 2b SAs with a single port of an authenticator within a phase 2a and 2b SAs with a single port of an authenticator within a
given Local Area Network (LAN). This implies that the successful given Local Area Network (LAN). This implies that the successful
negotiation of phase 2a and/or 2b SAs between an EAP peer port and a negotiation of phase 2a and/or 2b SAs between an EAP peer port and a
new authentiator port within a given LAN implies the deletion of new authentiator port within a given LAN implies the deletion of
existing phase 2a and 2b SAs with authenticators offering access to existing phase 2a and 2b SAs with authenticators offering access to
that Local Area Network (LAN). However, since a given IEEE 802.11 that Local Area Network (LAN). However, since a given IEEE 802.11
SSID may be comprised of multiple LANs, this does not imply an SSID may be comprised of multiple LANs, this does not imply an
implicit binding of phase 2a and 2b SAs to an SSID. implicit binding of phase 2a and 2b SAs to an SSID.
3.4 Multicast Secure Association SA 3.6 Multicast Secure Association SA
The multicast secure association SA includes: The multicast secure association SA includes:
the multicast Transient Session Keys the multicast Transient Session Keys
the direction vector (for a uni-directional SA) the direction vector (for a uni-directional SA)
the negotiated multicast capabilities and multicast ciphersuite the negotiated multicast capabilities and multicast ciphersuite
It is possible for more than one multicast secure association SA to It is possible for more than one multicast secure association SA to
be derived from a single unicast secure association SA. However, a be derived from a single unicast secure association SA. However, a
multicast secure association SA is bound to a single EAP SA and a multicast secure association SA is bound to a single EAP SA and a
skipping to change at page 28, line 25 skipping to change at page 28, line 19
Similarly, the deletion of a multicast secure association protocol SA Similarly, the deletion of a multicast secure association protocol SA
does not imply the deletion of the parent EAP, AAA-Key or unicast does not imply the deletion of the parent EAP, AAA-Key or unicast
secure association SA. Failure to mutually prove possession of the secure association SA. Failure to mutually prove possession of the
AAA-Key during the unicast secure association protocol exchange AAA-Key during the unicast secure association protocol exchange
(phase 2a) need not be grounds for removal of the AAA-Key, unicast (phase 2a) need not be grounds for removal of the AAA-Key, unicast
secure association and multicast secure association SAs; secure association and multicast secure association SAs;
rate-limiting unicast secure association exchanges should suffice to rate-limiting unicast secure association exchanges should suffice to
prevent a brute force attack. prevent a brute force attack.
3.5 Key Naming 3.7 Key Naming
In order to support the correct processing of phase 2 security In order to support the correct processing of phase 2 security
associations, the secure association (phase 2) protocol supports the associations, the secure association (phase 2) protocol supports the
naming of phase 2 security associations and associated transient naming of phase 2 security associations and associated transient
session keys, so that the correct set of transient session keys can session keys, so that the correct set of transient session keys can
be identified for processing a given packet. Explicit creation and be identified for processing a given packet. Explicit creation and
deletion operations are also typically supported so that deletion operations are also typically supported so that
establishment and re-establishment of transient session keys can be establishment and re-establishment of transient session keys can be
synchronized between the parties. synchronized between the parties.
In order to securely bind the AAA-Key security association (phase 1b) In order to securely bind the AAA SA (phase 1b) to its child phase 2
to its child phase 2 security associations, the phase 2 secure security associations, the phase 2 secure association protocol allows
association protocol allows the EAP peer and authenticator to the EAP peer and authenticator to mutually prove possession of the
mutually prove possession of the AAA-Key. In order to avoid AAA-Key. In order to avoid confusion in the case where an EAP peer
confusion in the case where an EAP peer has more than one AAA-Key has more than one AAA-Key (phase 1b) applicable to establishment of a
(phase 1b) applicable to establishment of a phase 2 security phase 2 security association, it is necessary for the secure
association, it is necessary for the secure association protocol association protocol (phase 2) to support key selection, so that the
(phase 2) to support key selection, so that the appropriate phase 1b appropriate phase 1b keying material can be utilized by both parties
keying material can be utilized by both parties in the secure in the secure association protocol exchange.
association protocol exchange.
For example, a peer might be pre-configured with policy indicating For example, a peer might be pre-configured with policy indicating
the ciphersuite to be used in communicating with a given the ciphersuite to be used in communicating with a given
authenticator. Within PPP, the ciphersuite is negotiated within the authenticator. Within PPP, the ciphersuite is negotiated within the
Encryption Control Protocol (ECP), after EAP authentication is Encryption Control Protocol (ECP), after EAP authentication is
completed. Within [IEEE80211i], the AP ciphersuites are advertised completed. Within [IEEE80211i], the AP ciphersuites are advertised
in the Beacon and Probe Responses, and are securely verified during a in the Beacon and Probe Responses, and are securely verified during a
4-way exchange after EAP authentication has completed. 4-way exchange after EAP authentication has completed.
As part of the secure association protocol (phase 2), it is necessary As part of the secure association protocol (phase 2), it is necessary
to bind the Transient Session Keys (TSKs) to the keying material to bind the Transient Session Keys (TSKs) to the keying material
provided in the AAA-Token. This ensures that the EAP peer and provided in the AAA-Token. This ensures that the EAP peer and
authenticator are both clear about what key to use to provide mutual authenticator are both clear about what key to use to provide mutual
proof of possession. Keys within the EAP key hierarchy are named as proof of possession. Keys within the EAP key hierarchy are named as
follows: follows:
EAP SA name EAP SA name
The EAP security association is negotiated between the EAP peer The EAP security association is negotiated between the EAP peer
and EAP server, and is uniquely named as follows <EAP peer name, and EAP server, and is uniquely named as follows <EAP peer name,
EAP server name, EAP Method Type, EAP peer nonce, EAP server EAP server name, EAP Method Type, EAP peer nonce, EAP server
nonce>. Here the EAP peer name and EAP server name are the nonce>. Here the EAP peer name and EAP server name are the
identifiers securely exchanged within the EAP method. Since identifiers securely exchanged within the EAP method. Since
multiple EAP SAs may exist between an EAP peer and EAP server, the multiple EAP SAs may exist between an EAP peer and EAP server, the
EAP peer nonce and EAP server nonce allow EAP SAs to be EAP peer nonce and EAP server nonce allow EAP SAs to be
differentiated. The inclusion of the Method Type in the EAP SA differentiated. The inclusion of the Method Type in the EAP SA
name ensures that each EAP method has a distinct EAP SA space. name ensures that each EAP method has a distinct EAP SA space.
MK Name MK Name
The EAP Master Key, if supported by an EAP method, is named by the The EAP Master Key, if supported by an EAP method, is named by the
concatenation of the EAP SA name and a method-specific session-id. concatenation of the EAP SA name and a method-specific session-id.
skipping to change at page 44, line 50 skipping to change at page 44, line 50
Aboba, B., "Certificate-Based Roaming", Aboba, B., "Certificate-Based Roaming",
draft-ietf-roamops-cert-02 (work in progress), April 1999. draft-ietf-roamops-cert-02 (work in progress), April 1999.
[I-D.ietf-aaa-eap] [I-D.ietf-aaa-eap]
Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application", Authentication Protocol (EAP) Application",
draft-ietf-aaa-eap-02 (work in progress), July 2003. draft-ietf-aaa-eap-02 (work in progress), July 2003.
[I-D.irtf-aaaarch-handoff] [I-D.irtf-aaaarch-handoff]
Arbaugh, W. and B. Aboba, "Experimental Handoff Extension Arbaugh, W. and B. Aboba, "Experimental Handoff Extension
to RADIUS", draft-irtf-aaaarch-handoff-02 (work in to RADIUS", draft-irtf-aaaarch-handoff-03 (work in
progress), May 2003. progress), October 2003.
[I-D.orman-public-key-lengths] [I-D.orman-public-key-lengths]
Orman, H. and P. Hoffman, "Determining Strengths For Orman, H. and P. Hoffman, "Determining Strengths For
Public Keys Used For Exchanging Symmetric Keys", Public Keys Used For Exchanging Symmetric Keys",
draft-orman-public-key-lengths-05 (work in progress), draft-orman-public-key-lengths-05 (work in progress),
January 2002. January 2002.
[I-D.puthenkulam-eap-binding] [I-D.puthenkulam-eap-binding]
Puthenkulam, J., "The Compound Authentication Binding Puthenkulam, J., "The Compound Authentication Binding
Problem", draft-puthenkulam-eap-binding-03 (work in Problem", draft-puthenkulam-eap-binding-03 (work in
progress), July 2003. progress), July 2003.
[I-D.aboba-802-context] [I-D.aboba-802-context]
Aboba, B. and T. Moore, "A Model for Context Transfer in Aboba, B. and T. Moore, "A Model for Context Transfer in
IEEE 802", draft-aboba-802-context-03 (work in progress), IEEE 802", draft-aboba-802-context-03 (work in progress),
October 2003. October 2003.
[I-D.arkko-pppext-eap-aka]
Arkko, J. and H. Haverinen, "EAP AKA Authentication",
draft-arkko-pppext-eap-aka-10 (work in progress), June
2003.
[8021XHandoff] [8021XHandoff]
Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff in a Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff in a
Public Wireless LAN Based on IEEE 802.1X Model", School of Public Wireless LAN Based on IEEE 802.1X Model", School of
Computer Science and Engineering, Seoul National Computer Science and Engineering, Seoul National
University, Seoul, Korea, 2002. University, Seoul, Korea, 2002.
[MD5Attack] [MD5Attack]
Dobbertin, H., "The Status of MD5 After a Recent Attack", Dobbertin, H., "The Status of MD5 After a Recent Attack",
CryptoBytes, Vol.2 No.2, 1996. CryptoBytes, Vol.2 No.2, 1996.
skipping to change at page 46, line 22 skipping to change at page 46, line 22
EMail: dansimon@microsoft.com EMail: dansimon@microsoft.com
Jari Arkko Jari Arkko
Ericsson Ericsson
Jorvas 02420 Jorvas 02420
Finland Finland
Phone: Phone:
EMail: jari.arkko@ericsson.com EMail: jari.arkko@ericsson.com
Henrik Levkowetz Henrik Levkowetz (editor)
ipUnplugged AB ipUnplugged AB
Arenavagen 27 Arenavagen 27
Stockholm S-121 28 Stockholm S-121 28
SWEDEN SWEDEN
Phone: +46 708 32 16 08 Phone: +46 708 32 16 08
EMail: henrik@levkowetz.com EMail: henrik@levkowetz.com
Appendix A. Ciphersuite Keying Requirements Appendix A. Ciphersuite Keying Requirements
skipping to change at page 50, line 5 skipping to change at page 50, line 5
(Auth-Send-Key) (Auth-Send-Key)
IV(0,31) = Peer to Authenticator Initialization Vector IV(0,31) = Peer to Authenticator Initialization Vector
(RECV-IV) (RECV-IV)
IV(32,63) = Authenticator to Peer Initialization vector IV(32,63) = Authenticator to Peer Initialization vector
(SEND-IV) (SEND-IV)
Where: Where:
AAA-Key(W,Z) = Octets W through Z includes of the AAA-Key. AAA-Key(W,Z) = Octets W through Z inclusive of the AAA-Key.
IV(W,Z) = Octets W through Z inclusive of the IV. IV(W,Z) = Octets W through Z inclusive of the IV.
MSK(W,Z) = Octets W through Z inclusive of the MSK. MSK(W,Z) = Octets W through Z inclusive of the MSK.
EMSK(W,Z) = Octets W through Z inclusive of the EMSK. EMSK(W,Z) = Octets W through Z inclusive of the EMSK.
MK = TLS master_secret MK = TLS master_secret
TLS-PRF-X = TLS PRF function [RFC2246], computed to X octets TLS-PRF-X = TLS PRF function [RFC2246], computed to X octets
 End of changes. 50 change blocks. 
168 lines changed or deleted 171 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/