Diff: rfc9965v3.txt - rfc9965.txt

	rfc9965v3.txt	rfc9965.txt

	skipping to change at line 272 ¶	skipping to change at line 272 ¶
	requested methods to be distinguished. The subdomain in the realm	requested methods to be distinguished. The subdomain in the realm
	field is assigned via the "EAP Provisioning Identifiers" registry	field is assigned via the "EAP Provisioning Identifiers" registry
	[EAPREG], which is defined in Section 5.2. The subdomain MUST follow	[EAPREG], which is defined in Section 5.2. The subdomain MUST follow
	the syntax defined in [RFC7542], Section 2.2, which is a more	the syntax defined in [RFC7542], Section 2.2, which is a more
	restrictive subset of the domain name conventions specified in	restrictive subset of the domain name conventions specified in
	[STD13].	[STD13].

	Where possible, the first subdomain of the eap.arpa. domain SHOULD	Where possible, the first subdomain of the eap.arpa. domain SHOULD
	use the EAP method name, as defined in the "Extensible Authentication	use the EAP method name, as defined in the "Extensible Authentication
	Protocol (EAP) Registry" registry group, "Method Types" registry.	Protocol (EAP) Registry" registry group, "Method Types" registry.

	However, the names in the "EAP Method Type" registry [EAP-METHOD] do	However, the names in the "EAP Method Type" registry [EAPREG] do not
	not follow the domain name formats specified in [STD13], so it is not	follow the domain name formats specified in [STD13], so it is not
	always possible to make a one-to-one mapping between the Method Type	always possible to make a one-to-one mapping between the Method Type
	name and a subdomain of the eap.arpa. domain.	name and a subdomain of the eap.arpa. domain.

	Where it is not possible to make a direct mapping between the EAP	Where it is not possible to make a direct mapping between the EAP
	Method Type name due to the EAP Method Type name not matching the	Method Type name due to the EAP Method Type name not matching the
	[RFC7542], Section 2.2 format, the NAI that is defined in the "EAP	[RFC7542], Section 2.2 format, the NAI that is defined in the "EAP
	Provisioning Identifiers" registry MUST use a realm name that is	Provisioning Identifiers" registry MUST use a realm name that is
	similar enough to allow the average reader to understand which EAP	similar enough to allow the average reader to understand which EAP
	Method Type is being used.	Method Type is being used.


	skipping to change at line 590 ¶	skipping to change at line 590 ¶
	authentication method, the credentials used there SHOULD be the	authentication method, the credentials used there SHOULD be the
	provisioning identifier for both the inner identity and any inner	provisioning identifier for both the inner identity and any inner
	password.	password.

	It is RECOMMENDED that provisioning be done via a TLS-based EAP	It is RECOMMENDED that provisioning be done via a TLS-based EAP
	method. TLS provides for authentication of the EAP server along with	method. TLS provides for authentication of the EAP server along with
	integrity and confidentiality protection for any provisioning data	integrity and confidentiality protection for any provisioning data
	exchanged in the tunnel. Similarly, if provisioning is done in a	exchanged in the tunnel. Similarly, if provisioning is done in a
	captive portal outside of EAP, EAP-TLS permits the EAP peer to run a	captive portal outside of EAP, EAP-TLS permits the EAP peer to run a
	full EAP authentication session while having nothing more than a few	full EAP authentication session while having nothing more than a few

	Certificate Authorities (CAs) locally configured.	Certification Authorities (CAs) locally configured.

	4.1. High Level Requirements	4.1. High Level Requirements

	All provisioning methods that are specified within the	All provisioning methods that are specified within the
	eap.arpa. domain MUST define a way to authenticate the server. This	eap.arpa. domain MUST define a way to authenticate the server. This
	authentication can happen either at the EAP layer (as with TLS-based	authentication can happen either at the EAP layer (as with TLS-based
	EAP methods) or after network access has been granted (if credentials	EAP methods) or after network access has been granted (if credentials
	are provisioned over HTTPS).	are provisioned over HTTPS).

	Where TLS-based EAP methods are used, implementations MUST still	Where TLS-based EAP methods are used, implementations MUST still

	skipping to change at line 627 ¶	skipping to change at line 627 ¶
	However, since the device is likely otherwise configured with web CAs	However, since the device is likely otherwise configured with web CAs
	[CAB], the captive portal would also be unauthenticated provisioning	[CAB], the captive portal would also be unauthenticated provisioning
	methods could use those CAs within an EAP method in order to allow	methods could use those CAs within an EAP method in order to allow
	the peer to authenticate the EAP server. Further discussion of this	the peer to authenticate the EAP server. Further discussion of this
	topic is better suited for the specification(s) that define a	topic is better suited for the specification(s) that define a
	particular provisioning method. This issue is not discussed further	particular provisioning method. This issue is not discussed further
	here, other than to say that it is technically possible.	here, other than to say that it is technically possible.

	4.2. EAP-TLS	4.2. EAP-TLS


	This document defines an NAI called "portal@tls.eap.arpa", which	This document defines an NAI "portal@tls.eap.arpa", which allows EAP
	allows EAP peers to use unauthenticated EAP-TLS. The purpose of the	peers to use unauthenticated EAP-TLS. The purpose of the identifier
	identifier is to allow EAP peers to signal to EAP servers that they	is to allow EAP peers to signal to EAP servers that they wish to
	wish to obtain "captive portal" network access.	obtain "captive portal" network access.

	This identifier signals to the EAP server that the peer wishes to	This identifier signals to the EAP server that the peer wishes to
	obtain "peer unauthenticated access" as per [RFC5216], Section 2.1.1	obtain "peer unauthenticated access" as per [RFC5216], Section 2.1.1
	and [RFC9190]. Note that peer unauthenticated access MUST provide	and [RFC9190]. Note that peer unauthenticated access MUST provide
	for authentication of the EAP server, such as with a server	for authentication of the EAP server, such as with a server
	certificate. Using TLS-PSK with a well-known Pre-Shared Key (PSK)	certificate. Using TLS-PSK with a well-known Pre-Shared Key (PSK)
	value is generally not appropriate, as it would not provide server	value is generally not appropriate, as it would not provide server
	authentication.	authentication.

	An EAP server that agrees to authenticate this request MUST ensure	An EAP server that agrees to authenticate this request MUST ensure

	skipping to change at line 1043 ¶	skipping to change at line 1043 ¶
	November 1987, <https://www.rfc-editor.org/info/rfc1035>.	November 1987, <https://www.rfc-editor.org/info/rfc1035>.

	8.2. Informative References	8.2. Informative References

	[ARPAREG] IANA, ".ARPA Zone Management",	[ARPAREG] IANA, ".ARPA Zone Management",
	<https://www.iana.org/domains/arpa>.	<https://www.iana.org/domains/arpa>.

	[CAB] CA/Browser Forum, "CA/Browser Forum",	[CAB] CA/Browser Forum, "CA/Browser Forum",
	<https://cabforum.org/>.	<https://cabforum.org/>.


	[EAP-METHOD]
	IANA, "Extensible Authentication Protocol (EAP) Registry",
	<https://www.iana.org/assignments/eap-numbers>.

	[EAPREG] IANA, "Extensible Authentication Protocol (EAP) Registry",	[EAPREG] IANA, "Extensible Authentication Protocol (EAP) Registry",
	<https://www.iana.org/assignments/eap-numbers>.	<https://www.iana.org/assignments/eap-numbers>.

	[HOTSPOT] Wi-Fi Alliance, "Passpoint",	[HOTSPOT] Wi-Fi Alliance, "Passpoint",
	<https://www.wi-fi.org/discover-wi-fi/passpoint>.	<https://www.wi-fi.org/discover-wi-fi/passpoint>.

	[IEEE802.11u]	[IEEE802.11u]
	IEEE, "IEEE Standard for Information Technology -	IEEE, "IEEE Standard for Information Technology -
	Telecommunications and information exchange between	Telecommunications and information exchange between
	systems - Local and Metropolitan networks-specific	systems - Local and Metropolitan networks-specific
	requirements - Part II: Wireless LAN Medium Access Control	requirements - Part II: Wireless LAN Medium Access Control
	(MAC) and Physical Layer (PHY) specifications: Amendment	(MAC) and Physical Layer (PHY) specifications: Amendment
	9: Interworking with External Networks", IEEE Std 802.11u-	9: Interworking with External Networks", IEEE Std 802.11u-
	2011, DOI 10.1109/IEEESTD.2011.5721908, 2011,	2011, DOI 10.1109/IEEESTD.2011.5721908, 2011,
	<https://ieeexplore.ieee.org/document/5721908>.	<https://ieeexplore.ieee.org/document/5721908>.

	[IEEE802.1X]	[IEEE802.1X]
	IEEE, "IEEE Standard for Local and metropolitan area	IEEE, "IEEE Standard for Local and metropolitan area
	networks--Port-Based Network Access Control", IEEE Std	networks--Port-Based Network Access Control", IEEE Std

	802.1X-2010, DOI 10.1109/IEEESTD.2010.5409813, 2010,	802.1X-2020, DOI 10.1109/IEEESTD.2020.9018454, 2020,
	<https://ieeexplore.ieee.org/document/5409813>.	<https://ieeexplore.ieee.org/document/5409813>.

	[INSECURE-RADIUS]	[INSECURE-RADIUS]
	DeKok, A., "Deprecating Insecure Practices in RADIUS",	DeKok, A., "Deprecating Insecure Practices in RADIUS",
	Work in Progress, Internet-Draft, draft-ietf-radext-	Work in Progress, Internet-Draft, draft-ietf-radext-
	deprecating-radius-09, 15 March 2026,	deprecating-radius-09, 15 March 2026,
	<https://datatracker.ietf.org/doc/html/draft-ietf-radext-	<https://datatracker.ietf.org/doc/html/draft-ietf-radext-
	deprecating-radius-09>.	deprecating-radius-09>.

	[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,	[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,

End of changes. 5 change blocks.
	12 lines changed or deleted	8 lines changed or added
This html diff was produced by rfcdiff 1.48.