< draft-nir-tls-eap-06.txt		draft-nir-tls-eap-07.txt >
	TLS Working Group Y. Nir		TLS Working Group Y. Nir
	Internet-Draft Y. Sheffer		Internet-Draft Y. Sheffer
	Intended status: Standards Track Check Point		Intended status: Standards Track Check Point
	Expires: October 23, 2009 H. Tschofenig		Expires: September 8, 2010 H. Tschofenig
	NSN		NSN
	P. Gutmann		P. Gutmann
	University of Auckland		University of Auckland
	April 21, 2009		March 7, 2010
	TLS using EAP Authentication		TLS using EAP Authentication
	draft-nir-tls-eap-06.txt		draft-nir-tls-eap-07
			Abstract
			This document describes an extension to the TLS protocol to allow TLS
			clients to authenticate with legacy credentials using the Extensible
			Authentication Protocol (EAP).
			This work follows the example of IKEv2, where EAP has been added to
			the protocol to allow clients to use different credentials such as
			passwords, token cards, and shared secrets.
	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.		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), 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 36 ¶		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 October 23, 2009.		This Internet-Draft will expire on September 8, 2010.
	Copyright Notice		Copyright Notice
			Copyright (c) 2010 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
	publication of this document (http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document.		carefully, as they describe your rights and restrictions with respect
			to this document. Code Components extracted from this document must
	Abstract		include Simplified BSD License text as described in Section 4.e of
			the Trust Legal Provisions and are provided without warranty as
	This document describes an extension to the TLS protocol to allow TLS		described in the BSD License.
	clients to authenticate with legacy credentials using the Extensible
	Authentication Protocol (EAP).
	This work follows the example of IKEv2, where EAP has been added to
	the IKEv2 protocol to allow clients to use different credentials such
	as passwords, token cards, and shared secrets.
	When TLS is used with EAP, additional records are sent after the
	ChangeCipherSpec protocol message and before the Finished message,
	effectively creating an extended handshake before the application
	layer data can be sent. Each EapMsg handshake record contains
	exactly one EAP message. Using EAP for client authentication allows
	TLS to be used with various AAA back-end servers such as RADIUS or
	Diameter.
	TLS with EAP may be used for securing a data connection such as HTTP		This document may contain material from IETF Documents or IETF
	or POP3. We believe it has three main benefits:		Contributions published or made publicly available before November
	o The ability of EAP to work with backend servers can remove that		10, 2008. The person(s) controlling the copyright in some of this
	burden from the application layer.		material may not have granted the IETF Trust the right to allow
	o Moving the user authentication into the TLS handshake protects the		modifications of such material outside the IETF Standards Process.
	presumably less secure application layer from attacks by		Without obtaining an adequate license from the person(s) controlling
	unauthenticated parties.		the copyright in such materials, this document may not be modified
	o Using mutual authentication methods within EAP can help thwart		outside the IETF Standards Process, and derivative works of it may
	certain classes of phishing attacks.		not be created outside the IETF Standards Process, except to format
			it for publication as an RFC or to translate it into languages other
			than English.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. EAP Applicability . . . . . . . . . . . . . . . . . . . . 5		1.1. EAP Applicability . . . . . . . . . . . . . . . . . . . . 5
	1.2. Comparison with Design Alternatives . . . . . . . . . . . 5		1.2. Comparison with Design Alternatives . . . . . . . . . . . 5
	1.3. Conventions Used in This Document . . . . . . . . . . . . 5		1.3. Conventions Used in This Document . . . . . . . . . . . . 5
	2. Operating Environment . . . . . . . . . . . . . . . . . . . . 6		2. Operating Environment . . . . . . . . . . . . . . . . . . . . 6
	3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7		3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7
	3.1. The tee_supported Extension . . . . . . . . . . . . . . . 8		3.1. The tee_supported Extension . . . . . . . . . . . . . . . 8
	3.2. The InterimAuth Handshake Message . . . . . . . . . . . . 8		3.2. The InterimAuth Handshake Message . . . . . . . . . . . . 8
	3.3. The EapMsg Handshake Message . . . . . . . . . . . . . . . 8		3.3. The EapMsg Handshake Message . . . . . . . . . . . . . . . 9
	3.4. Calculating the Finished message . . . . . . . . . . . . . 9		3.4. Calculating the Finished message . . . . . . . . . . . . . 9
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 10		4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	4.1. InterimAuth vs. Finished . . . . . . . . . . . . . . . . . 10		4.1. InterimAuth vs. Finished . . . . . . . . . . . . . . . . . 11
	4.2. Identity Protection . . . . . . . . . . . . . . . . . . . 10		4.2. Identity Protection . . . . . . . . . . . . . . . . . . . 11
	4.3. Mutual Authentication . . . . . . . . . . . . . . . . . . 11		4.3. Mutual Authentication . . . . . . . . . . . . . . . . . . 12
	5. Performance Considerations . . . . . . . . . . . . . . . . . . 12		5. Performance Considerations . . . . . . . . . . . . . . . . . . 13
	6. Operational Considerations . . . . . . . . . . . . . . . . . . 13		6. Operational Considerations . . . . . . . . . . . . . . . . . . 14
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
	9. Changes from Previous Versions . . . . . . . . . . . . . . . . 16		9. Changes from Previous Versions . . . . . . . . . . . . . . . . 17
	9.1. Changes in version -02 . . . . . . . . . . . . . . . . . . 16		9.1. Changes in version -02 . . . . . . . . . . . . . . . . . . 17
	9.2. Changes in version -01 . . . . . . . . . . . . . . . . . . 16		9.2. Changes in version -01 . . . . . . . . . . . . . . . . . . 17
	9.3. Changes from the protocol model draft . . . . . . . . . . 16		9.3. Changes from the protocol model draft . . . . . . . . . . 17
	10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 17		10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 18
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 18		11.1. Normative References . . . . . . . . . . . . . . . . . . . 19
	11.2. Informative References . . . . . . . . . . . . . . . . . . 18		11.2. Informative References . . . . . . . . . . . . . . . . . . 19
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
	1. Introduction		1. Introduction
	This document describes a new extension to [TLS]. This extension		This document describes a new extension to [TLS]. This extension
	allows a TLS client to authenticate using [EAP] instead of performing		allows a TLS client to authenticate using [EAP] instead of performing
	the authentication at the application level. The extension follows		the authentication at the application level. The extension follows
	[TLS-EXT]. For the remainder of this document we will refer to this		[TLS-EXT]. For the remainder of this document we will refer to this
	extension as TEE (TLS with EAP Extension).		extension as TEE (TLS with EAP Extension).
	TEE extends the TLS handshake beyond the regular setup, to allow the		TEE extends the TLS handshake beyond the regular setup, to allow the
	skipping to change at page 7, line 7 ¶		skipping to change at page 7, line 7 ¶
	communicates using the RADIUS protocol with EAP ([RADIUS] and		communicates using the RADIUS protocol with EAP ([RADIUS] and
	[RAD-EAP]), or the Diameter protocol ([Diameter] and [Dia-EAP]).		[RAD-EAP]), or the Diameter protocol ([Diameter] and [Dia-EAP]).
	As stated in the introduction, we expect TEE to be used in both		As stated in the introduction, we expect TEE to be used in both
	browsers and applications. Further uses may be authentication and		browsers and applications. Further uses may be authentication and
	key generation for other protocols, and tunneling clients, which so		key generation for other protocols, and tunneling clients, which so
	far have not been standardized.		far have not been standardized.
	3. Protocol Overview		3. Protocol Overview
			When TLS is used with EAP, additional records are sent after the
			ChangeCipherSpec protocol message and before the Finished message,
			effectively creating an extended handshake before the application
			layer data can be sent. Each EapMsg handshake record contains
			exactly one EAP message. Using EAP for client authentication allows
			TLS to be used with various AAA back-end servers such as RADIUS or
			Diameter.
			TLS with EAP may be used for securing a data connection such as HTTP
			or POP3. We believe it has three main benefits:
			o The ability of EAP to work with backend servers can remove that
			burden from the application layer.
			o Moving the user authentication into the TLS handshake protects the
			presumably less secure application layer from attacks by
			unauthenticated parties.
			o Using mutual authentication methods within EAP can help thwart
			certain classes of phishing attacks.
	The TEE extension defines the following:		The TEE extension defines the following:
	o A new extension type called tee_supported, used to indicate that		o A new extension type called tee_supported, used to indicate that
	the communicating application (either client or server) supports		the communicating application (either client or server) supports
	this extension.		this extension.
	o A new message type for the handshake protocol, called InterimAuth,		o A new message type for the handshake protocol, called InterimAuth,
	which is used to sign previous messages.		which is used to sign previous messages.
	o A new message type for the handshake protocol, called EapMsg,		o A new message type for the handshake protocol, called EapMsg,
	which is used to carry a single EAP message.		which is used to carry a single EAP message.
	The diagram below outlines the protocol structure. For illustration		The diagram below outlines the protocol structure. For illustration
	skipping to change at page 9, line 9 ¶		skipping to change at page 9, line 38 ¶
	Note that it is expected that the authentication server notifies the		Note that it is expected that the authentication server notifies the
	TLS server about authentication success or failure, and so TLS need		TLS server about authentication success or failure, and so TLS need
	not inspect the eap_payload within the EapMsg to detect success or		not inspect the eap_payload within the EapMsg to detect success or
	failure.		failure.
	struct {		struct {
	opaque eap_payload[4..65535];		opaque eap_payload[4..65535];
	} EapMsg;		} EapMsg;
	eap_payload is defined in section 4 of RFC 3748. It includes		eap_payload is defined in section 4 of RFC 3748. It includes the
	the Code, Identifier, Length and Data fields of the EAP		Code, Identifier, Length and Data fields of the EAP packet.
	packet.
	3.4. Calculating the Finished message		3.4. Calculating the Finished message
	If the EAP method is key-generating (see [I-D.ietf-eap-keying]), the		If the EAP method is key-generating (see [I-D.ietf-eap-keying]), the
	Finished message is calculated as follows:		Finished message is calculated as follows:
	struct {		struct {
	opaque verify_data[12];		opaque verify_data[12];
	} Finished;		} Finished;
End of changes. 11 change blocks.
	58 lines changed or deleted		72 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/