rfc9140v2.txt		rfc9140.txt
	skipping to change at line 106 ¶		skipping to change at line 106 ¶
	6.5. Downgrading Threats		6.5. Downgrading Threats
	6.6. Protected Success and Failure Indications		6.6. Protected Success and Failure Indications
	6.7. Channel Binding		6.7. Channel Binding
	6.8. Denial of Service		6.8. Denial of Service
	6.9. Recovery from Loss of Last Message		6.9. Recovery from Loss of Last Message
	6.10. Privacy Considerations		6.10. Privacy Considerations
	6.11. EAP Security Claims		6.11. EAP Security Claims
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	7.2. Informative References		7.2. Informative References
	Appendix A. Exchanges and Events Per State		Appendix A. Exchanges and Events per State
	Appendix B. Application-Specific Parameters		Appendix B. Application-Specific Parameters
	Appendix C. EAP-NOOB Roaming		Appendix C. EAP-NOOB Roaming
	Appendix D. OOB Message as a URL		Appendix D. OOB Message as a URL
	Acknowledgments		Acknowledgments
	Authors' Addresses		Authors' Addresses
	1. Introduction		1. Introduction
	This document describes a method for registration, authentication,		This document describes a method for registration, authentication,
	and key derivation for network-connected smart devices, such as		and key derivation for network-connected smart devices, such as
	skipping to change at line 795 ¶		skipping to change at line 795 ¶
	3.3.2. Message Data Fields		3.3.2. Message Data Fields
	Table 1 defines the data fields in the protocol messages. The in-		Table 1 defines the data fields in the protocol messages. The in-
	band messages are formatted as JSON objects [RFC8259] in UTF-8		band messages are formatted as JSON objects [RFC8259] in UTF-8
	encoding. The JSON member names are in the left-hand column of the		encoding. The JSON member names are in the left-hand column of the
	table.		table.
	+===============+=================================================+		+===============+=================================================+
	| Data Field | Description |		| Data Field | Description |
	+===============+=================================================+		+===============+=================================================+
	| Vers, Verp | EAP-NOOB method versions supported by the EAP |		| Vers, Verp | EAP-NOOB protocol versions supported by the EAP |
	| | server and the protocol version chosen by the |		| | server and the protocol version chosen by the |
	| | peer. Vers is a JSON array of unsigned |		| | peer. Vers is a JSON array of unsigned |
	| | integers, and Verp is an unsigned integer. |		| | integers, and Verp is an unsigned integer. |
	| | Example values are "[1]" and "1", respectively. |		| | Example values are "[1]" and "1", respectively. |
	+---------------+-------------------------------------------------+		+---------------+-------------------------------------------------+
	| PeerId | Peer identifier, as defined in Section 3.3.1. |		| PeerId | Peer identifier, as defined in Section 3.3.1. |
	+---------------+-------------------------------------------------+		+---------------+-------------------------------------------------+
	| NAI, NewNAI | Peer NAI and server-assigned new peer NAI, as |		| NAI, NewNAI | Peer NAI and server-assigned new peer NAI, as |
	| | defined in Section 3.3.1. |		| | defined in Section 3.3.1. |
	+---------------+-------------------------------------------------+		+---------------+-------------------------------------------------+
	skipping to change at line 942 ¶		skipping to change at line 942 ¶
	Table 1: Message Data Fields		Table 1: Message Data Fields
	It is RECOMMENDED for servers to support both OOB channel directions		It is RECOMMENDED for servers to support both OOB channel directions
	(Dirs=3) unless the type of the OOB channel limits them to one		(Dirs=3) unless the type of the OOB channel limits them to one
	direction (Dirs=1 or Dirs=2). On the other hand, it is RECOMMENDED		direction (Dirs=1 or Dirs=2). On the other hand, it is RECOMMENDED
	that the peer selects only one direction (Dirp=1 or Dirp=2) even when		that the peer selects only one direction (Dirp=1 or Dirp=2) even when
	both directions (Dirp=3) would be technically possible. The reason		both directions (Dirp=3) would be technically possible. The reason
	is that, if value 3 is negotiated, the user may be presented with two		is that, if value 3 is negotiated, the user may be presented with two
	OOB messages, one for each direction, even though only one of them		OOB messages, one for each direction, even though only one of them
	needs to be delivered. This can be confusing to the user.		needs to be delivered. This can be confusing to the user.
	Nevertheless, the EAP-NOOB method is designed to also cope with the		Nevertheless, the EAP-NOOB protocol is designed to also cope with the
	value 3; in which case, it uses the first delivered OOB message. In		value 3; in which case, it uses the first delivered OOB message. In
	the unlikely case of simultaneously delivered OOB messages, the		the unlikely case of simultaneously delivered OOB messages, the
	protocol prioritizes the server-to-peer direction.		protocol prioritizes the server-to-peer direction.
	The nonces in the in-band messages (Ns, Np, Ns2, Np2) are 32-byte		The nonces in the in-band messages (Ns, Np, Ns2, Np2) are 32-byte
	fresh random byte strings, and the secret nonce Noob is a 16-byte		fresh random byte strings, and the secret nonce Noob is a 16-byte
	fresh random byte string. All the nonces are generated by the		fresh random byte string. All the nonces are generated by the
	endpoint that sends the message.		endpoint that sends the message.
	The fingerprint Hoob and the identifier NoobId are computed with the		The fingerprint Hoob and the identifier NoobId are computed with the
	skipping to change at line 1915 ¶		skipping to change at line 1915 ¶
	Table 12: PeerInfo Data Fields		Table 12: PeerInfo Data Fields
	Assignment of new values for new PeerInfo data fields MUST be done		Assignment of new values for new PeerInfo data fields MUST be done
	through IANA with "Specification Required", as defined in [RFC8126].		through IANA with "Specification Required", as defined in [RFC8126].
	5.6. Domain Name Reservation		5.6. Domain Name Reservation
	The special-use domain "eap-noob.arpa" has been registered in the		The special-use domain "eap-noob.arpa" has been registered in the
	.arpa registry (https://www.iana.org/domains/arpa) and the "Special-		.arpa registry (https://www.iana.org/domains/arpa) and the "Special-
	Use Domain Names" registry (https://www.iana.org/assignments/special-		Use Domain Names" registry (https://www.iana.org/assignments/special-
	use-domain-names). No A, AAAA, or PTR records are requested.		use-domain-names).
	5.7. Guidance for Designated Experts		5.7. Guidance for Designated Experts
	Experts SHOULD be conservative in the allocation of new Cryptosuites.		Experts SHOULD be conservative in the allocation of new Cryptosuites.
	Experts MUST ascertain that the requested values match the current		Experts MUST ascertain that the requested values match the current
	Crypto Forum Research Group (CFRG) guidance on cryptographic		Crypto Forum Research Group (CFRG) guidance on cryptographic
	algorithm security. Experts MUST ensure that any new Cryptosuites		algorithm security. Experts MUST ensure that any new Cryptosuites
	fully specify the encoding of the ECDHE public key and should include		fully specify the encoding of the ECDHE public key and should include
	details, such as the value of the "kty" (key type) parameter when JWK		details, such as the value of the "kty" (key type) parameter when JWK
	[RFC7517] encoding is used.		[RFC7517] encoding is used.
	skipping to change at line 2410 ¶		skipping to change at line 2410 ¶
	identifiers and other information about the peer device (see		identifiers and other information about the peer device (see
	Table 6). While the information refers to the peer device and not		Table 6). While the information refers to the peer device and not
	directly to the user, it can leak information about the user to the		directly to the user, it can leak information about the user to the
	access network and to outside observers. The ServerInfo, on the		access network and to outside observers. The ServerInfo, on the
	other hand, can leak information about the peer's affiliation with		other hand, can leak information about the peer's affiliation with
	the home network. For this reason, the optional PeerInfo and		the home network. For this reason, the optional PeerInfo and
	ServerInfo in the Reconnect Exchange SHOULD be omitted unless some		ServerInfo in the Reconnect Exchange SHOULD be omitted unless some
	critical data has changed and it cannot be updated on the application		critical data has changed and it cannot be updated on the application
	layer.		layer.
	Peer devices that randomize their layer-2 address to prevent tracking		Peer devices that randomize their Layer 2 address to prevent tracking
	can do this whenever the user resets the EAP-NOOB association.		can do this whenever the user resets the EAP-NOOB association.
	During the lifetime of the association, the PeerId is a unique		During the lifetime of the association, the PeerId is a unique
	identifier that can be used to track the peer in the access network.		identifier that can be used to track the peer in the access network.
	Later versions of this specification may consider updating the PeerId		Later versions of this specification may consider updating the PeerId
	at each Reconnect Exchange. In that case, it is necessary to		at each Reconnect Exchange. In that case, it is necessary to
	consider how the authenticator and access-network administrators can		consider how the authenticator and access-network administrators can
	recognize and add misbehaving peer devices to a deny list, as well as		recognize and add misbehaving peer devices to a deny list, as well as
	how to avoid loss of synchronization between the server and the peer		how to avoid loss of synchronization between the server and the peer
	if messages are lost during the identifier update.		if messages are lost during the identifier update.
	skipping to change at line 2638 ¶		skipping to change at line 2638 ¶
	DOI 10.1145/3321705.3329813, February 2019,		DOI 10.1145/3321705.3329813, February 2019,
	<https://arxiv.org/abs/1902.07550>.		<https://arxiv.org/abs/1902.07550>.
	[TLS-CWT] Tschofenig, H. and M. Brossard, "Using CBOR Web Tokens		[TLS-CWT] Tschofenig, H. and M. Brossard, "Using CBOR Web Tokens
	(CWTs) in Transport Layer Security (TLS) and Datagram		(CWTs) in Transport Layer Security (TLS) and Datagram
	Transport Layer Security (DTLS)", Work in Progress,		Transport Layer Security (DTLS)", Work in Progress,
	Internet-Draft, draft-tschofenig-tls-cwt-02, 13 July 2020,		Internet-Draft, draft-tschofenig-tls-cwt-02, 13 July 2020,
	<https://datatracker.ietf.org/doc/html/draft-tschofenig-		<https://datatracker.ietf.org/doc/html/draft-tschofenig-
	tls-cwt-02>.		tls-cwt-02>.
	Appendix A. Exchanges and Events Per State		Appendix A. Exchanges and Events per State
	Table 14 shows how the EAP server chooses the exchange type depending		Table 14 shows how the EAP server chooses the exchange type depending
	on the server and peer states. In the state combinations marked with		on the server and peer states. In the state combinations marked with
	hyphen "-", there is no possible exchange and user action is required		hyphen "-", there is no possible exchange and user action is required
	to make progress. Note that peer state 4 is omitted from the table		to make progress. Note that peer state 4 is omitted from the table
	because the peer never connects to the server when the peer is in		because the peer never connects to the server when the peer is in
	that state. The table also shows the handling of errors in each		that state. The table also shows the handling of errors in each
	exchange. A notable detail is that the recipient of error code 2003		exchange. A notable detail is that the recipient of error code 2003
	moves to state 1.		moves to state 1.
	+=============+===============================+==================+		+=============+===============================+==================+
	| Peer States | Exchange Chosen By the Server | Next Peer and |		| Peer States | Exchange Chosen by the Server | Next Peer and |
	| | | Server States |		| | | Server States |
	+=============+===============================+==================+		+=============+===============================+==================+
	| Server State: Unregistered (0) |		| Server State: Unregistered (0) |
	+-------------+-------------------------------+------------------+		+-------------+-------------------------------+------------------+
	| 0..2 | Initial Exchange | both 1 (0 on |		| 0..2 | Initial Exchange | both 1 (0 on |
	| | | error) |		| | | error) |
	+-------------+-------------------------------+------------------+		+-------------+-------------------------------+------------------+
	| 3 | - | no change, |		| 3 | - | no change, |
	| | | notify user |		| | | notify user |
	+-------------+-------------------------------+------------------+		+-------------+-------------------------------+------------------+
	skipping to change at line 2674 ¶		skipping to change at line 2674 ¶
	| | | error) |		| | | error) |
	+-------------+-------------------------------+------------------+		+-------------+-------------------------------+------------------+
	| 1 | Waiting Exchange | both 1 (no |		| 1 | Waiting Exchange | both 1 (no |
	| | | change on error) |		| | | change on error) |
	+-------------+-------------------------------+------------------+		+-------------+-------------------------------+------------------+
	| 2 | Completion Exchange | both 4 (A) |		| 2 | Completion Exchange | both 4 (A) |
	+-------------+-------------------------------+------------------+		+-------------+-------------------------------+------------------+
	| 3 | - | no change, |		| 3 | - | no change, |
	| | | notify user |		| | | notify user |
	+-------------+-------------------------------+------------------+		+-------------+-------------------------------+------------------+
	| /server State: OOB Received (2) |		| Server State: OOB Received (2) |
	+-------------+-------------------------------+------------------+		+-------------+-------------------------------+------------------+
	| 0 | Initial Exchange | both 1 (0 on |		| 0 | Initial Exchange | both 1 (0 on |
	| | | error) |		| | | error) |
	+-------------+-------------------------------+------------------+		+-------------+-------------------------------+------------------+
	| 1 | Completion Exchange | both 4 (B) |		| 1 | Completion Exchange | both 4 (B) |
	+-------------+-------------------------------+------------------+		+-------------+-------------------------------+------------------+
	| 2 | Completion Exchange | both 4 (A) |		| 2 | Completion Exchange | both 4 (A) |
	+-------------+-------------------------------+------------------+		+-------------+-------------------------------+------------------+
	| 3 | - | no change, |		| 3 | - | no change, |
	| | | notify user |		| | | notify user |
End of changes. 8 change blocks.
	8 lines changed or deleted		8 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/