One document matched: draft-aura-eap-noob-00.xml
<?xml version="1.0" encoding="us-ascii"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC1738 SYSTEM "reference.RFC.1738.xml">
<!ENTITY RFC2104 SYSTEM "reference.RFC.2104.xml">
<!ENTITY RFC2119 SYSTEM "reference.RFC.2119.xml">
<!ENTITY RFC2434 SYSTEM "reference.RFC.2434.xml">
<!ENTITY RFC3748 SYSTEM "reference.RFC.3748.xml">
<!ENTITY RFC4648 SYSTEM "reference.RFC.4648.xml">
<!ENTITY RFC5216 SYSTEM "reference.RFC.5216.xml">
<!ENTITY RFC6234 SYSTEM "reference.RFC.6234.xml">
<!ENTITY RFC6761 SYSTEM "reference.RFC.6761.xml">
<!ENTITY RFC7159 SYSTEM "reference.RFC.7159.xml">
<!ENTITY RFC7517 SYSTEM "reference.RFC.7517.xml">
<!ENTITY RFC7542 SYSTEM "reference.RFC.7542.xml">
<!ENTITY RFC7748 SYSTEM "reference.RFC.7748.xml">
<!ENTITY peerstate SYSTEM "statemachine.xml">
<!ENTITY newline "
">
]>
<?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"?>
<rfc category="std" docName="draft-aura-eap-noob-00" ipr="trust200902">
<front>
<title abbrev="EAP-NOOB">Nimble out-of-band authentication for EAP (EAP-NOOB)</title>
<author initials="T" surname="Aura" fullname="Tuomas Aura">
<organization>Aalto University</organization>
<address>
<postal>
<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>Hirsalantie 11</street>
<city>Jorvas</city>
<code>02420</code>
<country>Finland</country>
</postal>
<email>mohit@piuha.net</email>
</address>
</author>
<date />
<area>Security</area>
<workgroup>Network Working Group</workgroup>
<abstract>
<t>
Extensible Authentication Protocol (EAP) <xref target="RFC3748"></xref> provides support for multiple authentication methods. This document defines the EAP-NOOB authentication method for nimble out-of-band (OOB) authentication and key derivation. This EAP method is intended for bootstrapping all kinds of Internet-of-Things (IoT) devices that have a minimal user interface and no pre-configured authentication credentials. The method makes use of a user-assisted one-directional OOB channel between the peer device and authentication server.
</t>
</abstract>
</front>
<middle>
<!-- **************************************************************** -->
<section title="Introduction" anchor="introduction">
<t>
This document describes a method for registration, authentication and key derivation for network-connected ubiquitous computing 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. 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 interfaces are limited to either only input (e.g. camera) or output (e.g. display screen). The device configuration is made more challenging by the fact that the devices may exist in large numbers or may have to be deployed or re-configured nimbly based on user needs.
</t>
<t>More specifically, the devices may have the following characteristics:
<list style="symbols">
<t>no pre-established relation with a specific server or user,
</t>
<t>no pre-provisioned device identifier or authentication credentials,
</t>
<t>limited user interface and configuration capabilities.
</t>
</list>
</t>
<t>
Many proprietary OOB configuration methods exits 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, speaker, and cameras. The security bootstrapping in this specification makes use of a user-assisted out-of-band (OOB) channel. The 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 of 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 man-in-the-middle (MitM) attacks.
</t>
<t>
The solution presented here is intended for devices that have either an input or output interface, such as a camera or display screen, which 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. We also assume that the OOB channel is at least partly automated (e.g. camera scanning a bar code) and, thus, there is no need to absolutely minimize the length of the data transferred through the OOB channel. This differs, for example, from Bluetooth simple pairing <xref target="SimplePairing"/>, where it is critical to minimize the length of the manually transferred or compared codes. Since the OOB messages are dynamically generated, we do not support static printed registration codes. This also prevents attacks where a static secret code would be leaked.
</t>
</section>
<section title="Terminology" anchor="terminology">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119"/>.
</t>
<t>
In addition, this document frequently uses the following terms as they have been defined in <xref target="RFC5216"/>:
<list style="hanging" hangIndent="6">
<t hangText="authenticator">
The entity initiating EAP authentication.
</t>
<t hangText="peer">
The entity that responds to the authenticator. In <xref target="IEEE-802.1X"/>, this entity is known as the Supplicant.
</t>
<t hangText="server">
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 authentication server.
</t>
</list>
</t>
</section>
<!-- **************************************************************** -->
<section title="EAP-NOOB protocol" anchor="eap-noob">
<t>
This section defines the EAP-NOOB protocol. The protocol is a generalized version of the original idea presented by <xref target="Sethi14">Sethi et al.</xref>.
</t>
<section title="Protocol overview" anchor="overview">
<t>
One EAP-NOOB protocol execution spans multiple EAP exchanges. This is necessary to leave time for the OOB message to be delivered, as will be explained below.
</t>
<t>
The overall protocol starts with the Initial Exchange, in which the server allocates an identifier to the peer, and the server and peer negotiate the protocol version and cryptosuite (i.e. cryptographic algorithm suite), exchange nonces and perform an Elliptic Curve Diffie-Hellman (ECDH) key exchange. The user-assisted OOB Step then takes place. This step involves only one out-of-band message either from the peer to the server or from the server to the peer. While waiting for the OOB Step action, the peer MAY 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 parties store the created association in persistent storage, and the OOB Step is not repeated. Thereafter, creation of new temporal keys, ECDH rekeying, and updates of cryptographic algorithms can be achieved with the Reconnect Exchange.
</t>
<t>
<xref target="figstatemachine"/> shows the association state machine, which is the same for the server and for the peer. When the client 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 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 either party may cause the protocol to fall back to the Initial Exchange. After the Completion Exchange has resulted in EAP-Success, the association state becomes persistent (persistent states 3..4), and only user reset or accidental failure can cause the return of the server or the peer to the ephemeral states and to the Initial Exchange.
</t>
<t>
<figure anchor="figstatemachine" title="EAP-NOOB server-peer association state machine" align="center">
<artwork>
<![CDATA[
]]>
<![CDATA[
OOB Output, Initial Exchange,
or Waiting Exchange
.-----.
| v
.------------------. Initial .------------------.
| | Exchange | |
.->| 0. Unregistered |---------------->|1. Waiting for OOB|
| | | | |
| '------------------' '------------------'
| | | ^
User Reset Completion | | |
| Exchange | OOB Initial
|<-------. .<------------------------' Input Exchange
| | | | |
| | v v |
| .------------------. Completion .------------------.
| | | Exchange | |
| | 4. Registered |<----------------| 2. OOB Received |
| | | | |
| '------------------' '------------------'
| | ^
| | |
| Timeout / Reconnect
| Failure Exchange
| | |
| v |
| .-----------------.
| | |
'--| 3. Reconnecting |
| |
'-----------------'
]]>
</artwork>
</figure>
</t>
<t>
The server MUST NOT repeat the 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 particular, once the association has entered the Registered state, the server MUST NOT delete the association or go back to states 0-2 without explicit user approval. Similarly, the peer MUST NOT repeat the OOB Step unless the user explicitly deletes the association with the server or resets it to the Unregistered state. However, it can happen that the client accidentally loses its persistent state and reconnects to the server without a previously allocated peer identifier. In that case, the server MUST treat the peer as a new peer. The server MAY use auxiliary information, such as the PeerInfo field received in the Initial Exchange, to detect such multiple association of the same peer. However, it MUST NOT automatically delete associations because there is no secure way of verifying that the two peers are the same physical device.
</t>
<t>
A special feature of the EAP-NOOB method is that the server is not assumed to have any a-priori knowledge of the peer. Therefore, the peer initially uses the generic identity string "noob@eap-noob.net" as the NAI. The server then allocates a server-specific identifier to the peer. The network access identifier NAI is a concatenation of the server-allocated peer identifier and the generic suffix "@eap-noob.net". This suffix serves two purposes: firstly, it tells the server that the peer supports and expects the EAP-NOOB method and, secondly, it allows routing of the EAP-NOOB sessions to a specific authentication server in the AAA architecture.
</t>
<t>
EAP-NOOB is an unusual EAP method in that the peer has to connect to the server two or more times 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. In particular, EAP-NOOB supports also peers or servers with no input capability in the user interface. Since these output-only parties cannot be told to perform the protocol at the right moment, they have to perform the initial exchange opportunistically and hope for the OOB Step to take place within a timeout period, which is why the timeout needs to be several minutes rather than seconds. For example, consider a printer (peer) from which the OOB message is printed as a bar code on paper and then scanned with a camera phone and communicated to the server. To support such devices and slow OOB channels, the peer in EAP-NOOB first contacts the server in the Initial Exchange, then disconnects for some time, and later continues with the Waiting and Completion Exchanges.
</t>
</section>
<!-- **************************************************************** -->
<section title="Protocol messages and sequences" anchor="protocol">
<t>
This section defines the EAP-NOOB exchanges. The protocol messages communicated and the data members in each message are listed in the diagrams below.
</t>
<t>
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, containing the network access identifier (NAI). The peer MUST compose the NAI as defined in <xref target="dataitems"/>. Essentially, if the peer has no previous peer identifier (PeerId), it uses the fixed NAI string "noob@eap-noob.net", and if it has received a PeerId from the server, it creates the NAI by concatenating the PeerId, a state indicator "+sX", and the fixed suffix string "@eap-noob.net".
</t>
<t>
After receiving the NAI, the server chooses the EAP-NOOB exchange, i.e. the ensuing message sequence, based on the combination of the client and server states. The client recognizes the exchange based on the message type field (Type) of the EAP-NOOB request received from the server. The available exchanges are defined in the following subsections. Each exchange comprises one or two EAP requests-response pairs and ends in either EAP-Failure, indicating that authentication is not (yet) successful, or in EAP-Success.
</t>
<section title="Initial Exchange" anchor="initialexchange">
<t>
Upon receiving the EAP-Response/Identity from the peer, if either the peer or the 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.
</t>
<t>
The Initial Exchange comprises two EAP-NOOB request-response pairs, one for version, algorithm and parameter negotiation and the other for the ECDH key exchange. The first EAP-NOOB request (Type=1) from the server contains a newly allocated PeerId for the peer, regardless of the username part of the received NAI. The server also sends in the request a list of protocol versions supported (Vers), cryptosuites (Cryptosuites), an indicator of the OOB channel directions supported by the server (Dirs), and a ServerInfo object. The peer chooses one of the versions and cryptosuites. The peer sends a response (Type=1) with the selected protocol version (Verp), the received PeerId, the selected cryptosuite (Cryptosuitep), an indicator of the OOB channel directions supported by the peer (Dirp), and a PeerInfo object. In the second EAP-NOOB request and response (Type=2), the server and peer exchange the public components of their ECDH keys and nonces (PKs,Ns,PKp,Np). The ECDH keys MUST be based on the negotiated cryptosuite. The Initial Exchange ends with EAP-Failure from the server because the authentication cannot yet be completed.
</t>
<t>
At the conclusion of the Initial Exchange, both the server and the peer move to the Waiting for OOB (1) state.
</t>
<t>
<figure anchor="fig-initial" title="Initial Exchange">
<artwork align="center">
<![CDATA[
]]>
<![CDATA[
EAP Peer EAP Server
| |
|<----------- EAP-Request/Identity -| |
| |
| |
|------------ EAP-Response/Identity -------------->|
| (NAI=noob|PeerId+sX@eap-noob.net) |
| |
| |
|<----------- EAP-Request/EAP-NOOB ----------------|
| (Type=1,Vers,PeerId,Cryptosuites,Dirs,ServerInfo)|
| |
| |
|------------ EAP-Response/EAP-NOOB -------------->|
| (Type=1,Verp,PeerId,Cryptosuitep,Dirp,PeerInfo) |
| |
| |
|<----------- EAP-Request/EAP-NOOB ----------------|
| (Type=2,PeerId,PKs,Ns) |
| |
| |
|------------ EAP-Response/EAP-NOOB -------------->|
| (Type=2,PeerId,PKp,Np) |
| |
| |
|<----------- EAP-Failure -------------------------|
| |
]]>
</artwork>
</figure>
</t>
</section>
<section title="OOB Step" anchor="oobstep">
<t>
The OOB Step, shown as OOB Output and OOB Input in <xref target="figstatemachine"/>, takes place after the Initial Exchange. Depending on the direction negotiated, the peer or the server outputs the OOB message containing the PeerId, the secret nonce Noob, and the cryptographic fingerprint Hoob, as defined in <xref target="dataitems"/>. This message is then delivered to the other party via a user-assisted OOB channel. The details of the OOB channel are defined by the application. The receiver of the OOB message MUST compare the received value of the fingerprint Hoob with a value that it computes locally.
</t>
<t>
Even though not recommended (see <xref target="dataitems"/>), this specification allows both directions to be negotiated. In this case, both sides SHOULD output the OOB message, and it is up to the user to deliver one of them.
</t>
<t>
<figure anchor="fig-oob1" title="OOB Step, from peer to EAP server">
<artwork align="center">
<![CDATA[
EAP Peer EAP Server
| |
|=================OOB=============================>|
| (PeerId,Noob,Hoob) |
| |
]]>
</artwork>
</figure>
<figure anchor="fig-oob2" title="OOB Step, from EAP server to peer">
<artwork align="center">
<![CDATA[
EAP Peer EAP Server
| |
|<================OOB==============================|
| (PeerId,Noob,Hoob) |
| |
]]>
</artwork>
</figure>
</t>
</section>
<section title="Completion Exchange" anchor="completionexchange">
<t>
After the Initial Exchange, if both the server the peer support the peer-to-server direction for the OOB channel, the peer SHOULD initiate the EAP-NOOB method again after an applications-specific waiting time in order to probe for completion of the OOB Step. Also, if both sides support the server-to-peer direction of the OOB exchange and the peer receives the OOB message, it SHOULD initiate the EAP-NOOB method immediately. Once server receives the EAP-Response/Identity, if one of the server and peer is in the OOB Received (2) state and the other is in the Waiting for OOB (1) or OOB Received (2) state, the OOB Step has taken place and the server SHOULD continue with the Completion Exchange.
</t>
<t>
The Completion Exchange comprises one EAP-NOOB request-response pair (Type=4). In these messages, the server and peer exchange message authentication codes. Both sides MUST compute the keys Kms and Kmp as defined in <xref target="keyderivation"/> and the message authentication codes MACs and MACp as defined in <xref target="dataitems"/>. Both sides MUST compare the received message authentication code with a locally computed value. If the EAP server finds that it has received the correct value of MACp, the Completion Exchange ends in EAP-Success; otherwise, in EAP-Failure.
</t>
<t>
While 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 by observing that both the server and peer are in the OOB Received state (2). In that case, the server MUST behave as if only the server-to-peer message was delivered.
</t>
<t>
After successful Completion Exchange, both the server and the peer move to the Registered (4) state.
</t>
<t>
<figure anchor="fig-completion" title="Completion Exchange">
<artwork align="center">
<![CDATA[
EAP Peer EAP Server
| |
|<----------- EAP-Request/Identity -| |
| |
| |
|------------ EAP-Response/Identity -------------->|
| (NAI=PeerId+sX@eap-noob.net) |
| |
| |
|<----------- EAP-Request/EAP-NOOB ----------------|
| (Type=4,PeerId,MACs) |
| |
| |
|------------ EAP-Response/EAP-NOOB -------------->|
| (Type=4,PeerId,MACp) |
| |
| |
|<----------- EAP-Success -------------------------|
| |
]]>
</artwork>
</figure>
</t>
</section>
<section title="Waiting Exchange" anchor="waitingexchange">
<t>
As explained in <xref target="completionexchange"/>, if both the server and the peer support the peer-to-server direction for the OOB channel, the peer will probe the server for completion of the OOB Step. If both the server and client states are Waiting for OOB (1), the server will continue with the Waiting Exchange (message Type=3). The only purpose of this exchange is to indicate to the peer that the server has not yet received a peer-to-server OOB message.
</t>
<t>
In order to limit the rate at which peers probe the server, the server sends to the peer a minimum time to wait before probing the server again. The peer MUST wait at least the server-specified minimum waiting time in seconds (MinSleep) before initiating EAP again with the same server. If the server omits the MinSleep field from the request, the peer SHOULD wait for an application-specified minimum time.
</t>
<t>
<figure anchor="fig-waiting" title="Waiting Exchange">
<artwork align="center">
<![CDATA[
EAP Peer EAP Server
| |
|<----------- EAP-Request/Identity -| |
| |
| |
|------------ EAP-Response/Identity -------------->|
| (NAI=PeerId+s1@eap-noob.net) |
| |
| |
|<----------- EAP-Request/EAP-NOOB ----------------|
| (Type=3,PeerId,[MinSleep]) |
| |
| |
|------------ EAP-Response/EAP-NOOB -------------->|
| (Type=3,PeerId) |
| |
| |
|<----------- EAP-Failure -------------------------|
| |
]]>
</artwork>
</figure>
</t>
</section>
</section>
<section title="Message data items" anchor="dataitems">
<t>
<xref target="datafieldtable"/> defines the data items in the protocol messages. The in-band messages are formatted as JSON objects <xref target="RFC7159"/> in UTF-8 encoding. The member names are in the left-hand column of table.
</t>
<texttable title="Message data items" anchor="datafieldtable">
<ttcol align="left" width="25%">Data field</ttcol>
<ttcol align="left">Description</ttcol>
<c>Vers,Verp</c>
<c>EAP-NOOB protocol versions supported by the EAP server, and the protocol version chosen by the peer. Vers is a JSON array of unsigned integers, and Verp is an unsigned integer. Currently, the only defined values are "[1]" and "1", respectively.
</c>
<c>PeerId</c>
<c>Peer identifier. If the peer does not yet have a peer identifier or it does not remember one, it uses the NAI "noob@eap-noob.net" in the Initial Exchange. The server then assigns an identifier to the peer and sends it in the first server-to-peer request of the Initial Exchange. The assigned identifier is ephemeral until a successful Completion Exchange takes place. Thereafter, the peer identifier becomes permanent until the user resets the peer and the server. Resetting the server means deleting the association for the peer from the server database. The peer identifier MUST follow the syntax of the utf8-username specified in <xref target="RFC7542"/>; however, it MUST NOT exceed 60 bytes in length and MUST NOT contain the character '+'. The server MUST generate the identifiers in such a way that they do not repeat and cannot be guessed by the peer or third parties beforehand. One way to generate the identifiers is to choose a random 40-digit lower-case hexadecimal string. </c>
<c></c><c></c>
<c>Peer State "+sX"</c>
<c>This part of the NAI informs the server about the peer state. The server uses this information together with the server state to decide on the type of the exchange and, thus, of the type of the next EAP-Request. The peer appends the peer state to the PeerId to form the username part of the NAI. (Sending it in the EAP-Response/Identity message avoids an additional round trip for querying the peer state.) If the peer is in state 0, it MUST use the NAI "noob@eap-noob.net"; otherwise, the peer MUST create the NAI as the concatenation of the PeerId, the string "+s", a single digit indicating the state of the peer, and the string "@eap-noob.net".</c>
<c></c><c></c>
<c>Type</c>
<c>EAP-NOOB message type. The type is an integer in the range 0..6. EAP-NOOB requests and the corresponding responses share the same type value. </c>
<c></c><c></c>
<c>PKs, PKp</c>
<c>The public components of the ECDH keys of the server and peer. PKs and PKp are sent in the JSON Web Key (JWK) format <xref target="RFC7517"/>. </c>
<c></c><c></c>
<c>Cryptosuites, Cryptosuitep</c>
<c>The identifiers of cryptosuites supported by the server and of the cryptosuite selected by the peer. The format is specified in <xref target="cryptosuites"/>. </c>
<c></c><c></c>
<c>Dirs, Dirp</c>
<c>OOB channel directions supported by the server and the peer. The possible values are 1=peer-to-server, 2=server-to-peer, 3=both directions. Endpoints that are general-purpose computers or online services SHOULD support both directions. IoT devices with a limited user interface will mostly support only one direction. If the negotiated value is 3, the user may be presented with two OOB messages, one for each direction, even though the user needs to deliver only one of them. Since this can be confusing to the user, it RECOMMENDED that the peer selects value 1 or 2. The EAP-NOOB protocol itself is designed to cope also with selected value 3, in which case it uses the first delivered OOB message. In the unlikely case of simultaneously delivered OOB messages, the protocol prioritizes the server-to-peer direction.</c>
<c></c><c></c>
<c>Ns, Np</c>
<c>Nonces for the Initial Exchange. </c>
<c></c><c></c>
<c>ServerInfo</c>
<c>This field contains information about the server to be passed from the EAP method to the application layer in the peer. The content of this field is specific to the application. It could include, for example, the network name and server name or a Uniform Resource Locator (URL) <xref target="RFC1738"/> or some other information that helps the user to deliver the OOB message to the server through the out-of-band channel. </c>
<c></c><c></c>
<c>PeerInfo</c>
<c>This field contains information about the peer to be passed from the EAP method to the application layer in the server. The content of this field is specific to the application. It could include, for example, the peer make, model and serial number that helps the user to distinguish between devices and to deliver the OOB message to the correct peer through the out-of-band channel. </c>
<c></c><c></c>
<c>MinSleep</c>
<c>The number of seconds for which peer MUST NOT start a new execution of the EAP-NOOB method with the authenticator, unless the peer is reset by the user. The server can use this field to limit the rate at which peers probe it for the completion of the OOB Step. MinSleep is an unsigned integer in the range 0..3600.</c>
<c></c><c></c>
<c>Noob</c>
<c>Secret nonce sent through the OOB channel and used for the session key derivation. The party that received the OOB message uses this secret in the Completion Exchange to authenticate the exchanged key to the party that sent the OOB message. </c>
<c></c><c></c>
<c>Hoob</c>
<c>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 party that receives the OOB message. </c>
<c></c><c></c>
<c>Ns2, Np2</c>
<c>Nonces for the Reconnect Exchange. </c>
<c></c><c></c>
<c>MACs, MACp</c>
<c>Message authentication codes 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 <xref target="keyderivation"/>. </c>
<c></c><c></c>
<c>PKs2, PKp2</c>
<c>The public components of the ECDH keys of the server and peer. These MUST be present if a new cryptosuite was negotiated. Otherwise, either party may omit the field. PKs2 and PKp2 are sent in the JSON Web Key (JWK) format <xref target="RFC7517"/>. </c>
<c></c><c></c>
<c>MACs2, MACp2</c>
<c>Message authentication codes 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 <xref target="keyderivation"/>. </c>
<c></c><c></c>
</texttable>
<t>
All nonces (Ns, Np, Ns2, Np2, Noob) are 16-byte fresh random byte strings generated by the party that sends the message.
</t>
<t>
The fingerprint Hoob is computed with the hash function 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 HMAC function <xref target="RFC2104"/> based on the same cryptographic hash function and truncated to the 16 leftmost bytes of the output.
</t>
<t>
The inputs to the hash function for computing the fingerprint Hoob and to the HMAC for computing MACs, MACp, MACs2 and MACp2 are JSON arrays containing a fixed number (15) of members. The array member values MUST be copied to the array verbatim from the in-band messages, and space characters or whitespace MUST NOT be added anywhere in the JSON structure.
</t>
<t>
The inputs for computing the fingerprint and message authentication codes are the following:
<list style="empty">
<t>Hoob = H(Dir,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,Cryptosuitepp,Dirp,PeerInfo,PKs,Ns,PKp,Np,Noob). </t>
<t>MACs = HMAC(Kms; 2,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,Cryptosuitep,Dirp,PeerInfo,PKs,Ns,PKp,Np,Noob). </t>
<t>MACp = HMAC(Kmp; 1,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,Cryptosuitep,Dirp,PeerInfo,PKs,Ns,PKp,Np,Noob). </t>
<t>MACs2 = HMAC(Kms2; 2,Vers,Verp,PeerId,Cryptosuites,"",[ServerInfo],Cryptosuitep,"",[PeerInfo],[PKs2],Ns2,[PKp2],Np2,"") </t>
<t>MACp2 = HMAC(Kmp2; 1,Vers,Verp,PeerId,Cryptosuites,"",[ServerInfo],Cryptosuitep,"",[PeerInfo],[PKs2],Ns2,[PKp2],Np2,"") </t>
</list>
</t>
<t>
Missing input values are represented by empty strings "" in the array. The values indicated with "" are always empty strings. The values in brackets MUST be included if they were exchanged in the same Reconnect Exchange; otherwise these values are replaced by empty strings "".
</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 in needed 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 for the HMACs are defined in the following section.
</t>
<t>
The nonces (Ns, Np, Ns2, Np2) and message authentication codes (MACs, MACp, MACs2, MACp2) in the in-band messages and in the cryptographic function inputs MUST be base64url encoded <xref target="RFC4648"/>. The values Noob and Hoob in the OOB channel MAY also be base64url encoded, if that is appropriate for the application and the used OOB channel.
</t>
<t>
The ServerInfo and PeerInfo are JSON object with UFT-8 encoding. The length of each encoded object as a byte arrays MUST NOT exceed 500 bytes. The format and semantics of these objects MUST be defined by the application that uses the EAP-NOOB method.
</t>
</section>
<section title="Fast reconnect and rekeying" anchor="reuseandrekeying">
<t>
EAP-NOOB implements Fast Reconnect (<xref target="RFC3748"/>, section 7.2.1) that avoids repeated use of the user-assisted OOB channel. For this reason, the EAP server and peer store the session state in persistent memory after a successful Completion Exchange. This persistent data, called "persistent EAP-NOOB association", MUST include at least the following data: PeerId, negotiated cryptosuite, Kms, Kmp, and Kz. The last three are shared keys used internally by EAP-NOOB for rekeying in the Reconnect Exchange. When a persistent EAP-NOOB association exists, the EAP server and peer are in the Registered state (4) or Reconnecting state (3), as shown in <xref target="figstatemachine"/>.
</t>
<t>
The rekeying and Reconnect Exchange may be needed for several reasons. A timeout, software or hardware failure, or user action may cause the EAP server, peer or authenticator to lose its non-persistent state data such as master keys. Change 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 such an event, it MUST change from the Registered to Reconnecting state. The EAP-NOOB method will then perform the Reconnect Exchange next time when EAP is triggered. Thus, the difference between the Registered state and Reconnecting state is that, in the Reconnecting state, some of the non-persistent data related to the EAP-NOOB association between the EAP server and peer may be lost or stale, and a new key exchange is needed.
</t>
<section title="Reconnect Exchange" anchor="reconnectexchange">
<t>
The server chooses the Reconnect Exchange when peer is in the Reconnecting (3) state and the server itself is in the Registered (4) or Reconnecting (3) state. The peer MUST NOT initiate EAP-NOOB when the peer is in Registered state.
</t>
<t>
The Reconnect Exchange comprises two EAP-NOOB request-response pairs, one for algorithm and parameter negotiation and the other for the key exchange. In the first request and response (Type=5) the server and peer negotiate a cryptosuite in the same way as in the Initial Exchange. The messages MAY also contain PeerInfo and ServerInfo objects. In the second request and response (Type=6), the server and peer exchange the public components of ECDH keys and nonces (PKs2,Ns2,PKp2,Np2). The server ECDH key MUST be fresh, i.e. not previously used with the same peer, and the client ECDH key SHOULD be fresh, i.e. not previously used.
</t>
<t>
However, if the negotiated cryptosuite is the same as previously, the server MAY refuse to perform a new ECDH exchange by omitting PKs2, and the peer MAY refuse by omitting PKp2. If the server omits PKs2, it is RECOMMENDED that the peer also omits PKp2, as it will not be used in any case. When one or both public keys are not present, the new master keys are derived from the fresh nonces and the previously established shared key Kz, as defined in <xref target="keyderivation"/>. The security property lost by refusing the ECDH exchange is forward secrecy.
</t>
<t>
The server and client MAY send updated ServerInfo and PeerInfo objects in the Reconnect Exchange. If there is no update to the values, they SHOULD omit this information from the messages.
</t>
<t>
Both sides MUST compare the received message authentication code with a locally computed value. If the EAP server finds that it has received the correct value of MACp2, the Reconnect Exchange ends in EAP-Success; otherwise, in EAP-Failure.
</t>
<t>
After successful Reconnect Exchange, both the server and the peer move to the Registered (4) state. If a new ECHD key exchange was performed, they also update the persistent EAP-NOOB association with the changed values.
</t>
<t>
<figure anchor="fig-reconnect" title="Reconnect Exchange">
<artwork align="center">
<![CDATA[
EAP Peer EAP Server
| |
|<----------- EAP-Request/Identity -| |
| |
| |
|------------ EAP-Response/Identity -------------->|
| (NAI=PeerId+s3@eap-noob.net) |
| |
| |
|<----------- EAP-Request/EAP-NOOB ----------------|
| (Type=5,PeerId,Cryptosuites,[ServerInfo]) |
| |
| |
|------------ EAP-Response/EAP-NOOB -------------->|
| (Type=5,PeerId,Cryptosuitep,[PeerInfo]) |
| |
|<----------- EAP-Request/EAP-NOOB ----------------|
| (Type=6,PeerId,[PKs2,]Ns2,MACs2) |
| |
| |
|------------ EAP-Response/EAP-NOOB -------------->|
| (Type=6,PeerId,[PKp2,]Np2,MACp2) |
| |
| |
|<----------- EAP-Success -------------------------|
| |
]]>
</artwork>
</figure>
</t>
</section>
<section title="User reset" anchor="userreset">
<t>
As shown in the association state machine in <xref target="figstatemachine"/>, the only specified way for the association to return from the Registered state (4) to the Unregistered state (0) 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 association data, or when the peer device is decommissioned.
</t>
<t>
The server could detect that the peer is in the Registered or Reconnecting state 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 server SHOULD log the error or notify an administrator. The only way to continue from such a situation is by having the user reset the peer device.
</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 administrator 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 step and, thus, identifies the physical peer device. The server user interface SHOULD support situations where the "new" peer is actually a previously registered peer that has been reset by a user or has otherwise lost the persistent EAP-NOOB association data and needs to be merged with the old peer data in the server.
</t>
</section>
</section>
<section title="Key derivation" anchor="keyderivation">
<t>
The EAP output values MSK and EMSK are derived with the Elliptic Curve Diffie-Hellman (ECDH) algorithm. In the terminology of the NIST specification <xref target="NIST-DH"/>, we use a C(2, 0, ECC CDH) scheme, i.e. two ephemeral keys and no static keys. The server and peer compute the ECDH shared secret Z as defined in section 6.1.2.2 and the secret keying material as defined in section 5.8.1 of the NIST specification. The hash function H for the Concatenation Key Derivation Function is taken from the negotiated cryptosuite.
</t>
<t>
The Concatenation Key Derivation Function in the NIST specification requires some additional input: AlgorithmID, PartyUInfo, PartyVInfo, SuppPubInfo, and SuppPrivInfo. In EAP_NOOB, the AlgorithmID is the fixed-length 8-byte ASCII string "EAP-NOOB". When keys are derived in the Completion Exchange, PartyUInfo is the nonce Np as a 16-byte byte string, and PartyVInfo is the nonce Ns as a 16-byte byte string. SuppPubInfo is not allowed in EAP-NOOB; that is, it is not included in the input of the key derivation function. In the Completion Exchange, SuppPrivInfo is the nonce Noob as a 16-byte byte string. When keys are derived in the Reconnect Exchange, the key derivation process is the same except for the following differences: PartyUInfo is the nonce Np2 as a 16-byte byte string, and PartyVInfo is the nonce Ns2 as a 16-byte byte string, and neither SuppPubInfo nor SuppPrivInfo is allowed.
</t>
<t>
After a successful Completion Exchange, the outputs of the EAP method are the following: MSK and EMSK are the bytes 0..63 and 64..127, respectively, of the output of the Concatenation Key Derivation Function. The 16-byte keys Kms and Kmp and the 32-byte key Kz used internally by EAP-NOOB for computing HMAC values are the bytes 128..143, 144..159, and 160..191, respectively, of the output of the Concatenation Key Derivation Function. EAP server and peer store the values Kms, Kmp and Kz in the persistent EAP-NOOB association.
</t>
<t>
After a successful Reconnect Exchange, there are two methods for deriving the new master keys. The first method is used when ECDH public keys were exchanged in the Reconnect Exchange. In this method, the outputs of the EAP method are the following: MSK and EMSK are the bytes 0..63 and 64..127, respectively, of the output of the Concatenation Key Derivation Function. The 32-byte key Kms2 is created by concatenating the stored 16-byte Kms value with the bytes 128..143 of the output of the Concatenation Key Derivation Function. The 32-byte key Kmp2 is similarly created by concatenating the stored 16-byte Kmp value with the bytes 144..159 of the output of the Concatenation Key Derivation Function. A new 32-byte key Kz is obtained by taking bytes 160..191 of the output of the Concatenation Key Derivation Function. EAP server and peer update the value of Kz in the persistent EAP-NOOB association.
</t>
<t>
The second method is used when no ECDH public keys were exchanged in the Reconnect Exchange (or if only one party sent its public key). In this method, input Z to the Concatenation Key Derivation Function is replaced with the 32-byte key Kz from the persistent EAP-NOOB association. This method achieves rekeying without the computational cost of the ECDH exchange, but does not provide forward secrecy. In this second method, no updates are made to the persistent EAP-NOOB association.
</t>
</section>
<section title="Error handling" anchor="failure">
<t>
Various error conditions in EAP-NOOB are handled by sending an error notification message (type=0) instead of the expected next EAP request or response message. Both the EAP server and the peer may send the error notification, as shown in <xref target="fig-servererror"/> and <xref target="fig-peererror"/>. After sending or receiving an error notification, the server MUST send an EAP-Failure message. The notification MAY contain an ErrorInfo field, which is a UTF-8 encoded text string with a maximum length of 500 bytes. It is used for sending descriptive information about the error, which may be useful for logging and debugging.
</t>
<t>
<figure anchor="fig-servererror" title="Error notification from server to peer">
<artwork align="center">
<![CDATA[
EAP Peer EAP Server
... ...
| |
|<----------- EAP-Request/EAP-NOOB ----------------|
| (Type=0,[PeerId],ErrorCode,[ErrorInfo]) |
| |
| |
|<----------- EAP-Failure -------------------------|
| |
]]>
</artwork>
</figure>
</t>
<t>
<figure anchor="fig-peererror" title="Error notification from peer to server">
<artwork align="center">
<![CDATA[
EAP Peer EAP Server
... ...
| |
|------------ EAP-Response/EAP-NOOB -------------->|
| (Type=0,[PeerId],ErrorCode,[ErrorInfo]) |
| |
| |
|<----------- EAP-Failure -------------------------|
| |
]]>
</artwork>
</figure>
</t>
<section title="Invalid messages" anchor="malformedmessages">
<t>
If the NAI structure is invalid, the server SHOULD send the error code 1001 to the peer. The recipient of an EAP-NOOB request or response SHOULD send the following error codes back to the sender: 1002 if it cannot parse the message as a JSON object or there are missing or unrecognized members in the JSON object; 1003 if a data field has an invalid value, such as an integer out of range; 1004 if the received message type was unexpected; 1005 if the PeerId has an unexpected value; and 1006 if the ECDH key is invalid.
</t>
</section>
<section title="Unwanted peer" anchor="unwantedpeer">
<t>
The preferred way for the EAP server to rate limit EAP-NOOB connections from a peer is to use the MinSleep parameter in the Waiting Exchange. However, if the EAP server receives repeated EAP-NOOB connections from a peer which apparently should not connect to this server, the server MAY indicate that the connections are unwanted by sending the error code 2001. The peer MAY refrain from reconnecting to the same EAP server and, if possible, both the EAP server and peer SHOULD indicate this error condition to the user. However, in order to avoid persistent denial-of-service, the peer is not required to stop entirely from reconnecting to the server.
</t>
</section>
<section title="State mismatch" anchor="statemismatch">
<t>
In the states indicated by "UA" in <xref target="exchangetable"/> in <xref target="exchangeappendix"/>, user action is required to reset the association state or to recover it, for example, from backup storage. In those case, the server sends the error code 2002 to the peer. If possible, both the EAP server and peer SHOULD indicate this error condition to the user.
</t>
</section>
<section title="Negotiation failure" anchor="negotiationfailure">
<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 the server. In practice, there is no way of recovering from these errors without software or hardware changes. If possible, both the EAP server and peer SHOULD indicate these error conditions to the user.
</t>
</section>
<section title="Cryptographic verification failure" anchor="cryptofailure">
<t>
If the EAP server or peer detect an unrecognized PeerId or incorrect fingerprint (Hoob) in the OOB message, the recipient SHOULD indicate the failure to accept the OOB message to the user. The recipient MUST remain in the Waiting for OOB state (1) as if no OOB message was received.
</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 destination. If possible, the peer SHOULD indicate this to the user; however, the peer device may not have capability for many different error indications and it MAY use the same method or error indication as in the case of an incorrect fingerprint.
</t>
<t>
The rationale for the above is that the invalid OOB message could have been presented to the recipient by mistake or intentionally by a malicious party and, thus, it should be ignored in the hope that the honest user will soon deliver a correct OOB message.
</t>
<t>
If the EAP server or peer detects an incorrect message authentication code (MACs, MACp, MACs2, MACp2), it sends the error code 4001 to the other side. If this error occurred in the Completion Exchange, both sides must remain in the old state as if the failed Completion Exchange did not take place. On the other hand, if the error occurred in the Reconnect Exchange, both sides MUST go to the Reconnecting state (3).
</t>
<t>
The rationale for the above is that the invalid cryptographic messages may have been spoofed by a malicious party and, thus, it should be ignored. In particular, a spoofed message on the network 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 software errors. For this reason, the EAP server MAY limit the rate of peer connections after the above error. Also, there MUST be a way for the user to reset the EAP server and peer to the Unregistered state (0), so that the OOB step can be repeated.
</t>
</section>
</section>
</section>
<!-- **************************************************************** -->
<section title="IANA Considerations" anchor="iana">
<t>
This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to the EAP-NOOB protocol, in accordance with <xref target="RFC2434"/>.
</t>
<t>
The EAP Method Type number for EAP-NOOB needs to be assigned.
</t>
<t>
This memo also requires IANA to create new registries as defined in the following subsections.
</t>
<section title="Cryptosuites" anchor="cryptosuites">
<t>
An EAP server MUST supply one or more suggestions for cryptosuites as the Cryptosuites value in the Initial Exchange. They are formatted as a JSON array of the identifier integers. Each suite MUST appear only once in the array. The cryptosuites MUST be supplied in order of priority. Peers MUST supply exactly one suite in the Cryptosuitep value, formatted as an identifier integer. The following suites are defined by EAP-NOOB:
</t>
<texttable title="EAP-NOOB cryptosuites" anchor="cryptosuitetable">
<ttcol>Cryptosuite</ttcol>
<ttcol>Algorithms</ttcol>
<c>1</c><c>Curve25519 <xref target="RFC7748"/>, SHA-256 <xref target="RFC6234"/></c>
</texttable>
<t>
Assignment of new values for new cryptosuites MUST be done through IANA with "Specification Required" and "IESG Approval" as defined in <xref target="RFC2434"/>.
</t>
</section>
<section title="Error codes" anchor="errorcodes">
<t>
The error codes defined by EAP-NOOB are listed in <xref target="errortable"/>.
</t>
<texttable title="EAP-NOOB error codes" anchor="errortable">
<ttcol>Error code</ttcol>
<ttcol>Purpose</ttcol>
<c>1001</c>
<c>Invalid NAI or peer state</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>Unexpected peer identifier</c>
<c>1006</c>
<c>Invalid ECDH key</c>
<c>2001</c>
<c>Unwanted peer</c>
<c>2002</c>
<c>State mismatch, user action required</c>
<c>3001</c>
<c>No mutually supported protocol version</c>
<c>3002</c>
<c>No mutually supported cryptosuite</c>
<c>3003</c>
<c>No mutually supported OOB direction</c>
<c>4001</c>
<c>MAC verification failure</c>
</texttable>
<t>
Assignment of new error codes MUST be done through IANA with "Specification Required" and "IESG Approval" as defined in <xref target="RFC2434"/>.
</t>
</section>
<section title="Domain name reservation considerations" anchor="specialdomainname">
<t>
"eap-noob.net" should be registered as a special-use domain. The considerations required by <xref target="RFC6761"/> for registering this special use domain name are as follows:
<list style="symbols">
<t>Users: Non-admin users are not expected to encounter this name or recognize it as special. AAA administrators may need to recognize the name.</t>
<t>Application Software: Application software is not expected to recognize this domain name as special.</t>
<t>Name Resolution APIs and Libraries: Name resolution APIs and libraries are not expected to recognize this domain name as special.</t>
<t>Caching DNS Servers: Caching servers are not expected to recognize this domain name as special.</t>
<t>Authoritative DNS Servers: Authoritative DNS servers MUST respond to queries for eap-noob.net with NXDOMAIN.</t>
<t>DNS Server Operators: Except for the authoritative DNS server, there are no special requirements for the operators.</t>
<t>DNS Registries/Registrars: There are no special requirements for DNS registrars.</t>
</list>
</t>
</section>
</section>
<!-- **************************************************************** -->
<section title="Security considerations" anchor="securityconsiderations">
<t>
EAP-NOOB is an authentication and key derivation protocol and, thus, security considerations can be found in most sections of this specification. In the following, we explain the protocol design and highlight some other special considerations.
</t>
<section title="Authentication principle" anchor="authenticationprinciple">
<t>
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 ECDH. The message authentication codes computed with the secret nonce Noob are alone sufficient for authenticating the key exchange. The OOB channel might, however, be vulnerable to eavesdropping of the OOB channel, which could lead to compromise of the secret nonce, which will then enable a man-in-the-middle attack on the in-band channel. This is why we include, as a second authentication feature, the integrity-protecting fingerprint Hoob in the OOB message. It is typically more difficult to spoof or alter messages on the human-assisted OOB channel, such as bar code, sound burst or user-transferred URL, than it is to spy on them.
</t>
<t>
The security provided by the cryptographic fingerprint is somewhat intricate to understand. The party that receives the OOB message uses Hoob to verify the integrity of the ECDH exchange. Thus, that party can detect man-in-the-middle attacks on the in-band channel. The other party, 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. Indeed, other device-pairing protocols have solved a similar situation by requiring the user to confirm to the OOB sender that the association was accepted by the OOB-receiver, e.g. by pressing an "accept" button on the sender. Since EAP-NOOB was designed to work strictly with one-directional OOB communication, it does not rely on such input to the OOB sender.
</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 it from the OOB channel. If an attacker is able to eavesdrop the secret nonce and performs a man-in-the-middle attack on in-band channel, the mismatching fingerprint will alert the OOB receiver, which will reject the OOB message. In this case, the association will appear to be complete only on the OOB sender side. The user in many applications will detect this apparently one-sided association because the peer device does not appear registered on the server or network.
</t>
<t>
The expected use cases for EAP-NOOB are ones where it replaces a user-entered access credentials. In wireless network access for IoT devices, the user-entered credential is often a passphrase, which is shared by all the network stations. Like any other EAP-based solution, EAP-NOOB establishes a different master secret for each peer device, which is obviously more resilient to device compromise than a common master secret. Additionally, it is possible to revoke the security association for an individual device on the server side.
</t>
<t>
Forward secrecy in EAP-NOOB is optional. The Reconnect exchange in EAP-NOOB provides forward secrecy only if both the server and peer send their fresh ECDH keys. This allows both the server and the peer to limit the frequency of the costly computation that is required for forward secrecy. The server should make its decision primarily based on what it knows about the peer's computational capabilities.
</t>
</section>
<section title="Identifying and naming peer devices" anchor="deviceidentification">
<t>
EAP-NOOB relies on physical possession or identification of the peer device and secure communication between the user and the server. The main remaining threat against EAP-NOOB is that the attacker performs a man-in-the-middle attack on the in-band channel and, during the protocol execution, tricks the user to deliver the OOB message to or from the wrong peer. The server will now be associated with that wrong peer. Similarly, the attacker could try to trick the user to accessing the wrong server in the OOB step. This reliance on user in identifying the correct parties is an inherent property of out-of-band authentication.
</t>
<t>
One mechanism that can be used to mitigate user mistakes is certification of trusted servers and peer devices. For example, if used together with EAP-NOOB, vendor certificates could prevent accidental association with a rogue peer device. Compared to a fully certificate-based authentication, EAP-NOOB does not depend on trusted third parties and does not require the user to know the identifier of the peer device; physical access is sufficient.
</t>
<t>
The user could also accidentally deliver the OOB message to more than one peer device. This could, for example, occur if the OOB message is a bar code and the peer is a camera: the user could by mistake show the bar code first to the wrong camera. Such accidents in EAP-NOOB will not enable the wrong camera to compute the master key or to opportunistically eavesdrop the communication. This is because the wrong peer device would need to have performed a man-in-the middle attack on the in-band channel before the accident. In comparison, simpler solutions where the master key is transferred to the device via the OOB channel would be vulnerable to opportunistic attacks if the user mistakenly delivers the master key to more than one device.
</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 properties, such as make and model or serial number. A compromised peer could lie about this information in the PeerInfo that 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 rigorous user checking, the PeerInfo is not authenticated information and should not be relied on. Therefore, it is better to include only minimal information about the peer in PeerInfo and to ask the user to name the peer devices. In many applications, such as OOB authentication for ad-hoc wireless network access, it may be unnecessary to store any names for the peer device. Since the user delivering the OOB message will often communicate with the server over an authenticated channel, e.g. logging into a secure web page, the user identity and user-given name can in those cases be reliably stored for the peer device. It is these user identities and user-given names that should be later used for access control and revocation.
</t>
<t>
Another reason to include only minimal information in the PeerInfo is potential privacy issues. The PeerInfo field is typically transmitted in plaintext between the peer and the authenticator. Although the PeerInfo sent by a new, unregistered device will not leak any information specifically about the user, it could reveal device identifiers and information about other device properties, which the user may want to avoid leaking at this point.
</t>
<t>
The PeerId value in the protocol is a server-allocated identifier for its association with the peer and SHOULD NOT be shown to the user 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 server SHOULD assign a random or pseudo-random PeerId to each new peer. It SHOULD NOT select the PeerId based on any peer characteristics that it may know, such as the peer's lower-layer address.
</t>
</section>
<section title="Downgrading threats" anchor="downgrading">
<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 downgrade attacks to weaker cryptosuites 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 cryptanalytic attacks.
</t>
<t>
As an additional precaution, the EAP server and peer SHOULD check for downgrading attacks in the Reconnect Exchange. As long as the server or peer saves any information about the other party, it SHOULD also remember the previously negotiated cryptosuite and not accept renegotiation of any cryptosuite that is known to be weaker than the previous one (e.g. a deprecated cryptosuite or the same ECDH field with a shorter key).
</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, a man-in-the-middle attacker could modify the negotiation messages and thereby cause that direction to be used. Applications that support OOB messages in both directions SHOULD 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 unexpected applications. However, most devices acting as the peer are likely to support only one direction of exchange, in which case interfering with the direction negotiation can only prevent the completion of the protocol.
</t>
</section>
<!--
Another point of comparison for EAP-NOOB is device pairing. For example, the Bluetooth simple pairing. : There the goal is to minimize the number of bits communicated through the OOB channel. These protocols require some kind of user input at both parties, even if just pressing a button to confirm the success. EAP-NOOB cannot achieve the same savings because one of the parties might not have any input interface. (Is this relevant???)
MOVE THIS: Backoff behavior when server does not support the EAP method, or when the server sends failure immediately after the EAP-Response/Identity, or when probing for long periods of time?
However, this authentication can only be achieved in one direction because most practical OOB channels are one-directional. EAP-NOOB therefore transfers a secret nonce over the OOB channel, and it is used in the completion step for authentication in the other direction. While this secret is vulnerable to eavesdropping on the OOB channel, the attacker will need to both perform an in-band man-in-the-middle attack on the Diffie-Hellman key exchange and eavesdrop the OOB secret. Also, a successful attack will not be full man-in-the middle on the secure connection, but instead the peer will think it is connected while the server will indicate failed connection to the user, who probably will reset the peer and try again.
????? Application-level roles are not authenticated!
Could use public signature keys for secure recognition of the same peer.
-->
<section title="EAP security claims" anchor="securityclaims">
<t>
EAP security claims are defined in section 7.2.1 of <xref target="RFC3748"/>. EAP-NOOB makes the following security claims:
</t>
<texttable title="Security claims" anchor="securityclaimstable">
<ttcol>Security property</ttcol>
<ttcol>EAP-NOOB claim</ttcol>
<c></c><c></c>
<c>Authentication mechanism</c>
<c>ECDH key exchange with out-of-band authentication</c>
<c></c><c></c>
<c>Protected cryptosuite negotiation</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>Key derivation</c>
<c>yes</c>
<c></c><c></c>
<c>Key strength</c>
<c>The specified cryptosuites provide key strength of at least 128 bits.</c>
<c></c><c></c>
<c>Dictionary attack protection</c>
<c>not applicable</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 (The largest EAP-NOOB packet is at most TBD bytes long.)</c>
<c></c><c></c>
<c>Channel binding</c>
<c>yes (The ServerInfo and PeerInfo can be used to convey integrity-protected channel properties such as peer MAC address.)</c>
</texttable>
</section>
</section>
<!-- **************************************************************** -->
</middle>
<back>
<!-- **************************************************************** -->
<references title="Normative references">
&RFC1738; <!-- URL -->
&RFC2104; <!-- HMAC -->
&RFC2119; <!-- Terminology -->
&RFC2434; <!-- IANA -->
&RFC3748; <!-- EAP -->
&RFC4648; <!-- Base64 -->
&RFC5216; <!-- EAP-TLS -->
&RFC6234; <!-- SHA-256 -->
&RFC6761; <!-- DNS registration requirements -->
&RFC7159; <!-- JSON -->
&RFC7542; <!-- NAI -->
&RFC7517; <!-- JWK -->
&RFC7748; <!-- Curve25519 -->
<reference anchor="IEEE-802.1X">
<front>
<title>Local and Metropolitan Area Networks: Port-Based Network Access Control</title>
<author>
<organization>Institute of Electrical and Electronics Engineers</organization>
</author>
<date month="December" year="2004" />
</front>
<seriesInfo name=" IEEE Standard 802.1X-2004." value="" />
</reference>
<reference anchor="NIST-DH" target="http://dx.doi.org/10.1145/2632048.2632049">
<front>
<title>Recommendation for Pair-Wise Key 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="D." surname="Johnson" fullname="Don Johnson">
<organization>National Institute of Standards and Technology</organization>
</author>
<author initials="M." surname="Smid" fullname="Miles Smid">
<organization>National Institute of Standards and Technology</organization>
</author>
<date month="March" year="2007" />
</front>
<seriesInfo name="NIST Special Publication 800-56A Revision 1" value="" />
</reference>
</references>
<references title="Informative references">
<reference anchor="Sethi14" target="http://dx.doi.org/10.1145/2632048.2632049">
<front>
<title>Secure Bootstrapping of 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" />
</front>
<seriesInfo name="Proceedings of ACM International Joint Conference on Pervasive and Ubiquitous Computing (UbiComp 2014), pp. 739-750, Seattle, USA" value="" />
</reference>
<reference anchor="SimplePairing">
<front>
<title>Simple pairing whitepaper</title>
<author>
<organization>Bluetooth, SIG</organization>
</author>
<date year="2007" />
</front>
<seriesInfo name=" Technical report" value="" />
</reference>
</references>
<!-- **************************************************************** -->
<section title="Exchanges and events per state" anchor="exchangeappendix">
<t>
<xref target="exchangetable"/> shows how the EAP server chooses the exchange type depending on the server and peer states. The table also indicates other possible events that may lead to a state change. In the fields marked with asterisk (*), the direction of the OOB message is further limited by the negotiated OOB directions (Dirp). Therefore, these OOB events are not always possible. Additionally, user may reset the association state at the EAP server or peer at any time. The fields with "UA" indicate state combinations where user action is required to recover or reset the association state.
</t>
<t>
<figure anchor="exchangetable" title="Exchanges and events possible in each state">
<artwork align="center">
<![CDATA[
+--------+--------------------------+-------------------------------+
| pier state: Unregistered (0) |
+--------+--------------------------+-------------------------------+
| server | possible exchanges | next peer and |
| state | and events | server states |
+--------+--------------------------+-------------------------------+
| 0 | Initial Exchange | both 1 (0 on error) |
| | | |
| 1 | Initial Exchange | both 1 (0 on error) |
| | | |
| 2 | Initial Exchange | both 1 (0 on error) |
| | | |
| 3 | UA | affected side 0 or 3 |
| | | |
| 4 | UA | affected side 0 or 3 |
+--------+--------------------------+-------------------------------+
| pier state: Waiting for OOB (1) |
+--------+--------------------------+-------------------------------+
| 0 | Initial Exchange | both 1 (0 on error) |
| | | |
| 1 | Waiting Exchange | both 1 |
| | OOB from server to peer* | peer 2 (1 on failure) |
| | OOB from peer to server* | server 2 (1 on failure) |
| | | |
| 2 | Completion Exchange | both 4 (no change on failure) |
| | OOB from server to peer* | peer 2 (1 on failure) |
| | | |
| 3 | UA | affected side 0 or 3 |
| | | |
| 4 | UA | affected side 0 or 3 |
+--------+--------------------------+-------------------------------+
| pier state: OOB Received (2) |
+--------+--------------------------+-------------------------------+
| 0 | Initial Exchange | both 1 (0 on error) |
| | | |
| 1 | Completion Exchange | both 4 (no change on failure) |
| | OOB from peer to server* | server 2 (1 on failure) |
| | | |
| 2 | Completion Exchange | both 4 (no change on failure) |
| | | |
| 3 | UA | affected side 0 or 3 |
| | | |
| 4 | UA | affected side 0 or 3 |
+--------+--------------------------+-------------------------------+
| pier state: Reconnecting (3) |
+--------+--------------------------+-------------------------------+
| 0 | UA | affected side 0 or 3 |
| | | |
| 1 | UA | affected side 0 or 3 |
| | | |
| 2 | UA | affected side 0 or 3 |
| | | |
| 3 | Reconnect Exchange | both 4 (3 on failure) |
| | | |
| 4 | Reconnect Exchange | both 4 (3 on failure) |
+--------+--------------------------+-------------------------------+
| pier state: Registered (4) |
+--------+--------------------------+-------------------------------+
| 0 | UA | affected side 0 or 3 |
| | | |
| 1 | UA | affected side 0 or 3 |
| | | |
| 2 | UA | affected side 0 or 3 |
| | | |
| 3 | Reconnect Exchange | both 4 (3 on failure) |
| | | |
| 4 | Timeout/Failure | one or both 3 |
| | UA | affected side 0 or 3 |
+--------+--------------------------+-------------------------------+
]]>
</artwork>
</figure>
</t>
</section>
<section title="TODO list" anchor="todo">
<t>
<list style="symbols">
<t>
Check maximum lengths of all messages to ensure no fragmentation.
</t>
<t>
Update Kms and Kmp in the persistent EAP_NOOb association after ECDH rekeying. This will add to security but is somewhat tricky.
</t>
<t>
Clarify the relation of Unregistered state and no association stored.
</t>
<t>
Consider less disruptive ways for handling protocol errors in state 1, compared to the current solution of returning to state 0.
</t>
<t>
Add examples of all exchanges and messages.
</t>
</list>
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 08:53:20 |