draft-ietf-emu-eaptunnel-req-06.txt   draft-ietf-emu-eaptunnel-req-07.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: November 15, 2010 Juniper Networks Expires: December 26, 2010 Juniper Networks
H. Zhou H. Zhou
J. Salowey, Ed. J. Salowey, Ed.
Cisco Systems, Inc. Cisco Systems, Inc.
May 14, 2010 June 24, 2010
Requirements for a Tunnel Based EAP Method Requirements for a Tunnel Based EAP Method
draft-ietf-emu-eaptunnel-req-06.txt draft-ietf-emu-eaptunnel-req-07.txt
Abstract Abstract
This memo defines the requirements for a tunnel-based Extensible This memo defines the requirements for a tunnel-based Extensible
Authentication Protocol (EAP) Method. This method will use Transport Authentication Protocol (EAP) Method. This method will use Transport
Layer Security (TLS) to establish a secure tunnel. The tunnel will Layer Security (TLS) to establish a secure tunnel. The tunnel will
provide support for password authentication, EAP authentication and provide support for password authentication, EAP authentication and
the transport of additional data for other purposes. the transport of additional data for other purposes.
Status of this Memo Status of this Memo
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on November 15, 2010. This Internet-Draft will expire on December 26, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 38 skipping to change at page 3, line 38
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 . . . . . . 11 4.2.1.1.2. Tunnel Data Protection Algorithms . . . . . . 11
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 . . . . . . . . . . . . . 11 4.2.1.2. Tunnel Replay Protection . . . . . . . . . . . . . 11
4.2.1.3. TLS Extensions . . . . . . . . . . . . . . . . . . 12 4.2.1.3. TLS Extensions . . . . . . . . . . . . . . . . . . 12
4.2.1.4. Peer Identity Privacy . . . . . . . . . . . . . . 12 4.2.1.4. Peer Identity Privacy . . . . . . . . . . . . . . 12
4.2.1.5. Session Resumption . . . . . . . . . . . . . . . . 12 4.2.1.5. Session Resumption . . . . . . . . . . . . . . . . 12
4.2.2. Fragmentation . . . . . . . . . . . . . . . . . . . . 12 4.2.2. Fragmentation . . . . . . . . . . . . . . . . . . . . 12
4.2.3. Protection of Data External to Tunnel . . . . . . . . 12 4.2.3. Protection of Data External to Tunnel . . . . . . . . 12
4.3. Tunnel Payload Requirements . . . . . . . . . . . . . . . 12 4.3. Tunnel Payload Requirements . . . . . . . . . . . . . . . 13
4.3.1. Extensible Attribute Types . . . . . . . . . . . . . . 13 4.3.1. Extensible Attribute Types . . . . . . . . . . . . . . 13
4.3.2. Request/Challenge Response Operation . . . . . . . . . 13 4.3.2. Request/Challenge Response Operation . . . . . . . . . 13
4.3.3. Indicating Criticality of Attributes . . . . . . . . . 13 4.3.3. Indicating Criticality of Attributes . . . . . . . . . 13
4.3.4. Vendor Specific Support . . . . . . . . . . . . . . . 13 4.3.4. Vendor Specific Support . . . . . . . . . . . . . . . 13
4.3.5. Result Indication . . . . . . . . . . . . . . . . . . 13 4.3.5. Result Indication . . . . . . . . . . . . . . . . . . 13
4.3.6. Internationalization of Display Strings . . . . . . . 14 4.3.6. Internationalization of Display Strings . . . . . . . 14
4.4. EAP Channel Binding Requirements . . . . . . . . . . . . . 14 4.4. EAP Channel Binding Requirements . . . . . . . . . . . . . 14
4.5. Requirements Associated with Carrying Username and 4.5. Requirements Associated with Carrying Username and
Passwords . . . . . . . . . . . . . . . . . . . . . . . . 14 Passwords . . . . . . . . . . . . . . . . . . . . . . . . 14
4.5.1. Security . . . . . . . . . . . . . . . . . . . . . . . 14 4.5.1. Security . . . . . . . . . . . . . . . . . . . . . . . 14
4.5.1.1. Confidentiality and Integrity . . . . . . . . . . 14 4.5.1.1. Confidentiality and Integrity . . . . . . . . . . 14
4.5.1.2. Authentication of Server . . . . . . . . . . . . . 14 4.5.1.2. Authentication of Server . . . . . . . . . . . . . 15
4.5.1.3. Server Certificate Revocation Checking . . . . . . 15 4.5.1.3. Server Certificate Revocation Checking . . . . . . 15
4.5.2. Internationalization . . . . . . . . . . . . . . . . . 15 4.5.2. Internationalization . . . . . . . . . . . . . . . . . 15
4.5.3. Meta-data . . . . . . . . . . . . . . . . . . . . . . 15 4.5.3. Meta-data . . . . . . . . . . . . . . . . . . . . . . 15
4.5.4. Password Change . . . . . . . . . . . . . . . . . . . 15 4.5.4. Password Change . . . . . . . . . . . . . . . . . . . 16
4.6. Requirements Associated with Carrying EAP Methods . . . . 16 4.6. Requirements Associated with Carrying EAP Methods . . . . 16
4.6.1. Method Negotiation . . . . . . . . . . . . . . . . . . 16 4.6.1. Method Negotiation . . . . . . . . . . . . . . . . . . 16
4.6.2. Chained Methods . . . . . . . . . . . . . . . . . . . 16 4.6.2. Chained Methods . . . . . . . . . . . . . . . . . . . 16
4.6.3. Cryptographic Binding with the TLS Tunnel . . . . . . 16 4.6.3. Cryptographic Binding with the TLS Tunnel . . . . . . 16
4.6.4. Peer Initiated . . . . . . . . . . . . . . . . . . . . 17 4.6.4. Peer Initiated . . . . . . . . . . . . . . . . . . . . 17
4.6.5. Method Meta-data . . . . . . . . . . . . . . . . . . . 17 4.6.5. Method Meta-data . . . . . . . . . . . . . . . . . . . 18
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
6.1. Cipher Suite Selection . . . . . . . . . . . . . . . . . . 18 6.1. Cipher Suite Selection . . . . . . . . . . . . . . . . . . 18
6.2. Tunneled Authentication . . . . . . . . . . . . . . . . . 19 6.2. Tunneled Authentication . . . . . . . . . . . . . . . . . 19
6.3. Data External to Tunnel . . . . . . . . . . . . . . . . . 19 6.3. Data External to Tunnel . . . . . . . . . . . . . . . . . 19
6.4. Separation of TLS Tunnel and Inner Authentication 6.4. Separation of TLS Tunnel and Inner Authentication
Termination . . . . . . . . . . . . . . . . . . . . . . . 19 Termination . . . . . . . . . . . . . . . . . . . . . . . 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 Appendix B. Changes from -02 . . . . . . . . . . . . . . . . . . 23
Appendix C. changes from -03 . . . . . . . . . . . . . . . . . . 23 Appendix C. changes from -03 . . . . . . . . . . . . . . . . . . 23
skipping to change at page 7, line 22 skipping to change at page 7, line 22
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 being used. However, chained EAP and also authenticate the device being used. However, chained EAP
methods from different conversations can be re-directed into the same methods from different conversations can be re-directed into the same
conversation by an attacker giving the authenticator the impression conversation by an attacker giving the authenticator the impression
that both conversations terminate at the same end-point. that both conversations terminate at the same end-point.
Cryptographic binding can be used to bind the results of chained key Cryptographic binding can be used to bind the results of chained 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 method chaining. 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 and only disclose it to a trusted EAP server. This its identity and only disclose it to a trusted EAP server. This
helps to maintain peer privacy. helps to maintain peer privacy.
The tunnel method MUST support identity protection, therefore the The tunnel method MUST support identity protection, therefore the
identity of the peer used for authentication purposes MUST NOT be identity of the peer used for authentication purposes MUST NOT be
obtainable by any entity other than the EAP server terminating the obtainable by any entity other than the EAP server terminating the
skipping to change at page 9, line 14 skipping to change at page 9, line 14
3.9. Certificate-less Authentication and Generic EAP Method Extension 3.9. Certificate-less Authentication and Generic EAP Method Extension
In some cases the peer will not have a way to verify a server In some cases the peer will not have a way to verify a server
certificate and in some cases a server might not have a certificate certificate and in some cases a server might not have a certificate
to verify. Therefore, it is desirable to support certificate-less to verify. Therefore, it is desirable to support certificate-less
authentication. An application for this is credential provisioning authentication. An application for this is credential provisioning
where the peer and server authenticate each other with a shared where the peer and server authenticate each other with a shared
password and credentials for subsequent authentication (e.g. a key password and credentials for subsequent authentication (e.g. a key
pair and certificate or a shared key) can be passed inside the pair and certificate or a shared key) can be passed inside the
tunnel. Another application is to extend existing strong EAP methods tunnel. Another application is to extend existing EAP methods with
with new features such as channel bindings. new features such as channel bindings.
Great care must be taken when attempting to perform certificate-less Great care must be taken when attempting to perform certificate-less
authentication. One way of doing it is to establish the tunnel authentication. One way of doing it is to establish the tunnel
without full server or client verification and inside the tunnel use without full server or client verification and inside the tunnel use
an EAP method that performs mutual authentication and key derivation. an EAP method that performs mutual authentication and key derivation.
If this technique is used the inner EAP method MUST provide If this technique is used the inner EAP method MUST provide
resistance to dictionary attack and a cryptographic binding between resistance to dictionary attack and a cryptographic binding between
the inner method and the tunnel method MUST be established. In the inner method and the tunnel method MUST be established. In
addition the cipher suite used to establish the tunnel MUST derive addition the cipher suite used to establish the tunnel MUST derive
the master key using contribution from both client and server, as in the master key using contribution from both client and server, as in
skipping to change at page 11, line 8 skipping to change at page 11, line 8
has been maliciously altered by another party. has been maliciously altered by another party.
Integrity checks prevent downgrading attacks only if the derived Integrity checks prevent downgrading attacks only if the derived
integrity keys and the employed integrity algorithms cannot be broken integrity keys and the employed integrity algorithms cannot be broken
in real-time. See Section 6.1 or [KHLC07] for more information on in real-time. See Section 6.1 or [KHLC07] for more information on
this. Hence, the tunnel method MUST provide integrity protected this. Hence, the tunnel method MUST provide integrity protected
cipher suite negotiation with secure integrity algorithms and cipher suite negotiation with secure integrity algorithms and
integrity keys. integrity keys.
TLS provides protected cipher suite negotiation as long as all the TLS provides protected cipher suite negotiation as long as all the
cipher suites supported provide strong authentication, key cipher suites supported provide authentication, key establishment and
establishment and data integrity protection. data integrity protection as discussed in Section 6.1.
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 Part 1 of the NIST Recommendation for message authentication. See Part 1 of the NIST Recommendation for
Key Management [NIST SP 800-57] for a discussion of the relative Key Management [NIST SP 800-57] for a discussion of the relative
skipping to change at page 12, line 5 skipping to change at page 12, line 5
EAP Methods Used in Wireless Network Access Authentication [NIST SP EAP Methods Used in Wireless Network Access Authentication [NIST SP
800-120]. 800-120].
4.2.1.2. Tunnel Replay Protection 4.2.1.2. Tunnel Replay Protection
In order to prevent replay attacks on a tunnel protocol, the message In order to prevent replay attacks on a tunnel protocol, the message
authentication MUST be generated using a time-variant input such as authentication MUST be generated using a time-variant input such as
timestamps, sequence numbers, nonces, or a combination of these so timestamps, sequence numbers, nonces, or a combination of these so
that any re-use of the authentication data can be detected as that any re-use of the authentication data can be detected as
invalid. TLS provides sufficient replay protection to meet this invalid. TLS provides sufficient replay protection to meet this
requirements as long as strong ciphersuites are used. requirements as long as weak cipher suites discussed in Section 6.1
are avoided.
4.2.1.3. TLS Extensions 4.2.1.3. TLS Extensions
In order to meet the requirements in this document TLS extensions MAY In order to meet the requirements in this document TLS extensions MAY
be used. For example, TLS extensions may be useful in providing be used. For example, TLS extensions may be useful in providing
certificate revocation information via the TLS OCSP extension (thus certificate revocation information via the TLS OCSP extension (thus
meeting the requirement in Section 4.5.1.3). meeting the requirement in Section 4.5.1.3).
4.2.1.4. Peer Identity Privacy 4.2.1.4. Peer Identity Privacy
skipping to change at page 17, line 5 skipping to change at page 17, line 12
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 key derivation function, such as one
one that complies with NIST Recommendation for Key Derivation Using that complies with NIST Recommendation for Key Derivation Using
Pseudorandom Functions [NIST SP 800-108]. CTK_n SHOULD serve as the 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 |
----------- -----------
| | | |
skipping to change at page 18, line 16 skipping to change at page 18, line 23
multiple inner EAP authentications where the user and machine both multiple inner EAP authentications where the user and machine both
need to be authenticated. need to be authenticated.
5. IANA Considerations 5. IANA Considerations
This document has no IANA considerations. This document has no IANA considerations.
6. Security Considerations 6. Security Considerations
A tunnel method is often deployed to provide mutual authentication A tunnel method is often deployed to provide mutual authentication
between EAP Peer and EAP Server and to generate strong key material between EAP Peer and EAP Server and to generate key material for use
for use in protecting lower layer protocols. In addition the tunnel in protecting lower layer protocols. In addition the tunnel is used
is used to protect the communication of additional data, including to protect the communication of additional data, including peer
peer identity between the EAP Peer and EAP Server from disclosure to identity between the EAP Peer and EAP Server from disclosure to or
or modification by an attacker. These sections cover considerations modification by an attacker. These sections cover considerations
that affect the ability for a method to achieve these goals. that affect the ability for a method to achieve these goals.
6.1. Cipher Suite Selection 6.1. Cipher Suite Selection
TLS supports a wide variety of cipher suites providing a variety of TLS supports a wide variety of cipher suites providing a variety of
security properties. The selection of strong cipher suites is security properties. The selection of cipher suites is critical to
critical to the security of the tunnel method. Selection of a cipher the security of the tunnel method. Selection of a cipher suite with
suite with weak or no authentication, such as an anonymous Diffie- weak or no authentication, such as an anonymous Diffie- Hellman based
Hellman based cipher suite will greatly increase the risk of system cipher suite will greatly increase the risk of system compromise.
compromise. Since a tunnel method uses the TLS tunnel to transport Since a tunnel method uses the TLS tunnel to transport data, the
data, the selection of a ciphersuite with weak data encryption and selection of a ciphersuite with weak data encryption and integrity
integrity algorithms will also increase the vulnerability of the algorithms will also increase the vulnerability of the method to
method to attacks. attacks.
A tunnel protocol is prone to downgrading attacks if the tunnel A tunnel protocol is prone to downgrading attacks if the tunnel
protocol supports any key establishment algorithm that can be broken protocol supports any key establishment algorithm that can be broken
on-line. In a successful downgrading attack, an adversary breaks the on-line. In a successful downgrading attack, an adversary breaks the
selected "weak" key establishment algorithm and optionally the "weak" selected "weak" key establishment algorithm and optionally the "weak"
authentication algorithm without being detected. Here, "weak" refers authentication algorithm without being detected. Here, "weak" refers
to a key establishment algorithm that can be broken in real-time, and to a key establishment algorithm that can be broken in real-time, and
an authentication scheme that can be broken off-line, respectively. an authentication scheme that can be broken off-line, respectively.
See [KHLC07] for more details. The requirements in this document See [KHLC07] for more details. The requirements in this document
disapprove the use of key establishment algorithms that can be broken disapprove the use of key establishment algorithms that can be broken
 End of changes. 16 change blocks. 
30 lines changed or deleted 31 lines changed or added

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