draft-ietf-emu-eaptunnel-req-02.txt   draft-ietf-emu-eaptunnel-req-03.txt 
EMU Working Group K. Hoeper EMU Working Group K. Hoeper
Internet-Draft Motorola, Inc. Internet-Draft Motorola, Inc.
Intended status: Informational S. Hanna Intended status: Informational S. Hanna
Expires: August 31, 2009 Juniper Networks Expires: January 7, 2010 Juniper Networks
H. Zhou H. Zhou
J. Salowey, Ed. J. Salowey, Ed.
Cisco Systems, Inc. Cisco Systems, Inc.
February 27, 2009 July 6, 2009
Requirements for a Tunnel Based EAP Method Requirements for a Tunnel Based EAP Method
draft-ietf-emu-eaptunnel-req-02.txt draft-ietf-emu-eaptunnel-req-03.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 August 31, 2009. This Internet-Draft will expire on January 7, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
skipping to change at page 3, line 22 skipping to change at page 3, line 22
3.1. Password Authentication . . . . . . . . . . . . . . . . . 6 3.1. Password Authentication . . . . . . . . . . . . . . . . . 6
3.2. Protection of Weak EAP Methods . . . . . . . . . . . . . . 6 3.2. Protection of Weak EAP Methods . . . . . . . . . . . . . . 6
3.3. Chained EAP Methods . . . . . . . . . . . . . . . . . . . 7 3.3. Chained EAP Methods . . . . . . . . . . . . . . . . . . . 7
3.4. Identity Protection . . . . . . . . . . . . . . . . . . . 7 3.4. Identity Protection . . . . . . . . . . . . . . . . . . . 7
3.5. Emergency Services Authentication . . . . . . . . . . . . 7 3.5. Emergency Services Authentication . . . . . . . . . . . . 7
3.6. Network Endpoint Assessment . . . . . . . . . . . . . . . 8 3.6. Network Endpoint Assessment . . . . . . . . . . . . . . . 8
3.7. Client Authentication During Tunnel Establishment . . . . 8 3.7. Client Authentication During Tunnel Establishment . . . . 8
3.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 8 3.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 8
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. General Requirements . . . . . . . . . . . . . . . . . . . 8 4.1. General Requirements . . . . . . . . . . . . . . . . . . . 9
4.1.1. RFC Compliance . . . . . . . . . . . . . . . . . . . . 8 4.1.1. RFC Compliance . . . . . . . . . . . . . . . . . . . . 9
4.1.2. Draw from Existing Work . . . . . . . . . . . . . . . 9 4.1.2. Draw from Existing Work . . . . . . . . . . . . . . . 9
4.2. Tunnel Requirements . . . . . . . . . . . . . . . . . . . 10 4.2. Tunnel Requirements . . . . . . . . . . . . . . . . . . . 10
4.2.1. TLS Requirements . . . . . . . . . . . . . . . . . . . 10 4.2.1. TLS Requirements . . . . . . . . . . . . . . . . . . . 10
4.2.1.1. Cipher Suites . . . . . . . . . . . . . . . . . . 10 4.2.1.1. Cipher Suites . . . . . . . . . . . . . . . . . . 10
4.2.1.1.1. Cipher Suite Negotiation . . . . . . . . . . . 10 4.2.1.1.1. Cipher Suite Negotiation . . . . . . . . . . . 10
4.2.1.1.2. Tunnel Data Protection Algorithms . . . . . . 10 4.2.1.1.2. Tunnel Data Protection Algorithms . . . . . . 10
4.2.1.1.3. Tunnel Authentication and Key Establishment . 11 4.2.1.1.3. Tunnel Authentication and Key Establishment . 11
4.2.1.2. Tunnel Replay Protection . . . . . . . . . . . . . 12 4.2.1.2. Tunnel Replay Protection . . . . . . . . . . . . . 12
4.2.1.3. TLS Extensions . . . . . . . . . . . . . . . . . . 13 4.2.1.3. TLS Extensions . . . . . . . . . . . . . . . . . . 13
4.2.1.4. Peer Identity Privacy . . . . . . . . . . . . . . 13 4.2.1.4. Peer Identity Privacy . . . . . . . . . . . . . . 13
skipping to change at page 4, line 25 skipping to change at page 4, line 25
6.1. Cipher Suite Selection . . . . . . . . . . . . . . . . . . 19 6.1. Cipher Suite Selection . . . . . . . . . . . . . . . . . . 19
6.2. Tunneled Authentication . . . . . . . . . . . . . . . . . 20 6.2. Tunneled Authentication . . . . . . . . . . . . . . . . . 20
6.3. Data External to Tunnel . . . . . . . . . . . . . . . . . 20 6.3. Data External to Tunnel . . . . . . . . . . . . . . . . . 20
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. Normative References . . . . . . . . . . . . . . . . . . . 20 7.1. Normative References . . . . . . . . . . . . . . . . . . . 20
7.2. Informative References . . . . . . . . . . . . . . . . . . 21 7.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. Changes from -01 . . . . . . . . . . . . . . . . . . 22 Appendix A. Changes from -01 . . . . . . . . . . . . . . . . . . 22
Appendix B. Changes from -02 . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
Running EAP methods within a TLS protected tunnel has been deployed Running EAP methods within a TLS protected tunnel has been deployed
in several different solutions. EAP methods supporting this include in several different solutions. EAP methods supporting this include
PEAP, TTLS [RFC5281] and EAP-FAST [RFC4851]. In general this has PEAP, TTLS [RFC5281] and EAP-FAST [RFC4851]. In general this has
worked well so there is consensus to continue to use TLS as the basis worked well so there is consensus to continue to use TLS as the basis
for a tunnel method. There have been various reasons for employing a for a tunnel method. There have been various reasons for employing a
protected tunnel for EAP processes. They include protecting weak protected tunnel for EAP processes. They include protecting weak
skipping to change at page 6, line 15 skipping to change at page 6, line 15
3.1. Password Authentication 3.1. Password Authentication
Many legacy systems only support user authentication with passwords. Many legacy systems only support user authentication with passwords.
Some of these systems require transport of the actual username and Some of these systems require transport of the actual username and
password to the authentication server. This is true for systems password to the authentication server. This is true for systems
where the authentication server does not have access to the cleartext where the authentication server does not have access to the cleartext
password or a consistent transform of the cleartext password. password or a consistent transform of the cleartext password.
Example of such systems are one time password (OTP) systems and other Example of such systems are one time password (OTP) systems and other
systems where the username and password are submitted to an external systems where the username and password are submitted to an external
party for validation. The tunnel method MUST support this use case. party for validation. The tunnel method MUST support this use case.
However, it MUST NOT expose the username and password to untrusted However, it MUST NOT expose the username and password to parties in
parties and it MUST provide protection against man-in-the-middle and the communication path between the peer and the EAP Server and it
dictionary attacks. The combination of the tunnel authentication and MUST provide protection against man-in-the-middle and dictionary
password authentication MUST enable mutual authentication. attacks. The combination of the tunnel authentication and password
authentication MUST enable mutual authentication.
Since EAP authentication occurs before network access is granted the Since EAP authentication occurs before network access is granted the
tunnel method SHOULD enable an inner exchange to provide support for tunnel method SHOULD enable an inner exchange to provide support for
minimal password management tasks including password change, "new PIN minimal password management tasks including password change, "new PIN
mode", and "next token mode" required by some systems. mode", and "next token mode" required by some systems.
3.2. Protection of Weak EAP Methods 3.2. Protection of Weak EAP Methods
Some existing EAP methods have vulnerabilities that could be Some existing EAP methods have vulnerabilities that could be
eliminated or reduced by running them inside a protected tunnel. For eliminated or reduced by running them inside a protected tunnel. For
example, a method such as EAP-MD5 does not provide mutual example, a method such as EAP-MD5 does not provide mutual
authentication or protection from dictionary attacks. Without extra authentication or protection from dictionary attacks. Without extra
protection, tunnel-based EAP methods are vulnerable to a special type protection, tunnel-based EAP methods are vulnerable to a special type
of man-in-the-middle attacks documented in [TUNNEL-MITM]. This of tunnel man-in-the-middle attack [TUNNEL-MITM]. This attack is
attack is referred to as "tunnel MitM attack" in the remainder of referred to as "tunnel MitM attack" in the remainder of this
this document. The additional protection needed to thwart tunnel document. The additional protection needed to thwart tunnel MitM
MitM attacks depends on the inner method executed within the tunnel. attacks depends on the inner method executed within the tunnel. In
In particular, when weak methods are used, security policies particular, when weak methods are used, security policies enforcing
enforcing that such methods can only be executed inside a tunnel but that such methods can only be executed inside a tunnel but never
never outside one are required to mitigate the attack. On the other outside one are required to mitigate the attack. On the other hand,
hand, a technical solution (so-called cryptographic bindings) can be a technical solution (so-called cryptographic bindings) can be used
used whenever the inner method is not susceptible to attacks outside whenever the inner method is not susceptible to attacks outside a
a tunnel and derives keying material. Only the latter mitigation tunnel and derives keying material. Only the latter mitigation
technique can be made an actual requirement for tunnel-based EAP technique can be made an actual requirement for tunnel-based EAP
methods (see Section 4.6.3), while security policies are outside the methods (see Section 4.6.3), while security policies are outside the
scope of this requirement draft. Please refer to [NIST SP 800-120] scope of this requirement draft. Please refer to the NIST
for a discussion on security policies and complete solutions for Recommendation for EAP Methods Used in Wireless Network Access
thwarting tunnel MitM attacks. Authentication [NIST SP 800-120] for a discussion on security
policies and complete solutions for thwarting tunnel MitM attacks.
The tunnel method MUST support protection of weak EAP methods, The tunnel method MUST support protection of weak EAP methods,
including cryptographic protection from tunnel MitM attacks. In including cryptographic protection from tunnel MitM attacks. In
combination with an appropriate security policy this will thwart MitM combination with an appropriate security policy this will thwart MitM
attacks against inner methods. attacks against inner methods.
3.3. Chained EAP Methods 3.3. Chained EAP Methods
Several circumstances are best addressed by using chained EAP Several circumstances are best addressed by using chained EAP
methods. For example, it may be desirable to authenticate the user methods. For example, it may be desirable to authenticate the user
and also authenticate the device that he or she is using. However, and also authenticate the device that he or she is using. However,
chained EAP methods from different conversations can be re-directed chained EAP methods from different conversations can be re-directed
into the same conversation by an attacker giving the authenticator into the same conversation by an attacker giving the authenticator
the impression that both conversations terminate at the same end- the impression that both conversations terminate at the same end-
point. Cryptographic binding can be used to bind the results of key point. Cryptographic binding can be used to bind the results of key
generating methods together or to an encompassing tunnel. generating methods together or to an encompassing tunnel.
The tunnel method MUST support chained EAP methods while including The tunnel method MUST support chained EAP methods while including
strong protection against attacks on the method chaining. strong protection against attacks on method chaining.
3.4. Identity Protection 3.4. Identity Protection
When performing an EAP authentication, the peer may want to protect When performing an EAP authentication, the peer may want to protect
its identity, only disclosing its identity to a trusted backend its identity, only disclosing its identity to a trusted backend
authentication server. This helps to maintain the privacy of the authentication server. This helps to maintain the privacy of the
peer's identity. peer's identity.
The tunnel method MUST support identity protection, ensuring that The tunnel method MUST support identity protection, ensuring that
peer identity is not disclosed to the authenticator and any other peer identity is not disclosed to the authenticator and any other
skipping to change at page 8, line 22 skipping to change at page 8, line 22
limited access to remediate itself. EAP is a convenient place for limited access to remediate itself. EAP is a convenient place for
conducting an NEA exchange. conducting an NEA exchange.
The tunnel method SHOULD support carrying NEA protocols such as PB- The tunnel method SHOULD support carrying NEA protocols such as PB-
TNC [I-D.ietf-nea-pb-tnc]. Depending on the specifics of the tunnel TNC [I-D.ietf-nea-pb-tnc]. Depending on the specifics of the tunnel
method, these protocols may be required to be carried in an EAP method, these protocols may be required to be carried in an EAP
method. method.
3.7. Client Authentication During Tunnel Establishment 3.7. Client Authentication During Tunnel Establishment
In cases where client authentication can be performed as part of the In some cases the peer will have credentials usable to authenticate
tunnel establishment it is efficient for the tunnel method to allow during tunnel establishment. These credentials may only partially
this. The tunnel method MUST be capable of providing client side authenticate the identity of the peer and additional authentication
authentication during tunnel establishment. may be required inside the tunnel. If the identity of the peer is
fully authenticated during tunnel establishment then the tunnel may
be used to communicate additional data. The tunnel method MUST be
capable of providing client side authentication during tunnel
establishment.
3.8. Extensibility 3.8. Extensibility
The tunnel method MUST provide extensibility so that additional types The tunnel method MUST provide extensibility so that additional data
of data can be carried inside the tunnel in the future. This removes related to authentication, authorization and network access can be
the need to develop new tunneling methods for specific purposes. carried inside the tunnel in the future. This removes the need to
develop new tunneling methods for specific purposes.
One example of a application for extensibility is credential One example of a application for extensibility is credential
provisioning. When a peer has authenticated with EAP, this is a provisioning. When a peer has authenticated with EAP, this is a
convenient time to distribute credentials to that peer that may be convenient time to distribute credentials to that peer that may be
used for later authentication exchanges. For example, the used for later authentication exchanges. For example, the
authentication server can provide a private key or shared key to the authentication server can provide a private key or shared key to the
peer that can be used by the peer to perform rapid re-authentication peer that can be used by the peer to perform rapid re-authentication
or roaming. In addition there have been proposals to perform or roaming. In addition there have been proposals to perform
enrollment within EAP, such as [I-D.mahy-eap-enrollment]. Another enrollment within EAP, such as [I-D.mahy-eap-enrollment]. Another
use for extensibility is support for authentication frameworks other use for extensibility is support for authentication frameworks other
skipping to change at page 9, line 6 skipping to change at page 9, line 13
4. Requirements 4. Requirements
4.1. General Requirements 4.1. General Requirements
4.1.1. RFC Compliance 4.1.1. RFC Compliance
The tunnel method MUST include a Security Claims section with all The tunnel method MUST include a Security Claims section with all
security claims specified in Section 7.2 in RFC 3748 [RFC3748]. In security claims specified in Section 7.2 in RFC 3748 [RFC3748]. In
addition, it MUST meet the requirement in Sections 2.1 and 7.4 of RFC addition, it MUST meet the requirement in Sections 2.1 and 7.4 of RFC
3748 that tunnel methods MUST support protection against man-in-the- 3748 that tunnel methods MUST support protection against man-in-the-
middle attacks. Furthermore, all tunnel methods MUST support middle attacks. Furthermore, the tunnel method MUST support identity
identity protection as specified in Section 7.3 in RFC 3748. protection as specified in Section 7.3 in RFC 3748.
The tunnel method MUST be unconditionally compliant with RFC 4017 The tunnel method MUST be unconditionally compliant with RFC 4017
[RFC4017] (using the definition of "unconditionally compliant" [RFC4017] (using the definition of "unconditionally compliant"
contained in section 1.1 of RFC 4017). This means that the method contained in section 1.1 of RFC 4017). This means that the method
MUST satisfy all the MUST, MUST NOT, SHOULD, and SHOULD NOT MUST satisfy all the MUST, MUST NOT, SHOULD, and SHOULD NOT
requirements in RFC 4017. requirements in RFC 4017.
The tunnel method MUST meet all the EAP method requirements contained The tunnel method MUST meet all the MUST and SHOULD requirements
in the EAP Key Management Framework [RFC5247] or its successor. The relevant to EAP methods contained in the EAP Key Management Framework
tunnel method MUST include MSK and EMSK generation. This will enable [RFC5247] or its successor. The tunnel method MUST include MSK and
the tunnel method to properly fit into the EAP key management EMSK generation. This will enable the tunnel method to properly fit
framework, maintaining all of the security properties and guarantees into the EAP key management framework, maintaining all of the
of that framework. security properties and guarantees of that framework.
The tunnel method MUST NOT be tied to any single cryptographic The tunnel method MUST NOT be tied to any single cryptographic
algorithm. Instead, it MUST support run-time negotiation to select algorithm. Instead, it MUST support run-time negotiation to select
among an extensible set of cryptographic algorithms. This among an extensible set of cryptographic algorithms. This
"cryptographic algorithm agility" provides several advantages. Most "cryptographic algorithm agility" provides several advantages. Most
important, when a weakness in an algorithm is discovered or increased important, when a weakness in an algorithm is discovered or increased
processing power overtakes an algorithm, users can easily transition processing power overtakes an algorithm, users can easily transition
to a new algorithm. Also, users can choose the algorithm that best to a new algorithm. Also, users can choose the algorithm that best
meets their needs. meets their needs.
The tunnel method MUST meet requirements pertinent to EAP method The tunnel method MUST meet the SHOULD and MUST requirements
contained in Section 3 of RFC 4962 [RFC4962]. This includes: pertinent to EAP method contained in Section 3 of RFC 4962 [RFC4962].
cryptographic algorithm independence; strong, fresh session keys; This includes: cryptographic algorithm independence; strong, fresh
replay detection; keying material confidentiality and integrity; session keys; replay detection; keying material confidentiality and
confirm cipher suite selection; and uniquely named keys. integrity; confirm cipher suite selection; and uniquely named keys.
4.1.2. Draw from Existing Work 4.1.2. Draw from Existing Work
Several existing tunnel methods are already in widespread usage: EAP- Several existing tunnel methods are already in widespread usage: EAP-
FAST [RFC4851], EAP-TTLS [RFC5281], and PEAP. Considerable FAST [RFC4851], EAP-TTLS [RFC5281], and PEAP. Considerable
experience has been gained from various deployments with these experience has been gained from various deployments with these
methods. This experience SHOULD be considered when evaluating tunnel methods. This experience SHOULD be considered when evaluating tunnel
methods. If one of these existing tunnel methods can meet the methods. If one of these existing tunnel methods can meet the
requirements contained in this specification then that method SHOULD requirements contained in this specification then that method SHOULD
be preferred over a new method. be preferred over a new method.
skipping to change at page 10, line 48 skipping to change at page 11, line 4
suites used provide strong authentication, key establishment and data suites used provide strong authentication, key establishment and data
integrity protection. integrity protection.
4.2.1.1.2. Tunnel Data Protection Algorithms 4.2.1.1.2. Tunnel Data Protection Algorithms
In order to prevent attacks on the cryptographic algorithms employed In order to prevent attacks on the cryptographic algorithms employed
by inner authentication methods, a tunnel protocol's protection needs by inner authentication methods, a tunnel protocol's protection needs
to provide a basic level of algorithm strength. The tunnel method to provide a basic level of algorithm strength. The tunnel method
MUST provide at least one mandatory to implement cipher suite that MUST provide at least one mandatory to implement cipher suite that
provides the equivalent security of 128-bit AES for encryption and provides the equivalent security of 128-bit AES for encryption and
message authentication. See [NIST SP 800-57] for a discussion of the message authentication. See Part 1 of the NIST Recommendation for
relative strengths of common algorithms. Key Management [NIST SP 800-57] for a discussion of the relative
strengths of common algorithms.
4.2.1.1.3. Tunnel Authentication and Key Establishment 4.2.1.1.3. Tunnel Authentication and Key Establishment
A tunnel method MUST provide unidirectional authentication from A tunnel method MUST provide unidirectional authentication from
authentication server to EAP peer or mutual authentication between authentication server to EAP peer or mutual authentication between
authentication server and EAP peer. The tunnel method MUST provide authentication server and EAP peer. The tunnel method MUST provide
at least one mandatory to implement cipher suite that provides at least one mandatory to implement cipher suite that provides
certificate based authentication of the server and provides optional certificate-based authentication of the server and provides optional
certificate based authentication of the client. Other types of certificate-based authentication of the client. Other types of
authentication MAY be supported. authentication MAY be supported.
At least one mandatory to implement cipher suite MUST meet the At least one mandatory to implement cipher suite MUST meet the
following requirements for secure key establishment along with the following requirements for secure key establishment along with the
previous requirements for authentication and data protection previous requirements for authentication and data protection
algorithms: algorithms:
o One-way key derivation, i.e., a compromised key leads to the o One-way key derivation, i.e., a compromised key leads to the
compromise of all descendant keys but does not affect the security compromise of all descendant keys but does not affect the security
of any precedent key in the same branch of the key hierarchy. of any precedent key in the same branch of the key hierarchy.
skipping to change at page 12, line 9 skipping to change at page 12, line 13
confidential. confidential.
o Key freshness, i.e. EAP peer and EAP server are assured that the o Key freshness, i.e. EAP peer and EAP server are assured that the
derived keys are fresh and the re-use of expired key material is derived keys are fresh and the re-use of expired key material is
prevented. The freshness property is typically achieved by using prevented. The freshness property is typically achieved by using
one or more of the following techniques: nonces, sequence numbers, one or more of the following techniques: nonces, sequence numbers,
timestamps. timestamps.
The mandatory to implement cipher suites MUST NOT include "export The mandatory to implement cipher suites MUST NOT include "export
strength" cipher suites, cipher suites providing mutually anonymous strength" cipher suites, cipher suites providing mutually anonymous
authentication or static Diffie-Hellman cipher suites. NIST authentication or static Diffie-Hellman cipher suites. Part 3 of the
publication [NIST SP 800-57p3] can be consulted for a list of NIST Recommendation for Key Management [NIST SP 800-57p3] can be
acceptable TLS v1.0, v1.1 and v 1.2 cipher suites and NIST consulted for a list of acceptable TLS v1.0, v1.1 and v 1.2 cipher
publication [NIST SP 800-108] for additional information on secure suites and NIST Recommendation for Key Derivation Using Pseudorandom
key derivation. Functions [NIST SP 800-108] for additional information on secure key
derivation.
In addition a tunnel method SHOULD provide cipher suites to meet the In addition a tunnel method SHOULD provide cipher suites to meet the
following additional recommendations for good key establishment following additional recommendations for good key establishment
algorithms: algorithms:
o Key control , i.e., EAP peer and authentication server each o Key control , i.e., EAP peer and authentication server each
contribute to the key computation of the tunnel key. This contribute to the key computation of the tunnel key. This
property prevents that a single protocol participant controls the property prevents that a single protocol participant controls the
value of an established key. In that way, protocol participants value of an established key. In that way, protocol participants
can ensure that generated keys are fresh and have good random can ensure that generated keys are fresh and have good random
skipping to change at page 16, line 33 skipping to change at page 16, line 33
associated meta-data which can be used to indicate whether the associated meta-data which can be used to indicate whether the
authentication is for a user or a machine. This allows the EAP authentication is for a user or a machine. This allows the EAP
server and peer to request and negotiate authentication specifically server and peer to request and negotiate authentication specifically
for a user or machine. This is useful in the case of multiple inner for a user or machine. This is useful in the case of multiple inner
authentications where the user and machine both need to be authentications where the user and machine both need to be
authenticated. authenticated.
4.5.4. Password Change 4.5.4. Password Change
The password authentication exchange MUST support password change, as The password authentication exchange MUST support password change, as
well as other multiple round trips exchanges like new pin mode and well as other other "housekeeping" functions required by some
next token mode for OTP verifiers. systems.
4.6. Requirements Associated with Carrying EAP Methods 4.6. Requirements Associated with Carrying EAP Methods
The tunnel method MUST be able to carry inner EAP methods without The tunnel method MUST be able to carry inner EAP methods without
modifying them. EAP methods MUST NOT be redefined inside the tunnel. modifying them. EAP methods MUST NOT be redefined inside the tunnel.
4.6.1. Method Negotiation 4.6.1. Method Negotiation
The tunnel method MUST support the protected negotiation of the inner The tunnel method MUST support the protected negotiation of the inner
EAP method. It MUST NOT allow the inner EAP method negotiation to be EAP method. It MUST NOT allow the inner EAP method negotiation to be
skipping to change at page 17, line 11 skipping to change at page 17, line 11
The tunnel method MUST support the chaining of multiple EAP methods. The tunnel method MUST support the chaining of multiple EAP methods.
The tunnel method MUST allow for the communication of intermediate The tunnel method MUST allow for the communication of intermediate
result and verification of compound binding between executed inner result and verification of compound binding between executed inner
methods when chained methods are employed. methods when chained methods are employed.
4.6.3. Cryptographic Binding with the TLS Tunnel 4.6.3. Cryptographic Binding with the TLS Tunnel
The tunnel method MUST provide a mechanism to bind the tunnel The tunnel method MUST provide a mechanism to bind the tunnel
protocol and the inner EAP method. This property is referred to as protocol and the inner EAP method. This property is referred to as
cryptographic binding. Such bindings are an important tool for cryptographic binding. Such bindings are an important tool for
mitigating the tunnel MitM attacks on tunnel methods described in mitigating the tunnel MitM attacks on tunnel methods [TUNNEL-MITM].
[TUNNEL-MITM]. Cryptographic bindings enable the complete prevention Cryptographic bindings enable the complete prevention of tunnel MitM
of tunnel MitM attacks without the need of additional security attacks without the need of additional security policies as long as
policies as long as the inner method derives keys and is not the inner method derives keys and is not vulnerable to attacks
vulnerable to attacks outside a protected tunnel [KHLC07]. Even outside a protected tunnel [KHLC07]. Even though weak or non-key
though weak or non-key deriving inner methods may be permitted, and deriving inner methods may be permitted, and thus security policies
thus security policies preventing tunnel MitM attacks are still preventing tunnel MitM attacks are still necessary, the tunnel method
necessary, the tunnel method MUST provide cryptographic bindings, MUST provide cryptographic bindings, because only this allows
because only this allows migrating to more secure, policy-independent migrating to more secure, policy-independent implementations.
implementations.
Cryptographic bindings are typically achieved by securely mixing the Cryptographic bindings are typically achieved by securely mixing the
established keying material (say tunnel key TK) from the tunnel established keying material (say tunnel key TK) from the tunnel
protocol with the established keying material (say method key MK) protocol with the established keying material (say method key MK)
from the inner authentication method(s) in order to derive fresh from the inner authentication method(s) in order to derive fresh
keying material. If chained EAP methods are executed in the tunnel, keying material. If chained EAP methods are executed in the tunnel,
all derived inner keys are combined with the tunnel key to create a all derived inner keys are combined with the tunnel key to create a
new compound tunnel key (CTK). In particular, CTK is used to derive new compound tunnel key (CTK). In particular, CTK is used to derive
the EAP MSK, EMSK and other transient keys (TEK), such as transient the EAP MSK, EMSK and other transient keys (TEK), such as transient
encryption keys and integrity protection keys. The key hierarchy for encryption keys and integrity protection keys. The key hierarchy for
tunnel methods executions that derive compound keys for the purpose tunnel methods executions that derive compound keys for the purpose
of cryptographic binding is depicted in Figure 1. of cryptographic binding is depicted in Figure 1.
In the case of the sequential executions of n inner methods, a In the case of the sequential executions of n inner methods, a
chained compound key CTK_i MUST be computed upon the completion of chained compound key CTK_i MUST be computed upon the completion of
each inner method i such that it contains the compound key of all each inner method i such that it contains the compound key of all
previous inner methods, i.e. CTK_i=f(CTK_i-1, MK_i) with 0 < i <= n previous inner methods, i.e. CTK_i=f(CTK_i-1, MK_i) with 0 < i <= n
and CTK_0=TK, where f() is a good key derivation function, such as and CTK_0=TK, where f() is a good key derivation function, such as
one that complies with [NIST SP 800-108]. CTK_n SHOULD serve as the one that complies with NIST Recommendation for Key Derivation Using
Pseudorandom Functions [NIST SP 800-108]. CTK_n SHOULD serve as the
key to derive further keys. Figure 1 depicts the key hierarchy in key to derive further keys. Figure 1 depicts the key hierarchy in
the case of a single inner method. Transient keys derived from the the case of a single inner method. Transient keys derived from the
compound key CTK are used in a cryptographic protocol to verify the compound key CTK are used in a cryptographic protocol to verify the
integrity of the tunnel and the inner authentication method. integrity of the tunnel and the inner authentication method.
----------- -----------
| TK | MK | | TK | MK |
----------- -----------
| | | |
v v v v
skipping to change at page 21, line 33 skipping to change at page 21, line 33
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible
Authentication Protocol (EAP) Key Management Framework", Authentication Protocol (EAP) Key Management Framework",
RFC 5247, August 2008. RFC 5247, August 2008.
7.2. Informative References 7.2. Informative References
[I-D.ietf-nea-pb-tnc] [I-D.ietf-nea-pb-tnc]
Sahita, R., Hanna, S., and K. Narayan, "PB-TNC: A Posture Sahita, R., Hanna, S., and K. Narayan, "PB-TNC: A Posture
Broker Protocol (PB) Compatible with TNC", Broker Protocol (PB) Compatible with TNC",
draft-ietf-nea-pb-tnc-02 (work in progress), draft-ietf-nea-pb-tnc-04 (work in progress), April 2009.
November 2008.
[I-D.mahy-eap-enrollment] [I-D.mahy-eap-enrollment]
Mahy, R., "An Extensible Authentication Protocol (EAP) Mahy, R., "An Extensible Authentication Protocol (EAP)
Enrollment Method", draft-mahy-eap-enrollment-01 (work in Enrollment Method", draft-mahy-eap-enrollment-01 (work in
progress), March 2006. progress), March 2006.
[KHLC07] Hoeper, K. and L. Chen, "Where EAP Security Claims Fail", [KHLC07] Hoeper, K. and L. Chen, "Where EAP Security Claims Fail",
ICST QShine , August 2007. ICST QShine , August 2007.
[NIST SP 800-108] [NIST SP 800-108]
skipping to change at page 23, line 21 skipping to change at page 23, line 21
extensibility extensibility
o Added text to emergency services section to emphasize that o Added text to emergency services section to emphasize that
sensitive information should not be sent if the server is sensitive information should not be sent if the server is
unauthenticated. unauthenticated.
o Reworded TLS requirements o Reworded TLS requirements
o Reworded external data protection requirements o Reworded external data protection requirements
o Added text to section 4.6 that states method must not be re- o Added text to section 4.6 that states method must not be re-
defined inside the tunnel. defined inside the tunnel.
o Editorial fixes o Editorial fixes
Appendix B. Changes from -02
o Editorial Fixes
o Clarified client authentication during tunnel establishment
o Changed text so that the tunnel method MUST meet all MUST and
SHOULD requirements relevant to EAP methods in RFCs 4962 and 5247
Authors' Addresses Authors' Addresses
Katrin Hoeper Katrin Hoeper
Motorola, Inc. Motorola, Inc.
1301 E Algonquin Rd 1301 E Algonquin Rd
Schaumburg, IL 60196 Schaumburg, IL 60196
USA USA
Email: khoeper@motorola.com Email: khoeper@motorola.com
 End of changes. 23 change blocks. 
68 lines changed or deleted 84 lines changed or added

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