draft-ietf-eap-keying-15.txt   draft-ietf-eap-keying-16.txt 
EAP Working Group Bernard Aboba EAP Working Group Bernard Aboba
INTERNET-DRAFT Dan Simon INTERNET-DRAFT Dan Simon
Category: Standards Track Microsoft Category: Standards Track Microsoft
<draft-ietf-eap-keying-15.txt> P. Eronen <draft-ietf-eap-keying-16.txt> P. Eronen
22 October 2006 Nokia 2 January 2007 Nokia
H. Levkowetz H. Levkowetz
Ericsson Research Ericsson Research
Extensible Authentication Protocol (EAP) Key Management Framework Extensible Authentication Protocol (EAP) Key Management Framework
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://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 March 10, 2007. This Internet-Draft will expire on July 10, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society 2006. Copyright (C) The IETF Trust (2007). All rights reserved.
Abstract Abstract
The Extensible Authentication Protocol (EAP), defined in [RFC3748], The Extensible Authentication Protocol (EAP), defined in [RFC3748],
enables extensible network access authentication. This document enables extensible network access authentication. This document
provides a framework for the transport and usage of keying material provides a framework for the transport and usage of keying material
generated by EAP authentication algorithms, known as "methods". It generated by EAP authentication algorithms, known as "methods". It
also specifies the EAP key hierarchy. also specifies the EAP key hierarchy.
Table of Contents Table of Contents
1. Introduction .......................................... 3 1. Introduction .......................................... 3
1.1 Requirements Language ........................... 3 1.1 Requirements Language ........................... 3
1.2 Terminology ..................................... 3 1.2 Terminology ..................................... 3
1.3 Overview ........................................ 6 1.3 Overview ........................................ 6
1.4 EAP Key Hierarchy ............................... 9 1.4 EAP Key Hierarchy ............................... 9
1.5 Security Goals .................................. 13 1.5 Security Goals .................................. 13
1.6 EAP Invariants .................................. 13 1.6 EAP Invariants .................................. 14
2. Lower Layer Operation ................................. 17 2. Lower Layer Operation ................................. 17
2.1 Transient Session Keys .......................... 17 2.1 Transient Session Keys .......................... 18
2.2 Authenticator and Peer Architecture ............. 19 2.2 Authenticator and Peer Architecture ............. 19
2.3 Server Identification ........................... 23 2.3 Server Identification ........................... 24
3. Key Management ........................................ 25 3. Key Management ........................................ 26
3.1 Secure Association Protocol ..................... 26 3.1 Secure Association Protocol ..................... 26
3.2 Key Scope ....................................... 29 3.2 Key Scope ....................................... 29
3.3 Parent-Child Relationships ...................... 29 3.3 Parent-Child Relationships ...................... 30
3.4 Local Key Lifetimes ............................. 30 3.4 Local Key Lifetimes ............................. 30
3.5 Exported and Calculated Key Lifetimes ........... 30 3.5 Exported and Calculated Key Lifetimes ........... 31
3.6 Key Cache Synchronization ....................... 33 3.6 Key Cache Synchronization ....................... 33
3.7 Key Strength .................................... 33 3.7 Key Strength .................................... 33
3.8 Key Wrap ........................................ 34 3.8 Key Wrap ........................................ 34
4. Handoff Vulnerabilities ............................... 34 4. Handoff Vulnerabilities ............................... 34
4.1 EAP Pre-authentication .......................... 35 4.1 EAP Pre-authentication .......................... 35
4.2 Authorization ................................... 36 4.2 Authorization ................................... 36
4.3 Correctness ..................................... 37 4.3 Correctness ..................................... 37
5. Security Considerations .............................. 40 5. Security Considerations .............................. 40
5.1 Authenticator Compromise ........................ 41 5.1 Authenticator Compromise ........................ 41
5.2 Spoofing ........................................ 42 5.2 Spoofing ........................................ 42
5.3 Downgrade Attacks ............................... 42 5.3 Downgrade Attacks ............................... 43
5.4 Unauthorized Disclosure ......................... 43 5.4 Unauthorized Disclosure ......................... 43
5.5 Replay Protection ............................... 45 5.5 Replay Protection ............................... 45
5.6 Key Freshness ................................... 46 5.6 Key Freshness ................................... 46
5.7 Elevation of Privilege .......................... 47 5.7 Elevation of Privilege .......................... 47
5.8 Man-in-the-Middle Attacks ....................... 48 5.8 Man-in-the-Middle Attacks ....................... 48
5.9 Denial of Service Attacks ....................... 48 5.9 Denial of Service Attacks ....................... 48
5.10 Impersonation ................................... 48 5.10 Impersonation ................................... 49
5.11 Channel Binding ................................. 50 5.11 Channel Binding ................................. 50
6. IANA Considerations ................................... 51 6. IANA Considerations ................................... 51
7. References ............................................ 51 7. References ............................................ 51
7.1 Normative References ............................ 51 7.1 Normative References ............................ 51
7.2 Informative References .......................... 51 7.2 Informative References .......................... 51
Acknowledgments .............................................. 56 Acknowledgments .............................................. 56
Author's Addresses ........................................... 57 Author's Addresses ........................................... 57
Appendix A - Exported Parameters in Existing Methods ......... 58 Appendix A - Exported Parameters in Existing Methods ......... 58
Intellectual Property Statement .............................. 59 Intellectual Property Statement .............................. 60
Disclaimer of Validity ....................................... 60 Disclaimer of Validity ....................................... 60
Copyright Statement .......................................... 60 Copyright Statement .......................................... 60
1. Introduction 1. Introduction
The Extensible Authentication Protocol (EAP), defined in [RFC3748], The Extensible Authentication Protocol (EAP), defined in [RFC3748],
was designed to enable extensible authentication for network access was designed to enable extensible authentication for network access
in situations in which the Internet Protocol (IP) protocol is not in situations in which the Internet Protocol (IP) protocol is not
available. Originally developed for use with Point-to-Point Protocol available. Originally developed for use with Point-to-Point Protocol
(PPP) [RFC1661], it has subsequently also been applied to IEEE 802 (PPP) [RFC1661], it has subsequently also been applied to IEEE 802
wired networks [IEEE-802.1X], wireless networks such as wired networks [IEEE-802.1X], wireless networks such as
[IEEE-802.11i] d [IEEE-802.16e], and IKEv2 [RFC4306]. [IEEE-802.11i], [IEEE-802.16e], and IKEv2 [RFC4306].
This document provides a framework for the transport and usage of This document provides a framework for the transport and usage of
keying material generated by EAP authentication algorithms, known as keying material generated by EAP authentication algorithms, known as
"methods". In EAP, keying material is generated by EAP methods. "methods". In EAP, keying material is generated by EAP methods.
Part of this keying material may be used by EAP methods themselves Part of this keying material may be used by EAP methods themselves
and part of this material may be exported. The exported keying and part of this material may be exported. The exported keying
material may be transported by Authentication, Authorization and material may be transported by Authentication, Authorization and
Accounting (AAA) protocols and used by Secure Association Protocols Accounting (AAA) protocols and used by Secure Association Protocols
in the generation or transport of session keys which are used by in the generation or transport of session keys which are used by
lower layer ciphersuites. This document describes each of these lower layer ciphersuites. This document describes each of these
skipping to change at page 11, line 47 skipping to change at page 11, line 47
V V V V V V V V V V
Figure 2: EAP Method Parameter Import/Export Figure 2: EAP Method Parameter Import/Export
Session-Id Session-Id
The Session-Id uniquely identifies an EAP session between an EAP The Session-Id uniquely identifies an EAP session between an EAP
peer (as identified by the Peer-Id) and server (as identified by peer (as identified by the Peer-Id) and server (as identified by
the Server-Id). Where the EAP Type Code is less than 255, the EAP the Server-Id). Where the EAP Type Code is less than 255, the EAP
Session-Id consists of the concatenation of the EAP Type Code and Session-Id consists of the concatenation of the EAP Type Code and
a temporally unique identifier obtained from the method. Where a temporally unique identifier obtained from the method (known as
expanded EAP Type Codes are used, the EAP Session-Id consists of the Method-Id). Where expanded EAP Type Codes are used, the EAP
the Expanded Type Code (including the Type, Vendor-Id and Vendor- Session-Id consists of the Expanded Type Code (including the Type,
Type fields defined in [RFC3748] Section 5.7) concatenated with a Vendor-Id and Vendor-Type fields defined in [RFC3748] Section 5.7)
temporally unique identifier obtained from the method. This concatenated with a temporally unique identifier obtained from the
unique identifier is typically constructed from nonces or method (Method-Id). This unique identifier is typically
counters used within the EAP method exchange. The inclusion of constructed from nonces or counters used within the EAP method
the Type Code in the EAP Session-Id ensures that each EAP method exchange. The inclusion of the Type Code in the EAP Session-Id
has a distinct Session-Id space. Since an EAP session is not ensures that each EAP method has a distinct Session-Id space.
bound to a particular authenticator or specific ports on the peer Since an EAP session is not bound to a particular authenticator or
and authenticator, the authenticator port or identity are not specific ports on the peer and authenticator, the authenticator
included in the Session-Id. port or identity are not included in the Session-Id.
Channel Bindings Channel Bindings
Channel Bindings include lower layer parameters that are verified Channel Bindings include lower layer parameters that are verified
for consistency between the EAP peer and server. In order to for consistency between the EAP peer and server. In order to
avoid introducing media dependencies, EAP methods that transport avoid introducing media dependencies, EAP methods that transport
Channel Binding data MUST treat this data as opaque octets. See Channel Binding data MUST treat this data as opaque octets. See
Section 5.11 for further discussion. Section 5.11 for further discussion.
1.4.1. Key Naming 1.4.1. Key Naming
skipping to change at page 13, line 28 skipping to change at page 13, line 28
is discussed in Sections 3.4, 3.5 and 5.6. is discussed in Sections 3.4, 3.5 and 5.6.
Completion of the AAA exchange (Phase 1b) results in the transport of Completion of the AAA exchange (Phase 1b) results in the transport of
EAP keying material from the EAP server (identified by the Server-Id) EAP keying material from the EAP server (identified by the Server-Id)
to the EAP authenticator (identified by the NAS-Identifier) without to the EAP authenticator (identified by the NAS-Identifier) without
disclosure to any other party. Both the EAP server and EAP disclosure to any other party. Both the EAP server and EAP
authenticator know this keying material to be fresh. Disclosure authenticator know this keying material to be fresh. Disclosure
issues are discussed in Section 5.4; security properties of AAA issues are discussed in Section 5.4; security properties of AAA
protocols are discussed in Sections 5.1-5.7, and 5.10. protocols are discussed in Sections 5.1-5.7, and 5.10.
The backend authentication server is trusted to only transport EAP
keying material to the authenticator that was established with the
peer, and it is trusted to transport that EAP keying material to no
other parties. In many systems, EAP keying material established by
the EAP peer and EAP server are combined with publicly available data
to derive other keys. The backend authentication server is trusted
to refrain from deriving these same keys or acting as a man-in-the-
middle even though it has access to the EAP keying material that is
needed to do so. The authenticator is also a trusted party. It is
trusted not to provide EAP keying material it obtains from the
backend authentication server to any other parties.
Completion of the Secure Association Protocol (Phase 2) results in Completion of the Secure Association Protocol (Phase 2) results in
the derivation or transport of Transient Session Keys (TSKs) known the derivation or transport of Transient Session Keys (TSKs) known
only to the EAP peer (identified by the Peer-Id) and authenticator only to the EAP peer (identified by the Peer-Id) and authenticator
(identified by the NAS-Identifier). Both the EAP peer and (identified by the NAS-Identifier). Both the EAP peer and
authenticator know the TSKs to be fresh. Both the EAP peer and authenticator know the TSKs to be fresh. Both the EAP peer and
authenticator demonstrate that they are authorized to perform their authenticator demonstrate that they are authorized to perform their
roles. Authorization issues are discussed in Section 5.7 and 5.8; roles. Authorization issues are discussed in Section 5.7 and 5.8;
security properties of Secure Association Protocols are discussed in security properties of Secure Association Protocols are discussed in
Section 3.1. Section 3.1.
skipping to change at page 21, line 5 skipping to change at page 21, line 18
communicated by using a single endpoint address. Instead, it is communicated by using a single endpoint address. Instead, it is
RECOMMENDED that the EAP peer and authenticator consistently identify RECOMMENDED that the EAP peer and authenticator consistently identify
themselves utilizing explicit identifiers, rather than endpoint themselves utilizing explicit identifiers, rather than endpoint
addresses or port identifiers. addresses or port identifiers.
AAA protocols such as RADIUS [RFC3579] and Diameter [RFC4072] provide AAA protocols such as RADIUS [RFC3579] and Diameter [RFC4072] provide
a mechanism for the identification of AAA clients; since the EAP a mechanism for the identification of AAA clients; since the EAP
authenticator and AAA client are always co-resident, this mechanism authenticator and AAA client are always co-resident, this mechanism
is applicable to the identification of EAP authenticators. is applicable to the identification of EAP authenticators.
RADIUS [RFC2865] requires that an Access-Request packet contain one
or more of the NAS-Identifier, NAS-IP-Address and NAS-IPv6-Address
attributes. Since a NAS may have more than one IP address, the NAS-
Identifier attribute is RECOMMENDED for explicit identification of
the authenticator, both within the AAA protocol exchange and the
Secure Association Protocol conversation.
+-+-+-+-+ +-+-+-+-+
| EAP | | EAP |
| Peer | | Peer |
+-+-+-+-+ +-+-+-+-+
| | | Peer Ports | | | Peer Ports
/ | \ / | \
/ | \ / | \
/ | \ / | \
/ | \ / | \
/ | \ / | \
skipping to change at page 21, line 45 skipping to change at page 22, line 4
(optional) \ | \ | (optional) \ | \ |
\ | \ | \ | \ |
\ | \ | \ | \ |
\ | \ | \ | \ |
+-+-+-+-+-+ +-+-+-+-+-+ Backend +-+-+-+-+-+ +-+-+-+-+-+ Backend
| EAP | | EAP | Authentication | EAP | | EAP | Authentication
| Server1 | | Server2 | Servers | Server1 | | Server2 | Servers
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
Figure 3: Relationship between EAP peer, authenticator and server Figure 3: Relationship between EAP peer, authenticator and server
RADIUS [RFC2865] requires that an Access-Request packet contain one
or more of the NAS-Identifier, NAS-IP-Address and NAS-IPv6-Address
attributes. Since a NAS may have more than one IP address, the NAS-
Identifier attribute is RECOMMENDED for explicit identification of
the authenticator, both within the AAA protocol exchange and the
Secure Association Protocol conversation.
Problems which may arise where the peer and authenticator implicitly Problems which may arise where the peer and authenticator implicitly
identify themselves using endpoint addresses include the following: identify themselves using endpoint addresses include the following:
[a] It may not be obvious to the peer which authenticator ports are [a] It may not be obvious to the peer which authenticator ports are
associated with which authenticators. The EAP peer will be unable associated with which authenticators. The EAP peer will be unable
to determine whether EAP keying material has been shared outside to determine whether EAP keying material has been shared outside
its authorized scope, and needs to be considered compromised. The its authorized scope, and needs to be considered compromised. The
EAP peer may also be unable to utilize the authenticator key cache EAP peer may also be unable to utilize the authenticator key cache
in an efficient way. in an efficient way.
skipping to change at page 23, line 16 skipping to change at page 23, line 29
phase 2a. phase 2a.
[k] Utilizing the advertised lower layer identities to enable the peer [k] Utilizing the advertised lower layer identities to enable the peer
and authenticator to verify that keys are maintained within the and authenticator to verify that keys are maintained within the
advertised scope. advertised scope.
2.2.2. Virtual Authenticators 2.2.2. Virtual Authenticators
When a single physical authenticator advertises itself as multiple When a single physical authenticator advertises itself as multiple
"virtual authenticators", if the virtual authenticators do not "virtual authenticators", if the virtual authenticators do not
maintain logically separate key caches, then by authenticating to maintain logically separate key caches, then by authenticating to one
one virtual authenticator, the peer can gain access to the other virtual authenticator, the peer can gain access to the other virtual
virtual authenticators sharing a key cache. authenticators sharing a key cache.
For example, where a physical authenticator implements "Guest" and For example, where a physical authenticator implements "Guest" and
"Corporate Intranet" virtual authenticators, an attacker acting as a "Corporate Intranet" virtual authenticators, an attacker acting as a
peer could authenticate with the "Guest" "virtual authenticator" and peer could authenticate with the "Guest" "virtual authenticator" and
derive EAP keying material. If the "Guest" and "Corporate Intranet" derive EAP keying material. If the "Guest" and "Corporate Intranet"
virtual authenticators share a key cache, then the peer can utilize virtual authenticators share a key cache, then the peer can utilize
the EAP keying material derived for the "Guest" network to obtain the EAP keying material derived for the "Guest" network to obtain
access to the "Corporate Intranet" network. access to the "Corporate Intranet" network.
In order to address this vulnerability: In order to address this vulnerability:
skipping to change at page 31, line 25 skipping to change at page 31, line 37
keying material within the key cache. In this case the lifetime of keying material within the key cache. In this case the lifetime of
exported keys can be managed as a system parameter on the peer and exported keys can be managed as a system parameter on the peer and
authenticator; a default lifetime of 8 hours is RECOMMENDED. authenticator; a default lifetime of 8 hours is RECOMMENDED.
3.5.1. AAA Protocols 3.5.1. AAA Protocols
AAA protocols such as RADIUS [RFC2865] and Diameter [RFC4072] can be AAA protocols such as RADIUS [RFC2865] and Diameter [RFC4072] can be
used to communicate the maximum exported key lifetime from the used to communicate the maximum exported key lifetime from the
backend authentication server to the authenticator. backend authentication server to the authenticator.
The Session-Timeout attribue is defined for RADIUS in [RFC2865] and The Session-Timeout attribute is defined for RADIUS in [RFC2865] and
for Diameter in [RFC4005]. Where EAP is used for authentication, for Diameter in [RFC4005]. Where EAP is used for authentication,
[RFC3580] Section 3.17 indicates that a Session-Timeout attribute [RFC3580] Section 3.17 indicates that a Session-Timeout attribute
sent in an Access-Accept along with a Termination-Action value of sent in an Access-Accept along with a Termination-Action value of
RADIUS-Request specifies the maximum number of seconds of service RADIUS-Request specifies the maximum number of seconds of service
provided prior to EAP re-authentication. provided prior to EAP re-authentication.
However, there is also a need to be able to specify the maximum However, there is also a need to be able to specify the maximum
lifetime of cached keying material. Where EAP pre-authentication is lifetime of cached keying material. Where EAP pre-authentication is
supported, cached keys can be pre-established on the authenticator supported, cached keys can be pre-established on the authenticator
prior to session start, and will remain there until they expire. EAP prior to session start, and will remain there until they expire. EAP
skipping to change at page 33, line 6 skipping to change at page 33, line 18
EMSK, and may optionally generate the IV. However, EAP, defined in EMSK, and may optionally generate the IV. However, EAP, defined in
[RFC3748], does not itself support the negotiation of lifetimes for [RFC3748], does not itself support the negotiation of lifetimes for
exported keying material such as the MSK, EMSK and IV. exported keying material such as the MSK, EMSK and IV.
While EAP itself does not support lifetime negotiation, it would be While EAP itself does not support lifetime negotiation, it would be
possible to specify methods that do. However, systems that rely on possible to specify methods that do. However, systems that rely on
such negotiation for exported keys would only function with these such negotiation for exported keys would only function with these
methods. Also, there is no guarantee that the lifetime negotiated methods. Also, there is no guarantee that the lifetime negotiated
within the EAP method would be compatible with backend authentication within the EAP method would be compatible with backend authentication
server policy. In the interest of method independence and server policy. In the interest of method independence and
compatibility with backend server implemenations, key management of compatibility with backend server implementations, key management of
exported or derived keys SHOULD NOT be provided within EAP methods. exported or derived keys SHOULD NOT be provided within EAP methods.
3.6. Key Cache Synchronization 3.6. Key Cache Synchronization
Key lifetime negotiation alone cannot guarantee key cache Key lifetime negotiation alone cannot guarantee key cache
synchronization. Even where a lower layer exchange is run synchronization. Even where a lower layer exchange is run
immediately after EAP in order to determine the lifetime of EAP immediately after EAP in order to determine the lifetime of EAP
keying material, it is still possible for the authenticator to purge keying material, it is still possible for the authenticator to purge
all or part of the key cache prematurely (e.g. due to reboot or need all or part of the key cache prematurely (e.g. due to reboot or need
to reclaim memory). to reclaim memory).
skipping to change at page 34, line 8 skipping to change at page 34, line 16
National Institute for Standards and Technology (NIST) also offers National Institute for Standards and Technology (NIST) also offers
advice on appropriate key sizes in [SP800-57]. advice on appropriate key sizes in [SP800-57].
[RFC3766] Section 5 advises use of the following required RSA or DH [RFC3766] Section 5 advises use of the following required RSA or DH
module and DSA subgroup size in bits, for a given level of attack module and DSA subgroup size in bits, for a given level of attack
resistance in bits: resistance in bits:
Attack Resistance RSA or DH Modulus DSA subgroup Attack Resistance RSA or DH Modulus DSA subgroup
(bits) size (bits) size (bits) (bits) size (bits) size (bits)
----------------- ----------------- ------------ ----------------- ----------------- ------------
70 947 128 70 947 129
80 1228 145 80 1228 148
90 1553 153 90 1553 167
100 1926 184 100 1926 186
150 4575 279 150 4575 284
200 8719 373 200 8719 383
250 14596 475 250 14596 482
3.8. Key Wrap 3.8. Key Wrap
The key wrap specified in [RFC2548], which is based on an MD5-based The key wrap specified in [RFC2548], which is based on an MD5-based
stream cipher, has known problems, as described in [RFC3579] Section stream cipher, has known problems, as described in [RFC3579] Section
4.3. RADIUS uses the shared secret for multiple purposes, including 4.3. RADIUS uses the shared secret for multiple purposes, including
per-packet authentication and attribute hiding, considerable per-packet authentication and attribute hiding, considerable
information is exposed about the shared secret with each packet. information is exposed about the shared secret with each packet.
This exposes the shared secret to dictionary attacks. MD5 is used This exposes the shared secret to dictionary attacks. MD5 is used
both to compute the RADIUS Response Authenticator and the Message- both to compute the RADIUS Response Authenticator and the Message-
skipping to change at page 46, line 47 skipping to change at page 46, line 50
AAA The AAA protocol needs to ensure that transported keying material AAA The AAA protocol needs to ensure that transported keying material
is fresh and is not utilized outside its recommended lifetime. is fresh and is not utilized outside its recommended lifetime.
Replay protection is necessary for key freshness, but an attacker Replay protection is necessary for key freshness, but an attacker
can deliver a stale (and therefore potentially compromised) key in can deliver a stale (and therefore potentially compromised) key in
a replay-protected message, so replay protection is not sufficient. a replay-protected message, so replay protection is not sufficient.
As discussed in Section 3.5, the Session-Timeout attribute enables As discussed in Section 3.5, the Session-Timeout attribute enables
the backend authentication server to limit the exposure of the backend authentication server to limit the exposure of
transported EAP keying material. transported EAP keying material.
The EAP Session-Id, derived from the Expanded EAP Type and the The EAP Session-Id, derived as described in Section 1.4, enables
temporally unique identifier obtained from the method, enables the the EAP peer, authenticator and server to distinguish EAP
EAP peer, authenticator and server to distinguish EAP
conversations. However, unless the authenticator keeps track of conversations. However, unless the authenticator keeps track of
EAP Session-Ids, the authenticator cannot use the Session-Id to EAP Session-Ids, the authenticator cannot use the Session-Id to
guarantee the freshness of EAP keying material. guarantee the freshness of EAP keying material.
Lower Layer Lower Layer
As described in Section 3.1, the lower layer Secure Association As described in Section 3.1, the lower layer Secure Association
Protocol MUST generate a fresh session key for each session, even Protocol MUST generate a fresh session key for each session, even
if the keying material and parameters provided by EAP methods are if the keying material and parameters provided by EAP methods are
cached, or either the peer or authenticator lack a high entropy cached, or either the peer or authenticator lack a high entropy
random number generator. A RECOMMENDED method is for the peer and random number generator. A RECOMMENDED method is for the peer and
skipping to change at page 53, line 17 skipping to change at page 53, line 22
[IEEE-03-084] [IEEE-03-084]
Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang,
"Proactive Key Distribution to support fast and secure "Proactive Key Distribution to support fast and secure
roaming", IEEE 802.11 Working Group, IEEE-03-084r1-I, roaming", IEEE 802.11 Working Group, IEEE-03-084r1-I,
http://www.ieee802.org/11/Documents/DocumentHolder/ http://www.ieee802.org/11/Documents/DocumentHolder/
3-084.zip, January 2003. 3-084.zip, January 2003.
[I-D.housley-aaa-key-mgmt] [I-D.housley-aaa-key-mgmt]
Housley, R. and B. Aboba, "Guidance for AAA Key Housley, R. and B. Aboba, "Guidance for AAA Key
Management", draft-housley-aaa-key-mgmt-04.txt, Internet Management", draft-housley-aaa-key-mgmt-06.txt, Internet
draft (work in progress), October 2006. draft (work in progress), November 2006.
[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-04 (work in Problem", draft-puthenkulam-eap-binding-04, Internet draft
progress), October 2003. (work in progress), October 2003.
[I-D.arkko-eap-service-identity-auth] [I-D.arkko-eap-service-identity-auth]
Arkko, J. and P. Eronen, "Authenticated Service Information Arkko, J. and P. Eronen, "Authenticated Service Information
for the Extensible Authentication Protocol (EAP)", draft- for the Extensible Authentication Protocol (EAP)", draft-
arkko-eap-service-identity-auth-02.txt (work in progress), arkko-eap-service-identity-auth-02.txt Internet draft (work
May 2005. in progress), May 2005.
[I-D.ohba-eap-channel-binding] [I-D.ohba-eap-channel-binding]
Ohba, Y., Parthasrathy, M. and M. Yanagiya, "Channel Ohba, Y., Parthasrathy, M. and M. Yanagiya, "Channel
Binding Mechanism Based on Parameter Binding in Key Binding Mechanism Based on Parameter Binding in Key
Derivation", draft-ohba-eap-channel-binding-00.txt (work in Derivation", draft-ohba-eap-channel-binding-00.txt,
progress), January 2006. Internet draft (work in progress), January 2006.
[I-D.irtf-aaaarch-handoff] [I-D.irtf-aaaarch-handoff]
Arbaugh, W. and B. Aboba, "Handoff Extension to RADIUS", Arbaugh, W. and B. Aboba, "Handoff Extension to RADIUS",
draft-irtf-aaaarch-handoff-04.txt (work in progress), draft-irtf-aaaarch-handoff-04.txt, Internet draft (work in
October 2003. progress), October 2003.
[MD5Collision] [MD5Collision]
Klima, V., "Tunnels in Hash Functions: MD5 Collisions Klima, V., "Tunnels in Hash Functions: MD5 Collisions
Within a Minute", Cryptology ePrint Archive, March 2006, Within a Minute", Cryptology ePrint Archive, March 2006,
http://eprint.iacr.org/2006/105.pdf http://eprint.iacr.org/2006/105.pdf
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994. RFC 1661, July 1994.
[RFC1968] Meyer, G. and K. Fox, "The PPP Encryption Control Protocol [RFC1968] Meyer, G. and K. Fox, "The PPP Encryption Control Protocol
skipping to change at page 55, line 21 skipping to change at page 55, line 27
Arkko, "Diameter Base Protocol", RFC 3588, September 2003. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public
Keys Used For Exchanging Symmetric Keys", RFC 3766, April Keys Used For Exchanging Symmetric Keys", RFC 3766, April
2004. 2004.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M. and K. [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M. and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004. August 2004.
[RFC4005] Calhoun, P., Zorn, G., Spence, D. and D. Mitton, "Diameter
Network Access Server Application", RFC 4005, August 2005
[RFC4017] Stanley, D., Walker, J. and B. Aboba, "EAP Method [RFC4017] Stanley, D., Walker, J. and B. Aboba, "EAP Method
Requirements for Wireless LANs", RFC 4017, March 2005. Requirements for Wireless LANs", RFC 4017, March 2005.
[RFC4067] Loughney, J., Nakhjiri, M., Perkins, C. and R. Koodli, [RFC4067] Loughney, J., Nakhjiri, M., Perkins, C. and R. Koodli,
"Context Transfer Protocol (CXTP)", RFC 4067, July 2005. "Context Transfer Protocol (CXTP)", RFC 4067, July 2005.
[RFC4072] Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible [RFC4072] Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application", RFC 4072, Authentication Protocol (EAP) Application", RFC 4072,
August 2005. August 2005.
skipping to change at page 56, line 7 skipping to change at page 56, line 16
4306, December 2005. 4306, December 2005.
[RFC4372] Adrangi, F., Lior, A., Korhonen, J. and J. Loughney, [RFC4372] Adrangi, F., Lior, A., Korhonen, J. and J. Loughney,
"Chargeable User Identity", RFC 4372, January 2006. "Chargeable User Identity", RFC 4372, January 2006.
[RFC4334] Housley, R. and T. Moore, "Certificate Extensions and [RFC4334] Housley, R. and T. Moore, "Certificate Extensions and
Attributes Suporting Authentication in Point-to-Point Attributes Suporting Authentication in Point-to-Point
Protocol (PPP) and Wireless Local Area Neworks (WLAN)", RFC Protocol (PPP) and Wireless Local Area Neworks (WLAN)", RFC
4334, February 2006. 4334, February 2006.
[RFC4763] Vanderveen, M. and H. Soliman, "Extensible Authentication
Protocol Method for Shared-secret Authentication and Key
Establishment (EAP-SAKE)", RFC 4763, November 2006.
[RFCPSK] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: a
Pre-Shared Key EAP Method", Internet draft (work in
progress), draft-bersani-eap-psk-11.txt, June 2006.
[SP800-57] National Institute of Standards and Technology, [SP800-57] National Institute of Standards and Technology,
"Recommendation for Key Management", Special Publication "Recommendation for Key Management", Special Publication
800-57, May 2006. 800-57, May 2006.
[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.
skipping to change at page 58, line 15 skipping to change at page 58, line 15
Appendix A - Exported Parameters in Existing Methods Appendix A - Exported Parameters in Existing Methods
This Appendix specifies Session-Id, Peer-Id, Server-Id and Key- This Appendix specifies Session-Id, Peer-Id, Server-Id and Key-
Lifetime for EAP methods that have been published prior to this Lifetime for EAP methods that have been published prior to this
specification. Future EAP method specifications MUST include a specification. Future EAP method specifications MUST include a
definition of the Session-Id, Peer-Id, and Server-Id (could be the definition of the Session-Id, Peer-Id, and Server-Id (could be the
empty string). empty string).
EAP-Identity EAP-Identity
The EAP-Identity method is defined in [RC3748]. It does not derive The EAP-Identity method is defined in [RFC3748]. It does not derive
keys, and therefore does not define the Session-Id. The Peer-Id keys, and therefore does not define the Session-Id. The Peer-Id
exported by the Identity method is determined by the octets included exported by the Identity method is determined by the octets included
within the EAP- Response/Identity. The Server-Id is the empty string within the EAP- Response/Identity. The Server-Id is the empty string
(zero length). (zero length).
EAP-Notification EAP-Notification
The EAP-Notification method is defined in [RFC3748]. It does not The EAP-Notification method is defined in [RFC3748]. It does not
derive keys and therefore does not define the Session-Id. The Peer- derive keys and therefore does not define the Session-Id. The Peer-
Id and Server-Id are the empty string (zero length). Id and Server-Id are the empty string (zero length).
skipping to change at page 59, line 26 skipping to change at page 59, line 26
RAND field from the AT_RAND attribute, followed by the contents of RAND field from the AT_RAND attribute, followed by the contents of
the NONCE_MT field in the AT_NONCE_MT attribute. the NONCE_MT field in the AT_NONCE_MT attribute.
The Peer-Id is the contents of the Identity field from the The Peer-Id is the contents of the Identity field from the
AT_IDENTITY attribute, using only the Actual Identity Length octets AT_IDENTITY attribute, using only the Actual Identity Length octets
from the beginning, however. Note that the contents are used as they from the beginning, however. Note that the contents are used as they
are transmitted, regardless of whether the transmitted identity was a are transmitted, regardless of whether the transmitted identity was a
permanent, pseudonym, or fast EAP re-authentication identity. The permanent, pseudonym, or fast EAP re-authentication identity. The
Server-Id is an empty string. Server-Id is an empty string.
EAP-PSK
EAP-PSK is defined in [RFCPSK]. The EAP-PSK Session-Id is the
concatenation of the EAP Type Code (0x2F) with the peer (RAND_P) and
server (RAND_S) nonces. The Peer-Id is the contents of the ID_P
field and the Server-Id is the contents of the ID_S field.
EAP-SAKE
EAP-SAKE is defined in [RFC4763]. The EAP-SAKE Session-Id is the
concatenation of the EAP Type Code (0x30) with the contents of the
RAND_S field from the AT_RAND_S attribute, followed by the contents
of the RAND_P field in the AT_RAND_P attribute. Note that the EAP-
SAKE Session-Id is not the same as the "Session ID" parameter chosen
by the Server, which is sent in the first message, and replicated in
subsequent messages. The Peer-Id is contained within the value field
of the AT_PEERID attibute and the Server-Id, if available, is
contained in the value field of the AT_SERVERID attribute.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 60, line 9 skipping to change at page 60, line 33
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject Copyright (C) The IETF Trust (2007). This document is subject to the
to the rights, licenses and restrictions contained in BCP 78, and rights, licenses and restrictions contained in BCP 78, and except as
except as set forth therein, the authors retain all their rights. set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
Open Issues Open Issues
Open issues relating to this specification are tracked on the Open issues relating to this specification are tracked on the
following web site: following web site:
 End of changes. 32 change blocks. 
66 lines changed or deleted 106 lines changed or added

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