draft-ietf-emu-eaptunnel-req-05.txt   draft-ietf-emu-eaptunnel-req-06.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: September 9, 2010 Juniper Networks Expires: November 15, 2010 Juniper Networks
H. Zhou H. Zhou
J. Salowey, Ed. J. Salowey, Ed.
Cisco Systems, Inc. Cisco Systems, Inc.
March 8, 2010 May 14, 2010
Requirements for a Tunnel Based EAP Method Requirements for a Tunnel Based EAP Method
draft-ietf-emu-eaptunnel-req-05.txt draft-ietf-emu-eaptunnel-req-06.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
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on November 15, 2010.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 9, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
skipping to change at page 3, line 20 skipping to change at page 3, line 20
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
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. Anonymous Service Access . . . . . . . . . . . . . . . . . 7 3.5. Anonymous Service Access . . . . . . . . . . . . . . . . . 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
3.9. Certificate-less Authentication and Generic EAP Method
Extension . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. General Requirements . . . . . . . . . . . . . . . . . . . 9 4.1. General Requirements . . . . . . . . . . . . . . . . . . . 9
4.1.1. RFC Compliance . . . . . . . . . . . . . . . . . . . . 9 4.1.1. RFC Compliance . . . . . . . . . . . . . . . . . . . . 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 . . . . . . 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 . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . 12
4.3.1. Extensible Attribute Types . . . . . . . . . . . . . . 12 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. Mandatory and Optional Attributes . . . . . . . . . . 13 4.3.3. Indicating Criticality of Attributes . . . . . . . . . 13
4.3.4. Vendor Specific Support . . . . . . . . . . . . . . . 14 4.3.4. Vendor Specific Support . . . . . . . . . . . . . . . 13
4.3.5. Result Indication . . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . 15 4.5.1.1. Confidentiality and Integrity . . . . . . . . . . 14
4.5.1.2. Authentication of Server . . . . . . . . . . . . . 15 4.5.1.2. Authentication of Server . . . . . . . . . . . . . 14
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 . . . . . . . . . . . . . . . . . . . . . . 16 4.5.3. Meta-data . . . . . . . . . . . . . . . . . . . . . . 15
4.5.4. Password Change . . . . . . . . . . . . . . . . . . . 16 4.5.4. Password Change . . . . . . . . . . . . . . . . . . . 15
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 . . . . . . . . . . . . . . . . . . . . 18 4.6.4. Peer Initiated . . . . . . . . . . . . . . . . . . . . 17
4.6.5. Method Meta-data . . . . . . . . . . . . . . . . . . . 18 4.6.5. Method Meta-data . . . . . . . . . . . . . . . . . . . 17
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 . . . . . . . . . . . . . . . . . 20 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 . . . . . . . . . . . . . . . . . . . . . . . 20 Termination . . . . . . . . . . . . . . . . . . . . . . . 19
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 . . . . . . . . . . . . . . . . . . 23 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
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 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 [PEAP], TTLS [RFC5281] and EAP-FAST [RFC4851]. In general this PEAP [PEAP], TTLS [RFC5281] and EAP-FAST [RFC4851]. In general this
has worked well so there is consensus to continue to use TLS as the has worked well so there is consensus to continue to use TLS as the
basis for a tunnel method. There have been various reasons for basis for a tunnel method. There have been various reasons for
employing a protected tunnel for EAP processes. They include employing a protected tunnel for EAP processes. They include
protecting weak authentication exchanges, such as username and protecting weak authentication exchanges, such as username and
skipping to change at page 8, line 21 skipping to change at page 8, line 21
The Network Endpoint Assessment (NEA) protocols and reference model The Network Endpoint Assessment (NEA) protocols and reference model
described in [RFC5209] provide a standard way to check the health described in [RFC5209] provide a standard way to check the health
("posture") of a device at or after the time it connects to a ("posture") of a device at or after the time it connects to a
network. If the device does not comply with the network's network. If the device does not comply with the network's
requirements, it can be denied access to the network or granted requirements, it can be denied access to the network or granted
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 [RFC5793]. Depending on the specifics of the tunnel method,
method, these protocols may be required to be carried in an EAP 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 some cases the peer will have credentials that allow it to In some cases the peer will have credentials that allow it to
authenticate during tunnel establishment. These credentials may only authenticate during tunnel establishment. These credentials may only
partially authenticate the identity of the peer and additional partially authenticate the identity of the peer and additional
authentication may be required inside the tunnel. For example, a authentication may be required inside the tunnel. For example, a
communication device may be authenticated during tunnel communication device may be authenticated during tunnel
establishment, in addition user authentication may be required to establishment, in addition user authentication may be required to
satisfy authentication policy. The tunnel method MUST be capable of satisfy authentication policy. The tunnel method MUST be capable of
skipping to change at page 9, line 5 skipping to change at page 9, line 5
An application for extensibility is credential provisioning. When a An application for extensibility is credential provisioning. When a
peer has authenticated with EAP, this is a convenient time to peer has authenticated with EAP, this is a convenient time to
distribute credentials to that peer that may be used for later distribute credentials to that peer that may be used for later
authentication exchanges. For example, the authentication server can authentication exchanges. For example, the authentication server can
provide a private key or shared key to the peer that can be used by provide a private key or shared key to the peer that can be used by
the peer to perform rapid re-authentication or roaming. In addition the peer to perform rapid re-authentication or roaming. In addition
there have been proposals to perform enrollment within EAP, such as there have been proposals to perform enrollment within EAP, such as
[I-D.mahy-eap-enrollment]. Another use for extensibility is support [I-D.mahy-eap-enrollment]. Another use for extensibility is support
for alternate authentication frameworks within the tunnel. for alternate authentication frameworks within the tunnel.
3.9. Certificate-less Authentication and Generic EAP Method Extension
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
to verify. Therefore, it is desirable to support certificate-less
authentication. An application for this is credential provisioning
where the peer and server authenticate each other with a shared
password and credentials for subsequent authentication (e.g. a key
pair and certificate or a shared key) can be passed inside the
tunnel. Another application is to extend existing strong EAP methods
with new features such as channel bindings.
Great care must be taken when attempting to perform certificate-less
authentication. One way of doing it is to establish the tunnel
without full server or client verification and inside the tunnel use
an EAP method that performs mutual authentication and key derivation.
If this technique is used the inner EAP method MUST provide
resistance to dictionary attack and a cryptographic binding between
the inner method and the tunnel method MUST be established. In
addition the cipher suite used to establish the tunnel MUST derive
the master key using contribution from both client and server, as in
ephemeral Diffie-Hellman cipher suites.
The tunnel method MAY allow for certificate-less authentication.
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-
skipping to change at page 9, line 48 skipping to change at page 10, line 25
is discovered or increased processing power overtakes an algorithm, is discovered or increased processing power overtakes an algorithm,
users can easily transition to a new algorithm. Also, users can users can easily transition to a new algorithm. Also, users can
choose the algorithm that best meets their needs. choose the algorithm that best meets their needs.
The tunnel method MUST meet the SHOULD and MUST requirements The tunnel method MUST meet the SHOULD and MUST requirements
pertinent to EAP method contained in Section 3 of RFC 4962 [RFC4962]. pertinent to EAP method contained in Section 3 of RFC 4962 [RFC4962].
This includes: cryptographic algorithm independence; strong, fresh This includes: cryptographic algorithm independence; strong, fresh
session keys; replay detection; keying material confidentiality and session keys; replay detection; keying material confidentiality and
integrity; and confirmation of cipher suite selection. integrity; and confirmation of cipher suite selection.
4.1.2. Draw from Existing Work
Several existing tunnel methods are already in widespread usage: EAP-
FAST [RFC4851], EAP-TTLS [RFC5281], and PEAP. Considerable
experience has been gained from various deployments with these
methods. This experience SHOULD be considered when evaluating tunnel
methods. If one of these existing tunnel methods can meet the
requirements contained in this specification then that method SHOULD
be preferred over a new method.
Even if minor modifications or extensions to an existing tunnel
method are needed, this method SHOULD be preferred over a completely
new method so that the advantage of accumulated deployment experience
and security analysis can be gained.
4.2. Tunnel Requirements 4.2. Tunnel Requirements
The following section discusses requirements for TLS Tunnel The following section discusses requirements for TLS Tunnel
Establishment. Establishment.
4.2.1. TLS Requirements 4.2.1. TLS Requirements
The tunnel based method MUST support TLS version 1.2 [RFC5246] and The tunnel based method MUST support TLS version 1.2 [RFC5246] and
may support earlier versions to enable the possibility of backwards may support earlier versions to enable the possibility of backwards
compatibility. compatibility.
skipping to change at page 13, line 15 skipping to change at page 13, line 25
be defined in the future to support additional features and data be defined in the future to support additional features and data
types. types.
4.3.2. Request/Challenge Response Operation 4.3.2. Request/Challenge Response Operation
The payload MUST support request and response type of half-duplex The payload MUST support request and response type of half-duplex
operation typical of EAP. Multiple attributes may be sent in a operation typical of EAP. Multiple attributes may be sent in a
single payload. The payload MAY support carrying on multiple single payload. The payload MAY support carrying on multiple
authentications in a single payload packet. authentications in a single payload packet.
4.3.3. Mandatory and Optional Attributes 4.3.3. Indicating Criticality of Attributes
The payload MUST support marking of mandatory and optional
attributes, as well as an attribute used for rejecting mandatory
attributes. Mandatory attributes are attributes sent by the
requester that the responder is expected to understand and MUST
respond to. If the responder does not understand or support one of
the mandatory attributes in the request, it MUST ignore the rest of
the attributes and send a NAK attribute to decline the request. The
NAK attribute MUST support inclusion of which mandatory attribute is
not supported. The optional attributes are attributes that are not
mandatory to support and respond to. If the responder does not
understand or support the optional attributes, it can ignore these
attributes.
The payload MUST support marking of mandatory and optional
attributes, as well as a "NAK" attribute used to communicate
disagreements about received attributes.
Mandatory attributes are attributes that a receiver MUST process as
per the specification. Optional attributes are attributes that a
receiver MAY ignore.
A receiver MUST process mandatory attributes before optional ones.
After an attribute has been processed, it SHOULD be marked as no
longer being mandatory. If a receiver does not process a mandatory
attribute, it MUST ignore everything else in a request, and it MUST
send a NAK attribute in response. Similarly, if a receiver expects a
mandatory attribute and does not receive one in a request, it MUST
send a NAK attribute in the response that contains the set of
attributes it expected to receive.
The NAK attribute MUST support a description of which mandatory It is expected that new attributes will be defined to be carried
attribute is either required, or is not supported. The NAK attribute within the tunnel method. In some cases it is necessary for the
MUST be otherwise treated as an optional attribute, and it MUST NOT sender to know if the receiver did not understand the attribute. To
contain a NAK of the NAK attribute, in order to prevent infinite support this, there MUST be a way for the sender to mark attributes
recursion. such that the receiver will indicate if an attribute is not
understood.
4.3.4. Vendor Specific Support 4.3.4. Vendor Specific Support
The payload MUST support communication of an extensible set of The payload MUST support communication of an extensible set of
vendor-specific attributes. These attributes will be segmented into vendor-specific attributes. These attributes will be segmented into
uniquely identified vendor specific name spaces. They can be used uniquely identified vendor specific name spaces. They can be used
for experiments or vendor specific features. for experiments or vendor specific features.
4.3.5. Result Indication 4.3.5. Result Indication
skipping to change at page 14, line 28 skipping to change at page 14, line 12
separate result indication for intermediate and final result MUST be separate result indication for intermediate and final result MUST be
supported. supported.
4.3.6. Internationalization of Display Strings 4.3.6. Internationalization of Display Strings
The payload MAY provide a standard attribute format that supports The payload MAY provide a standard attribute format that supports
international strings. This attribute format MUST support encoding international strings. This attribute format MUST support encoding
strings in UTF-8 [RFC3629] format. Any strings sent by the server strings in UTF-8 [RFC3629] format. Any strings sent by the server
intended for display to the user MUST be sent in UTF-8 format and intended for display to the user MUST be sent in UTF-8 format and
SHOULD be able to be marked with language information and adapted to SHOULD be able to be marked with language information and adapted to
the user's language preference as indicated by RFC 4646 [RFC4646]. the user's language preference as indicated by RFC 5646 [RFC5646].
Note that in some cases, such as when transmitting error codes, it is Note that in some cases, such as when transmitting error codes, it is
acceptable to exchange numeric codes that can be translated by the acceptable to exchange numeric codes that can be translated by the
client to support the particular local language. These numeric codes client to support the particular local language. These numeric codes
are not subject internationalization during transmission. are not subject internationalization during transmission.
4.4. EAP Channel Binding Requirements 4.4. EAP Channel Binding Requirements
The tunnel method MUST be capable of meeting EAP channel binding The tunnel method MUST be capable of meeting EAP channel binding
requirements described in [I-D.clancy-emu-chbind]. requirements described in [I-D.clancy-emu-chbind].
skipping to change at page 15, line 44 skipping to change at page 15, line 29
The password authentication exchange MUST support user names and The password authentication exchange MUST support user names and
passwords in international languages. It MUST support encoding of passwords in international languages. It MUST support encoding of
user name and password strings in UTF-8 [RFC3629] format. The method user name and password strings in UTF-8 [RFC3629] format. The method
MUST specify how username and password normalizations and/or MUST specify how username and password normalizations and/or
comparisons is performed in reference to SASLPrep [RFC4013] or Net- comparisons is performed in reference to SASLPrep [RFC4013] or Net-
UTF-8 [RFC5198]. UTF-8 [RFC5198].
Any strings sent by the server intended for display to the user MUST Any strings sent by the server intended for display to the user MUST
be sent in UTF-8 format and SHOULD be able to be marked with language be sent in UTF-8 format and SHOULD be able to be marked with language
information and adapted to the user's language preference as information and adapted to the user's language preference as
indicated by RFC 4646 [RFC4646]. Note that in some cases, such as indicated by RFC 5646 [RFC5646]. Note that in some cases, such as
when transmitting error codes, it is acceptable to exchange numeric when transmitting error codes, it is acceptable to exchange numeric
codes that can be translated by the client to support the particular codes that can be translated by the client to support the particular
local language. These numeric codes are not subject local language. These numeric codes are not subject
internationalization during transmission. internationalization during transmission.
4.5.3. Meta-data 4.5.3. Meta-data
The password authentication exchange SHOULD support additional The password authentication exchange SHOULD support additional
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
skipping to change at page 21, line 26 skipping to change at page 21, line 11
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[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]
Sahita, R., Hanna, S., and K. Narayan, "PB-TNC: A Posture
Broker Protocol (PB) Compatible with TNC",
draft-ietf-nea-pb-tnc-06 (work in progress), October 2009.
[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]
Chen, L., "Recommendation for Key Derivation Using Chen, L., "Recommendation for Key Derivation Using
skipping to change at page 22, line 22 skipping to change at page 21, line 51
[PEAP] Microsoft Corporation, "[MS-PEAP]: Protected Extensible [PEAP] Microsoft Corporation, "[MS-PEAP]: Protected Extensible
Authentication Protocol (PEAP) Specification", Authentication Protocol (PEAP) Specification",
August 2009. August 2009.
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names
and Passwords", RFC 4013, February 2005. and Passwords", RFC 4013, February 2005.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005. Network Access Identifier", RFC 4282, December 2005.
[RFC4646] Phillips, A. and M. Davis, "Tags for Identifying
Languages", RFC 4646, September 2006.
[RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The
Flexible Authentication via Secure Tunneling Extensible Flexible Authentication via Secure Tunneling Extensible
Authentication Protocol Method (EAP-FAST)", RFC 4851, Authentication Protocol Method (EAP-FAST)", RFC 4851,
May 2007. May 2007.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without "Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, January 2008. Server-Side State", RFC 5077, January 2008.
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network
Interchange", RFC 5198, March 2008. Interchange", RFC 5198, March 2008.
[RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J.
Tardo, "Network Endpoint Assessment (NEA): Overview and Tardo, "Network Endpoint Assessment (NEA): Overview and
Requirements", RFC 5209, June 2008. Requirements", RFC 5209, June 2008.
[RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication
Protocol Tunneled Transport Layer Security Authenticated Protocol Tunneled Transport Layer Security Authenticated
Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008. Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008.
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying
Languages", BCP 47, RFC 5646, September 2009.
[RFC5793] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC:
A Posture Broker (PB) Protocol Compatible with Trusted
Network Connect (TNC)", RFC 5793, March 2010.
[TUNNEL-MITM] [TUNNEL-MITM]
Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle
in Tunnelled Authentication Protocols", Cryptology ePrint in Tunnelled Authentication Protocols", Cryptology ePrint
Archive: Report 2002/163, November 2002. Archive: Report 2002/163, November 2002.
Appendix A. Changes from -01 Appendix A. Changes from -01
o Added combined mutual authentication in section 3.1 o Added combined mutual authentication in section 3.1
o Changed reference from SP 800-52 to SP 800-57,part 3 o Changed reference from SP 800-52 to SP 800-57,part 3
o In section 6.2 changed terminology to tunnel MitM and security o In section 6.2 changed terminology to tunnel MitM and security
policy enforcement policy enforcement
 End of changes. 30 change blocks. 
96 lines changed or deleted 70 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/