< draft-simon-emu-rfc2716bis-12.txt   draft-simon-emu-rfc2716bis-13.txt >
EMU Working Group Dan Simon EMU Working Group Dan Simon
Internet-Draft Bernard Aboba Internet-Draft Bernard Aboba
Obsoletes: 2716 Ryan Hurst Obsoletes: 2716 Ryan Hurst
Category: Proposed Standard Microsoft Corporation Category: Proposed Standard Microsoft Corporation
Expires: July 25, 2008 28 December 2007 Expires: August 25, 2008 9 January 2008
The EAP TLS Authentication Protocol The EAP TLS Authentication Protocol
draft-simon-emu-rfc2716bis-12.txt draft-simon-emu-rfc2716bis-13.txt
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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 July 25, 2008. This Internet-Draft will expire on August 25, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). All rights reserved. Copyright (C) The IETF Trust (2007). All rights reserved.
Abstract Abstract
The Extensible Authentication Protocol (EAP), defined in RFC 3748, The Extensible Authentication Protocol (EAP), defined in RFC 3748,
provides support for multiple authentication methods. Transport provides support for multiple authentication methods. Transport
Level Security (TLS) provides for mutual authentication, integrity- Level Security (TLS) provides for mutual authentication, integrity-
skipping to change at page 4, line 34 skipping to change at page 4, line 34
that is exported by the EAP method. that is exported by the EAP method.
2. Protocol Overview 2. Protocol Overview
2.1. Overview of the EAP-TLS Conversation 2.1. Overview of the EAP-TLS Conversation
As described in [RFC3748], the EAP-TLS conversation will typically As described in [RFC3748], the EAP-TLS conversation will typically
begin with the authenticator and the peer negotiating EAP. The begin with the authenticator and the peer negotiating EAP. The
authenticator will then typically send an EAP-Request/Identity packet authenticator will then typically send an EAP-Request/Identity packet
to the peer, and the peer will respond with an EAP-Response/Identity to the peer, and the peer will respond with an EAP-Response/Identity
packet to the authenticator, containing the peer's userId. packet to the authenticator, containing the peer's user-Id.
From this point forward, while nominally the EAP conversation occurs From this point forward, while nominally the EAP conversation occurs
between the EAP authenticator and the peer, the authenticator MAY act between the EAP authenticator and the peer, the authenticator MAY act
as a passthrough device, with the EAP packets received from the peer as a pass-through device, with the EAP packets received from the peer
being encapsulated for transmission to a backend security server. In being encapsulated for transmission to a backend authentication
the discussion that follows, we will use the term "EAP server" to server. In the discussion that follows, we will use the term "EAP
denote the ultimate endpoint conversing with the peer. server" to denote the ultimate endpoint conversing with the peer.
2.1.1. Base Case 2.1.1. Base Case
Once having received the peer's Identity, the EAP server MUST respond Once having received the peer's Identity, the EAP server MUST respond
with an EAP-TLS/Start packet, which is an EAP-Request packet with with an EAP-TLS/Start packet, which is an EAP-Request packet with
EAP-Type=EAP-TLS, the Start (S) bit set, and no data. The EAP-TLS EAP-Type=EAP-TLS, the Start (S) bit set, and no data. The EAP-TLS
conversation will then begin, with the peer sending an EAP-Response conversation will then begin, with the peer sending an EAP-Response
packet with EAP-Type=EAP-TLS. The data field of that packet will packet with EAP-Type=EAP-TLS. The data field of that packet will
encapsulate one or more TLS records in TLS record layer format, encapsulate one or more TLS records in TLS record layer format,
containing a TLS client_hello handshake message. The current cipher containing a TLS client_hello handshake message. The current cipher
skipping to change at page 5, line 27 skipping to change at page 5, line 27
certificate_request, server_hello_done and/or finished handshake certificate_request, server_hello_done and/or finished handshake
messages, and/or a TLS change_cipher_spec message. The server_hello messages, and/or a TLS change_cipher_spec message. The server_hello
handshake message contains a TLS version number, another random handshake message contains a TLS version number, another random
number, a sessionId, and a ciphersuite. The version offered by the number, a sessionId, and a ciphersuite. The version offered by the
server MUST correspond to TLS v1.0 or later. server MUST correspond to TLS v1.0 or later.
If the peer's sessionId is null or unrecognized by the server, the If the peer's sessionId is null or unrecognized by the server, the
server MUST choose the sessionId to establish a new session. server MUST choose the sessionId to establish a new session.
Otherwise, the sessionId will match that offered by the peer, Otherwise, the sessionId will match that offered by the peer,
indicating a resumption of the previously established session with indicating a resumption of the previously established session with
that sessionID. The server will also choose a ciphersuite from those that sessionId. The server will also choose a ciphersuite from those
offered by the peer. If the session matches the peer's, then the offered by the peer. If the session matches the peer's, then the
ciphersuite MUST match the one negotiated during the handshake ciphersuite MUST match the one negotiated during the handshake
protocol execution that established the session. protocol execution that established the session.
If the EAP server is not resuming a previously established session, If the EAP server is not resuming a previously established session,
then it MUST include a TLS server_certificate handshake message, and then it MUST include a TLS server_certificate handshake message, and
a server_hello_done handshake message MUST be the last handshake a server_hello_done handshake message MUST be the last handshake
message encapsulated in this EAP-Request packet. message encapsulated in this EAP-Request packet.
The certificate message contains a public key certificate chain for The certificate message contains a public key certificate chain for
either a key exchange public key (such as an RSA or Diffie-Hellman either a key exchange public key (such as an RSA or Diffie-Hellman
key exchange public key) or a signature public key (such as an RSA or key exchange public key) or a signature public key (such as an RSA or
DSS signature public key). In the latter case, a TLS DSS signature public key). In the latter case, a TLS
server_key_exchange handshake message MUST also be included to allow server_key_exchange handshake message MUST also be included to allow
the key exchange to take place. the key exchange to take place.
The certificate_request message is included when the server desires The certificate_request message is included when the server desires
the peer to authenticate itself via public key. While the EAP server the peer to authenticate itself via public key. While the EAP server
SHOULD require peer authentication, this is not mandatory, since SHOULD require peer authentication, this is not mandatory, since
there are circumstances in which peer authentication will not be there are circumstances in which peer authentication will not be
needed (e.g. emergency services, as described in [UNAUTH]), or where needed (e.g., emergency services, as described in [UNAUTH]), or where
the peer will authenticate via some other means. the peer will authenticate via some other means.
If the peer supports EAP-TLS and is configured to use it, it MUST If the peer supports EAP-TLS and is configured to use it, it MUST
respond to the EAP-Request with an EAP-Response packet of EAP- respond to the EAP-Request with an EAP-Response packet of EAP-
Type=EAP-TLS. If the preceding server_hello message sent by the EAP Type=EAP-TLS. If the preceding server_hello message sent by the EAP
server in the preceding EAP-Request packet did not indicate the server in the preceding EAP-Request packet did not indicate the
resumption of a previous session, the data field of this packet MUST resumption of a previous session, the data field of this packet MUST
encapsulate one or more TLS records containing a TLS encapsulate one or more TLS records containing a TLS
client_key_exchange, change_cipher_spec and finished messages. If client_key_exchange, change_cipher_spec and finished messages. If
the EAP server sent a certificate_request message in the preceding the EAP server sent a certificate_request message in the preceding
skipping to change at page 12, line 18 skipping to change at page 12, line 18
[RFC4284] to determine the appropriate configuration. [RFC4284] to determine the appropriate configuration.
In the case where the peer and server support privacy and mutual In the case where the peer and server support privacy and mutual
authentication, the conversation will appear as follows: authentication, the conversation will appear as follows:
Authenticating Peer Authenticator Authenticating Peer Authenticator
------------------- ------------- ------------------- -------------
<- EAP-Request/ <- EAP-Request/
Identity Identity
EAP-Response/ EAP-Response/
Identity (AnonymousNAI) -> Identity (Anonymous NAI) ->
<- EAP-Request/ <- EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS Start) (TLS Start)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS client_hello)-> (TLS client_hello)->
<- EAP-Request/ <- EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS server_hello, (TLS server_hello,
TLS certificate, TLS certificate,
skipping to change at page 23, line 21 skipping to change at page 23, line 21
[2] Privacy is an optional feature described in Section 2.1.4. [2] Privacy is an optional feature described in Section 2.1.4.
[3] BCP 86 [RFC3766] Section 5 offers advice on the required RSA or [3] BCP 86 [RFC3766] Section 5 offers advice on the required RSA or
DH module and DSA subgroup size in bits, for a given level of attack DH module and DSA subgroup size in bits, for a given level of attack
resistance in bits. For example, a 2048-bit RSA key is recommended resistance in bits. For example, a 2048-bit RSA key is recommended
to provide 128-bit equivalent key strength. The National Institute to provide 128-bit equivalent key strength. The National Institute
for Standards and Technology (NIST) also offers advice on appropriate for Standards and Technology (NIST) also offers advice on appropriate
key sizes in [SP800-57]. key sizes in [SP800-57].
[4] EAP-TLS inherits the secure ciphersuite negotiation features of [4] EAP-TLS inherits the secure ciphersuite negotiation features of
TLS, including KDF negotiation when utilized with TLS v1.2 TLS, including key derivation function negotiation when utilized with
[RFC4346bis]. TLS v1.2 [RFC4346bis].
5.2. Peer and Server Identities 5.2. Peer and Server Identities
The EAP-TLS peer name (Peer-Id) represents the identity to be used The EAP-TLS peer name (Peer-Id) represents the identity to be used
for access control and accounting purposes. The Server-Id represents for access control and accounting purposes. The Server-Id represents
the identity of the EAP server. Together the Peer-Id and Server-Id the identity of the EAP server. Together the Peer-Id and Server-Id
name the entities involved in deriving the MSK/EMSK. name the entities involved in deriving the MSK/EMSK.
In EAP-TLS, the Peer-Id and Server-Id are determined from the subject In EAP-TLS, the Peer-Id and Server-Id are determined from the subject
or subjectAltName fields in the peer and server certificates. For or subjectAltName fields in the peer and server certificates. For
skipping to change at page 24, line 10 skipping to change at page 24, line 10
A server identity will typically represent a host, not a user or a A server identity will typically represent a host, not a user or a
resource. As a result, a subjectAltName of type dnsName SHOULD be resource. As a result, a subjectAltName of type dnsName SHOULD be
present in the server certificate. If a dnsName is not available present in the server certificate. If a dnsName is not available
other field types (for example a subjectAltName of type ipAddress or other field types (for example a subjectAltName of type ipAddress or
uniformResourceIdentifier) MAY be used. uniformResourceIdentifier) MAY be used.
Conforming implementations generating new certificates with Network Conforming implementations generating new certificates with Network
Access Identifiers (NAIs) MUST use the rfc822Name in the subject Access Identifiers (NAIs) MUST use the rfc822Name in the subject
alternative name field to describe such identities. The use of the alternative name field to describe such identities. The use of the
subject name field to contain an emailAddress RDN is deprecated, and subject name field to contain an emailAddress Relative Distinguished
MUST NOT be used. The subject name field MAY contain other RDNs for Name (RDN) is deprecated, and MUST NOT be used. The subject name
representing the subject's identity. field MAY contain other RDNs for representing the subject's identity.
Where it is non-empty, the subject name field MUST contain an X.500 Where it is non-empty, the subject name field MUST contain an X.500
distinguished name (DN). If subject naming information is present distinguished name (DN). If subject naming information is present
only in the subject name field of a peer certificate and the peer only in the subject name field of a peer certificate and the peer
identity represents a host or device the subject name field SHOULD identity represents a host or device the subject name field SHOULD
contain a CN RDN or serialNumber RDN. If subject naming information contain a CommonName (CN) RDN or serialNumber RDN. If subject naming
is present only in the subject name field of a server certificate, information is present only in the subject name field of a server
then the subject name field SHOULD contain a CN RDN or serialNumber certificate, then the subject name field SHOULD contain a CN RDN or
RDN. serialNumber RDN.
It is possible for more than one subjectAltName field to be present It is possible for more than one subjectAltName field to be present
in a peer or server certificate in addition to an empty or non-empty in a peer or server certificate in addition to an empty or non-empty
subject distinguished name. EAP-TLS implementations supporting subject distinguished name. EAP-TLS implementations supporting
export of the Peer-Id and Server-Id SHOULD export all the export of the Peer-Id and Server-Id SHOULD export all the
subjectAltName fields within Peer-Ids or Server-Ids, and SHOULD also subjectAltName fields within Peer-Ids or Server-Ids, and SHOULD also
export a non-empty subject distinguished name field within the Peer- export a non-empty subject distinguished name field within the Peer-
Ids or Server-Ids. All of the exported Peer-Ids and Server-Ids are Ids or Server-Ids. All of the exported Peer-Ids and Server-Ids are
considered valid. considered valid.
EAP-TLS implementations supporting export of the Peer-Id and Server- EAP-TLS implementations supporting export of the Peer-Id and Server-
Id SHOULD export Peer-Ids and Server-Ids in the same order in which Id SHOULD export Peer-Ids and Server-Ids in the same order in which
they appear within the certificate. Such canonical ordering would they appear within the certificate. Such canonical ordering would
aid in comparison operations and would enable using those IDs for key aid in comparison operations and would enable using those identifiers
derivation if that is deemed useful. However, the ordering of fields for key derivation if that is deemed useful. However, the ordering
within the certificate SHOULD NOT be used for access control. of fields within the certificate SHOULD NOT be used for access
control.
5.3. Certificate Validation 5.3. Certificate Validation
Since the EAP-TLS server is typically connected to the Internet, it Since the EAP-TLS server is typically connected to the Internet, it
SHOULD support validating the peer certificate using RFC 3280 SHOULD support validating the peer certificate using RFC 3280
[RFC3280] conformant path validation, including the ability to [RFC3280] compliant path validation, including the ability to
retrieve intermediate certificates that may be necessary to validate retrieve intermediate certificates that may be necessary to validate
the peer certificate. For details, see [RFC3280] Section 4.2.2.1. the peer certificate. For details, see [RFC3280] Section 4.2.2.1.
Where the EAP-TLS server is unable to retrieve intermediate Where the EAP-TLS server is unable to retrieve intermediate
certificates, it either will need to be pre-configured with the certificates, it either will need to be pre-configured with the
necessary intermediate certificates to complete path validation or it necessary intermediate certificates to complete path validation or it
will rely on the EAP-TLS peer to provide this information as part of will rely on the EAP-TLS peer to provide this information as part of
the TLS Handshake (see [RFC4346] section 7.4.6). the TLS Handshake (see [RFC4346] section 7.4.6).
In contrast to the EAP-TLS server, the EAP-TLS peer may not have In contrast to the EAP-TLS server, the EAP-TLS peer may not have
Internet connectivity. Therefore the EAP-TLS server SHOULD provide Internet connectivity. Therefore the EAP-TLS server SHOULD provide
its entire certificate chain minus the root to facilitate certificate its entire certificate chain minus the root to facilitate certificate
validation by the peer. The EAP-TLS peer SHOULD support validating validation by the peer. The EAP-TLS peer SHOULD support validating
the server certificate using RFC 3280 [RFC3280] conformant path the server certificate using RFC 3280 [RFC3280] compliant path
validation. validation.
Once a TLS session is established EAP-TLS peer and server Once a TLS session is established EAP-TLS peer and server
implementations MUST validate that the identities represented in the implementations MUST validate that the identities represented in the
certificate are appropriate and authorized for use with EAP-TLS. The certificate are appropriate and authorized for use with EAP-TLS. The
authorization process makes use of the contents of the certificates authorization process makes use of the contents of the certificates
as well as other contextual information. While authorization as well as other contextual information. While authorization
requirements will vary from deployment to deployment it is requirements will vary from deployment to deployment it is
RECOMMENDED that implementations be able to authorize based on the RECOMMENDED that implementations be able to authorize based on the
EAP-TLS Peer-Id and Server-Id determined as described in Section 5.2. EAP-TLS Peer-Id and Server-Id determined as described in Section 5.2.
skipping to change at page 28, line 23 skipping to change at page 28, line 27
metropolitan area networks - Specific Requirements Part metropolitan area networks - Specific Requirements Part
11: Wireless LAN Medium Access Control (MAC) and 11: Wireless LAN Medium Access Control (MAC) and
Physical Layer (PHY) Specifications, IEEE Std. Physical Layer (PHY) Specifications, IEEE Std.
802.11-2007, 2007. 802.11-2007, 2007.
[IEEE-802.16e] Institute of Electrical and Electronics Engineers, "IEEE [IEEE-802.16e] Institute of Electrical and Electronics Engineers, "IEEE
Standard for Local and Metropolitan Area Networks: Part Standard for Local and Metropolitan Area Networks: Part
16: Air Interface for Fixed and Mobile Broadband Wireless 16: Air Interface for Fixed and Mobile Broadband Wireless
Access Systems: Amendment for Physical and Medium Access Access Systems: Amendment for Physical and Medium Access
Control Layers for Combined Fixed and Mobile Operations Control Layers for Combined Fixed and Mobile Operations
in Licensed Bands" IEEE 802.16e, August 2005. in Licensed Bands", IEEE 802.16e, August 2005.
[He] He, C., Sundararajan, M., Datta, A., Derek, A. and J. [He] He, C., Sundararajan, M., Datta, A., Derek, A. and J.
Mitchell, "A Modular Correctness Proof of IEEE 802.11i Mitchell, "A Modular Correctness Proof of IEEE 802.11i
and TLS", CCS '05, November 7-11, 2005, Alexandria, and TLS", CCS '05, November 7-11, 2005, Alexandria,
Virginia, USA Virginia, USA
[KEYFRAME] Aboba, B., Simon, D. and P. Eronen, "Extensible [KEYFRAME] Aboba, B., Simon, D. and P. Eronen, "Extensible
Authentication Protocol (EAP) Key Management Framework", Authentication Protocol (EAP) Key Management Framework",
draft-ietf-eap-keying-22.txt, Internet Draft (work in draft-ietf-eap-keying-22.txt, Internet Draft (work in
progress), November 2007. progress), November 2007.
 End of changes. 15 change blocks. 
26 lines changed or deleted 27 lines changed or added

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