< draft-ietf-emu-tls-eap-types-03.txt		draft-ietf-emu-tls-eap-types-04.txt >
	Network Working Group DeKok, Alan		Network Working Group DeKok, Alan
	INTERNET-DRAFT FreeRADIUS		INTERNET-DRAFT FreeRADIUS
	Updates: 5247, 5281, 7170 22 June 2021		Updates: 5247, 5281, 7170 21 January 2022
	Category: Standards Track		Category: Standards Track
	Expires: December 22, 2021		Expires: July 21, 2022
	TLS-based EAP types and TLS 1.3		TLS-based EAP types and TLS 1.3
	draft-ietf-emu-tls-eap-types-03.txt		draft-ietf-emu-tls-eap-types-04.txt
	Abstract		Abstract
	EAP-TLS [RFC5216] is being updated for TLS 1.3 in [EAPTLS]. Many		EAP-TLS [RFC5216] is being updated for TLS 1.3 in [EAPTLS]. Many
	other EAP [RFC3748] and [RFC5247] types also depend on TLS, such as		other EAP [RFC3748] and [RFC5247] types also depend on TLS, such as
	FAST [RFC4851], TTLS [RFC5281], TEAP [RFC7170], and possibly many		FAST [RFC4851], TTLS [RFC5281], TEAP [RFC7170], and possibly many
	vendor specific EAP methods. This document updates those methods in		vendor specific EAP methods. This document updates those methods in
	order to use the new key derivation methods available in TLS 1.3.		order to use the new key derivation methods available in TLS 1.3.
	Additional changes necessitated by TLS 1.3 are also discussed.		Additional changes necessitated by TLS 1.3 are also discussed.
	skipping to change at page 1, line 46 ¶		skipping to change at page 1, line 46 ¶
	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 January 29, 2021.		This Internet-Draft will expire on January 29, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2022 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info/) in effect on the date of		(http://trustee.ietf.org/license-info/) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 3, line 16 ¶		skipping to change at page 3, line 16 ¶
	1. Introduction ............................................. 4		1. Introduction ............................................. 4
	1.1. Requirements Language ............................... 4		1.1. Requirements Language ............................... 4
	2. Using TLS-based EAP methods with TLS 1.3 ................. 5		2. Using TLS-based EAP methods with TLS 1.3 ................. 5
	2.1. Key Derivation ...................................... 5		2.1. Key Derivation ...................................... 5
	2.2. TEAP ................................................ 6		2.2. TEAP ................................................ 6
	2.3. FAST ................................................ 7		2.3. FAST ................................................ 7
	2.4. TTLS ................................................ 8		2.4. TTLS ................................................ 8
	2.5. PEAP ................................................ 8		2.5. PEAP ................................................ 8
	3. Application Data ......................................... 9		3. Application Data ......................................... 9
	4. Resumption ............................................... 10		3.1. Identities .......................................... 10
	5. Security Considerations .................................. 10		4. Resumption ............................................... 12
	5.1. Protected Success and Failure indicators ............ 11		5. Implementation Status .................................... 12
	6. IANA Considerations ...................................... 12		6. Security Considerations .................................. 13
	7. References ............................................... 13		6.1. Protected Success and Failure indicators ............ 14
	7.1. Normative References ................................ 13		7. IANA Considerations ...................................... 15
	7.2. Informative References .............................. 14		8. References ............................................... 15
			8.1. Normative References ................................ 15
			8.2. Informative References .............................. 16
	1. Introduction		1. Introduction
	EAP-TLS is being updated for TLS 1.3 in [EAPTLS]. Many other EAP		EAP-TLS is being updated for TLS 1.3 in [EAPTLS]. Many other EAP
	types also depend on TLS, such as FAST [RFC4851], TTLS [RFC5281],		types also depend on TLS, such as FAST [RFC4851], TTLS [RFC5281],
	TEAP [RFC7170], and possibly many vendor specific EAP methods such as		TEAP [RFC7170], and possibly many vendor specific EAP methods such as
	PEAP [PEAP]. All of these methods use key derivation functions which		PEAP [PEAP]. All of these methods use key derivation functions which
	are no longer applicable to TLS 1.3. As such, all of those methods		are no longer applicable to TLS 1.3. As such, all of those methods
	are incompatible with TLS 1.3.		are incompatible with TLS 1.3.
	skipping to change at page 5, line 19 ¶		skipping to change at page 5, line 19 ¶
	implementations of EAP methods that wish to use TLS 1.3 MUST follow		implementations of EAP methods that wish to use TLS 1.3 MUST follow
	the guidelines in [EAPTLS].		the guidelines in [EAPTLS].
	There remain some differences between EAP-TLS and other TLS-based EAP		There remain some differences between EAP-TLS and other TLS-based EAP
	methods which necessitates this document. The main difference is		methods which necessitates this document. The main difference is
	that [EAPTLS] uses the EAP-TLS Type (value 0x0D) in a number of		that [EAPTLS] uses the EAP-TLS Type (value 0x0D) in a number of
	calculations, whereas other method types will use their own Type		calculations, whereas other method types will use their own Type
	value instead of the EAP-TLS Type value. This topic is discussed		value instead of the EAP-TLS Type value. This topic is discussed
	further below in Section 2.		further below in Section 2.
	An additional difference is that the [EAPTLS] Section 2.5 requires		An additional difference is that [EAPTLS] Section 2.5 requires that
	that once the EAP-TLS handshake has completed, the EAP server sends a		once the EAP-TLS handshake has completed, the EAP server sends a
	protected success result indication. This indication is composed of		protected success result indication. This indication is composed of
	one octet (0x00) of application data. Other TLS-based EAP methods		one octet (0x00) of application data. Other TLS-based EAP methods
	also use this indicator, but only during resumption. When the other		also use this indicator, but only during resumption. When other TLS-
	TLS-based EAP methods use full authentication, the indicator is not		based EAP methods use full authentication, the indicator is not
	needed, and is not used. This topic is explained in more detail		needed, and is not used. This topic is explained in more detail
	below, in Section 3.		below, in Section 3.
	Finally, the document includes clarifications on how various TLS-		Finally, the document includes clarifications on how various TLS-
	based parameters are calculated when using TLS 1.3. These parameters		based parameters are calculated when using TLS 1.3. These parameters
	are different for each EAP method, so they are discussed separately.		are different for each EAP method, so they are discussed separately.
	2.1. Key Derivation		2.1. Key Derivation
	The key derivation for TLS-based EAP methods depends on the value of		The key derivation for TLS-based EAP methods depends on the value of
	skipping to change at page 5, line 48 ¶		skipping to change at page 5, line 48 ¶
	Type = value of the EAP Method type		Type = value of the EAP Method type
	For the purposes of this specification, when we refer to logical		For the purposes of this specification, when we refer to logical
	Type, we mean that the logical Type is defined to be 1 octet for		Type, we mean that the logical Type is defined to be 1 octet for
	values smaller than 254 (the value for the Expanded Type), and when		values smaller than 254 (the value for the Expanded Type), and when
	Expanded EAP Types are used, the logical Type is defined to be the		Expanded EAP Types are used, the logical Type is defined to be the
	concatetation of the fields required to define the Expanded Type,		concatetation of the fields required to define the Expanded Type,
	including the Type with value 0xfe, Vendor-Id (in network byte order)		including the Type with value 0xfe, Vendor-Id (in network byte order)
	and Vendor-Type fields (in network byte order) defined in [RFC3748]		and Vendor-Type fields (in network byte order) defined in [RFC3748]
	Section 5.7.		Section 5.7, as given below:
	Type = 0xFE || Vendor-Id || Vendor-Type		Type = 0xFE || Vendor-Id || Vendor-Type
	This definition does not alter the meaning of Type in [RFC3748], or		This definition does not alter the meaning of Type in [RFC3748], or
	change the structure of EAP packets. Instead, this definition allows		change the structure of EAP packets. Instead, this definition allows
	us to simplify references to EAP Types, by just using a logical		us to simplify references to EAP Types, by just using a logical
	"Type" instead of referring to "the Type field or the Type field with		"Type" instead of referring to "the Type field or the Type field with
	value 0xfe, plus the Vendor-ID and Vendor-Type".		value 0xfe, plus the Vendor-ID and Vendor-Type".
	Unless otherwise discussed below, the key derivation functions for		Unless otherwise discussed below, the key derivation functions for
	skipping to change at page 8, line 15 ¶		skipping to change at page 8, line 15 ¶
	2.4. TTLS		2.4. TTLS
	[RFC5281] Section 11.1 defines an implicit challenge when the inner		[RFC5281] Section 11.1 defines an implicit challenge when the inner
	methods of CHAP [RFC1994], MS-CHAP [RFC2433], or MS-CHAPv2 [RFC2759]		methods of CHAP [RFC1994], MS-CHAP [RFC2433], or MS-CHAPv2 [RFC2759]
	are used. The derivation for TLS 1.3 is instead given as		are used. The derivation for TLS 1.3 is instead given as
	EAP-TTLS_challenge = TLS-Exporter("ttls challenge",, n)		EAP-TTLS_challenge = TLS-Exporter("ttls challenge",, n)
	There no "context_value" ([RFC8446] Section 7.5) passed to the TLS-		There no "context_value" ([RFC8446] Section 7.5) passed to the TLS-
	Exporter function. The value "n" given here is the length of the		Exporter function. The value "n" given here is the length of the
	challenge required, which [RFC5281] requires to be either 8 or 16		data required, which [RFC5281] requires it to be 17 octets for CHAP
	octets, depending on the challenge being used.		(Section 11.2.2) and MS-CHAP-V2 (Section 11.2.4), and to be 9 octets
			for Ms-CHAP (Section 11.2.3).
	Note that unlike TLS 1.2 and earlier, the calculation of TLS-Exporter		Note that unlike TLS 1.2 and earlier, the calculation of TLS-Exporter
	depends on the length passed to it. Implementations therefore MUST		depends on the length passed to it. Implementations therefore MUST
	pass the correct length, instead of passing a large length and		pass the correct length instead of passing a large length and
	truncating the output. Any output calculated using a longer length		truncating the output. Any output calculated using a larger length
	which is then truncated, will be different from the output calculated		value, and which is then truncated, will be different from the output
	using the correct length.		which was calculated using the correct length.
	2.5. PEAP		2.5. PEAP
	When PEAP uses crypto binding, it uses a different key calculation		When PEAP uses crypto binding, it uses a different key calculation
	defined in [PEAP-MPPE] which consumes inner method keying material.		defined in [PEAP-MPPE] which consumes inner method keying material.
	The pseudo-random function (PRF) used here is not taken from the TLS		The pseudo-random function (PRF) used here is not taken from the TLS
	exporter, but is instead calculated via a different method which is		exporter, but is instead calculated via a different method which is
	given in [PEAP-PRF]. That derivation remains unchanged in this		given in [PEAP-PRF]. That derivation remains unchanged in this
	specification.		specification.
	skipping to change at page 9, line 12 ¶		skipping to change at page 9, line 12 ¶
	above in Section 2.1, instead of using the TLS-PRF-128 derivation		above in Section 2.1, instead of using the TLS-PRF-128 derivation
	given above.		given above.
	3. Application Data		3. Application Data
	Unlike previous TLS versions, TLS 1.3 can continue negotiation after		Unlike previous TLS versions, TLS 1.3 can continue negotiation after
	the initial TLS handshake has been completed, which TLS 1.3 calls the		the initial TLS handshake has been completed, which TLS 1.3 calls the
	"CONNECTED" state. Some implementations use a "TLS finished"		"CONNECTED" state. Some implementations use a "TLS finished"
	determination as an indication that TLS negotiation has completed,		determination as an indication that TLS negotiation has completed,
	and that an "inner tunnel" session can now be negotiated. This		and that an "inner tunnel" session can now be negotiated. This
	assumption is no longer correct for TLS 1.3.		assumption is not always correct with TLS 1.3.
	TLS 1.3 permits NewSessionTicket messages to be sent before the TLS		Earlier TLS versions did not always send application data along with
	"Finished", and after application data is sent. This change can		the "TLS finished" method. It was then possible for implementations
	cause many implementations to fail in a number of different ways.		to assume that a transition to "TLS finished" also meant that there
			was no application data available, and that another round trip was
			required. This assumption is not true with TLS 1.3, and applications
			relying on that behavior will not operate correctly with TLS 1.3.
			As a result, implementations MUST check for application data once the
			TLS session has been established. This check MUST be performed
			before proceeding with another round trip of TLS negotiation. If
			application data is available, it MUST be processed according to the
			relevant resumption and/or EAP type.
			TLS 1.3 also permits NewSessionTicket messages to be sent before the
			TLS "Finished", and after application data is sent. This change can
			cause many implementations to fail in a number of different ways, due
			to a reliance on implicit behavior seen in earlier TLS versions/
	In order to correct this failure, we require that if the underlying		In order to correct this failure, we require that if the underlying
	TLS connection is still performing negotiation, then implementations		TLS connection is still performing negotiation, then implementations
	MUST NOT send, or expect to receive application data in the TLS		MUST NOT send, or expect to receive application data in the TLS
	session. Implementations MUST delay processing of application data		session. Implementations MUST delay processing of application data
	until such time as the TLS negotiation has finished. If the TLS		until such time as the TLS negotiation has finished. If the TLS
	negotiation is successful, then the application data can be examined.		negotiation is successful, then the application data can be examined.
	If the TLS negotiation is unsuccessful, then the application data is		If the TLS negotiation is unsuccessful, then the application data is
	untrusted, and therefore MUST be discarded without being examined.		untrusted, and therefore MUST be discarded without being examined.
	The default for many TLS library implementations is to send a		The default for many TLS library implementations is to send a
	NewSessionTicket message immediately after, or along with, the TLS		NewSessionTicket message immediately after, or along with, the TLS
	Finished message. This ticket is could be used for resumption, even		Finished message. This ticket could be used for resumption, even if
	if the "inner tunnel" authentication has not been completed. If the		the "inner tunnel" authentication has not been completed. If the
	ticket could be used, then it could allow a malicious EAP peer to		ticket could be used, then it could allow a malicious EAP peer to
	completely bypass the "inner tunnel" authentication		completely bypass the "inner tunnel" authentication
	Therefore, the EAP server MUST NOT permit any session ticket to		Therefore, the EAP server MUST NOT permit any session ticket to
	successfully resume authentication, unless the inner tunnel		successfully resume authentication, unless the inner tunnel
	authentication has completed successfully.		authentication has completed successfully. The alternative would
			allow an attacker to bypass authentication by obtaining a session
			ticket, and then immediately closing the current session, and
			"resuming" using the session ticket.
	To protect against that attack, implementations SHOULD NOT send		To protect against that attack, implementations SHOULD NOT send
	NewSessionTicket messages until the "inner tunnel" authentication has		NewSessionTicket messages until the "inner tunnel" authentication has
	completed. There is no reason to send session tickets which will		completed. There is no reason to send session tickets which will
	later be invalidated or ignored. However, we recognize that this		later be invalidated or ignored. However, we recognize that this
	suggestion may not always be possible to implement with some		suggestion may not always be possible to implement with some
	available TLS libraries. As such, EAP server MUST take care to		available TLS libraries. As such, EAP servers MUST take care to
	either invalidate or discard session tickets which are associated		either invalidate or discard session tickets which are associated
	with sessions that terminate in EAP Failure.		with sessions that terminate in EAP Failure.
	The NewSessionTicketMessage SHOULD also be sent along with other		The NewSessionTicketMessage SHOULD also be sent along with other
	application data, if possible. Sending that message alone bloats the		application data, if possible. Sending that message alone prolongs
	packet exchange to no benefit.		the packet exchange to no benefit.
	[EAPTLS] Section 2.5 requires a protected result indicator which		[EAPTLS] Section 2.5 requires a protected result indicator which
	indicates that TLS negotiation has finished. Methods which use		indicates that TLS negotiation has finished. Methods which use
	"inner tunnel" methods MUST instead begin their "inner tunnel"		"inner tunnel" methods MUST instead begin their "inner tunnel"
	negotiation by sending Type-specific application data.		negotiation by sending Type-specific application data.
			3.1. Identities
			[EAPTLS] Sections 2.1.3 and 2.1.7 recommend the use of anonymous
			Network Access Identifiers (NAIs) [RFC7542] in the EAP Identity
			Response packet. However, as EAP-TLS does not send application data
			inside of the TLS tunnel, that specification does not address the
			subject of "inner" identities in tunneled EAP methods. This subject,
			however, must be addressed for the tunneled methods.
			Using an anonymous NAI has two benefits. First, an anonymous identity
			makes it more difficult to track users. Second, an NAI allows the
			EAP session to be routed in an AAA framework.
			For the purposes of tunneled EAP methods, we can therefore view the
			outer TLS layer as being mainly a secure transport layer. That
			transport layer is responsible for getting the actual (inner)
			authentication credentials securely from the EAP peer to the EAP
			server. As the outer identity is simply an anonymous routing
			identifier, there is little reason for it to be the same as the inner
			identity. We therefore have a few recommendations on the inner
			identity, and its relationship to the outer identity.
			For the purpose of this section, we define the inner identity as the
			identification information carried inside of the TLS tunnel. For
			PEAP, that identity may be an EAP Response Identity. For TTLS, it
			may be the User-Name attribute. Vendor-specific EAP methods which
			use TLS will generally also have an "inner" identity.
			Implementations MUST NOT use anonymous identities for the inner
			identity. If anonymous network access is desired, eap peers MUST use
			EAP-TLS without peer authentication, as per [EAPTLS] section 2.1.5.
			EAP servers MUST cause authentication to fail if an EAP peer uses an
			anonymous "inner" identity for any TLS-based EAP method.
			Implementations SHOULD NOT use inner identies which contain an NAI
			realm. The outer identity contains an NAI realm, which ensures that
			the inner authentication method is routed to the correct destination.
			As such, any NAI realm in the inner identity is almost always
			redundant.
			However, if the inner identity does contain an NAI realm, the inner
			realm SHOULD be either an exact copy of the outer realm, or be a
			subdomain of the outer realm. The inner realm SHOULD NOT be from a
			different realm than the outer realm. There are very few reasons for
			those realms to be different.
			In general, routing identifiers should be strongly tied to the data
			which they are routing. Tying disparate identities together means
			that different processes are artificially correlated, which makes
			networks more fragile.
			For example, an organization which uses a "hosted" AAA provider may
			choose to use the realm of the AAA provider as the outer identity.
			The inner identity can then be fully qualified (user name plus realm)
			of the organization. This practice can result in successful
			authentications, but it has difficulties.
			Other organizations may host their own AAA servers, but use a "cloud"
			identity provider to hold user accounts. In that situation, the
			organizations may use their own realm as the outer (routing)
			identity, then use an identity from the "cloud" provider as the inner
			identity. This practice is NOT RECOMMENDED. User accounts for an
			organization should be qualified as belonging to that organization,
			and not to an unrelated third party.
			Both of these practices mean that changing "cloud" providers is
			difficult. When such a change happens, each individual supplicant
			must be updated with new identies pointing to the new "cloude"
			provider. This process can be expensive, and some supplicants may
			not be online when this changover happens. The result could be
			devices or users who are unable to obtain network access, even if all
			relevant network systems are online and functional.
			Further, standards such as [RFC7585] allow for dynamic discovery of
			home servers for authentication. That specification has been widely
			deployed, and means that there is minimal cost to routing
			authentication to a particular domain. The authentication can also
			be routed to a particular identity provider, and changed at will,
			with no loss of functionality. That specification is also scalable,
			in that it does not require changes to many systems when one domain
			updates its configuration.
			We recognize that there may be existing use-cases where these
			identities use different realms. As such, we cannot forbid that
			practice. We hope that the discussion above shows not only why such
			practices are problematic, but also that it shows how alternative
			methods are more flexible, and more scalable.
	4. Resumption		4. Resumption
	[EAPTLS] Section 2.1.3 defines the process for resumption. This		[EAPTLS] Section 2.1.3 defines the process for resumption. This
	process is the same for all TLS-based EAP types. The only practical		process is the same for all TLS-based EAP types. The only practical
	difference is that the value of the Type field is different.		difference is that the value of the Type field is different.
	All TLS-based EAP methods support resumption, as it is a property of		All TLS-based EAP methods support resumption, as it is a property of
	the underlying TLS protocol. All EAP servers and peers MUST support		the underlying TLS protocol. All EAP servers and peers MUST support
	resumption for all TLS-based EAP methods. We note that EAP servers		resumption for all TLS-based EAP methods. We note that EAP servers
	and peers can still choose to not resume any particular session. For		and peers can still choose to not resume any particular session. For
	skipping to change at page 10, line 39 ¶		skipping to change at page 12, line 48 ¶
	using EAP-TLS (Type 13), and then perform resumption using another		using EAP-TLS (Type 13), and then perform resumption using another
	EAP type, just as EAP-TTLS (Type 21). However, there is no practical		EAP type, just as EAP-TTLS (Type 21). However, there is no practical
	benefit to doing so. It is also not clear what this behavior would		benefit to doing so. It is also not clear what this behavior would
	mean, or what (if any) security issues there may be with it. As a		mean, or what (if any) security issues there may be with it. As a
	result, this behavior is forbidden.		result, this behavior is forbidden.
	EAP servers therefore MUST NOT resume sessions across different EAP		EAP servers therefore MUST NOT resume sessions across different EAP
	Types, and EAP servers MUST reject resumptions in which the EAP Type		Types, and EAP servers MUST reject resumptions in which the EAP Type
	value is different from the original authentication.		value is different from the original authentication.
	5. Security Considerations		5. Implementation Status
			TTLS and PEAP are implemented and tested to be inter-operable with
			wpa_supplicant 2.10 and Windows 11 as clients, and FreeRADIUS 3.0.26
			and Radiator as RADIUS servers.
			The wpa_supplicant implementation requires that a configuration flag
			be set "tls_disable_tlsv1_3=0", and describes the flag as "enable
			TLSv1.3 (experimental - disabled by default)". However,
			interoperability testing shows that PEAP and TTLS both work with
			Radiator and FreeRADIUS.
			Implementors have demonstrated significant interest in getting PEAP
			and TTLS working for TLS 1.3, but less interest in EAP-FAST and TTLS.
			As such, there is no implementation experience with EAP-FAST or TEAP.
			However, we believe that the definitions described above are correct,
			and are workable.
			6. Security Considerations
	[EAPTLS] Section 5 is included here by reference.		[EAPTLS] Section 5 is included here by reference.
	Updating the above EAP methods to use TLS 1.3 is of high importance		Updating the above EAP methods to use TLS 1.3 is of high importance
	for the Internet Community. Using the most recent security protocols		for the Internet Community. Using the most recent security protocols
	can significantly improve security and privace of a network.		can significantly improve security and privacy of a network.
	In some cases, client certificates are not used for TLS-based EAP		In some cases, client certificates are not used for TLS-based EAP
	methods. In those cases, the user is authenticated only after		methods. In those cases, the user is authenticated only after
	successful completion of the inner tunnel authentication. However,		successful completion of the inner tunnel authentication. However,
	the TLS protocol may send one or more NewSessionTicket after		the TLS protocol may send one or more NewSessionTicket after
	receiving the TLS Finished message from the client, and therefore		receiving the TLS Finished message from the client, and therefore
	before the user is authenticated.		before the user is authenticated.
	This separation of data allows for a "time of use, time of check"		This separation of data allows for a "time of use, time of check"
	security issue. Malicious clients can begin a session and receive a		security issue. Malicious clients can begin a session and receive a
	skipping to change at page 11, line 19 ¶		skipping to change at page 13, line 46 ¶
	authentication session, and the obtained NewSessionTicket to "resume"		authentication session, and the obtained NewSessionTicket to "resume"
	the previous session.		the previous session.
	As a result, EAP servers MUST NOT permit sessions to be resumed until		As a result, EAP servers MUST NOT permit sessions to be resumed until
	after authentication has successfully completed. This requirement		after authentication has successfully completed. This requirement
	may be met in a number of ways. For example, by not caching the		may be met in a number of ways. For example, by not caching the
	session ticket until after authentication has completed, or by		session ticket until after authentication has completed, or by
	marking up the cached session ticket with a flag stating whether or		marking up the cached session ticket with a flag stating whether or
	not authentication has completed.		not authentication has completed.
	For PEAP, some derivation use HMAC-SHA1 [PEAP-MPPE]. There are no		For PEAP, some derivations use HMAC-SHA1 [PEAP-MPPE]. In the
	known security issues with HMAC-SHA1. In the interests of		interests of interoperability and minimal changes, we do not change
	interoperability and minimal changes, we do not change that		that deriviation, as there are no known security issues with HMAC-
	deriviation.		SHA1. Further, the data derived from the HMAC-SHA1 calculations is
			exchanged inside of the TLS tunnel, and is visible only to users who
			have already successfully authenticated. As such, the security risks
			are minimal.
	5.1. Protected Success and Failure indicators		6.1. Protected Success and Failure indicators
	[EAPTLS] provides for protected success and failure indicators as		[EAPTLS] provides for protected success and failure indicators as
	discussed in Section 4.1.1 of [RFC4137]. These indicators are		discussed in Section 4.1.1 of [RFC4137]. These indicators are
	provided for both full authentication, and for resumption.		provided for both full authentication, and for resumption.
	Other TLS-based EAP methods provide these indicators only for		Other TLS-based EAP methods provide these indicators only for
	resumption.		resumption.
	For full authenticaton, the other TLS-based EAP methods do not		For full authenticaton, the other TLS-based EAP methods do not
	provide for protected success and failure indicators as part of the		provide for protected success and failure indicators as part of the
	skipping to change at page 11, line 49 ¶		skipping to change at page 14, line 31 ¶
	versions, and therefore introduces no new security issues.		versions, and therefore introduces no new security issues.
	We note that most TLS-based EAP methods provide for success and		We note that most TLS-based EAP methods provide for success and
	failure indicators as part of the authentication exchange performed		failure indicators as part of the authentication exchange performed
	inside of the TLS tunnel. These indicators are therefore protected,		inside of the TLS tunnel. These indicators are therefore protected,
	as they cannot be modified or forged.		as they cannot be modified or forged.
	However, some inner methods do not provide for success or failure		However, some inner methods do not provide for success or failure
	indicators. For example, the use of TTLS with inner PAP or CHAP.		indicators. For example, the use of TTLS with inner PAP or CHAP.
	Those methods send authentication credentials to the server via the		Those methods send authentication credentials to the server via the
	inner tunnel, with no possibility to similarly signal success or		inner tunnel, with no method to signal success or failure inside of
	failure inside of the tunnel.		the tunnel.
	There are functionally equivalent authentication methods which can be		There are functionally equivalent authentication methods which can be
	used to replace the methods which are missing protected indicators.		used to provide protected indicators. PAP can often be replaced with
	PAP can often be replaced with EAP-GTC, and CHAP with EAP-MD5. Both		EAP-GTC, and CHAP with EAP-MD5. Both replacement methods provide for
	replacement methods provide for similar functionality, and have		similar functionality, and have protected success and failure
	protected success and failure indicator. The main cost to this		indicator. The main cost to this change is additional round trips.
	change is additional round trips.
	It is RECOMMENDED that implementations deprecate inner tunnel methods		It is RECOMMENDED that implementations deprecate inner tunnel methods
	which do not provided protected success and failure indicators.		which do not provided protected success and failure indicators.
	Implementations SHOULD use EAP-GTC instead of PAP, and EAP-MD5		Implementations SHOULD use EAP-GTC instead of PAP, and EAP-MD5
	instead of CHAP. New TLS-based EAP methods MUST provide protected		instead of CHAP. New TLS-based EAP methods MUST provide protected
	success and failure indicators inside of the TLS tunnel.		success and failure indicators inside of the TLS tunnel.
	When the inner authentication protocol indicates that authentication		When the inner authentication protocol indicates that authentication
	has failed, then implementations MUST fail authentication for the		has failed, then implementations MUST fail authentication for the
	entire session. There MAY be additional protocol exchanges in order		entire session. There MAY be additional protocol exchanges in order
	skipping to change at page 12, line 38 ¶		skipping to change at page 15, line 18 ¶
	authentication to succeed for the entire session. There MAY be		authentication to succeed for the entire session. There MAY be
	additional protocol exchanges in order which could cause other		additional protocol exchanges in order which could cause other
	failures, so success is not required here.		failures, so success is not required here.
	In both of these cases, the EAP server MUST send an EAP-Failure or		In both of these cases, the EAP server MUST send an EAP-Failure or
	EAP-Success message, as indicated by Section 2, item 4 of [RFC3748].		EAP-Success message, as indicated by Section 2, item 4 of [RFC3748].
	Even though both parties have already determined the final		Even though both parties have already determined the final
	authentication status, the full EAP state machine must still be		authentication status, the full EAP state machine must still be
	followed.		followed.
	6. IANA Considerations		7. IANA Considerations
	This section provides guidance to the Internet Assigned Numbers		This section provides guidance to the Internet Assigned Numbers
	Authority (IANA) regarding registration of values related to the TLS-		Authority (IANA) regarding registration of values related to the TLS-
	based EAP methods for TLS 1.3 protocol in accordance with [RFC8126].		based EAP methods for TLS 1.3 protocol in accordance with [RFC8126].
	This memo requires IANA to add the following labels to the TLS		This memo requires IANA to add the following labels to the TLS
	Exporter Label Registry defined by [RFC5705]. These labels are used		Exporter Label Registry defined by [RFC5705]. These labels are used
	in the derivation of Key_Material and Method-Id as defined above in		in the derivation of Key_Material and Method-Id as defined above in
	Section 2.		Section 2.
	The labels below need to be added to the "TLS Exporter Labels"		The labels below need to be added to the "TLS Exporter Labels"
	registry. These labels are used only for TEAP.		registry. These labels are used only for TEAP.
	* EXPORTER: session key seed		* EXPORTER: session key seed
	* EXPORTER: Inner Methods Compound Keys		* EXPORTER: Inner Methods Compound Keys
	* EXPORTER: Session Key Generating Function		* EXPORTER: Session Key Generating Function
	* EXPORTER: Extended Session Key Generating Function		* EXPORTER: Extended Session Key Generating Function
	* TEAPbindkey@ietf.org		* TEAPbindkey@ietf.org
	7. References		8. References
	7.1. Normative References		8.1. Normative References
	[RFC2119]		[RFC2119]
	Bradner, S., "Key words for use in RFCs to Indicate Requirement		Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", RFC 2119, March, 1997, <http://www.rfc-		Levels", RFC 2119, March, 1997, <http://www.rfc-
	editor.org/info/rfc2119>.		editor.org/info/rfc2119>.
	[RFC3748]		[RFC3748]
	Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.		Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
	Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748,		Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748,
	June 2004.		June 2004.
	skipping to change at page 14, line 7 ¶		skipping to change at page 16, line 36 ¶
	Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key		Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key
	Words", RFC 8174, May 2017, <http://www.rfc-		Words", RFC 8174, May 2017, <http://www.rfc-
	editor.org/info/rfc8174>.		editor.org/info/rfc8174>.
	[RFC8446]		[RFC8446]
	Rescorla, E., "The Transport Layer Security (TLS) Protocol Version		Rescorla, E., "The Transport Layer Security (TLS) Protocol Version
	1.3", RFC 8446, August 2018.		1.3", RFC 8446, August 2018.
	[EAPTLS]		[EAPTLS]
	Mattsson, J., and Sethi, M., "Using EAP-TLS with TLS 1.3", draft-		Mattsson, J., and Sethi, M., "Using EAP-TLS with TLS 1.3", draft-
	ietf-emu-eap-tls13-14, February, 2021.		ietf-emu-eap-tls13-18, July 2021.
	[IANA]		[IANA]
	https://www.iana.org/assignments/eap-numbers/eap-numbers.xhtml#eap-		https://www.iana.org/assignments/eap-numbers/eap-numbers.xhtml#eap-
	numbers-4		numbers-4
	7.2. Informative References		8.2. Informative References
	[MSPEAP]		[MSPEAP]
	https://msdn.microsoft.com/en-us/library/cc238354.aspx		https://msdn.microsoft.com/en-us/library/cc238354.aspx
	[PEAP]		[PEAP]
	Palekar, A. et al, "Protected EAP Protocol (PEAP)", draft-		Palekar, A. et al, "Protected EAP Protocol (PEAP)", draft-
	josefsson-pppext-eap-tls-eap-06.txt, March 2003.		josefsson-pppext-eap-tls-eap-06.txt, March 2003.
	[PEAP-MPPE]		[PEAP-MPPE]
	https://docs.microsoft.com/en-us/openspecs/windows_protocols/MS-		https://docs.microsoft.com/en-us/openspecs/windows_protocols/MS-
	skipping to change at page 15, line 12 ¶		skipping to change at page 17, line 41 ¶
	[RFC4851]		[RFC4851]
	Cam-Winget, N., et al, "The Flexible Authentication via Secure		Cam-Winget, N., et al, "The Flexible Authentication via Secure
	Tunneling Extensible Authentication Protocol Method (EAP-FAST)",		Tunneling Extensible Authentication Protocol Method (EAP-FAST)",
	RFC 4851, May 2007.		RFC 4851, May 2007.
	[RFC5281]		[RFC5281]
	Funk, P., and Blake-Wilson, S., "Extensible Authentication Protocol		Funk, P., and Blake-Wilson, S., "Extensible Authentication Protocol
	Tunneled Transport Layer Security Authenticated Protocol Version 0		Tunneled Transport Layer Security Authenticated Protocol Version 0
	(EAP-TTLSv0)", RFC 5281, August 2008.		(EAP-TTLSv0)", RFC 5281, August 2008.
			[RFC7542]
			DeKoK, A, "The Network Access Identifier", RFC 7542, May 2015.
			[RFC7585]
			Winter, S, and McCauley, M., "Dynamic Peer Discovery for RADIUS/TLS
			and RADIUS/DTLS Based on the Network Access Identifier (NAI)", RFC
			7585, October 2015.
	Acknowledgments		Acknowledgments
	Thanks to Jorge Vergara for a detailed review of the requirements for		Thanks to Jorge Vergara for a detailed review of the requirements for
	various EAP types, and for assistance with interoperability testing.		various EAP types.
			Thanks to Jorge Vergara, Bruno Periera Vidal, Alexander Clouter,
			Karri Huhtanen, and Heikki Vatiainen for reviews of this document,
			and for assistance with interoperability testing.
	Authors' Addresses		Authors' Addresses
	Alan DeKok		Alan DeKok
	The FreeRADIUS Server Project		The FreeRADIUS Server Project
	Email: aland@freeradius.org		Email: aland@freeradius.org
End of changes. 30 change blocks.
	52 lines changed or deleted		192 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/