< draft-nir-tls-eap-00.txt		draft-nir-tls-eap-01.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: December 9, 2007 H. Tschofenig		Expires: January 5, 2008 H. Tschofenig
	NSN		NSN
	P. Gutmann		P. Gutmann
	University of Auckland		University of Auckland
	June 7, 2007		July 4, 2007
	TLS using EAP Authentication		TLS using EAP Authentication
	draft-nir-tls-eap-00.txt		draft-nir-tls-eap-01.txt
	Status of this Memo		Status of this Memo
	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
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	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 December 9, 2007.		This Internet-Draft will expire on January 5, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	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).
	skipping to change at page 3, line 25 ¶		skipping to change at page 3, line 25 ¶
	3.4. Calculating the Finished message . . . . . . . . . . . . . 9		3.4. Calculating the Finished message . . . . . . . . . . . . . 9
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 10		4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	4.1. InterimAuth vs. Finished . . . . . . . . . . . . . . . . . 10		4.1. InterimAuth vs. Finished . . . . . . . . . . . . . . . . . 10
	4.2. Identity Protection . . . . . . . . . . . . . . . . . . . 10		4.2. Identity Protection . . . . . . . . . . . . . . . . . . . 10
	4.3. Mutual Authentication . . . . . . . . . . . . . . . . . . 11		4.3. Mutual Authentication . . . . . . . . . . . . . . . . . . 11
	5. Performance Considerations . . . . . . . . . . . . . . . . . . 12		5. Performance Considerations . . . . . . . . . . . . . . . . . . 12
	6. Operational Considerations . . . . . . . . . . . . . . . . . . 13		6. Operational Considerations . . . . . . . . . . . . . . . . . . 13
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
	9. Changes from Previous Versions . . . . . . . . . . . . . . . . 16		9. Changes from Previous Versions . . . . . . . . . . . . . . . . 16
	9.1. Changes from the protocol model draft . . . . . . . . . . 16		9.1. Changes in version -01 . . . . . . . . . . . . . . . . . . 16
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17		9.2. Changes from the protocol model draft . . . . . . . . . . 16
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 17		10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 17
	10.2. Informative References . . . . . . . . . . . . . . . . . . 17		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19		11.1. Normative References . . . . . . . . . . . . . . . . . . . 18
	Intellectual Property and Copyright Statements . . . . . . . . . . 20		11.2. Informative References . . . . . . . . . . . . . . . . . . 18
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
			Intellectual Property and Copyright Statements . . . . . . . . . . 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 9 ¶		skipping to change at page 7, line 9 ¶
	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
	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 client supports this extension.		the communicating application (either client or server) supports
			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 MSCHAPv2 EAP method		purposes only, we use the GPSK EAP method [EAP-GPSK].
	[I-D.dpotter-pppext-eap-mschap].
	Client Server		Client Server
	------ ------		------ ------
	ClientHello(*) -------->		ClientHello(*) -------->
	ServerHello(*)		ServerHello(*)
	(Certificate)		(Certificate)
	ServerKeyExchange		ServerKeyExchange
	EapMsg(Identity-Request)		EapMsg(Identity-Request)
	<-------- ServerHelloDone		<-------- ServerHelloDone
	ClientKeyExchange		ClientKeyExchange
	(CertificateVerify)		(CertificateVerify)
	ChangeCipherSpec		ChangeCipherSpec
	InterimAuth		InterimAuth
	EapMsg(Identity-Reply) -------->		EapMsg(Identity-Reply) -------->
	ChangeCipherSpec		ChangeCipherSpec
	InterimAuth		InterimAuth
	EapMsg(MS-CHAP-v2-Request)		EapMsg(GPSK-Request)
	<--------		<--------
	EapMsg(MS-CHAP-v2-Reply) -------->		EapMsg(GPSK-Reply) -------->
			EapMsg(GPSK-Request)
			<--------
			EapMsg(GPSK-Reply) -------->
	EapMsg(Success)		EapMsg(Success)
	<-------- Finished		<-------- Finished
	Finished -------->		Finished -------->
	(*) The ClientHello and ServerHello include the tee_supported		(*) The ClientHello and ServerHello include the tee_supported
	extension to indicate support for TEE		extension to indicate support for TEE
	The client indicates in the first message its support for TEE. The		The client indicates in the first message its support for TEE. The
	server sends an EAP identity request in the reply. The client sends		server sends an EAP identity request in the reply. The client sends
	the identity reply after the handshake completion. The EAP request-		the identity reply after the handshake completion. The EAP request-
	skipping to change at page 9, line 21 ¶		skipping to change at page 9, line 29 ¶
	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
	[TLS].		[TLS].
	The handshake_messages field, similar to regular TLS, comprises all		The handshake_messages field, unlike regular TLS, does not sign all
	of the data from all messages in this handshake, including any EapMsg		the data in the handshake. Instead it signs all the data that has
	and InterimAuth messages, up to but not including this Finished		not been signed by the previous InterimAuth message. The
	message. This is the concatenation of all the Handshake structures		handshake_messages field includes all of the octets beginning with
	exchanged thus far, as defined in section 7.4 of [TLS].		and including the InterimAuth message, up to but not including this
			Finished message. This is the concatenation of all the Handshake
			structures exchanged thus far, and not yet signed, as defined in
			section 7.4 of [TLS]and in this document.
	The Master Session Key (MSK) is derived by the AAA server and by the		The Master Session Key (MSK) is derived by the AAA server and by the
	client if the EAP method is key-generating. On the server-side, it		client if the EAP method is key-generating. On the server-side, it
	is typically received from the AAA server over the RADIUS or Diameter		is typically received from the AAA server over the RADIUS or Diameter
	protocol. On the client-side, it is passed to TLS by some other		protocol. On the client-side, it is passed to TLS by some other
	method.		method.
	If the EAP method is not key-generating, then the Finished message is		If the EAP method is not key-generating, then the master_secret is
	calculated exactly as described in [TLS]. For a discussion on the		used to sign the messages instead of the MSK. For a discussion on
	use of such methods, see Section 4.1.		the use of such methods, see Section 4.1.
	4. Security Considerations		4. Security Considerations
	4.1. InterimAuth vs. Finished		4.1. InterimAuth vs. Finished
	In regular TLS, the Finished message provides two functions: it signs		In regular TLS, the Finished message provides two functions: it signs
	all preceding messages, and it signals that application data can now		all preceding messages, and it signals that application data can now
	be sent. In TEE, some of the messages are signed twice.		be sent. In TEE, it only signs those messages that have not yet been
			signed.
	Some EAP methods, such as EAP-TLS, EAP-IKEv2 and EAP-SIM generate		Some EAP methods, such as EAP-TLS, EAP-IKEv2 and EAP-SIM generate
	keys in addition to authenticating clients. Such methods are said to		keys in addition to authenticating clients. Such methods are said to
	be resistant to man-in-the-middle (MITM) attacks as discussed in		be resistant to man-in-the-middle (MITM) attacks as discussed in
	[MITM]. Such methods are called key-generating methods.		[MITM]. Such methods are called key-generating methods.
	To realize the benefit of such methods, we need to verify the key		To realize the benefit of such methods, we need to verify the key
	that was generated within the EAP method. This is referred to as the		that was generated within the EAP method. This is referred to as the
	MSK in EAP. In TEE, the InterimAuth message signs all previous		MSK in EAP. In TEE, the InterimAuth message signs all previous
	messages with the master_secret, just like the Finished message in		messages with the master_secret, just like the Finished message in
	regular TLS. The Finished message signs all previous messages using		regular TLS. The Finished message signs the rest of the messages
	the MSK if such exists. If not, then the messages are signed with		using the MSK if such exists. If not, then the messages are signed
	the master_secret as in regular TLS.		with the master_secret as in regular TLS.
	The need for signing twice arises from the fact that we need to use		The need for signing twice arises from the fact that we need to use
	both the master_secret and the MSK. It was possible to use just one		both the master_secret and the MSK. It was possible to use just one
	Finished record and blend the MSK into the master_secret. However,		Finished record and blend the MSK into the master_secret. However,
	this would needlessly complicate the protocol and make security		this would needlessly complicate the protocol and make security
	analysis more difficult. Instead, we have decided to follow the		analysis more difficult. Instead, we have decided to follow the
	example of IKEv2, where two AUTH payloads are exchanged.		example of IKEv2, where two AUTH payloads are exchanged.
	It should be noted that using non-key-generating methods may expose		It should be noted that using non-key-generating methods may expose
	the client to a MITM attack if the same method and credentials are		the client to a MITM attack if the same method and credentials are
	used in some other situation, in which the EAP is done outside of a		used in some other situation, in which the EAP is done outside of a
	protected tunnel with an authenticated server. Unless it can be		protected tunnel with an authenticated server. Unless it can be
	determined that the EAP method is never used in such a situation,		determined that the EAP method is never used in such a situation,
	non-key-generating methods SHOULD NOT be used.		non-key-generating methods SHOULD NOT be used. This issue is
			discussed extensively in [Compound-Authentication].
	4.2. Identity Protection		4.2. Identity Protection
	Unlike [TLS-PSK], TEE provides identity protection for the client.		Unlike [TLS-PSK], TEE provides identity protection for the client.
	The client's identity is hidden from a passive eavesdropper using TLS		The client's identity is hidden from a passive eavesdropper using TLS
	encryption. Active attacks are discussed in Section 4.3.		encryption. Active attacks are discussed in Section 4.3.
	We could save one round-trip by having the client send its identity		We could save one round-trip by having the client send its identity
	within the Client Hello message. This is similar to TLS-PSK.		within the Client Hello message. This is similar to TLS-PSK.
	However, we believe that identity protection is a worthy enough goal,		However, we believe that identity protection is a worthy enough goal,
	skipping to change at page 11, line 18 ¶		skipping to change at page 11, line 18 ¶
	server and the client authenticate. Client authentication is		server and the client authenticate. Client authentication is
	obviously done using the EAP method. The server authentication can		obviously done using the EAP method. The server authentication can
	be done in either of two ways:		be done in either of two ways:
	1. The client can verify the server certificate. This may work well		1. The client can verify the server certificate. This may work well
	depending on the scenario, but implies that the client or its		depending on the scenario, but implies that the client or its
	user can recognize the right DN or alternate name, and		user can recognize the right DN or alternate name, and
	distinguish it from plausible alternatives. The introduction to		distinguish it from plausible alternatives. The introduction to
	[I.D.Webauth-phishing] shows that at least in HTTPS, this is not		[I.D.Webauth-phishing] shows that at least in HTTPS, this is not
	always the case.		always the case.
	2. The client can use a mutually authenticated (MA) EAP method such		2. The client can use a mutually authenticated (MA) EAP method such
	as MS-CHAPv2. In this case, server certificate verification does		as GPSK. In this case, server certificate verification does not
	not matter, and the TLS handshake may as well be anonymous. Note		matter, and the TLS handshake may as well be anonymous. Note
	that in this case, the client identity is sent to the server		that in this case, the client identity is sent to the server
	before server authentication.		before server authentication.
	To summarize:		To summarize:
	o Clients MUST NOT propose anonymous ciphersuites, unless they		o Clients MUST NOT propose anonymous ciphersuites, unless they
	support MA EAP methods.		support MA EAP methods.
	o Servers MUST NOT accept anonymous ciphersuites, unless they
	support MA EAP methods. If they support both MA and non-MA
	methods, they SHOULD prefer to use the MA methods.
	o Clients MUST NOT accept non-MA methods if the ciphersuite is		o Clients MUST NOT accept non-MA methods if the ciphersuite is
	anonymous.		anonymous.
	o Clients MUST NOT accpet non-MA mehtods if they are not able to		o Clients MUST NOT accept non-MA methods if they are not able to
	verify the server credentials. Note that this document does not		verify the server credentials. Note that this document does not
	define what verification involves. If the server DN is known and		define what verification involves. If the server DN is known and
	stored on the client, verifying certificate signature and checking		stored on the client, verifying certificate signature and checking
	revocation may be enough. For web browsers, the case is not as		revocation may be enough. For web browsers, the case is not as
	clear cut, and MA methods SHOULD be used.		clear cut, and MA methods SHOULD be used.
	5. Performance Considerations		5. Performance Considerations
	Regular TLS adds two round-trips to a TCP connection. However,		Regular TLS adds two round-trips to a TCP connection. However,
	because of the stream nature of TCP, the client does not really need		because of the stream nature of TCP, the client does not really need
	to wait for the server's Finished message, and can begin sending		to wait for the server's Finished message, and can begin sending
	application data immediately after its own Finished message. In		application data immediately after its own Finished message. In
	practice, many clients do so, and TLS only adds one round-trip of		practice, many clients do so, and TLS only adds one round-trip of
	delay.		delay.
	TEE adds as many round-trips as the EAP method requires. For		TEE adds as many round-trips as the EAP method requires. For
	example, EAP-MD5 requires 1 round-trip, while EAP-SIM requires 2		example, EAP-MD5 requires 1 round-trip, while EAP-GPSK requires 2
	round-trips. Additionally, the client MUST wait for the EAP-Success		round-trips. Additionally, the client MUST wait for the EAP-Success
	message before sending its own Finished message, so we need at least		message before sending its own Finished message, so we need at least
	3 round-trips for the entire handshake. The best a client can do is		3 round-trips for the entire handshake. The best a client can do is
	two round-trips plus however many round-trips the EAP method		two round-trips plus however many round-trips the EAP method
	requires.		requires.
	It should be noted, though, that these extra round-trips save		It should be noted, though, that these extra round-trips save
	processing time at the application level. Two extra round-trips take		processing time at the application level. Two extra round-trips take
	a lot less time than presenting a log-in web page and processing the		a lot less time than presenting a log-in web page and processing the
	user's input.		user's input.
	skipping to change at page 15, line 7 ¶		skipping to change at page 15, line 7 ¶
	7. IANA Considerations		7. IANA Considerations
	IANA is asked to assign an extension type value from the		IANA is asked to assign an extension type value from the
	"ExtensionType Values" registry for the tee_supported extension.		"ExtensionType Values" registry for the tee_supported extension.
	IANA is asked to assign two handshake message types from the "TLS		IANA is asked to assign two handshake message types from the "TLS
	HandshakeType Registry", one for "EapMsg" and one for "InterimAuth".		HandshakeType Registry", one for "EapMsg" and one for "InterimAuth".
	8. Acknowledgments		8. Acknowledgments
			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.		[RFC4306] whose work inspired this one.
	9. Changes from Previous Versions		9. Changes from Previous Versions
	9.1. Changes from the protocol model draft		9.1. Changes in version -01
			o Changed the construction of the Finished message
			o Replaced MS-CHAPv2 with GPSK in examples.
			o Added open issues section.
			o Added reference to [Compound-Authentication]
			o Fixed reference to MITM attack
			9.2. Changes from the protocol model draft
	o Added diagram for EapMsg		o Added diagram for EapMsg
	o Added discussion of EAP applicability		o Added discussion of EAP applicability
	o Added discussion of mutually-authenticated EAP methods vs other		o Added discussion of mutually-authenticated EAP methods vs other
	methods in the security considerations.		methods in the security considerations.
	o Added operational considerations.		o Added operational considerations.
	o Other minor nits.		o Other minor nits.
	10. References		10. Open Issues
	10.1. Normative References		Some have suggested that since the protocol is identical to regular
			TLS up to the InterimAuth message, we should call that the Finished
			message, and call the last message in the extended handshake
			something like "EapFinished". This has the advantage that the
			construction of Finished is already well defined and will not change.
			However, the Finished message has a specific meaning as indicated by
			its name. It means that the handshake is over and that application
			data can now be sent. This is not true of what is in this draft
			called InterimAuth. We'd like the opinions of reviewrs about this
			issue.
			The MSK from the EAP exchange is only used to sign the Finished
			message. It is not used again in the data encryption. In this we
			followed the example of IKEv2. The reason is that TLS already has
			perfectly good ways of exchanging keys, and we do not need this
			capability from EAP methods. Also, using the MSK in keys would
			require an additional ChangeCipherSpec and would complicate the
			protocol. We'd like the opinions of reviewrs about this issue.
			Another response we got was that we should have a MUST requirement
			that only mutually authenticated and key-generating methods be used
			in TEE. This would simplify the security considerations section.
			While we agree that this is a good idea, most EAP methods in common
			use are not compliant. Additionally, such requirements assume that
			EAP packets are visible to a passive attacker. As EAP is used in
			protected tunnels such as in L2TP, in IKEv2 and here, this assumption
			may not be required. If we consider the server authenticated by its
			certificate, it may be acceptable to use a non-MA method.
			It has been suggested that identity protection is not important
			enough to add a roundtrip, and so we should have the client send the
			username in the ClientHello. We are not sure about how others feel
			about this, and would like to solicit the reviewers opinion. Note
			that if this is done, the client sends the user name before ever
			receiving any indication that the server actually supports TEE. This
			might be acceptable in an email client, where the server is
			preconfigured, but it may be unacceptable in other uses, such as web
			browsers.
			11. References
			11.1. Normative References
	[EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.		[EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
	Levkowetz, "Extensible Authentication Protocol (EAP)",		Levkowetz, "Extensible Authentication Protocol (EAP)",
	RFC 3748, June 2004.		RFC 3748, June 2004.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security		[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.1", RFC 4346, April 2006.		(TLS) Protocol Version 1.1", RFC 4346, April 2006.
	[TLS-EXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,		[TLS-EXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
	and T. Wright, "Transport Layer Security (TLS)		and T. Wright, "Transport Layer Security (TLS)
	Extensions", RFC 4366, April 2006.		Extensions", RFC 4366, April 2006.
	10.2. Informative References		11.2. Informative References
			[Compound-Authentication]
			Puthenkulam, J., Lortz, V., Palekar, A., and D. Simon,
			"The Compound Authentication Binding Problem",
			draft-puthenkulam-eap-binding-04 (work in progress),
			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.
	[I-D.dpotter-pppext-eap-mschap]		[EAP-GPSK]
	Potter, D. and J. Zamick, "PPP EAP MS-CHAP-V2		Clancy, T. and H. Tschofenig, "EAP Generalized Pre-Shared
	Authentication Protocol",		Key (EAP-GPSK)", draft-ietf-emu-eap-gpsk-05 (work in
	draft-dpotter-pppext-eap-mschap-01 (work in progress),		progress), April 2007.
	January 2002.
	[I-D.ietf-eap-keying]		[I-D.ietf-eap-keying]
	Aboba, B., "Extensible Authentication Protocol (EAP) Key		Aboba, B., "Extensible Authentication Protocol (EAP) Key
	Management Framework", draft-ietf-eap-keying-18 (work in		Management Framework", draft-ietf-eap-keying-18 (work in
	progress), February 2007.		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-03
	(work in progress), March 2007.		(work in progress), March 2007.
	[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", October 2002.		in Tunneled Authentication Protocols", IACR ePrint
			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",		[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
End of changes. 25 change blocks.
	45 lines changed or deleted		109 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/