< draft-nir-tls-eap-09.txt		draft-nir-tls-eap-10.txt >
	TLS Working Group Y. Nir		TLS Working Group Y. Nir
	Internet-Draft Check Point		Internet-Draft Check Point
	Intended status: Standards Track Y. Sheffer		Intended status: Standards Track Y. Sheffer
	Expires: July 7, 2011 Independent		Expires: September 1, 2011 Independent
	H. Tschofenig		H. Tschofenig
	NSN		NSN
	P. Gutmann		P. Gutmann
	University of Auckland		University of Auckland
	January 3, 2011		February 28, 2011
	TLS using EAP Authentication		TLS using EAP Authentication
	draft-nir-tls-eap-09		draft-nir-tls-eap-10
	Abstract		Abstract
	This document describes an extension to the TLS protocol to allow TLS		This document describes an extension to the TLS protocol to allow TLS
	clients to authenticate with legacy credentials using the Extensible		clients to authenticate with legacy credentials using the Extensible
	Authentication Protocol (EAP).		Authentication Protocol (EAP).
	This work follows the example of IKEv2, where EAP has been added to		This work follows the example of IKEv2, where EAP has been added to
	the protocol to allow clients to use different credentials such as		the protocol to allow clients to use different credentials such as
	passwords, token cards, and shared secrets.		passwords, token cards, and shared secrets.
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	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 July 7, 2011.		This Internet-Draft will expire on September 1, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 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 18 ¶		skipping to change at page 3, line 18 ¶
	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
	EAP protocol to run between the TLS server (called an "authenticator"		EAP protocol to run between the TLS server (called an "authenticator"
	in EAP) and the TLS client (called a "supplicant"). This allows the		in EAP) and the TLS client (called a "supplicant"). This allows the
	TLS architecture to handle client authentication before exposing the		TLS architecture to handle client authentication before exposing the
	server application software to an unauthenticated client. In doing		server application software to an unauthenticated client. In doing
	this, we follow the approach taken for IKEv2 in [RFC4306]. However,		this, we follow the approach taken for IKEv2 in [RFC5996]. However,
	similar to regular TLS, we protect the user identity by only sending		similar to regular TLS, we protect the user identity by only sending
	the client identity after the server has authenticated. In this our		the client identity after the server has authenticated. In this our
	solution differs from that of IKEv2.		solution differs from that of IKEv2.
	Currently used applications that rely on non-certificate user		Currently used applications that rely on non-certificate user
	credentials use TLS to authenticate the server only. After that, the		credentials use TLS to authenticate the server only. After that, the
	application takes over, and presents a login screen where the user is		application takes over, and presents a login screen where the user is
	expected to present their credentials.		expected to present their credentials.
	This creates several problems. It allows a client to access the		This creates several problems. It allows a client to access the
	skipping to change at page 6, line 35 ¶		skipping to change at page 6, line 35 ¶
	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
	purposes only, we use the GPSK EAP method [EAP-GPSK].		purposes only, we use the GPSK EAP method [RFC5433].
	Client Server		Client Server
	------ ------		------ ------
	ClientHello(*) -------->		ClientHello(*) -------->
	ServerHello(*)		ServerHello(*)
	(Certificate)		(Certificate)
	ServerKeyExchange		ServerKeyExchange
	EapMsg(Identity-Request)		EapMsg(Identity-Request)
	<-------- ServerHelloDone		<-------- ServerHelloDone
	skipping to change at page 8, line 43 ¶		skipping to change at page 8, line 43 ¶
	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 the		eap_payload is defined in section 4 of RFC 3748. It includes the
	Code, Identifier, Length and Data fields of the EAP packet.		Code, Identifier, Length and Data fields of the EAP 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 [RFC5247]), the Finished
	Finished message is calculated as follows:		message is calculated as follows:
	struct {		struct {
	opaque verify_data[12];		opaque verify_data[12];
	} Finished;		} Finished;
	verify_data		verify_data
	PRF(MSK, finished_label, MD5(handshake_messages) +		PRF(MSK, finished_label, MD5(handshake_messages) +
	SHA-1(handshake_messages)) [0..11];		SHA-1(handshake_messages)) [0..11];
	The finished_label and the PRF are as defined in section 7.4.9 of		The finished_label and the PRF are as defined in section 7.4.9 of
	skipping to change at page 15, line 16 ¶		skipping to change at page 15, line 16 ¶
	The authors would like to thank Josh Howlett for his comments.		The authors would like to thank Josh Howlett for his comments.
	The TLS Inner Application Extension work ([TLS/IA]) has inspired the		The TLS Inner Application Extension work ([TLS/IA]) has inspired the
	authors to create this simplified work. TLS/IA provides a somewhat		authors to create this simplified work. TLS/IA provides a somewhat
	different approach to integrating non-certificate credentials into		different approach to integrating non-certificate credentials into
	the TLS protocol, in addition to several other features available		the TLS protocol, in addition to several other features available
	from the RADIUS namespace.		from the RADIUS namespace.
	The authors would also like to thank the various contributors to		The authors would also like to thank the various contributors to
	[RFC4306] whose work inspired this one.		[RFC5996] whose work inspired this one.
	9. Changes from Previous Versions		9. Changes from Previous Versions
	9.1. Changes in version -02		9.1. Changes in version -02
	o Added discussion of alternative designs.		o Added discussion of alternative designs.
	9.2. Changes in version -01		9.2. Changes in version -01
	o Changed the construction of the Finished message		o Changed the construction of the Finished message
	skipping to change at page 18, line 39 ¶		skipping to change at page 18, line 39 ¶
	October 2003.		October 2003.
	[Dia-EAP] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible		[Dia-EAP] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
	Authentication Protocol (EAP) Application", RFC 4072,		Authentication Protocol (EAP) Application", RFC 4072,
	August 2005.		August 2005.
	[Diameter]		[Diameter]
	Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.		Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
	Arkko, "Diameter Base Protocol", RFC 3588, September 2003.		Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
	[EAP-GPSK]
	Clancy, T. and H. Tschofenig, "EAP Generalized Pre-Shared
	Key (EAP-GPSK)", draft-ietf-emu-eap-gpsk-05 (work in
	progress), April 2007.
	[I-D.ietf-eap-keying]
	Aboba, B., "Extensible Authentication Protocol (EAP) Key
	Management Framework", draft-ietf-eap-keying-18 (work in
	progress), February 2007.
	[I.D.Webauth-phishing]		[I.D.Webauth-phishing]
	Hartman, S., "Requirements for Web Authentication		Hartman, S., "Requirements for Web Authentication
	Resistant to Phishing", draft-hartman-webauth-phishing-03		Resistant to Phishing", draft-hartman-webauth-phishing-09
	(work in progress), March 2007.		(work in progress), August 2008.
	[MITM] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle		[MITM] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle
	in Tunneled Authentication Protocols", IACR ePrint		in Tunneled Authentication Protocols", IACR ePrint
	Archive , October 2002.		Archive , October 2002.
	[RAD-EAP] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication		[RAD-EAP] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
	Dial In User Service) Support For Extensible		Dial In User Service) Support For Extensible
	Authentication Protocol (EAP)", RFC 3579, September 2003.		Authentication Protocol (EAP)", RFC 3579, September 2003.
	[RADIUS] Rigney, C., Willens, S., Rubens, A., and W. Simpson,		[RADIUS] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
	"Remote Authentication Dial In User Service (RADIUS)",		"Remote Authentication Dial In User Service (RADIUS)",
	RFC 2865, June 2000.		RFC 2865, June 2000.
	[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",		[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible
	RFC 4306, December 2005.		Authentication Protocol (EAP) Key Management Framework",
			RFC 5247, August 2008.
			[RFC5433] Clancy, T. and H. Tschofenig, "EAP Generalized Pre-Shared
			Key (EAP-GPSK)", RFC 5433, February 2009.
			[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
			"Internet Key Exchange Protocol: IKEv2", RFC 5996,
			September 2010.
	[TLS-PSK] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites		[TLS-PSK] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
	for Transport Layer Security (TLS)", RFC 4279,		for Transport Layer Security (TLS)", RFC 4279,
	December 2005.		December 2005.
	[TLS/IA] Funk, P., Blake-Wilson, S., Smith, H., Tschofenig, N., and		[TLS/IA] Funk, P., Blake-Wilson, S., Smith, H., Tschofenig, N., and
	T. Hardjono, "TLS Inner Application Extension (TLS/IA)",		T. Hardjono, "TLS Inner Application Extension (TLS/IA)",
	draft-funk-tls-inner-application-extension-03 (work in		draft-funk-tls-inner-application-extension-03 (work in
	progress), June 2006.		progress), June 2006.
End of changes. 11 change blocks.
	23 lines changed or deleted		21 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/