<?xml version="1.0"encoding="us-ascii"?>encoding="UTF-8"?> <!DOCTYPE rfcSYSTEM "rfc2629.dtd"[ <!ENTITYRFC2104 SYSTEM "reference.RFC.2104.xml">nbsp " "> <!ENTITYRFC2119 SYSTEM "reference.RFC.2119.xml">zwsp "​"> <!ENTITYRFC3748 SYSTEM "reference.RFC.3748.xml">nbhy "‑"> <!ENTITYRFC4137 SYSTEM "reference.RFC.4137.xml"> <!ENTITY RFC3986 SYSTEM "reference.RFC.3986.xml"> <!ENTITY RFC4648 SYSTEM "reference.RFC.4648.xml"> <!ENTITY RFC5216 SYSTEM "reference.RFC.5216.xml"> <!ENTITY RFC5247 SYSTEM "reference.RFC.5247.xml"> <!ENTITY RFC6234 SYSTEM "reference.RFC.6234.xml"> <!ENTITY RFC7517 SYSTEM "reference.RFC.7517.xml"> <!ENTITY RFC7542 SYSTEM "reference.RFC.7542.xml"> <!ENTITY RFC7748 SYSTEM "reference.RFC.7748.xml"> <!ENTITY RFC7942 SYSTEM "reference.RFC.7942.xml"> <!ENTITY RFC8126 SYSTEM "reference.RFC.8126.xml"> <!ENTITY RFC8174 SYSTEM "reference.RFC.2119.xml"> <!ENTITY RFC8259 SYSTEM "reference.RFC.8259.xml"> <!ENTITY newline " ">wj "⁠"> ]><?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?> <?rfc strict="yes"?> <?rfc toc="yes"?> <?rfc tocdepth="4"?> <?rfc symrefs="yes"?> <?rfc sortrefs="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?> <?rfc rfcedstyle="yes"?><rfccategory="std"xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-emu-eap-noob-06"ipr="trust200902">number="9140" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3"> <!-- xml2rfc v2v3 conversion 3.9.1 --> <front> <title abbrev="EAP-NOOB">Nimbleout-of-band authenticationOut-of-Band Authentication for EAP(EAP-NOOB)</title>(EAP&nbhy;NOOB)</title> <seriesInfo name="RFC" value="9140"/> <author initials="T" surname="Aura" fullname="Tuomas Aura"> <organization>Aalto University</organization> <address> <postal><street></street><street/> <city>Aalto</city> <code>00076</code> <country>Finland</country> </postal> <email>tuomas.aura@aalto.fi</email> </address> </author> <author initials="M" surname="Sethi" fullname="Mohit Sethi"> <organization>Ericsson</organization> <address> <postal><street></street><street/> <city>Jorvas</city> <code>02420</code> <country>Finland</country> </postal><email>mohit@piuha.net</email><email>mohit@iki.fi</email> </address> </author> <author initials="A" surname="Peltonen" fullname="Aleksi Peltonen"> <organization>Aalto University</organization> <address> <postal><street></street><street/> <city>Aalto</city> <code>00076</code> <country>Finland</country> </postal> <email>aleksi.peltonen@aalto.fi</email> </address> </author> <date/>year="2021" month="December"/> <area>Security</area><workgroup>Network Working Group</workgroup><workgroup>EAP Method Update</workgroup> <keyword>IoT security</keyword> <keyword>cybersecurity</keyword> <keyword>network access authorization</keyword> <keyword>Extensible Authentication Protocol</keyword> <keyword>key exchange</keyword> <abstract><t> The<t>The Extensible Authentication Protocol (EAP) provides support for multiple authentication methods. This document defines the EAP-NOOB authentication method for nimble out-of-band (OOB)authentication,authentication and key derivation. The EAP method is intended for bootstrapping all kinds of Internet-of-Things (IoT) devices that have nopre-configuredpreconfigured authentication credentials. The method makes use of auser-assisted one-directional OOBuser-assisted, one-directional, out-of-band (OOB) message between the peer device and authentication server to authenticate the in-band key exchange. The device must have anon-networknonnetwork input or output interface, such as a display, microphone, speaker, or blinking light,whichthat can send or receive dynamically generated messages of tens of bytes inlength. </t>length.</t> </abstract> </front> <middle> <sectiontitle="Introduction" anchor="introduction"> <t> Thisanchor="introduction" numbered="true" toc="default"> <name>Introduction</name> <t>This document describes a method for registration,authenticationauthentication, and key derivation for network-connected smart devices, such as consumer and enterprise appliances that are part of the Internet of Things (IoT). These devices may be off-the-shelf hardware that is sold and distributed without any prior registration or credential-provisioning process, or they may be recycled devices after a hard reset. Thus, the device registration in a server database, ownership of the device, and the authentication credentials for both network access and application-level security must all be established at the time of the device deployment. Furthermore, many such devices have only limited user interfaces that could be used for their configuration. Often, the user interfaces are limited to either only input (e.g., a camera) or output (e.g., a display screen). The device configuration is made more challenging by the fact that the devices may exist in large numbers and may have to be deployed orre-configuredreconfigured nimbly based on userneeds. </t>needs.</t> <t>To summarize, devices may have the followingcharacteristics: <list style="symbols"> <t>no pre-establishedcharacteristics:</t> <ul spacing="normal"> <li>no preestablished relation with the intended server oruser, </t> <t>no pre-provisioneduser,</li> <li>no preprovisioned device identifier or authentication credentials,</t> <t>inputor</li> <li>an input or output interface that may be capable of only one-directional out-of-bandcommunication. </t> </list> </t> <t> Manycommunication.</li> </ul> <t>Many proprietary out-of-band (OOB) configuration methods exist for specific IoT devices. The goal of this specification is to provide an open standard and a generic protocol for bootstrapping the security of network-connected appliances, such as displays, printers, speakers, and cameras. The security bootstrapping in this specification makes use of a user-assisted OOB channel. The device authentication relies on a user having physical access to the device, and the key exchange security is based on the assumption that attackers are not able to observe or modify the messages conveyed through the OOB channel. We follow the common approach taken in pairing protocols: performing a Diffie-Hellman key exchange over the insecure network and authenticating the established key with the help of the OOB channel in order to prevent impersonationattacks. </t> <t> Theattacks.</t> <t>The solution presented here is intended for devices that have either anon-networknonnetwork input or output interface, such as a camera, microphone, display screen,speakersspeaker, or blinkingLEDLight Emitting Diode (LED) light,whichthat is able to send or receive dynamically generated messages of tens of bytes in length. Naturally, this solution may not be appropriate for very small sensors or actuators that have no user interface at all or for devices that are inaccessible to the user. We also assume that the OOB channel is at least partly automated (e.g., a camera scanning a barcode) and,code); thus, there is no need to absolutely minimize the length of the data transferred through the OOB channel. This differs, for example, from Bluetooth pairing <xreftarget="BluetoothPairing"/>,target="Bluetooth" format="default"/>, where it is essential to minimize the length of the manually transferred or compared codes. The OOB messages in this specification are dynamically generated.We thusThus, we do not support static printed registration codes. One reason for requiring dynamic OOB messages is that the receipt of the OOB message authorizes the server to take ownership of the device. Dynamic OOB messages are more secure than static printed codes, which could be leaked and latermisused. </t>misused.</t> </section> <sectiontitle="Terminology" anchor="terminology"> <t> Theanchor="terminology" numbered="true" toc="default"> <name>Terminology</name> <t>The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xreftarget='RFC2119'/>target="RFC2119"/> <xreftarget='RFC8174'/>target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere. </t> <t> Inhere.</t> <t>In addition, this document frequently uses the following terms as they have been defined in <xreftarget="RFC5216"/>: <list style="hanging" hangIndent="6"> <t hangText="authenticator"> Thetarget="RFC5216" format="default"/>:</t> <dl newline="true" spacing="normal" indent="6"> <dt>authenticator</dt> <dd>The entity initiating EAPauthentication. </t> <t hangText="peer"> Theauthentication.</dd> <dt>peer</dt> <dd>The entity that responds to the authenticator. In <xreftarget="IEEE-802.1X"/>,target="IEEE-802.1X" format="default"/>, this entity is known as the supplicant. (We use the terms peer, device, and peer deviceinterchangeably.) </t> <t hangText="server"> Theinterchangeably.)</dd> <dt>server</dt> <dd>The entity that terminates the EAP authentication method with the peer. In the case where no backend authentication server is used, the EAP server is part of the authenticator. In the case where the authenticator operates in pass-through mode, the EAP server is located on the backend authenticationserver. </t> </list> </t>server.</dd> </dl> </section> <sectiontitle="EAP-NOOB protocol" anchor="eap-noob"> <t> Thisanchor="eap-noob" numbered="true" toc="default"> <name>EAP-NOOB Method</name> <t>This section defines the EAP-NOOBprotocol.method. The protocol is a generalized version of the original idea presented by <xreftarget="Sethi14">Sethitarget="Sethi14" format="default">Sethi etal.</xref>. </t>al.</xref>.</t> <sectiontitle="Protocol overview" anchor="overview"> <t> Oneanchor="overview" numbered="true" toc="default"> <name>Protocol Overview</name> <t>One EAP-NOOBprotocolmethod execution spans two or more EAP conversations, called Exchanges in this specification. Each Exchange consists of several EAP request-response pairs. At least two separate EAP conversations are needed to give the human user time to deliver the OOB message betweenthem. </t> <t> Thethem.</t> <t>The overall protocol starts with the Initial Exchange, which comprises four EAP request-response pairs. In the Initial Exchange, the server allocates an identifier to the peer, and the server and peer negotiate the protocol version and cryptosuite (i.e., cryptographic algorithm suite), exchangenoncesnonces, and perform an Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key exchange. The user-assisted OOB Step then takes place. This step requires only one out-of-bandmessagemessage, either from the peer to the server or from the server to the peer. While waiting for the OOB Step action, the peerMAY<bcp14>MAY</bcp14> probe the server by reconnecting to it with EAP-NOOB. If the OOB Step has already taken place, the probe leads to the Completion Exchange, which completes the mutual authentication and key confirmation. On the other hand, if the OOB Step has not yet taken place, the probe leads to the Waiting Exchange, and the peer will perform another probe after a server-defined minimum waiting time. The Initial Exchange and Waiting Exchange always end in EAP-Failure, while the Completion Exchange may result in EAP-Success. Once the peer and server have performed a successful Completion Exchange, both endpoints store the created association in persistent storage, and the OOB Step is not repeated. Thereafter, creation of new temporal keys, ECDHE rekeying, and updates of cryptographic algorithms can be achieved with the ReconnectExchange. </t> <t>Exchange.</t> <figureanchor="fig-statemachine" title="EAP-NOOB server-peer association state machine" align="center"> <artwork> <![CDATA[anchor="fig-statemachine"> <name>EAP-NOOB Server-Peer Association State Machine</name> <artwork name="" type="" align="left" alt=""><![CDATA[ OOB Output/Initial Exchange/ Waiting Exchange .-----. | v .------------------. Initial .------------------. | | Exchange | | .->| Unregistered (0) |---------------->|Waiting for OOB(1)| | | (ephemeral) | | (ephemeral) | | | | | | | '------------------' '------------------' | | | ^ User Reset Completion | | | | Exchange | OOB OOB |<-------. .-------------------------' Input Reject/ | | | | Initial | | | | Exchange | | v v | | .------------------. Completion .------------------. | | | Exchange | | | | Registered (4) |<----------------| OOB Received (2) | | | (persistent) | | (ephemeral) | | | | | | | '------------------' '------------------' | | ^ | Mobility/ | | Timeout/ Reconnect | Failure Exchange | | | | v | | .------------------. | | | '--| Reconnecting (3) | | (persistent) | | | '------------------']]> </artwork>]]></artwork> </figure></t> <t> <xref target="fig-statemachine"/><t><xref target="fig-statemachine" format="default"/> shows the association state machine, which is the same for the server and for the peer. (For readability, only the main state transitions are shown. The complete table of transitions can be found in <xreftarget="exchangeappendix"/>.)target="exchangeappendix" format="default"/>.) When the peer initiates the EAP-NOOB method, the server chooses the ensuing message exchange based on the combination of the server and peer states. The EAP server and peer are initially in the Unregistered (0) state, in which no state information needs to be stored. Before a successful Completion Exchange, the server-peer association state is ephemeral in both the server and peer (ephemeral states 0..2), and a timeout or error may cause one or both endpoints to go back to the Unregistered (0) state so that the Initial Exchange is repeated. After the Completion Exchange has resulted in EAP-Success, the association state becomes persistent (persistent states 3..4). Only user reset or memory failure can cause the return of the server or the peer from the persistent states to the ephemeral states and to the InitialExchange. </t> <t> TheExchange.</t> <t>The serverMUST NOT<bcp14>MUST NOT</bcp14> repeat a successful OOB Step with the same peer except if the association with the peer is explicitly reset by the user or lost due to failure of the persistent storage in the server. More specifically, once the association has entered the Registered (4) state, the serverMUST NOT<bcp14>MUST NOT</bcp14> delete the association or go back to the ephemeral states 0..2 without explicit user approval. Similarly, the peerMUST NOT<bcp14>MUST NOT</bcp14> repeat the OOB Step unless the user explicitly deletesfrom the peerthe association with the server from the peer or resets the peer to the Unregistered (0) state. The server and peerMAY<bcp14>MAY</bcp14> implement user reset of the association by deleting the state data from that endpoint. If an endpoint continues to store data about the association after the user reset, its behaviorMUST<bcp14>MUST</bcp14> be equivalent to having deleted the associationdata. </t> <t> Itdata.</t> <t>It can happen that the peer accidentallyor(or through userresetreset) loses its persistent state and reconnects to the server without a previously allocated peer identifier. In that case, the serverMUST<bcp14>MUST</bcp14> treat the peer as a new peer. The serverMAY<bcp14>MAY</bcp14> use auxiliary information, such as the PeerInfo field received in the Initial Exchange, to detect multiple associations with the same peer. However, itMUST NOT<bcp14>MUST NOT</bcp14> delete or merge redundant associations without user or application approval because EAP-NOOB internally has no secure way of verifying that the two peers are the same physical device. Similarly, the server might lose the association state because of a memory failure or user reset. In that case, the only way to recover is that the user also resets thepeer. </t> <t> Apeer.</t> <t>A special feature of the EAP-NOOB method is that the server is not assumed to have anya-prioria priori knowledge of the peer. Therefore, the peer initially uses the generic identity string "noob@eap-noob.arpa" as itsnetwork access identifierNetwork Access Identifier (NAI). The server then allocates a server-specific identifier to the peer. The generic NAI serves two purposes: firstly, it tells the server that the peer supports and expects the EAP-NOOBmethod and,method; secondly, it allows routing of the EAP-NOOB sessions to a specific authentication server in an Authentication,AuthorizationAuthorization, and Accounting (AAA)architecture. </t> <t> EAP-NOOBarchitecture.</t> <t>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-Success. The reason is that, while EAP allows delays between the request-response pairs, e.g., for repeated password entry, the user delays in OOB authentication can be much longer than in password trials. Moreover, EAP-NOOB supports peers with no input capability in the user interface (e.g., LED light bulbs). Since users cannot initiate the protocol in these devices, the devices have to perform the Initial Exchange opportunistically and hope for the OOB Step to take place within a timeout period (NoobTimeout), which is why the timeout needs to be several minutes rather than seconds. To support such high-latency OOB channels, the peer and server perform the Initial Exchange in one EAP conversation, then allow time for the OOB message to be delivered, and later perform the Waiting Exchange and CompletionExchangesExchange in different EAPconversations. </t>conversations.</t> </section> <sectiontitle="Protocol messagesanchor="protocol" numbered="true" toc="default"> <name>Protocol Messages andsequences" anchor="protocol"> <t> ThisSequences</name> <t>This section defines the EAP-NOOB exchanges, which correspond to EAP conversations. The exchanges start with a common handshake, which determines the type of the following exchange. The common handshake messages and the subsequent messages for each exchange type are listed in the diagrams below. The diagrams also specify the data fields present in each message. Each exchange comprises multiple EAP request-response pairs and ends in either EAP-Failure, indicating that authentication is not (yet) successful, or inEAP-Success. </t>EAP-Success.</t> <sectiontitle="Common handshakeanchor="commonhandshake" numbered="true" toc="default"> <name>Common Handshake inall EAP-NOOB exchanges" anchor="commonhandshake"> <t>All EAP-NOOB Exchanges</name> <t>All EAP-NOOB exchanges start with common handshake messages. The handshake begins with the identity request and response that are common to all EAP methods. Their purpose is to enable the AAA architecture to route the EAP conversation to the EAP server and to enable the EAP server to select the EAP method. The handshake then continues with one EAP-NOOB request-response pair in which the server discovers the peer identifier used in EAP-NOOB and the peerstate. </t> <t> Instate.</t> <t>In more detail, each EAP-NOOB exchange begins with the authenticator sending an EAP-Request/Identity packet to the peer. From this point on, the EAP conversation occurs between the server and the peer, and the authenticator acts as a pass-through device. The peer responds to the authenticator with an EAP-Response/Identity packet, which contains thenetwork access identifierNetwork Access Identifier (NAI). The authenticator, acting as a pass-through device, forwards this response and the following EAP conversation between the peer and the AAA architecture. The AAA architecture routes the conversation to a specific AAA server (called "EAP server" or simply "server" in this specification) based 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 <xreftarget="nai"/>. </t> <t> Aftertarget="nai" format="default"/>.</t> <t>After receiving the EAP-Response/Identity message, the server sends 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. However, the peerSHOULD<bcp14>SHOULD</bcp14> omit the PeerId from the response (Type=1) when PeerState=0. The server then chooses the EAP-NOOB exchange, i.e., the ensuing message sequence, as explained below. The peer recognizes the exchange based on the message type field (Type) of the next EAP-NOOB request received from theserver. </t> <t> Theserver.</t> <t>The serverMUST<bcp14>MUST</bcp14> determine the exchange type based on the combination of the peer and server states as follows (also summarized in <xreftarget="table-exchanges"/>).target="tab-exchanges" format="default"/>). 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 server chooses the Initial Exchange. Ifone ofeither the peer or server is 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 and the server chooses the Completion Exchange. If both the server and peer are in the Waiting for OOB (1) state, the server chooses the Waiting Exchange. If the peer is in the Reconnecting (3) state and the server is in the Registered (4) or Reconnecting (3) state, the server chooses the Reconnect Exchange. All other state combinations are error situations where user action is required, and the serverSHOULD<bcp14>SHOULD</bcp14> indicate such errors to the peer with the error code 2002 (see <xreftarget="statemismatch"/>).target="statemismatch" format="default"/>). Note also that the peerMUST NOT<bcp14>MUST NOT</bcp14> initiate EAP-NOOB when the peer is in the Registered (4)state. </t> <t>state.</t> <figureanchor="fig-commonhandshake" title="Common handshakeanchor="fig-commonhandshake"> <name>Common Handshake inallAll EAP-NOOBexchanges">Exchanges</name> <artworkalign="center"> <![CDATA[align="center" name="" type="" alt=""><![CDATA[ EAP Peer Authenticator EAP Server | | | |<----------- EAP-Request/Identity -| | | | | | |------------ EAP-Response/Identity -------------->| | (NAI=noob@eap-noob.arpa) | | | | | |<----------- EAP-Request/EAP-NOOB ----------------| | (Type=1) | | | | | |------------ EAP-Response/EAP-NOOB -------------->| | (Type=1,[PeerId],PeerState=1) | | | | continuing with exchange-specific messages... |]]> </artwork>]]></artwork> </figure></t></section> <sectiontitle="Initial Exchange" anchor="initialexchange"> <t> Theanchor="initialexchange" numbered="true" toc="default"> <name>Initial Exchange</name> <t>The Initial Exchange comprises the common handshake and two further EAP-NOOB request-responsepairs,pairs: one for version,cryptosuitecryptosuite, and parameter negotiation and the other for the ECDHE key exchange. The first EAP-NOOB request (Type=2) from the server contains a newly allocated PeerId for the peer and an optional NewNAI for assigning a new NAI to the peer. The server allocates a new PeerId in the Initial Exchange regardless of any old PeerId received in the previous response (Type=1). The server also sends in the request a list of the protocol versions (Vers) and cryptosuites (Cryptosuites) it supports, an indicator of the OOB channel directions it supports (Dirs), and a ServerInfo object. The peer chooses one of the versions and cryptosuites. The peer sends a response (Type=2) with the selected protocol version (Verp), the received PeerId, the selected cryptosuite (Cryptosuitep), an indicator of the OOB channel direction(s) selected by the peer (Dirp), and a PeerInfo object. In the second EAP-NOOB request and response (Type=3), the server and peer exchange the public components of their ECDHE keys and nonces(PKs,Ns,PKp,Np).(PKs, Ns, PKp, and Np). The ECDHE keysMUST<bcp14>MUST</bcp14> be based on the negotiated cryptosuite, i.e., Cryptosuitep. The Initial Exchange always ends with EAP-Failure from the server because the authentication cannot yet becompleted. </t> <t>completed.</t> <figureanchor="fig-initial" title="Initial Exchange">anchor="fig-initial"> <name>Initial Exchange</name> <artworkalign="center"> <![CDATA[align="center" name="" type="" alt=""><![CDATA[ EAP Peer EAP Server | ...continuing from common handshake | | | |<----------- EAP-Request/EAP-NOOB ----------------| | (Type=2,Vers,PeerId,[NewNAI], | | Cryptosuites,Dirs,ServerInfo) | | | | | |------------ EAP-Response/EAP-NOOB -------------->| | (Type=2,Verp,PeerId,Cryptosuitep, | | Dirp,PeerInfo) | | | | | |<----------- EAP-Request/EAP-NOOB ----------------| | (Type=3,PeerId,PKs,Ns,[SleepTime]) | | | | | |------------ EAP-Response/EAP-NOOB -------------->| | (Type=3,PeerId,PKp,Np) | | | | | |<----------- EAP-Failure -------------------------| | |]]> </artwork>]]></artwork> </figure></t> <t> At<t>At the conclusion of the Initial Exchange, both the server and the peer move to the Waiting for OOB (1)state. </t>state.</t> </section> <sectiontitle="OOB Step" anchor="oobstep"> <t> Theanchor="oobstep" numbered="true" toc="default"> <name>OOB Step</name> <t>The OOB Step, labeled as OOB Output and OOB Input in <xreftarget="fig-statemachine"/>,target="fig-statemachine" format="default"/>, takes place after the Initial Exchange. Depending on the negotiated OOB channel direction, the peer or the server outputs the OOB message as shown in Figures <xreftarget="fig-oob1"/>target="fig-oob1" format="counter"/> or <xreftarget="fig-oob2"/>,target="fig-oob2" format="counter"/>, respectively. The data fields are the PeerId, the secret nonce Noob, and the cryptographic fingerprint Hoob. The contents of the data fields are defined in <xreftarget="messagedatafields"/>.target="messagedatafields" format="default"/>. The OOB message is delivered to the other endpoint via a user-assisted OOBchannel. </t> <t> Forchannel.</t> <t>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 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 OOB message is sent in the peer-to-server direction, the OOB sender is the peer and the OOB receiver is theserver. </t> <t>server.</t> <figureanchor="fig-oob1" title="OOBanchor="fig-oob1"> <name>OOB Step, frompeerPeer to EAPserver">Server</name> <artworkalign="center"> <![CDATA[align="center" name="" type="" alt=""><![CDATA[ EAP Peer EAP Server | | |=================OOB=============================>| | (PeerId,Noob,Hoob) | | |]]> </artwork>]]></artwork> </figure> <figureanchor="fig-oob2" title="OOBanchor="fig-oob2"> <name>OOB Step, from EAPserverServer topeer">Peer</name> <artworkalign="center"> <![CDATA[align="center" name="" type="" alt=""><![CDATA[ EAP Peer EAP Server | | |<================OOB==============================| | (PeerId,Noob,Hoob) | | |]]> </artwork>]]></artwork> </figure></t> <t> The<t>The OOB receiverMUST<bcp14>MUST</bcp14> compare the received value of the fingerprint Hoob (see <xreftarget="messagedatafields"/>)target="messagedatafields" format="default"/>) with a value that it computed locally for the PeerID received. This integrity check ensures that the endpoints agree on contents of the Initial Exchange. If the values are equal, the receiver moves to the OOB Received (2) state. Otherwise, the receiverMUST<bcp14>MUST</bcp14> reject the OOB message. For usability reasons, the OOB receiverSHOULD<bcp14>SHOULD</bcp14> indicate the acceptance or rejection of the OOB message to the user. The receiverSHOULD<bcp14>SHOULD</bcp14> reject invalid OOB messages without changing its state in the association statemachine,machine until an application-specific number of invalid messages (OobRetries) has beenreached,reached; afterwhichwhich, the receiverSHOULD<bcp14>SHOULD</bcp14> consider it an error and go back to the Unregistered (0)state. </t> <t> Thestate.</t> <t>The server or peerMAY<bcp14>MAY</bcp14> send multiple OOB messages with different Noob values while in the Waiting for OOB (1) state. The OOB senderSHOULD<bcp14>SHOULD</bcp14> remember the Noob values until they expire and accept any one of them in the following Completion Exchange. The Noob values sent by the server expire after an application-dependent timeout (NoobTimeout), and the serverMUST NOT<bcp14>MUST NOT</bcp14> accept Noob values older than that in the Completion Exchange. TheRECOMMENDED<bcp14>RECOMMENDED</bcp14> value for NoobTimeout is 3600 seconds if there are no application-specific reasons for making it shorter or longer. The Noob values sent by the peerexpireexpire, as defined in <xreftarget="waitingexchange"/>. </t> <t> Thetarget="waitingexchange" format="default"/>.</t> <t>The OOB receiver does not accept further OOB messages after it has accepted one and moved to the OOB Received (2) state. However, the receiverMAY<bcp14>MAY</bcp14> buffer redundant OOB messages in case an OOB message expiry or similar error detected in the Completion Exchange causes it to return to the Waiting for OOB (1) state. It isRECOMMENDED<bcp14>RECOMMENDED</bcp14> that the OOB receiver notifies the user about redundant OOB messages, but itMAY<bcp14>MAY</bcp14> instead discard themsilently. </t> <t> Thesilently.</t> <t>The sender will typically generate a new Noob, and therefore a new OOB message, at constant time intervals (NoobInterval). TheRECOMMENDED<bcp14>RECOMMENDED</bcp14> intervalis NoobIntervalis</t> <t indent="3">NoobInterval = NoobTimeout /2, in2</t> <t>in whichcasecase, the receiver of the OOB will at any given time accept either of the two latest Noob values. However, the timing of the Noob generation may also be based on user interaction or on implementationconsiderations. </t> <t> Evenconsiderations.</t> <t>Even though not recommended (see <xreftarget="datafields"/>),target="datafields" format="default"/>), this specification allows both directions to be negotiated (Dirp=3) for the OOB channel. In that case, both sidesSHOULD<bcp14>SHOULD</bcp14> output the OOB message, and it is up to the user to deliver at least one ofthem. </t> <t> Thethem.</t> <t>The details of the OOB channel implementation including the message encoding are defined by the application. <xreftarget="urloob"/>target="urloob" format="default"/> gives an example of how the OOB message can be encoded as a URL that may be embedded in a dynamic QR code or NFCtag. </t>(Near Field Communication) tag.</t> </section> <sectiontitle="Completion Exchange" anchor="completionexchange"> <t> Afteranchor="completionexchange" numbered="true" toc="default"> <name>Completion Exchange</name> <t>After the Initial Exchange, if the OOB channel directions selected by the peer include the peer-to-server direction, the peerSHOULD<bcp14>SHOULD</bcp14> initiate the EAP-NOOB method again after an applications-specific waiting time in order to probe for completion of the OOB Step. If the OOB channel directions selected by the peer include the server-to-peer direction and the peer receives the OOB message, itSHOULD<bcp14>SHOULD</bcp14> initiate the EAP-NOOB method immediately. Depending on the combination of the peer and server states, the server continues with the Completion Exchange or Waiting Exchange (see <xreftarget="commonhandshake"/>target="commonhandshake" format="default"/> on how the server makes thisdecision). </t> <t> Thedecision).</t> <t>The Completion Exchange comprises the common handshake and one or two further EAP-NOOB request-response pairs. If the peer is in the Waiting for OOB (1) state, the OOB message has been sent in the peer-to-server direction. In that case, only one request-response pair (Type=6) takes place. In the request, the server sends the NoobId value (see <xreftarget="messagedatafields"/>),target="messagedatafields" format="default"/>), which the peer uses to identify the exact OOB message received by the server. On the other hand, if the peer is in the OOB Received (2) state, the direction of the OOB message is from server to peer. In this case, two request-response pairs (Type=5 and Type=6) are needed. The purpose of the first request-response pair (Type=5) is that it enables the server to discover NoobId, which identifies the exact OOB message received by the peer. The server returns the same NoobId to the peer in the latterrequest. </t> <t> Inrequest.</t> <t>In the last request-response pair (Type=6) of the Completion Exchange, the server and peer exchange message authentication codes. Both sidesMUST<bcp14>MUST</bcp14> compute the keys Kms andKmpKmp, as defined in <xreftarget="keyderivation"/>target="keyderivation" format="default"/>, and the message authentication codes MACs andMACpMACp, as defined in <xreftarget="messagedatafields"/>.target="messagedatafields" format="default"/>. Both sidesMUST<bcp14>MUST</bcp14> compare the received message authentication code with a locally computed value. If the peer finds that it has received the correct value of MACs and the server finds that it has received the correct value of MACp, the Completion Exchange ends in EAP-Success. Otherwise, the endpoint where the comparison fails indicates this with an error message (error code 4001, see <xreftarget="invalidmessages"/>)target="cryptofailure" format="default"/>), and the Completion Exchange ends inEAP-Failure. </t> <t> AfterEAP-Failure.</t> <t>After the successful Completion Exchange, both the server and the peer move to the Registered (4) state. They also derive the output keying material and store the persistent EAP-NOOB associationstatestate, as defined in Sections <xreftarget="fastreconnect"/>target="fastreconnect" format="counter"/> and <xreftarget="keyderivation"/>. </t> <t> Ittarget="keyderivation" format="counter"/>.</t> <t>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 NoobId that it receives in the Completion Exchange. Another reason why the OOB sender might not recognize the NoobId is if the received OOB message was spoofed and contained an attacker-generated Noob value. The recipient of an unrecognized NoobId indicates this with an error message (error code 2003, see <xreftarget="invalidmessages"/>),target="invalidmessages" format="default"/>), and the Completion Exchange ends in EAP-Failure. The recipient of the error message 2003 moves back to the Waiting for OOB (1) state. This state transition is called OOB Reject in <xreftarget="fig-statemachine"/>target="fig-statemachine" format="default"/> (even though it really is a specific type of failed Completion Exchange).TheOn the other hand, the sender of the errormessage, on the other hand,message stays in its previousstate. </t> <t> Althoughstate.</t> <t>Although it is not expected to occur in practice, poor user interface design could lead to two OOB messages delivered simultaneously, one 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 Completion Exchange by observing that both the server and peer are in the OOB Receivedstate (2).(2) state. In that case, as a tiebreaker, the serverMUST<bcp14>MUST</bcp14> behave as if only the server-to-peer message had beendelivered. </t> <t>delivered.</t> <figureanchor="fig-completion" title="Completion Exchange">anchor="fig-completion"> <name>Completion Exchange</name> <artworkalign="center"> <![CDATA[align="center" name="" type="" alt=""><![CDATA[ EAP Peer EAP Server | ...continuing from common handshake | | | |<----------- [ EAP-Request/EAP-NOOB ] ------------| | (Type=5,PeerId) | | | | | |------------ [ EAP-Response/EAP-NOOB ] ---------->| | (Type=5,PeerId,NoobId) | | | | | |<----------- EAP-Request/EAP-NOOB ----------------| | (Type=6,PeerId,NoobId,MACs) | | | | | |------------ EAP-Response/EAP-NOOB -------------->| | (Type=6,PeerId,MACp) | | | | | |<----------- EAP-Success -------------------------| | |]]> </artwork>]]></artwork> </figure></t></section> <sectiontitle="Waiting Exchange" anchor="waitingexchange"> <t> Asanchor="waitingexchange" numbered="true" toc="default"> <name>Waiting Exchange</name> <t>As explained in <xreftarget="completionexchange"/>,target="completionexchange" format="default"/>, the peerSHOULD<bcp14>SHOULD</bcp14> probe the server for completion of the OOB Step. When the combination of the peer and server states indicates that the OOB message has not yet been delivered, the server chooses the Waiting Exchange (see <xreftarget="commonhandshake"/>target="commonhandshake" format="default"/> on how the server makes this decision). The Waiting Exchange comprises the common handshake and one further request-response pair, and it always ends inEAP-Failure. </t> <t> InEAP-Failure.</t> <t>In order to limit the rate at which peers probe the server, the serverMAY<bcp14>MAY</bcp14> send to the peer either in the Initial Exchange or in the Waiting Exchange a minimum time to wait before probing the server again. A peer that has not received an OOB messageSHOULD<bcp14>SHOULD</bcp14> wait at least the server-specified minimum waiting time in seconds (SleepTime) before initiating EAP again with the same server. The peer uses the latest SleepTime value that it has received in or after the Initial Exchange. If the server has not sent any SleepTime value, the peerMUST<bcp14>MUST</bcp14> wait for an application-specified minimum time(SleepTimeDefault). </t> <t> After(SleepTimeDefault).</t> <t>After the Waiting Exchange, the peerMUST<bcp14>MUST</bcp14> discard (from its local ephemeral storage) Noob values that it has sent to the server in OOB messages that are older than the application-defined timeout NoobTimeout (see <xreftarget="oobstep"/>).target="oobstep" format="default"/>). The peerSHOULD<bcp14>SHOULD</bcp14> discard such expired Noob values even if the probingfailed, e.g.,failed becauseofof, e.g., failure to connect to the EAP server or an incorrect message authentication code. The timeout of peer-generated Noob values is defined like this in order to allow the peer to probe the server once after it has waited for the server-specifiedSleepTime. </t> <t> IfSleepTime.</t> <t>If the server and peer have negotiated to use only the server-to-peer direction for the OOB channel (Dirp=2), the peerSHOULD<bcp14>SHOULD</bcp14> nevertheless probe the server. The purpose of this is to keep the server informed about the peers that are still waiting for OOB messages. The serverMAY<bcp14>MAY</bcp14> set SleepTime to a high number(3600)(e.g., 3600) to prevent the peer from probing the serverfrequently. </t> <t>frequently.</t> <figureanchor="fig-waiting" title="Waiting Exchange">anchor="fig-waiting"> <name>Waiting Exchange</name> <artworkalign="center"> <![CDATA[align="center" name="" type="" alt=""><![CDATA[ EAP Peer EAP Server | ...continuing from common handshake | | | |<----------- EAP-Request/EAP-NOOB ----------------| | (Type=4,PeerId,[SleepTime]) | | | | | |------------ EAP-Response/EAP-NOOB -------------->| | (Type=4,PeerId) | | | | | |<----------- EAP-Failure -------------------------| | |]]> </artwork>]]></artwork> </figure></t></section> </section> <sectiontitle="Protocol data fields" anchor="datafields"> <t> Thisanchor="datafields" numbered="true" toc="default"> <name>Protocol Data Fields</name> <t>This section defines the various identifiers and data fields used in the EAP-NOOBprotocol. </t>method.</t> <sectiontitle="Peer identifieranchor="nai" numbered="true" toc="default"> <name>Peer Identifier andNAI" anchor="nai"> <t> TheNAI</name> <t>The server allocates a new peer identifier (PeerId) for the peer in the Initial Exchange. The peer identifierMUST<bcp14>MUST</bcp14> follow the syntax of the utf8-username specified in <xreftarget="RFC7542"/>.target="RFC7542" format="default"/>. The serverMUST<bcp14>MUST</bcp14> generate 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 the peer in the Initial Exchange. One way to generate the identifiers is to choose a random 16-byte identifier and to base64url encode it without padding <xreftarget="RFC4648"/>target="RFC4648" format="default"/> into a 22-character ASCII string. Another way to generate the identifiers is to choose a random 22-character alphanumeric ASCII string. It isRECOMMENDED<bcp14>RECOMMENDED</bcp14> to not use identifiers longer than this because they result in longer OOBmessages. </t> <t> Themessages.</t> <t>The peer uses the allocated PeerId to identify itself to the server in the subsequent exchanges. The peerMUST<bcp14>MUST</bcp14> copy the PeerIdbyte-by-bytebyte by byte from the message where it was allocated, and the serverMUST<bcp14>MUST</bcp14> perform a byte-by-byte comparison between the received and the previously allocated PeerID. The peer sets the PeerId value in response type 1 as follows. As stated in <xreftarget="commonhandshake"/>,target="commonhandshake" format="default"/>, when the peer is in the Unregistered (0) state, itSHOULD<bcp14>SHOULD</bcp14> omit the PeerId from response type 1. When the peer is in one of the states 1..2, itMUST<bcp14>MUST</bcp14> use the PeerId that the server assigned to it in the latest Initial Exchange. When the peer is in one of the persistent states 3..4, itMUST<bcp14>MUST</bcp14> use the PeerId from its persistent EAP-NOOB association. (The PeerId is written to the association when the peer moves to the Registered (4) state after a CompletionExchange.) </t> <t> TheExchange.)</t> <t>The default NAI for the peer is "noob@eap-noob.arpa". The peer implementationMAY<bcp14>MAY</bcp14> allow the user or application to configure a different NAI, which overrides the default NAI. Furthermore, the serverMAY<bcp14>MAY</bcp14> assign a new NAI to the peer in the Initial Exchange or ReconnectExchange,Exchange in the NewNAI field of request types 2 and7,7 to 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 and the server did not send a NewNAI in the latest Initial Exchange, the peerMUST<bcp14>MUST</bcp14> use the configuredNAI, orNAI or, if it does not exist, the default NAI. When the peer is in one of the states 1..2 and the server sent a NewNAI in the latest Initial Exchange, the peerMUST<bcp14>MUST</bcp14> use this server-assigned NAI. When the peer moves to the Registered (4) state after the Completion Exchange, it writes to the persistent EAP-NOOB association the same NAI value that it used in the Completion Exchange. When the peer is in the Reconnecting (3) or Registered (4) state, itMUST<bcp14>MUST</bcp14> use the NAI from its persistent EAP-NOOB association. When the server sends NewNAI in the Reconnect Exchange, the peer writes its value to the persistent EAP-NOOB association when it moves from the Reconnecting (3) state to the Registered (4) state. All the NAI valuesMUST<bcp14>MUST</bcp14> follow the syntax specified in <xreftarget="RFC7542"/>.target="RFC7542" format="default"/>. </t><t> The<t>The purpose of the server-assigned NAI is to enable more flexible routing of the EAP sessions over the AAA infrastructure, including roaming scenarios (see <xreftarget="roaming"/>).target="roaming" format="default"/>). Moreover, someAuthenticatorsauthenticators or AAA servers use the realm part of the assigned NAI to determine peer-specific connection parameters, such as isolating the peer to a specific VLAN.The user or application configured NAI, onOn the other hand, the user- or application-configured NAI enables registration of new devices while roaming. It also enables manufacturers to set up their own AAA servers for bootstrapping of new peerdevices. </t> <t> Thedevices.</t> <t>The peer's PeerId and server-assigned NAI are ephemeral until a successful Completion Exchange takes place. Thereafter, the values become parts of the persistent EAP-NOOBassociation,association until the user resets the peer andtheserver or until a new NAI is assigned in the ReconnectExchange. </t>Exchange.</t> </section> <sectiontitle="Message data fields" anchor="messagedatafields"> <t> <xref target="table-datafields"/>anchor="messagedatafields" numbered="true" toc="default"> <name>Message Data Fields</name> <t><xref target="tab-datafields" format="default"/> defines the data fields in the protocol messages. The in-band messages are formatted as JSON objects <xreftarget="RFC8259"/>target="RFC8259" format="default"/> in UTF-8 encoding. The JSON member names are in the left-hand column of thetable. </t> <texttable title="Message data fields" anchor="table-datafields"> <ttcol align="left" width="25%">Data field</ttcol> <ttcol align="left">Description</ttcol> <c>Vers, Verp</c> <c>EAP-NOOBtable.</t> <table anchor="tab-datafields" align="center"> <name>Message Data Fields</name> <thead> <tr> <th align="left">Data Field</th> <th align="left">Description</th> </tr> </thead> <tbody> <tr> <td align="left">Vers, Verp</td> <td align="left">EAP-NOOB protocol versions supported by the EAPserver,server and the protocol version chosen by the peer. Vers is a JSON array of unsigned integers, and Verp is an unsigned integer. Example values are "[1]" and "1",respectively.</c> <c></c><c></c> <c>PeerId</c> <c>Peer identifierrespectively.</td> </tr> <tr> <td align="left">PeerId</td> <td align="left">Peer identifier, as defined in <xreftarget="nai"/>.</c> <c></c><c></c> <c>NAI, NewNAI</c> <c>Peertarget="nai" format="default"/>.</td> </tr> <tr> <td align="left">NAI, NewNAI</td> <td align="left">Peer NAI and server-assigned new peerNAINAI, as defined in <xreftarget="nai"/>.</c> <c></c><c></c> <c>Type</c> <c>EAP-NOOBtarget="nai" format="default"/>.</td> </tr> <tr> <td align="left">Type</td> <td align="left">EAP-NOOB message type. The type is an integer in the range 0..9. EAP-NOOB requests and the corresponding responses share the same typevalue.</c> <c></c><c></c> <c>PeerState</c> <c>Peervalue.</td> </tr> <tr> <td align="left">PeerState</td> <td align="left">Peer state is an integer in the range 0..4 (see <xreftarget="fig-statemachine"/>).target="fig-statemachine" format="default"/>). However, only values 0..3 are ever sent in the protocolmessages.</c> <c></c><c></c> <c>PKs, PKp</c> <c>Themessages.</td> </tr> <tr> <td align="left">PKs, PKp</td> <td align="left">The public components of the ECDHE keys of the server and peer. PKs and PKp are sent in the JSON Web Key (JWK) format <xreftarget="RFC7517"/>.target="RFC7517" format="default"/>. The detailed format of the JWK object is defined by thecryptosuite.</c> <c></c><c></c> <c>Cryptosuites, Cryptosuitep</c> <c>Thecryptosuite.</td> </tr> <tr> <td align="left">Cryptosuites, Cryptosuitep</td> <td align="left">The identifiers of cryptosuites supported by the server and of the cryptosuite selected by the peer. The server-supported cryptosuites in Cryptosuites are formatted as a JSON array of the identifier integers. The serverMUST<bcp14>MUST</bcp14> send a nonempty array with no repeating elements, ordered by decreasing priority. The peerMUST<bcp14>MUST</bcp14> respond with exactly one suite in the Cryptosuitep value, formatted as an identifier integer.Mandatory to implementMandatory-to-implement cryptosuites and the registration procedure for new cryptosuitesisare specified in <xreftarget="cryptosuites"/>.target="cryptosuites" format="default"/>. Example values are "[1]" and "1",respectively.</c> <c></c><c></c> <c>Dirs, Dirp</c> <c>Anrespectively.</td> </tr> <tr> <td align="left">Dirs, Dirp</td> <td align="left">An integer indicating the OOB channel directions supported by the server and the directions selected by the peer. The possible values are 1=peer-to-server, 2=server-to-peer, and 3=bothdirections.</c> <c></c><c></c> <c>Dir</c> <c>Thedirections.</td> </tr> <tr> <td align="left">Dir</td> <td align="left">The actual direction of the OOB message (1=peer-to-server, 2=server-to-peer). This value is not sent over any communication channel, but it is included in the computation of the cryptographic fingerprintHoob.</c> <c></c><c></c> <c>Ns, Np</c> <c>32-byteHoob.</td> </tr> <tr> <td align="left">Ns, Np</td> <td align="left">32-byte nonces for the InitialExchange.</c> <c></c><c></c> <c>ServerInfo</c> <c>ThisExchange.</td> </tr> <tr> <td align="left">ServerInfo</td> <td align="left">This field contains information about the server to be passed from the EAP method to the application layer in the peer. The information is specific to the application or to the OOB channel, and it is encoded as a JSON object of at most 500 bytes. It could include, for example, the access-network name and servername orname, a Uniform Resource Locator (URL) <xreftarget="RFC3986"/>target="RFC3986" format="default"/>, or some other information that helps the usertodeliver the OOB message to the server through the out-of-bandchannel.</c> <c></c><c></c> <c>PeerInfo</c> <c>Thischannel.</td> </tr> <tr> <td align="left">PeerInfo</td> <td align="left">This field contains information about the peer to be passed from the EAP method to the application layer in the server. The information is specific to the application or to the OOB channel, and it is encoded as a JSON object of at most 500 bytes. It could include, for example, the peer brand, model, and serial number, which help the usertodistinguish between devices andtodeliver the OOB message to the correct peer through the out-of-bandchannel.</c> <c></c><c></c> <c>SleepTime</c> <c>Thechannel.</td> </tr> <tr> <td align="left">SleepTime</td> <td align="left">The number of seconds for which the peerMUST NOT<bcp14>MUST NOT</bcp14> start a new execution of the EAP-NOOB method with the authenticator, unless the peer receives the OOB message or the sending is triggered by an application-specific user action. The server can use this field to limit the rate at which peers probe it. SleepTime is an unsigned integer in the range0..3600.</c> <c></c><c></c> <c>Noob</c> <c>16-byte0..3600.</td> </tr> <tr> <td align="left">Noob</td> <td align="left">16-byte secret nonce sent through the OOB channel and used for the session key derivation. The endpoint that received the OOB message uses this secret in the Completion Exchange to authenticate the exchanged key to the endpoint that sent the OOBmessage.</c> <c></c><c></c> <c>Hoob</c> <c>16-bytemessage.</td> </tr> <tr> <td align="left">Hoob</td> <td align="left">16-byte cryptographic fingerprint (i.e., hash value) computed from all the parameters exchanged in the Initial Exchange and in the OOB message. Receiving this fingerprint over the OOB channel guarantees the integrity of the key exchange and parameter negotiation. Hence, it authenticates the exchanged key to the endpoint that receives the OOBmessage.</c> <c></c><c></c> <c>NoobId</c> <c>16-bytemessage.</td> </tr> <tr> <td align="left">NoobId</td> <td align="left">16-byte identifier for the OOB message, computed with a one-way function from the nonce Noob in themessage.</c> <c></c><c></c> <c>MACs, MACp</c> <c>Messagemessage.</td> </tr> <tr> <td align="left">MACs, MACp</td> <td align="left">Message authentication codes (HMAC) for mutual authentication, key confirmation, and integrity check on the exchanged information. The input to the HMAC is defined below, and the key for the HMAC is defined in <xreftarget="keyderivation"/>.</c> <c></c><c></c> <c>Ns2, Np2</c> <c>32-bytetarget="keyderivation" format="default"/>.</td> </tr> <tr> <td align="left">Ns2, Np2</td> <td align="left">32-byte nonces for the ReconnectExchange.</c> <c></c><c></c> <c>KeyingMode</c> <c>IntegerExchange.</td> </tr> <tr> <td align="left">KeyingMode</td> <td align="left">Integer indicating the key derivation method. 0 in the Completion Exchange, and 1..3 in the ReconnectExchange.</c> <c></c><c></c> <c>PKs2, PKp2</c> <c>TheExchange.</td> </tr> <tr> <td align="left">PKs2, PKp2</td> <td align="left">The public components of the ECDHE keys of the server and peer for the Reconnect Exchange. PKp2 and PKs2 are sent in the JSON Web Key (JWK) format <xreftarget="RFC7517"/>.target="RFC7517" format="default"/>. The detailed format of the JWK object is defined by thecryptosuite.</c> <c></c><c></c> <c>MACs2, MACp2</c> <c>Messagecryptosuite.</td> </tr> <tr> <td align="left">MACs2, MACp2</td> <td align="left">Message authentication codes (HMAC) for mutual authentication, key confirmation, and integrity check on the Reconnect Exchange. The input to the HMAC is defined below, and the key for the HMAC is defined in <xreftarget="keyderivation"/>.</c> <c></c><c></c> <c>ErrorCode</c> <c>Integertarget="keyderivation" format="default"/>.</td> </tr> <tr> <td align="left">ErrorCode</td> <td align="left">Integer indicating an error condition. Defined in <xreftarget="errorcodes"/>.</c> <c></c><c></c> <c>ErrorInfo</c> <c>Textualtarget="errorcodes" format="default"/>.</td> </tr> <tr> <td align="left">ErrorInfo</td> <td align="left">Textual error message for logging and debugging purposes. A UTF-8 string of at most 500bytes.</c> <c></c><c></c> </texttable> <t> Itbytes.</td> </tr> </tbody> </table> <t>It isRECOMMENDED<bcp14>RECOMMENDED</bcp14> for servers to support both OOB channel directions (Dirs=3) unless the type of the OOB channel limits them to one direction (Dirs=1 or Dirs=2). On the other hand, it isRECOMMENDED<bcp14>RECOMMENDED</bcp14> that the peer selects only one direction (Dirp=1 or Dirp=2) even when both directions (Dirp=3) would be technically possible. The reason 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 needs to be delivered. This can be confusing to the user. Nevertheless, the EAP-NOOB protocol is designed tocopealso cope with the value3,3; in whichcasecase, it uses the first delivered OOB message. In the unlikely case of simultaneously delivered OOB messages, the protocol prioritizes the server-to-peerdirection. </t> <t> Thedirection.</t> <t>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 string. All the nonces are generated by the endpoint that sends themessage. </t> <t> Themessage.</t> <t>The fingerprint Hoob and the identifier NoobId are computed with the cryptographic hash function H, which is specified in the negotiated cryptosuite and truncated to the 16 leftmost bytes of the output. The message authentication codes (MACs, MACp, MACs2, MACp2) are computed with the function HMAC, which is theHMAChashed message authentication code <xreftarget="RFC2104"/>target="RFC2104" format="default"/> based on the cryptographic hash function H and truncated to the 32 leftmost bytes of theoutput. </t> <t> Theoutput.</t> <t>The inputs to the hash function for computing the fingerprint Hoob and to the HMAC for computing MACs, MACp,MACs2MACs2, and MACp2 are JSON arrays containing a fixed number (17) of elements. The array elementsMUST<bcp14>MUST</bcp14> be copied to the array verbatim from the sent and received in-band messages. When the element is a JSON object, its membersMUST NOT<bcp14>MUST NOT</bcp14> be reordered orre-encoded. Whitespace MUST NOTreencoded. White space <bcp14>MUST NOT</bcp14> be added anywhere in the JSON structure. Implementers should check that their JSON library copies the elements as UTF-8strings andstrings, does not modify them in any way, andthat itdoes not addwhitespacewhite space to the HMACinput. </t> <t> Theinput.</t> <t>The inputs for computing the fingerprint and message authentication codes are thefollowing: <list style="empty"> <t>Hoobfollowing:</t> <sourcecode type="pseudocode"> Hoob =H(Dir,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,Cryptosuitep,Dirp,NAI,PeerInfo,0,PKs,Ns,PKp,Np,Noob). </t> <t>NoobIdH(Dir,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo, Cryptosuitep,Dirp,NAI,PeerInfo,0,PKs,Ns,PKp,Np,Noob). NoobId = H("NoobId",Noob).</t> <t>MACsMACs = HMAC(Kms;2,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,Cryptosuitep,Dirp,NAI,PeerInfo,0,PKs,Ns,PKp,Np,Noob). </t> <t>MACp2,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo, Cryptosuitep,Dirp,NAI,PeerInfo,0,PKs,Ns,PKp,Np,Noob). MACp = HMAC(Kmp;1,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,Cryptosuitep,Dirp,NAI,PeerInfo,0,PKs,Ns,PKp,Np,Noob). </t> <t>MACs21,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo, Cryptosuitep,Dirp,NAI,PeerInfo,0,PKs,Ns,PKp,Np,Noob). MACs2 = HMAC(Kms2;2,Vers,Verp,PeerId,Cryptosuites,"",[ServerInfo],Cryptosuitep,"",NAI,[PeerInfo],KeyingMode,[PKs2],Ns2,[PKp2],Np2,"") </t> <t>MACp22,Vers,Verp,PeerId,Cryptosuites,"",[ServerInfo], Cryptosuitep,"",NAI,[PeerInfo],KeyingMode,[PKs2],Ns2,[PKp2],Np2,"") MACp2 = HMAC(Kmp2;1,Vers,Verp,PeerId,Cryptosuites,"",[ServerInfo],Cryptosuitep,"",NAI,[PeerInfo],KeyingMode,[PKs2],Ns2,[PKp2],Np2,"") </t> </list> </t> <t> The1,Vers,Verp,PeerId,Cryptosuites,"",[ServerInfo], Cryptosuitep,"",NAI,[PeerInfo],KeyingMode,[PKs2],Ns2,[PKp2],Np2,"") </sourcecode> <t>The inputs denoted with "" above are not present, and the values in brackets [] are optional. Both kinds of missing input values are represented by empty strings "" in the HMAC input (JSON array). The NAI included in the inputs is the NAI value that will be in the persistent EAP-NOOB association if the Completion Exchange or Reconnect Exchange succeeds. In the Completion Exchange, the NAI is the NewNAI value assigned by the server in the preceding InitialExchange, orExchange or, if no NewNAI was sent, the NAI used by the client in the Initial Exchange. In the Reconnect Exchange, the NAI is the NewNAI value assigned by the server in the same ReconnectExchange, orExchange or, if no NewNAI was sent, the unchanged NAI from the persistent EAP-NOOB association. Each of the values in brackets for the computation of Macs2 and Macp2MUST<bcp14>MUST</bcp14> be included if it was sent or received in the same Reconnect Exchange; otherwise, the value is replaced by an empty string"". </t> <t> The"".</t> <t>The parameter Dir indicates the direction in which the OOB message 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 user from accidentally delivering the OOB message back to its originator in the rare cases where both OOB directions have been negotiated. The keys (Kms, Kmp, Kms2, and Kmp2) for the HMACs are defined in <xreftarget="keyderivation"/>. </t> <t> Thetarget="keyderivation" format="default"/>.</t> <t>The nonces (Ns, Np, Ns2, Np2, and Noob) and the hash value (NoobId)MUST<bcp14>MUST</bcp14> be base64url encoded <xreftarget="RFC4648"/>target="RFC4648" format="default"/> when they are used as input to the cryptographic functions H or HMAC. These values and the message authentication codes (MACs, MACp, MACs2, and MACp2)MUST<bcp14>MUST</bcp14> also be base64url encoded when they are sent as JSON strings in the in-band messages. The values Noob and Hoob in the OOB channelMAY<bcp14>MAY</bcp14> be base64url encoded if that is appropriate for the application and the OOB channel. All base64url encoding is done without padding. Thebase64url encodedbase64url-encoded values will naturally consume more space than the number of bytes specified above(22-character(e.g., a 22-character string for a 16-byte nonce and a 43-character string for a 32-byte nonce or message authentication code). In the key derivation in <xreftarget="keyderivation"/>,target="keyderivation" format="default"/>, on the other hand, the unencoded nonces (raw bytes) are used as input to the key derivationfunction. </t> <t> Thefunction.</t> <t>The ServerInfo and PeerInfo are JSON objects with UTF-8 encoding. The length of either encoded object as a byte arrayMUST NOT<bcp14>MUST NOT</bcp14> exceed 500 bytes. The format and semantics of these objectsMUST<bcp14>MUST</bcp14> be defined by the application that uses the EAP-NOOBmethod. </t>method.</t> </section> </section> <sectiontitle="Fast reconnectanchor="fastreconnect" numbered="true" toc="default"> <name>Fast Reconnect andrekeying" anchor="fastreconnect"> <t> EAP-NOOBRekeying</name> <t>EAP-NOOB implementsFast Reconnectfast reconnect (<xreftarget="RFC3748"/>, section 7.2.1) thattarget="RFC3748" sectionFormat="comma" section="7.2.1"/>), which avoids repeated use of the user-assisted OOBchannel. </t> <t> Thechannel.</t> <t>The rekeying and the Reconnect Exchange may be needed for several reasons. New EAP output values Main Session Key (MSK) and Extended Main Session Key (EMSK) may be needed because of mobility or timeout of session keys. Software or hardware failure or user action may also cause the authenticator, EAPserverserver, or peer to lose itsnon-persistentnonpersistent state data. The failure would typically be detected by the peer or authenticator when session keys are no longer accepted by the other endpoint. Changes in the supported 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 these events, itMUST<bcp14>MUST</bcp14> change from the Registered (4) state to the Reconnecting (3) state. These state transitions are labeled Mobility/Timeout/Failure in <xreftarget="fig-statemachine"/>.target="fig-statemachine" format="default"/>. The EAP-NOOB method will then perform the Reconnect Exchange the next time when EAP istriggered. </t>triggered.</t> <sectiontitle="Persistentanchor="persistentassociation" numbered="true" toc="default"> <name>Persistent EAP-NOOBassociation" anchor="persistentassociation"> <t> ToAssociation</name> <t>To enable rekeying, the EAP server and peer store the session state in persistent memory after a successful Completion Exchange. This state data, called "persistent EAP-NOOB association",MUST<bcp14>MUST</bcp14> include at least the data fields shown in <xreftarget="table-persistent"/>.target="tab-persistent" format="default"/>. They are used for identifying and authenticating the peer in the Reconnect Exchange. When a persistent EAP-NOOB association exists, the EAP server and peer are in the Registeredstate(4) state or Reconnectingstate (3),(3) state, as shown in <xreftarget="fig-statemachine"/>. </t> <texttable title="Persistenttarget="fig-statemachine" format="default"/>.</t> <table anchor="tab-persistent" align="center"> <name>Persistent EAP-NOOBassociation" anchor="table-persistent"> <ttcol>Data Field</ttcol> <ttcol>Value</ttcol> <ttcol>Type</ttcol> <c>PeerId</c><c>PeerAssociation</name> <thead> <tr> <th align="left">Data Field</th> <th align="left">Value</th> <th align="left">Type</th> </tr> </thead> <tbody> <tr> <td align="left">PeerId</td> <td align="left">Peer identifier allocated byserver</c><c>UTF-8server</td> <td align="left">UTF-8 string (typically 22 ASCIIcharacters)</c> <c></c><c></c><c></c> <c>Verp</c><c>Negotiatedcharacters)</td> </tr> <tr> <td align="left">Verp</td> <td align="left">Negotiated protocolversion</c><c>integer</c> <c></c><c></c><c></c> <c>Cryptosuitep</c><c>Negotiated cryptosuite</c><c>integer</c> <c></c><c></c><c></c> <c>CryptosuitepPrevversion</td> <td align="left">integer</td> </tr> <tr> <td align="left">Cryptosuitep</td> <td align="left">Negotiated cryptosuite</td> <td align="left">integer</td> </tr> <tr> <td align="left">CryptosuitepPrev (at peeronly)</c><c>Previous cryptosuite</c><c>integer</c> <c></c><c></c><c></c> <c>NAI</c><c>NAIonly)</td> <td align="left">Previous cryptosuite</td> <td align="left">integer</td> </tr> <tr> <td align="left">NAI</td> <td align="left">NAI assigned byserver,the server or configured byuser,the user or the default NAI"noob@eap-noob.arpa"</c><c>UTF-8 string</c> <c>Kz</c><c>Persistent"noob@eap-noob.arpa"</td> <td align="left">UTF-8 string</td> </tr> <tr> <td align="left">Kz</td> <td align="left">Persistent keymaterial</c><c>32 bytes</c> <c></c><c></c><c></c> <c>KzPrevmaterial</td> <td align="left">32 bytes</td> </tr> <tr> <td align="left">KzPrev (at peeronly)</c><c>Previousonly)</td> <td align="left">Previous Kzvalue</c><c>32 bytes</c> </texttable>value</td> <td align="left">32 bytes</td> </tr> </tbody> </table> </section> <sectiontitle="Reconnect Exchange" anchor="reconnectexchange"> <t> Theanchor="reconnectexchange" numbered="true" toc="default"> <name>Reconnect Exchange</name> <t>The server chooses the Reconnect Exchange when both the peer and the server are in a persistent state and fast reconnection is needed (see <xreftarget="commonhandshake"/>target="commonhandshake" format="default"/> fordetails). </t> <t> Thedetails).</t> <t>The Reconnect Exchange comprises the common handshake and three further EAP-NOOB request-responsepairs,pairs: one for cryptosuite and parameter negotiation, another for the nonce and ECDHE key exchange, and the last one for exchanging message authentication codes. In the first request and response(Type=7)(Type=7), the server and peer negotiate a protocol version and cryptosuite in the same way as in the Initial Exchange. The serverSHOULD NOT<bcp14>SHOULD NOT</bcp14> offer and the peerMUST NOT<bcp14>MUST NOT</bcp14> accept protocol versions or cryptosuites that it knows to be weaker than the one currently in the Cryptosuitep field of the persistent EAP-NOOB association. The serverSHOULD NOT<bcp14>SHOULD NOT</bcp14> needlessly change the cryptosuites it offers to the same peer because peer devices may have limited ability to update their persistent storage. However, if the peer has different values in the Cryptosuitep and CryptosuitepPrev fields, itSHOULD<bcp14>SHOULD</bcp14> also accept offers that are not weaker than CryptosuitepPrev. Note that Cryptosuitep and CryptosuitePrev from the persistent EAP-NOOB association are only used to support the negotiation as described above; all actual cryptographic operations use the newly negotiated cryptosuite. The request and response (Type=7)MAY<bcp14>MAY</bcp14> additionally contain PeerInfo and ServerInfoobjects. </t> <t> Theobjects.</t> <t>The server then determines the KeyingMode (defined in <xreftarget="keyderivation"/>)target="keyderivation" format="default"/>) based on changes in the negotiated cryptosuite and whether it desires to achieve forward secrecy or not. The serverSHOULD<bcp14>SHOULD</bcp14> only select KeyingMode 3 when the negotiated cryptosuite differs from the Cryptosuitep in the server's persistent EAP-NOOB association, although it is technically possible to select this value without changing the cryptosuite. In the second request and response (Type=8), the server informs the peer about theKeyingMode,KeyingMode and the server and peer exchange nonces (Ns2, Np2). When KeyingMode is 2 or 3 (rekeying with ECDHE), they also exchange public components of ECDHE keys (PKs2, PKp2). The server ECDHE keyMUST<bcp14>MUST</bcp14> be fresh, i.e., not previously used with the same peer, and the peer ECDHE keySHOULD<bcp14>SHOULD</bcp14> be fresh, i.e., not previouslyused. </t> <t> Inused.</t> <t>In the third and final request and response (Type=9), the server and peer exchange message authentication codes. Both sidesMUST<bcp14>MUST</bcp14> compute the keys Kms2 andKmp2Kmp2, as defined in <xreftarget="keyderivation"/>target="keyderivation" format="default"/>, and the message authentication codes MACs2 andMACp2MACp2, as defined in <xreftarget="messagedatafields"/>.target="messagedatafields" format="default"/>. Both sidesMUST<bcp14>MUST</bcp14> compare the received message authentication code with a locally computedvalue. </t> <t> Thevalue.</t> <t>The rules by which the peer compares the received MACs2 arenon-trivialnontrivial because, in addition to authenticating the current exchange, MACs2 may confirm the success or failure of a recent cryptosuite upgrade. The peer processes the final request (Type=9) asfollows: </t> <t> <list style="numbers"> <t> Thefollows:</t> <ol spacing="normal" type="1"> <li>The peer first compares the received MACs2 value with one it computed using the Kz stored in the persistent EAP-NOOB association. If the received and computed values match, the peer deletes any data stored in the CryptosuitepPrev and KzPrev fields of the persistent EAP-NOOB association. It does this because the received MACs2 confirms that the peer and server share the same Cryptosuitep and Kz, and any previous values must no longer beaccepted. </t> <t> If, onaccepted.</li> <li>On the other hand, if the peer finds that the received MACs2 value does not match the one it computed locally with Kz, the peer checks whether the KzPrev field in the persistent EAP-NOOB association stores a key. If it does, the peer repeats the key derivation (<xreftarget="keyderivation"/>)target="keyderivation" format="default"/>) and local MACs2 computation (<xreftarget="messagedatafields"/>)target="messagedatafields" format="default"/>) using KzPrev in place of Kz. If this second computed MACs2 matches the received value, the match indicates synchronization failure caused by the loss of the last response (Type=9) in a previously attempted cryptosuite upgrade. In this case, the peer rolls back that upgrade by overwriting Cryptosuitep with CryptosuitepPrev and Kz with KzPrev in the persistent EAP-NOOB association. It also clears the CryptosuitepPrev and KzPrevfields. </t> <t> Iffields.</li> <li>If the received MACs2 matched one of the locally computed values, the peer proceeds to send the final response (Type=9). The peer also moves to the Registered (4) state. When KeyingMode is 1 or 2, the peer stops here. When KeyingMode is 3, the peer also updates the persistent EAP-NOOB association with the negotiated Cryptosuitep and thenewly-derivednewly derived Kz value. To prepare for possible synchronization failure caused by the loss of the final response (Type=9) during cryptosuite upgrade, the peer copies the old Cryptosuitep and Kz values in the persistent EAP-NOOB association to the CryptosuitepPrev and KzPrevfields. </t> <t> Finally,fields.</li> <li>Finally, if the peer finds that the received MACs2 does not match either of the two values that it computed locally (or one value if no KzPrev was stored), the peer sends an error message (error code 4001, see <xreftarget="invalidmessages"/>),target="cryptofailure" format="default"/>), which causes the Reconnect Exchange to end inEAP-Failure. </t> </list> </t> <t> TheEAP-Failure.</li> </ol> <t>The server rules for processing the final message are simpler than the peer rules because the server does not store previouskeys,keys and it never rolls back a cryptosuite upgrade. Upon receiving the final response (Type=9), the server compares the received value of MACp2 with one it computes locally. If the values match, the Reconnect Exchange ends in EAP-Success. When KeyingMode is 3, the server also updates Cryptosuitep and Kz in the persistent EAP-NOOB association. 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 Exchange ends inEAP-Failure. </t> <t> TheEAP-Failure.</t> <t>The endpointsMAY<bcp14>MAY</bcp14> send updated NewNAI,ServerInfoServerInfo, and PeerInfo objects in the Reconnect Exchange. When there is no update to the values, theySHOULD<bcp14>SHOULD</bcp14> omit this information from the messages. If the NewNAI was sent, each side updates NAI in the persistent EAP-NOOB association when moving to the Registered (4)state. </t> <t>state.</t> <figureanchor="fig-reconnect" title="Reconnect Exchange">anchor="fig-reconnect"> <name>Reconnect Exchange</name> <artworkalign="center"> <![CDATA[align="center" name="" type="" alt=""><![CDATA[ EAP Peer EAP Server | ...continuing from common handshake | | | |<----------- EAP-Request/EAP-NOOB ----------------| | (Type=7,Vers,PeerId,Cryptosuites, | | [NewNAI],[ServerInfo]) | | | | | |------------ EAP-Response/EAP-NOOB -------------->| | (Type=7,Verp,PeerId,Cryptosuitep,[PeerInfo])| | | | | |<----------- EAP-Request/EAP-NOOB ----------------| | (Type=8,PeerId,KeyingMode,[PKs2],Ns2) | | | | | |------------ EAP-Response/EAP-NOOB -------------->| | (Type=8,PeerId,[PKp2],Np2) | | | | | |<----------- EAP-Request/EAP-NOOB ----------------| | (Type=9,PeerId,MACs2) | | | | | |------------ EAP-Response/EAP-NOOB -------------->| | (Type=9,PeerId,MACp2) | | | | | |<----------- EAP-Success -------------------------| | |]]> </artwork>]]></artwork> </figure></t></section> <sectiontitle="User reset" anchor="userreset"> <t> Asanchor="userreset" numbered="true" toc="default"> <name>User Reset</name> <t>As shown in the association state machine in <xreftarget="fig-statemachine"/>,target="fig-statemachine" format="default"/>, the only specified way for the association to return from the Registeredstate(4) state to the Unregisteredstate(0) state is through user-initiated reset. After the reset, a new OOB message will be needed to establish a new association between the EAP server and peer. Typical situations in which the user reset is required are when the other side has accidentally lost the persistent EAP-NOOB associationdata,data or when the peer device isdecommissioned. </t> <t> Thedecommissioned.</t> <t>The server could detect that the peer is in the Registered or Reconnectingstatestate, but the server itself is in one of the ephemeral states 0..2 (including situations where the server does not recognize the PeerId). In this case, effort should be made to recover the persistent server state, for example, from a backup storage--- especially if many peer devices are similarly affected. If that is not possible, the EAP serverSHOULD<bcp14>SHOULD</bcp14> log the error or notify an administrator. The only way to continue from such a situation is by having the user reset the peerdevice. </t> <t> Ondevice.</t> <t>On the other hand, if the peer is in any of the ephemeral states 0..2, including the Unregistered state, the server will treat the peer as a new peer device and allocate a new PeerId to it. The PeerInfo can be used by the user as a clue to which physical device has lost its state. However, there is no secure way of matching the "new" peer with the old PeerId without repeating the OOB Step. This situation will be resolved when the user performs the OOB Stepand, thus,and thus identifies the physical peer device. The server user interfaceMAY<bcp14>MAY</bcp14> support situations where the "new" peer is actually a previously registered peer that has been reset by a user or otherwise lost its persistent data. In those cases, the user could choose to merge the new peer identity with the old one in the server. The alternative is to treat the device just like a newpeer. </t>peer.</t> </section> </section> <sectiontitle="Key derivation" anchor="keyderivation"> <t> EAP-NOOBanchor="keyderivation" numbered="true" toc="default"> <name>Key Derivation</name> <t>EAP-NOOB derives the EAP output values MSK and EMSK and other secret keying material from the output of an Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) algorithm following the NIST specification <xreftarget="NIST-DH"/>.target="NIST-DH" format="default"/>. In NIST terminology, we use a C(2e, 0s, ECC CDH) scheme, i.e., two ephemeral keys and no static keys. In the Initial Exchange and ReconnectExchanges,Exchange, the server and peer compute the ECDHE shared secretZZ, as defined in<xref target="NIST-DH">sectionSection 6.1.2 of the NISTspecification</xref>.specification <xref target="NIST-DH" />. In the Completion Exchange and ReconnectExchanges,Exchange, the server and peer compute the secret keying material from Z with the one-step key derivation function (KDF) defined insectionSection 5.8.2.1 of the NIST specification. The auxiliary function H is a hash function, and it is taken from the negotiatedcryptosuite. </t> <texttable title="Keying modes" anchor="keyingmodes"> <ttcol>KeyingMode</ttcol> <ttcol>Description</ttcol> <c>0</c><c>Completioncryptosuite.</t> <table anchor="keyingmodes" align="center"> <name>Keying Modes</name> <thead> <tr> <th align="left">KeyingMode</th> <th align="left">Description</th> </tr> </thead> <tbody> <tr> <td align="left">0</td> <td align="left">Completion Exchange (always withECDHE)</c> <c></c><c></c> <c>1</c><c>ReconnectECDHE)</td> </tr> <tr> <td align="left">1</td> <td align="left">Reconnect Exchange, rekeying withoutECDHE</c> <c></c><c></c> <c>2</c><c>ReconnectECDHE</td> </tr> <tr> <td align="left">2</td> <td align="left">Reconnect Exchange, rekeying with ECHDE, no change incryptosuite</c> <c></c><c></c> <c>3</c><c>Reconnectcryptosuite</td> </tr> <tr> <td align="left">3</td> <td align="left">Reconnect Exchange, rekeying with ECDHE, new cryptosuitenegotiated</c> </texttable> <t> Thenegotiated</td> </tr> </tbody> </table> <t>The key derivation has four different modes (KeyingMode), which are specified in <xreftarget="keyingmodes"/>.target="keyingmodes" format="default"/>. <xreftarget="table-keyderivationinput"/>target="tab-keyderivationinput" format="default"/> defines the inputs to KDF in eachKeyingMode. </t> <t> InKeyingMode.</t> <t>In the Completion Exchange (KeyingMode=0), the input Z comes from the preceding Initial exchange. The KDF takes some additional inputs (FixedInfo), for which we use the concatenation format defined in<xref target="NIST-DH">sectionSection 5.8.2.1.1 of the NISTspecification</xref>.specification <xref target="NIST-DH" />. FixedInfo consists of the AlgorithmId, PartyUInfo, PartyVInfo, and SuppPrivInfo fields. The first three fields are fixed-length bit strings, and SuppPrivInfo is a variable-length string with a one-byte Datalength counter. AlgorithmId is thefixed-lengthfixed-length, 8-byte ASCII string "EAP-NOOB". The other input values are the server and peer nonces. In the Completion Exchange, the inputs also include the secret nonce Noob from the OOBmessage. </t> <t> Inmessage.</t> <t>In the simplest form of the Reconnect Exchange (KeyingMode=1), fresh nonces areexchangedexchanged, but no ECDHE keys are sent. In this case, input Z to the KDF is replaced with the shared key Kz from the persistent EAP-NOOB association. The result is rekeying without the computational cost of the ECDHEexchange,exchange but also without forwardsecrecy. </t> <t> Whensecrecy.</t> <t>When forward secrecy is desired in the Reconnect Exchange (KeyingMode=2 or KeyingMode=3), both nonces and ECDHE keys are exchanged. Input Z is the fresh shared secret from the ECDHE exchange with PKs2 and PKp2. The inputs also include the shared secret Kz from the persistent EAP-NOOB association. This binds the rekeying output to the previously authenticatedkeys. </t> <texttable title="Key derivation input" anchor="table-keyderivationinput"> <ttcol>KeyingMode</ttcol> <ttcol>KDFkeys.</t> <table anchor="tab-keyderivationinput" align="center"> <name>Key Derivation Input</name> <thead> <tr> <th align="left">KeyingMode</th> <th align="left">KDF inputfield</ttcol> <ttcol>Value</ttcol> <ttcol>Length (bytes)</ttcol> <c>0 Completion</c><c>Z</c><c>ECDHEfield</th> <th align="left">Value</th> <th align="left">Length (bytes)</th> </tr> </thead> <tbody> <tr> <td align="left" rowspan="6">0 Completion</td> <td align="left">Z</td> <td align="left">ECDHE shared secret from PKs andPKp</c><c>variable</c> <c></c><c>AlgorithmId</c><c>"EAP-NOOB"</c><c>8</c> <c></c><c>PartyUInfo</c><c>Np</c><c>32</c> <c></c><c>PartyVInfo</c><c>Ns</c><c>32</c> <c></c><c>SuppPubInfo</c><c>(not allowed)</c><c></c> <c></c><c>SuppPrivInfo</c><c>Noob</c><c>16</c> <c></c><c></c><c></c><c></c> <c>1</c><c>Z</c><c>Kz</c><c>32</c> <c>Reconnect,</c><c>AlgorithmId</c><c>"EAP-NOOB"</c><c>8</c> <c>rekeying</c><c>PartyUInfo</c><c>Np2</c><c>32</c> <c>without</c><c>PartyVInfo</c><c>Ns2</c><c>32</c> <c>ECDHE</c><c>SuppPubInfo</c><c>(not allowed)</c><c></c> <c></c><c>SuppPrivInfo</c><c>(null)</c><c>0</c> <c></c><c></c><c></c><c></c> <c>2PKp</td> <td align="left">variable</td> </tr> <tr> <td align="left">AlgorithmId</td> <td align="left">"EAP-NOOB"</td> <td align="left">8</td> </tr> <tr> <td align="left">PartyUInfo</td> <td align="left">Np</td> <td align="left">32</td> </tr> <tr> <td align="left">PartyVInfo</td> <td align="left">Ns</td> <td align="left">32</td> </tr> <tr> <td align="left">SuppPubInfo</td> <td align="left">(not allowed)</td> <td align="left"/> </tr> <tr> <td align="left">SuppPrivInfo</td> <td align="left">Noob</td> <td align="left">16</td> </tr> <tr> <td align="left" rowspan="6">1 Reconnect, rekeying without ECDHE</td> <td align="left">Z</td> <td align="left">Kz</td> <td align="left">32</td> </tr> <tr> <td align="left">AlgorithmId</td> <td align="left">"EAP-NOOB"</td> <td align="left">8</td> </tr> <tr> <td align="left">PartyUInfo</td> <td align="left">Np2</td> <td align="left">32</td> </tr> <tr> <td align="left">PartyVInfo</td> <td align="left">Ns2</td> <td align="left">32</td> </tr> <tr> <td align="left">SuppPubInfo</td> <td align="left">(not allowed)</td> <td align="left"/> </tr> <tr> <td align="left">SuppPrivInfo</td> <td align="left">(null)</td> <td align="left">0</td> </tr> <tr> <td align="left" rowspan="6">2 or 3Reconnect,</c><c>Z</c><c>ECDHEReconnect, rekeying, with ECDHE, same or new cryptosuite</td> <td align="left">Z</td> <td align="left">ECDHE shared secret from PKs2 andPKp2</c><c>variable</c> <c>rekeying,</c><c>AlgorithmId</c><c>"EAP-NOOB"</c><c>8</c> <c>with ECDHE,</c><c>PartyUInfo</c><c>Np2</c><c>32</c> <c>same or new</c><c>PartyVInfo</c><c>Ns2</c><c>32</c> <c>cryptosuite</c><c>SuppPubInfo</c><c>(not allowed)</c><c></c> <c></c><c>SuppPrivInfo</c><c>Kz</c><c>32</c> </texttable> <t> <xref target="table-keyderivationoutput"/>PKp2</td> <td align="left">variable</td> </tr> <tr> <td align="left">AlgorithmId</td> <td align="left">"EAP-NOOB"</td> <td align="left">8</td> </tr> <tr> <td align="left">PartyUInfo</td> <td align="left">Np2</td> <td align="left">32</td> </tr> <tr> <td align="left">PartyVInfo</td> <td align="left">Ns2</td> <td align="left">32</td> </tr> <tr> <td align="left">SuppPubInfo</td> <td align="left">(not allowed)</td> <td align="left"/> </tr> <tr> <td align="left">SuppPrivInfo</td> <td align="left">Kz</td> <td align="left">32</td> </tr> </tbody> </table> <t><xref target="tab-keyderivationoutput" format="default"/> defines how the output bytes of the KDF are used. In addition to the EAP output values MSK and EMSK, the server and peer derive another shared secret keyAMSK,AMSK (Application Main Session Key), whichMAY<bcp14>MAY</bcp14> be used for application-layer security. Further output bytes are used internally by EAP-NOOB for the message authentication keys (Kms, Kmp, Kms2,Kmp2). </t> <t> Theand Kmp2).</t> <t>The Completion Exchange (KeyingMode=0) produces the shared secret Kz, which the server and peer store in the persistent EAP-NOOB association. When a new cryptosuite is negotiated in the Reconnect Exchange (KeyingMode=3), it similarly produces a new Kz. In that case, the server and peer update both the cryptosuite and Kz in the persistent EAP-NOOB association. Additionally, the peer stores the previous Cryptosuitep and Kz values in the CryptosuitepPrev and KzPrev fields of the persistent EAP-NOOBassociation. </t> <texttable title="Key derivation output" anchor="table-keyderivationoutput"> <ttcol>KeyingMode</ttcol> <ttcol>KDFassociation.</t> <table anchor="tab-keyderivationoutput" align="center"> <name>Key Derivation Output</name> <thead> <tr> <th align="left">KeyingMode</th> <th align="left">KDF outputbytes</ttcol> <ttcol>Used as</ttcol> <ttcol>Length (bytes)</ttcol> <c>0</c><c>0..63</c><c>MSK</c><c>64</c> <c>Completion</c><c>64..127</c><c>EMSK</c><c>64</c> <c></c><c>128..191</c><c>AMSK</c><c>64</c> <c></c><c>192..223</c><c>MethodId</c><c>32</c> <c></c><c>224..255</c><c>Kms</c><c>32</c> <c></c><c>256..287</c><c>Kmp</c><c>32</c> <c></c><c>288..319</c><c>Kz</c><c>32</c> <c></c><c></c><c></c><c></c> <c>1 or 2</c><c>0..63</c><c>MSK</c><c>64</c> <c>Reconnect,</c><c>64..127</c><c>EMSK</c><c>64</c> <c>rekeying</c><c>128..191</c><c>AMSK</c><c>64</c> <c>without ECDHE,</c><c>192..223</c><c>MethodId</c><c>32</c> <c>or with ECDHE</c><c>224..255</c><c>Kms2</c><c>32</c> <c>and unchanged</c><c>256..287</c><c>Kmp2</c><c>32</c> <c>cryptosuite</c><c></c><c></c><c></c> <c></c><c></c><c></c><c></c> <c></c><c></c><c></c><c></c> <c>3 Reconnect,</c><c>0..63</c><c>MSK</c><c>64</c> <c>rekeying</c><c>64..127</c><c>EMSK</c><c>64</c> <c>with ECDHE,</c><c>128..191</c><c>AMSK</c><c>64</c> <c>new cryptosuite</c><c>192..223</c><c>MethodId</c><c>32</c> <c></c><c>224..255</c><c>Kms2</c><c>32</c> <c></c><c>256..287</c><c>Kmp2</c><c>32</c> <c></c><c>288..319</c><c>Kz</c><c>32</c> </texttable> <t> Finally,bytes</th> <th align="left">Used as</th> <th align="left">Length (bytes)</th> </tr> </thead> <tbody> <tr> <td align="left" rowspan="7">0 Completion</td> <td align="left">0..63</td> <td align="left">MSK</td> <td align="left">64</td> </tr> <tr> <td align="left">64..127</td> <td align="left">EMSK</td> <td align="left">64</td> </tr> <tr> <td align="left">128..191</td> <td align="left">AMSK</td> <td align="left">64</td> </tr> <tr> <td align="left">192..223</td> <td align="left">MethodId</td> <td align="left">32</td> </tr> <tr> <td align="left">224..255</td> <td align="left">Kms</td> <td align="left">32</td> </tr> <tr> <td align="left">256..287</td> <td align="left">Kmp</td> <td align="left">32</td> </tr> <tr> <td align="left">288..319</td> <td align="left">Kz</td> <td align="left">32</td> </tr> <tr> <td align="left" rowspan="6">1 or 2 Reconnect, rekeying without ECDHE, or with ECDHE and unchanged cryptosuite</td> <td align="left">0..63</td> <td align="left">MSK</td> <td align="left">64</td> </tr> <tr> <td align="left">64..127</td> <td align="left">EMSK</td> <td align="left">64</td> </tr> <tr> <td align="left">128..191</td> <td align="left">AMSK</td> <td align="left">64</td> </tr> <tr> <td align="left">192..223</td> <td align="left">MethodId</td> <td align="left">32</td> </tr> <tr> <td align="left">224..255</td> <td align="left">Kms2</td> <td align="left">32</td> </tr> <tr> <td align="left">256..287</td> <td align="left">Kmp2</td> <td align="left">32</td> </tr> <tr> <td align="left" rowspan="7">3 Reconnect, rekeying with ECDHE, new cryptosuite</td> <td align="left">0..63</td> <td align="left">MSK</td> <td align="left">64</td> </tr> <tr> <td align="left">64..127</td> <td align="left">EMSK</td> <td align="left">64</td> </tr> <tr> <td align="left">128..191</td> <td align="left">AMSK</td> <td align="left">64</td> </tr> <tr> <td align="left">192..223</td> <td align="left">MethodId</td> <td align="left">32</td> </tr> <tr> <td align="left">224..255</td> <td align="left">Kms2</td> <td align="left">32</td> </tr> <tr> <td align="left">256..287</td> <td align="left">Kmp2</td> <td align="left">32</td> </tr> <tr> <td align="left">288..319</td> <td align="left">Kz</td> <td align="left">32</td> </tr> </tbody> </table> <t>Finally, every EAP method must export a Server-Id, Peer-Id, and Session-Id <xreftarget="RFC5247"/>.target="RFC5247" format="default"/>. In EAP-NOOB, the exported Peer-Id is the PeerIdwhichthat the server has assigned to the peer. The exported Server-Id is a zero-length string (i.e., null string) because EAP-NOOB neither knows nor assigns any server identifier. The exported Session-Id is created by concatenating the one-byte Type-Codexxx (TBA)0x38 (decimal value 56) with the MethodId, which is obtained from the KDFoutputoutput, as shown in <xreftarget="table-keyderivationoutput"/>. </t>target="tab-keyderivationoutput" format="default"/>.</t> </section> <sectiontitle="Error handling" anchor="failure"> <t> Variousanchor="failure" numbered="true" toc="default"> <name>Error Handling</name> <t>Various error conditions in EAP-NOOB are handled by sending an error notification message (Type=0) instead of a next EAP request or response message. Both the EAP server and the peer may send the error notification, as shown in Figures <xreftarget="fig-servererror"/>target="fig-servererror" format="counter"/> and <xreftarget="fig-peererror"/>.target="fig-peererror" format="counter"/>. After sending or receiving an error notification, the serverMUST<bcp14>MUST</bcp14> send an EAP-Failure (as required by <xreftarget="RFC3748"/> section 4.2).target="RFC3748" sectionFormat="comma" section="4.2"/>). The notificationMAY<bcp14>MAY</bcp14> contain an ErrorInfo field, which is aUTF-8 encodedUTF-8-encoded text string with a maximum length of 500 bytes. It is used for sending descriptive information about the error for logging and debuggingpurposes. </t> <t>purposes.</t> <figureanchor="fig-servererror" title="Error notificationanchor="fig-servererror"> <name>Error Notification fromserverServer topeer">Peer</name> <artworkalign="center"> <![CDATA[align="center" name="" type="" alt=""><![CDATA[ EAP Peer EAP Server ... ... | | |<----------- EAP-Request/EAP-NOOB ----------------| | (Type=0,[PeerId],ErrorCode,[ErrorInfo]) | | | | | |<----------- EAP-Failure -------------------------| | |]]> </artwork>]]></artwork> </figure></t> <t><figureanchor="fig-peererror" title="Error notificationanchor="fig-peererror"> <name>Error Notification frompeerPeer toserver">Server</name> <artworkalign="center"> <![CDATA[align="center" name="" type="" alt=""><![CDATA[ EAP Peer EAP Server ... ... | | |------------ EAP-Response/EAP-NOOB -------------->| | (Type=0,[PeerId],ErrorCode,[ErrorInfo]) | | | | | |<----------- EAP-Failure -------------------------| | |]]> </artwork>]]></artwork> </figure></t> <t> After<t>After the exchange fails due to an error notification, the server and peer set the association state as follows. In the Initial Exchange, both the sender and recipient of the error notificationMUST<bcp14>MUST</bcp14> set the association state to the Unregistered (0) state. In the Waiting Exchange and CompletionExchanges,Exchange, each sideMUST<bcp14>MUST</bcp14> remain in its old state as if the failed exchange had not taken place, with the exception that the recipient of error code 2003 processes it as specified in <xreftarget="completionexchange"/>.target="completionexchange" format="default"/>. In the Reconnect Exchange, both sidesMUST<bcp14>MUST</bcp14> set the association state to the Reconnecting (3)state. </t> <t> Errorsstate.</t> <t>Errors that occur in the OOB channel are not explicitly notifiedin-band. </t>in-band.</t> <sectiontitle="Invalid messages" anchor="invalidmessages"> <t> Ifanchor="invalidmessages" numbered="true" toc="default"> <name>Invalid Messages</name> <t>If the NAI structure is invalid, the serverSHOULD<bcp14>SHOULD</bcp14> send the error code 1001 to the peer. The recipient of an EAP-NOOB request or responseSHOULD<bcp14>SHOULD</bcp14> send the following error codes back to the sender: 1002 if it cannot parse the message as a JSON object or the top-level JSON object has missing or unrecognized members; 1003 if a data field has an invalid value, such as an integer out of range, and there is no more specific error code available; 1004 if the received message type was unexpected in the current state; 2004 if the PeerId has an unexpected value; 2003 if the NoobId is not recognized; and 1005 if the ECDHE key isinvalid. </t>invalid.</t> </section> <sectiontitle="Unwanted peer" anchor="unwantedpeer"> <t> Theanchor="unwantedpeer" numbered="true" toc="default"> <name>Unwanted Peer</name> <t>The preferred way for the EAP server to rate limit EAP-NOOB connections from a peer is to use the SleepTime parameter in the Waiting Exchange. However, if the EAP server receives repeated EAP-NOOB connections from a peerwhichthat apparently should not connect to this server, the serverMAY<bcp14>MAY</bcp14> indicate that the connections are unwanted by sending the error code 2001. After receiving this error message, the peerMAY<bcp14>MAY</bcp14> refrain from reconnecting to the same EAPserverserver, and, if possible, both the EAP server and peerSHOULD<bcp14>SHOULD</bcp14> indicate this error condition to the user or server administrator. However, in order to avoid persistent denial of service, peer devices that are unable to alert a userSHOULD<bcp14>SHOULD</bcp14> continue to try to reconnect infrequently (e.g., approximately every 3600 seconds). </t> </section> <sectiontitle="State mismatch" anchor="statemismatch"> <t> Inanchor="statemismatch" numbered="true" toc="default"> <name>State Mismatch</name> <t>In the states indicated by "-" in <xreftarget="table-exchanges"/>target="tab-exchanges" format="default"/> in <xreftarget="exchangeappendix"/>,target="exchangeappendix" format="default"/>, user action is required to reset the association state or to recover it, for example, from backup storage. In those cases, the server sends the error code 2002 to the peer. If possible, both the EAP server and peerSHOULD<bcp14>SHOULD</bcp14> indicate this error condition to the user or serveradministrator. </t>administrator.</t> </section> <sectiontitle="Negotiation failure" anchor="negotiationfailure"> <t> Ifanchor="negotiationfailure" numbered="true" toc="default"> <name>Negotiation Failure</name> <t>If there is no matching protocol version, the peer sends the error code 3001 to the server. If there is no matching cryptosuite, the peer sends the error code 3002 to the server. If there is no matching OOB direction, the peer sends the error code 3003 to theserver. </t> <t> Inserver.</t> <t>In practice, there is no way of recovering from these errors without software or hardware changes. If possible, both the EAP server and peerSHOULD<bcp14>SHOULD</bcp14> indicate these error conditions to theuser. </t>user.</t> </section> <sectiontitle="Cryptographic verification failure" anchor="cryptofailure"> <t> Ifanchor="cryptofailure" numbered="true" toc="default"> <name>Cryptographic Verification Failure</name> <t>If the receiver of the OOB message detects an unrecognized PeerId or incorrect fingerprint (Hoob) in the OOB message, the receiverMUST<bcp14>MUST</bcp14> remain in the Waiting for OOBstate(1) state as if no OOB message was received. The receiverSHOULD<bcp14>SHOULD</bcp14> indicate the failure to accept the OOB message to the user. No in-band error message issent. </t> <t> Notesent.</t> <t>Note that if the OOB message was delivered from the server to the peer and the peer does not recognize the PeerId, the likely cause is that the user has unintentionally delivered the OOB message to the wrong peer device. If possible, the peerSHOULD<bcp14>SHOULD</bcp14> indicate this to the user; however, the peer device may not have the capability for many different error indications to the user, and itMAY<bcp14>MAY</bcp14> use the same indication as in the case of an incorrectfingerprint. </t> <t> Thefingerprint.</t> <t>The rationale for the above is that the invalid OOB message could have been presented to the receiver by mistake or intentionally by a maliciousparty and,party; thus, it should be ignored in the hope that the honest user will soon deliver a correct OOBmessage. </t> <t> Ifmessage.</t> <t>If the EAP server or peer detects an incorrect message authentication code (MACs, MACp, MACs2, or MACp2), it sends the error code 4001 to the other side. As specified in the beginning of <xreftarget="failure"/>,target="failure" format="default"/>, the failed Completion Exchange will not result in server or peer statechangeschanges, while an error in the Reconnect Exchange will put both sides to the Reconnecting (3) state and thus lead to another reconnectattempt. </t> <t> Theattempt.</t> <t>The rationale for this is that the invalid cryptographic message may have been spoofed by a maliciousparty and,party; thus, it should be ignored. In particular, a spoofed message on the in-band channel should not force the honest user to perform the OOB Step again. In practice, however, the error may be caused by other failures, such as a software bug. For this reason, the EAP serverMAY<bcp14>MAY</bcp14> limit the rate of peer connections with SleepTime after the above error. Also, thereSHOULD<bcp14>SHOULD</bcp14> be a way for the user to reset the peer to the Unregistered (0) state(0),so that the OOB Step can be repeated as the lastresort. </t>resort.</t> </section> <sectiontitle="Application-specific failure" anchor="appfailure"> <t> Applications MAYanchor="appfailure" numbered="true" toc="default"> <name>Application-Specific Failure</name> <t>Applications <bcp14>MAY</bcp14> define new error messages for failures that are specific to the application or to one type of OOB channel. TheyMAY<bcp14>MAY</bcp14> also use the generic application-specific error code5001,5001 or the error codes 5002 and 5004, which have been reserved for indicating invalid data in the ServerInfo and PeerInfo fields, respectively. Additionally, anticipating OOB channels that make use of a URL, the error code 5003 has been reserved for indicating an invalid serverURL. </t>URL.</t> </section> </section> </section> <sectiontitle="ServerInfoanchor="serverinfo-peerinfo-meaning" numbered="true" toc="default"> <name>ServerInfo and PeerInfocontents" anchor="serverinfo-peerinfo-meaning"> <t> TheContents</name> <t>The ServerInfo and PeerInfo fields in the Initial Exchange and Reconnect Exchange enable the server and peer, respectively, to send information about themselves to the other endpoint. They contain JSON objects whose structure may be specified separately for each application and each type of OOB channel. ServerInfo and PeerInfoMAY<bcp14>MAY</bcp14> contain auxiliary data needed for the OOB channel messaging and for EAP channel binding (see <xreftarget="channel-binding"/>).target="channel-binding" format="default"/>). This section describes the optional initial data fields for ServerInfo and PeerInfo registered by this specification. Further specifications may request new application-specific ServerInfo and PeerInfo data fields from IANA (see Sections <xreftarget="serverinfo-data-fields"/>target="serverinfo-data-fields" format="counter"/> and <xreftarget="peerinfo-data-fields"/>).target="peerinfo-data-fields" format="counter"/>). </t><texttable title="ServerInfo data fields" anchor="table-serverinfo-meaning"> <ttcol>Data Field</ttcol> <ttcol>Description</ttcol> <c>Type</c><c>Type-tag<table anchor="tab-serverinfo-meaning" align="center"> <name>ServerInfo Data Fields</name> <thead> <tr> <th align="left">Data Field</th> <th align="left">Description</th> </tr> </thead> <tbody> <tr> <td align="left">Type</td> <td align="left">Type-tag string that can be used by the peer as a hint for how to interpret the ServerInfocontents.</c> <c></c><c></c> <c>ServerName</c><c>Stringcontents.</td> </tr> <tr> <td align="left">ServerName</td> <td align="left">String that may be used to aid human identification of theserver.</c> <c></c><c></c> <c>ServerURL</c><c>Prefixserver.</td> </tr> <tr> <td align="left">ServerURL</td> <td align="left">Prefix string when the OOB message is formatted as a URL, as suggested in <xreftarget="urloob"/>.</c> <c></c><c></c> <c>SSIDList</c><c>Listtarget="urloob" format="default"/>.</td> </tr> <tr> <td align="left">SSIDList</td> <td align="left">List of IEEE 802.11 wireless network service set identifier (SSID) strings used for roaming support, as suggested in <xreftarget="roaming"/>.target="roaming" format="default"/>. JSON array ofASCII encodedASCII-encoded SSIDstrings.</c> <c></c><c></c> <c>Base64SSIDList</c><c>Liststrings.</td> </tr> <tr> <td align="left">Base64SSIDList</td> <td align="left">List of IEEE 802.11 wireless network identifier (SSID) strings used for roaming support, as suggested in <xreftarget="roaming"/>.target="roaming" format="default"/>. JSON array of SSIDs, each of which isbase64url encodedbase64url-encoded without padding. PeersSHOULD<bcp14>SHOULD</bcp14> send at most one of the fields SSIDList and Base64SSIDList in PeerInfo, and the serverSHOULD<bcp14>SHOULD</bcp14> ignore SSIDList if Base64SSIDList isincluded.</c> </texttable> <texttable title="PeerInfo data fields" anchor="table-peerinfo-meaning"> <ttcol>Data Field</ttcol> <ttcol>Description</ttcol> <c>Type</c><c>Type-tagincluded.</td> </tr> </tbody> </table> <table anchor="tab-peerinfo-meaning" align="center"> <name>PeerInfo Data Fields</name> <thead> <tr> <th align="left">Data Field</th> <th align="left">Description</th> </tr> </thead> <tbody> <tr> <td align="left">Type</td> <td align="left">Type-tag string that can be used by the server as a hint for how to interpret the PeerInfocontents.</c> <c></c><c></c> <c>PeerName</c><c>Stringcontents.</td> </tr> <tr> <td align="left">PeerName</td> <td align="left">String that may be used to aid human identification of thepeer.</c> <c></c><c></c> <c>Manufacturer</c><c>Manufacturerpeer.</td> </tr> <tr> <td align="left">Manufacturer</td> <td align="left">Manufacturer or brandstring.</c> <c></c><c></c> <c>Model</c><c>Manufacturer-specifiedstring.</td> </tr> <tr> <td align="left">Model</td> <td align="left">Manufacturer-specified modelstring.</c> <c></c><c></c> <c>SerialNumber</c><c>Manufacturer-assignedstring.</td> </tr> <tr> <td align="left">SerialNumber</td> <td align="left">Manufacturer-assigned serialnumber.</c> <c></c><c></c> <c>MACAddress</c><c>Peernumber.</td> </tr> <tr> <td align="left">MACAddress</td> <td align="left">Peer link-layer 48-bit extended unique identifier (EUI-48) in the 12-digit base-16 form <xreftarget="EUI-48"/>.target="EUI-48" format="default"/>. The stringMAY<bcp14>MAY</bcp14> be in upper or lower case andMAY<bcp14>MAY</bcp14> include additional colon ':' or dash '-' characters thatMUST<bcp14>MUST</bcp14> be ignored by theserver.</c> <c></c><c></c> <c>SSID</c><c>IEEEserver.</td> </tr> <tr> <td align="left">SSID</td> <td align="left">IEEE 802.11 network SSID for channel binding. The SSID is an ASCIIstring.</c> <c></c><c></c> <c>Base64SSID</c><c>IEEEstring.</td> </tr> <tr> <td align="left">Base64SSID</td> <td align="left">IEEE 802.11 network SSID for channel binding. The SSID is base64url encoded. PeerSHOULD<bcp14>SHOULD</bcp14> send at most one of the fields SSID and Base64SSID in PeerInfo, and the serverSHOULD<bcp14>SHOULD</bcp14> ignore SSID if Base64SSID isincluded.</c> <c></c><c></c> <c>BSSID</c><c>Wirelessincluded.</td> </tr> <tr> <td align="left">BSSID</td> <td align="left">Wireless networkBSSIDbasic service set identifier (BSSID) (EUI-48) in the 12-digit base-16 form <xreftarget="EUI-48"/>target="EUI-48" format="default"/> for channel binding. The stringMAY<bcp14>MAY</bcp14> be in upper or lower case andMAY<bcp14>MAY</bcp14> include additional colon ':' or dash '-' characters thatMUST<bcp14>MUST</bcp14> be ignored by theserver.</c> <c></c><c></c> </texttable>server.</td> </tr> </tbody> </table> </section> <sectiontitle="IANA Considerations" anchor="iana"> <t> Thisanchor="iana" numbered="true" toc="default"> <name>IANA Considerations</name> <t>This section providesguidance to the Internet Assigned Numbers Authority (IANA)information regarding registration of values related to the EAP-NOOBprotocol,method, in accordance with <xreftarget="RFC8126"/>. </t> <t> Thetarget="RFC8126" format="default"/>.</t> <t>The EAP Method Typenumberfor EAP-NOOBneeds to be(value 56) has been assigned in theMethod Types sub-registry"Method Types" subregistry of theExtensible"Extensible Authentication Protocol (EAP)registry (requested value = 56). </t> <t> This memo also requiresRegistry".</t> <t>Per this memo, IANAto createhas created and will maintain a new registry entitled "Nimbleout-of-band authenticationOut-of-Band Authentication for EAPParameters"Parameters (EAP-NOOB)" in the Extensible Authentication Protocol (EAP)registry.category. Also, IANAis also requested to createhas created and will maintainsub-registriesthe subregistries defined in the following subsections. </t> <sectiontitle="Cryptosuites" anchor="cryptosuites"> <t> IANA is requested to createanchor="cryptosuites" numbered="true" toc="default"> <name>Cryptosuites</name> <t>IANA has created and will maintain a newsub-registrysubregistry entitled "EAP-NOOB Cryptosuites" in the "Nimbleout-of-band authenticationOut-of-Band Authentication for EAPParameters"Parameters (EAP-NOOB)" registry. Cryptosuites are identified by an integer. Each cryptosuiteMUST<bcp14>MUST</bcp14> specify an ECDHE curve for the key exchange, encoding of the ECDHE public key as a JWK object, and a cryptographic hash function for the fingerprint and HMAC computation and key derivation. The hash value output by the cryptographic hash functionMUST<bcp14>MUST</bcp14> be at least 32 bytes in length. The initial values for this registryare: </t> <texttable title="EAP-NOOB cryptosuites" anchor="table-cryptosuites"> <ttcol>Cryptosuite</ttcol> <ttcol>Algorithms</ttcol> <c>1</c><c>ECDHEare:</t> <table anchor="tab-cryptosuites" align="center"> <name>EAP-NOOB Cryptosuites</name> <thead> <tr> <th align="left">Cryptosuite</th> <th align="left">Algorithms</th> </tr> </thead> <tbody> <tr> <td align="left">0</td> <td align="left">Reserved</td> </tr> <tr> <td align="left">1</td> <td align="left">ECDHE curve Curve25519 <xreftarget="RFC7748"/>,target="RFC7748" format="default"/>, public-key format <xreftarget="RFC7517"/>,target="RFC7517" format="default"/>, hash function SHA-256 <xreftarget="RFC6234"/>.target="RFC6234" format="default"/>. The JWK encoding of Curve25519 public key is defined in <xreftarget="RFC8037"/>.target="RFC8037" format="default"/>. Forclarity:clarity, the "crv" parameter is "X25519", the "kty" parameter is "OKP", and the public-key encoding contains only anx-coordinate.</c> <c>2</c><c>ECDHEx-coordinate.</td> </tr> <tr> <td align="left">2</td> <td align="left">ECDHE curve NIST P-256 <xreftarget="FIPS186-4"/>,target="FIPS186-4" format="default"/>, public-key format <xreftarget="RFC7517"/>,target="RFC7517" format="default"/>, hash function SHA-256 <xreftarget="RFC6234"/>.target="RFC6234" format="default"/>. The JWK encoding of NIST P-256 public key is defined in <xreftarget="RFC7518"/>.target="RFC7518" format="default"/>. Forclarity:clarity, the "crv" parameter is "P-256", the "kty" parameter is "EC", and the public-key encoding has both an x and ycoordinatescoordinate, as defined inSection 6.2.1 of<xreftarget="RFC7518"/>.</c> </texttable> <t> EAP-NOOBtarget="RFC7518" sectionFormat="of" section="6.2.1"/>.</td> </tr> </tbody> </table> <t>EAP-NOOB implementationsMUST<bcp14>MUST</bcp14> support Cryptosuite 1. Support for Cryptosuite 2 isRECOMMENDED.<bcp14>RECOMMENDED</bcp14>. An example of a Cryptosuite 1 public-key encoded as a JWK object is givenbelow (linebelow. (Line breaks are for readabilityonly). </t> <t> "jwk":{"kty":"OKP","crv":"X25519","x":"3p7bfXt9wbTTW2HC7OQ1Nz-DQ8hbeGdNrfx-FG-IK08"} </t> <t> Assignmentonly.)</t> <sourcecode type="json"> "jwk":{"kty":"OKP","crv":"X25519","x":"3p7bfXt9wbTTW2HC7OQ1Nz- DQ8hbeGdNrfx-FG-IK08"} </sourcecode> <t>Assignment of new values for new cryptosuitesMUST<bcp14>MUST</bcp14> be done through IANA with "SpecificationRequired"Required", as defined in <xreftarget="RFC8126"/>. </t>target="RFC8126" format="default"/>.</t> </section> <sectiontitle="Message Types" anchor="messagetypes"> <t> IANA is requested to createanchor="messagetypes" numbered="true" toc="default"> <name>Message Types</name> <t>IANA has created and will maintain a newsub-registrysubregistry entitled "EAP-NOOB Message Types" in the "Nimbleout-of-band authenticationOut-of-Band Authentication for EAPParameters"Parameters (EAP-NOOB)" registry. EAP-NOOB request and response pairs are identified by an integer Message Type. The initial values for this registryare: </t> <texttable title="EAP-NOOBare:</t> <table anchor="tab-messagetypes" align="center"> <name>EAP-NOOB MessageTypes" anchor="table-messagetypes"> <ttcol>Message Type</ttcol> <ttcol>Used in Exchange</ttcol> <ttcol>Purpose</ttcol> <c>1</c><c>All exchanges</c><c>PeerIdTypes</name> <thead> <tr> <th align="left">Message Type</th> <th align="left">Used in Exchange</th> <th align="left">Purpose</th> </tr> </thead> <tbody> <tr> <td align="left">0</td> <td align="left">Error</td> <td align="left">Error notification</td> </tr> <tr> <td align="left">1</td> <td align="left">All exchanges</td> <td align="left">PeerId and PeerStatediscovery</c> <c></c><c></c><c></c> <c>2</c><c>Initial</c><c>Version, cryptosuitediscovery</td> </tr> <tr> <td align="left">2</td> <td align="left">Initial</td> <td align="left">Version, cryptosuite, and parameternegotiation</c> <c></c><c></c><c></c> <c>3</c><c>Initial</c><c>Exchangenegotiation</td> </tr> <tr> <td align="left">3</td> <td align="left">Initial</td> <td align="left">Exchange of ECDHE keys andnonces</c> <c></c><c></c><c></c> <c>4</c><c>Waiting</c><c>Indicationnonces</td> </tr> <tr> <td align="left">4</td> <td align="left">Waiting</td> <td align="left">Indication to the peer that the server has not yet received an OOBmessage</c> <c></c><c></c><c></c> <c>5</c><c>Completion</c><c>NoobId discovery</c> <c></c><c></c><c></c> <c>6</c><c>Completion</c><c>Authenticationmessage</td> </tr> <tr> <td align="left">5</td> <td align="left">Completion</td> <td align="left">NoobId discovery</td> </tr> <tr> <td align="left">6</td> <td align="left">Completion</td> <td align="left">Authentication and key confirmation withHMAC</c> <c></c><c></c><c></c> <c>7</c><c>Reconnect</c><c>Version,HMAC</td> </tr> <tr> <td align="left">7</td> <td align="left">Reconnect</td> <td align="left">Version, cryptosuite, and parameternegotiation</c> <c></c><c></c><c></c> <c>8</c><c>Reconnect</c><c>Exchangenegotiation</td> </tr> <tr> <td align="left">8</td> <td align="left">Reconnect</td> <td align="left">Exchange of ECDHE keys andnonces</c> <c></c><c></c><c></c> <c>9</c><c>Reconnect</c><c>Authenticationnonces</td> </tr> <tr> <td align="left">9</td> <td align="left">Reconnect</td> <td align="left">Authentication and key confirmation withHMAC</c> <c></c><c></c><c></c> <c>0</c><c>Error</c><c>Error notification</c> <c></c><c></c><c></c> </texttable> <t> AssignmentHMAC</td> </tr> </tbody> </table> <t>Assignment of new values for new Message TypesMUST<bcp14>MUST</bcp14> be done through IANA with "SpecificationRequired"Required", as defined in <xreftarget="RFC8126"/>. </t>target="RFC8126" format="default"/>.</t> </section> <sectiontitle="Error codes" anchor="errorcodes"> <t> IANA is requested to createanchor="errorcodes" numbered="true" toc="default"> <name>Error Codes</name> <t>IANA has created and will maintain a newsub-registrysubregistry entitled "EAP-NOOB Error codes" in the "Nimbleout-of-band authenticationOut-of-Band Authentication for EAPParameters"Parameters (EAP-NOOB)" registry. Cryptosuites are identified by an integer. The initial values for this registryare: </t> <texttable title="EAP-NOOB error codes" anchor="table-errors"> <ttcol>Error code</ttcol> <ttcol>Purpose</ttcol> <c>1001</c> <c>Invalid NAI</c> <c>1002</c> <c>Invalid message structure</c> <c>1003</c> <c>Invalid data</c> <c>1004</c> <c>Unexpected message type</c> <c>1005</c> <c>Invalidare:</t> <table anchor="tab-errors" align="center"> <name>EAP-NOOB Error Codes</name> <thead> <tr> <th align="left">Error code</th> <th align="left">Purpose</th> </tr> </thead> <tbody> <tr> <td align="left">1001</td> <td align="left">Invalid NAI</td> </tr> <tr> <td align="left">1002</td> <td align="left">Invalid message structure</td> </tr> <tr> <td align="left">1003</td> <td align="left">Invalid data</td> </tr> <tr> <td align="left">1004</td> <td align="left">Unexpected message type</td> </tr> <tr> <td align="left">1005</td> <td align="left">Invalid ECDHEkey</c> <c>2001</c> <c>Unwanted peer</c> <c>2002</c> <c>Statekey</td> </tr> <tr> <td align="left">2001</td> <td align="left">Unwanted peer</td> </tr> <tr> <td align="left">2002</td> <td align="left">State mismatch, user actionrequired</c> <c>2003</c> <c>Unrecognized OOB message identifier</c> <c>2004</c> <c>Unexpected peer identifier</c> <c>3001</c> <c>Norequired</td> </tr> <tr> <td align="left">2003</td> <td align="left">Unrecognized OOB message identifier</td> </tr> <tr> <td align="left">2004</td> <td align="left">Unexpected peer identifier</td> </tr> <tr> <td align="left">3001</td> <td align="left">No mutually supported protocolversion</c> <c>3002</c> <c>Noversion</td> </tr> <tr> <td align="left">3002</td> <td align="left">No mutually supportedcryptosuite</c> <c>3003</c> <c>Nocryptosuite</td> </tr> <tr> <td align="left">3003</td> <td align="left">No mutually supported OOBdirection</c> <c>4001</c> <c>HMACdirection</td> </tr> <tr> <td align="left">4001</td> <td align="left">HMAC verificationfailure</c> <c>5001</c> <c>Application-specific error</c> <c>5002</c> <c>Invalid server info</c> <c>5003</c> <c>Invalid server URL</c> <c>5004</c> <c>Invalid peer info</c> <c>6001-6999</c> <c>Private and experimental use</c> </texttable> <t> Assignmentfailure</td> </tr> <tr> <td align="left">5001</td> <td align="left">Application-specific error</td> </tr> <tr> <td align="left">5002</td> <td align="left">Invalid server info</td> </tr> <tr> <td align="left">5003</td> <td align="left">Invalid server URL</td> </tr> <tr> <td align="left">5004</td> <td align="left">Invalid peer info</td> </tr> <tr> <td align="left">6001-6999</td> <td align="left">Reserved for Private and Experimental Use</td> </tr> </tbody> </table> <t>Assignment of new error codesMUST<bcp14>MUST</bcp14> be done through IANA with "SpecificationRequired"Required", as defined in <xreftarget="RFC8126"/>,target="RFC8126" format="default"/>, except for the range 6001-6999. This range is reserved for "Private Use" and "Experimental Use", both locally and on the openInternet. </t>Internet.</t> </section> <sectiontitle="ServerInfo data fields" anchor="serverinfo-data-fields"> <t> IANA is requested to createanchor="serverinfo-data-fields" numbered="true" toc="default"> <name>ServerInfo Data Fields</name> <t>IANA has created and will maintain a newsub-registrysubregistry entitled "EAP-NOOB ServerInfodata fields"Data Fields" in the "Nimbleout-of-band authenticationOut-of-Band Authentication for EAPParameters"Parameters (EAP-NOOB)" registry. The initial values for this registryare: </t> <texttable title="ServerInfo data fields" anchor="table-serverinfo-data-fields"> <ttcol>Data Field</ttcol> <ttcol>Specification</ttcol> <c>Type</c><c>This RFC <xref target="serverinfo-peerinfo-meaning"/></c> <c></c><c></c> <c>ServerName</c><c>This RFC <xref target="serverinfo-peerinfo-meaning"/></c> <c></c><c></c> <c>ServerURL</c><c>This RFC <xref target="serverinfo-peerinfo-meaning"/></c> <c></c><c></c> <c>SSIDList</c><c>This RFC <xref target="serverinfo-peerinfo-meaning"/></c> <c></c><c></c> <c>Base64SSIDList</c><c>This RFC <xref target="serverinfo-peerinfo-meaning"/></c> </texttable> <t> Assignmentare:</t> <table anchor="tab-serverinfo-data-fields" align="center"> <name>ServerInfo Data Fields</name> <thead> <tr> <th align="left">Data Field</th> <th align="left">Specification</th> </tr> </thead> <tbody> <tr> <td align="left">Type</td> <td align="left">RFC 9140, <xref target="serverinfo-peerinfo-meaning" format="default"/></td> </tr> <tr> <td align="left">ServerName</td> <td align="left">RFC 9140, <xref target="serverinfo-peerinfo-meaning" format="default"/></td> </tr> <tr> <td align="left">ServerURL</td> <td align="left">RFC 9140, <xref target="serverinfo-peerinfo-meaning" format="default"/></td> </tr> <tr> <td align="left">SSIDList</td> <td align="left">RFC 9140, <xref target="serverinfo-peerinfo-meaning" format="default"/></td> </tr> <tr> <td align="left">Base64SSIDList</td> <td align="left">RFC 9140, <xref target="serverinfo-peerinfo-meaning" format="default"/></td> </tr> </tbody> </table> <t>Assignment of new values for new ServerInfo data fieldsMUST<bcp14>MUST</bcp14> be done through IANA with "SpecificationRequired"Required", as defined in <xreftarget="RFC8126"/>.target="RFC8126" format="default"/>. </t> </section> <sectiontitle="PeerInfo data fields" anchor="peerinfo-data-fields"> <t> IANAanchor="peerinfo-data-fields" numbered="true" toc="default"> <name>PeerInfo Data Fields</name> <t>IANA is requested to create and maintain a newsub-registrysubregistry entitled "EAP-NOOB PeerInfodata fields"Data Fields" in the "Nimbleout-of-band authenticationOut-of-Band Authentication for EAPParameters"Parameters (EAP-NOOB)" registry. The initial values for this registryare: </t> <texttable title="PeerInfo data fields" anchor="peerinfo-data-fields-table"> <ttcol>Data Field</ttcol> <ttcol>Specification</ttcol> <c>Type</c><c>This RFC <xref target="serverinfo-peerinfo-meaning"/></c> <c></c><c></c> <c>PeerName</c><c>This RFC <xref target="serverinfo-peerinfo-meaning"/></c> <c></c><c></c> <c>Manufacturer</c><c>This RFC <xref target="serverinfo-peerinfo-meaning"/></c> <c></c><c></c> <c>Model</c><c>This RFC <xref target="serverinfo-peerinfo-meaning"/></c> <c></c><c></c> <c>SerialNumber</c><c>This RFC <xref target="serverinfo-peerinfo-meaning"/></c> <c></c><c></c> <c>MACAddress</c><c>This RFC <xref target="serverinfo-peerinfo-meaning"/></c> <c></c><c></c> <c>SSID</c><c>This RFC <xref target="serverinfo-peerinfo-meaning"/></c> <c></c><c></c> <c>Base64SSID</c><c>This RFC <xref target="serverinfo-peerinfo-meaning"/></c> <c></c><c></c> <c>BSSID</c><c>This RFC <xref target="serverinfo-peerinfo-meaning"/></c> <c></c><c></c> </texttable> <t> Assignmentare:</t> <table anchor="peerinfo-data-fields-table" align="center"> <name>PeerInfo Data Fields</name> <thead> <tr> <th align="left">Data Field</th> <th align="left">Specification</th> </tr> </thead> <tbody> <tr> <td align="left">Type</td> <td align="left">RFC 9140, <xref target="serverinfo-peerinfo-meaning" format="default"/></td> </tr> <tr> <td align="left">PeerName</td> <td align="left">RFC 9140, <xref target="serverinfo-peerinfo-meaning" format="default"/></td> </tr> <tr> <td align="left">Manufacturer</td> <td align="left">RFC 9140, <xref target="serverinfo-peerinfo-meaning" format="default"/></td> </tr> <tr> <td align="left">Model</td> <td align="left">RFC 9140, <xref target="serverinfo-peerinfo-meaning" format="default"/></td> </tr> <tr> <td align="left">SerialNumber</td> <td align="left">RFC 9140, <xref target="serverinfo-peerinfo-meaning" format="default"/></td> </tr> <tr> <td align="left">MACAddress</td> <td align="left">RFC 9140, <xref target="serverinfo-peerinfo-meaning" format="default"/></td> </tr> <tr> <td align="left">SSID</td> <td align="left">RFC 9140, <xref target="serverinfo-peerinfo-meaning" format="default"/></td> </tr> <tr> <td align="left">Base64SSID</td> <td align="left">RFC 9140, <xref target="serverinfo-peerinfo-meaning" format="default"/></td> </tr> <tr> <td align="left">BSSID</td> <td align="left">RFC 9140, <xref target="serverinfo-peerinfo-meaning" format="default"/></td> </tr> </tbody> </table> <t>Assignment of new values for new PeerInfo data fieldsMUST<bcp14>MUST</bcp14> be done through IANA with "SpecificationRequired"Required", as defined in <xreftarget="RFC8126"/>. </t>target="RFC8126" format="default"/>.</t> </section> <sectiontitle="Domain name reservation" anchor="specialdomainname"> <t> Theanchor="specialdomainname" numbered="true" toc="default"> <name>Domain Name Reservation</name> <t>The special-use domain "eap-noob.arpa"should behas been registered in the .arpa registry (<ereftarget="https://www.iana.org/domains/arpa"/>). No A, AAAA, or PTR records are requested. </t>target="https://www.iana.org/domains/arpa"/>) and the "Special-Use Domain Names" registry (<eref target="https://www.iana.org/assignments/special-use-domain-names"/>).</t> </section> <sectiontitle="Guidanceanchor="expertguidance" numbered="true" toc="default"> <name>Guidance for DesignatedExperts" anchor="expertguidance">Experts</name> <t>ExpertsSHOULD<bcp14>SHOULD</bcp14> be conservative in the allocation of new Cryptosuites. ExpertsMUST<bcp14>MUST</bcp14> ascertain that the requested values match the current Crypto Forum Research Group (CFRG) guidance on cryptographic algorithm security. ExpertsMUST<bcp14>MUST</bcp14> ensure that any new Cryptosuites fully specify the encoding of the ECDHE public key and should includedetailsdetails, such as the value of the "kty" (key type) parameter when JWK <xreftarget="RFC7517"/>target="RFC7517" format="default"/> encoding is used.</t> <t>ExpertsSHOULD<bcp14>SHOULD</bcp14> be conservative in the allocation of new Message Types. ExpertsSHOULD<bcp14>SHOULD</bcp14> ascertain that a well-defined specification for the new Message Type is permanently and publicly available.</t> <t>ExpertsSHOULD<bcp14>SHOULD</bcp14> be conservative in the allocation of new Errorcodescodes, since the 6001-6999 range is alreadyallocatedreserved for private and experimental use.</t> <t>ExpertsMAY<bcp14>MAY</bcp14> be liberal in the allocation of new ServerInfo and PeerInfo data fields. ExpertsMUST<bcp14>MUST</bcp14> ensure that theData Fielddata field requested has a unique name that is not easily confused with existing registrations. For example, requests for a new PeerInfo data field "ssid" should be rejected even though it is unique because it can be confused with the existing registration of "SSID". ExpertsMUST<bcp14>MUST</bcp14> ensure that a suitable Description for the data field is available.</t> </section> </section> <sectiontitle="Implementation Status" anchor="implementationstatus"> <t>Note to RFC Editor: Please remove this entire section and the reference to RFC7942 before publication.</t> <t> This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft and is based on a proposal described in <xref target="RFC7942"/>. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. </t> <section title="Implementation with wpa_supplicant and hostapd" anchor="aaltoimplementation"> <t> <list style="symbols"> <t>Responsible Organization: Aalto University</t> <t>Location: <eref target="https://github.com/tuomaura/eap-noob"/></t> <t>Coverage: This implementation includes all the features described in the current specification. The implementation supports two-dimensional QR codes and NFC as example out-of-band (OOB) channels.</t> <t>Level of Maturity: Alpha</t> <t>Version compatibility: Version 08 of the individual draft implemented</t> <t>Licensing: BSD</t> <t>Contact Information: Tuomas Aura, tuomas.aura@aalto.fi</t> </list> </t> </section> <section title="Implementation on Contiki" anchor="murciaimplementation_contiki"> <t> <list style="symbols"> <t>Responsible Organization: University of Murcia and Aalto University</t> <t>Location: <eref target="https://github.com/eduingles/coap-eap-noob"/></t> <t>Coverage: This implementation includes all the features described in the current specification. The implementation uses a blinking LED light as the out-of-band (OOB) channel.</t> <t>Level of Maturity: Alpha</t> <t>Version compatibility: Version 06 of the draft implemented</t> <t>Licensing: BSD</t> <t>Contact Information: Eduardo Ingles, eduardo.ingles@um.es</t> </list> </t> </section> <section title="Implementation with wpa_supplicant and hostapd" anchor="murciaimplementation_linux"> <t> <list style="symbols"> <t>Responsible Organization: Ericsson</t> <t>Location: <eref target="https://github.com/Vogeltak/hostap"/></t> <t>Coverage: This implementation is the most up-to-date one. The implementation only provides a minimal API interface for transferring OOB messages.</t> <t>Level of Maturity: Alpha</t> <t>Version compatibility: Version 02 of the working group adopted draft is implemented</t> <t>Licensing: BSD</t> </list> </t> </section> <section title="Protocol modeling " anchor="modeling"> <t> The current EAP-NOOB specification has been modeled with the mCRL2 formal specification language <xref target="mcrl2"/>. The model <xref target="noob-mcrl2"/> was used mainly for simulating the protocol behavior and for verifying basic safety and liveness properties as part of the specification process. For example, we verified the correctness of the tiebreaking mechanism when two OOB messages are received simultaneously, one in each direction. We also verified that an on-path attacker cannot cause persistent failure by spoofing a finite number of messages in the Reconnect Exchange. Additionally, the protocol has been modeled with the ProVerif <xref target="proverif"/> tool. This model <xref target="noob-proverif"/> was used to verify security properties such as mutual authentication. </t> </section> </section> <section title="Security considerations" anchor="securityconsiderations"> <t> EAP-NOOBanchor="securityconsiderations" numbered="true" toc="default"> <name>Security Considerations</name> <t>EAP-NOOB is an authentication and key derivationprotocol and,protocol; thus, security considerations can be found in most sections of this specification. In the following, we explain the protocol design and highlight some other specialconsiderations. </t>considerations.</t> <sectiontitle="Authentication principle" anchor="authenticationprinciple"> <t> EAP-NOOBanchor="authenticationprinciple" numbered="true" toc="default"> <name>Authentication Principle</name> <t>EAP-NOOB establishes a shared secret with an authenticated ECDHE key exchange. The mutual authentication in EAP-NOOB is based on two separate features, both conveyed in the OOB message. The first authentication feature is the secret nonce Noob. The peer and server use this secret in the Completion Exchange to mutually authenticate the session key previously created with ECDHE. The message authentication codes computed with the secret nonce Noob are alone sufficient for authenticating the key exchange. The second authentication feature is the integrity-protecting fingerprint Hoob. Its purpose is to prevent impersonation attacks even in situations where the attacker is able to eavesdrop on the OOB channel and the nonce Noob is compromised. In some human-assisted OOB channels, such as human-perceptible audio or a user-typed URL, it may be easier to detect tampering than disclosure of the OOB message, and such applications benefit from the second authenticationfeature. </t> <t> Thefeature.</t> <t>The additional security provided by the cryptographic fingerprint Hoob is somewhat intricate to understand. The endpoint that receives the OOB message uses Hoob to verify the integrity of the ECDHE exchange. Thus, the OOB receiver can detect impersonation attacks that may have happened on the in-band channel. The other endpoint, however, is not equally protected because the OOB message and fingerprint are sent only in one direction. Some protection to the OOB sender is afforded by the fact that the user may notice the failure of the association at the OOB receiver and therefore reset the OOB sender. Other device-pairing protocols have solved similar situations by requiring the user to confirm to the OOB sender that the association was accepted by the OOB receiver, e.g., with a button press on the sender side. ApplicationsMAY<bcp14>MAY</bcp14> implement EAP-NOOB in this way. Nevertheless, since EAP-NOOB was designed to work with strictly one-directional OOB communication and the fingerprint is only the second authentication feature, the EAP-NOOB specification does not mandate such explicit confirmation to the OOBsender. </t> <t> Tosender.</t> <t>To summarize, EAP-NOOB uses the combined protection of the secret nonce Noob and the cryptographic fingerprint Hoob, both conveyed in the OOB message. The secret nonce Noob alone is sufficient for mutual authentication unless the attacker can eavesdrop on it from the OOB channel. Even if an attacker is able to eavesdrop on the secret nonce Noob, it nevertheless cannot perform a full impersonation attack on the in-band channel because a mismatching fingerprint would alert the OOB receiver, which would reject the OOB message. The attacker that eavesdropped on the secret nonce can impersonate the OOB receiver to the OOB sender. If it does, the association will appear to be complete only on the OOB sender side, and such situations have to be resolved by the user by resetting the OOB sender to the initialstate. </t> <t> Thestate.</t> <t>The expected use cases for EAP-NOOB are ones where it replaces a user-entered access credential in IoT appliances. In wireless network access without EAP, the user-entered credential is often a passphrase that is shared by all the network stations. The advantage of an EAP-based solution, including EAP-NOOB, is that it establishes a different shared secret for each peer device, which makes the system more resilient against device compromise. Another advantage is that it is possible to revoke the security association for an individual device on the serverside. </t> <t> Forwardside.</t> <t>Forward secrecy during fast reconnect in EAP-NOOB is optional. The Reconnect Exchange in EAP-NOOB provides forward secrecy only if both the server and peer send their fresh ECDHE keys. This allows both the server andthepeer to limit the frequency of the costly computation that is required for forward secrecy. The serverMAY<bcp14>MAY</bcp14> adjust the frequency of its attempts at ECDHE rekeying based on what it knows about the peer's computationalcapabilities. </t> <t> Anothercapabilities.</t> <t>Another way in which some servers may control their computational load is to reuse the same ECDHE key for all peers over a short server-specific time window. In that case, forward secrecy will be achieved only after the server updates its ECDHE key, which may be a reasonable trade-off between security and performance. However, the serverMUST NOT<bcp14>MUST NOT</bcp14> reuse the same ECDHE key with the same peer when rekeying with ECDHE (KeyingMode=2 or KeyingMode=3). Instead, it can simply not send an ECDHE key(KeyingMode=1). </t> <t> The(KeyingMode=1).</t> <t>The users delivering the OOB messages will often authenticate themselves to the EAP server, e.g., by logging into a secure web page or API. In this case, the server can associate the peer device with the user account. Applications that make use of EAP-NOOB can use this information for configuring the initial owner of thefreshly-registered device. </t>freshly registered device.</t> </section> <sectiontitle="Identifying correct endpoints" anchor="deviceidentification"> <t> Potentialanchor="deviceidentification" numbered="true" toc="default"> <name>Identifying Correct Endpoints</name> <t>Potential weaknesses in EAP-NOOB arise from the fact that the user mustidentifyphysically identify the correct peer device. If the user mistakenly delivers the OOB message from the wrong peer device to the server, the server may create an association with the wrong peer. The reliance on the user in identifying the correct endpoints is an inherent property ofuser-assisteduser-assisted, out-of-band authentication. To understand the potential consequences of the user mistake, we need to consider a few different scenarios. In the first scenario, there is no malicious party, and the user makes an accidental mistake between two out-of-the-box devices that are both ready to be registered to a server. If the user delivers the OOB message from the wrong device to the server, confusion may arise but usually no security issues. In the second scenario, an attacker intentionally tricks the user, for example, by substituting the original peer device with a compromised one. This is essentially a supply chain attack where the user accepts a compromised physical device. </t><t> There<t>There is also a third scenario, in which an opportunistic attacker tries to take advantage of the user's accidental mistake. For example, the user could play an audio or a blinking LED message to a device that is not expecting to receive it. In simple security bootstrapping solutions that transfer amasterprimary key to the device via the OOB channel, the device could misuse or leak the accidentally receivedmasterprimary key. EAP-NOOB is not vulnerable to such opportunistic attackers because the OOB message has no value to anyone who did not take part in the corresponding InitialExchange. </t> <t> OneExchange.</t> <t>One mechanism that can mitigate user mistakes is certification of peer devices. A certificate or an attestation token(e.g.,<xref target="I-D.tschofenig-tls-cwt"/>(e.g., <xref target="I-D.tschofenig-tls-cwt" format="default"/> and <xreftarget="I-D.ietf-rats-eat"/>)target="I-D.ietf-rats-eat" format="default"/>) can convey to the server authentic identifiers and attributes, such as model and serial number, of the peer device. Compared to a fully certificate-based authentication, however, EAP-NOOB can be used without trusted third parties and does not require the user to know any identifier of the peer device; physical access to the device is sufficient for bootstrapping withEAP-NOOB. </t> <t> Similarly,EAP-NOOB.</t> <t>Similarly, the attacker can try to trick the user into delivering the OOB message to the wrongserver,server so that the peer device becomes associated with the wrong server. If the EAP server is accessed through a web user interface, the attack is akin to phishing attacks where the user is tricked into accessing the wrong URL and wrong web page. OOB implementation with a dedicated app on a mobile device, which communicates with a server API at apre-configuredpreconfigured URL, can protect against such attacks. </t><t> After<t>After the device registration, an attacker could clone the device identity by copying the keys from the persistent EAP-NOOB association 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 matching the same registration. The cloning threats can be mitigated by creating the cryptographic keys and storing the persistent EAP-NOOB association on the peer device in a secure hardware component such as a trusted execution environment (TEE). Furthermore, remote attestation on the application level could provide assurance to the server that the device has not been cloned. Reconnect Exchange with a new cryptosuite (KeyingMode=3) will also disconnect all but the first clone that performs theupdate. </t>update.</t> </section> <sectiontitle="Trusted path issues and misbinding attacks" anchor="trustedpath"> <t> Anotheranchor="trustedpath" numbered="true" toc="default"> <name>Trusted Path Issues and Misbinding Attacks</name> <t>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 correct peer device, a trusted path between the user and the peer device is needed. That is, the user must communicate directly with an authentic operating system and EAP-NOOB implementation in the peer device and not with a spoofed user interface. Otherwise, a registered device that is under the control of the attacker could emulate the behavior of an unregistered device. The secure path can be implemented, for example, by having the user press a reset button to return the device to the Unregistered (0) state and to invoke a trusted UI. The problem with such trusted paths is that they are not standardized acrossdevices. </t> <t> Anotherdevices.</t> <t>Another potential consequence of a spoofed UI is the misbinding attack where the user tries to register a correct but compromised device, which tricks the user into registering another (uncompromised) device instead. For example, the compromised device might have amaliciousmalicious, full-screen app running, which presents to the user QR codes copied, in real time, from another device's screen. If the unwitting user scans the QR code and delivers the OOB message in it to the server, the wrong device may become registered in the server. Such misbinding vulnerabilities arise because the user does not have any secure way of verifying that the in-band cryptographic handshake and the out-of-band physical access are terminated at the same physical device. Sethi et al. <xreftarget="Sethi19"/>target="Sethi19" format="default"/> analyze the misbinding threat against device-pairing protocols and also EAP-NOOB. Essentially, all protocols where the authentication relies on the user's physical access to the device are vulnerable to misbinding, includingEAP-NOOB. </t> <t> AEAP-NOOB.</t> <t>A standardized trusted path for communicating directly with the trusted computing base in a physical device would mitigate the misbinding threat, but such paths rarely exist in practice. Careful asset tracking on the server side can also prevent most misbinding attacks if the peer device sends its identifiers or attributes in the PeerInfo field and the server compares them with the expected values. The wrong but uncompromised device's PeerInfo will not match the expected values. Device certification by the manufacturer can further strengthen the assettracking. </t>tracking.</t> </section> <sectiontitle="Peer identifiersanchor="peeridentifiers" numbered="true" toc="default"> <name>Peer Identifiers andattributes" anchor="peeridentifiers"> <t> TheAttributes</name> <t>The PeerId value in the protocol is a server-allocated identifier for its association with the peer andSHOULD NOT<bcp14>SHOULD NOT</bcp14> be shown to the user because its value is initially ephemeral. Since the PeerId is allocated by the server and the scope of the identifier is the single server, the so-called identifier squatting attacks, where a malicious peer could reserve another peer's identifier, are not possible in EAP-NOOB. The serverSHOULD<bcp14>SHOULD</bcp14> assign a random orpseudo-randompseudorandom PeerId to each new peer. ItSHOULD NOT<bcp14>SHOULD NOT</bcp14> select the PeerId based on any peer characteristics that it may know, such as the peer's link-layer networkaddress. </t> <t> Useraddress.</t> <t>User reset or failure in the OOB Step can cause the peer to perform many Initial Exchanges with the server, which allocates many PeerId values and stores the ephemeral protocol state for them. The peer will typically only remember the latest ones. EAP-NOOB leaves it to the implementation to decide when to delete these ephemeral associations. There is no security reason to delete them early, and the server does not have any way to verify that the peers are actually the same one. Thus, it is safest to store the ephemeral states on the server for at least one day. If the OOB messages are sent only in the server-to-peer direction, the serverSHOULD NOT<bcp14>SHOULD NOT</bcp14> delete the ephemeral state before all the related Noob values haveexpired. </t> <t> Afterexpired.</t> <t>After completion of EAP-NOOB, the server may store the PeerInfo data, and the user may use it to identify the peer and its attributes, such as the make and model or serial number. A compromised peer could lie in the PeerInfowhichthat it sends to the server. If the server stores any information about the peer, it is important that this information is approved by the user during or after the OOB Step. Without verification by the user or authentication on the application level, the PeerInfo is not authenticated information and should not be relied on. One possible use for the PeerInfo field is EAP channel binding (see <xreftarget="channel-binding"/>). </t>target="channel-binding" format="default"/>).</t> </section> <sectiontitle="Downgrading threats" anchor="downgrading"> <t> Theanchor="downgrading" numbered="true" toc="default"> <name>Downgrading Threats</name> <t>The fingerprint Hoob protects all the information exchanged in the Initial Exchange, including the cryptosuite negotiation. The message authentication codes MACs and MACp also protect the same information. The message authentication codes MACs2 and MACp2 protect information exchanged during key renegotiation in the Reconnect Exchange. This prevents downgrading attacks to weakercryptosuitescryptosuites, as long as the possible attacks take more time than the maximum time allowed for the EAP-NOOB completion. This is typically the case for recently discovered cryptanalyticattacks. </t> <t> Asattacks.</t> <t>As an additional precaution, the EAP server and peerMUST<bcp14>MUST</bcp14> check for downgrading attacks in the Reconnect Exchange as follows. As long as the server or peer saves any information about the other endpoint, itMUST<bcp14>MUST</bcp14> also remember the previously negotiated cryptosuite andMUST NOT<bcp14>MUST NOT</bcp14> accept renegotiation of any cryptosuite that is known to be weaker than the previous one, such as a deprecated cryptosuite. Determining the relative strength of the cryptosuites is out of scope of this specification and may be managed by implementations or by local policies at the peer andserver. </t> <t> Integrityserver.</t> <t>Integrity of the direction negotiation cannot be verified in the same way as the integrity of the cryptosuite negotiation. That is, if the OOB channel used in an application is critically insecure in one direction, an on-path attacker could modify the negotiation messages and thereby cause that direction to be used. Applications that support OOB messages in both directionsSHOULD therefore<bcp14>SHOULD</bcp14>, therefore, ensure that the OOB channel has sufficiently strong security in both directions. While this is a theoretical vulnerability, it could arise in practice if EAP-NOOB is deployed in new applications. Currently, we expect most peer devices to support only one OOBdirection,direction; in whichcasecase, interfering with the direction negotiation can only prevent the completion of theprotocol. </t> <t> Theprotocol.</t> <t>The long-term shared key material Kz in the persistent EAP-NOOB association is established with an ECDHE key exchange when the peer and server are first associated. It is a weaker secret than a manually configured random shared key because advances in cryptanalysis against the used ECDHE curve could eventually enable the attacker to recover Kz. EAP-NOOB protects against such attacks by allowing cryptosuite upgrades in the Reconnect Exchange and by updating the shared key material Kz whenever the cryptosuite is upgraded. We do not expect the cryptosuite upgrades to be frequent,butbut, if an upgrade becomes necessary, it can be done without manual reset and reassociation of the peerdevices. </t>devices.</t> </section> <sectiontitle="Protected successanchor="indicators" numbered="true" toc="default"> <name>Protected Success andfailure indications" anchor="indicators"> <t> Section 7.16 of <xref target="RFC3748"/>Failure Indications</name> <t><xref target="RFC3748" sectionFormat="of" section="7.16"/> allows EAP methods to specify protected result indications because EAP-Success and EAP-Failure packets are neither acknowledged nor integrity protected. <xreftarget="RFC3748"/>target="RFC3748" format="default"/> notes that these indications may be explicit orimplicit. </t> <t> EAP-NOOBimplicit.</t> <t>EAP-NOOB relies onimplicitimplicit, protected success indicators in the Completion Exchange and Reconnectexchange.Exchange. Successful verification of MACs and MACs2 in the EAP-Request message from the server (message type 6 and message type 9, respectively) acts as animplicitimplicit, protected success indication to the peer. Similarly, successful verification of MACp and MACp2 in the EAP-Response message from the peer (message type 6 and message type 9, respectively) act as animplicitimplicit, protected success indication to the server. </t><t> EAP-NOOB<t>EAP-NOOB failure messages are not protected. Protected failure result indications would not significantly improve availability since EAP-NOOB reacts to most malformed data by ending the current EAP conversation in EAP-Failure. However, since EAP-NOOB spans multiple conversations, failure in one conversation usually means no state change on the level of the EAP-NOOB statemachine. </t>machine.</t> </section> <sectiontitle="Channel Binding" anchor="channel-binding"> <t> EAPanchor="channel-binding" numbered="true" toc="default"> <name>Channel Binding</name> <t>EAP channel binding, defined in <xreftarget="RFC6677"/>,target="RFC6677" format="default"/>, means that the endpoints compare their perceptions of network properties, such as lower-layer identifiers, over the secure channel established by EAP authentication.Section 4.1 of<xreftarget="RFC6677"/>target="RFC6677" sectionFormat="of" section="4.1"/> defines two approaches to channel binding. EAP-NOOB follows the first approach, in which the peer and server exchange plaintext information about the network over a channel that is integrity protected with keys derived during the EAP execution. More specifically, channel information is exchanged in the plaintext PeerInfo and ServerInfo objects and is later verified with message authentication codes (MACp, MACs, MACp2, and MACs2). This allows policy-based comparison with locally perceived network properties on either side, as well as logging for debugging purposes. The peerMAY<bcp14>MAY</bcp14> include in PeerInfo 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 or the access link, such as the SSID and BSSID of the wireless network (see <xreftarget="table-serverinfo-meaning"/>).target="tab-serverinfo-meaning" format="default"/>). As noted inSection 4.3 of<xreftarget="RFC6677"/>,target="RFC6677" sectionFormat="of" section="4.3"/>, the scope of the channel binding varies between deployments. For example, the server may have less link-layer information available from roaming networks than from a local enterprise network, and it may be unable to verify all the network properties received in PeerInfo. There are also privacy considerations related to exchanging the ServerInfo and PeerInfo while roaming (see <xreftarget="privacyconsiderations"/>).target="privacyconsiderations" format="default"/>). </t><t> Channel<t>Channel binding to secure channels, defined in <xreftarget="RFC5056"/>,target="RFC5056" format="default"/>, binds authentication at a higher protocol layer to a secure channel at a lower layer. Like most EAP methods, EAP-NOOB exports the session keys MSK and EMSK, and an outer tunnel or a higher-layer protocol can bind its authentication to these keys. Additionally, EAP-NOOB exports the key AMSK, which may be used to bind application-layer authentication to the secure channel created by EAP-NOOB and to the session keys MSK andEMSK. </t>EMSK.</t> </section> <sectiontitle="Denialanchor="dos" numbered="true" toc="default"> <name>Denial ofService" anchor="dos"> <t> WhileService</name> <t>While denial-of-service (DoS) attacks by on-link attackers cannot be fully prevented, the design goal in EAP-NOOB is to void long-lasting failure caused by an attacker who is present only temporarily or intermittently. The main defense mechanism is the persistent EAP-NOOB association, which is never deleted automatically due to in-band messages or error indications. Thus, the endpoints can always use the persistent association for reconnecting after the DoS attacker leaves the network. In this sense, the persistent association serves the same function in EAP-NOOB as a permanentmasterprimary key or certificate in other authentication protocols. We discuss logical attacks against the updates of the persistent association in <xreftarget="completion-loss"/>.target="completion-loss" format="default"/>. </t><t> In<t>In addition to logical DoS attacks, it is necessary to consider resource exhaustion attacks against the EAP server. The number of persistent EAP-NOOB associations created in the server is limited by the need for a user to assist in delivering the OOB message. The users can be authenticated for the input or output of the OOB message at the EAP server, and any users who create excessive numbers of persistent associations can be held accountable and their associations can be deleted by the server administrator. What the attacker can do without user authentication is to perform the Initial Exchange repeatedly and create a large number of ephemeral associations (server instate 1,Waiting forOOB)OOB (1) state) without ever delivering the OOB message.Above inIn <xreftarget="peeridentifiers"/>,target="peeridentifiers" format="default"/>, it was suggested that the server should store the ephemeral states for at least a day. This may require off-loading the state storage from memory to disk during a DoS attack. However, if the server implementation is unable to keep up with a rate of Initial Exchanges performed by a DoS attacker and needs to drop some ephemeral states, no damage is caused toalready createdalready-created persistent associations, and the honest users can resume registering new peers when the DoS attacker leaves thenetwork. </t> <t> Therenetwork.</t> <t>There are some trade-offs in the protocol design betweenpolite back-offpolitely backing off and giving way to DoS attackers. An on-link DoS attacker could spoof the SleepTime value in the Initial Exchange or Waiting Exchange to cause denial of service against a specific peer device. There is an upper limit on the SleepTime (3600 seconds) to mitigate the spoofing threat. This means that, in the presence of an on-link DoS attacker who spoofs the SleepTime, it could take up to one hour after the delivery of the OOB message before the device performs the Completion Exchange and becomes functional. Similarly, the Unwanted peer error (error code 2001) could cause the peer to stop connecting to the network. If the peer device is able to alert the user about the error condition, it can safely stop connecting to the server and wait for the user to trigger a reconnection attempt, e.g., by resetting the device. As mentioned in <xreftarget="unwantedpeer"/>,target="unwantedpeer" format="default"/>, peer devices that are unable to alert the user should continue to retry the Initial Exchange infrequently to avoid a permanent DoS condition. We believe a maximum backoff time of 3600 seconds is reasonable for a new protocol because malfunctioning or misconfigured peer implementations are at least as great a concern as DoS attacks, and politely backing off within some reasonable limits will increase the acceptance of the protocol. The maximum backoff times could be updated to be shorter as the protocol implementationsmature. </t>mature.</t> </section> <sectiontitle="Recovery from loss of last message" anchor="completion-loss"> <t> Theanchor="completion-loss" numbered="true" toc="default"> <name>Recovery from Loss of Last Message</name> <t>The EAP-NOOB Completion Exchange, as well as the Reconnect Exchange with cryptosuite update,resultresults in a persistent state change that should take place either on both endpoints or on neither; otherwise, the result is a state mismatch that requires user action to resolve. The state mismatch can occur if the final EAP response of the exchanges is lost. In the Completion Exchange, the loss of the final response (Type=6) results in the peer moving to the Registered (4) state and creating a persistent EAP-NOOB association while the server stays in an ephemeral state (1 or 2). In the Reconnect Exchange, the loss of the final response (Type=9) results in the peer moving to the Registered (4) state and updating its persistent key material Kz while the server stays in the Reconnecting (3) state and keeps the old keymaterial. </t> <t> Thematerial.</t> <t>The state mismatch is an example of an unavoidable problem in distributed systems: it is theoretically impossible to guarantee synchronous state changes in endpoints that communicate asynchronously. The protocol will always have one critical message that may get lost, so that one side commits to the state change and the other side does not. In EAP, the critical message is the final response from the peer to the server. While the final response is normally followed by EAP-Success, <xreftarget="RFC3748"/> section 4.2target="RFC3748" sectionFormat="comma" section="4.2"/> states that the peerMAY<bcp14>MAY</bcp14> assume that the EAP-Success was lost and the authentication was successful. Furthermore, EAP method implementations in the peer do not receive notification of the EAP-Success message from the parent EAP state machine <xreftarget="RFC4137"/>.target="RFC4137" format="default"/>. For these reasons, EAP-NOOB on the peer side commits to a state change already when it sends the finalresponse. </t> <t> Theresponse.</t> <t>The best available solution to the loss of the critical message is to keep trying. EAP retransmission behavior defined inSection 4.3 of<xreftarget="RFC3748"/>target="RFC3748" sectionFormat="of" section="4.3"/> suggests 3-5 retransmissions. In the absence of an attacker, this would be sufficient to reduce the probability of failure to an acceptable level. However, a determined attacker on the in-band channel can drop the final EAP-Response message and all subsequent retransmissions. In the Completion Exchange (KeyingMode=0) andin theReconnect Exchange with cryptosuite upgrade (KeyingMode=3), this could result in a state mismatch and persistent denial of service until the user resets the peerstate. </t> <t> EAP-NOOBstate.</t> <t>EAP-NOOB implements its own recovery mechanism that allows unlimited retries of the Reconnect Exchange. When the DoS attacker eventually stops dropping packets on the in-band channel, the protocol will recover. The logic for this recovery mechanism is specified in <xreftarget="reconnectexchange"/>. </t> <t> EAP-NOOBtarget="reconnectexchange" format="default"/>.</t> <t>EAP-NOOB does not implement the same kind of retry mechanism in the Completion Exchange. The reason is that there is always a user involved in the initial association process, and the user can repeat the OOB Step to complete the association after the DoS attacker has left. On the other hand, Reconnect Exchange needs to work without userinvolvement. </t>involvement.</t> </section> <sectiontitle="Privacy considerations" anchor="privacyconsiderations"> <t> Thereanchor="privacyconsiderations" numbered="true" toc="default"> <name>Privacy Considerations</name> <t>There are privacy considerations related to performing the Reconnect Exchange while roaming. The peer and server may send updated PeerInfo and ServerInfo fields in the Reconnect Exchange. This data is sent unencrypted between the peer and the EAP authenticator, such as a wireless access point. Thus, it can be observed by both outsiders and the access network. The PeerInfo field contains identifiers and other information about the peer device (see <xreftarget="table-serverinfo-meaning" />).target="tab-serverinfo-meaning" format="default"/>). While the information refers to the peer device and not directly to the user, it can leak information about the user to the access network and to outside observers. The ServerInfo, on the other hand, can leak information about the peer's affiliation with the home network. For this reason, the optional PeerInfo and ServerInfo in the Reconnect ExchangeSHOULD<bcp14>SHOULD</bcp14> be omitted unless some critical data has changed and it cannot be updated on the applicationlayer. </t> <t> Peerlayer.</t> <t>Peer devices that randomize theirlayer-2Layer 2 address to prevent tracking can do this whenever the user resets the EAP-NOOB association. During the lifetime of the association, the PeerId is a unique identifier that can be used to track the peer in the access network. Later versions of this specification may consider updating the PeerId at each Reconnect Exchange. In that case, it is necessary to consider how the authenticator and access-network administrators can recognize and add misbehaving peer devices to a deny list, as wellas,as how to avoid loss of synchronization between the server and the peer if messages are lost during the identifierupdate. </t> <t> Toupdate.</t> <t>To enable stronger identity protection in later versions of EAP-NOOB, the optional server-assigned NAI (NewNAI)SHOULD<bcp14>SHOULD</bcp14> have a constant username part. TheRECOMMENDED<bcp14>RECOMMENDED</bcp14> username is "noob". The serverMAY,<bcp14>MAY</bcp14>, however, send a different username in NewNAI to avoid username collisions within its realm or to conform to a local policy on usernames. </t> </section> <sectiontitle="EAP security claims" anchor="securityclaims"> <t> EAPanchor="securityclaims" numbered="true" toc="default"> <name>EAP Security Claims</name> <t>EAP security claims are defined insection 7.2.1 of<xreftarget="RFC3748"/>.target="RFC3748" sectionFormat="of" section="7.2.1"/>. The security claims for EAP-NOOB are listed in <xreftarget="table-securityclaims"/>. </t> <texttable title="EAP security claims" anchor="table-securityclaims"> <ttcol>Security property</ttcol> <ttcol>EAP-NOOB claim</ttcol> <c>Authentication mechanism</c> <c>ECDHEtarget="tab-securityclaims" format="default"/>.</t> <table anchor="tab-securityclaims" align="center"> <name>EAP Security Claims</name> <thead> <tr> <th align="left">Security Property</th> <th align="left">EAP-NOOB Claim</th> </tr> </thead> <tbody> <tr> <td align="left">Authentication mechanism</td> <td align="left">ECDHE key exchange with out-of-bandauthentication</c> <c></c><c></c> <c>Protectedauthentication</td> </tr> <tr> <td align="left">Protected cryptosuitenegotiation</c> <c>yes</c> <c></c><c></c> <c>Mutual authentication</c> <c>yes</c> <c></c><c></c> <c>Integrity protection</c> <c>yes</c> <c></c><c></c> <c>Replay protection</c> <c>yes</c> <c></c><c></c> <c>Confidentiality</c> <c>no</c> <c></c><c></c> <c>Key derivation</c> <c>yes</c> <c></c><c></c> <c>Key strength</c> <c>Thenegotiation</td> <td align="left">yes</td> </tr> <tr> <td align="left">Mutual authentication</td> <td align="left">yes</td> </tr> <tr> <td align="left">Integrity protection</td> <td align="left">yes</td> </tr> <tr> <td align="left">Replay protection</td> <td align="left">yes</td> </tr> <tr> <td align="left">Confidentiality</td> <td align="left">no</td> </tr> <tr> <td align="left">Key derivation</td> <td align="left">yes</td> </tr> <tr> <td align="left">Key strength</td> <td align="left">The specified cryptosuites provide key strength of at least 128bits.</c> <c></c><c></c> <c>Dictionarybits.</td> </tr> <tr> <td align="left">Dictionary attackprotection</c> <c>yes</c> <c></c><c></c> <c>Fast reconnect</c> <c>yes</c> <c></c><c></c> <c>Cryptographic binding</c> <c>not applicable</c> <c></c><c></c> <c>Session independence</c> <c>yes</c> <c></c><c></c> <c>Fragmentation</c> <c>no</c> <c></c><c></c> <c>Channel binding</c> <c>yesprotection</td> <td align="left">yes</td> </tr> <tr> <td align="left">Fast reconnect</td> <td align="left">yes</td> </tr> <tr> <td align="left">Cryptographic binding</td> <td align="left">not applicable</td> </tr> <tr> <td align="left">Session independence</td> <td align="left">yes</td> </tr> <tr> <td align="left">Fragmentation</td> <td align="left">no</td> </tr> <tr> <td align="left">Channel binding</td> <td align="left">yes (The ServerInfo and PeerInfo can be used to convey integrity-protected channelpropertiesproperties, such as network SSID or peer MACaddress.)</c> </texttable>address.)</td> </tr> </tbody> </table> </section> </section> </middle> <back><references title="Normative references"> <?rfc include='reference.RFC.2104.xml'?> <!-- HMAC --> <?rfc include='reference.RFC.2119.xml'?> <!-- Terminology --> <?rfc include='reference.RFC.3748.xml'?> <!-- EAP --> <?rfc include='reference.RFC.4648.xml'?> <!-- Base64 --> <?rfc include='reference.RFC.5247.xml'?> <!-- EAP key management --> <?rfc include='reference.RFC.6234.xml'?> <!-- SHA-256 --> <?rfc include='reference.RFC.7517.xml'?> <!-- JWK --> <?rfc include='reference.RFC.7518.xml'?> <!-- JWA --> <?rfc include='reference.RFC.7542.xml'?> <!-- NAI --> <?rfc include='reference.RFC.7748.xml'?> <!-- Curve25519 --> <?rfc include='reference.RFC.8037.xml'?> <!-- JWK for curve25519 --> <?rfc include='reference.RFC.8174.xml'?> <!-- Terminology --> <?rfc include='reference.RFC.8126.xml'?> <!-- IANA --> <?rfc include='reference.RFC.8259.xml'?> <!-- JSON --><displayreference target="I-D.tschofenig-tls-cwt" to="TLS-CWT"/> <displayreference target="I-D.ietf-rats-eat" to="RATS-EAT"/> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2104.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3748.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5247.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6234.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7517.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7518.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7542.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7748.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8037.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8259.xml"/> <reference anchor="NIST-DH" target="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pdf"> <front> <title>Recommendation for Pair-WiseKey EstablishmentKey-Establishment Schemes Using Discrete Logarithm Cryptography</title> <author initials="E." surname="Barker" fullname="Elaine Barker"> <organization>National Institute of Standards and Technology</organization> </author> <author initials="L." surname="Chen" fullname="Lily Chen"> <organization>National Institute of Standards and Technology</organization> </author> <author initials="A." surname="Roginsky" fullname="Allen Roginsky"> <organization>National Institute of Standards and Technology</organization> </author> <author initials="A." surname="Vassilev" fullname="Apostol Vassilev"> <organization>National Institute of Standards and Technology</organization> </author> <author initials="R." surname="Davis" fullname="Richard Davis"> <organization>National Security Agency</organization> </author> <date month="April"year="2018" />year="2018"/> </front> <seriesInfo name="DOI" value="10.6028/NIST.SP.800-56Ar3"/> <seriesInfo name="NIST SpecialPublication 800-56APublication" value="800-56A Revision3" value="" />3"/> </reference> <referenceanchor='FIPS186-4'>anchor="FIPS186-4"> <front> <title>Digital Signature Standard (DSS)</title> <author> <organization>National Institute of Standards andTechnology</organization>Technology (NIST)</organization> </author> <datemonth='July' year='2013'/>month="July" year="2013"/> </front> <seriesInfoname='FIPS 186-4' value=''/>name="DOI" value="10.6028/NIST.FIPS.186-4"/> <seriesInfo name="FIPS" value="186-4"/> </reference> <reference anchor="EUI-48"> <front><title>802-2014 IEEE<title>IEEE Standard for Local and Metropolitan Area Networks: Overview andArchitecture.</title>Architecture</title> <author><organization>Institute of Electrical and Electronics Engineers</organization><organization>IEEE</organization> </author> <date month="June"year="2014" />year="2014"/> </front> <seriesInfoname=" IEEE Standard 802-2014." value="" />name="DOI" value="10.1109/IEEESTD.2014.6847097"/> <seriesInfo name="IEEE Standard" value="802-2014"/> </reference> </references><references title="Informative references"> <?rfc include='reference.RFC.2904.xml'?> <!-- AAA authorization --> <?rfc include='reference.RFC.4137.xml'?> <!-- EAP State Machine --> <?rfc include='reference.RFC.3986.xml'?> <!-- URL --> <?rfc include='reference.RFC.5056.xml'?> <!-- Secure channel binding --> <?rfc include='reference.RFC.6677.xml'?> <!-- EAP channel binding --> <?rfc include='reference.I-D.tschofenig-tls-cwt'?> <!-- CWT as certificates --> <?rfc include='reference.I-D.ietf-rats-eat'?> <!-- Entity attestation token --><references> <name>Informative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2904.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4137.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5056.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6677.xml"/> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.tschofenig-tls-cwt.xml"/> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-rats-eat.xml"/> <reference anchor="IEEE-802.1X"> <front><title>Local<title>IEEE Standard for Local and Metropolitan AreaNetworks: Port-BasedNetworks--Port-Based Network Access Control</title> <author><organization>Institute of Electrical and Electronics Engineers</organization><organization>IEEE</organization> </author> <datemonth="December" year="2004" />month="February" year="2020"/> </front> <seriesInfoname=" IEEE Standard 802.1X-2004." value="" />name="IEEE Standard" value="802.1X-2020"/> </reference> <reference anchor="Sethi14" target="http://dx.doi.org/10.1145/2632048.2632049"> <front> <title>SecureBootstrappingbootstrapping ofCloud-Managed Ubiquitous Displays</title>cloud-managed ubiquitous displays</title> <author initials="M." surname="Sethi" fullname="Mohit Sethi"> <organization>Ericsson</organization> </author> <author initials="E." surname="Oat" fullname="Elena Oat"> <organization>Aalto University</organization> </author> <author initials="M." surname="Di Francesco" fullname="Mario Di Francesco"> <organization>Aalto University</organization> </author> <author initials="T." surname="Aura" fullname="Tuomas Aura"> <organization>Aalto University</organization> </author> <date month="September"year="2014" />year="2014"/> </front> <seriesInfoname="Proceedingsname="DOI" value="10.1145/2632048.2632049"/> <refcontent>Proceedings of ACM International Joint Conference on Pervasive and Ubiquitous Computing (UbiComp 2014), pp. 739-750, Seattle,USA" value="" />USA</refcontent> </reference> <referenceanchor="BluetoothPairing">anchor="Bluetooth" target="https://www.bluetooth.com/specifications/bluetooth-core-specification"> <front><title>Simple pairing whitepaper</title><title>Bluetooth Core Specification Version 5.3</title> <author><organization>Bluetooth, SIG</organization> </author> <date year="2007" /> </front> <seriesInfo name=" Technical report" value="" /> </reference> <reference anchor="mcrl2" target="https://mitpress.mit.edu/books/modeling-and-analysis-communicating-systems"> <front> <title>Modeling and analysis of communicating systems</title> <author initials="J.F." surname="Groote" fullname="Jan Friso Groote"> <organization>Eindhoven University of Technology</organization> </author> <author initials="M.R." surname="Mousavi" fullname="Mohammad Reza Mousavi"> <organization>Halmstad University</organization> </author> <date year="2014" /> </front> <seriesInfo name="The MIT press" value="" /> </reference> <reference anchor="noob-mcrl2" target="https://github.com/tuomaura/eap-noob/tree/master/protocolmodel/mcrl2"> <front> <title>mCRL2 model of EAP-NOOB</title> <author initials="A." surname="Peltonen" fullname="Aleksi Peltonen"> </author> <date year="2021" /> </front> </reference> <reference anchor="noob-proverif" target="https://github.com/tuomaura/eap-noob/tree/master/protocolmodel/proverif "> <front> <title>ProVerif model of EAP-NOOB</title> <author initials="A." surname="Peltonen" fullname="Aleksi Peltonen"><organization>Bluetooth Special Interest Group</organization> </author> <date year="2021"/>month="July"/> </front> </reference><reference anchor="proverif" target="http://prosecco.gforge.inria.fr/personal/bblanche/proverif/"> <front> <title>ProVerif 2.00: Automatic Cryptographic Protocol Verifier, User Manual and Tutorial</title> <author initials="B." surname="Blanchet" fullname="Bruno Blanchet"> </author> <author initials="B." surname="Smyth" fullname="Ben Smyth"> </author> <author initials="V." surname="Cheval" fullname="Vincent Cheval"> </author> <author initials="M." surname="Sylvestre" fullname="Marc Sylvestre"> </author> <date year="2018" /> </front> <seriesInfo name="The MIT press" value="" /> </reference> <?rfc include='reference.RFC.5216.xml'?> <!-- EAP-TLS --> <?rfc include='reference.RFC.7942.xml'?> <!-- Implementation Status --><xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5216.xml"/> <reference anchor="Sethi19" target="https://arxiv.org/abs/1902.07550"> <front> <title>Misbinding Attacks on Secure DevicePairing</title>Pairing and Bootstrapping</title> <author initials="M." surname="Sethi" fullname="Mohit Sethi"> </author> <author initials="A." surname="Peltonen" fullname="Aleksi Peltonen"> </author> <author initials="T." surname="Aura"fullname="Tuomas">fullname="Tuomas Aura"> </author> <date year="2019"/>month="February"/> </front> <seriesInfo name="DOI" value="10.1145/3321705.3329813"/> </reference> </references> </references> <sectiontitle="Exchangesanchor="exchangeappendix" numbered="true" toc="default"> <name>Exchanges andeventsEvents perstate" anchor="exchangeappendix"> <t> <xref target="table-exchanges"/>State</name> <t><xref target="tab-exchanges" format="default"/> shows how the EAP server chooses the exchange type depending on the server and peer states. In the state combinations marked with hyphen "-", there is no possible exchange and user action is required to make progress. Note that peer state 4 is omitted from the table because the peer never connects to the server when the peer is in that state. The table also shows the handling of errors in each exchange. A notable detail is that the recipient of error code 2003 moves to state1. </t> <t> <figure title="How server chooses1.</t> <table anchor="tab-exchanges"> <name>How theexchange type" anchor="table-exchanges"> <artwork align="center"> <![CDATA[ +--------+---------------------------+------------------------------+ | peer | exchange chosenServer Chooses the Exchange Type</name> <thead> <tr> <th>Peer States</th> <th>Exchange Chosen by| next peerthe Server</th> <th>Next Peer and| | states | server | server states | +========+===========================+==============================+ | server state:Server States</th> </tr> </thead> <tbody> <tr> <td colspan="3" align="center">Server State: Unregistered(0) | +--------+---------------------------+------------------------------+ | 0..2 | Initial Exchange | both(0)</td> </tr> <tr> <td>0..2</td> <td>Initial Exchange</td> <td>both 1 (0 onerror) | | 3 | - | noerror)</td> </tr> <tr> <td>3</td> <td>-</td> <td>no change, notifyuser | +--------+---------------------------+------------------------------+ | server state:user</td></tr> <tr> <td colspan="3" align="center">Server State: Waiting for OOB(1) | +--------+---------------------------+------------------------------+ | 0 | Initial Exchange | both(1)</td> </tr> <tr> <td>0</td> <td>Initial Exchange</td> <td>both 1 (0 onerror) | | 1 | Waiting Exchange | botherror)</td> </tr> <tr> <td>1</td> <td>Waiting Exchange</td> <td>both 1 (no change onerror) | | 2 | Completion Exchange | botherror)</td> </tr> <tr> <td>2</td> <td>Completion Exchange</td> <td>both 4(A) | | 3 | - | no(A)</td> </tr> <tr> <td>3</td> <td>-</td> <td>no change, notifyuser | +--------+---------------------------+------------------------------+ | server state:user</td> </tr> <tr> <td colspan="3" align="center">Server State: OOB Received(2) | +--------+---------------------------+------------------------------+ | 0 | Initial Exchange | both(2)</td> </tr> <tr> <td>0</td> <td>Initial Exchange</td> <td>both 1 (0 onerror) | | 1 | Completion Exchange | botherror)</td> </tr> <tr> <td>1</td> <td>Completion Exchange</td> <td>both 4(B) | | 2 | Completion Exchange | both(B)</td> </tr> <tr> <td>2</td> <td>Completion Exchange</td> <td>both 4(A) | | 3 | - | no(A)</td> </tr> <tr> <td>3</td> <td>-</td> <td>no change, notifyuser | +--------+---------------------------+------------------------------+ | server state:user</td> </tr> <tr> <td colspan="3" align="center">Server State: Reconnecting (3) or Registered(4) | +--------+---------------------------+------------------------------+ | 0..2 | - | no(4)</td> </tr> <tr> <td>0..2</td> <td>-</td> <td>no change, notifyuser | | 3 | Reconnect Exchange | bothuser</td> </tr> <tr> <td>3</td> <td>Reconnect Exchange</td> <td>both 4 (3 onerror) | +--------+---------------------------+------------------------------+ (A) peererror)</td></tr> </tbody> </table> <dl> <dt>(A)</dt> <dd>peer to 1 on error2003,2003; no other changes onerror (B) servererror</dd> <dt>(B)</dt> <dd>server to 1 on error2003,2003; no other changes onerror ]]> </artwork> </figure> </t> <t> <xref target="table-localevents"/>error</dd> </dl> <t><xref target="tab-localevents" format="default"/> lists the local events that can take place in the server or peer. Both the server and peer output and accept OOB messages in association state 1, leading the receiver to state 2. Communication errors and timeouts in states 0..2 lead back to state 0, while similar errors in states 3..4 lead to state 3.ApplicationAn application request for rekeying (e.g., to refresh session keys or to upgrade cryptosuite) also takes the association from state 3..4 to state 3.UserThe user can always reset the association state to 0. Recovering association data, e.g., from a backup, leads to state3. </t> <t> <figure anchor="table-localevents" title="Local events on server3.</t> <table anchor="tab-localevents"> <name>Local Events in the Server andpeer"> <artwork align="center"> <![CDATA[ +--------+----------------------------------+--------------------+ | server/| possible local events | next state | | peer | on serverPeer</name> <thead> <tr> <th>Server/Peer State</th> <th>Possible Local Events in the Server andpeer | | | state | | | +========+==================================+====================+ | 1 | OOB Output | 1 | | 1 | OOB Input | 2Peer</th> <th>Next State</th> </tr> </thead> <tbody> <tr> <td>1</td> <td>OOB Output</td> <td>1</td> </tr> <tr> <td>1</td> <td>OOB Input</td> <td>2 (1 onerror) | | 0..2 | Mobility/timeout/network failure | 0 | | 3..4 | Mobility/timeout/network failure | 3 | | 3..4 | Rekeying request | 3 | | 0..4 | Usererror)</td> </tr> <tr> <td>0..2</td> <td>Mobility/timeout/network failure</td> <td>0</td> </tr> <tr> <td>3..4</td> <td>Mobility/timeout/network failure</td> <td>3</td> </tr> <tr> <td>3..4</td> <td>Rekeying request</td> <td>3</td> </tr> <tr> <td>0..4</td> <td>User resetsassociation | 0 | | 0..4 | Association state recovery | 3 | +--------+----------------------------------+--------------------+ ]]> </artwork> </figure> </t>association</td> <td>0</td> </tr> <tr> <td>0..4</td> <td>Association state recovery</td> <td>3</td> </tr> </tbody> </table> </section> <sectiontitle="Application-specific parameters" anchor="oobchannelappendix"> <t> <xref target="table-oobchannel"/>anchor="oobchannelappendix" numbered="true" toc="default"> <name>Application-Specific Parameters</name> <t><xref target="tab-oobchannel" format="default"/> lists OOB channel parameters that need to be specified in each application that makes use of EAP-NOOB. The list is not exhaustive and is included for the convenience of implementersonly. </t> <texttable title="OOB channel characteristics" anchor="table-oobchannel"> <ttcol>Parameter</ttcol> <ttcol>Description</ttcol> <c>OobDirs</c><c>Allowedonly.</t> <table anchor="tab-oobchannel" align="center"> <name>OOB Channel Characteristics</name> <thead> <tr> <th align="left">Parameter</th> <th align="left">Description</th> </tr> </thead> <tbody> <tr> <td align="left">OobDirs</td> <td align="left">Allowed directions of the OOBchannel</c> <c></c><c></c> <c>OobMessageEncoding</c><c>Howchannel.</td> </tr> <tr> <td align="left">OobMessageEncoding</td> <td align="left">How the OOB message data fields are encoded for the OOBchannel</c> <c></c><c></c> <c>SleepTimeDefault</c><c>Defaultchannel.</td> </tr> <tr> <td align="left">SleepTimeDefault</td> <td align="left">Default minimum time in seconds that the peer should sleep before the next WaitingExchange</c> <c></c><c></c> <c>OobRetries</c><c>NumberExchange.</td> </tr> <tr> <td align="left">OobRetries</td> <td align="left">Number of received OOB messages with invalidHoobHoob, after which the receiver moves to Unregistered (0) state. When the OOB channel has error detection or correction, theRECOMMENDED<bcp14>RECOMMENDED</bcp14> value is5.</c> <c></c><c></c> <c>NoobTimeout</c><c>How5.</td> </tr> <tr> <td align="left">NoobTimeout</td> <td align="left">How many seconds the sender of the OOB message remembers the sent Noob value. TheRECOMMENDED<bcp14>RECOMMENDED</bcp14> value is 3600seconds.</c> <c></c><c></c> <c>ServerInfoType</c><c>Theseconds.</td> </tr> <tr> <td align="left">ServerInfoType</td> <td align="left">The value of the Type field and the other required fields inServerInfo</c> <c></c><c></c> <c>PeerInfoType</c><c>TheServerInfo.</td> </tr> <tr> <td align="left">PeerInfoType</td> <td align="left">The value of the Type field and the other required fields inPeerInfo</c> </texttable>PeerInfo.</td> </tr> </tbody> </table> </section> <sectiontitle="EAP-NOOB roaming" anchor="roaming"> <t> AAAanchor="roaming" numbered="true" toc="default"> <name>EAP-NOOB Roaming</name> <t>AAA architectures <xreftarget="RFC2904"/>target="RFC2904" format="default"/> allow for roaming of network-connected appliances that are authenticated over EAP. While the peer is roaming in a visited network, authentication still takes place between the peer and an authentication server at its home network. 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 network to route the EAP session to the peer's home AAAserver. </t> <t> Aserver.</t> <t>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 association with its home AAA server before it is able to roam. After that, it can perform the Reconnect Exchange from the visitednetwork. </t> <t> Alternatively,network.</t> <t>Alternatively, the device may provide some method for the user to configure the NAI of the home network. This is the user orapplication configuredapplication-configured NAI mentioned in <xreftarget="nai"/>.target="nai" format="default"/>. In that case, the EAP-NOOB association can be created while roaming. The configured NAI enables the EAP messages to be routed correctly to the home AAA server. </t><t> While<t>While roaming, the device needs to identify the networks where the EAP-NOOB association can be used to gain network access. For 802.11 access networks, the serverMAY<bcp14>MAY</bcp14> send a list of SSID strings in the ServerInfofieldfield, called either SSIDList or Base64SSIDList. The list is formatted as explained in <xreftarget="table-serverinfo-meaning"/>.target="tab-serverinfo-meaning" format="default"/>. If present, the peerMAY<bcp14>MAY</bcp14> use this list as a hint to determine the networks where the EAP-NOOB association can be used for access authorization, in addition to the access network where the Initial Exchange tookplace. </t>place.</t> </section> <sectiontitle="OOB messageanchor="urloob" numbered="true" toc="default"> <name>OOB Message asURL" anchor="urloob"> <t> Whilea URL</name> <t>While EAP-NOOB does not mandate any particular OOB communication channel, typical OOB channels include graphical displays and emulated 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 for displays and printers or as anNDEFNFC Data Exchange Format (NDEF) record for dynamic NFC tags. A user can then simply scan the QR code or NFC tag and open the URL, which causes the OOB message to be delivered to the authentication server. The URLMUST<bcp14>MUST</bcp14> specify https or another server-authenticatedscheme,scheme so that there is a secure connection to the server and the on-path attacker cannot read or modify the OOBmessage. </t> <t> Themessage.</t> <t>The ServerInfo in this case includes a field called ServerURL of the following format withRECOMMENDEDa <bcp14>RECOMMENDED</bcp14> length of at most 60characters: </t> <t> https://<host>[:<port>]/[<path>] </t> <t> Tocharacters:</t> <t><tt>https://<host>[:<port>]/[<path>]</tt></t> <t>To this, the peer appends the OOB message fields (PeerId, Noob, and Hoob) 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, without padding, the 16-byte values Noob and Hoob into 22-character ASCII strings. The query parametersMAY<bcp14>MAY</bcp14> be in any order. The resulting URL is of the followingformat: </t> <t> https://<host>[:<port>]/[<path>]?P=<PeerId>&N=<Noob>&H=<Hoob>format:</t> <t><tt>https://<host>[:<port>]/[<path>]?P=<PeerId>&N=<Noob>&H=<Hoob></tt> </t><t> The<t>The following is an example of a well-formed URL encoding the OOB message (without linebreaks): </t> <t> https://aaa.example.com/eapnoob?P=mcm5BSCDZ45cYPlAr1ghNw&N=rMinS0-F4EfCU8D9ljxX_A&H=QvnMp4UGxuQVFaXPW_14UW </t> </section> <section title="Version history" anchor="vertrack"> <t> <list style="symbols"> <t> Version 01: <list> <t>Fixed Reconnection Exchange.</t> <t>URL examples.</t> <t>Message examples.</t> <t>Improved state transition (event) tables.</t> </list> </t> <t> Version 02: <list> <t>Reworked the rekeying and key derivation.</t> <t>Increased internal key lengths and in-band nonce and HMAC lengths to 32 bytes.</t> <t>Less data in the persistent EAP-NOOB association.</t> <t>Updated reference <xref target="NIST-DH"/> to Revision 2 (2013).</t> <t>Shorter suggested PeerId format.</t> <t>Optimized the example of encoding OOB message as URL.</t> <t>NoobId in Completion Exchange to differentiate between multiple valid Noob values.</t> <t>List of application-specific parameters in appendix.</t> <t>Clarified the equivalence of Unregistered state and no state.</t> <t>Peer SHOULD probe the server regardless of the OOB channel direction. </t> <t>Added new error messages.</t> <t>Realm is part of the persistent association and can be updated.</t> <t>Clarified error handling.</t> <t>Updated message examples.</t> <t>Explained roaming in appendix. </t> <t>More accurate definition of timeout for the Noob nonce. </t> <t>Additions to security considerations.</t> </list> </t> <t> Version 03: <list> <t>Clarified reasons for going to Reconnecting state.</t> <t>Included Verp in persistent state.</t> <t>Added appendix on suggested ServerInfo and PeerInfo fields.</t> <t>Exporting PeerId and SessionId.</t> <t>Explicitly specified next state after OOB Step.</t> <t>Clarified the processing of an expired OOB message and unrecognized NoobId.</t> <t>Enabled protocol version upgrade in Reconnect Exchange.</t> <t>Explained handling of redundant received OOB messages.</t> <t>Clarified where raw and base64url encoded values are used.</t> <t>Cryptosuite must specify the detailed format of the JWK object.</t> <t>Base64url encoding in JSON strings is done without padding.</t> <t>Simplified explanation of PeerId, Realm and NAI.</t> <t>Added error codes for private and experimental use.</t> <t>Updated the security considerations.</t> </list> </t> <t> Version 04: <list> <t>Recovery from synchronization failure due to lost last response.</t> </list> </t> <t> Version 05: <list> <t>Kz identifier added to help recovery from lost last messages.</t> <t>Error message codes changed for better structure.</t> <t>Improved security considerations section.</t> </list> </t> <t> Version 06: <list> <t>Kz identifier removed to enable PeerId anonymization in the future.</t> <t>Clarified text on when to use server-assigned realm.</t> <t>Send PeerId and PeerState in a separate request-response pair, not in NAI.</t> <t>New subsection for the common handshake in all exchanges to avoid repetition.</t> </list> </t> <t> Version 07: <list> <t>Updated example messages.</t> <t>Added pointers to new implementation in Contiki.</t> </list> </t> <t> Version 08: <list> <t>Editorial improvements and corrections.</t> </list> </t> <t> WG Version 00: <list> <t>Editorial improvements and corrections.</t> <t>Updated reference <xref target="NIST-DH"/> to Revision 3 (2018).</t> </list> </t> <t> WG Version 01: <list> <t>Add NIST P-256 as Cryptosuite 2.</t> <t>Renumber message types.</t> <t>Very minor editorial fixes.</t> </list> </t> <t> WG Version 02: <list> <t>Updated message examples with all KeyingModes.</t> <t>Many editorial fixes and other updates based on the IoT directorate review of Dave Thaler.</t> <t>Text on cloning attacks based on review by Hannes Tschofenig.</t> </list> </t> <t> WG Version 03: <list> <t>Changed server-assigned Realm to server-assigned NAI to avoid username collisions. This issue was identified in a review by Alan Dekok.</t> <t>Minor editorial improvements.</t> </list> </t> <t> WG Version 04: <list> <t>Use of more inclusive language.</t> <t>Minor changes to IANA registration policies.</t> <t>Explain how relative strength of cryptosuites is determined.</t> <t>Improvements based on AD review from Roman Danyliw and shepherd review from Joseph Salowey.</t> </list> </t> <t> WG Version 05: <list> <t>Many text clarifications based on IESG evaluation.</t> <t>Security considerations subsections on success indications, channel binding, and denial of service.</t> <t>Privacy considerations gathered to a separate section.</t> </list> </t> <t> WG Version 06: <list> <t>Remove leftover text in section on identifying correct endpoints.</t> <t>Example messages removed.</t> </list> </t> </list> </t>breaks):</t> <t><tt>https://aaa.example.com/eapnoob?P=mcm5BSCDZ45cYPlAr1ghNw&N=rMinS0-F4EfCU8D9ljxX_A&H=QvnMp4UGxuQVFaXPW_14UW</tt></t> </section> <sectiontitle="Acknowledgments" anchor="acks"> <t> Max Crone, Shivaanchor="acks" numbered="false" toc="default"> <name>Acknowledgments</name> <t><contact fullname="Max Crone"/>, <contact fullname="Shiva PrasadTP,TP"/>, andRaghavendra MS<contact fullname="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<contact fullname="Eduardo Inglés"/> and <contact fullname="Dan Garcia-Carrillo"/> were involved in the implementation of this protocol on Contiki. Their inputs helped us in improving thespecification. </t> <t> Thespecification.</t> <t>The authors would like to thankRhys Smith and Josh Howlett<contact fullname="Rhys Smith"/> and <contact fullname="Josh Howlett"/> for providing valuablefeedbackfeedback, as well as new use cases and requirements for the protocol. Thanks toEric Rescorla, Alan Dekok, Darshak Thakore, Stefan Winter, Hannes Tschofenig, Daniel Migault, Roman Danyliw, Benjamin Kaduk, Francesca Palombini, Steve Hanna, Lars Eggert, and Eric Vyncke<contact fullname="Eric Rescorla"/>, <contact fullname="Alan Dekok"/>, <contact fullname="Darshak Thakore"/>, <contact fullname="Stefan Winter"/>, <contact fullname="Hannes Tschofenig"/>, <contact fullname="Daniel Migault"/>, <contact fullname="Roman Danyliw"/>, <contact fullname="Benjamin Kaduk"/>, <contact fullname="Francesca Palombini"/>, <contact fullname="Steve Hanna"/>, <contact fullname="Lars Eggert"/>, and <contact fullname="Éric Vyncke"/> for their comments andreviews. </t> <t> Wereviews.</t> <t>We would also like to express our sincere gratitude toDave Thaler<contact fullname="Dave Thaler"/> for his thorough review of thedocument. </t>document.</t> </section> </back> </rfc>