< draft-ietf-pppext-eap-ttls-04.txt		draft-ietf-pppext-eap-ttls-05.txt >
	PPPEXT Working Group Paul Funk		PPPEXT Working Group Paul Funk
	Internet-Draft Funk Software, Inc.		Internet-Draft Funk Software, Inc.
	Category: Standards Track Simon Blake-Wilson		Category: Standards Track Simon Blake-Wilson
	<draft-ietf-pppext-eap-ttls-04.txt> Basic Commerce &		<draft-ietf-pppext-eap-ttls-05.txt> Basic Commerce &
	Industries, Inc.		Industries, Inc.
	April 2004		July 2004
	EAP Tunneled TLS Authentication Protocol		EAP Tunneled TLS Authentication Protocol
	(EAP-TTLS)		(EAP-TTLS)
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is subject to all provisions		This document is an Internet-Draft and is subject to all provisions
	of Section 10 of RFC2026.		of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	skipping to change at page 2, line ? ¶		skipping to change at page 2, line ? ¶
	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/1id-abstracts.html		http://www.ietf.org/1id-abstracts.html
	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
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2001). All Rights Reserved.		Copyright (C) The Internet Society (2001-2004). All Rights Reserved.
	Abstract		Abstract
	EAP-TTLS is an EAP protocol that extends EAP-TLS. In EAP-TLS, a TLS		EAP-TTLS is an EAP protocol that extends EAP-TLS. In EAP-TLS, a TLS
	handshake is used to mutually authenticate a client and server. EAP-		handshake is used to mutually authenticate a client and server. EAP-
	TTLS extends this authentication negotiation by using the secure		TTLS extends this authentication negotiation by using the secure
	connection established by the TLS handshake to exchange additional		connection established by the TLS handshake to exchange additional
	information between client and server. In EAP-TTLS, the TLS		information between client and server. In EAP-TTLS, the TLS
	handshake may be mutual; or it may be one-way, in which only the		handshake may be mutual; or it may be one-way, in which only the
	server is authenticated to the client. The secure connection		server is authenticated to the client. The secure connection
	skipping to change at page 2, line ? ¶		skipping to change at page 2, line ? ¶
	Thus, EAP-TTLS allows legacy password-based authentication protocols		Thus, EAP-TTLS allows legacy password-based authentication protocols
	to be used against existing authentication databases, while		to be used against existing authentication databases, while
	protecting the security of these legacy protocols against		protecting the security of these legacy protocols against
	eavesdropping, man-in-the-middle and other cryptographic attacks.		eavesdropping, man-in-the-middle and other cryptographic attacks.
	EAP-TTLS also allows client and server to establish keying material		EAP-TTLS also allows client and server to establish keying material
	for use in the data connection between the client and access point.		for use in the data connection between the client and access point.
	The keying material is established implicitly between client and		The keying material is established implicitly between client and
	server based on the TLS handshake.		server based on the TLS handshake.
			This document describes two versions of EAP-TTLS - version 0 and
			version 1. Most of the document concerns EAP-TTLS v0, a form of the
			protocol that has been implemented by multiple vendors. Section 11
			defines EAP-TTLS v1, an enhanced version of the protocol that
			utilizes the TLS extensions mechanism to allow authentications to
			occur within, rather than after, the TLS handshake. The TLS
			extension that is defined is believed to useful in its own right,
			and may be used in other contexts in addition to EAP-TTLS v1.
	Table of Contents		Table of Contents
	1. Introduction......................................................3		1. Introduction......................................................3
	2. Motivation........................................................4		2. Motivation........................................................4
	3. Terminology.......................................................5		3. Terminology.......................................................6
	4. Architectural Model...............................................8		4. Architectural Model...............................................8
	4.1 Carrier Protocols.............................................8		4.1 Carrier Protocols.............................................9
	4.2 Security Relationships........................................9		4.2 Security Relationships.......................................10
	4.3 Messaging.....................................................9		4.3 Messaging....................................................10
	4.4 Resulting Security...........................................10		4.4 Resulting Security...........................................11
	5. Protocol Layering Model..........................................10		5. Protocol Layering Model..........................................11
	6. Protocol Overview................................................11		6. EAP-TTLS version 0 Overview......................................12
	6.1 Phase 1: Handshake...........................................12		6.1 Phase 1: Handshake...........................................13
	6.2 Phase 2: Tunnel..............................................13		6.2 Phase 2: Tunnel..............................................14
	6.3 Piggybacking.................................................14		6.3 Piggybacking.................................................14
	6.4 Session Resumption...........................................14		6.4 Session Resumption...........................................15
	6.4.1 TTLS Server Guidelines for Session Resumption............15		6.4.1 TTLS Server Guidelines for Session Resumption............16
	7. Generating Keying Material.......................................16		7. Generating Keying Material.......................................16
	8. EAP-TTLS Encoding................................................16		8. EAP-TTLS Encoding................................................17
	8.1 EAP-TTLS Start Packet........................................17		8.1 EAP-TTLS Start Packet........................................17
	8.2 EAP-TTLS Packets with No Data................................17		8.2 EAP-TTLS Packets with No Data................................18
	9. Encapsulation of AVPs within the TLS Record Layer................17		9. Encapsulation of AVPs within the TLS Record Layer................18
	9.1 AVP Format...................................................18		9.1 AVP Format...................................................19
	9.2 AVP Sequences................................................19		9.2 AVP Sequences................................................20
	9.3 Guidelines for Maximum Compatibility with AAA Servers........19		9.3 Guidelines for Maximum Compatibility with AAA Servers........20
	10. Tunneled Authentication..........................................20		10. Tunneled Authentication..........................................20
	10.1 Implicit challenge...........................................20		10.1 Implicit challenge...........................................21
	10.2 Tunneled Authentication Protocols............................21		10.2 Tunneled Authentication Protocols............................21
	10.2.1 EAP ......................................................21		10.2.1 EAP ......................................................22
	10.2.2 CHAP .....................................................22		10.2.2 CHAP .....................................................23
	10.2.3 MS-CHAP..................................................23		10.2.3 MS-CHAP..................................................23
	10.2.4 MS-CHAP-V2...............................................23		10.2.4 MS-CHAP-V2...............................................24
	10.2.5 PAP ......................................................25		10.2.5 PAP ......................................................25
	10.3 Performing Multiple Authentications..........................26		10.3 Performing Multiple Authentications..........................26
	11. Key Distribution......................Error! Bookmark not defined.		11. EAP-TTLS Version 1...............................................27
	11.1 AVPs for Key Distribution.........Error! Bookmark not defined.		11.1 EAP-TTLS v1 Introduction.....................................27
	11.1.1 XXX-Data-Cipher-Suite.........Error! Bookmark not defined.		11.2 Intentions Beyond EAP-TTLS...................................28
	11.1.2 XXX-Data-Keying-Material......Error! Bookmark not defined.		11.3 The InnerApplication Extension to TLS........................28
			11.3.1 TLS/IA Overview..........................................29
	12. Discussion of Certificates and PKI...............................26		11.3.2 Message Exchange.........................................31
	13. Message Sequences................................................27		11.3.3 Master Key Permutation...................................31
	13.1 Successful authentication via tunneled CHAP..................27		11.3.4 Session Resumption.......................................33
	13.2 Successful authentication via tunneled EAP/MD5-Challenge.....30		11.3.5 Error Termination........................................33
	13.3 Successful session resumption................................32		11.3.6 Application Session Key Material.........................33
	14. Security Considerations..........................................34		11.3.7 Computing Verification Data..............................34
	15. Changes since previous drafts....................................35		11.3.8 Attribute-Value Pairs (AVPs).............................36
	16. References.......................................................36		11.3.9 TLS/IA Messages..........................................36
	17. Authors' Addresses...............................................37		11.3.10 The InnerApplication Extension...........................37
	18. Full Copyright Statement.........................................37		11.3.11 The PhaseFinished Handshake Message......................37
			11.3.12 The ApplicationPayload Handshake Message.................37
			11.3.13 The InnerApplicationFailure Alert........................38
			11.4 Binding of TLS/IA to EAP-TTLS v1.............................38
			11.4.1 Flags Octet..............................................38
			11.4.2 Version Negotiation......................................39
			11.4.3 Acknowledgement Packets..................................39
			11.4.4 Generating Keying Material...............................40
			12. Discussion of Certificates and PKI...............................40
			13. Message Sequences................................................42
			13.1 Successful authentication via tunneled CHAP..................42
			13.2 Successful authentication via tunneled EAP/MD5-Challenge.....44
			13.3 Successful session resumption................................46
			14. Security Considerations..........................................47
			15. Changes since previous drafts....................................49
			16. References.......................................................50
			17. Authors' Addresses...............................................51
			18. Full Copyright Statement.........................................51
	1. Introduction		1. Introduction
	Extensible Authentication Protocol (EAP) [2] defines a standard		Extensible Authentication Protocol (EAP) [2] defines a standard
	message exchange that allows a server to authenticate a client based		message exchange that allows a server to authenticate a client based
	on an authentication protocol agreed upon by both parties. EAP may		on an authentication protocol agreed upon by both parties. EAP may
	be extended with additional authentication protocols by registering		be extended with additional authentication protocols by registering
	such protocols with IANA.		such protocols with IANA or by defining vendor specific protocols.
	Transport Layer Security (TLS) [3] is an authentication protocol		Transport Layer Security (TLS) [3] is an authentication protocol
	that provides for client authentication of a server or mutual		that provides for client authentication of a server or mutual
	authentication of client and server, as well as secure ciphersuite		authentication of client and server, as well as secure ciphersuite
	negotiation and key exchange between the parties. TLS has been		negotiation and key exchange between the parties. TLS has been
	defined as an authentication protocol for use within EAP (EAP-TLS)		defined as an authentication protocol for use within EAP (EAP-TLS)
	[1].		[1].
	Other authentication protocols are also widely deployed. These are		Other authentication protocols are also widely deployed. These are
	typically password-based protocols, and there is a large installed		typically password-based protocols, and there is a large installed
	skipping to change at page 5, line 4 ¶		skipping to change at page 5, line 32 ¶
	changes dramatically:		changes dramatically:
	- Wireless connections are considerably more susceptible to		- Wireless connections are considerably more susceptible to
	eavesdropping and man-in-the-middle attacks. These attacks may		eavesdropping and man-in-the-middle attacks. These attacks may
	enable dictionary attacks against low-entropy passwords. In		enable dictionary attacks against low-entropy passwords. In
	addition, they may enable channel hijacking, in which an attacker		addition, they may enable channel hijacking, in which an attacker
	gains fraudulent access by seizing control of the communications		gains fraudulent access by seizing control of the communications
	channel after authentication is complete.		channel after authentication is complete.
	- Existing authentication protocols often begin by exchanging the		- Existing authentication protocols often begin by exchanging the
	client’s username in the clear. In the context of eavesdropping		clientÆs username in the clear. In the context of eavesdropping
	on the wireless channel, this can compromise the client’s		on the wireless channel, this can compromise the clientÆs
	anonymity and locational privacy.		anonymity and locational privacy.
	- Often in wireless networks, the access point does not reside in		- Often in wireless networks, the access point does not reside in
	the administrative domain of the service provider with which the		the administrative domain of the service provider with which the
	user has a relationship. For example, the access point may reside		user has a relationship. For example, the access point may reside
	in an airport, coffee shop, or hotel in order to provide public		in an airport, coffee shop, or hotel in order to provide public
	access via 802.11. Even if password authentications are protected		access via 802.11. Even if password authentications are protected
	in the wireless leg, they may still be susceptible to		in the wireless leg, they may still be susceptible to
	eavesdropping within the untrusted wired network of the access		eavesdropping within the untrusted wired network of the access
	point.		point.
	skipping to change at page 10, line 52 ¶		skipping to change at page 11, line 32 ¶
	TTLS server, and performs key distribution to allow network data		TTLS server, and performs key distribution to allow network data
	subsequent to authentication to be securely transmitted between		subsequent to authentication to be securely transmitted between
	client and access point.		client and access point.
	5. Protocol Layering Model		5. Protocol Layering Model
	EAP-TTLS packets are encapsulated within EAP, and EAP in turn		EAP-TTLS packets are encapsulated within EAP, and EAP in turn
	requires a carrier protocol to transport it. EAP-TTLS packets		requires a carrier protocol to transport it. EAP-TTLS packets
	themselves encapsulate TLS, which is then used to encapsulate user		themselves encapsulate TLS, which is then used to encapsulate user
	authentication information. Thus, EAP-TTLS messaging can be		authentication information. Thus, EAP-TTLS messaging can be
	described using a layered model, where each layer encapsulates the		described using a layered model, where each layer is encapsulated by
	layer beneath it. The following diagram clarifies the relationship		the layer beneath it. The following diagram clarifies the
	between protocols:		relationship between protocols:
	+--------------------------------------------------------+		+--------------------------------------------------------+
	| Carrier Protocol (PPP, EAPOL, RADIUS, Diameter, etc.) |		| User Authentication Protocol (PAP, CHAP, MS-CHAP, etc.)|
	+--------------------------------------------------------+		+--------------------------------------------------------+
	| EAP |		| TLS |
	+--------------------------------------------------------+		+--------------------------------------------------------+
	| EAP-TTLS |		| EAP-TTLS |
	+--------------------------------------------------------+		+--------------------------------------------------------+
	| TLS |		| EAP |
	+--------------------------------------------------------+		+--------------------------------------------------------+
	| User Authentication Protocol (PAP, CHAP, MS-CHAP, etc.) |		| Carrier Protocol (PPP, EAPOL, RADIUS, Diameter, etc.) |
	+--------------------------------------------------------+		+--------------------------------------------------------+
	When the user authentication protocol is itself EAP, the layering is		When the user authentication protocol is itself EAP, the layering is
	as follows:		as follows:
	+--------------------------------------------------------+		+--------------------------------------------------------+
	| Carrier Protocol (PPP, EAPOL, RADIUS, Diameter, etc.) |		| User EAP Authentication Protocol (MD-Challenge, etc.) |
	+--------------------------------------------------------+		+--------------------------------------------------------+
	| EAP |		| EAP |
	+--------------------------------------------------------+		+--------------------------------------------------------+
	| EAP-TTLS |
	+--------------------------------------------------------+
	| TLS |		| TLS |
	+--------------------------------------------------------+		+--------------------------------------------------------+
			| EAP-TTLS |
			+--------------------------------------------------------+
	| EAP |		| EAP |
	+--------------------------------------------------------+		+--------------------------------------------------------+
	| User EAP Authentication Protocol (MD-Challenge, etc.) |		| Carrier Protocol (PPP, EAPOL, RADIUS, Diameter, etc.) |
	+--------------------------------------------------------+		+--------------------------------------------------------+
	Methods for encapsulating EAP within carrier protocols are already		Methods for encapsulating EAP within carrier protocols are already
	defined. For example, PPP [5] or EAPOL [4] may be used to transport		defined. For example, PPP [5] or EAPOL [4] may be used to transport
	EAP between client and access point; RADIUS [6] or Diameter [8] are		EAP between client and access point; RADIUS [6] or Diameter [8] are
	used to transport EAP between access point and TTLS server.		used to transport EAP between access point and TTLS server.
	6. Protocol Overview		6. EAP-TTLS version 0 Overview
			[Authors' note: This section as well as sections 7, 8, 9 and 10,
			describe version 0 of the EAP-TTLS protocol. Section 11 describes
			version 1 of EAP-TTLS. Much of the material describing version 0
			also applies to version 1; the version 1 documentation will refer to
			the version 0 material as required. The intention is to provide a
			separate draft for each of the two versions in the near future.]
	A EAP-TTLS negotiation comprises two phases: the TLS handshake phase		A EAP-TTLS negotiation comprises two phases: the TLS handshake phase
	and the TLS tunnel phase.		and the TLS tunnel phase.
	During phase 1, TLS is used to authenticate the TTLS server to the		During phase 1, TLS is used to authenticate the TTLS server to the
	client and, optionally, the client to the TTLS server. Phase 1		client and, optionally, the client to the TTLS server. Phase 1
	results in the activation of a cipher suite, allowing phase 2 to		results in the activation of a cipher suite, allowing phase 2 to
	proceed securely using the TLS record layer. (Note that the type and		proceed securely using the TLS record layer. (Note that the type and
	degree of security in phase 2 depends on the cipher suite negotiated		degree of security in phase 2 depends on the cipher suite negotiated
	during phase 1; if the null cipher suite is negotiated, there will		during phase 1; if the null cipher suite is negotiated, there will
	skipping to change at page 26, line 22 ¶		skipping to change at page 27, line 7 ¶
	using EAP, simply by issuing a EAP-Request with a new protocol type		using EAP, simply by issuing a EAP-Request with a new protocol type
	once the previous authentication succeeded but prior to issuing an		once the previous authentication succeeded but prior to issuing an
	EAP-Success or accepting the user via the AAA carrier protocol.		EAP-Success or accepting the user via the AAA carrier protocol.
	For example, an AAA/H wishing to perform MD5-Challenge followed by		For example, an AAA/H wishing to perform MD5-Challenge followed by
	Generic Token Card would first issue an EAP-Request/MD5-Challenge		Generic Token Card would first issue an EAP-Request/MD5-Challenge
	and receive a response. If the response is satisfactory, it would		and receive a response. If the response is satisfactory, it would
	then issue EAP-Request/Generic Token Card and receive a response. If		then issue EAP-Request/Generic Token Card and receive a response. If
	that response were also satisfactory, it would issue EAP-Success.		that response were also satisfactory, it would issue EAP-Success.
	11. Discussion of Certificates and PKI		11. EAP-TTLS Version 1
			Version 1 of EAP-TTLS improves upon the original version 0 protocol
			in several ways.
			- Session keys developed from inner authentications are mixed with
			the master secret developed during the initial TLS handshake.
			This eliminates the Man-in-the-Middle (MitM) attack against
			tunneled protocols for inner authentications that generate
			session keys. See [15] and [16] for information about this
			attack.
			- A secure final exchange of the result of inner authentication is
			exchanged between client and server to conclude the EAP-TTLS
			exchange. This precludes any possibility of truncation attack
			that could occur when the client relies solely on an unprotected
			EAP-Success message to determine that the server has completed
			its authentication.
			- Inner authentication occurs within the TLS handshake, rather than
			after it. Thus, the TLS handshake itself includes both a standard
			TLS authentication as well as tunneled inner authentication(s)
			using EAP or legacy protocols, as well as any other tunneled
			communications required between client and server.
			11.1 EAP-TTLS v1 Introduction
			Version 1 of EAP-TTLS utilizes the TLS extensions mechanism to
			extend the TLS handshake to include exchange of inner AVPs prior to
			completion of the TLS handshake by exchange of Finished messages.
			The TLS protocol provides a handshake phase and a data phase. EAP-
			TTLS v0, as well as other proposed tunneled EAP types such as EAP-
			PEAP and EAP-FAST, share a common strategy of utilizing the
			handshake phase to establish a tunnel and the data phase to perform
			protected authentication.
			In EAP-TTLS v1, the AVP exchange is folded into the TLS handshake
			itself; in other words, the inner authentication precedes the
			conclusion of the TLS handshake, rather following it.
			An advantage of this arrangement is a certain amount of
			cryptographic integration of inner authentication with standard TLS
			mechanisms. For example, mixing of inner session keys to thwart MitM
			attacks is easily performed in such a way that both the
			authentication result and the final session key is conditioned upon
			these inner session keys.
			The definition of EAP-TTLS v1 proceeds by first defining the
			InnerApplication extension to TLS, and then by defining the binding
			of the extended TLS to EAP via EAP-TTLS v1, which in effect serves
			as a carrier protocol.
			11.2 Intentions Beyond EAP-TTLS
			The use of TLS for EAP is a relative newcomer. TLS has long used for
			many other purposes, most notably for protecting HTTP traffic.
			However, TLS used in these contexts has no mechanism for
			authentication beyond the certificate mechanisms that have been
			defined. Any additional authentication, say in HTTP, must use
			relatively primitive mechanisms defined in the HTTP protocol. It
			would be very useful for the TLS protocol to provide more general
			authentication mechanisms for subsequent authentication, for example
			EAP.
			The InnerApplication extension allows TLS to provide inner
			authentication during the handshake, rather than after it. The EAP-
			TTLS version 1 protocol is in fact just a binding of this extended
			TLS to EAP; that it, EAP-TTLS is a carrier protocol for the extended
			TLS. TLS with the InnerApplication extension can just as easily be
			bound to TCP, to enable its use in HTTP.
			The applicability of TLS with the InnerApplication extension
			includes setting up HTTP connections (including SSL VPN
			connections), establishing IPsec connections as an alternative to
			IKE, obtaining credentials for single sign-on, providing for client
			integrity verification, etc. The inner AVP mechanism offers both
			legacy and EAP authentication capabilities, natural compatibility
			with RADIUS and Diameter servers, and the flexibility to allow
			arbitrary client-server exchanges for various purposes.
			The authors' intention is to separately propose the TLS
			InnerApplication extension as an enhancement to TLS, and then define
			EAP-TTLS version 1 as a carrier protocol, or binding, of that
			extended TLS to EAP. For reasons of timing, the TLS InnerApplication
			extension is defined in this draft for now.
			11.3 The InnerApplication Extension to TLS
			The InnerApplication extension to TLS follows the guidelines of RFC
			3546. The client proposes use of this extension by including an
			InnerApplication message in its ClientHello handshake message, and
			the server confirms its use by including an InnerApplication message
			in its ServerHello handshake message.
			In this document, the term "TLS/IA" shall refer to TLS with the
			InnerApplication extension.
			Two new handshake messages are defined for use in TLS/IA:
			- The PhaseFinished message. This message is similar to the
			standard TLS Finished message; it allows the TLS/IA handshake to
			operate in phases, with message and key confirmation occurring at
			the end of each phase.
			- The ApplicationPayload message. This message is used to carry AVP
			(Attribute-Value Pair) sequences within the TLS/IA handshake, in
			support of client-server applications such as authentication.
			A new alert code is also defined for use in TLS/IA:
			- The InnerApplicationFailure alert. This error alert allows either
			party to terminate the handshake due to a failure in an
			application implemented via AVP sequences carried in
			ApplicationPayload messages.
			11.3.1 TLS/IA Overview
			In TLS/IA, the handshake is divided into phases.
			The first phase is called the "initial phase", and consists of a
			standard TLS handshake with PhaseFinished substituted for Finished
			as the concluding message.
			There are one or more subsequent phases, called "application
			phases". The last application phase is called the "final phase"; any
			application phase prior to the final phase is called an
			"intermediate phase".
			Each application phase consists of ApplicationPayload messages
			exchanged by client and server to implement applications such as
			authentication, plus concluding messages for cryptographic
			confirmation.
			Thus, the entire handshake consists of a initial phase, zero or more
			intermediate phases, and a final phase. Intermediate phases are only
			necessary if interim confirmation of key material generated during
			an application phase is desired.
			In each application phase, the client sends the first
			ApplicationPayload message. ApplicationPayload messages are then
			traded one at a time between client and server, until the server
			concludes the phase by sending a ChangeCipherSpec and PhaseFinished
			sequence to conclude an intermediate phase, or a ChangeCipherSpec
			and Finished sequence to conclude the final phase. The client then
			responds with its own ChangeCipherSpec and PhaseFinished sequence,
			or ChangeCipherSpec and Finished sequence.
			The server determines which type of concluding message is used,
			either PhaseFinished or Finished, and the client MUST echo the same
			type of concluding message. Each PhaseFinished or Finished message
			provides cryptographic confirmation of the integrity of all
			handshake messages and keys generated from the start of the
			handshake through the current phase.
			Each ApplicationPayload message contains opaque data interpreted as
			an AVP (Attribute-Value Pair) sequence. Each AVP in the sequence
			contains a typed data element. The exchanged AVPs allow client and
			server to implement "applications" within a secure tunnel. An
			application may be any procedure that someone may usefully define. A
			typical application might be authentication; for example, the server
			may authenticate the client based on password credentials using EAP.
			Other possible applications include distribution of keys, validating
			client integrity, setting up IPsec parameters, setting up SSL VPNs,
			and so on.
			In TLS/IA, the TLS master secret undergoes multiple permutations
			until a final master secret is computed at the end of the entire
			handshake. Each phase of the handshake results in a new master
			secret; the master secret for each phase is confirmed by the
			PhaseFinished or Finished message exchange that concludes that
			phase.
			The initial master secret is computed during the initial phase of
			the handshake, using the usual TLS algorithm, namely, that a
			premaster secret is established and the TLS PRF function is used to
			compute the initial master secret. This initial master secret is
			confirmed via the first exchange of ChangeCipherSpec and
			PhaseFinished messages.
			Each subsequent master secret for an application phase is computed
			using a PRF based on the current master secret, then mixing into the
			result any session key material generated during authentications
			during that phase. Each party computes a new master secret prior to
			the conclusion of each application phase, and uses that new master
			secret is to compute fresh keying material (that is, a TLS
			"key_block", consisting of client and server MAC secrets, write keys
			and IVs). The new master secret and keying material become part of
			the pending read and write connection states. Following standard TLS
			procedures, these connection states become current states upon
			sending or receiving ChangeCipherSpec, and are confirmed via the
			PhaseFinished or Finished message.
			The final master secret, computed during the final handshake phase
			and confirmed by an exchange of ChangeCipherSpec and Finished
			messages, becomes the actual TLS master secret that defines the
			session. This final master secret is the surviving master secret,
			and each prior master secrets SHOULD be discarded when a new
			connection state is instantiated. The final master secret is used
			for session resumption, as well as for any session key derivation
			that protocols defined over TLS may require.
			11.3.2 Message Exchange
			Each intermediate handshake phase consists of ApplicationPayload
			messages sent alternately by client and server, and a concluding
			exchange of {ChangeCipherSpec, PhaseFinished} messages. The first
			ApplicationPayload message in the each intermediate phase is sent by
			the client; the first {ChangeCipherSpec, PhaseFinished} message
			sequence is sent by the server. Thus the client begins the exchange
			with an ApplicationPayload message and the server determines when to
			conclude it by sending {ChangeCipherSpec, PhaseFinished}. When it
			receives the server's {ChangeCipherSpec, PhaseFinished} messages,
			the client sends its own {ChangeCipherSpec, PhaseFinished} messages.
			The client then sends an ApplicationPayload message to begin the
			next handshake phase.
			The final handshake proceeds in the same manner as the intermediate
			handshake, except that the Finished message is used rather than the
			PhaseFinished message, and the client does not send an
			ApplicationPayload message for the next phase because there is no
			next phase.
			At the start of each application handshake phase, the server MUST
			wait for the client's opening ApplicationPayload message before it
			sends its own ApplicationPayload message to the client. The client
			MAY NOT initiate conclusion of an application handshake phase by
			sending the first {ChangeCipherSpec, PhaseFinished} or
			{ChangeCipherSpec, Finished message} sequence; it MUST allow the
			server to initiate the conclusion of the phase.
			11.3.3 Master Key Permutation
			Each permutation of the master secret from one phase to the next
			begins with the calculation of a preliminary 48 octet vector based
			on the current master secret:
			preliminary_vector = PRF(master_secret,
			"InnerApplication preliminary vector",
			server_random + client_random) [0..48];
			Session key material generated by applications during the current
			application phase are mixed into the preliminary vector by
			arithmetically adding each session key to the preliminary vector to
			compute the new master secret. The preliminary vector is treated as
			a 48-octet integer in big-endian order; that is, the first octet is
			of the highest significance. Each session key is also treated as a
			big-endian integer of whatever size it happens to be. Arithmetic
			carry past the most significant octet is discarded; that is, the
			addition is performed modulo 2 ^ 384.
			Thus, the logical procedure for computing the next master secret
			(which may also be a convenient implementation procedure) is as
			follows:
			1 At the start of each application handshake phase, use the current
			master secret to compute the preliminary vector for the next
			master secret.
			2 Each time session key material is generated from an
			authentication or other exchange, arithmetically add that session
			key material to the preliminary vector.
			3 At the conclusion of the application handshake phase, copy the
			current contents of the preliminary vector (which now includes
			addition of all session key material) into the new master secret,
			prior to computing verify_data.
			The purpose of using a PRF to compute a preliminary vector is to
			ensure that, even in the absence of session keys, the master secret
			is cryptographically distinct in each phase of the handshake.
			The purpose of adding session keys into the preliminary vector is to
			ensure that the same client entity that negotiated the original
			master secret also negotiated the inner authentication(s). In the
			absence of such mixing of keys generated from the standard TLS
			handshake with keys generated from inner authentication, it is
			possible for a hostile agent to mount a man-in-the-middle attack,
			acting as server to an unsuspecting client to induce it to perform
			an authentication with it, which it can then pass through the TLS
			tunnel to allow it to pose as that client.
			An application phase may include no authentications that produce a
			session key, may include one such authentication, or may include
			several. Arithmetic addition was chosen as the mixing method because
			it is commutative, that is, it does not depend on the order of
			operations. This allows multiple authentications to proceed
			concurrently if desired, without having to synchronize the order of
			master secret updates between client and server.
			Addition was chosen rather than XOR in order to avoid what is
			probably a highly unlikely problem; namely, that two separate
			authentications produce the same session key, which, if XORed, would
			mutually cancel. This might occur, for example, if two instances of
			an authentication method were to be applied against different forms
			of a user identity that turn out in a some cases to devolve to the
			same identity.
			Finally, it was decided that a more complex mixing mechanism for
			session key material, such as hashing, besides not being
			commutative, would not provide any additional security, due to the
			effectively random character of the preliminary vector and the
			powerful PRF function which is applied to create derivative keys.
			11.3.4 Session Resumption
			A TLS/IA handshake may be resumed using standard mechanisms defined
			in RFC 2246. In TLS/IA, session resumption is simply an alternative
			form of the initial handshake phase, after which subsequent
			application phases proceed.
			When the initial handshake phase is resumed, client and server may
			not deem it necessary to perform the same type of AVP exchange that
			they might after a full handshake. In fact, the resumption itself
			might provide all the security needed and no AVPs need be exchanged
			at all.
			If the client determines that it has no need for AVP negotiation, it
			sends an ApplicationPayload message with no data as its first
			application phase message. If the server concurs, it may conclude
			the handshake with ChangeCipherSpec and Finished immediately upon
			receiving the empty ApplicationPayload message.
			Alternatively, either party may initiate AVP exchange if inner
			applications must execute upon session resumption. For example,
			authentication exchanges might be omitted but key distribution for
			some purpose might still occur.
			[Author's note: A future draft may provide a mechanism to avoid the
			extra round trip incurred when neither party has a requirement to
			send AVPs after session resumption.]
			11.3.5 Error Termination
			The TLS/IA handshake may be terminated by either party sending a
			fatal alert, following standard TLS procedures.
			11.3.6 Application Session Key Material
			Many authentication mechanisms generate session keying material as a
			by-product of authentication. Such keying material is normally
			intended for use in a subsequent data connection for encryption and
			validation. For example, EAP-TLS, MS-CHAP-V2 and its alter ego EAP-
			MS-CHAP-V2 each generate keying material.
			When encapsulated within TLS/IA, such keying material MUST NOT be
			used to set up data connections; the TLS/IA master secret is a
			better basis for this use.
			However, such keying material generated during an application phase
			MUST be used to permute the TLS/IA master secret between on phase
			and the next. The purpose of this is to preclude man-in-the-middle
			attacks, in which an unsuspecting client is induced to perform an
			authentication outside a tunnel with an attacker posing as a server;
			the attacker can then introduce the authentication protocol into a
			tunnel such as provided by TLS/IA, fooling an authentic server into
			believing that the attacker is the authentic user.
			By mixing keying material generating during application phase
			authentication into the master secret, such attacks are thwarted,
			since only a single client identity could both authenticate
			successfully and have derived the session keying material.
			Note that the keying material generated during authentication must
			be cryptographically related to the authentication and not derivable
			from data exchanged during authentication in order for the keying
			material to be useful in thwarting such attacks.
			The RECOMMENDED amount of keying material to mix into the master
			secret is 32 octets. Up to 48 octets MAY be used.
			Each authentication protocol may define how the keying material it
			generates is mapped to an octet sequence of some length for the
			purpose of TLS/IA mixing. However, for protocols which do not
			specify this (including the multitude of protocols that pre-date
			TLS/IA) the following rules are defined. The first rule that applies
			SHALL be the method for determining keying material:
			- If the authentication protocol maps its keying material to the
			RADIUS attributes MS-MPPE-Receive-Key and MS-MPPE-Send-Key, then
			the keying material for those attributes are concatenated (with
			MS-MPPE-Receive-Key first), the concatenated sequence is
			truncated to 32 octets if longer, and the result is used as
			keying material. (Note that this rule applies to MS-CHAP-V2 and
			EAP-MS-CHAP-V2.)
			- If the authentication protocol uses a pseudo-random function to
			generate keying material, that function is used to generate 32
			octets for use as keying material.
			11.3.7 Computing Verification Data
			In standard TLS, the "verify_data" vector of the Finished message is
			computed as follows:
			PRF(master_secret, finished_label, MD5(handshake_messages) +
			SHA-1(handshake_messages)) [0..11];
			This allows both parties to confirm the master secret as well as the
			integrity of all handshake messages that have been exchanged.
			In TLS/IA, verify_data for the initial handshake phase is computed
			in exactly the same manner, though verify_data is encapsulated in a
			PhaseFinished, rather than Finished, message.
			In the subsequent application phases, a slight variation to this
			formula is used. For each hash, the handshake messages of the
			current phase are appended to the hash of the handshake messages of
			the previous phase. Thus, for each application phase, the MD5 hash
			input to the PRF is a hash of the MD5 hash computed for the previous
			phase concatenated with the handshake messages of the current phase;
			the SHA-1 hash is computed in the same way, but using the SHA-1 hash
			computed for the previous phase.
			Also, the master secret used in the PRF computation in each
			application phase is the new master secret generated at the
			conclusion of that phase.
			For clarity, this is best expressed in formal notation.
			Let phases be numbered from 0, where phase 0 is the initial phase.
			Let:
			Secret[n] be the master secret determined at the conclusion of
			phase n.
			Messages[n] be the handshake messages in phase n.
			MD5[n] be the MD5 hash of handshake message material in phase n.
			SHA-1[n] be the SHA-1 hash of handshake message material in phase
			n.
			PRF[n] be the verify_data generated via PRF in phase n.
			Hash computations for phase 0 are as follows:
			MD5[0] = MD5(Messages[0])
			SHA-1[0] = SHA-1(Messages[0])
			PRF[0] = PRF(master_secret, finished_label, MD5[0] + SHA-1[0])
			[0..11]
			Hash computations for phase i, where i > 0 (i.e. application phases)
			are as follows:
			MD5[i] = MD5(MD5[i-1] + Messages[i])
			SHA-1[i] = SHA-1(SHA-1[i-1] + Messages[i])
			The PRF computation to generate verify_data for any phase i
			(including i = 0) is as follows:
			PRF[i] = PRF(Secret[i], finished_label, MD5[i] + SHA-1[i])
			[0..11]
			Note that for phase 0, the PRF computation is identical to the
			standard TLS computation. Variations to the algorithm occur only in
			application phases, in the use of new master secrets and the
			inclusion of hashes of previous handshake messages as input to the
			hashing algorithms.
			Note that the only handshake messages that appear in an application
			phase are InnerApplication messages and Finished or Phase Finished
			messages. During an application phase, the handshake messages input
			to the hashing algorithm by the server will include all
			InnerApplication messages exchanged during that phase; the handshake
			messages input to the hashing algorithm by the client will include
			all InnerApplication messages exchanged during that phase plus the
			server's PhaseFinished or Finished message.
			11.3.8 Attribute-Value Pairs (AVPs)
			AVPs used in InnerApplication messages are exactly as defined in
			Section 9 of this document; that is, they are Diameter-style AVPs
			and use the RADIUS-Diameter namespace.
			Rules for performing authentications using these AVPs are exactly as
			defined in Section 10 of this document. This includes rules for
			creating implicit challenges, and rules for use of inner EAP
			authentications as well as legacy protocols such as PAP, CHAP and
			MS-CHAP-V1/V2. Note that all implicit challenges are based on the
			then-current master secret.
			11.3.9 TLS/IA Messages
			All specifications of TLS/IA messages follow the usage defined in
			RFC 2246.
			TLS/IA defines a new TLS extension - "InnerApplication"; two new
			handshake messages - "PhaseFinished" and "ApplicationPayload"; and a
			new alert code - "InnerApplicationFailure".
			The InnerApplication extension type is 9347 (hex).
			In order to avoid potential type-assignment problems, the new
			handshake message types and alert code are dynamically defined
			within the InnerApplication extension message. Client and server
			independently specify the values they will send. Thus, the client
			assigns its own message type and alert code values for use in its
			own transmissions, and includes these values in its InnerApplication
			message within ClientHello. Similarly, the server assigns its own
			message type and alert code values for use in its own transmissions,
			and includes these values in its InnerApplication message within
			ServerHello. Each party must note the message type and alert code
			values assigned by the other party and interpret messages from the
			other party accordingly. Both client and server assign message types
			and alert code so as not to conflict with values that that it might
			otherwise send. There is no requirement that client and server
			assign identical values for these items.
			11.3.10 The InnerApplication Extension
			Use of the InnerApplication extension follows RFC 3546. The client
			proposes use of this extension by including the InnerApplication
			extension in the client_hello_extension_list vector of the extended
			ClientHello. If the extension is included in the ClientHello, the
			server MAY accept the proposal by including the InnerApplication
			extension in the server_hello_extension_list of the extended
			ServerHello. If use of this extension is either not proposed by the
			client or not confirmed by the server, the variations to the TLS
			handshake described here MUST NOT be used.
			The "extension_data" field of the Extension structure for the
			InnerApplication extension SHALL contain "InnerApplication" where:
			struct {
			uint8 PhaseFinishedType;
			uint8 ApplicationPayloadType;
			uint8 InnerApplicationFailureAlertCode;
			} InnerApplication;
			11.3.11 The PhaseFinished Handshake Message
			The PhaseFinished message concludes the initial handshake phase and
			each intermediate handshake phase. It MUST be immediately preceded
			by a ChangeCipherSpec message. It is defined as follows:
			struct {
			opaque verify_data[12];
			} PhaseFinished;
			11.3.12 The ApplicationPayload Handshake Message
			The ApplicationPayload message carries an AVP sequence during an
			application handshake phase. It is defined as follows:
			struct {
			opaque avps[Handshake.length];
			} ApplicationPayload;
			where Handshake.length is the 24-bit length field in the
			encapsulating Handshake message.
			Note that the "avps" element has its length defined in square
			bracket rather than angle bracket notation, implying a fixed rather
			than variable length vector. This avoids the having the length of
			the AVP sequence specified redundantly both in the encapsulating
			Handshake message and as a length prefix in the avps element itself.
			11.3.13 The InnerApplicationFailure Alert
			An InnerApplicationFailure error alert may be sent by either party
			during an application phase. This indicates that the sending party
			considers the negotiation to have failed due to an application
			carried in the AVP sequences, for example, a failed authentication.
			The AlertLevel for an InnerApplicationFailure alert MUST be set to
			"fatal".
			Note that other alerts are possible during an application phase; for
			example, decrypt_error. The InnerApplicationFailure alert relates
			specifically to the failure of an application implemented via AVP
			sequences; for example, failure of an EAP or other authentication
			method, or information passed within the AVP sequence that is found
			unsatisfactory.
			11.4 Binding of TLS/IA to EAP-TTLS v1
			EAP-TTLS v1 encapsulates a TLS handshake with the InnerApplication
			extension (TLS/IA). EAP-TTLS v1 acts as a carrier protocol for
			TLS/IA, and uses cryptographic information developed during the
			TLS/IA exchange to create session keys for encrypting subsequent
			data transmission between client and access point.
			The format for encapsulated TLS/IA messages in EAP-TTLS v1 is
			identical to the formats described for EAP-TTLS v0 in Section 8,
			unless otherwise specified
			11.4.1 Flags Octet
			Use of version 1 of EAP-TTLS is negotiated through a new 3-bit
			"Version" field in the Flags octet of the EAP-TTLS request/response
			header. The Flags octet is the first octet of each EAP-TTLS message,
			following immediately after the EAP type. The Version field uses
			bits of the Flags octet that were formerly reserved and required to
			be 0.
			The new bit field definitions for the Flags octet are as follows:
			0 1 2 3 4 5 6 7
			+---+---+---+---+---+---+---+---+
			| L M S R R | Version |
			+---+---+---+---+---+---+---+---+
			where:
			L = Length included
			M = More fragments
			S = Start
			R = Reserved
			Version = EAP-TTLS version number
			For EAP-TTLS v1, Version is set to 1; that is, the bit sequence 001.
			Interpretation of L, M and S are as in EAP-TTLS v0.
			11.4.2 Version Negotiation
			The version of EAP-TTLS is negotiated in the first exchange between
			server and client. The server sets the highest version number of
			EAP-TTLS that it supports in the Version field of its Start message
			(in the case of EAP-TTLS v1, this is 1). In its first EAP message in
			response, the client sets the Version field to the highest version
			number that it supports that is no higher than the version number
			offered by the server. If the client version is not acceptable to
			the server, it sends an EAP-Failure to terminate the EAP session.
			Otherwise, the version sent by the client is the version of EAP-TTLS
			that MUST be used, and both server and client set the version field
			to that version number in all subsequent EAP messages.
			11.4.3 Acknowledgement Packets
			An Acknowledgement packet is an EAP-TTLS v1 packet with no
			additional data beyond the Flags octet, and with the L, M and S bits
			of the Flags octet set to 0. (Note, however, that the Version field
			MUST still be set to the appropriate version number.)
			An Acknowledgement packet is sent for the following purposes:
			- Fragment acknowledgement
			- Error alert acknowledgement
			Note that in EAP-TTLS v0 there are other cases in which a packet
			with no data must be sent by the client for the simple reason that
			the client has no AVPs to send. This situation does not arise in
			EAP-TTLS v1. If no AVPs are to be sent, there will nevertheless be
			an ApplicationPayload message containing no data, which the client
			must send.
			- Fragment Acknowledgement
			Each EAP-TTLS v1 message contains a sequence of TLS/IA messages
			that represent a single leg of a half-duplex conversation. The
			EAP carrier protocol (e.g., PPP, EAPOL, RADIUS) may impose
			constraints on the length of of an EAP message. Therefore it may
			be necessary to fragment an EAP-TTLS v1 message across multiple
			EAP messages.
			Each fragment except for the last MUST have the M bit set, to
			indicate that more data is to follow; the final fragment MUST NOT
			have the M bit set. The party that receives a message with the M
			bit set MUST respond with an Acknowledgement packet.
			- Error Alert Acknowledgement
			Either party may at any time send a TLS error alert to fail the
			TLS/IA handshake.
			If the client sends an error alert to the server, no further EAP-
			TTLS messages are exchanged, and the server sends an EAP-Failure
			to terminate the conversation.
			If the server sends an error alert to the client, the client MUST
			respond with an Acknowledgement packet to allow the conversation
			to continue. Upon receipt of the Acknowledgement packet, the
			server sends an EAP-Failure to terminate the conversation.
			11.4.4 Generating Keying Material
			EAP-TTLS v1 uses the same mechanism as EAP-TTLS v0 to generate
			keying material (session keys) for use in the data connection
			between client and access point.
			Note that it is the final master secret of the TLS/IA exchange that
			is used to generate keying material for use in the subsequent data
			connection.
			12. Discussion of Certificates and PKI
	Public-key cryptography, certificates, and the associated PKI are		Public-key cryptography, certificates, and the associated PKI are
	used in EAP-TTLS to authenticate the EAP-TTLS server to the client,		used in EAP-TTLS to authenticate the EAP-TTLS server to the client,
	and optionally the client to the EAP-TTLS server. Previous		and optionally the client to the EAP-TTLS server. Previous
	experience with the deployment of PKI in applications has shown that		experience with the deployment of PKI in applications has shown that
	its implementation requires care. This section provides a brief		its implementation requires care. This section provides a brief
	discussion of the issues implementers will face when deploying PKI		discussion of the issues implementers will face when deploying PKI
	for EAP-TTLS.		for EAP-TTLS.
	The traditional use of TLS for securing e-commerce transactions over		The traditional use of TLS for securing e-commerce transactions over
	skipping to change at page 27, line 34 ¶		skipping to change at page 42, line 6 ¶
	One open question in the area of PKI on which the authors would like		One open question in the area of PKI on which the authors would like
	to promote discussion is the following:		to promote discussion is the following:
	- Should EAP-TTLS enforce rules on name matching regarding the EAP-		- Should EAP-TTLS enforce rules on name matching regarding the EAP-
	TTLS server? For example, EAP-TTLS could mandate that		TTLS server? For example, EAP-TTLS could mandate that
	radius.xyz.realm or diameter.xyz.realm be used as the name in the		radius.xyz.realm or diameter.xyz.realm be used as the name in the
	EAP-TTLS server's certificate, and that the client must match		EAP-TTLS server's certificate, and that the client must match
	this name with the realm it sent in the initial EAP-		this name with the realm it sent in the initial EAP-
	Response/Identity.		Response/Identity.
	12. Message Sequences		13. Message Sequences
			[Author's note: The message sequences in these sections apply to
			version 0 of the EAP-TTLS protocol. Messages sequences for version 1
			have not yet been completed.]
	This section presents EAP-TTLS message sequences for various		This section presents EAP-TTLS message sequences for various
	negotiation scenarios. These examples do not attempt to exhaustively		negotiation scenarios. These examples do not attempt to exhaustively
	depict all possible scenarios.		depict all possible scenarios.
	It is assumed that RADIUS is the AAA carrier protocol both between		It is assumed that RADIUS is the AAA carrier protocol both between
	access point and TTLS server, and between TTLS server and AAA/H.		access point and TTLS server, and between TTLS server and AAA/H.
	EAP packets that are passed unmodified between client and TTLS		EAP packets that are passed unmodified between client and TTLS
	server by the access point are indicated as "passthrough". AVPs that		server by the access point are indicated as "passthrough". AVPs that
	are securely tunneled within the TLS record layer are enclosed in		are securely tunneled within the TLS record layer are enclosed in
	curly braces ({}). Items that are optional are suffixed with		curly braces ({}). Items that are optional are suffixed with
	question mark (?). Items that may appear multiple times are suffixed		question mark (?). Items that may appear multiple times are suffixed
	with plus sign (+).		with plus sign (+).
	12.1 Successful authentication via tunneled CHAP		13.1 Successful authentication via tunneled CHAP
	In this example, the client performs one-way TLS authentication of		In this example, the client performs one-way TLS authentication of
	the TTLS server, CHAP is used as a tunneled user authentication		the TTLS server nad CHAP is used as a tunneled user authentication
	mechanism, and the TTLS server returns cipher suite and keying		mechanism.
	material.
	client access point TTLS server AAA/H		client access point TTLS server AAA/H
	------ ------------ ----------- -----		------ ------------ ----------- -----
	EAP-Request/Identity		EAP-Request/Identity
	<--------------------		<--------------------
	EAP-Response/Identity		EAP-Response/Identity
	-------------------->		-------------------->
	RADIUS Access-Request:		RADIUS Access-Request:
	XXX-Data-Cipher-Suite+
	EAP-Response passthrough		EAP-Response passthrough
	-------------------->		-------------------->
	RADIUS Access-Challenge:		RADIUS Access-Challenge:
	EAP-Request/TTLS-Start		EAP-Request/TTLS-Start
	<--------------------		<--------------------
	EAP-Request passthrough		EAP-Request passthrough
	<--------------------		<--------------------
	skipping to change at page 29, line 4 ¶		skipping to change at page 43, line 28 ¶
	EAP-Response/TTLS:		EAP-Response/TTLS:
	ClientKeyExchange		ClientKeyExchange
	ChangeCipherSpec		ChangeCipherSpec
	Finished		Finished
	-------------------->		-------------------->
	RADIUS Access-Request:		RADIUS Access-Request:
	EAP-Response passthrough		EAP-Response passthrough
	-------------------->		-------------------->
	RADIUS Access-Challenge:		RADIUS Access-Challenge:
	EAP-Request/TTLS:		EAP-Request/TTLS:
	ChangeCipherSpec		ChangeCipherSpec
	Finished		Finished
	<--------------------		<--------------------
	EAP-Request passthrough		EAP-Request passthrough
	<--------------------		<--------------------
	EAP-Response/TTLS:		EAP-Response/TTLS:
	{User-Name}		{User-Name}
	{CHAP-Challenge}		{CHAP-Challenge}
	{CHAP-Password}		{CHAP-Password}
	{XXX-Data-Cipher-Suite+}
	-------------------->		-------------------->
	RADIUS Access-Request:		RADIUS Access-Request:
	EAP-Response passthrough		EAP-Response passthrough
	-------------------->		-------------------->
	RADIUS Access-Request:		RADIUS Access-Request:
	User-Name		User-Name
	CHAP-Challenge		CHAP-Challenge
	CHAP-Password		CHAP-Password
	skipping to change at page 29, line 29 ¶		skipping to change at page 44, line 4 ¶
	RADIUS Access-Request:		RADIUS Access-Request:
	EAP-Response passthrough		EAP-Response passthrough
	-------------------->		-------------------->
	RADIUS Access-Request:		RADIUS Access-Request:
	User-Name		User-Name
	CHAP-Challenge		CHAP-Challenge
	CHAP-Password		CHAP-Password
	-------------------->		-------------------->
	RADIUS Access-Accept		RADIUS Access-Accept
	<--------------------		<--------------------
	RADIUS Access-Challenge:
	EAP-Request/TTLS:
	{XXX-Data-Cipher-Suite}
	<--------------------
	EAP-Request passthrough
	<--------------------
	EAP-Response/TTLS: no data
	-------------------->
	RADIUS Access-Request:
	EAP-Response passthrough
	-------------------->
	RADIUS Access-Accept:		RADIUS Access-Accept:
	XXX-Data-Cipher-Suite
	XXX-Data-Keying-Material
	EAP-Success		EAP-Success
	<--------------------		<--------------------
	EAP-Success passthrough		EAP-Success passthrough
	<--------------------		<--------------------
	12.2 Successful authentication via tunneled EAP/MD5-Challenge		13.2 Successful authentication via tunneled EAP/MD5-Challenge
	In this example, the client performs one-way TLS authentication of		In this example, the client performs one-way TLS authentication of
	the TTLS server, EAP/MD5-Challenge is used as a tunneled user		the TTLS server and EAP/MD5-Challenge is used as a tunneled user
	authentication mechanism, and the TTLS server returns cipher suite		authentication mechanism.
	and keying material.
	client access point TTLS server AAA/H		client access point TTLS server AAA/H
	------ ------------ ----------- -----		------ ------------ ----------- -----
	EAP-Request/Identity		EAP-Request/Identity
	<--------------------		<--------------------
	EAP-Response/Identity		EAP-Response/Identity
	-------------------->		-------------------->
	RADIUS Access-Request:		RADIUS Access-Request:
	XXX-Data-Cipher-Suite+
	EAP-Response passthrough		EAP-Response passthrough
	-------------------->		-------------------->
	RADIUS Access-Challenge:		RADIUS Access-Challenge:
	EAP-Request/TTLS-Start		EAP-Request/TTLS-Start
	<--------------------		<--------------------
	EAP-Request passthrough		EAP-Request passthrough
	<--------------------		<--------------------
	skipping to change at page 31, line 25 ¶		skipping to change at page 45, line 29 ¶
	EAP-Request/TTLS:		EAP-Request/TTLS:
	ChangeCipherSpec		ChangeCipherSpec
	Finished		Finished
	<--------------------		<--------------------
	EAP-Request passthrough		EAP-Request passthrough
	<--------------------		<--------------------
	EAP-Response/TTLS:		EAP-Response/TTLS:
	{EAP-Response/Identity}		{EAP-Response/Identity}
	{XXX-Data-Cipher-Suite+}
	-------------------->		-------------------->
	RADIUS Access-Request:		RADIUS Access-Request:
	EAP-Response passthrough		EAP-Response passthrough
	-------------------->		-------------------->
	RADIUS Access-Request:		RADIUS Access-Request:
	EAP-Response/Identity		EAP-Response/Identity
	-------------------->		-------------------->
	RADIUS Access-Challenge		RADIUS Access-Challenge
	EAP-Request/		EAP-Request/
	MD5-Challenge		MD5-Challenge
	-------------------->		-------------------->
	RADIUS Access-Challenge:		RADIUS Access-Challenge:
	EAP-Request/TTLS:		EAP-Request/TTLS:
	{EAP-Request/MD5-Challenge}		{EAP-Request/MD5-Challenge}
	{XXX-Data-Cipher-Suite}
	<--------------------		<--------------------
	EAP-Request passthrough		EAP-Request passthrough
	<--------------------		<--------------------
	EAP-Response/TTLS:		EAP-Response/TTLS:
	{EAP-Response/MD5-Challenge}		{EAP-Response/MD5-Challenge}
	-------------------->		-------------------->
	RADIUS Access-Request:		RADIUS Access-Request:
	EAP-Response passthrough		EAP-Response passthrough
	skipping to change at page 32, line 17 ¶		skipping to change at page 46, line 17 ¶
	RADIUS Access-Challenge		RADIUS Access-Challenge
	EAP-Response/		EAP-Response/
	MD5-Challenge		MD5-Challenge
	-------------------->		-------------------->
	RADIUS Access-Accept		RADIUS Access-Accept
	<--------------------		<--------------------
	RADIUS Access-Accept:		RADIUS Access-Accept:
	XXX-Data-Cipher-Suite
	XXX-Data-Keying-Material
	EAP-Success		EAP-Success
	<--------------------		<--------------------
	EAP-Success passthrough		EAP-Success passthrough
	<--------------------		<--------------------
	12.3 Successful session resumption		13.3 Successful session resumption
	In this example, the client and server resume a previous TLS		In this example, the client and server resume a previous TLS
	session, and the TTLS server returns cipher suite and keying		session. The ID of the session to be resumed is sent as part of the
	material. The ID of the session to be resumed is sent as part of the
	ClientHello, and the server agrees to resume this session by sending		ClientHello, and the server agrees to resume this session by sending
	the same session ID as part of ServerHello.		the same session ID as part of ServerHello.
	Note the piggybacking of tunneled XXX-Data-Cipher-Suite AVPs in the
	same EAP packet as handshake messages.
	client access point TTLS server AAA/H		client access point TTLS server AAA/H
	------ ------------ ----------- -----		------ ------------ ----------- -----
	EAP-Request/Identity		EAP-Request/Identity
	<--------------------		<--------------------
	EAP-Response/Identity		EAP-Response/Identity
	-------------------->		-------------------->
	RADIUS Access-Request:		RADIUS Access-Request:
	XXX-Data-Cipher-Suite+
	EAP-Response passthrough		EAP-Response passthrough
	-------------------->		-------------------->
	RADIUS Access-Challenge:		RADIUS Access-Challenge:
	EAP-Request/TTLS-Start		EAP-Request/TTLS-Start
	<--------------------		<--------------------
	EAP-Request passthrough		EAP-Request passthrough
	<--------------------		<--------------------
	skipping to change at page 33, line 11 ¶		skipping to change at page 47, line 4 ¶
	RADIUS Access-Challenge:		RADIUS Access-Challenge:
	EAP-Request/TTLS-Start		EAP-Request/TTLS-Start
	<--------------------		<--------------------
	EAP-Request passthrough		EAP-Request passthrough
	<--------------------		<--------------------
	EAP-Response/TTLS:		EAP-Response/TTLS:
	ClientHello		ClientHello
	-------------------->		-------------------->
	RADIUS Access-Request:		RADIUS Access-Request:
	EAP-Response passthrough		EAP-Response passthrough
	-------------------->		-------------------->
	RADIUS Access-Challenge:		RADIUS Access-Challenge:
	EAP-Request/TTLS:		EAP-Request/TTLS:
	ServerHello		ServerHello
	ChangeCipherSpec		ChangeCipherSpec
	Finished		Finished
	<--------------------		<--------------------
	EAP-Request passthrough		EAP-Request passthrough
	<--------------------		<--------------------
	EAP-Response/TTLS:		EAP-Response/TTLS:
	ChangeCipherSpec		ChangeCipherSpec
	Finished		Finished
	{XXX-Data-Cipher-Suite+}
	-------------------->
	RADIUS Access-Request:
	EAP-Response passthrough
	-------------------->
	RADIUS Access-Challenge:
	EAP-Request/TTLS:
	{XXX-Data-Cipher-Suite}
	<--------------------
	EAP-Request passthrough
	<--------------------
	EAP-Response/TTLS: no data
	-------------------->		-------------------->
	RADIUS Access-Request:		RADIUS Access-Request:
	EAP-Response passthrough		EAP-Response passthrough
	-------------------->		-------------------->
	RADIUS Access-Accept:		RADIUS Access-Accept:
	XXX-Data-Cipher-Suite
	XXX-Data-Keying-Material
	EAP-Success		EAP-Success
	<--------------------		<--------------------
	EAP-Success passthrough		EAP-Success passthrough
	<--------------------		<--------------------
	13. Security Considerations		14. Security Considerations
	This draft is entirely about security and the security		This draft is entirely about security and the security
	considerations associated with the mechanisms employed in this		considerations associated with the mechanisms employed in this
	document should be considered by implementers.		document should be considered by implementers.
	The following additional issues are relevant:		The following additional issues are relevant:
	- Anonymity and privacy. Unlike other EAP methods, EAP-TTLS does		- Anonymity and privacy. Unlike other EAP methods, EAP-TTLS does
	not communicate a username in the clear in the initial EAP-		not communicate a username in the clear in the initial EAP-
	Response/Identity. This feature is designed to support anonymity		Response/Identity. This feature is designed to support anonymity
	skipping to change at page 35, line 40 ¶		skipping to change at page 49, line 16 ¶
	does not compromise session keys previously negotiated based on		does not compromise session keys previously negotiated based on
	that secret. Thus, when the TLS key exchange algorithm provides		that secret. Thus, when the TLS key exchange algorithm provides
	forward secrecy, if a TTLS server certificate's private key is		forward secrecy, if a TTLS server certificate's private key is
	eventually stolen or cracked, tunneled user password information		eventually stolen or cracked, tunneled user password information
	will remain secure as long as that certificate is no longer in		will remain secure as long as that certificate is no longer in
	use. Diffie-Hellman key exchange is an example of an algorithm		use. Diffie-Hellman key exchange is an example of an algorithm
	that provides forward secrecy. A forward secrecy algorithm should		that provides forward secrecy. A forward secrecy algorithm should
	be considered if attacks against recorded authentication or data		be considered if attacks against recorded authentication or data
	sessions are considered to pose a significant threat.		sessions are considered to pose a significant threat.
	14. Changes since previous drafts		15. Changes since previous drafts
	Other than minor editorial changes, the following changes have been		Other than minor editorial changes, the following changes have been
	made to this draft:		made to this draft:
			Since version 04:
			- An enhanced version of EAP-TTLS, called version 1, has been
			defined in section 11.
	Since version 03:		Since version 03:
	- Removed section on keying information.		- Removed section on keying information.
	Since version 02:		Since version 02:
	- Added password change for MS-CHAP-V2.		- Added password change for MS-CHAP-V2.
	Since version 01:		Since version 01:
	skipping to change at page 36, line 32 ¶		skipping to change at page 50, line 11 ¶
	- In sections 7 and 10.1, reversed the order of randoms used in		- In sections 7 and 10.1, reversed the order of randoms used in
	PRF, to follow EAP-TLS practice and avoid namespace collisions		PRF, to follow EAP-TLS practice and avoid namespace collisions
	with TLS.		with TLS.
	- In section 8, specified the assigned EAP-TTLS number.		- In section 8, specified the assigned EAP-TTLS number.
	- Added section 8.1, reserving for future standardization the		- Added section 8.1, reserving for future standardization the
	ability to add data to an EAP-TTLS Start packet.		ability to add data to an EAP-TTLS Start packet.
	15. References		16. References
	[1] Aboba, B., and D. Simon, "PPP EAP TLS Authentication		[1] Aboba, B., and D. Simon, "PPP EAP TLS Authentication
	Protocol", RFC 2716, October 1999.		Protocol", RFC 2716, October 1999.
	[2] Blunk, L., and J. Vollbrecht, "PPP Extensible Authentication		[2] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
	Protocol (EAP)", RFC 2284, March 1998.		Levkowetz, "PPP Extensible Authentication Protocol (EAP)", RFC
			3784, June 2004.
	[3] Dierks, T., and C. Allen, "The TLS Protocol Version 1.0", RFC		[3] Dierks, T., and C. Allen, "The TLS Protocol Version 1.0", RFC
	2246, November 1998.		2246, November 1998.
	[4] Institute for Electrical and Electronics Engineers, "IEEE		[4] Institute for Electrical and Electronics Engineers, "IEEE
	802.1X, Standard for Port Based Network Access Control", 2001.		802.1X, Standard for Port Based Network Access Control", 2001.
	[5] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD		[5] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
	51, RFC 1661, July 1994.		51, RFC 1661, July 1994.
	[6] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "Remote		[6] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "Remote
	Authentication Dial In User Service (RADIUS)", RFC 2865, June		Authentication Dial In User Service (RADIUS)", RFC 2865, June
	2000.		2000.
	[7] Aboba, B., and M. Beadles, "The Network Access Identifier",		[7] Aboba, B., and M. Beadles, "The Network Access Identifier",
	RFC 2486, January 1999.		RFC 2486, January 1999.
	[8] Calhoun, P., et al.. "Diameter Base Protocol", AAA Working		[8] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
	Group Internet-Draft, draft-ietf-aaa-diameter-07.txt, July		Arkko, "Diameter Base Protocol", RFC 3588, July 2001.
	2001
	[9] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1700,		[9] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1700,
	October 1994.		October 1994.
	[10] Zorn, G., and S. Cobb, "Microsoft PPP CHAP Extensions", RFC		[10] Zorn, G., and S. Cobb, "Microsoft PPP CHAP Extensions", RFC
	2433, October 1998.		2433, October 1998.
	[11] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC		[11] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC
	2759, January 2000.		2759, January 2000.
	[12] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC		[12] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC
	2548, March 1999.		2548, March 1999.
	[13] Blake-Wilson, S., Hopwood, D., Mikkelson, J., Nystrom, M., and		[13] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and
	T. Wright, "TLS Extensions", TLS Working Group Internet-Draft,		T. Wright, "Transport Layer Security (TLS) Extensions", RFC
	draft-ietf-tls-extensions-00.txt, June 2001.		3546, June 2003.
	[14] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.		[14] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
	Adams, "Internet X.509 Public Key Infrastructure: Online		Adams, "Internet X.509 Public Key Infrastructure: Online
	Certificate Status Protocol - OCSP", RFC 2560, June 1999.		Certificate Status Protocol - OCSP", RFC 2560, June 1999.
	16. Authors' Addresses		[15] Asokan, N., Niemi, V., and Nyberg, K., "Man-in-the-Middle in
			Tunneled Authentication",
			http://www.saunalahti.fi/~asokan/research/mitm.html, Nokia
			Research Center, Finland, October 24 2002.
			[16] Puthenkulam, J., "The Compound Authentication Binding
			Problem", draft-puthenkulam-eap-binding-04.txt, October 2003.
			17. Authors' Addresses
	Questions about this memo can be directed to:		Questions about this memo can be directed to:
	Paul Funk		Paul Funk
	Funk Software, Inc.		Funk Software, Inc.
	222 Third Street		222 Third Street
	Cambridge, MA 02142		Cambridge, MA 02142
	USA		USA
	Phone: +1 617 497-6339		Phone: +1 617 497-6339
	E-mail: paul@funk.com		E-mail: paul@funk.com
	Simon Blake-Wilson		Simon Blake-Wilson
	Basic Commerce & Industries, Inc.		Basic Commerce & Industries, Inc.
	304 Harper Drive, Suite 203		304 Harper Drive, Suite 203
	Moorestown, NJ 08057		Moorestown, NJ 08057
	Phone: +1 856 778-1660		Phone: +1 856 778-1660
	E-mail: sblakewilson@bcisse.com		E-mail: sblakewilson@bcisse.com
	17. Full Copyright Statement		18. Full Copyright Statement
	Copyright (C) The Internet Society (2001). All Rights Reserved.		Copyright (C) The Internet Society (2001-2004). All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it		others, and derivative works that comment on or otherwise explain it
	or assist in its implementation may be prepared, copied, published		or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any		and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph		kind, provided that the above copyright notice and this paragraph
	are included on all such copies and derivative works. However, this		are included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing		document itself may not be modified in any way, such as by removing
	the copyright notice or references to the Internet Society or other		the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of		Internet organizations, except as needed for the purpose of
End of changes. 58 change blocks.
	129 lines changed or deleted		823 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/