< draft-ietf-emu-eap-noob-02.txt		draft-ietf-emu-eap-noob-03.txt >
	Network Working Group T. Aura		Network Working Group T. Aura
	Internet-Draft Aalto University		Internet-Draft Aalto University
	Intended status: Standards Track M. Sethi		Intended status: Standards Track M. Sethi
	Expires: January 13, 2021 Ericsson		Expires: June 16, 2021 Ericsson
	July 12, 2020		A. Peltonen
			Aalto University
			December 13, 2020
	Nimble out-of-band authentication for EAP (EAP-NOOB)		Nimble out-of-band authentication for EAP (EAP-NOOB)
	draft-ietf-emu-eap-noob-02		draft-ietf-emu-eap-noob-03
	Abstract		Abstract
	The Extensible Authentication Protocol (EAP) provides support for		The Extensible Authentication Protocol (EAP) provides support for
	multiple authentication methods. This document defines the EAP-NOOB		multiple authentication methods. This document defines the EAP-NOOB
	authentication method for nimble out-of-band (OOB) authentication and		authentication method for nimble out-of-band (OOB) authentication and
	key derivation. The EAP method is intended for bootstrapping all		key derivation. The EAP method is intended for bootstrapping all
	kinds of Internet-of-Things (IoT) devices that have no pre-configured		kinds of Internet-of-Things (IoT) devices that have no pre-configured
	authentication credentials. The method makes use of a user-assisted		authentication credentials. The method makes use of a user-assisted
	one-directional OOB message between the peer device and		one-directional OOB message between the peer device and
	authentication server to authenticate the in-band key exchange. The		authentication server to authenticate the in-band key exchange. The
	device must have an input or output interface, such as a display,		device must have an input or output interface, such as a display,
	microphone, speakers or blinking light, which can send or receive		microphone, speaker or blinking light, which can send or receive
	dynamically generated messages of tens of bytes in length.		dynamically generated messages of tens of bytes in length.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted 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). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on January 13, 2021.		This Internet-Draft will expire on June 16, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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
	skipping to change at page 2, line 25 ¶		skipping to change at page 2, line 28 ¶
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. EAP-NOOB protocol . . . . . . . . . . . . . . . . . . . . . . 5		3. EAP-NOOB protocol . . . . . . . . . . . . . . . . . . . . . . 5
	3.1. Protocol overview . . . . . . . . . . . . . . . . . . . . 5		3.1. Protocol overview . . . . . . . . . . . . . . . . . . . . 5
	3.2. Protocol messages and sequences . . . . . . . . . . . . . 8		3.2. Protocol messages and sequences . . . . . . . . . . . . . 8
	3.2.1. Common handshake in all EAP-NOOB exchanges . . . . . 8		3.2.1. Common handshake in all EAP-NOOB exchanges . . . . . 8
	3.2.2. Initial Exchange . . . . . . . . . . . . . . . . . . 10		3.2.2. Initial Exchange . . . . . . . . . . . . . . . . . . 10
	3.2.3. OOB Step . . . . . . . . . . . . . . . . . . . . . . 11		3.2.3. OOB Step . . . . . . . . . . . . . . . . . . . . . . 11
	3.2.4. Completion Exchange . . . . . . . . . . . . . . . . . 13		3.2.4. Completion Exchange . . . . . . . . . . . . . . . . . 13
	3.2.5. Waiting Exchange . . . . . . . . . . . . . . . . . . 15		3.2.5. Waiting Exchange . . . . . . . . . . . . . . . . . . 15
	3.3. Protocol data fields . . . . . . . . . . . . . . . . . . 16		3.3. Protocol data fields . . . . . . . . . . . . . . . . . . 16
	3.3.1. Peer identifier, realm and NAI . . . . . . . . . . . 16		3.3.1. Peer identifier and NAI . . . . . . . . . . . . . . . 16
	3.3.2. Message data fields . . . . . . . . . . . . . . . . . 18		3.3.2. Message data fields . . . . . . . . . . . . . . . . . 18
	3.4. Fast reconnect and rekeying . . . . . . . . . . . . . . . 23		3.4. Fast reconnect and rekeying . . . . . . . . . . . . . . . 23
	3.4.1. Persistent EAP-NOOB association . . . . . . . . . . . 23		3.4.1. Persistent EAP-NOOB association . . . . . . . . . . . 23
	3.4.2. Reconnect Exchange . . . . . . . . . . . . . . . . . 24		3.4.2. Reconnect Exchange . . . . . . . . . . . . . . . . . 24
	3.4.3. User reset . . . . . . . . . . . . . . . . . . . . . 27		3.4.3. User reset . . . . . . . . . . . . . . . . . . . . . 27
	3.5. Key derivation . . . . . . . . . . . . . . . . . . . . . 28		3.5. Key derivation . . . . . . . . . . . . . . . . . . . . . 28
	3.6. Error handling . . . . . . . . . . . . . . . . . . . . . 31		3.6. Error handling . . . . . . . . . . . . . . . . . . . . . 31
	3.6.1. Invalid messages . . . . . . . . . . . . . . . . . . 33		3.6.1. Invalid messages . . . . . . . . . . . . . . . . . . 33
	3.6.2. Unwanted peer . . . . . . . . . . . . . . . . . . . . 33		3.6.2. Unwanted peer . . . . . . . . . . . . . . . . . . . . 33
	3.6.3. State mismatch . . . . . . . . . . . . . . . . . . . 33		3.6.3. State mismatch . . . . . . . . . . . . . . . . . . . 33
	skipping to change at page 2, line 47 ¶		skipping to change at page 2, line 50 ¶
	3.6.5. Cryptographic verification failure . . . . . . . . . 34		3.6.5. Cryptographic verification failure . . . . . . . . . 34
	3.6.6. Application-specific failure . . . . . . . . . . . . 34		3.6.6. Application-specific failure . . . . . . . . . . . . 34
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
	4.1. Cryptosuites . . . . . . . . . . . . . . . . . . . . . . 35		4.1. Cryptosuites . . . . . . . . . . . . . . . . . . . . . . 35
	4.2. Message Types . . . . . . . . . . . . . . . . . . . . . . 36		4.2. Message Types . . . . . . . . . . . . . . . . . . . . . . 36
	4.3. Error codes . . . . . . . . . . . . . . . . . . . . . . . 36		4.3. Error codes . . . . . . . . . . . . . . . . . . . . . . . 36
	4.4. Domain name reservation considerations . . . . . . . . . 37		4.4. Domain name reservation considerations . . . . . . . . . 37
	5. Implementation Status . . . . . . . . . . . . . . . . . . . . 38		5. Implementation Status . . . . . . . . . . . . . . . . . . . . 38
	5.1. Implementation with wpa_supplicant and hostapd . . . . . 38		5.1. Implementation with wpa_supplicant and hostapd . . . . . 38
	5.2. Implementation on Contiki . . . . . . . . . . . . . . . . 39		5.2. Implementation on Contiki . . . . . . . . . . . . . . . . 39
	5.3. Protocol modeling . . . . . . . . . . . . . . . . . . . . 39		5.3. Implementation with wpa_supplicant and hostapd . . . . . 39
	6. Security considerations . . . . . . . . . . . . . . . . . . . 39		5.4. Protocol modeling . . . . . . . . . . . . . . . . . . . . 39
	6.1. Authentication principle . . . . . . . . . . . . . . . . 39		6. Security considerations . . . . . . . . . . . . . . . . . . . 40
	6.2. Cloning of Devices . . . . . . . . . . . . . . . . . . . 41		6.1. Authentication principle . . . . . . . . . . . . . . . . 40
	6.3. Identifying correct endpoints . . . . . . . . . . . . . . 41		6.2. Identifying correct endpoints . . . . . . . . . . . . . . 41
	6.4. Trusted path issues and misbinding attacks . . . . . . . 42		6.3. Trusted path issues and misbinding attacks . . . . . . . 43
	6.5. Peer identifiers and attributes . . . . . . . . . . . . . 43		6.4. Peer identifiers and attributes . . . . . . . . . . . . . 43
	6.6. Identity protection . . . . . . . . . . . . . . . . . . . 44		6.5. Identity protection . . . . . . . . . . . . . . . . . . . 44
	6.7. Downgrading threats . . . . . . . . . . . . . . . . . . . 44		6.6. Downgrading threats . . . . . . . . . . . . . . . . . . . 45
	6.8. Recovery from loss of last message . . . . . . . . . . . 45		6.7. Recovery from loss of last message . . . . . . . . . . . 46
	6.9. EAP security claims . . . . . . . . . . . . . . . . . . . 46		6.8. EAP security claims . . . . . . . . . . . . . . . . . . . 47
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 48		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 49
	7.1. Normative references . . . . . . . . . . . . . . . . . . 48		7.1. Normative references . . . . . . . . . . . . . . . . . . 49
	7.2. Informative references . . . . . . . . . . . . . . . . . 49		7.2. Informative references . . . . . . . . . . . . . . . . . 50
	Appendix A. Exchanges and events per state . . . . . . . . . . . 52		Appendix A. Exchanges and events per state . . . . . . . . . . . 53
	Appendix B. Application-specific parameters . . . . . . . . . . 53		Appendix B. Application-specific parameters . . . . . . . . . . 54
	Appendix C. ServerInfo and PeerInfo contents . . . . . . . . . . 54		Appendix C. ServerInfo and PeerInfo contents . . . . . . . . . . 55
	Appendix D. EAP-NOOB roaming . . . . . . . . . . . . . . . . . . 56		Appendix D. EAP-NOOB roaming . . . . . . . . . . . . . . . . . . 57
	Appendix E. OOB message as URL . . . . . . . . . . . . . . . . . 57		Appendix E. OOB message as URL . . . . . . . . . . . . . . . . . 58
	Appendix F. Example messages . . . . . . . . . . . . . . . . . . 58		Appendix F. Example messages . . . . . . . . . . . . . . . . . . 59
	Appendix G. TODO list . . . . . . . . . . . . . . . . . . . . . 62		Appendix G. Version history . . . . . . . . . . . . . . . . . . 63
	Appendix H. Version history . . . . . . . . . . . . . . . . . . 62		Appendix H. Acknowledgments . . . . . . . . . . . . . . . . . . 66
	Appendix I. Acknowledgments . . . . . . . . . . . . . . . . . . 65		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 67
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 66
	1. Introduction		1. Introduction
	This document describes a method for registration, authentication and		This document describes a method for registration, authentication and
	key derivation for network-connected ubiquitous computing devices,		key derivation for network-connected ubiquitous computing devices,
	such as consumer and enterprise appliances that are part of the		such as consumer and enterprise appliances that are part of the
	Internet of Things (IoT). These devices may be off-the-shelf		Internet of Things (IoT). These devices may be off-the-shelf
	hardware that is sold and distributed without any prior registration		hardware that is sold and distributed without any prior registration
	or credential-provisioning process, or they may be recycled devices		or credential-provisioning process, or they may be recycled devices
	after a hard reset. Thus, the device registration in a server		after a hard reset. Thus, the device registration in a server
	skipping to change at page 4, line 31 ¶		skipping to change at page 4, line 34 ¶
	an input or output interface, such as a camera, microphone, display		an input or output interface, such as a camera, microphone, display
	screen, speakers or blinking LED light, which is able to send or		screen, speakers or blinking LED light, which is able to send or
	receive dynamically generated messages of tens of bytes in length.		receive dynamically generated messages of tens of bytes in length.
	Naturally, this solution may not be appropriate for very small		Naturally, this solution may not be appropriate for very small
	sensors or actuators that have no user interface at all or for		sensors or actuators that have no user interface at all or for
	devices that are inaccessible to the user. We also assume that the		devices that are inaccessible to the user. We also assume that the
	OOB channel is at least partly automated (e.g., camera scanning a bar		OOB channel is at least partly automated (e.g., camera scanning a bar
	code) and, thus, there is no need to absolutely minimize the length		code) and, thus, there is no need to absolutely minimize the length
	of the data transferred through the OOB channel. This differs, for		of the data transferred through the OOB channel. This differs, for
	example, from Bluetooth simple pairing [BluetoothPairing], where it		example, from Bluetooth simple pairing [BluetoothPairing], where it
	is critical to minimize the length of the manually transferred or		is essential to minimize the length of the manually transferred or
	compared codes. The OOB messages in this specification are		compared codes. The OOB messages in this specification are
	dynamically generated. We thus do not support static printed		dynamically generated. We thus do not support static printed
	registration codes. One reason for requiring dynamic OOB messages is		registration codes. One reason for requiring dynamic OOB messages is
	that the receipt of the OOB message authorizes the server to take		that the receipt of the OOB message authorizes the server to take
	ownership of the device. This is more secure than a static printed		ownership of the device. This is more secure than a static printed
	code, which could be leaked and later misused.		code, which could be leaked and later misused.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	skipping to change at page 7, line 47 ¶		skipping to change at page 7, line 47 ¶
	way to recover is that the user also resets the peer.		way to recover is that the user also resets the peer.
	A special feature of the EAP-NOOB method is that the server is not		A special feature of the EAP-NOOB method is that the server is not
	assumed to have any a-priori knowledge of the peer. Therefore, the		assumed to have any a-priori knowledge of the peer. Therefore, the
	peer initially uses the generic identity string "noob@eap-noob.arpa"		peer initially uses the generic identity string "noob@eap-noob.arpa"
	as its network access identifier (NAI). The server then allocates a		as its network access identifier (NAI). The server then allocates a
	server-specific identifier to the peer. The generic NAI serves two		server-specific identifier to the peer. The generic NAI serves two
	purposes: firstly, it tells the server that the peer supports and		purposes: firstly, it tells the server that the peer supports and
	expects the EAP-NOOB method and, secondly, it allows routing of the		expects the EAP-NOOB method and, secondly, it allows routing of the
	EAP-NOOB sessions to a specific authentication server in an		EAP-NOOB sessions to a specific authentication server in an
	Authentication, Authorization, Accounting (AAA) architecture.		Authentication, Authorization and Accounting (AAA) architecture.
	EAP-NOOB is an unusual EAP method in that the peer has to have		EAP-NOOB is an unusual EAP method in that the peer has to have
	multiple EAP conversations with the server before it can receive EAP-		multiple EAP conversations with the server before it can receive EAP-
	Success. The reason is that, while EAP allows delays between the		Success. The reason is that, while EAP allows delays between the
	request-response pairs, e.g. for repeated password entry, the user		request-response pairs, e.g., for repeated password entry, the user
	delays in OOB authentication can be much longer than in password		delays in OOB authentication can be much longer than in password
	trials. Moreover, EAP-NOOB supports peers with no input capability		trials. Moreover, EAP-NOOB supports peers with no input capability
	in the user interface (e.g., LED light bulbs). Since users cannot		in the user interface (e.g., LED light bulbs). Since users cannot
	initiate the protocol in these devices, they have to perform the		initiate the protocol in these devices, the devices have to perform
	Initial Exchange opportunistically and hope for the OOB Step to take		the Initial Exchange opportunistically and hope for the OOB Step to
	place within a timeout period (NoobTimeout), which is why the timeout		take place within a timeout period (NoobTimeout), which is why the
	needs to be several minutes rather than seconds. To support such		timeout needs to be several minutes rather than seconds. To support
	high-latency OOB channels, the peer and server perform the Initial		such high-latency OOB channels, the peer and server perform the
	Exchange in one EAP conversation, then allow time for the OOB message		Initial Exchange in one EAP conversation, then allow time for the OOB
	to be delivered, and later perform the Waiting and Completion		message to be delivered, and later perform the Waiting and Completion
	Exchanges in different EAP conversations.		Exchanges in different EAP conversations.
	3.2. Protocol messages and sequences		3.2. Protocol messages and sequences
	This section defines the EAP-NOOB exchanges, which correspond to EAP		This section defines the EAP-NOOB exchanges, which correspond to EAP
	conversations. The exchanges start with a common handshake, which		conversations. The exchanges start with a common handshake, which
	determines the type of the following exchange. The common handshake		determines the type of the following exchange. The common handshake
	messages and the subsequent messages for each exchange type are		messages and the subsequent messages for each exchange type are
	listed in the diagrams below. The diagrams also specify the data		listed in the diagrams below. The diagrams also specify the data
	fields present in each message. Each exchange comprises multiple EAP		fields present in each message. Each exchange comprises multiple EAP
	request-response pairs and ends in either EAP-Failure, indicating		request-response pairs and ends in either EAP-Failure, indicating
	that authentication is not (yet) successful, or in EAP-Success.		that authentication is not (yet) successful, or in EAP-Success.
	3.2.1. Common handshake in all EAP-NOOB exchanges		3.2.1. Common handshake in all EAP-NOOB exchanges
	All EAP-NOOB exchanges start with common handshake messages. The		All EAP-NOOB exchanges start with common handshake messages. The
	handshake starts with the identity request and response that are		handshake begins with the identity request and response that are
	common to all EAP methods. Their purpose is to enable the AAA		common to all EAP methods. Their purpose is to enable the AAA
	architecture to route the EAP conversation to the EAP server and to		architecture to route the EAP conversation to the EAP server and to
	enable the EAP server to select the EAP method. The handshake then		enable the EAP server to select the EAP method. The handshake then
	continues with one EAP-NOOB request-response pair in which the server		continues with one EAP-NOOB request-response pair in which the server
	discovers the peer identifier used in EAP-NOOB and the peer state.		discovers the peer identifier used in EAP-NOOB and the peer state.
	In more detail, each EAP-NOOB exchange begins with the authenticator		In more detail, each EAP-NOOB exchange begins with the authenticator
	sending an EAP-Request/Identity packet to the peer. From this point		sending an EAP-Request/Identity packet to the peer. From this point
	on, the EAP conversation occurs between the server and the peer, and		on, the EAP conversation occurs between the server and the peer, and
	the authenticator acts as a pass-through device. The peer responds		the authenticator acts as a pass-through device. The peer responds
	skipping to change at page 9, line 10 ¶		skipping to change at page 9, line 10 ¶
	The AAA architecture routes the conversation to a specific AAA server		The AAA architecture routes the conversation to a specific AAA server
	(called "EAP server" or simply "server" in this specification) based		(called "EAP server" or simply "server" in this specification) based
	on the realm part of the NAI. The server selects the EAP-NOOB method		on the realm part of the NAI. The server selects the EAP-NOOB method
	based on the user part of the NAI, as defined in Section 3.3.1.		based on the user part of the NAI, as defined in Section 3.3.1.
	After receiving the EAP-Response/Identity message, the server sends		After receiving the EAP-Response/Identity message, the server sends
	the first EAP-NOOB request (Type=1) to the peer, which responds with		the first EAP-NOOB request (Type=1) to the peer, which responds with
	the peer identifier (PeerId) and state (PeerState) in the range 0..3.		the peer identifier (PeerId) and state (PeerState) in the range 0..3.
	However, the peer SHOULD omit the PeerId from the response (Type=1)		However, the peer SHOULD omit the PeerId from the response (Type=1)
	when PeerState=0. The server then chooses the EAP-NOOB exchange,		when PeerState=0. The server then chooses the EAP-NOOB exchange,
	i.e. the ensuing message sequence, as explained below. The peer		i.e., the ensuing message sequence, as explained below. The peer
	recognizes the exchange based on the message type field (Type) of the		recognizes the exchange based on the message type field (Type) of the
	next EAP-NOOB request received from the server.		next EAP-NOOB request received from the server.
	The server MUST determine the exchange type based on the combination		The server MUST determine the exchange type based on the combination
	of the peer and server states as follows (also summarized in		of the peer and server states as follows (also summarized in
	Figure 11). If either the peer or server is in the Unregistered (0)		Figure 11). If either the peer or server is in the Unregistered (0)
	state and the other is in one of the ephemeral states (0..2), the		state and the other is in one of the ephemeral states (0..2), the
	server chooses the Initial Exchange. If one of the peer or server is		server chooses the Initial Exchange. If one of the peer or server is
	in the OOB Received (2) state and the other is either in the Waiting		in the OOB Received (2) state and the other is either in the Waiting
	for OOB (1) or OOB Received (2) state, the OOB Step has taken place		for OOB (1) or OOB Received (2) state, the OOB Step has taken place
	skipping to change at page 9, line 37 ¶		skipping to change at page 9, line 37 ¶
	SHOULD indicate such errors to the peer with the error code 2002 (see		SHOULD indicate such errors to the peer with the error code 2002 (see
	Section 3.6.3). Note also that the peer MUST NOT initiate EAP-NOOB		Section 3.6.3). Note also that the peer MUST NOT initiate EAP-NOOB
	when the peer is in the Registered (4) state.		when the peer is in the Registered (4) state.
	EAP Peer Authenticator EAP Server		EAP Peer Authenticator EAP Server
	| | |		| | |
	|<----------- EAP-Request/Identity -| |		|<----------- EAP-Request/Identity -| |
	| |		| |
	| |		| |
	|------------ EAP-Response/Identity -------------->|		|------------ EAP-Response/Identity -------------->|
	| (NAI=noob@eap-noob.net) |		| (NAI=noob@eap-noob.arpa) |
	| |		| |
	| |		| |
	|<----------- EAP-Request/EAP-NOOB ----------------|		|<----------- EAP-Request/EAP-NOOB ----------------|
	| (Type=1) |		| (Type=1) |
	| |		| |
	| |		| |
	|------------ EAP-Response/EAP-NOOB -------------->|		|------------ EAP-Response/EAP-NOOB -------------->|
	| (Type=1,[PeerId],PeerState=1) |		| (Type=1,[PeerId],PeerState=1) |
	| |		| |
	| continuing with exchange-specific messages... |		| continuing with exchange-specific messages... |
	Figure 2: Common handshake in all EAP-NOOB exchanges		Figure 2: Common handshake in all EAP-NOOB exchanges
	3.2.2. Initial Exchange		3.2.2. Initial Exchange
	The Initial Exchange comprises the common handshake and two further		The Initial Exchange comprises the common handshake and two further
	EAP-NOOB request-response pairs, one for version, cryptosuite and		EAP-NOOB request-response pairs, one for version, cryptosuite and
	parameter negotiation and the other for the ECDHE key exchange. The		parameter negotiation and the other for the ECDHE key exchange. The
	first EAP-NOOB request (Type=2) from the server contains a newly		first EAP-NOOB request (Type=2) from the server contains a newly
	allocated PeerId for the peer and an optional Realm. The server		allocated PeerId for the peer and an optional NewNAI for assigning a
	allocates a new PeerId in the Initial Exchange regardless of any old		new NAI to the peer. The server allocates a new PeerId in the
	PeerId in the username part of the received NAI. The server also		Initial Exchange regardless of any old PeerId received in the
	sends in the request a list of the protocol versions (Vers) and		previous reponse (Type=1). The server also sends in the request a
	cryptosuites (Cryptosuites) it supports, an indicator of the OOB		list of the protocol versions (Vers) and cryptosuites (Cryptosuites)
	channel directions it supports (Dirs), and a ServerInfo object. The		it supports, an indicator of the OOB channel directions it supports
	peer chooses one of the versions and cryptosuites. The peer sends a		(Dirs), and a ServerInfo object. The peer chooses one of the
	response (Type=2) with the selected protocol version (Verp), the		versions and cryptosuites. The peer sends a response (Type=2) with
	received PeerId, the selected cryptosuite (Cryptosuitep), an		the selected protocol version (Verp), the received PeerId, the
	indicator of the OOB channel directions selected by the peer (Dirp),		selected cryptosuite (Cryptosuitep), an indicator of the OOB channel
	and a PeerInfo object. In the second EAP-NOOB request and response		directions selected by the peer (Dirp), and a PeerInfo object. In
	(Type=3), the server and peer exchange the public components of their		the second EAP-NOOB request and response (Type=3), the server and
	ECDHE keys and nonces (PKs,Ns,PKp,Np). The ECDHE keys MUST be based		peer exchange the public components of their ECDHE keys and nonces
	on the negotiated cryptosuite, i.e., Cryptosuitep. The Initial		(PKs,Ns,PKp,Np). The ECDHE keys MUST be based on the negotiated
	Exchange always ends with EAP-Failure from the server because the		cryptosuite, i.e., Cryptosuitep. The Initial Exchange always ends
	authentication cannot yet be completed.		with EAP-Failure from the server because the authentication cannot
			yet be completed.
	EAP Peer EAP Server		EAP Peer EAP Server
	| ...continuing from common handshake |		| ...continuing from common handshake |
	| |		| |
	|<----------- EAP-Request/EAP-NOOB ----------------|		|<----------- EAP-Request/EAP-NOOB ----------------|
	| (Type=2,Vers,PeerId,[Realm], |		| (Type=2,Vers,PeerId,[NewNAI], |
	| Cryptosuites,Dirs,ServerInfo) |		| Cryptosuites,Dirs,ServerInfo) |
	| |		| |
	| |		| |
	|------------ EAP-Response/EAP-NOOB -------------->|		|------------ EAP-Response/EAP-NOOB -------------->|
	| (Type=2,Verp,PeerId,Cryptosuitep, |		| (Type=2,Verp,PeerId,Cryptosuitep, |
	| Dirp,PeerInfo) |		| Dirp,PeerInfo) |
	| |		| |
	| |		| |
	|<----------- EAP-Request/EAP-NOOB ----------------|		|<----------- EAP-Request/EAP-NOOB ----------------|
	| (Type=3,PeerId,PKs,Ns,[SleepTime]) |		| (Type=3,PeerId,PKs,Ns,[SleepTime]) |
	skipping to change at page 11, line 38 ¶		skipping to change at page 11, line 38 ¶
	Figure 3: Initial Exchange		Figure 3: Initial Exchange
	At the conclusion of the Initial Exchange, both the server and the		At the conclusion of the Initial Exchange, both the server and the
	peer move to the Waiting for OOB (1) state.		peer move to the Waiting for OOB (1) state.
	3.2.3. OOB Step		3.2.3. OOB Step
	The OOB Step, labeled as OOB Output and OOB Input in Figure 1, takes		The OOB Step, labeled as OOB Output and OOB Input in Figure 1, takes
	place after the Initial Exchange. Depending on the negotiated OOB		place after the Initial Exchange. Depending on the negotiated OOB
	channel direction, the peer or the server outputs the OOB message		channel direction, the peer or the server outputs the OOB message as
	shown in Figure 4 or Figure 5, respectively. The data fields are the		shown in Figure 4 or Figure 5, respectively. The data fields are the
	PeerId, the secret nonce Noob, and the cryptographic fingerprint		PeerId, the secret nonce Noob, and the cryptographic fingerprint
	Hoob. The contents of the data fields are defined in Section 3.3.2.		Hoob. The contents of the data fields are defined in Section 3.3.2.
	The OOB message is delivered to the other endpoint via a user-		The OOB message is delivered to the other endpoint via a user-
	assisted OOB channel.		assisted OOB channel.
	For brevity, we will use the terms OOB sender and OOB receiver in		For brevity, we will use the terms OOB sender and OOB receiver in
	addition to the already familiar EAP server and EAP peer. If the OOB		addition to the already familiar EAP server and EAP peer. If the OOB
	message is sent in the server-to-peer direction, the OOB sender is		message is sent in the server-to-peer direction, the OOB sender is
	the server and the OOB receiver is the peer. On the other hand, if		the server and the OOB receiver is the peer. On the other hand, if
	skipping to change at page 13, line 23 ¶		skipping to change at page 13, line 23 ¶
	considerations.		considerations.
	Even though not recommended (see Section 3.3), this specification		Even though not recommended (see Section 3.3), this specification
	allows both directions to be negotiated (Dirp=3) for the OOB channel.		allows both directions to be negotiated (Dirp=3) for the OOB channel.
	In that case, both sides SHOULD output the OOB message, and it is up		In that case, both sides SHOULD output the OOB message, and it is up
	to the user to deliver at least one of them.		to the user to deliver at least one of them.
	The details of the OOB channel implementation including the message		The details of the OOB channel implementation including the message
	encoding are defined by the application. Appendix E gives an example		encoding are defined by the application. Appendix E gives an example
	of how the OOB message can be encoded as a URL that may be embedded		of how the OOB message can be encoded as a URL that may be embedded
	in a QR code or NFC tag.		in a dynamic QR code or NFC tag.
	3.2.4. Completion Exchange		3.2.4. Completion Exchange
	After the Initial Exchange, if both the server and the peer support		After the Initial Exchange, if both the server and the peer support
	the peer-to-server direction for the OOB channel, the peer SHOULD		the peer-to-server direction for the OOB channel, the peer SHOULD
	initiate the EAP-NOOB method again after an applications-specific		initiate the EAP-NOOB method again after an applications-specific
	waiting time in order to probe for completion of the OOB Step. Also,		waiting time in order to probe for completion of the OOB Step. Also,
	if both sides support the server-to-peer direction of the OOB		if both sides support the server-to-peer direction of the OOB
	exchange and the peer receives the OOB message, it SHOULD initiate		exchange and the peer receives the OOB message, it SHOULD initiate
	the EAP-NOOB method immediately. Depending on the combination of the		the EAP-NOOB method immediately. Depending on the combination of the
	skipping to change at page 14, line 29 ¶		skipping to change at page 14, line 29 ¶
	move to the Registered (4) state. They also derive the output keying		move to the Registered (4) state. They also derive the output keying
	material and store the persistent EAP-NOOB association state as		material and store the persistent EAP-NOOB association state as
	defined in Section 3.4 and Section 3.5.		defined in Section 3.4 and Section 3.5.
	It is possible that the OOB message expires before it is received.		It is possible that the OOB message expires before it is received.
	In that case, the sender of the OOB message no longer recognizes the		In that case, the sender of the OOB message no longer recognizes the
	NoobId that it receives in the Completion Exchange. Another reason		NoobId that it receives in the Completion Exchange. Another reason
	why the OOB sender might not recognize the NoobId is if the received		why the OOB sender might not recognize the NoobId is if the received
	OOB message was spoofed and contained an attacker-generated Noob		OOB message was spoofed and contained an attacker-generated Noob
	value. The recipient of an unrecognized NoobId indicates this with		value. The recipient of an unrecognized NoobId indicates this with
	an error message (error code 2003, see Section 3.6.1) and the		an error message (error code 2003, see Section 3.6.1), and the
	Completion Exchange ends in EAP-Failure. The recipient of the error		Completion Exchange ends in EAP-Failure. The recipient of the error
	message 2003 moves back to the Waiting for OOB (1) state. This state		message 2003 moves back to the Waiting for OOB (1) state. This state
	transition is shown as OOB Reject in Figure 1 (even though it really		transition is called OOB Reject in Figure 1 (even though it really is
	is a specific type of failed Completion Exchange). The sender of the		a specific type of failed Completion Exchange). The sender of the
	error message, on the other hand, stays in its previous state.		error message, on the other hand, stays in its previous state.
	Although it is not expected to occur in practice, poor user interface		Although it is not expected to occur in practice, poor user interface
	design could lead to two OOB messages delivered simultaneously, one		design could lead to two OOB messages delivered simultaneously, one
	from the peer to the server and the other from the server to the		from the peer to the server and the other from the server to the
	peer. The server detects this event in the beginning of the		peer. The server detects this event in the beginning of the
	Completion Exchange by observing that both the server and peer are in		Completion Exchange by observing that both the server and peer are in
	the OOB Received state (2). In that case, as a tiebreaker, the		the OOB Received state (2). In that case, as a tiebreaker, the
	server MUST behave as if only the server-to-peer message had been		server MUST behave as if only the server-to-peer message had been
	delivered.		delivered.
	skipping to change at page 15, line 37 ¶		skipping to change at page 15, line 37 ¶
	Figure 6: Completion Exchange		Figure 6: Completion Exchange
	3.2.5. Waiting Exchange		3.2.5. Waiting Exchange
	As explained in Section 3.2.4, the peer SHOULD probe the server for		As explained in Section 3.2.4, the peer SHOULD probe the server for
	completion of the OOB Step. When the combination of the peer and		completion of the OOB Step. When the combination of the peer and
	server states indicates that the OOB message has not yet been		server states indicates that the OOB message has not yet been
	delivered, the server chooses the Waiting Exchange (see Section 3.2.1		delivered, the server chooses the Waiting Exchange (see Section 3.2.1
	on how the server makes this decision). The Waiting Exchange		on how the server makes this decision). The Waiting Exchange
	comprises the common handshake and one further request-response pair,		comprises the common handshake and one further request-response pair,
	and it ends always in EAP-Failure.		and it always ends in EAP-Failure.
	In order to limit the rate at which peers probe the server, the		In order to limit the rate at which peers probe the server, the
	server MAY send to the peer either in the Initial Exchange or in the		server MAY send to the peer either in the Initial Exchange or in the
	Waiting Exchange a minimum time to wait before probing the server		Waiting Exchange a minimum time to wait before probing the server
	again. A peer that has not received an OOB message SHOULD wait at		again. A peer that has not received an OOB message SHOULD wait at
	least the server-specified minimum waiting time in seconds		least the server-specified minimum waiting time in seconds
	(SleepTime) before initiating EAP again with the same server. The		(SleepTime) before initiating EAP again with the same server. The
	peer uses the latest SleepTime value that it has received in or after		peer uses the latest SleepTime value that it has received in or after
	the Initial Exchange. If the server has not sent any SleepTime		the Initial Exchange. If the server has not sent any SleepTime
	value, the peer MUST wait for an application-specified minimum time		value, the peer MUST wait for an application-specified minimum time
	skipping to change at page 16, line 40 ¶		skipping to change at page 16, line 40 ¶
	|<----------- EAP-Failure -------------------------|		|<----------- EAP-Failure -------------------------|
	| |		| |
	Figure 7: Waiting Exchange		Figure 7: Waiting Exchange
	3.3. Protocol data fields		3.3. Protocol data fields
	This section defines the various identifiers and data fields used in		This section defines the various identifiers and data fields used in
	the EAP-NOOB protocol.		the EAP-NOOB protocol.
	3.3.1. Peer identifier, realm and NAI		3.3.1. Peer identifier and NAI
	The server allocates a new peer identifier (PeerId) for the peer in		The server allocates a new peer identifier (PeerId) for the peer in
	the Initial Exchange. The peer identifier MUST follow the syntax of		the Initial Exchange. The peer identifier MUST follow the syntax of
	the utf8-username specified in [RFC7542]. The server MUST generate		the utf8-username specified in [RFC7542]. The server MUST generate
	the identifiers in such a way that they do not repeat and cannot be		the identifiers in such a way that they do not repeat and cannot be
	guessed by the peer or third parties before the server sends them to		guessed by the peer or third parties before the server sends them to
	the peer in the Initial Exchange. One way to generate the		the peer in the Initial Exchange. One way to generate the
	identifiers is to choose a random 16-byte identifier and to base64url		identifiers is to choose a random 16-byte identifier and to base64url
	encode it without padding [RFC4648] into a 22-character ASCII string.		encode it without padding [RFC4648] into a 22-character ASCII string.
	skipping to change at page 17, line 24 ¶		skipping to change at page 17, line 24 ¶
	previously allocated PeerID. The peer sets the PeerId value in		previously allocated PeerID. The peer sets the PeerId value in
	response type 1 as follows. When the peer is in the Unregistered (0)		response type 1 as follows. When the peer is in the Unregistered (0)
	state, it SHOULD omit the PeerId from response type 1. When the peer		state, it SHOULD omit the PeerId from response type 1. When the peer
	is in one of the states 1..2, it MUST use the PeerId that the server		is in one of the states 1..2, it MUST use the PeerId that the server
	assigned to it in the latest Initial Exchange. When the peer is in		assigned to it in the latest Initial Exchange. When the peer is in
	one of the persistent states 3..4, it MUST use the PeerId from its		one of the persistent states 3..4, it MUST use the PeerId from its
	persistent EAP-NOOB association. (The PeerId is written to the		persistent EAP-NOOB association. (The PeerId is written to the
	association when the peer moves to the Registered (4) state after a		association when the peer moves to the Registered (4) state after a
	Completion Exchange.)		Completion Exchange.)
	The default realm for the peer is "eap-noob.arpa". However, the peer		The default NAI for the peer is "noob@eap-noob.arpa". The peer
	MAY allow the user or application to provide a different default		implementation MAY allow the user or application to configure a
	realm. Furthermore, the server MAY assign a new realm to the peer in		different NAI, which overrides the default NAI. Furthermore, the
	the Initial Exchange or Reconnect Exchange, in the Realm field of		server MAY assign a new NAI to the peer in the Initial Exchange or
	response types 2 and 7. The Realm value MUST follow the syntax of		Reconnect Exchange, in the NewNAI field of request types 2 and 7, to
	the utf8-realm specified in [RFC7542]. When the peer is in the		override any previous NAI value. When the peer is in the
	Unregistered (0) state, or when the peer is in one of the states 1..2		Unregistered (0) state, or when the peer is in one of the states 1..2
	and the server did not send a Realm in the latest Initial Exchange,		and the server did not send a NewNAI in the latest Initial Exchange,
	the peer MUST use the default realm. When the peer is in one of the		the peer MUST use the configured NAI, or if it does not exist, the
	states 1..2 and the server sent a Realm in the latest Initial		default NAI. When the peer is in one of the states 1..2 and the
	Exchange, the peer MUST use that realm. Finally, when the peer is in		server sent a NewNAI in the latest Initial Exchange, the peer MUST
	one of the persistent states 3..4, it MUST use the Realm from its		use this serve-assigned NAI. When the peer moves to the Registered
	persistent EAP-NOOB association. (The Realm is written to the		(4) state after the Completion Exchange, it writes to the persistent
	association when the peer moves to the Registered (4) state after a		EAP-NOOB association the same NAI value that it used in the
	Completion Exchange or Reconnect Exchange.)		Completion Exchange. When the peer is in the Reconnecting (3) or
			Registered (4) state, it MUST use the NAI from its persistent EAP-
	To compose its NAI [RFC7542], the peer concatenates the string		NOOB association. When the server sends NewNAI in the Reconnect
	"noob@" and the server-assigned realm. When no server-assigned realm		Exchange, the peer writes its value to the persistent EAP-NOOB
	is available, the default value is used instead.		association when it moves from the Reconnecting (3) state to the
			Registered (4) state. All the NAI values MUST follow the syntax
			specified in [RFC7542].
	The purpose of the server-assigned realm is to enable more flexible		The purpose of the server-assigned NAI is to enable more flexible
	routing of the EAP sessions over the AAA infrastructure, including		routing of the EAP sessions over the AAA infrastructure, including
	roaming scenarios (see Appendix D). Moreover, some Authenticators or		roaming scenarios (see Appendix D). Moreover, some Authenticators or
	AAA servers use the assigned Realm to determine peer-specific		AAA servers use the realm part of the assigned NAI to determine peer-
	connection parameters, such as isolating the peer to a specific VLAN.		specific connection parameters, such as isolating the peer to a
	The possibility to configure a different default realm enables		specific VLAN. The user or application configured NAI, on the other
	registration of new devices while roaming. It also enables		hand, enables registration of new devices while roaming. It also
	manufacturers to set up their own AAA servers for bootstrapping of		enables manufacturers to set up their own AAA servers for
	new peer devices.		bootstrapping of new peer devices.
	The peer's PeerId and Realm are ephemeral until a successful		The peer's PeerId and server-assigned NAI are ephemeral until a
	Completion Exchange takes place. Thereafter, the values become parts		successful Completion Exchange takes place. Thereafter, the values
	of the persistent EAP-NOOB association, until the user resets the		become parts of the persistent EAP-NOOB association, until the user
	peer and the server or until a new Realm is assigned in the Reconnect		resets the peer and the server or until a new NAI is assigned in the
	Exchange.		Reconnect Exchange.
	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 protocol versions supported by the |		| Vers, Verp | EAP-NOOB protocol versions supported by the |
	| | EAP server, and the protocol version chosen by |		| | EAP server, and the protocol version chosen by |
	| | the peer. Vers is a JSON array of unsigned |		| | the 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", |		| | Example values are "[1]" and "1", |
	| | respectively. |		| | respectively. |
	| | |		| | |
	| PeerId | Peer identifier as defined in Section 3.3.1. |		| PeerId | Peer identifier as defined in Section 3.3.1. |
	| | |		| | |
	| Realm | Peer realm as defined in Section 3.3.1. |		| NAI | Peer NAI as defined in Section 3.3.1. |
	| | |		| | |
	| PeerState | Peer state is an integer in the range 0..4 |		| PeerState | Peer state is an integer in the range 0..4 |
	| | (see Figure 1). However, only values 0..3 are |		| | (see Figure 1). However, only values 0..3 are |
	| | ever sent in the protocol messages. |		| | ever sent in the protocol messages. |
	| | |		| | |
	| Type | EAP-NOOB message type. The type is an integer |		| Type | EAP-NOOB message type. The type is an integer |
	| | in the range 0..9. EAP-NOOB requests and the |		| | in the range 0..9. EAP-NOOB requests and the |
	| | corresponding responses share the same type |		| | corresponding responses share the same type |
	| | value. |		| | value. |
	| | |		| | |
	skipping to change at page 19, line 51 ¶		skipping to change at page 20, line 6 ¶
	| | object of at most 500 bytes. It could include, |		| | object of at most 500 bytes. It could include, |
	| | for example, the peer brand, model and serial |		| | for example, the peer brand, model and serial |
	| | number, which help the user to distinguish |		| | number, which help the user to distinguish |
	| | between devices and to deliver the OOB message |		| | between devices and to deliver the OOB message |
	| | to the correct peer through the out-of-band |		| | to the correct peer through the out-of-band |
	| | channel. |		| | channel. |
	| | |		| | |
	| SleepTime | The number of seconds for which the peer MUST |		| SleepTime | The number of seconds for which the peer MUST |
	| | NOT start a new execution of the EAP-NOOB |		| | NOT start a new execution of the EAP-NOOB |
	| | method with the authenticator, unless the peer |		| | method with the authenticator, unless the peer |
	| | receives the OOB message or the peer is reset |		| | receives the OOB message or the sending is |
	| | by the user. The server can use this field to |		| | triggered by an application-specific user |
	| | limit the rate at which peers probe it. |		| | action. The server can use this field to limit |
	| | SleepTime is an unsigned integer in the range |		| | the rate at which peers probe it. SleepTime is |
	| | 0..3600. |		| | an unsigned integer in the range 0..3600. |
	| | |		| | |
	| Noob | 16-byte secret nonce sent through the OOB |		| Noob | 16-byte secret nonce sent through the OOB |
	| | channel and used for the session key |		| | channel and used for the session key |
	| | derivation. The endpoint that received the OOB |		| | derivation. The endpoint that received the OOB |
	| | message uses this secret in the Completion |		| | message uses this secret in the Completion |
	| | Exchange to authenticate the exchanged key to |		| | Exchange to authenticate the exchanged key to |
	| | the endpoint that sent the OOB message. |		| | the endpoint that sent the OOB message. |
	| | |		| | |
	| Hoob | 16-byte cryptographic fingerprint (i.e., hash |		| Hoob | 16-byte cryptographic fingerprint (i.e., hash |
	| | value) computed from all the parameters |		| | value) computed from all the parameters |
	skipping to change at page 21, line 25 ¶		skipping to change at page 21, line 28 ¶
	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 protocol is designed to cope also with		Nevertheless, the EAP-NOOB protocol is designed to cope also with the
	selected value 3, in which case it uses the first delivered OOB		value 3, in which case it uses the first delivered OOB message. In
	message. In the unlikely case of simultaneously delivered OOB		the unlikely case of simultaneously delivered OOB messages, the
	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
	cryptographic hash function specified in the negotiated cryptosuite		cryptographic hash function specified in the negotiated cryptosuite
	and truncated to the 16 leftmost bytes of the output. The message		and truncated to the 16 leftmost bytes of the output. The message
	authentication codes (MACs, MACp, MACs2, MACp2) are computed with the		authentication codes (MACs, MACp, MACs2, MACp2) are computed with the
	skipping to change at page 22, line 9 ¶		skipping to change at page 22, line 12 ¶
	members MUST NOT be reordered or re-encoded. Whitespace MUST NOT be		members MUST NOT be reordered or re-encoded. Whitespace MUST NOT be
	added anywhere in the JSON structure. Implementers should check that		added anywhere in the JSON structure. Implementers should check that
	their JSON library copies the elements as UTF-8 strings and does not		their JSON library copies the elements as UTF-8 strings and does not
	modify them in any way, and that it does not add whitespace to the		modify them in any way, and that it does not add whitespace to the
	HMAC input.		HMAC input.
	The inputs for computing the fingerprint and message authentication		The inputs for computing the fingerprint and message authentication
	codes are the following:		codes are the following:
	Hoob = H(Dir,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,Cryptos		Hoob = H(Dir,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,Cryptos
	uitep,Dirp,[Realm],PeerInfo,0,PKs,Ns,PKp,Np,Noob).		uitep,Dirp,[NewNAI],PeerInfo,0,PKs,Ns,PKp,Np,Noob).
	NoobId = H("NoobId",Noob).		NoobId = H("NoobId",Noob).
	MACs = HMAC(Kms; 2,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,C		MACs = HMAC(Kms; 2,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,C
	ryptosuitep,Dirp,[Realm],PeerInfo,0,PKs,Ns,PKp,Np,Noob).		ryptosuitep,Dirp,[NewNAI],PeerInfo,0,PKs,Ns,PKp,Np,Noob).
	MACp = HMAC(Kmp; 1,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,C		MACp = HMAC(Kmp; 1,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,C
	ryptosuitep,Dirp,[Realm],PeerInfo,0,PKs,Ns,PKp,Np,Noob).		ryptosuitep,Dirp,[NewNAI],PeerInfo,0,PKs,Ns,PKp,Np,Noob).
	MACs2 = HMAC(Kms2; 2,Vers,Verp,PeerId,Cryptosuites,"",[ServerInfo]		MACs2 = HMAC(Kms2; 2,Vers,Verp,PeerId,Cryptosuites,"",[ServerInfo]
	,Cryptosuitep,"",[Realm],[PeerInfo],KeyingMode,[PKs2],Ns2,[PKp2],N		,Cryptosuitep,"",[NewNAI],[PeerInfo],KeyingMode,[PKs2],Ns2,[PKp2],
	p2,"")		Np2,"")
	MACp2 = HMAC(Kmp2; 1,Vers,Verp,PeerId,Cryptosuites,"",[ServerInfo]		MACp2 = HMAC(Kmp2; 1,Vers,Verp,PeerId,Cryptosuites,"",[ServerInfo]
	,Cryptosuitep,"",[Realm],[PeerInfo],KeyingMode,[PKs2],Ns2,[PKp2],N		,Cryptosuitep,"",[NewNAI],[PeerInfo],KeyingMode,[PKs2],Ns2,[PKp2],
	p2,"")		Np2,"")
	The inputs denoted with "" above are not present, and the values in		The inputs denoted with "" above are not present, and the values in
	brackets [] are optional. Both kinds of missing input values are		brackets [] are optional. Both kinds of missing input values are
	represented by empty strings "" in the HMAC input (JSON array).		represented by empty strings "" in the HMAC input (JSON array).
	Realm is included in the computation of MACs and MACp if it was sent		NewNAI is included in the computation of MACs and MACp if it was sent
	or received in the preceding Initial Exchange. Each of the values in		or received in the preceding Initial Exchange. Each of the values in
	brackets for the computation of Macs2 and Macp2 MUST be included if		brackets for the computation of Macs2 and Macp2 MUST be included if
	it was sent or received in the same Reconnect Exchange; otherwise the		it was sent or received in the same Reconnect Exchange; otherwise the
	value is replaced by an empty string "".		value is replaced by an empty string "".
	The parameter Dir indicates the direction in which the OOB message		The parameter Dir indicates the direction in which the OOB message
	containing the Noob value is being sent (1=peer-to-server, 2=server-		containing the Noob value is being sent (1=peer-to-server, 2=server-
	to-peer). This field is included in the Hoob input to prevent the		to-peer). This field is included in the Hoob input to prevent the
	user from accidentally delivering the OOB message back to its		user from accidentally delivering the OOB message back to its
	originator in the rare cases where both OOB directions have been		originator in the rare cases where both OOB directions have been
	skipping to change at page 23, line 32 ¶		skipping to change at page 23, line 36 ¶
	mobility or timeout of session keys. Software or hardware failure or		mobility or timeout of session keys. Software or hardware failure or
	user action may also cause the authenticator, EAP server or peer to		user action may also cause the authenticator, EAP server or peer to
	lose its non-persistent state data. The failure would typically be		lose its non-persistent state data. The failure would typically be
	detected by the peer or authenticator when session keys are no longer		detected by the peer or authenticator when session keys are no longer
	accepted by the other endpoint. Changes in the supported		accepted by the other endpoint. Changes in the supported
	cryptosuites in the EAP server or peer may also cause the need for a		cryptosuites in the EAP server or peer may also cause the need for a
	new key exchange. When the EAP server or peer detects any one of		new key exchange. When the EAP server or peer detects any one of
	these events, it MUST change from the Registered to Reconnecting		these events, it MUST change from the Registered to Reconnecting
	state. These state transitions are labeled Mobility/Timeout/Failure		state. These state transitions are labeled Mobility/Timeout/Failure
	in Figure 1. The EAP-NOOB method will then perform the Reconnect		in Figure 1. The EAP-NOOB method will then perform the Reconnect
	Exchange the next time that EAP is triggered.		Exchange the next time when EAP is triggered.
	3.4.1. Persistent EAP-NOOB association		3.4.1. Persistent EAP-NOOB association
	To enable rekeying, the EAP server and peer store the session state		To enable rekeying, the EAP server and peer store the session state
	in persistent memory after a successful Completion Exchange. This		in persistent memory after a successful Completion Exchange. This
	state data, called "persistent EAP-NOOB association", MUST include at		state data, called "persistent EAP-NOOB association", MUST include at
	least the data fields shown in Table 2. They are used for		least the data fields shown in Table 2. They are used for
	identifying and authenticating the peer in the Reconnect Exchange.		identifying and authenticating the peer in the Reconnect Exchange.
	When a persistent EAP-NOOB association exists, the EAP server and		When a persistent EAP-NOOB association exists, the EAP server and
	peer are in the Registered state (4) or Reconnecting state (3), as		peer are in the Registered state (4) or Reconnecting state (3), as
	shown in Figure 1.		shown in Figure 1.
	+------------------+---------------------------+--------------------+		+------------------+----------------------------+-------------------+
	| Data field | Value | Type |		| Data field | Value | Type |
	+------------------+---------------------------+--------------------+		+------------------+----------------------------+-------------------+
	| PeerId | Peer identifier allocated | UTF-8 string |		| PeerId | Peer identifier allocated | UTF-8 string |
	| | by server | (typically 22 |		| | by server | (typically 22 |
	| | | ASCII characters) |		| | | ASCII characters) |
	| | | |		| | | |
	| Verp | Negotiated protocol | integer |		| Verp | Negotiated protocol | integer |
	| | version | |		| | version | |
	| | | |		| | | |
	| Cryptosuitep | Negotiated cryptosuite | integer |		| Cryptosuitep | Negotiated cryptosuite | integer |
	| | | |		| | | |
	| CryptosuitepPrev | Previous cryptosuite | integer |		| CryptosuitepPrev | Previous cryptosuite | integer |
	| (at peer only) | | |		| (at peer only) | | |
	| | | |		| | | |
	| Realm | Optional realm assigned | UTF-8 string |		| NAI | NAI assigned by server, | UTF-8 string |
	| | by server (default value | |		| | configured by user, or the | |
	| | is "eap-noob.arpa") | |		| | default NAI "noob@eap- | |
	| | | |		| | noob.arpa" | |
	| Kz | Persistent key material | 32 bytes |		| Kz | Persistent key material | 32 bytes |
	| | | |		| | | |
	| KzPrev (at | Previous Kz value | 32 bytes |		| KzPrev (at peer | Previous Kz value | 32 bytes |
	| peer only) | | |		| only) | | |
	+------------------+---------------------------+--------------------+		+------------------+----------------------------+-------------------+
	Table 2: Persistent EAP-NOOB association		Table 2: Persistent EAP-NOOB association
	3.4.2. Reconnect Exchange		3.4.2. Reconnect Exchange
	The server chooses the Reconnect Exchange when both the peer and the		The server chooses the Reconnect Exchange when both the peer and the
	server are in a persistent state and fast reconnection is needed (see		server are in a persistent state and fast reconnection is needed (see
	Section 3.2.1 for details).		Section 3.2.1 for details).
	The Reconnect Exchange comprises the common handshake and three		The Reconnect Exchange comprises the common handshake and three
	skipping to change at page 25, line 6 ¶		skipping to change at page 25, line 6 ¶
	protocol versions or cryptosuites that it knows to be weaker than the		protocol versions or cryptosuites that it knows to be weaker than the
	one currently in the Cryptosuitep field of the persistent EAP-NOOB		one currently in the Cryptosuitep field of the persistent EAP-NOOB
	association. The server SHOULD NOT needlessly change the		association. The server SHOULD NOT needlessly change the
	cryptosuites it offers to the same peer because peer devices may have		cryptosuites it offers to the same peer because peer devices may have
	limited ability to update their persistent storage. However, if the		limited ability to update their persistent storage. However, if the
	peer has different values in the Cryptosuitep and CryptosuitepPrev		peer has different values in the Cryptosuitep and CryptosuitepPrev
	fields, it SHOULD also accept offers that are not weaker than		fields, it SHOULD also accept offers that are not weaker than
	CryptosuitepPrev. Note that Cryptosuitep and CryptosuitePrev from		CryptosuitepPrev. Note that Cryptosuitep and CryptosuitePrev from
	the persistent EAP-NOOB association are only used to support the		the persistent EAP-NOOB association are only used to support the
	negotiation as described above; all actual cryptographic operations		negotiation as described above; all actual cryptographic operations
	use the negotiated cryptosuite. The request and response (Type=7)		use the newly negotiated cryptosuite. The request and response
	MAY additionally contain PeerInfo and ServerInfo objects.		(Type=7) MAY additionally contain PeerInfo and ServerInfo objects.
	The server then determines the KeyingMode (defined in Section 3.5)		The server then determines the KeyingMode (defined in Section 3.5)
	based on changes in the negotiated cryptosuite and whether it desires		based on changes in the negotiated cryptosuite and whether it desires
	to achieve forward secrecy or not. The server SHOULD only select		to achieve forward secrecy or not. The server SHOULD only select
	KeyingMode 3 when the negotiated cryptosuite differs from the		KeyingMode 3 when the negotiated cryptosuite differs from the
	Cryptosuitep in the server's persistent EAP-NOOB association,		Cryptosuitep in the server's persistent EAP-NOOB association,
	although it is technically possible to select this values without		although it is technically possible to select this value without
	changing the cryptosuite. In the second request and response		changing the cryptosuite. In the second request and response
	(Type=8), the server informs the peer about the KeyingMode, and the		(Type=8), the server informs the peer about the KeyingMode, and the
	server and peer exchange nonces (Ns2, Np2). When KeyingMode is 2 or		server and peer exchange nonces (Ns2, Np2). When KeyingMode is 2 or
	3 (rekeying with ECDHE), they also exchange public components of		3 (rekeying with ECDHE), they also exchange public components of
	ECDHE keys (PKs2, PKp2). The server ECDHE key MUST be fresh, i.e.,		ECDHE keys (PKs2, PKp2). The server ECDHE key MUST be fresh, i.e.,
	not previously used with the same peer, and the peer ECDHE key SHOULD		not previously used with the same peer, and the peer ECDHE key SHOULD
	be fresh, i.e., not previously used.		be fresh, i.e., not previously used.
	In the third and final request and response (Type=9), the server and		In the third and final request and response (Type=9), the server and
	peer exchange message authentication codes. Both sides MUST compute		peer exchange message authentication codes. Both sides MUST compute
	skipping to change at page 26, line 38 ¶		skipping to change at page 26, line 38 ¶
	the peer rules because the server does not store previous keys and it		the peer rules because the server does not store previous keys and it
	never rolls back a cryptosuite upgrade. Upon receiving the final		never rolls back a cryptosuite upgrade. Upon receiving the final
	response (Type=9), the server compares the received value of MACp2		response (Type=9), the server compares the received value of MACp2
	with one it computes locally. If the values match, the Reconnect		with one it computes locally. If the values match, the Reconnect
	Exchange ends in EAP-Success. When KeyingMode is 3, the server also		Exchange ends in EAP-Success. When KeyingMode is 3, the server also
	updates Cryptosuitep and Kz in the persistent EAP-NOOB association.		updates Cryptosuitep and Kz in the persistent EAP-NOOB association.
	On the other hand, if the server finds that the values do not match,		On the other hand, if the server finds that the values do not match,
	it sends an error message (error code 4001), and the Reconnect		it sends an error message (error code 4001), and the Reconnect
	Exchange ends in EAP-Failure.		Exchange ends in EAP-Failure.
	The endpoints MAY send updated Realm, ServerInfo and PeerInfo objects		The endpoints MAY send updated NewNAI, ServerInfo and PeerInfo
	in the Reconnect Exchange. When there is no update to the values,		objects in the Reconnect Exchange. When there is no update to the
	they SHOULD omit this information from the messages. If the Realm		values, they SHOULD omit this information from the messages. If the
	was sent, each side updates Realm in the persistent EAP-NOOB		NewNAI was sent, each side updates NAI in the persistent EAP-NOOB
	association when moving to the Registered (4) state.		association when moving to the Registered (4) state.
	EAP Peer EAP Server		EAP Peer EAP Server
	| ...continuing from common handshake |		| ...continuing from common handshake |
	| |		| |
	|<----------- EAP-Request/EAP-NOOB ----------------|		|<----------- EAP-Request/EAP-NOOB ----------------|
	| (Type=7,Vers,PeerId,Cryptosuites, |		| (Type=7,Vers,PeerId,Cryptosuites, |
	| [Realm],[ServerInfo]) |		| [NewNAI],[ServerInfo]) |
	| |		| |
	| |		| |
	|------------ EAP-Response/EAP-NOOB -------------->|		|------------ EAP-Response/EAP-NOOB -------------->|
	| (Type=7,Verp,PeerId,Cryptosuitep,[PeerInfo])|		| (Type=7,Verp,PeerId,Cryptosuitep,[PeerInfo])|
	| |		| |
	| |		| |
	|<----------- EAP-Request/EAP-NOOB ----------------|		|<----------- EAP-Request/EAP-NOOB ----------------|
	| (Type=8,PeerId,KeyingMode,[PKs2],Ns2) |		| (Type=8,PeerId,KeyingMode,[PKs2],Ns2) |
	| |		| |
	| |		| |
	skipping to change at page 28, line 33 ¶		skipping to change at page 28, line 33 ¶
	to treat the device just like a new peer.		to treat the device just like a new peer.
	3.5. Key derivation		3.5. Key derivation
	EAP-NOOB derives the EAP output values MSK and EMSK and other secret		EAP-NOOB derives the EAP output values MSK and EMSK and other secret
	keying material from the output of an Ephemeral Elliptic Curve		keying material from the output of an Ephemeral Elliptic Curve
	Diffie-Hellman (ECDHE) algorithm following the NIST specification		Diffie-Hellman (ECDHE) algorithm following the NIST specification
	[NIST-DH]. In NIST terminology, we use a C(2e, 0s, ECC CDH) scheme,		[NIST-DH]. In NIST terminology, we use a C(2e, 0s, ECC CDH) scheme,
	i.e., two ephemeral keys and no static keys. In the Initial and		i.e., two ephemeral keys and no static keys. In the Initial and
	Reconnect Exchanges, the server and peer compute the ECDHE shared		Reconnect Exchanges, the server and peer compute the ECDHE shared
	secret Z as defined in section 6.1.2.2 of the NIST specification		secret Z as defined in section 6.1.2 of the NIST specification
	[NIST-DH]. In the Completion and Reconnect Exchanges, the server and		[NIST-DH]. In the Completion and Reconnect Exchanges, the server and
	peer compute the secret keying material from Z with the single-step		peer compute the secret keying material from Z with the one-step key
	key derivation function (KDF) defined in section 5.8.1 of the NIST		derivation function (KDF) defined in section 5.8.2.1 of the NIST
	specification. The hash function H for KDF is taken from the		specification. The auxiliary function H is a hash function and it is
	negotiated cryptosuite.		taken from the negotiated cryptosuite.
	+------------+------------------------------------------------------+		+------------+------------------------------------------------------+
	| KeyingMode | Description |		| KeyingMode | Description |
	+------------+------------------------------------------------------+		+------------+------------------------------------------------------+
	| 0 | Completion Exchange (always with ECDHE) |		| 0 | Completion Exchange (always with ECDHE) |
	| | |		| | |
	| 1 | Reconnect Exchange, rekeying without ECDHE |		| 1 | Reconnect Exchange, rekeying without ECDHE |
	| | |		| | |
	| 2 | Reconnect Exchange, rekeying with ECHDE, no change |		| 2 | Reconnect Exchange, rekeying with ECHDE, no change |
	| | in cryptosuite |		| | in cryptosuite |
	skipping to change at page 29, line 27 ¶		skipping to change at page 29, line 27 ¶
	+------------+------------------------------------------------------+		+------------+------------------------------------------------------+
	Table 3: Keying modes		Table 3: Keying modes
	The key derivation has four different modes (KeyingMode), which are		The key derivation has four different modes (KeyingMode), which are
	specified in Table 3. Table 4 defines the inputs to KDF in each		specified in Table 3. Table 4 defines the inputs to KDF in each
	KeyingMode.		KeyingMode.
	In the Completion Exchange (KeyingMode=0), the input Z comes from the		In the Completion Exchange (KeyingMode=0), the input Z comes from the
	preceding Initial exchange. KDF takes some additional inputs		preceding Initial exchange. KDF takes some additional inputs
	(OtherInfo), for which we use the concatenation format defined in		(FixedInfo), for which we use the concatenation format defined in
	section 5.8.1.2.1 of the NIST specification [NIST-DH]. OtherInfo		section 5.8.2.1.1 of the NIST specification [NIST-DH]. FixedInfo
	consists of the AlgorithmId, PartyUInfo, PartyVInfo, and SuppPrivInfo		consists of the AlgorithmId, PartyUInfo, PartyVInfo, and SuppPrivInfo
	fields. The first three fields are fixed-length bit strings, and		fields. The first three fields are fixed-length bit strings, and
	SuppPrivInfo is a variable-length string with a one-byte Datalength		SuppPrivInfo is a variable-length string with a one-byte Datalength
	counter. AlgorithmId is the fixed-length 8-byte ASCII string "EAP-		counter. AlgorithmId is the fixed-length 8-byte ASCII string "EAP-
	NOOB". The other input values are the server and peer nonces. In		NOOB". The other input values are the server and peer nonces. In
	the Completion Exchange, the inputs also include the secret nonce		the Completion Exchange, the inputs also include the secret nonce
	Noob from the OOB message.		Noob from the OOB message.
	In the simplest form of the Reconnect Exchange (KeyingMode=1), fresh		In the simplest form of the Reconnect Exchange (KeyingMode=1), fresh
	nonces are exchanged but no ECDHE keys are sent. In this case, input		nonces are exchanged but no ECDHE keys are sent. In this case, input
	skipping to change at page 31, line 48 ¶		skipping to change at page 31, line 48 ¶
	PeerId which the server has assigned to the peer. The exported		PeerId which the server has assigned to the peer. The exported
	Server-Id is a zero-length string (i.e., null string) because EAP-		Server-Id is a zero-length string (i.e., null string) because EAP-
	NOOB neither knows nor assigns any server identifier. The exported		NOOB neither knows nor assigns any server identifier. The exported
	Session-Id is created by concatenating the Type-Code xxx (TBA) with		Session-Id is created by concatenating the Type-Code xxx (TBA) with
	the MethodId, which is obtained from the KDF output as shown in		the MethodId, which is obtained from the KDF output as shown in
	Table 5.		Table 5.
	3.6. Error handling		3.6. Error handling
	Various error conditions in EAP-NOOB are handled by sending an error		Various error conditions in EAP-NOOB are handled by sending an error
	notification message (Type=0) instead of the expected next EAP		notification message (Type=0) instead of a next EAP request or
	request or response message. Both the EAP server and the peer may		response message. Both the EAP server and the peer may send the
	send the error notification, as shown in Figure 9 and Figure 10.		error notification, as shown in Figure 9 and Figure 10. After
	After sending or receiving an error notification, the server MUST		sending or receiving an error notification, the server MUST send an
	send an EAP-Failure (as required by [RFC3748] section 4.2). The		EAP-Failure (as required by [RFC3748] section 4.2). The notification
	notification MAY contain an ErrorInfo field, which is a UTF-8 encoded		MAY contain an ErrorInfo field, which is a UTF-8 encoded text string
	text string with a maximum length of 500 bytes. It is used for		with a maximum length of 500 bytes. It is used for sending
	sending descriptive information about the error for logging and		descriptive information about the error for logging and debugging
	debugging purposes.		purposes.
	EAP Peer EAP Server		EAP Peer EAP Server
	... ...		... ...
	| |		| |
	|<----------- EAP-Request/EAP-NOOB ----------------|		|<----------- EAP-Request/EAP-NOOB ----------------|
	| (Type=0,[PeerId],ErrorCode,[ErrorInfo]) |		| (Type=0,[PeerId],ErrorCode,[ErrorInfo]) |
	| |		| |
	| |		| |
	|<----------- EAP-Failure -------------------------|		|<----------- EAP-Failure -------------------------|
	| |		| |
	skipping to change at page 34, line 52 ¶		skipping to change at page 35, line 4 ¶
	last resort.		last resort.
	3.6.6. Application-specific failure		3.6.6. Application-specific failure
	Applications MAY define new error messages for failures that are		Applications MAY define new error messages for failures that are
	specific to the application or to one type of OOB channel. They MAY		specific to the application or to one type of OOB channel. They MAY
	also use the generic application-specific error code 5001, or the		also use the generic application-specific error code 5001, or the
	error codes 5002 and 5004, which have been reserved for indicating		error codes 5002 and 5004, which have been reserved for indicating
	invalid data in the ServerInfo and PeerInfo fields, respectively.		invalid data in the ServerInfo and PeerInfo fields, respectively.
	Additionally, anticipating OOB channels that make use of a URL, the		Additionally, anticipating OOB channels that make use of a URL, the
	error code 5003 has been reserved for indicating invalid server URL.		error code 5003 has been reserved for indicating an invalid server
			URL.
	4. IANA Considerations		4. 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 EAP-		Authority (IANA) regarding registration of values related to the EAP-
	NOOB protocol, in accordance with [RFC8126].		NOOB protocol, in accordance with [RFC8126].
	The EAP Method Type number for EAP-NOOB needs to be assigned.		The EAP Method Type number for EAP-NOOB needs to be assigned.
	This memo also requires IANA to create new registries as defined in		This memo also requires IANA to create new registries as defined in
	skipping to change at page 38, line 19 ¶		skipping to change at page 38, line 19 ¶
	to queries for "eap-noob.arpa" with NXDOMAIN.		to queries for "eap-noob.arpa" with NXDOMAIN.
	o DNS Server Operators: Except for the authoritative DNS server,		o DNS Server Operators: Except for the authoritative DNS server,
	there are no special requirements for the operators.		there are no special requirements for the operators.
	o DNS Registries/Registrars: There are no special requirements for		o DNS Registries/Registrars: There are no special requirements for
	DNS registrars.		DNS registrars.
	5. Implementation Status		5. Implementation Status
			Note to RFC Editor: Please remove this entire section and the
			reference to RFC7942 before publication.
	This section records the status of known implementations of the		This section records the status of known implementations of the
	protocol defined by this specification at the time of posting of this		protocol defined by this specification at the time of posting of this
	Internet-Draft, and is based on a proposal described in [RFC7942].		Internet-Draft, and is based on a proposal described in [RFC7942].
	The description of implementations in this section is intended to		The description of implementations in this section is intended to
	assist the IETF in its decision processes in progressing drafts to		assist the IETF in its decision processes in progressing drafts to
	RFCs. Please note that the listing of any individual implementation		RFCs. Please note that the listing of any individual implementation
	here does not imply endorsement by the IETF. Furthermore, no effort		here does not imply endorsement by the IETF. Furthermore, no effort
	has been spent to verify the information presented here that was		has been spent to verify the information presented here that was
	supplied by IETF contributors. This is not intended as, and must not		supplied by IETF contributors. This is not intended as, and must not
	be construed to be, a catalog of available implementations or their		be construed to be, a catalog of available implementations or their
	skipping to change at page 38, line 45 ¶		skipping to change at page 38, line 48 ¶
	o Location: <https://github.com/tuomaura/eap-noob>		o Location: <https://github.com/tuomaura/eap-noob>
	o Coverage: This implementation includes all of the features		o Coverage: This implementation includes all of the features
	described in the current specification. The implementation		described in the current specification. The implementation
	supports two dimensional QR codes and NFC as example out-of-band		supports two dimensional QR codes and NFC as example out-of-band
	(OOB) channels.		(OOB) channels.
	o Level of Maturity: Alpha		o Level of Maturity: Alpha
	o Version compatibility: Version 06 of the draft implemented		o Version compatibility: Version 08 of the individual draft
			implemented
	o Licensing: BSD		o Licensing: BSD
	o Contact Information: Tuomas Aura, tuomas.aura@aalto.fi		o Contact Information: Tuomas Aura, tuomas.aura@aalto.fi
	5.2. Implementation on Contiki		5.2. Implementation on Contiki
	o Responsible Organization: University of Murcia and Aalto		o Responsible Organization: University of Murcia and Aalto
	University		University
	o Location: <https://github.com/eduingles/coap-eap-noob>		o Location: <https://github.com/eduingles/coap-eap-noob>
	o Coverage: This implementation includes all of the features		o Coverage: This implementation includes all of the features
	described in the current specification. The implementation uses a		described in the current specification. The implementation uses a
	blinking LED light as the out-of-band (OOB) channel.		blinking LED light as the out-of-band (OOB) channel.
	o Level of Maturity: Alpha		o Level of Maturity: Alpha
	o Version compatibility: Version 05 of the draft implemented		o Version compatibility: Version 06 of the draft implemented
	o Licensing: BSD		o Licensing: BSD
	o Contact Information: Eduardo Ingles, eduardo.ingles@um.es		o Contact Information: Eduardo Ingles, eduardo.ingles@um.es
	5.3. Protocol modeling		5.3. Implementation with wpa_supplicant and hostapd
			o Responsible Organization: Ericsson
			o Location: <https://github.com/Vogeltak/hostap>
			o Coverage: This implementation is the most up-to-date. The
			implementation only provides a minimal API interface for
			transferring OOB messages.
			o Level of Maturity: Alpha
			o Version compatibility: Version 02 of the working group adopted
			draft is implemented
			o Licensing: BSD
			5.4. Protocol modeling
	The current EAP-NOOB specification has been modeled with the mCRL2		The current EAP-NOOB specification has been modeled with the mCRL2
	formal specification language [mcrl2]. The model		formal specification language [mcrl2]. The model
	<https://github.com/tuomaura/eap-noob/tree/master/protocolmodel/		<https://github.com/tuomaura/eap-noob/tree/master/protocolmodel/
	mcrl2> was used mainly for simulating the protocol behavior and for		mcrl2> was used mainly for simulating the protocol behavior and for
	verifying basic safety and liveness properties as part of the		verifying basic safety and liveness properties as part of the
	specification process. For example, we verified the correctness of		specification process. For example, we verified the correctness of
	the tiebreaking mechanism when two OOB messages are received		the tiebreaking mechanism when two OOB messages are received
	simultaneously, one in each direction. We also verified that a man-		simultaneously, one in each direction. We also verified that a man-
	in-the-middle attacker cannot cause persistent failure by spoofing a		in-the-middle attacker cannot cause persistent failure by spoofing a
	skipping to change at page 41, line 12 ¶		skipping to change at page 41, line 31 ¶
	The expected use cases for EAP-NOOB are ones where it replaces a		The expected use cases for EAP-NOOB are ones where it replaces a
	user-entered access credential in IoT appliances. In wireless		user-entered access credential in IoT appliances. In wireless
	network access without EAP, the user-entered credential is often a		network access without EAP, the user-entered credential is often a
	passphrase that is shared by all the network stations. The advantage		passphrase that is shared by all the network stations. The advantage
	of an EAP-based solution, including EAP-NOOB, is that it establishes		of an EAP-based solution, including EAP-NOOB, is that it establishes
	a different master secret for each peer device, which makes the		a different master secret for each peer device, which makes the
	system more resilient against device compromise. Another advantage		system more resilient against device compromise. Another advantage
	is that it is possible to revoke the security association for an		is that it is possible to revoke the security association for an
	individual device on the server side.		individual device on the server side.
	Forward secrecy in EAP-NOOB is optional. The Reconnect Exchange in		Forward secrecy during fast reconnect in EAP-NOOB is optional. The
	EAP-NOOB provides forward secrecy only if both the server and peer		Reconnect Exchange in EAP-NOOB provides forward secrecy only if both
	send their fresh ECDHE keys. This allows both the server and the		the server and peer send their fresh ECDHE keys. This allows both
	peer to limit the frequency of the costly computation that is		the server and the peer to limit the frequency of the costly
	required for forward secrecy. The server MAY adjust the frequency of		computation that is required for forward secrecy. The server MAY
	its attempts at ECDHE rekeying based on what it knows about the		adjust the frequency of its attempts at ECDHE rekeying based on what
	peer's computational capabilities.		it knows about the peer's computational capabilities.
	The users delivering the OOB messages will often authenticate		The users delivering the OOB messages will often authenticate
	themselves to the EAP server, e.g., by logging into a secure web page		themselves to the EAP server, e.g., by logging into a secure web page
	or API. In this case, the server can reliably associate the peer		or API. In this case, the server can reliably associate the peer
	device with the user account. Applications that make use of EAP-NOOB		device with the user account. Applications that make use of EAP-NOOB
	can use this information for configuring the initial owner of the		can use this information for configuring the initial owner of the
	freshly-registered device.		freshly-registered device.
	6.2. Cloning of Devices		6.2. Identifying correct endpoints
	6.3. Identifying correct endpoints
	Potential weaknesses in EAP-NOOB arise from the fact that the user		Potential weaknesses in EAP-NOOB arise from the fact that the user
	must identify physically the correct peer device. If the attacker is		must identify physically the correct peer device. If the attacker is
	able to trick the user into delivering the OOB message to or from the		able to trick the user into delivering the OOB message to or from the
	wrong peer device, the server may create an association with the		wrong peer device, the server may create an association with the
	wrong peer. This reliance on the user in identifying the correct		wrong peer. This reliance on the user in identifying the correct
	endpoints is an inherent property of user-assisted out-of-band		endpoints is an inherent property of user-assisted out-of-band
	authentication.		authentication.
	It is, however, not possible to exploit accidental delivery of the		It is, however, not possible to exploit accidental delivery of the
	skipping to change at page 42, line 31 ¶		skipping to change at page 43, line 5 ¶
	identity by copying the keys from the persistent EAP-NOOB association		identity by copying the keys from the persistent EAP-NOOB association
	into another device. The attacker can be an outsider who gains		into another device. The attacker can be an outsider who gains
	access to the keys or the device owner who wants to have two devices		access to the keys or the device owner who wants to have two devices
	matching the same registration. The cloning threats can be mitigated		matching the same registration. The cloning threats can be mitigated
	by creating the cryptographic keys and storing the persistent EAP-		by creating the cryptographic keys and storing the persistent EAP-
	NOOB association on the peer device in a secure hardware component		NOOB association on the peer device in a secure hardware component
	such as a trusted execution environment (TEE). Furthermore, remote		such as a trusted execution environment (TEE). Furthermore, remote
	attestation on the application level could provide assurance to the		attestation on the application level could provide assurance to the
	server that the device has not been cloned.		server that the device has not been cloned.
	6.4. Trusted path issues and misbinding attacks		6.3. Trusted path issues and misbinding attacks
	Another potential threat is spoofed user input or output on the peer		Another potential threat is spoofed user input or output on the peer
	device. When the user is delivering the OOB message to or from the		device. When the user is delivering the OOB message to or from the
	correct peer device, a trusted path between the user and the peer		correct peer device, a trusted path between the user and the peer
	device is needed. That is, the user must communicate directly with		device is needed. That is, the user must communicate directly with
	an authentic operating system and EAP-NOOB implementation in the peer		an authentic operating system and EAP-NOOB implementation in the peer
	device and not with a spoofed user interface. Otherwise, a		device and not with a spoofed user interface. Otherwise, a
	registered device that is under the control of the attacker could		registered device that is under the control of the attacker could
	emulate the behavior of an unregistered device. The secure path can		emulate the behavior of an unregistered device. The secure path can
	be implemented, for example, by having the user press a reset button		be implemented, for example, by having the user press a reset button
	skipping to change at page 43, line 25 ¶		skipping to change at page 43, line 47 ¶
	A standardized trusted path for communicating directly with the		A standardized trusted path for communicating directly with the
	trusted computing base in a physical device would mitigate the		trusted computing base in a physical device would mitigate the
	misbinding threat, but such paths rarely exist in practice. Careful		misbinding threat, but such paths rarely exist in practice. Careful
	asset tracking on the server side can also prevent most misbinding		asset tracking on the server side can also prevent most misbinding
	attacks if the peer device sends its identifiers or attributes in the		attacks if the peer device sends its identifiers or attributes in the
	PeerInfo field and the server compares them with the expected values.		PeerInfo field and the server compares them with the expected values.
	The wrong but uncompromised device's PeerInfo will not match the		The wrong but uncompromised device's PeerInfo will not match the
	expected values. Device certification by the manufacturer can		expected values. Device certification by the manufacturer can
	further strengthen the asset tracking.		further strengthen the asset tracking.
	6.5. Peer identifiers and attributes		6.4. Peer identifiers and attributes
	The PeerId value in the protocol is a server-allocated identifier for		The PeerId value in the protocol is a server-allocated identifier for
	its association with the peer and SHOULD NOT be shown to the user		its association with the peer and SHOULD NOT be shown to the user
	because its value is initially ephemeral. Since the PeerId is		because its value is initially ephemeral. Since the PeerId is
	allocated by the server and the scope of the identifier is the single		allocated by the server and the scope of the identifier is the single
	server, the so-called identifier squatting attacks, where a malicious		server, the so-called identifier squatting attacks, where a malicious
	peer could reserve another peer's identifier, are not possible in		peer could reserve another peer's identifier, are not possible in
	EAP-NOOB. The server SHOULD assign a random or pseudo-random PeerId		EAP-NOOB. The server SHOULD assign a random or pseudo-random PeerId
	to each new peer. It SHOULD NOT select the PeerId based on any peer		to each new peer. It SHOULD NOT select the PeerId based on any peer
	characteristics that it may know, such as the peer's link-layer		characteristics that it may know, such as the peer's link-layer
	skipping to change at page 44, line 19 ¶		skipping to change at page 44, line 40 ¶
	the PeerInfo is not authenticated information and should not be		the PeerInfo is not authenticated information and should not be
	relied on.		relied on.
	One possible use for the PeerInfo field is EAP channel binding		One possible use for the PeerInfo field is EAP channel binding
	([RFC3748] Section 7.15). That is, the peer MAY include in PeerInfo		([RFC3748] Section 7.15). That is, the peer MAY include in PeerInfo
	any data items that it wants to bind to the EAP-NOOB association and		any data items that it wants to bind to the EAP-NOOB association and
	to the exported keys. These can be properties of the authenticator		to the exported keys. These can be properties of the authenticator
	or the access link, such as the SSID and BSSID of the wireless		or the access link, such as the SSID and BSSID of the wireless
	network (see Appendix C).		network (see Appendix C).
	6.6. Identity protection		6.5. Identity protection
	The PeerInfo field contains identifiers and other information about		The PeerInfo field contains identifiers and other information about
	the peer device (see Appendix C), and the peer sends this information		the peer device (see Appendix C), and the peer sends this information
	in plaintext to the EAP server before the server authentication in		in plaintext to the EAP server before the server authentication in
	EAP-NOOB has been completed. While the information refers to the		EAP-NOOB has been completed. While the information refers to the
	peer device and not directly to the user, it may be better for user		peer device and not directly to the user, it may be better for user
	privacy to avoid sending unnecessary information. In the Reconnect		privacy to avoid sending unnecessary information. In the Reconnect
	Exchange, the optional PeerInfo SHOULD be omitted unless some		Exchange, which may take place while roaming, the optional PeerInfo
	critical data has changed.		SHOULD be omitted unless some critical data has changed and it cannot
			be updated on the application 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 blacklist misbehaving peer devices and how to avoid		recognize and blacklist misbehaving peer devices and how to avoid
	loss of synchronization between the server and the peer if messages		loss of synchronization between the server and the peer if messages
	are lost during the identifier update.		are lost during the identifier update.
	6.7. Downgrading threats		To enable stronger identity protection in later versions of EAP-NOOB,
			the optional server-assigned NAI (NewNAI) SHOULD have a constant
			username part. The RECOMMENDED username is "noob". The server MAY,
			however, send a different username in NewNAI to avoid username
			collisions within the realm or to conform to its local policy on
			usernames.
			6.6. Downgrading threats
	The fingerprint Hoob protects all the information exchanged in the		The fingerprint Hoob protects all the information exchanged in the
	Initial Exchange, including the cryptosuite negotiation. The message		Initial Exchange, including the cryptosuite negotiation. The message
	authentication codes MACs and MACp also protect the same information.		authentication codes MACs and MACp also protect the same information.
	The message authentication codes MACs2 and MACp2 protect information		The message authentication codes MACs2 and MACp2 protect information
	exchanged during key renegotiation in the Reconnect Exchange. This		exchanged during key renegotiation in the Reconnect Exchange. This
	prevents downgrading attacks to weaker cryptosuites as long as the		prevents downgrading attacks to weaker cryptosuites as long as the
	possible attacks take more time than the maximum time allowed for the		possible attacks take more time than the maximum time allowed for the
	EAP-NOOB completion. This is typically the case for recently		EAP-NOOB completion. This is typically the case for recently
	discovered cryptanalytic attacks.		discovered cryptanalytic attacks.
	skipping to change at page 45, line 37 ¶		skipping to change at page 46, line 19 ¶
	and server are first associated. It is a weaker secret than a		and server are first associated. It is a weaker secret than a
	manually configured random shared key because advances in		manually configured random shared key because advances in
	cryptanalysis against the used ECDHE curve could eventually enable		cryptanalysis against the used ECDHE curve could eventually enable
	the attacker to recover Kz. EAP-NOOB protects against such attacks		the attacker to recover Kz. EAP-NOOB protects against such attacks
	by allowing cryptosuite upgrades in the Reconnect Exchange and by		by allowing cryptosuite upgrades in the Reconnect Exchange and by
	updating the shared key material Kz whenever the cryptosuite is		updating the shared key material Kz whenever the cryptosuite is
	upgraded. We do not expect the cryptosuite upgrades to be frequent,		upgraded. We do not expect the cryptosuite upgrades to be frequent,
	but if an upgrade becomes necessary, it can be done without manual		but if an upgrade becomes necessary, it can be done without manual
	reset and reassociation of the peer devices.		reset and reassociation of the peer devices.
	6.8. Recovery from loss of last message		6.7. Recovery from loss of last message
	The EAP-NOOB Completion Exchange, as well as the Reconnect Exchange		The EAP-NOOB Completion Exchange, as well as the Reconnect Exchange
	with cryptosuite update, result in a persistent state change that		with cryptosuite update, result in a persistent state change that
	should take place either on both endpoints or on neither; otherwise,		should take place either on both endpoints or on neither; otherwise,
	the result is a state mismatch that requires user action to resolve.		the result is a state mismatch that requires user action to resolve.
	The state mismatch can occur if the final EAP response of the		The state mismatch can occur if the final EAP response of the
	exchanges is lost. In the Completion Exchange, the loss of the final		exchanges is lost. In the Completion Exchange, the loss of the final
	response (Type=6) results in the peer moving to Registered (4) state		response (Type=6) results in the peer moving to Registered (4) state
	and creating a persistent EAP-NOOB association while the server stays		and creating a persistent EAP-NOOB association while the server stays
	in an ephemeral state (1 or 2). In the Reconnect Exchange, the loss		in an ephemeral state (1 or 2). In the Reconnect Exchange, the loss
	skipping to change at page 46, line 22 ¶		skipping to change at page 47, line 4 ¶
	normally followed by EAP-Success, [RFC3748] section 4.2 states that		normally followed by EAP-Success, [RFC3748] section 4.2 states that
	the peer MAY assume that the EAP-Success was lost and the		the peer MAY assume that the EAP-Success was lost and the
	authentication was successful. Furthermore, EAP method		authentication was successful. Furthermore, EAP method
	implementations in the peer do not receive notification of the EAP-		implementations in the peer do not receive notification of the EAP-
	Success message from the parent EAP state machine [RFC4137]. For		Success message from the parent EAP state machine [RFC4137]. For
	these reasons, EAP-NOOB on the peer side commits to a state change		these reasons, EAP-NOOB on the peer side commits to a state change
	already when it sends the final response.		already when it sends the final response.
	The best available solution to the loss of the critical message is to		The best available solution to the loss of the critical message is to
	keep trying. EAP retransmission behavior defined in Section 4.3 of		keep trying. EAP retransmission behavior defined in Section 4.3 of
	[RFC3748] suggests 3-5 retransmissions. In the absence of an		[RFC3748] suggests 3-5 retransmissions. In the absence of an
	attacker, this would be sufficient to reduce the probability of		attacker, this would be sufficient to reduce the probability of
	failure to an acceptable level. However, a determined attacker on		failure to an acceptable level. However, a determined attacker on
	the in-band channel can drop the final EAP-Response message and all		the in-band channel can drop the final EAP-Response message and all
	subsequent retransmissions. In the Completion Exchange		subsequent retransmissions. In the Completion Exchange
	(KeyingMode=0) and in the Reconnect Exchange with cryptosuite upgrade		(KeyingMode=0) and in the Reconnect Exchange with cryptosuite upgrade
	(KeyingMode=3), this could result in a state mismatch and persistent		(KeyingMode=3), this could result in a state mismatch and persistent
	denial of service until user resets the peer state.		denial of service until the user resets the peer state.
	EAP-NOOB implements its own recovery mechanism that allows unlimited		EAP-NOOB implements its own recovery mechanism that allows unlimited
	retries of the Reconnect Exchange. When the DoS attacker eventually		retries of the Reconnect Exchange. When the DoS attacker eventually
	stops dropping packets on the in-band channel, the protocol will		stops dropping packets on the in-band channel, the protocol will
	recover. The logic for this recovery mechanism is specified in		recover. The logic for this recovery mechanism is specified in
	Section 3.4.2.		Section 3.4.2.
	EAP-NOOB does not implement the same kind of retry mechanism in the		EAP-NOOB does not implement the same kind of retry mechanism in the
	Completion Exchange. The reason is that there is always a user		Completion Exchange. The reason is that there is always a user
	involved in the initial association process, and the user can repeat		involved in the initial association process, and the user can repeat
	the OOB Step to complete the association after the DoS attacker has		the OOB Step to complete the association after the DoS attacker has
	left. On the other hand, Reconnect Exchange needs to work without		left. On the other hand, Reconnect Exchange needs to work without
	user involvement.		user involvement.
	6.9. EAP security claims		6.8. EAP security claims
	EAP security claims are defined in section 7.2.1 of [RFC3748]. The		EAP security claims are defined in section 7.2.1 of [RFC3748]. The
	security claims for EAP-NOOB are listed in Table 9.		security claims for EAP-NOOB are listed in Table 9.
	+----------------+--------------------------------------------------+		+----------------+--------------------------------------------------+
	| Security | EAP-NOOB claim |		| Security | EAP-NOOB claim |
	| property | |		| property | |
	+----------------+--------------------------------------------------+		+----------------+--------------------------------------------------+
	| Authentication | ECDHE key exchange with out-of-band |		| Authentication | ECDHE key exchange with out-of-band |
	| mechanism | authentication |		| mechanism | authentication |
	skipping to change at page 49, line 41 ¶		skipping to change at page 50, line 41 ¶
	report , 2007.		report , 2007.
	[EUI-48] Institute of Electrical and Electronics Engineers,		[EUI-48] Institute of Electrical and Electronics Engineers,
	"802-2014 IEEE Standard for Local and Metropolitan Area		"802-2014 IEEE Standard for Local and Metropolitan Area
	Networks: Overview and Architecture.", IEEE Standard		Networks: Overview and Architecture.", IEEE Standard
	802-2014. , June 2014.		802-2014. , June 2014.
	[I-D.ietf-rats-eat]		[I-D.ietf-rats-eat]
	Mandyam, G., Lundblade, L., Ballesteros, M., and J.		Mandyam, G., Lundblade, L., Ballesteros, M., and J.
	O'Donoghue, "The Entity Attestation Token (EAT)", draft-		O'Donoghue, "The Entity Attestation Token (EAT)", draft-
	ietf-rats-eat-03 (work in progress), February 2020.		ietf-rats-eat-06 (work in progress), December 2020.
	[I-D.tschofenig-tls-cwt]		[I-D.tschofenig-tls-cwt]
	Tschofenig, H. and M. Brossard, "Using CBOR Web Tokens		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)", draft-tschofenig-tls-		Transport Layer Security (DTLS)", draft-tschofenig-tls-
	cwt-01 (work in progress), November 2019.		cwt-02 (work in progress), July 2020.
	[IEEE-802.1X]		[IEEE-802.1X]
	Institute of Electrical and Electronics Engineers, "Local		Institute of Electrical and Electronics Engineers, "Local
	and Metropolitan Area Networks: Port-Based Network Access		and Metropolitan Area Networks: Port-Based Network Access
	Control", IEEE Standard 802.1X-2004. , December 2004.		Control", IEEE Standard 802.1X-2004. , December 2004.
	[mcrl2] Groote, J. and M. Mousavi, "Modeling and analysis of		[mcrl2] Groote, J. and M. Mousavi, "Modeling and analysis of
	communicating systems", The MIT press , 2014,		communicating systems", The MIT press , 2014,
	<https://mitpress.mit.edu/books/modeling-and-analysis-		<https://mitpress.mit.edu/books/modeling-and-analysis-
	communicating-systems>.		communicating-systems>.
	skipping to change at page 53, line 10 ¶		skipping to change at page 54, line 10 ¶
	Figure 11: How server chooses the exchange type		Figure 11: How server chooses the exchange type
	Figure 12 lists the local events that can take place in the server or		Figure 12 lists the local events that can take place in the server or
	peer. Both the server and peer output and accept OOB messages in		peer. Both the server and peer output and accept OOB messages in
	association state 1, leading the receiver to state 2. Communication		association state 1, leading the receiver to state 2. Communication
	errors and timeouts in states 0..2 lead back to state 0, while		errors and timeouts in states 0..2 lead back to state 0, while
	similar errors in states 3..4 lead to state 3. Application request		similar errors in states 3..4 lead to state 3. Application request
	for rekeying (e.g., to refresh session keys or to upgrade		for rekeying (e.g., to refresh session keys or to upgrade
	cryptosuite) also takes the association from state 3..4 to state 3.		cryptosuite) also takes the association from state 3..4 to state 3.
	User can always reset the association state to 0. Recovering		User can always reset the association state to 0. Recovering
	association data, e.g. from a backup, leads to state 3.		association data, e.g., from a backup, leads to state 3.
	+--------+---------------------------+------------------------------+		+--------+----------------------------------+--------------------+
	| server/| possible local events | next state |		| server/| possible local events | next state |
	| peer | on server and peer | |		| peer | on server and peer | |
	| state | | |		| state | | |
	+========+===========================+==============================+		+========+==================================+====================+
	| 1 | OOB Output* | 1 |		| 1 | OOB Output* | 1 |
	| 1 | OOB Input* | 2 (1 on error) |		| 1 | OOB Input* | 2 (1 on error) |
	| 0..2 | Timeout/network failure | 0 |		| 0..2 | Mobility/timeout/network failure | 0 |
	| 3..4 | Timeout/network failure | 3 |		| 3..4 | Mobility/timeout/network failure | 3 |
	| 3..4 | Rekeying request | 3 |		| 3..4 | Rekeying request | 3 |
	| 0..4 | User resets peer state | 0 |		| 0..4 | User resets association | 0 |
	| 0..4 | Association state recovery| 3 |		| 0..4 | Association state recovery | 3 |
	+--------+---------------------------+------------------------------+		+--------+----------------------------------+--------------------+
	Figure 12: Local events on server and peer		Figure 12: Local events on server and peer
	Appendix B. Application-specific parameters		Appendix B. Application-specific parameters
	Table 10 lists OOB channel parameters that need to be specified in		Table 10 lists OOB channel parameters that need to be specified in
	each application that makes use of EAP-NOOB. The list is not		each application that makes use of EAP-NOOB. The list is not
	exhaustive and is included for the convenience of implementers only.		exhaustive and is included for the convenience of implementers only.
	+--------------------+----------------------------------------------+		+--------------------+----------------------------------------------+
	skipping to change at page 54, line 43 ¶		skipping to change at page 55, line 43 ¶
	Appendix C. ServerInfo and PeerInfo contents		Appendix C. ServerInfo and PeerInfo contents
	The ServerInfo and PeerInfo fields in the Initial Exchange and		The ServerInfo and PeerInfo fields in the Initial Exchange and
	Reconnect Exchange enable the server and peer, respectively, to send		Reconnect Exchange enable the server and peer, respectively, to send
	information about themselves to the other endpoint. They contain		information about themselves to the other endpoint. They contain
	JSON objects whose structure may be specified separately for each		JSON objects whose structure may be specified separately for each
	application and each type of OOB channel. ServerInfo and PeerInfo		application and each type of OOB channel. ServerInfo and PeerInfo
	MAY contain auxiliary data needed for the OOB channel messaging and		MAY contain auxiliary data needed for the OOB channel messaging and
	for EAP channel binding. Table 11 lists some suggested data fields		for EAP channel binding. Table 11 lists some suggested data fields
	for ServerInfo. Further specifications may specify domain-specific		for ServerInfo. Further specifications may specify application-
	ServerInfo and PeerInfo contents.		specific ServerInfo and PeerInfo contents.
	+----------------+--------------------------------------------------+		+----------------+--------------------------------------------------+
	| Data field | Description |		| Data field | Description |
	+----------------+--------------------------------------------------+		+----------------+--------------------------------------------------+
	| Type | Type-tag string that can be used by the peer as |		| Type | Type-tag string that can be used by the peer as |
	| | a hint for how to interpret the ServerInfo |		| | a hint for how to interpret the ServerInfo |
	| | contents. |		| | contents. |
	| | |		| | |
	| ServerName | String that may be used to aid human |		| ServerName | String that may be used to aid human |
	| | identification of the server. |		| | identification of the server. |
	skipping to change at page 56, line 36 ¶		skipping to change at page 57, line 36 ¶
	| SSID | IEEE 802.11 network SSID for channel binding. The |		| SSID | IEEE 802.11 network SSID for channel binding. The |
	| | SSID is a ASCII string. |		| | SSID is a ASCII string. |
	| | |		| | |
	| Base64SSID | IEEE 802.11 network SSID for channel binding. The |		| Base64SSID | IEEE 802.11 network SSID for channel binding. The |
	| | SSID is base64url encoded. Peer SHOULD send at |		| | SSID is base64url encoded. Peer SHOULD send at |
	| | most one of the fields SSID and Base64SSID in |		| | most one of the fields SSID and Base64SSID in |
	| | PeerInfo, and the server SHOULD ignore SSID if |		| | PeerInfo, and the server SHOULD ignore SSID if |
	| | Base64SSID is included. |		| | Base64SSID is included. |
	| | |		| | |
	| BSSID | Wireless network BSSID (EUI-48) in the 12-digit |		| BSSID | Wireless network BSSID (EUI-48) in the 12-digit |
	| | base-16 form [EUI-48]. The string MAY be in upper |		| | base-16 form [EUI-48] for channel binding. The |
	| | or lower case and MAY include additional colon ':' |		| | string MAY be in upper or lower case and MAY |
	| | or dash '-' characters that MUST be ignored by the |		| | include additional colon ':' or dash '-' |
	| | server. |		| | characters that MUST be ignored by the server. |
	| | |		| | |
	+--------------+----------------------------------------------------+		+--------------+----------------------------------------------------+
	Table 12: Suggested PeerInfo data fields		Table 12: Suggested PeerInfo data fields
	Appendix D. EAP-NOOB roaming		Appendix D. EAP-NOOB roaming
	AAA architectures [RFC2904] allow for roaming of network-connected		AAA architectures [RFC2904] allow for roaming of network-connected
	appliances that are authenticated over EAP. While the peer is		appliances that are authenticated over EAP. While the peer is
	roaming in a visited network, authentication still takes place		roaming in a visited network, authentication still takes place
	between the peer and an authentication server at its home network.		between the peer and an authentication server at its home network.
	EAP-NOOB supports such roaming by assigning a Realm to the peer.		EAP-NOOB supports such roaming by allowing the server to assign a NAI
			to the peer. After the NAI has been assigned, it enables the visited
	After the Realm has been assigned, the peer's NAI enables the visited
	network to route the EAP session to the peer's home AAA server.		network to route the EAP session to the peer's home AAA server.
	A peer device that is new or has gone through a hard reset should be		A peer device that is new or has gone through a hard reset should be
	connected first to the home network and establish an EAP-NOOB		connected first to the home network and establish an EAP-NOOB
	association with its home AAA server before it is able to roam.		association with its home AAA server before it is able to roam.
	After that, it can perform the Reconnect Exchange from the visited		After that, it can perform the Reconnect Exchange from the visited
	network.		network.
	Alternatively, the device may provide some method for the user to		Alternatively, the device may provide some method for the user to
	configure the Realm of the home network. In that case, the EAP-NOOB		configure the NAI of the home network. This is the user or
	association can be created while roaming. The device will use the		application configured NAI mentioned in Section 3.3.1. In that case,
	user-assigned Realm in the Initial Exchange, which enables the EAP		the EAP-NOOB association can be created while roaming. The
	messages to be routed correctly to the home AAA server.		configured NAI enables the EAP messages to be routed correctly to the
			home AAA server.
	While roaming, the device needs to identify the networks where the		While roaming, the device needs to identify the networks where the
	EAP-NOOB association can be used to gain network access. For 802.11		EAP-NOOB association can be used to gain network access. For 802.11
	access networks, the server MAY send a list of SSID strings in the		access networks, the server MAY send a list of SSID strings in the
	ServerInfo field called either SSIDList or Base64SSIDList. The list		ServerInfo field called either SSIDList or Base64SSIDList. The list
	is formatted as explained in Table 11. If present, the peer MAY use		is formatted as explained in Table 11. If present, the peer MAY use
	this list as a hint to determine the networks where the EAP-NOOB		this list as a hint to determine the networks where the EAP-NOOB
	association can be used for access authorization, in addition to the		association can be used for access authorization, in addition to the
	access network where the Initial Exchange took place.		access network where the Initial Exchange took place.
	Appendix E. OOB message as URL		Appendix E. OOB message as URL
	While EAP-NOOB does not mandate any particular OOB communication		While EAP-NOOB does not mandate any particular OOB communication
	channel, typical OOB channels include graphical displays and emulated		channel, typical OOB channels include graphical displays and emulated
	NFC tags. In the peer-to-server direction, it may be convenient to		NFC tags. In the peer-to-server direction, it may be convenient to
	encode the OOB message as a URL, which is then encoded as a QR code		encode the OOB message as a URL, which is then encoded as a QR code
	for displays and printers or as an NDEF record for NFC tags. A user		for displays and printers or as an NDEF record for dynamic NFC tags.
	can then simply scan the QR code or NFC tag and open the URL, which		A user can then simply scan the QR code or NFC tag and open the URL,
	causes the OOB message to be delivered to the authentication server.		which causes the OOB message to be delivered to the authentication
	The URL MUST specify the https protocol, so that there is a secure		server. The URL MUST specify the https protocol, so that there is a
	connection to the server and the man-in-the-middle attacker cannot		secure connection to the server and the man-in-the-middle attacker
	read or modify the OOB message.		cannot read or modify the OOB message.
	The ServerInfo in this case includes a field called ServerUrl of the		The ServerInfo in this case includes a field called ServerUrl of the
	following format with RECOMMENDED length of 60 characters or less:		following format with RECOMMENDED length of 60 characters or less:
	https://<host>[:<port>]/[<path>]		https://<host>[:<port>]/[<path>]
	To this, the peer appends the OOB message fields (PeerId, Noob, Hoob)		To this, the peer appends the OOB message fields (PeerId, Noob, Hoob)
	as a query string. PeerId is provided to the peer by the server and		as a query string. PeerId is provided to the peer by the server and
	might be a 22-character ASCII string. The peer base64url encodes,		might be a 22-character ASCII string. The peer base64url encodes,
	without padding, the 16-byte values Noob and Hoob into 22-character		without padding, the 16-byte values Noob and Hoob into 22-character
	ASCII strings. The query parameters MAY be in any order. The		ASCII strings. The query parameters MAY be in any order. The
	resulting URL is of the following format:		resulting URL is of the following format:
	https://<host>[:<port>]/[<path>]?P=<PeerId>&N=<Noob>&H=<Hoob>		https://<host>[:<port>]/[<path>]?P=<PeerId>&N=<Noob>&H=<Hoob>
	The following is an example of a well-formed URL encoding the OOB		The following is an example of a well-formed URL encoding the OOB
	message (without line breaks):		message (without line breaks):
	https://example.com/Noob?P=ZrD7qkczNoHGbGcN2bN0&N=rMinS0-F4EfCU8D9ljx		https://aaa.example.com/eapnoob?P=mcm5BSCDZ45cYPlAr1ghNw&N=rMinS0-F4E
	X_A&H=QvnMp4UGxuQVFaXPW_14UW		fCU8D9ljxX_A&H=QvnMp4UGxuQVFaXPW_14UW
	Appendix F. Example messages		Appendix F. Example messages
	The message examples in this section are generated with Curve25519		The message examples in this section are generated with Curve25519
	ECDHE test vectors specified in section 6.1 of [RFC7748]		ECDHE test vectors specified in section 6.1 of [RFC7748]
	(server=Alice, peer=Bob). The direction of the OOB channel		(server=Alice, peer=Bob). The direction of the OOB channel
	negotiated is 2 (server-to-peer). The JSON messages are as follows		negotiated is 2 (server-to-peer). The JSON messages are as follows
	(line breaks are for readability only).		(line breaks are for readability only).
	====== Initial Exchange ======		====== Initial Exchange ======
	skipping to change at page 58, line 33 ¶		skipping to change at page 59, line 35 ¶
	Identity response:		Identity response:
	noob@eap-noob.arpa		noob@eap-noob.arpa
	EAP request (type 1):		EAP request (type 1):
	{"Type":1}		{"Type":1}
	EAP response (type 1):		EAP response (type 1):
	{"Type":1,"PeerState":0}		{"Type":1,"PeerState":0}
	EAP request (type 2):		EAP request (type 2):
	{"Type":2,"Vers":[1],"PeerId":"07KRU6OgqX0HIeRFldnbSW","Realm":"no		{"Type":2,"Vers":[1],"PeerId":"07KRU6OgqX0HIeRFldnbSW","NewNAI":"n
	ob.example.com","Cryptosuites":[1,2],"Dirs":3,"ServerInfo":{"Type"		oob@example.org","Cryptosuites":[1,2],"Dirs":3,"ServerInfo":{"Type
	:"url_wifi","Name":"Example","Url":"https://noob.example.com/		":"url_wifi","Name":"Example","Url":"https://noob.example.org/
	sendOOB"}}		sendOOB"}}
	EAP response (type 2):		EAP response (type 2):
	{"Type":2,"Verp":1,"PeerId":"07KRU6OgqX0HIeRFldnbSW","Cryptosuitep		{"Type":2,"Verp":1,"PeerId":"07KRU6OgqX0HIeRFldnbSW","Cryptosuitep
	":1,"Dirp":2,"PeerInfo":{"Type":"wifi","Make":"Acme","Serial":"DU-		":1,"Dirp":2,"PeerInfo":{"Type":"wifi","Make":"Acme","Serial":"DU-
	9999","SSID":"Noob1","BSSID":"6c:19:8f:83:c2:80"}}		9999","SSID":"Noob1","BSSID":"6c:19:8f:83:c2:80"}}
	EAP request (type 3):		EAP request (type 3):
	{"Type":3,"PeerId":"07KRU6OgqX0HIeRFldnbSW","PKs":{"kty":"EC","crv		{"Type":3,"PeerId":"07KRU6OgqX0HIeRFldnbSW","PKs":{"kty":"EC","crv
	":"X25519","x":"hSDwCYkwp1R0i33ctD73Wg2_Og0mOBr066SpjqqbTmo"},"Ns"		":"X25519","x":"hSDwCYkwp1R0i33ctD73Wg2_Og0mOBr066SpjqqbTmo"},"Ns"
	skipping to change at page 58, line 49 ¶		skipping to change at page 60, line 4 ¶
	{"Type":2,"Verp":1,"PeerId":"07KRU6OgqX0HIeRFldnbSW","Cryptosuitep		{"Type":2,"Verp":1,"PeerId":"07KRU6OgqX0HIeRFldnbSW","Cryptosuitep
	":1,"Dirp":2,"PeerInfo":{"Type":"wifi","Make":"Acme","Serial":"DU-		":1,"Dirp":2,"PeerInfo":{"Type":"wifi","Make":"Acme","Serial":"DU-
	9999","SSID":"Noob1","BSSID":"6c:19:8f:83:c2:80"}}		9999","SSID":"Noob1","BSSID":"6c:19:8f:83:c2:80"}}
	EAP request (type 3):		EAP request (type 3):
	{"Type":3,"PeerId":"07KRU6OgqX0HIeRFldnbSW","PKs":{"kty":"EC","crv		{"Type":3,"PeerId":"07KRU6OgqX0HIeRFldnbSW","PKs":{"kty":"EC","crv
	":"X25519","x":"hSDwCYkwp1R0i33ctD73Wg2_Og0mOBr066SpjqqbTmo"},"Ns"		":"X25519","x":"hSDwCYkwp1R0i33ctD73Wg2_Og0mOBr066SpjqqbTmo"},"Ns"
	:"PYO7NVd9Af3BxEri1MI6hL8Ck49YxwCjSRPqlC1SPbw","SleepTime":60}		:"PYO7NVd9Af3BxEri1MI6hL8Ck49YxwCjSRPqlC1SPbw","SleepTime":60}
	EAP response (type 3):		EAP response (type 3):
	{"Type":3,"PeerId":"07KRU6OgqX0HIeRFldnbSW","PKp":{"kty":"EC","crv		{"Type":3,"PeerId":"07KRU6OgqX0HIeRFldnbSW","PKp":{"kty":"EC","crv
	":"X25519","x":"3p7bfXt9wbTTW2HC7OQ1Nz-DQ8hbeGdNrfx-FG-		":"X25519","x":"3p7bfXt9wbTTW2HC7OQ1Nz-DQ8hbeGdNrfx-FG-
	IK08"},"Np":"HIvB6g0n2btpxEcU7YXnWB-451ED6L6veQQd6ugiPFU"}		IK08"},"Np":"HIvB6g0n2btpxEcU7YXnWB-451ED6L6veQQd6ugiPFU"}
	====== Waiting Exchange ======		====== Waiting Exchange ======
	Identity response:		Identity response:
	noob@noob.example.com		noob@example.org
	EAP request (type 1):		EAP request (type 1):
	{"Type":1}		{"Type":1}
	EAP response (type 1):		EAP response (type 1):
	{"Type":1,"PeerId":"07KRU6OgqX0HIeRFldnbSW","PeerState":1}		{"Type":1,"PeerId":"07KRU6OgqX0HIeRFldnbSW","PeerState":1}
	EAP request (type 4):		EAP request (type 4):
	{"Type":4,"PeerId":"07KRU6OgqX0HIeRFldnbSW","SleepTime":60}		{"Type":4,"PeerId":"07KRU6OgqX0HIeRFldnbSW","SleepTime":60}
	EAP response (type 4):		EAP response (type 4):
	{"Type":4,"PeerId":"07KRU6OgqX0HIeRFldnbSW"}		{"Type":4,"PeerId":"07KRU6OgqX0HIeRFldnbSW"}
	====== OOB Step ======		====== OOB Step ======
	OOB message:		OOB message:
	P=07KRU6OgqX0HIeRFldnbSW&N=x3JlolaPciK4Wa6XlMJxtQ&H=W3-icQoP19bJzJ		P=07KRU6OgqX0HIeRFldnbSW&N=x3JlolaPciK4Wa6XlMJxtQ&H=unFfhYbHTzcDtV
	zI3kvpTA		uMso7Bmw
	====== Completion Exchange ======		====== Completion Exchange ======
	Identity response:		Identity response:
	noob@noob.example.com		noob@example.org
	EAP request (type 1):		EAP request (type 1):
	{"Type":1}		{"Type":1}
	EAP response (type 1):		EAP response (type 1):
	{"Type":1,"PeerId":"07KRU6OgqX0HIeRFldnbSW","PeerState":2}		{"Type":1,"PeerId":"07KRU6OgqX0HIeRFldnbSW","PeerState":2}
	EAP request (type 5):		EAP request (type 5):
	{"Type":5,"PeerId":"07KRU6OgqX0HIeRFldnbSW"}		{"Type":5,"PeerId":"07KRU6OgqX0HIeRFldnbSW"}
	EAP response (type 5):		EAP response (type 5):
	{"Type":5,"PeerId":"07KRU6OgqX0HIeRFldnbSW","NoobId":"U0OHwYGCS4nE		{"Type":5,"PeerId":"07KRU6OgqX0HIeRFldnbSW","NoobId":"U0OHwYGCS4nE
	kzk2TPIE6g"}		kzk2TPIE6g"}
	EAP request (type 6):		EAP request (type 6):
	{"Type":6,"PeerId":"07KRU6OgqX0HIeRFldnbSW","NoobId":"U0OHwYGCS4nE		{"Type":6,"PeerId":"07KRU6OgqX0HIeRFldnbSW","NoobId":"U0OHwYGCS4nE
	kzk2TPIE6g","MACs":"yQTuMzkEBblsjCTUCTqHTbOR5Z2fs7s1tqMeCFqQT0k"}		kzk2TPIE6g","MACs":"caIpiJr3xjjfg--w1s9CVgDiDrIHrCJQyZ_NWsRO9HQ"}
	EAP response (type 6):		EAP response (type 6):
	{"Type":6,"PeerId":"07KRU6OgqX0HIeRFldnbSW","MACp":"MZOEIma1mHZUL2		{"Type":6,"PeerId":"07KRU6OgqX0HIeRFldnbSW","MACp":"5ouhafoqzbNY4S
	_kJX8KMhGDBNkvwqamiv8cCjxIZgM"}		NiPlGCkXynS5zx7su1TMQnlmrPXws"}
	====== Reconnect Exchange (KeyingMode = 1) ======		====== Reconnect Exchange (KeyingMode = 1) ======
	Identity response:		Identity response:
	noob@noob.example.com		noob@example.org
	EAP request (type 1):		EAP request (type 1):
	{"Type":1}		{"Type":1}
	EAP response (type 1):		EAP response (type 1):
	{"Type":1,"PeerId":"07KRU6OgqX0HIeRFldnbSW","PeerState":3}		{"Type":1,"PeerId":"07KRU6OgqX0HIeRFldnbSW","PeerState":3}
	EAP request (type 7):		EAP request (type 7):
	{"Type":7,"Vers":[1],"PeerId":"07KRU6OgqX0HIeRFldnbSW","Cryptosuit		{"Type":7,"Vers":[1],"PeerId":"07KRU6OgqX0HIeRFldnbSW","Cryptosuit
	es":[1,2],"Realm":"noob.example.com","ServerInfo":{"Type":"url_wif		es":[1,2]}
	i","Name":"Example","Url":"https://noob.example.com/sendOOB"}}
	EAP response (type 7):		EAP response (type 7):
	{"Type":7,"Verp":1,"PeerId":"07KRU6OgqX0HIeRFldnbSW","Cryptosuitep		{"Type":7,"Verp":1,"PeerId":"07KRU6OgqX0HIeRFldnbSW","Cryptosuitep
	":1,"PeerInfo":{"Type":"wifi","Make":"Acme","Serial":"DU-		":2}
	9999","SSID":"Noob1","BSSID":"6c:19:8f:83:c2:80"}}
	EAP request (type 8):		EAP request (type 8):
	{"Type":8,"PeerId":"07KRU6OgqX0HIeRFldnbSW","KeyingMode":1,"Ns2":"		{"Type":8,"PeerId":"07KRU6OgqX0HIeRFldnbSW","KeyingMode":1,"Ns2":"
	RDLahHBlIgnmL_F_xcynrHurLPkCsrp3G3B_S82WUF4"}		RDLahHBlIgnmL_F_xcynrHurLPkCsrp3G3B_S82WUF4"}
	EAP response (type 8):		EAP response (type 8):
	{"Type":8,"PeerId":"07KRU6OgqX0HIeRFldnbSW","Np2":"jN0_V4P0JoTqwI9		{"Type":8,"PeerId":"07KRU6OgqX0HIeRFldnbSW","Np2":"jN0_V4P0JoTqwI9
	VHHQKd9ozUh7tQdc9ABd-j6oTy_4"}		VHHQKd9ozUh7tQdc9ABd-j6oTy_4"}
	EAP request (type 9):		EAP request (type 9):
	{"Type":9,"PeerId":"07KRU6OgqX0HIeRFldnbSW","MACs2":"WsZU_JZNhE1ju		{"Type":9,"PeerId":"07KRU6OgqX0HIeRFldnbSW","MACs2":"kQpDAb8W5set6
	dcVeEbIhiDEo1OXXOAxqxxgEP2FckI"}		juShu10Kqa_qZ12NDTAq6S6ca_RzXI"}
	EAP response (type 9):		EAP response (type 9):
	{"Type":9,"PeerId":"07KRU6OgqX0HIeRFldnbSW","MACp2":"sopB5xkLBjZBC		{"Type":9,"PeerId":"07KRU6OgqX0HIeRFldnbSW","MACp2":"l3-
	81GE3YXdBDDadqRFh1vQTGIBXnr_Dk"}		f_WAlQuriP-_OaHA9IY6gWYUsM5Ngz3hk83PLgBc"}
	====== Reconnect Exchange (KeyingMode = 2) ======		====== Reconnect Exchange (KeyingMode = 2) ======
	Identity response:		Identity response:
	noob@noob.example.com		noob@example.org
	EAP request (type 1):		EAP request (type 1):
	{"Type":1}		{"Type":1}
	EAP response (type 1):		EAP response (type 1):
	{"Type":1,"PeerId":"07KRU6OgqX0HIeRFldnbSW","PeerState":3}		{"Type":1,"PeerId":"07KRU6OgqX0HIeRFldnbSW","PeerState":3}
	EAP request (type 7):		EAP request (type 7):
	{"Type":7,"Vers":[1],"PeerId":"07KRU6OgqX0HIeRFldnbSW","Cryptosuit		{"Type":7,"Vers":[1],"PeerId":"07KRU6OgqX0HIeRFldnbSW","Cryptosuit
	es":[1,2],"Realm":"noob.example.com","ServerInfo":{"Type":"url_wif		es":[1,2]}
	i","Name":"Example","Url":"https://noob.example.com/sendOOB"}}
	EAP response (type 7):		EAP response (type 7):
	{"Type":7,"Verp":1,"PeerId":"07KRU6OgqX0HIeRFldnbSW","Cryptosuitep		{"Type":7,"Verp":1,"PeerId":"07KRU6OgqX0HIeRFldnbSW","Cryptosuitep
	":1,"PeerInfo":{"Type":"wifi","Make":"Acme","Serial":"DU-		":1}
	9999","SSID":"Noob1","BSSID":"6c:19:8f:83:c2:80"}}
	EAP request (type 8):		EAP request (type 8):
	{"Type":8,"PeerId":"07KRU6OgqX0HIeRFldnbSW","KeyingMode":2,"PKs2":		{"Type":8,"PeerId":"07KRU6OgqX0HIeRFldnbSW","KeyingMode":2,"PKs2":
	{"kty":"EC","crv":"X25519","x":"hSDwCYkwp1R0i33ctD73Wg2_Og0mOBr066		{"kty":"EC","crv":"X25519","x":"hSDwCYkwp1R0i33ctD73Wg2_Og0mOBr066
	SpjqqbTmo"},"Ns2":"RDLahHBlIgnmL_F_xcynrHurLPkCsrp3G3B_S82WUF4"}		SpjqqbTmo"},"Ns2":"RDLahHBlIgnmL_F_xcynrHurLPkCsrp3G3B_S82WUF4"}
	EAP response (type 8):		EAP response (type 8):
	{"Type":8,"PeerId":"07KRU6OgqX0HIeRFldnbSW","PKp2":{"kty":"EC","cr		{"Type":8,"PeerId":"07KRU6OgqX0HIeRFldnbSW","PKp2":{"kty":"EC","cr
	v":"X25519","x":"3p7bfXt9wbTTW2HC7OQ1Nz-DQ8hbeGdNrfx-FG-		v":"X25519","x":"3p7bfXt9wbTTW2HC7OQ1Nz-DQ8hbeGdNrfx-FG-
	IK08"},"Np2":"jN0_V4P0JoTqwI9VHHQKd9ozUh7tQdc9ABd-j6oTy_4"}		IK08"},"Np2":"jN0_V4P0JoTqwI9VHHQKd9ozUh7tQdc9ABd-j6oTy_4"}
	EAP request (type 9):		EAP request (type 9):
	{"Type":9,"PeerId":"07KRU6OgqX0HIeRFldnbSW","MACs2":"CJ6bIYcSMvWD6		{"Type":9,"PeerId":"07KRU6OgqX0HIeRFldnbSW","MACs2":"cjKfWIXhAnqBC
	NIq1zikdnmwVlvOJBJ3TODkg7QCl40"}		0XbWgpbL3FFQ6KJBh2_E7dMig8QyoY"}
	EAP response (type 9):		EAP response (type 9):
	{"Type":9,"PeerId":"07KRU6OgqX0HIeRFldnbSW","MACp2":"TUP9IqEK78y4Q		{"Type":9,"PeerId":"07KRU6OgqX0HIeRFldnbSW","MACp2":"H-7SS9fJfAyPu
	fmsjDIijlLHHq3EgcQ_mYhXT0LSpmk"}		nOq4MYCGYLRwN_xxklgf4WuqyCJ84g"}
	====== Reconnect Exchange (KeyingMode = 3) ======		====== Reconnect Exchange (KeyingMode = 3) ======
	These message examples show the case where the peer upgrades to		These message examples show the case where the peer upgrades to
	Cryptosuite 2 during the Reconnect Exchange. The messages are		Cryptosuite 2 during the Reconnect Exchange. The messages are
	generated with NIST P-256 ECDHE test vectors specified in section 8.1		generated with NIST P-256 ECDHE test vectors specified in section 8.1
	of [RFC5903] (server=responder, peer=initiator).		of [RFC5903] (server=responder, peer=initiator).
	Identity response:		Identity response:
	noob@noob.example.com		noob@example.org
	EAP request (type 1):		EAP request (type 1):
	{"Type":1}		{"Type":1}
	EAP response (type 1):		EAP response (type 1):
	{"Type":1,"PeerId":"07KRU6OgqX0HIeRFldnbSW","PeerState":3}		{"Type":1,"PeerId":"07KRU6OgqX0HIeRFldnbSW","PeerState":3}
	EAP request (type 7):		EAP request (type 7):
	{"Type":7,"Vers":[1],"PeerId":"07KRU6OgqX0HIeRFldnbSW","Cryptosuit		{"Type":7,"Vers":[1],"PeerId":"07KRU6OgqX0HIeRFldnbSW","Cryptosuit
	es":[1,2],"Realm":"noob.example.com","ServerInfo":{"Type":"url_wif		es":[1,2]}
	i","Name":"Example","Url":"https://noob.example.com/sendOOB"}}
	EAP response (type 7):		EAP response (type 7):
	{"Type":7,"Verp":1,"PeerId":"07KRU6OgqX0HIeRFldnbSW","Cryptosuitep		{"Type":7,"Verp":1,"PeerId":"07KRU6OgqX0HIeRFldnbSW","Cryptosuitep
	":2,"PeerInfo":{"Type":"wifi","Make":"Acme","Serial":"DU-		":2}
	9999","SSID":"Noob1","BSSID":"6c:19:8f:83:c2:80"}}
	EAP request (type 8):		EAP request (type 8):
	{"Type":8,"PeerId":"07KRU6OgqX0HIeRFldnbSW","KeyingMode":3,"PKs2":		{"Type":8,"PeerId":"07KRU6OgqX0HIeRFldnbSW","KeyingMode":3,"PKs2":
	{"kty":"EC","crv":"P-256","x":"2tC2U5QiHPmwUeH-yleH0Jjf5jf8kLnvlF0		{"kty":"EC","crv":"P-256","x":"2tC2U5QiHPmwUeH-yleH0Jjf5jf8kLnvlF0
	MN3JYEYA","y":"UnGgRhzbglLWHxxFb6PlmrH0WzOsz19YOJ4Fd7iZC7M"},"Ns2"		MN3JYEYA","y":"UnGgRhzbglLWHxxFb6PlmrH0WzOsz19YOJ4Fd7iZC7M"},"Ns2"
	:"RDLahHBlIgnmL_F_xcynrHurLPkCsrp3G3B_S82WUF4"}		:"RDLahHBlIgnmL_F_xcynrHurLPkCsrp3G3B_S82WUF4"}
	EAP response (type 8):		EAP response (type 8):
	{"Type":8,"PeerId":"07KRU6OgqX0HIeRFldnbSW","PKp2":{"kty":"EC","cr		{"Type":8,"PeerId":"07KRU6OgqX0HIeRFldnbSW","PKp2":{"kty":"EC","cr
	v":"P-256","x":"0S37UonI1PgSCLcCcDmMNCKWlwoLzLdMc2_HVUSUv2M","y":"		v":"P-256","x":"0S37UonI1PgSCLcCcDmMNCKWlwoLzLdMc2_HVUSUv2M","y":"
	VvvzyjZswj6BV4VME8WNaqwj8Eatow-DU-		VvvzyjZswj6BV4VME8WNaqwj8Eatow-DU-
	dPMwOYcqs"},"Np2":"jN0_V4P0JoTqwI9VHHQKd9ozUh7tQdc9ABd-j6oTy_4"}		dPMwOYcqs"},"Np2":"jN0_V4P0JoTqwI9VHHQKd9ozUh7tQdc9ABd-j6oTy_4"}
	EAP request (type 9):		EAP request (type 9):
	{"Type":9,"PeerId":"07KRU6OgqX0HIeRFldnbSW","MACs2":"Baj0VovNadExD		{"Type":9,"PeerId":"07KRU6OgqX0HIeRFldnbSW","MACs2":"j94I1oGeUfVc7
	WhuY-ehTy92AgV236Xilx-hcjuePOs"}		wrUHjPm_babIQUTUp5esSeAt2LhYC4"}
	EAP response (type 9):		EAP response (type 9):
	{"Type":9,"PeerId":"07KRU6OgqX0HIeRFldnbSW","MACp2":"8NZNZJqaptSsB		{"Type":9,"PeerId":"07KRU6OgqX0HIeRFldnbSW","MACp2":"-aIFkKDNyCC8n
	A8CdCrfTfx1gBgdsdqW28oAAG27LpM"}		S6_uEv0ZePLX2AQ_ZQOLYS5wqe7dAc"}
	Appendix G. TODO list
	o Update EAP Method Type number assigned by IANA
	o Update reserved domain name.
	Appendix H. Version history		Appendix G. Version history
	o Version 01:		o Version 01:
	* Fixed Reconnection Exchange.		* Fixed Reconnection Exchange.
	* URL examples.		* URL examples.
	* Message examples.		* Message examples.
	* Improved state transition (event) tables.		* Improved state transition (event) tables.
	skipping to change at page 65, line 34 ¶		skipping to change at page 66, line 24 ¶
	o WG Version 02:		o WG Version 02:
	* Updated message examples with all KeyingModes.		* Updated message examples with all KeyingModes.
	* Many editorial fixes and other updates based on the IoT		* Many editorial fixes and other updates based on the IoT
	directorate review of Dave Thaler.		directorate review of Dave Thaler.
	* Text on cloning attacks based on review by Hannes Tschofenig.		* Text on cloning attacks based on review by Hannes Tschofenig.
	Appendix I. Acknowledgments		o WG Version 03:
	Aleksi Peltonen modeled the protocol specification with the mCRL2		* Changed server-assigned Realm to server-assigned NAI to avoid
	formal specification language. Max Crone, Shiva Prasad TP, and		username collisions. This issue was identified in a review by
	Raghavendra MS implemented parts of the protocol with wpa_supplicant		Alan Dekok.
	and hostapd. Their inputs helped us in improving the specification.
			* Minor editorial improvements.
			Appendix H. Acknowledgments
			Max Crone, Shiva Prasad TP, and Raghavendra MS implemented parts of
			this protocol with wpa_supplicant and hostapd. Eduardo Ingles (RFC
			editor: please add an accented e in Ingles) and Dan Garcia-Carrillo
			were involved in the implementation of this protocol on Contiki.
			Their inputs helped us in improving the specification.
	The authors would like to thank Rhys Smith and Josh Howlett for		The authors would like to thank Rhys Smith and Josh Howlett for
	providing valuable feedback as well as new use cases and requirements		providing valuable feedback as well as new use cases and requirements
	for the protocol. Thanks to Eric Rescorla, Darshak Thakore, Stefan		for the protocol. Thanks to Eric Rescorla, Alan Dekok, Darshak
	Winter, Hannes Tschofenig, and Daniel Migault for interesting		Thakore, Stefan Winter, Hannes Tschofenig, and Daniel Migault for
	discussions in this problem space.		their comments and reviews.
	We would also like to express our sincere gratitude to Dave Thaler		We would also like to express our sincere gratitude to Dave Thaler
	for his thorough review of the document.		for his thorough review of the document.
	Authors' Addresses		Authors' Addresses
	Tuomas Aura		Tuomas Aura
	Aalto University		Aalto University
	Aalto 00076		Aalto 00076
	Finland		Finland
	EMail: tuomas.aura@aalto.fi		EMail: tuomas.aura@aalto.fi
	Mohit Sethi		Mohit Sethi
	Ericsson		Ericsson
	Jorvas 02420		Jorvas 02420
	Finland		Finland
	EMail: mohit@piuha.net		EMail: mohit@piuha.net
			Aleksi Peltonen
			Aalto University
			Aalto 00076
			Finland
			EMail: aleksi.peltonen@aalto.fi
End of changes. 100 change blocks.
	277 lines changed or deleted		308 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/