< draft-ietf-emu-tls-eap-types-04.txt		draft-ietf-emu-tls-eap-types-05.txt >
	Network Working Group DeKok, Alan		Network Working Group DeKok, Alan
	INTERNET-DRAFT FreeRADIUS		INTERNET-DRAFT FreeRADIUS
	Updates: 5247, 5281, 7170 21 January 2022		Updates: 5247, 5281, 7170 5 March 2022
	Category: Standards Track		Category: Standards Track
	Expires: July 21, 2022		Expires: September 05, 2022
	TLS-based EAP types and TLS 1.3		TLS-based EAP types and TLS 1.3
	draft-ietf-emu-tls-eap-types-04.txt		draft-ietf-emu-tls-eap-types-05.txt
	Abstract		Abstract
	EAP-TLS [RFC5216] is being updated for TLS 1.3 in [EAPTLS]. Many		EAP-TLS (RFC 5216) has been updated for TLS 1.3 in RFC 9190. Many
	other EAP [RFC3748] and [RFC5247] types also depend on TLS, such as		other EAP types also depend on TLS, such as FAST (RFC 4851), TTLS
	FAST [RFC4851], TTLS [RFC5281], TEAP [RFC7170], and possibly many		(RFC 5281), TEAP (RFC 7170), and possibly many vendor specific EAP
	vendor specific EAP methods. This document updates those methods in		methods. This document updates those methods in order to use the new
	order to use the new key derivation methods available in TLS 1.3.		key derivation methods available in TLS 1.3. Additional changes
	Additional changes necessitated by TLS 1.3 are also discussed.		necessitated by TLS 1.3 are also discussed.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 3, line 14 ¶		skipping to change at page 3, line 14 ¶
	Table of Contents		Table of Contents
	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.4.1. Client Certificates ............................ 8
			2.5. PEAP ................................................ 9
			2.5.1. Client Certificates ............................ 9
	3. Application Data ......................................... 9		3. Application Data ......................................... 9
	3.1. Identities .......................................... 10		3.1. Identities .......................................... 11
	4. Resumption ............................................... 12		4. Resumption ............................................... 13
	5. Implementation Status .................................... 12		5. Implementation Status .................................... 14
	6. Security Considerations .................................. 13		6. Security Considerations .................................. 14
	6.1. Protected Success and Failure indicators ............ 14		6.1. Protected Success and Failure indicators ............ 15
	7. IANA Considerations ...................................... 15		7. IANA Considerations ...................................... 16
	8. References ............................................... 15		8. References ............................................... 17
	8.1. Normative References ................................ 15		8.1. Normative References ................................ 17
	8.2. Informative References .............................. 16		8.2. Informative References .............................. 18
	1. Introduction		1. Introduction
	EAP-TLS is being updated for TLS 1.3 in [EAPTLS]. Many other EAP		EAP-TLS has been updated for TLS 1.3 in [RFC9190]. 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.
	We wish to enable the use of TLS 1.3 in the wider Internet community.		This document updates those methods in order to be used with TLS 1.3.
	As such, it is necessary to update the above EAP Types. These		These changes involve defining new key derivation functions. We also
	changes involve defining new key derivation functions. We also
	discuss implementation issues in order to highlight differences		discuss implementation issues in order to highlight differences
	between TLS 1.3 and earlier versions of TLS.		between TLS 1.3 and earlier versions of TLS.
	1.1. Requirements Language		1.1. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	2. Using TLS-based EAP methods with TLS 1.3		2. Using TLS-based EAP methods with TLS 1.3
	In general, all of the requirements of [EAPTLS] apply to other EAP		In general, all of the requirements of [RFC9190] apply to other EAP
	methods that wish to use TLS 1.3. Unless otherwise required herein,		methods that wish to use TLS 1.3. Unless otherwise required herein,
	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 [RFC9190].
	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 [RFC9190] 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 [EAPTLS] Section 2.5 requires that		An additional difference is that [RFC9190] Section 2.5 requires 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 other TLS-		also use this indicator, but only during resumption. When other 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 and Section 4.
	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
	the EAP Type as defined by [IANA] in the Extensible Authentication		the EAP Type as defined by [IANA] in the Extensible Authentication
	Protocol (EAP) Registry. The most important definition is of the		Protocol (EAP) Registry. The most important definition is of the
	Type field, as first defined in [RFC3748] Section 2:		Type field, as first defined in [RFC3748] Section 2:
	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,		concatenation 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, as given below:		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". For example, the
			value of Type for PEAP is simply 0x19.
	Unless otherwise discussed below, the key derivation functions for		Unless otherwise discussed below, the key derivation functions for
	all TLS-based EAP Types are defined as follows:		all TLS-based EAP Types are defined in [RFC9190] Section 2.3, and
			reproduced here for clarity:
	Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material",		Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material",
	Type, 128)		Type, 128)
	Method-Id = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id",		Method-Id = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id",
	Type, 64)		Type, 64)
	Session-Id = Type || Method-Id		Session-Id = Type || Method-Id
	MSK = Key_Material(0, 63)		MSK = Key_Material(0, 63)
	EMSK = Key_Material(64, 127)		EMSK = Key_Material(64, 127)
	We note that these definitions re-use the EAP-TLS exporter labels,		We note that these definitions re-use the EAP-TLS exporter labels,
	skipping to change at page 6, line 37 ¶		skipping to change at page 6, line 39 ¶
	as defined in [PEAP] and [MSPEAP]. Some definitions apply to FAST		as defined in [PEAP] and [MSPEAP]. Some definitions apply to FAST
	and TEAP, with exceptions as noted below.		and TEAP, with exceptions as noted below.
	It is RECOMMENDED that vendor-defined TLS-based EAP methods use the		It is RECOMMENDED that vendor-defined TLS-based EAP methods use the
	above definitions for TLS 1.3. There is no compelling reason to use		above definitions for TLS 1.3. There is no compelling reason to use
	different definitions.		different definitions.
	2.2. TEAP		2.2. TEAP
	[RFC7170] Section 5.2 gives a definition for the Inner Method Session		[RFC7170] Section 5.2 gives a definition for the Inner Method Session
	Key (IMSK), which depends on the TLS-PRF. We update that definition		Key (IMSK), which depends on the TLS-PRF. When the inner methods
	for TLS 1.3 as:		generates an EMSK, we update that definition for TLS 1.3 as:
	IMSK = TLS-Exporter("TEAPbindkey@ietf.org", EMSK, 32)		IMSK = TLS-Exporter("TEAPbindkey@ietf.org", EMSK, 32)
			If an inner method does not support export of an Extended Master
			Session Key (EMSK), then IMSK is the MSK of the inner method as per
			[RFC7170] Section 5.2.
	For MSK and EMSK, TEAP [RFC7170] uses an inner tunnel EMSK to		For MSK and EMSK, TEAP [RFC7170] uses an inner tunnel EMSK to
	calculate the outer EMSK. As such, those key derivations cannot use		calculate the outer EMSK. As such, those key derivations cannot use
	the above derivation.		the above derivation.
	The other key derivations for TEAP are given here. All derivations		The other key derivations for TEAP are given here. All derivations
	not given here are the same as given above in the previous section.		not given here are the same as given above in the previous section.
	These derivations are also used for FAST, but using the FAST Type.		These derivations are also used for FAST, but using the FAST Type.
	session_key_seed = TLS-Exporter("EXPORTER: session key seed",		session_key_seed = TLS-Exporter("EXPORTER: session key seed",
	Type, 40)		Type, 40)
	S-IMCK[0] = session_key_seed		S-IMCK[0] = session_key_seed
	For j = 1 to n-1 do		For j = 1 to n-1 do
	IMCK[j] = TLS-Exporter("EXPORTER: Inner Methods Compound Keys",		IMCK[j] = TLS-Exporter("EXPORTER: Inner Methods Compound Keys",
	S-IMCK[j-1] | IMSK[j], 60)		S-IMCK[j-1] | IMSK[j], 60)
	S-IMCK[j] = first 40 octets of IMCK[j]		S-IMCK[j] = first 40 octets of IMCK[j]
	CMK[j] = last 20 octets of IMCK[j]		CMK[j] = last 20 octets of IMCK[j]
	Where | denotes concatenation. MSK and EMSK are then derived from		Where | denotes concatenation. The outer MSK and EMSK are then
	the above definitions, as:		derived from the above definitions, as:
	MSK = TLS-Exporter("EXPORTER: Session Key Generating Function",		MSK = TLS-Exporter("EXPORTER: Session Key Generating Function",
	S-IMCK[j], 64)		S-IMCK[j], 64)
	EMSK = TLS-Exporter("EXPORTER: Extended Session Key Generating Function",		EMSK = TLS-Exporter("EXPORTER: Extended Session Key Generating Function",
	S-IMCK[j], 64)		S-IMCK[j], 64)
	The TEAP Compound MAC defined in [RFC7170] Section 5.3 is updated to		The TEAP Compound MAC defined in [RFC7170] Section 5.3 is updated to
	use the definition of CMK[j] given above, which then leads to the		use the definition of CMK[j] given above, which then leads to the
	following definition		following definition
	CMK = CMK[j]		CMK = CMK[j]
	Compound-MAC = MAC( CMK, BUFFER )		Compound-MAC = MAC( CMK, BUFFER )
	where j is the number of the last successfully executed inner EAP		where j is the number of the last successfully executed inner EAP
	method. For TLS 1.3, the hash function used is the same as the		method. For TLS 1.3, the message authentication code (MAC) is
	ciphersuite hash function negotiated for HKDF in the key schedule, as		computed with the HMAC algorithm negotiated for HKDF in the key
	per section 7.1 of RFC 8446. The definition of BUFFER is unchanged		schedule, as per section 7.1 of RFC 8446. The definition of BUFFER
	from [RFC7170] Section 5.3		is unchanged from [RFC7170] Section 5.3
	2.3. FAST		2.3. FAST
	For FAST, the session_key_seed is also used as the key_block, as		For FAST, the session_key_seed is also part of the key_block, as
	defined in [RFC4851] Section 5.1.		defined in [RFC4851] Section 5.1.
	The definition of S-IMCK[n], MSK, and EMSK are the same as given		The definition of S-IMCK[n], MSK, and EMSK are the same as given
	above for TEAP. We reiterate that the EAP-FAST Type must be used		above for TEAP. We reiterate that the EAP-FAST Type must be used
	when deriving the session_key_seed, and not the TEAP Type.		when deriving the session_key_seed, and not the TEAP Type.
	Unlike [RFC4851] Section 5.2, the definition of IMCK[j] places the		Unlike [RFC4851] Section 5.2, the definition of IMCK[j] places the
	reference to S-IMCK after the textual label, and the concatenates the		reference to S-IMCK after the textual label, and the concatenates the
	IMSK instead of MSK.		IMSK instead of MSK.
	EAP-FAST previously used a PAC, which is a type of pre-shared key		EAP-FAST previously used a PAC, which is a session ticket that
	(PSK). Such uses are deprecated in TLS 1.3. As such, PAC		contains a pre-shared key (PSK) along with other data. As TLS 1.3
	provisioning is no longer part of EAP-FAST when TLS 1.3 is used.		allows session resumptuion using a PSK, the use of a PAC is
			deprecated for EAP-FAST in TLS 1.3. PAC provisioning [RFC5422] is
			also no longer part of EAP-FAST when TLS 1.3 is used.
	The T-PRF given in [RFC4851] Section 5.5 is not used for TLS 1.3.		The T-PRF given in [RFC4851] Section 5.5 is not used for TLS 1.3.
			Instead, it is replaced with the TLS 1.3 TLS-Exporter function.
	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 is no "context_value" ([RFC8446] Section 7.5) passed to the
	Exporter function. The value "n" given here is the length of the		TLS-Exporter function. The value "n" given here is the length of the
	data required, which [RFC5281] requires it to be 17 octets for CHAP		data required, which [RFC5281] requires it to be 17 octets for CHAP
	(Section 11.2.2) and MS-CHAP-V2 (Section 11.2.4), and to be 9 octets		(Section 11.2.2) and MS-CHAP-V2 (Section 11.2.4), and to be 9 octets
	for Ms-CHAP (Section 11.2.3).		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 larger length		truncating the output. Any output calculated using a larger length
	value, and which is then truncated, will be different from the output		value, and which is then truncated, will be different from the output
	which was calculated using the correct length.		which was calculated using the correct length.
			2.4.1. Client Certificates
			[RFC5281] Section 7.6 permits "Authentication of the client via
			client certificate during phase 1, with no additional authentication
			or information exchange required.". This practice is forbidden when
			TTLS is used with TLS 1.3. If there is a requirement to use client
			certificates with no inner tunnel methods, then EAP-TLS should be
			used instead of TTLS.
			The use of client certificates is still permitted when using TTLS
			with TLS 1.3. However, if the client certificate is accepted, then
			the EAP peer MUST proceed with additional authentication of Phase 2,
			as per [RFC5281] Section 7.2 and following. If there is no Phase 2
			data, then the EAP server MUST reject the session.
	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.
	However, the key calculation uses a PEAP Tunnel Key [PEAP-TK] which		However, the key calculation uses a PEAP Tunnel Key [PEAP-TK] which
	is defined as:		is defined as:
	... the TK is the first 60 octets of the Key_Material, as		... the TK is the first 60 octets of the Key_Material, as
	specified in [RFC5216]: TLS-PRF-128 (master secret, "client EAP		specified in [RFC5216]: TLS-PRF-128 (master secret, "client EAP
	encryption", client.random || server.random).		encryption", client.random || server.random).
	We note that this text does not define Key_Material. Instead, it		We note that this text does not define Key_Material. Instead, it
	defines TK as the first octets of Key_Material, and gives a		defines TK as the first octets of Key_Material, and gives a
	definition of Key_Material which is appropriate for TLS versions		definition of Key_Material which is appropriate for TLS versions
	before TLS 1.3.		before TLS 1.3.
	For TLS 1.3, the TK should be derived from the Key_Material defined		For TLS 1.3, the TK should be derived from the Key_Material defined
	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.
			2.5.1. Client Certificates
			As with TTLS, [PEAP] permits the use of client certificates in
			addition to inner tunnel methods.
			The use of client certificates is still permitted when using PEAP
			with TLS 1.3. However, if the client certificate is accepted, then
			the EAP peer MUST proceed with additional authentication of the inner
			tunnel. If there is no inner tunnel authentication data, then the
			EAP server MUST reject the session.
	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 not always correct with TLS 1.3.		assumption is not always correct with TLS 1.3.
	Earlier TLS versions did not always send application data along with		Earlier TLS versions did not always send application data along with
	skipping to change at page 9, line 30 ¶		skipping to change at page 10, line 17 ¶
	As a result, implementations MUST check for application data once the		As a result, implementations MUST check for application data once the
	TLS session has been established. This check MUST be performed		TLS session has been established. This check MUST be performed
	before proceeding with another round trip of TLS negotiation. If		before proceeding with another round trip of TLS negotiation. If
	application data is available, it MUST be processed according to the		application data is available, it MUST be processed according to the
	relevant resumption and/or EAP type.		relevant resumption and/or EAP type.
	TLS 1.3 also permits NewSessionTicket messages to be sent before the		TLS 1.3 also permits NewSessionTicket messages to be sent before the
	TLS "Finished", and after application data is sent. This change can		TLS "Finished", and after application data is sent. This change can
	cause many implementations to fail in a number of different ways, due		cause many implementations to fail in a number of different ways, due
	to a reliance on implicit behavior seen in earlier TLS versions/		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 could be used for resumption, even if		Finished message. This ticket could be used for resumption, even 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. The alternative would		authentication has completed successfully. The alternative would
	allow an attacker to bypass authentication by obtaining a session		allow an attacker to bypass authentication by obtaining a session
	ticket, and then immediately closing the current session, and		ticket, and then immediately closing the current session, and
	"resuming" using the session ticket.		"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 servers 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 NewSessionTicket message SHOULD also be sent along with other
	application data, if possible. Sending that message alone prolongs		application data, if possible. Sending that message alone prolongs
	the packet exchange to no benefit.		the packet exchange to no benefit.
	[EAPTLS] Section 2.5 requires a protected result indicator which		[RFC9190] 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		3.1. Identities
	[EAPTLS] Sections 2.1.3 and 2.1.7 recommend the use of anonymous		[RFC9190] Sections 2.1.3 and 2.1.7 recommend the use of anonymous
	Network Access Identifiers (NAIs) [RFC7542] in the EAP Identity		Network Access Identifiers (NAIs) [RFC7542] in the EAP Identity
	Response packet. However, as EAP-TLS does not send application data		Response packet. However, as EAP-TLS does not send application data
	inside of the TLS tunnel, that specification does not address the		inside of the TLS tunnel, that specification does not address the
	subject of "inner" identities in tunneled EAP methods. This subject,		subject of "inner" identities in tunneled EAP methods. This subject
	however, must be addressed for the tunneled methods.		must, however, be addressed for the tunneled methods.
	Using an anonymous NAI has two benefits. First, an anonymous identity		Using an anonymous NAI as per [RFC7542] Section 2.4 has two benefits.
	makes it more difficult to track users. Second, an NAI allows the		First, an anonymous identity makes it more difficult to track users.
	EAP session to be routed in an AAA framework.		Second, an NAI allows the EAP session to be routed in an AAA
			framework as described in [RFC7542] Section 3.
	For the purposes of tunneled EAP methods, we can therefore view the		For the purposes of tunneled EAP methods, we can therefore view the
	outer TLS layer as being mainly a secure transport layer. That		outer TLS layer as being mainly a secure transport layer. That
	transport layer is responsible for getting the actual (inner)		transport layer is responsible for getting the actual (inner)
	authentication credentials securely from the EAP peer to the EAP		authentication credentials securely from the EAP peer to the EAP
	server. As the outer identity is simply an anonymous routing		server. As the outer identity is often used as an anonymous routing
	identifier, there is little reason for it to be the same as the inner		identifier for AAA ([RFC7542] Section 3), there is little reason for
	identity. We therefore have a few recommendations on the inner		it to be the same as the inner identity. We therefore have a few
	identity, and its relationship to the outer identity.		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		For the purpose of this section, we define the inner identity as the
	identification information carried inside of the TLS tunnel. For		identification information carried inside of the TLS tunnel. For
	PEAP, that identity may be an EAP Response Identity. For TTLS, it		PEAP, that identity may be an EAP Response Identity. For TTLS, it
	may be the User-Name attribute. Vendor-specific EAP methods which		may be the User-Name attribute. Vendor-specific EAP methods which
	use TLS will generally also have an "inner" identity.		use TLS will generally also have an inner identity.
	Implementations MUST NOT use anonymous identities for the inner		Implementations MUST NOT use anonymous identities for the inner
	identity. If anonymous network access is desired, eap peers MUST use		identity. If anonymous network access is desired, eap peers MUST use
	EAP-TLS without peer authentication, as per [EAPTLS] section 2.1.5.		EAP-TLS without peer authentication, as per [RFC9190] section 2.1.5.
	EAP servers MUST cause authentication to fail if an EAP peer uses an		EAP servers MUST cause authentication to fail if an EAP peer uses an
	anonymous "inner" identity for any TLS-based EAP method.		anonymous "inner" identity for any TLS-based EAP method.
	Implementations SHOULD NOT use inner identies which contain an NAI		Implementations SHOULD NOT use inner identities which contain an NAI
	realm. The outer identity contains an NAI realm, which ensures that		realm. The outer identity contains an NAI realm, which ensures that
	the inner authentication method is routed to the correct destination.		the inner authentication method is routed to the correct destination.
	As such, any NAI realm in the inner identity is almost always		As such, any NAI realm in the inner identity is almost always
	redundant.		redundant.
	However, if the inner identity does contain an NAI realm, the inner		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		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		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		different realm than the outer realm. There are very few reasons for
	those realms to be different.		those realms to be different.
	In general, routing identifiers should be strongly tied to the data		In general, routing identifiers should be associated with with the
	which they are routing. Tying disparate identities together means		authentication data that they are routing. For example, if a user
	that different processes are artificially correlated, which makes		has an inner identity of "user@example.com", then it generally makes
	networks more fragile.		no sense to have an outer identity of "@example.org". The
			authentication request would then be routed to the "example.org"
			domain, which may have no idea what to do with the credentials for
			"user@example.com". At best, the authentication request would be
			discarded. At worst, the "example.org" domain could harvest user
			credentials for later use in attacks on "example.com".
			In addition, associating disparate inner/outer identities in the same
			EAP authentication session means that otherwise unrelated realms are
			tied together, which can make networks more fragile.
	For example, an organization which uses a "hosted" AAA provider may		For example, an organization which uses a "hosted" AAA provider may
	choose to use the realm of the AAA provider as the outer identity.		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)		The inner identity can then be fully qualified: user name plus realm
	of the organization. This practice can result in successful		of the organization. This practice can result in successful
	authentications, but it has difficulties.		authentications, but it has difficulties.
	Other organizations may host their own AAA servers, but use a "cloud"		Other organizations may host their own AAA servers, but use a "cloud"
	identity provider to hold user accounts. In that situation, the		identity provider to hold user accounts. In that situation, the
	organizations may use their own realm as the outer (routing)		organizations may use their own realm as the outer (routing)
	identity, then use an identity from the "cloud" provider as the inner		identity, then use an identity from the "cloud" provider as the inner
	identity. This practice is NOT RECOMMENDED. User accounts for an		identity. This practice is NOT RECOMMENDED. User accounts for an
	organization should be qualified as belonging to that organization,		organization should be qualified as belonging to that organization,
	and not to an unrelated third party.		and not to an unrelated third party.
	Both of these practices mean that changing "cloud" providers is		Both of these practices mean that changing "cloud" providers is
	difficult. When such a change happens, each individual supplicant		difficult. When such a change happens, each individual supplicant
	must be updated with new identies pointing to the new "cloude"		must be updated with a different outer identity which points to the
	provider. This process can be expensive, and some supplicants may		new "cloud" provider. This process can be expensive, and some
	not be online when this changover happens. The result could be		supplicants may not be online when this changeover happens. The
	devices or users who are unable to obtain network access, even if all		result could be devices or users who are unable to obtain network
	relevant network systems are online and functional.		access, even if all relevant network systems are online and
			functional.
	Further, standards such as [RFC7585] allow for dynamic discovery of		Further, standards such as [RFC7585] allow for dynamic discovery of
	home servers for authentication. That specification has been widely		home servers for authentication. That specification has been widely
	deployed, and means that there is minimal cost to routing		deployed, and means that there is minimal cost to routing
	authentication to a particular domain. The authentication can also		authentication to a particular domain. The authentication can also
	be routed to a particular identity provider, and changed at will,		be routed to a particular identity provider, and changed at will,
	with no loss of functionality. That specification is also scalable,		with no loss of functionality. That specification is also scalable,
	in that it does not require changes to many systems when one domain		in that it does not require changes to many systems when a domain
	updates its configuration.		updates its configuration. Instead, only one thing has to change:
			the configuration of that domain. Everything else is discovered
			dynamically.
	We recognize that there may be existing use-cases where these		That is, changing the configuration for one domain is significantly
	identities use different realms. As such, we cannot forbid that		simpler and more scalable than changing the configuration for
	practice. We hope that the discussion above shows not only why such		potentially millions of end-user devices.
	practices are problematic, but also that it shows how alternative
	methods are more flexible, and more scalable.		We recognize that there may be existing use-cases where the inner and
			outer 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, more scalable, and are easier
			to manage.
	4. Resumption		4. Resumption
	[EAPTLS] Section 2.1.3 defines the process for resumption. This		[RFC9190] 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.
			Note that if resumption is performed, then the EAP server MUST send
			the protected success result indicator (one octet of 0x00) inside the
			TLS tunnel as per [RFC9190]. If either peer or server instead
			initiates an inner tunnel method, then that method MUST be followed,
			and resumption MUST NOT be used. The EAP peer MUST in turn check for
			the existence the protected success result indicator (one octet of
			0x00), and cause authentication to fail if that octet is not
			received.
	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
	example, EAP servers may forbid resumption for administrative, or		example, EAP servers may forbid resumption for administrative, or
	other policy reasons.		other policy reasons.
	It is RECOMMENDED that EAP servers and peers enable resumption, and		It is RECOMMENDED that EAP servers and peers enable resumption, and
	use it where possible. The use of resumption decreases the number of		use it where possible. The use of resumption decreases the number of
	round trips used for authentication. This decrease leads to lower		round trips used for authentication. This decrease leads to lower
	skipping to change at page 13, line 13 ¶		skipping to change at page 14, line 30 ¶
	wpa_supplicant 2.10 and Windows 11 as clients, and FreeRADIUS 3.0.26		wpa_supplicant 2.10 and Windows 11 as clients, and FreeRADIUS 3.0.26
	and Radiator as RADIUS servers.		and Radiator as RADIUS servers.
	The wpa_supplicant implementation requires that a configuration flag		The wpa_supplicant implementation requires that a configuration flag
	be set "tls_disable_tlsv1_3=0", and describes the flag as "enable		be set "tls_disable_tlsv1_3=0", and describes the flag as "enable
	TLSv1.3 (experimental - disabled by default)". However,		TLSv1.3 (experimental - disabled by default)". However,
	interoperability testing shows that PEAP and TTLS both work with		interoperability testing shows that PEAP and TTLS both work with
	Radiator and FreeRADIUS.		Radiator and FreeRADIUS.
	Implementors have demonstrated significant interest in getting PEAP		Implementors have demonstrated significant interest in getting PEAP
	and TTLS working for TLS 1.3, but less interest in EAP-FAST and TTLS.		and TTLS working for TLS 1.3, but less interest in EAP-FAST and TEAP.
	As such, there is no implementation experience with EAP-FAST or TEAP.		As such, there is no implementation experience with EAP-FAST or TEAP.
	However, we believe that the definitions described above are correct,		However, we believe that the definitions described above are correct,
	and are workable.		and are workable.
	6. Security Considerations		6. Security Considerations
	[EAPTLS] Section 5 is included here by reference.		[RFC9190] 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 privacy 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
	skipping to change at page 13, line 48 ¶		skipping to change at page 15, line 16 ¶
	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 derivations use HMAC-SHA1 [PEAP-MPPE]. In the		For PEAP, some derivations use HMAC-SHA1 [PEAP-MPPE]. In the
	interests of interoperability and minimal changes, we do not change		interests of interoperability and minimal changes, we do not change
	that deriviation, as there are no known security issues with HMAC-		that derivation, as there are no known security issues with HMAC-
	SHA1. Further, the data derived from the HMAC-SHA1 calculations is		SHA1. Further, the data derived from the HMAC-SHA1 calculations is
	exchanged inside of the TLS tunnel, and is visible only to users who		exchanged inside of the TLS tunnel, and is visible only to users who
	have already successfully authenticated. As such, the security risks		have already successfully authenticated. As such, the security risks
	are minimal.		are minimal.
	6.1. Protected Success and Failure indicators		6.1. Protected Success and Failure indicators
	[EAPTLS] provides for protected success and failure indicators as		[RFC9190] 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 authentication, 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
	outer TLS exchange. That is, the protected result indicator is not		outer TLS exchange. That is, the protected result indicator is not
	used, and there is no TLS-layer alert sent when the inner		used, and there is no TLS-layer alert sent when the inner
	authentication fails. Instead, there is simply either an EAP-Success		authentication fails. Instead, there is simply either an EAP-Success
	or EAP-Failure sent. This behavior is the same as for previous TLS		or EAP-Failure sent. This behavior is the same as for previous TLS
	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,
	skipping to change at page 15, line 7 ¶		skipping to change at page 16, line 23 ¶
	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
	to exchange more detailed failure indicators, but the final result		to exchange more detailed failure indicators, but the final result
	MUST be a failed authentication. As noted earlier, any session		MUST be a failed authentication. As noted earlier, any session
	tickets for this failed authentication MUST be either invalidated or		tickets for this failed authentication MUST be either invalidated or
	discarded.		discarded.
	Similarly, when the inner authentication protocol indicates that		Similarly, when the inner authentication protocol indicates that
	authentication has succeeed, then implementations SHOULD cause		authentication has succeed, then implementations SHOULD cause
	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.
	skipping to change at page 16, line 34 ¶		skipping to change at page 17, line 49 ¶
	[RFC8174]		[RFC8174]
	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]		[RFC9190]
	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-18, July 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
	8.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, May 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-
	PEAP/e75b0385-915a-4fc3-a549-fd3d06b995b0		PEAP/e75b0385-915a-4fc3-a549-fd3d06b995b0
	[PEAP-PRF]		[PEAP-PRF]
	https://docs.microsoft.com/en-us/openspecs/windows_protocols/MS-		https://docs.microsoft.com/en-us/openspecs/windows_protocols/MS-
	PEAP/0de54161-0bd3-424a-9b1a-854b4040a6df		PEAP/0de54161-0bd3-424a-9b1a-854b4040a6df
	[PEAP-TK]		[PEAP-TK]
	skipping to change at page 17, line 41 ¶		skipping to change at page 19, line 10 ¶
	[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.
			[RFC5422]
			Cam-Winget, N., et al, "Dynamic Provisioning Using Flexible
			Authentication via Secure Tunneling Extensible Authentication
			Protocol (EAP-FAST)", RFC 5422, March 2009.
	[RFC7542]		[RFC7542]
	DeKoK, A, "The Network Access Identifier", RFC 7542, May 2015.		DeKoK, A, "The Network Access Identifier", RFC 7542, May 2015.
	[RFC7585]		[RFC7585]
	Winter, S, and McCauley, M., "Dynamic Peer Discovery for RADIUS/TLS		Winter, S, and McCauley, M., "Dynamic Peer Discovery for RADIUS/TLS
	and RADIUS/DTLS Based on the Network Access Identifier (NAI)", RFC		and RADIUS/DTLS Based on the Network Access Identifier (NAI)", RFC
	7585, October 2015.		7585, October 2015.
	Acknowledgments		Acknowledgments
End of changes. 54 change blocks.
	89 lines changed or deleted		158 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/