rfc9140xml2.original.xml   rfc9140.xml 
<?xml version="1.0" encoding="us-ascii"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2104 SYSTEM "reference.RFC.2104.xml"> <!DOCTYPE rfc [
<!ENTITY RFC2119 SYSTEM "reference.RFC.2119.xml"> <!ENTITY nbsp "&#160;">
<!ENTITY RFC3748 SYSTEM "reference.RFC.3748.xml"> <!ENTITY zwsp "&#8203;">
<!ENTITY RFC4137 SYSTEM "reference.RFC.4137.xml"> <!ENTITY nbhy "&#8209;">
<!ENTITY RFC3986 SYSTEM "reference.RFC.3986.xml"> <!ENTITY wj "&#8288;">
<!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 "&#10;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
<?rfc strict="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-emu-eap-noob
<?rfc toc="yes"?> -06" number="9140" ipr="trust200902" obsoletes="" updates="" submissionType="IET
<?rfc tocdepth="4"?> F" category="std" consensus="true" xml:lang="en" tocInclude="true" tocDepth="4"
<?rfc symrefs="yes"?> symRefs="true" sortRefs="true" version="3">
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?> <!-- xml2rfc v2v3 conversion 3.9.1 -->
<?rfc subcompact="no"?>
<?rfc rfcedstyle="yes"?>
<rfc category="std" docName="draft-ietf-emu-eap-noob-06" ipr="trust200902">
<front> <front>
<title abbrev="EAP-NOOB">Nimble out-of-band authentication for EAP (EAP-NOOB <title abbrev="EAP-NOOB">Nimble Out-of-Band Authentication for EAP (EAP&nbhy
)</title> ;NOOB)</title>
<seriesInfo name="RFC" value="9140"/>
<author initials="T" surname="Aura" fullname="Tuomas Aura"> <author initials="T" surname="Aura" fullname="Tuomas Aura">
<organization>Aalto University</organization> <organization>Aalto University</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city>Aalto</city> <city>Aalto</city>
<code>00076</code> <code>00076</code>
<country>Finland</country> <country>Finland</country>
</postal> </postal>
<email>tuomas.aura@aalto.fi</email> <email>tuomas.aura@aalto.fi</email>
</address> </address>
</author> </author>
<author initials="M" surname="Sethi" fullname="Mohit Sethi"> <author initials="M" surname="Sethi" fullname="Mohit Sethi">
<organization>Ericsson</organization> <organization>Ericsson</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city>Jorvas</city> <city>Jorvas</city>
<code>02420</code> <code>02420</code>
<country>Finland</country> <country>Finland</country>
</postal> </postal>
<email>mohit@piuha.net</email> <email>mohit@iki.fi</email>
</address> </address>
</author> </author>
<author initials="A" surname="Peltonen" fullname="Aleksi Peltonen"> <author initials="A" surname="Peltonen" fullname="Aleksi Peltonen">
<organization>Aalto University</organization> <organization>Aalto University</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city>Aalto</city> <city>Aalto</city>
<code>00076</code> <code>00076</code>
<country>Finland</country> <country>Finland</country>
</postal> </postal>
<email>aleksi.peltonen@aalto.fi</email> <email>aleksi.peltonen@aalto.fi</email>
</address> </address>
</author> </author>
<date /> <date year="2021" month="December"/>
<area>Security</area> <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> <abstract>
<t> <t>The Extensible Authentication Protocol (EAP) provides support for multi
The Extensible Authentication Protocol (EAP) provides support for multip ple
le authentication methods. This document defines the EAP-NOOB authentication met authentication methods.
hod for nimble out-of-band (OOB) authentication, and key derivation. The EAP met This document defines the EAP-NOOB authentication method for
hod is intended for bootstrapping all kinds of Internet-of-Things (IoT) devices nimble out-of-band (OOB) authentication and key derivation. The EAP method
that have no pre-configured authentication credentials. The method makes use of is intended
a user-assisted one-directional OOB message between the peer device and authenti for bootstrapping all kinds of Internet-of-Things (IoT) devices that have
cation server to authenticate the in-band key exchange. The device must have a n no
on-network input or output interface, such as a display, microphone, speaker, or preconfigured authentication credentials. The method makes use of a user-a
blinking light, which can send or receive dynamically generated messages of ten ssisted,
s of bytes in length. one-directional, out-of-band (OOB) message between the peer device and aut
</t> hentication
server to
authenticate the in-band key exchange. The device must have a nonnetwork i
nput or
output interface, such as a display, microphone, speaker, or blinking ligh
t, that can
send or receive dynamically generated messages of tens of bytes in length.
</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction" numbered="true" toc="default">
<section title="Introduction" anchor="introduction"> <name>Introduction</name>
<t> <t>This document describes a method for registration, authentication, and
This document describes a method for registration, authentication and ke key derivation
y derivation for network-connected smart devices, such as consumer and enterpris for network-connected smart devices, such as consumer and enterprise appli
e appliances that are part of the Internet of Things (IoT). These devices may be ances that are
off-the-shelf hardware that is sold and distributed without any prior registrat part of the Internet of Things (IoT). These devices may be off-the-shelf h
ion or credential-provisioning process, or they may be recycled devices after a ardware that
hard reset. Thus, the device registration in a server database, ownership of the is sold and distributed without any prior registration or credential-provi
device, and the authentication credentials for both network access and applicat sioning
ion-level security must all be established at the time of the device deployment. process, or they may be recycled devices after a hard reset. Thus, the dev
Furthermore, many such devices have only limited user interfaces that could be ice
used for their configuration. Often, the user interfaces are limited to either o registration in a server database, ownership of the device, and the authen
nly input (e.g., camera) or output (e.g., display screen). The device configurat tication
ion is made more challenging by the fact that the devices may exist in large num credentials for both network access and application-level security must al
bers and may have to be deployed or re-configured nimbly based on user needs. l be
</t> established at the time of the device deployment. Furthermore, many such d
<t>To summarize, devices may have the following characteristics: evices have
<list style="symbols"> only limited user interfaces that could be used for their configuration. O
<t>no pre-established relation with the intended server or user, ften, the user
</t> interfaces are limited to either only input (e.g., a camera) or output (e.
<t>no pre-provisioned device identifier or authentication credentials, g., a display
</t> screen). The device configuration is made more challenging by the fact tha
<t>input or output interface that may be capable of only one-direction t the devices
al out-of-band communication. may exist in large numbers and may have to be deployed or reconfigured nim
</t> bly based on
</list> user needs.</t>
</t> <t>To summarize, devices may have the following characteristics:</t>
<t> <ul spacing="normal">
Many proprietary out-of-band (OOB) configuration methods exist for speci <li>no preestablished relation with the intended server or user,</li>
fic IoT devices. The goal of this specification is to provide an open standard a <li>no preprovisioned device identifier or authentication credentials, o
nd a generic protocol for bootstrapping the security of network-connected applia r</li>
nces, such as displays, printers, speakers, and cameras. The security bootstrapp <li>an input or output interface that may be capable of only one-directi
ing in this specification makes use of a user-assisted OOB channel. The device a onal
uthentication relies on a user having physical access to the device, and the key out-of-band communication.</li>
exchange security is based on the assumption that attackers are not able to obs </ul>
erve or modify the messages conveyed through the OOB channel. We follow the comm <t>Many proprietary out-of-band (OOB) configuration methods exist for spec
on approach taken in pairing protocols: performing a Diffie-Hellman key exchange ific IoT
over the insecure network and authenticating the established key with the help devices. The goal of this specification is to provide an open standard and
of the OOB channel in order to prevent impersonation attacks. a generic
</t> protocol for bootstrapping the security of network-connected appliances, s
<t> uch as
The solution presented here is intended for devices that have either a n displays, printers, speakers, and cameras. The security bootstrapping in t
on-network input or output interface, such as a camera, microphone, display scre his
en, speakers or blinking LED light, which is able to send or receive dynamically specification makes use of a user-assisted OOB channel. The device authent
generated messages of tens of bytes in length. Naturally, this solution may not ication relies
be appropriate for very small sensors or actuators that have no user interface on a user having physical access to the device, and the key exchange secur
at all or for devices that are inaccessible to the user. We also assume that the ity is based
OOB channel is at least partly automated (e.g., camera scanning a bar code) and on the assumption that attackers are not able to observe or modify the mes
, thus, there is no need to absolutely minimize the length of the data transferr sages conveyed
ed through the OOB channel. This differs, for example, from Bluetooth pairing <x through the OOB channel. We follow the common approach taken in pairing pr
ref target="BluetoothPairing"/>, where it is essential to minimize the length of otocols:
the manually transferred or compared codes. The OOB messages in this specificat performing a Diffie-Hellman key exchange over the insecure network and aut
ion are dynamically generated. We thus do not support static printed registratio henticating
n codes. One reason for requiring dynamic OOB messages is that the receipt of th the established key with the help of the OOB channel in order to prevent i
e OOB message authorizes the server to take ownership of the device. Dynamic OOB mpersonation
messages are more secure than static printed codes, which could be leaked and l attacks.</t>
ater misused. <t>The solution presented here is intended for devices that have either a
</t> nonnetwork
input or output interface, such as a camera, microphone, display screen, s
peaker, or
blinking Light Emitting Diode (LED) light, that is able to send or receive
dynamically
generated messages of
tens of bytes in length. Naturally, this solution may not be appropriate f
or very small
sensors or actuators that have no user interface at all or for devices tha
t are
inaccessible to the user. We also assume that the OOB channel is at least
partly
automated (e.g., a camera scanning a bar 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 <xref target="Bluetooth" format="default"/
>,
where it is essential to minimize the length of the manually transferred o
r compared
codes. The OOB messages in this specification are dynamically generated. T
hus, we do not
support static printed registration codes. One reason for requiring dynami
c OOB messages
is that the receipt of the OOB message authorizes the server to take owner
ship of the
device. Dynamic OOB messages are more secure than static printed codes, wh
ich could be
leaked and later misused.</t>
</section> </section>
<section anchor="terminology" numbered="true" toc="default">
<section title="Terminology" anchor="terminology"> <name>Terminology</name>
<t> <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHO "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
ULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
be interpreted as described in BCP 14 <xref target='RFC2119'/> <xref target='RF "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
C8174'/> when, and only when, they appear in all capitals, as shown here. "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are t
</t> o be
<t> interpreted as
In addition, this document frequently uses the following terms as they h described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
ave been defined in <xref target="RFC5216"/>: when, and only when, they appear in all capitals, as shown here.</t>
<t>In addition, this document frequently uses the following terms as they
<list style="hanging" hangIndent="6"> have been
<t hangText="authenticator"> defined in <xref target="RFC5216" format="default"/>:</t>
The entity initiating EAP authentication. <dl newline="true" spacing="normal" indent="6">
</t> <dt>authenticator</dt>
<t hangText="peer"> <dd>The entity initiating EAP authentication.</dd>
The entity that responds to the authenticator. In <xref target="IEEE <dt>peer</dt>
-802.1X"/>, this entity is known as the supplicant. (We use the terms peer, devi <dd>The entity that responds to the authenticator. In <xref target="IEEE
ce, and peer device interchangeably.) -802.1X"
</t> format="default"/>, this entity is known as the supplicant. (We use the t
<t hangText="server"> erms peer,
The entity that terminates the EAP authentication method with the pe device, and peer device interchangeably.)</dd>
er. In the case where no backend authentication server is used, the EAP server i <dt>server</dt>
s part of the authenticator. In the case where the authenticator operates in pas <dd>The entity that terminates the EAP authentication method with the pe
s-through mode, the EAP server is located on the backend authentication server. er. In the
</t> case where no backend authentication server is used, the EAP server is pa
</list> rt of the
</t> authenticator. In the case where the authenticator operates in pass-throu
gh mode, the
EAP server is located on the backend authentication server.</dd>
</dl>
</section> </section>
<section anchor="eap-noob" numbered="true" toc="default">
<section title="EAP-NOOB protocol" anchor="eap-noob"> <name>EAP-NOOB Method</name>
<t> <t>This section defines the EAP-NOOB method. The protocol is a generalized
This section defines the EAP-NOOB protocol. The protocol is a generalize version of
d version of the original idea presented by <xref target="Sethi14">Sethi et al.< the original idea presented by <xref target="Sethi14" format="default">Set
/xref>. hi et
</t> al.</xref>.</t>
<section anchor="overview" numbered="true" toc="default">
<name>Protocol Overview</name>
<t>One EAP-NOOB method execution spans two or more EAP conversations, ca
lled
Exchanges in this specification. Each Exchange consists of several EAP
request-response pairs. At least two separate EAP conversations are neede
d to give the
human user time to deliver the OOB message between them.</t>
<section title="Protocol overview" anchor="overview"> <t>The overall protocol starts with the Initial Exchange, which comprise
<t> s four EAP
One EAP-NOOB protocol execution spans two or more EAP conversations, c request-response pairs. In the Initial Exchange, the server allocates an
alled Exchanges in this specification. Each Exchange consists of several EAP req identifier to
uest-response pairs. At least two separate EAP conversations are needed to give the peer, and the server and peer negotiate the protocol version and cryp
the human user time to deliver the OOB message between them. tosuite
</t> (i.e., cryptographic algorithm suite), exchange nonces, and perform an Ep
<t> hemeral
The overall protocol starts with the Initial Exchange, which comprises Elliptic Curve Diffie-Hellman (ECDHE) key exchange. The user-assisted OOB
four EAP request-response pairs. In the Initial Exchange, the server allocates Step then
an identifier to the peer, and the server and peer negotiate the protocol versio takes place. This step requires only one out-of-band message, either from
n and cryptosuite (i.e., cryptographic algorithm suite), exchange nonces and per the peer to
form an Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key exchange. The user-a the server or from the server to the peer. While waiting for the OOB Step
ssisted OOB Step then takes place. This step requires only one out-of-band messa action, the
ge either from the peer to the server or from the server to the peer. While wait peer <bcp14>MAY</bcp14> probe the server by reconnecting to it with EAP-N
ing for the OOB Step action, the peer MAY probe the server by reconnecting to it OOB. If the
with EAP-NOOB. If the OOB Step has already taken place, the probe leads to the OOB Step has already taken place, the probe leads to the Completion Excha
Completion Exchange, which completes the mutual authentication and key confirmat nge, which
ion. On the other hand, if the OOB Step has not yet taken place, the probe leads completes the mutual authentication and key confirmation. On the other ha
to the Waiting Exchange, and the peer will perform another probe after a server nd, if the
-defined minimum waiting time. The Initial Exchange and Waiting Exchange always OOB Step has not yet taken place, the probe leads to the Waiting Exchange
end in EAP-Failure, while the Completion Exchange may result in EAP-Success. Onc , and the
e the peer and server have performed a successful Completion Exchange, both endp peer will perform another probe after a server-defined minimum waiting ti
oints store the created association in persistent storage, and the OOB Step is n me. The
ot repeated. Thereafter, creation of new temporal keys, ECDHE rekeying, and upda Initial Exchange and Waiting Exchange always end in EAP-Failure, while th
tes of cryptographic algorithms can be achieved with the Reconnect Exchange. e Completion
</t> Exchange may result in EAP-Success. Once the peer and server have perform
<t> ed a
<figure anchor="fig-statemachine" title="EAP-NOOB server-peer associat successful Completion Exchange, both endpoints store the created associat
ion state machine" align="center"> ion in
<artwork> persistent storage, and the OOB Step is not repeated. Thereafter, creatio
<![CDATA[ n of new
temporal keys, ECDHE rekeying, and updates of cryptographic algorithms ca
n be achieved
with the Reconnect Exchange.</t>
<figure anchor="fig-statemachine">
<name>EAP-NOOB Server-Peer Association State Machine</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
OOB Output/Initial Exchange/ OOB Output/Initial Exchange/
Waiting Exchange Waiting Exchange
.-----. .-----.
| v | v
.------------------. Initial .------------------. .------------------. Initial .------------------.
| | Exchange | | | | Exchange | |
.->| Unregistered (0) |---------------->|Waiting for OOB(1)| .->| Unregistered (0) |---------------->|Waiting for OOB(1)|
| | (ephemeral) | | (ephemeral) | | | (ephemeral) | | (ephemeral) |
| | | | | | | | | |
| '------------------' '------------------' | '------------------' '------------------'
skipping to change at line 174 skipping to change at line 222
| Timeout/ Reconnect | Timeout/ Reconnect
| Failure Exchange | Failure Exchange
| | | | | |
| v | | v |
| .------------------. | .------------------.
| | | | | |
'--| Reconnecting (3) | '--| Reconnecting (3) |
| (persistent) | | (persistent) |
| | | |
'------------------' '------------------'
]]> ]]></artwork>
</artwork> </figure>
</figure> <t><xref target="fig-statemachine" format="default"/> shows the associat
</t> ion state
<t> machine, which is the same for the server and for the peer. (For readabil
<xref target="fig-statemachine"/> shows the association state machine, ity, only the
which is the same for the server and for the peer. (For readability, only the m main state transitions are shown. The complete table of transitions can b
ain state transitions are shown. The complete table of transitions can be found e found in
in <xref target="exchangeappendix"/>.) When the peer initiates the EAP-NOOB meth <xref target="exchangeappendix" format="default"/>.) When the peer initia
od, the server chooses the ensuing message exchange based on the combination of tes the
the server and peer states. The EAP server and peer are initially in the Unregis EAP-NOOB method, the server chooses the ensuing message exchange based on
tered state, in which no state information needs to be stored. Before a successf the
ul Completion Exchange, the server-peer association state is ephemeral in both t combination of the server and peer states. The EAP server and peer are in
he server and peer (ephemeral states 0..2), and a timeout or error may cause one itially in
or both endpoints to go back to the Unregistered state so that the Initial Exch the Unregistered (0) state, in which no state information needs to be sto
ange is repeated. After the Completion Exchange has resulted in EAP-Success, the red. Before a
association state becomes persistent (persistent states 3..4). Only user reset successful Completion Exchange, the server-peer association state is ephe
or memory failure can cause the return of the server or the peer from the persis meral in both
tent states to the ephemeral states and to the Initial Exchange. the server and peer (ephemeral states 0..2), and a timeout or error may c
</t> ause one or
<t> both endpoints to go back to the Unregistered (0) state so that the Initi
The server MUST NOT repeat a successful OOB Step with the same peer ex al Exchange
cept if the association with the peer is explicitly reset by the user or lost du is
e to failure of the persistent storage in the server. More specifically, once th repeated. After the Completion Exchange has resulted in EAP-Success, the
e association has entered the Registered state, the server MUST NOT delete the a association
ssociation or go back to the ephemeral states 0..2 without explicit user approva state becomes persistent (persistent states 3..4). Only user reset or mem
l. Similarly, the peer MUST NOT repeat the OOB Step unless the user explicitly d ory failure
eletes from the peer the association with the server or resets the peer to the U can cause the return of the server or the peer from the persistent states
nregistered state. The server and peer MAY implement user reset of the associati to the
on by deleting the state data from that endpoint. If an endpoint continues to st ephemeral states and to the Initial Exchange.</t>
ore data about the association after the user reset, its behavior MUST be equiva <t>The server <bcp14>MUST NOT</bcp14> repeat a successful OOB Step with
lent to having deleted the association data. the same peer
</t> except if the association with the peer is explicitly reset by the user o
<t> r lost due to
It can happen that the peer accidentally or through user reset loses i failure of the persistent storage in the server. More specifically, once
ts persistent state and reconnects to the server without a previously allocated the
peer identifier. In that case, the server MUST treat the peer as a new peer. The association has entered the Registered (4) state, the server <bcp14>MUST
server MAY use auxiliary information, such as the PeerInfo field received in th NOT</bcp14>
e Initial Exchange, to detect multiple associations with the same peer. However, delete the association or go back to the ephemeral states 0..2 without ex
it MUST NOT delete or merge redundant associations without user or application plicit user
approval because EAP-NOOB internally has no secure way of verifying that the two approval. Similarly, the peer <bcp14>MUST NOT</bcp14> repeat the OOB Step
peers are the same physical device. Similarly, the server might lose the associ unless the
ation state because of a memory failure or user reset. In that case, the only wa user explicitly deletes the association with the server from the peer or
y to recover is that the user also resets the peer. resets the
</t> peer to the Unregistered (0) state. The server and peer <bcp14>MAY</bcp14
<t> > implement
A special feature of the EAP-NOOB method is that the server is not ass user
umed to have any a-priori knowledge of the peer. Therefore, the peer initially u reset of the association by deleting the state data from that endpoint. I
ses the generic identity string "noob@eap-noob.arpa" as its network access ident f an endpoint
ifier (NAI). The server then allocates a server-specific identifier to the peer. continues to store data about the association after the user reset, its b
The generic NAI serves two purposes: firstly, it tells the server that the peer ehavior
supports and expects the EAP-NOOB method and, secondly, it allows routing of th <bcp14>MUST</bcp14> be equivalent to having deleted the association data.
e EAP-NOOB sessions to a specific authentication server in an Authentication, Au </t>
thorization and Accounting (AAA) architecture. <t>It can happen that the peer accidentally (or through user reset) lose
</t> s its
<t> persistent
EAP-NOOB is an unusual EAP method in that the peer has to have multipl state and reconnects to the server without a previously allocated peer id
e EAP conversations with the server before it can receive EAP-Success. The reaso entifier. In
n is that, while EAP allows delays between the request-response pairs, e.g., for that case, the server <bcp14>MUST</bcp14> treat the peer as a new peer. T
repeated password entry, the user delays in OOB authentication can be much long he server
er than in password trials. Moreover, EAP-NOOB supports peers with no input capa <bcp14>MAY</bcp14> use auxiliary information, such as the PeerInfo field
bility in the user interface (e.g., LED light bulbs). Since users cannot initiat received in
e the protocol in these devices, the devices have to perform the Initial Exchang the Initial Exchange, to detect multiple associations with the same peer.
e opportunistically and hope for the OOB Step to take place within a timeout per However, it
iod (NoobTimeout), which is why the timeout needs to be several minutes rather t <bcp14>MUST NOT</bcp14> delete or merge redundant associations without us
han seconds. To support such high-latency OOB channels, the peer and server perf er or
orm the Initial Exchange in one EAP conversation, then allow time for the OOB me application approval because EAP-NOOB internally has no secure way of ver
ssage to be delivered, and later perform the Waiting and Completion Exchanges in ifying that
different EAP conversations. the two peers are the same physical device. Similarly, the server might l
</t> ose 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 the peer.</t>
<t>A special feature of the EAP-NOOB method is that the server is not as
sumed to have
any a priori knowledge of the peer. Therefore, the peer initially uses th
e generic
identity string "noob@eap-noob.arpa" as its Network Access Identifier (NA
I). The
server then allocates a server-specific identifier to the peer. The gener
ic NAI serves
two purposes: firstly, it tells the server that the peer supports and exp
ects the
EAP-NOOB method; secondly, it allows routing of the EAP-NOOB sessions to
a
specific authentication server in an Authentication, Authorization, and A
ccounting
(AAA) architecture.</t>
<t>EAP-NOOB is an unusual EAP method in that the peer has to have multip
le EAP
conversations with the server before it can receive EAP-Success. The reas
on is that,
while EAP allows delays between the request-response pairs, e.g., for rep
eated
password entry, the user delays in OOB authentication can be much longer
than in
password trials. Moreover, EAP-NOOB supports peers with no input capabili
ty in the
user interface (e.g., LED light bulbs). Since users cannot initiate the p
rotocol in
these devices, the devices have to perform the Initial Exchange opportuni
stically 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 suppo
rt such
high-latency OOB channels, the peer and server perform the Initial Exchan
ge in one EAP
conversation, then allow time for the OOB message to be delivered, and la
ter perform
the Waiting Exchange and Completion Exchange in different EAP conversatio
ns.</t>
</section> </section>
<section anchor="protocol" numbered="true" toc="default">
<section title="Protocol messages and sequences" anchor="protocol"> <name>Protocol Messages and Sequences</name>
<t> <t>This section defines the EAP-NOOB exchanges, which correspond to EAP
This section defines the EAP-NOOB exchanges, which correspond to EAP c conversations.
onversations. The exchanges start with a common handshake, which determines the The exchanges start with a common handshake, which determines the type of
type of the following exchange. The common handshake messages and the subsequent the
messages for each exchange type are listed in the diagrams below. The diagrams following exchange. The common handshake messages and the subsequent mess
also specify the data fields present in each message. Each exchange comprises mu ages for each
ltiple EAP request-response pairs and ends in either EAP-Failure, indicating tha exchange type are listed in the diagrams below. The diagrams also specify
t authentication is not (yet) successful, or in EAP-Success. the data
</t> fields present in each message. Each exchange comprises multiple EAP requ
est-response
<section title="Common handshake in all EAP-NOOB exchanges" anchor="comm pairs and ends in either EAP-Failure, indicating that authentication is n
onhandshake"> ot (yet)
<t> successful, or in EAP-Success.</t>
All EAP-NOOB exchanges start with common handshake messages. The han <section anchor="commonhandshake" numbered="true" toc="default">
dshake begins with the identity request and response that are common to all EAP <name>Common Handshake in All EAP-NOOB Exchanges</name>
methods. Their purpose is to enable the AAA architecture to route the EAP conver <t>All EAP-NOOB exchanges start with common handshake messages. The ha
sation to the EAP server and to enable the EAP server to select the EAP method. ndshake begins
The handshake then continues with one EAP-NOOB request-response pair in which th with the identity request and response that are common to all EAP metho
e server discovers the peer identifier used in EAP-NOOB and the peer state. ds. Their
</t> purpose is to enable the AAA architecture to route the EAP conversation
<t> to the EAP
In more detail, each EAP-NOOB exchange begins with the authenticator server and to enable the EAP server to select the EAP method. The hands
sending an EAP-Request/Identity packet to the peer. From this point on, the EAP hake then
conversation occurs between the server and the peer, and the authenticator acts continues with one EAP-NOOB request-response pair in which the server d
as a pass-through device. The peer responds to the authenticator with an EAP-Re iscovers the
sponse/Identity packet, which contains the network access identifier (NAI). The peer identifier used in EAP-NOOB and the peer state.</t>
authenticator, acting as a pass-through device, forwards this response and the f <t>In more detail, each EAP-NOOB exchange begins with the authenticato
ollowing EAP conversation between the peer and the AAA architecture. The AAA arc r sending an
hitecture routes the conversation to a specific AAA server (called "EAP server" EAP-Request/Identity packet to the peer. From this point on, the EAP co
or simply "server" in this specification) based on the realm part of the NAI. Th nversation
e server selects the EAP-NOOB method based on the user part of the NAI, as defin occurs between the server and the peer, and the authenticator acts as a
ed in <xref target="nai"/>. pass-through
</t> device. The peer responds to the authenticator with an EAP-Response/Ide
<t> ntity packet,
After receiving the EAP-Response/Identity message, the server sends which contains the Network Access Identifier (NAI). The authenticator,
the first EAP-NOOB request (Type=1) to the peer, which responds with the peer id acting as a
entifier (PeerId) and state (PeerState) in the range 0..3. However, the peer SHO pass-through device, forwards this response and the following EAP conve
ULD omit the PeerId from the response (Type=1) when PeerState=0. The server then rsation
chooses the EAP-NOOB exchange, i.e., the ensuing message sequence, as explained between the peer and the AAA architecture. The AAA architecture routes
below. The peer recognizes the exchange based on the message type field (Type) the
of the next EAP-NOOB request received from the server. conversation to a specific AAA server (called "EAP server" or simply "s
</t> erver" in
<t> this specification) based on the realm part of the NAI. The server sele
The server MUST determine the exchange type based on the combination cts the
of the peer and server states as follows (also summarized in <xref target="tabl EAP-NOOB method based on the user part of the NAI, as defined in <xref
e-exchanges"/>). If either the peer or server is in the Unregistered (0) state a target="nai"
nd the other is in one of the ephemeral states (0..2), the server chooses the In format="default"/>.</t>
itial Exchange. If one of the peer or server is in the OOB Received (2) state an <t>After receiving the EAP-Response/Identity message, the server sends
d the other is either in the Waiting for OOB (1) or OOB Received (2) state, the the first
OOB Step has taken place and the server chooses the Completion Exchange. If both EAP-NOOB request (Type=1) to the peer, which responds with the peer ide
the server and peer are in the Waiting for OOB (1) state, the server chooses th ntifier
e Waiting Exchange. If the peer is in the Reconnecting (3) state and the server (PeerId) and state (PeerState) in the range 0..3. However, the peer
is in the Registered (4) or Reconnecting (3) state, the server chooses the Recon <bcp14>SHOULD</bcp14> omit the PeerId from the response (Type=1) when P
nect Exchange. All other state combinations are error situations where user acti eerState=0.
on is required, and the server SHOULD indicate such errors to the peer with the The server then chooses the EAP-NOOB exchange, i.e., the ensuing messag
error code 2002 (see <xref target="statemismatch"/>). Note also that the peer MU e sequence,
ST NOT initiate EAP-NOOB when the peer is in the Registered (4) state. as explained below. The peer recognizes the exchange based on the messa
</t> ge type field
<t> (Type) of the next EAP-NOOB request received from the server.</t>
<figure anchor="fig-commonhandshake" title="Common handshake in all <t>The server <bcp14>MUST</bcp14> determine the exchange type based on
EAP-NOOB exchanges"> the
<artwork align="center"> combination of the peer and server states as follows (also summarized i
<![CDATA[ n <xref
target="tab-exchanges" format="default"/>). If either the peer or serve
r is in the
Unregistered (0) state and the other is in one of the ephemeral states
(0..2), the
server chooses the Initial Exchange. If either the peer or server is in
the OOB
Received (2) state and the other is either in the Waiting for OOB (1) o
r 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 R
econnecting
(3) state and the server is in the Registered (4) or Reconnecting (3) s
tate, the
server chooses the Reconnect Exchange. All other state combinations are
error
situations where user action is required, and the server <bcp14>SHOULD<
/bcp14>
indicate such errors to the peer with the error code 2002 (see <xref
target="statemismatch" format="default"/>). Note also that the peer <bc
p14>MUST
NOT</bcp14> initiate EAP-NOOB when the peer is in the Registered (4) st
ate.</t>
<figure anchor="fig-commonhandshake">
<name>Common Handshake in All EAP-NOOB Exchanges</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
EAP Peer Authenticator EAP Server EAP Peer Authenticator EAP Server
| | | | | |
|<----------- EAP-Request/Identity -| | |<----------- EAP-Request/Identity -| |
| | | |
| | | |
|------------ EAP-Response/Identity -------------->| |------------ EAP-Response/Identity -------------->|
| (NAI=noob@eap-noob.arpa) | | (NAI=noob@eap-noob.arpa) |
| | | |
| | | |
|<----------- EAP-Request/EAP-NOOB ----------------| |<----------- EAP-Request/EAP-NOOB ----------------|
| (Type=1) | | (Type=1) |
| | | |
| | | |
|------------ EAP-Response/EAP-NOOB -------------->| |------------ EAP-Response/EAP-NOOB -------------->|
| (Type=1,[PeerId],PeerState=1) | | (Type=1,[PeerId],PeerState=1) |
| | | |
| continuing with exchange-specific messages... | | continuing with exchange-specific messages... |
]]> ]]></artwork>
</artwork> </figure>
</figure>
</t>
</section> </section>
<section anchor="initialexchange" numbered="true" toc="default">
<section title="Initial Exchange" anchor="initialexchange"> <name>Initial Exchange</name>
<t> <t>The Initial Exchange comprises the common handshake and two further
The Initial Exchange comprises the common handshake and two further EAP-NOOB
EAP-NOOB request-response pairs, one for version, cryptosuite and parameter nego request-response pairs: one for version, cryptosuite, and parameter neg
tiation and the other for the ECDHE key exchange. The first EAP-NOOB request (Ty otiation and
pe=2) from the server contains a newly allocated PeerId for the peer and an opti the other for the ECDHE key exchange. The first EAP-NOOB request (Type=
onal NewNAI for assigning a new NAI to the peer. The server allocates a new Peer 2) from the
Id in the Initial Exchange regardless of any old PeerId received in the previous server contains a newly allocated PeerId for the peer and an optional N
response (Type=1). The server also sends in the request a list of the protocol ewNAI for
versions (Vers) and cryptosuites (Cryptosuites) it supports, an indicator of the assigning a new NAI to the peer. The server allocates a new PeerId in t
OOB channel directions it supports (Dirs), and a ServerInfo object. The peer ch he Initial
ooses one of the versions and cryptosuites. The peer sends a response (Type=2) w Exchange regardless of any old PeerId received in the previous response
ith the selected protocol version (Verp), the received PeerId, the selected cryp (Type=1).
tosuite (Cryptosuitep), an indicator of the OOB channel direction(s) selected by The server also sends in the request a list of the protocol versions (V
the peer (Dirp), and a PeerInfo object. In the second EAP-NOOB request and resp ers) and
onse (Type=3), the server and peer exchange the public components of their ECDHE cryptosuites (Cryptosuites) it supports, an indicator of the OOB channe
keys and nonces (PKs,Ns,PKp,Np). The ECDHE keys MUST be based on the negotiated l directions
cryptosuite, i.e., Cryptosuitep. The Initial Exchange always ends with EAP-Fail it supports (Dirs), and a ServerInfo object. The peer chooses one of th
ure from the server because the authentication cannot yet be completed. e versions
</t> and cryptosuites. The peer sends a response (Type=2) with the selected
<t> protocol
<figure anchor="fig-initial" title="Initial Exchange"> version (Verp), the received PeerId, the selected cryptosuite (Cryptosu
<artwork align="center"> itep), an
<![CDATA[ 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, and Np). The ECDHE keys <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 be completed.</t>
<figure anchor="fig-initial">
<name>Initial Exchange</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
EAP Peer EAP Server EAP Peer EAP Server
| ...continuing from common handshake | | ...continuing from common handshake |
| | | |
|<----------- EAP-Request/EAP-NOOB ----------------| |<----------- EAP-Request/EAP-NOOB ----------------|
| (Type=2,Vers,PeerId,[NewNAI], | | (Type=2,Vers,PeerId,[NewNAI], |
| Cryptosuites,Dirs,ServerInfo) | | Cryptosuites,Dirs,ServerInfo) |
| | | |
| | | |
|------------ EAP-Response/EAP-NOOB -------------->| |------------ EAP-Response/EAP-NOOB -------------->|
| (Type=2,Verp,PeerId,Cryptosuitep, | | (Type=2,Verp,PeerId,Cryptosuitep, |
skipping to change at line 271 skipping to change at line 402
|<----------- EAP-Request/EAP-NOOB ----------------| |<----------- EAP-Request/EAP-NOOB ----------------|
| (Type=3,PeerId,PKs,Ns,[SleepTime]) | | (Type=3,PeerId,PKs,Ns,[SleepTime]) |
| | | |
| | | |
|------------ EAP-Response/EAP-NOOB -------------->| |------------ EAP-Response/EAP-NOOB -------------->|
| (Type=3,PeerId,PKp,Np) | | (Type=3,PeerId,PKp,Np) |
| | | |
| | | |
|<----------- EAP-Failure -------------------------| |<----------- EAP-Failure -------------------------|
| | | |
]]> ]]></artwork>
</artwork> </figure>
</figure> <t>At the conclusion of the Initial Exchange, both the server and the
</t> peer move to
<t> the Waiting for OOB (1) state.</t>
At the conclusion of the Initial Exchange, both the server and the p
eer move to the Waiting for OOB (1) state.
</t>
</section> </section>
<section anchor="oobstep" numbered="true" toc="default">
<section title="OOB Step" anchor="oobstep"> <name>OOB Step</name>
<t> <t>The OOB Step, labeled as OOB Output and OOB Input in <xref
The OOB Step, labeled as OOB Output and OOB Input in <xref target="f target="fig-statemachine" format="default"/>, takes place after the Ini
ig-statemachine"/>, takes place after the Initial Exchange. Depending on the neg tial
otiated OOB channel direction, the peer or the server outputs the OOB message as Exchange. Depending on the negotiated OOB channel direction, the peer o
shown in <xref target="fig-oob1"/> or <xref target="fig-oob2"/>, respectively. r the server
The data fields are the PeerId, the secret nonce Noob, and the cryptographic fin outputs the OOB message as shown in Figures <xref target="fig-oob1"
gerprint Hoob. The contents of the data fields are defined in <xref target="mess format="counter"/> or
agedatafields"/>. The OOB message is delivered to the other endpoint via a user- <xref target="fig-oob2" format="counter"/>, respectively. The data fiel
assisted OOB channel. ds are the
</t> PeerId, the secret nonce Noob, and the cryptographic fingerprint Hoob.
<t> The contents
For brevity, we will use the terms OOB sender and OOB receiver in ad of the data fields are defined in <xref target="messagedatafields"
dition to the already familiar EAP server and EAP peer. If the OOB message is se format="default"/>. The OOB message is delivered to the other endpoint
nt in the server-to-peer direction, the OOB sender is the server and the OOB rec via a
eiver is the peer. On the other hand, if the OOB message is sent in the peer-to- user-assisted OOB channel.</t>
server direction, the OOB sender is the peer and the OOB receiver is the server. <t>For brevity, we will use the terms OOB sender and OOB receiver in a
</t> ddition to the
<t> already familiar EAP server and EAP peer. If the OOB message is sent in
<figure anchor="fig-oob1" title="OOB Step, from peer to EAP server"> the
<artwork align="center"> server-to-peer direction, the OOB sender is the server and the OOB rece
<![CDATA[ iver is the
peer. On the other hand, if the OOB message is sent in the peer-to-serv
er direction,
the OOB sender is the peer and the OOB receiver is the server.</t>
<figure anchor="fig-oob1">
<name>OOB Step, from Peer to EAP Server</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
EAP Peer EAP Server EAP Peer EAP Server
| | | |
|=================OOB=============================>| |=================OOB=============================>|
| (PeerId,Noob,Hoob) | | (PeerId,Noob,Hoob) |
| | | |
]]> ]]></artwork>
</artwork> </figure>
</figure>
<figure anchor="fig-oob2" title="OOB Step, from EAP server to peer"> <figure anchor="fig-oob2">
<artwork align="center"> <name>OOB Step, from EAP Server to Peer</name>
<![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
EAP Peer EAP Server EAP Peer EAP Server
| | | |
|<================OOB==============================| |<================OOB==============================|
| (PeerId,Noob,Hoob) | | (PeerId,Noob,Hoob) |
| | | |
]]> ]]></artwork>
</artwork> </figure>
</figure> <t>The OOB receiver <bcp14>MUST</bcp14> compare the received value of
</t> the
<t> fingerprint Hoob (see <xref target="messagedatafields" format="default"
The OOB receiver MUST compare the received value of the fingerprint />) with a
Hoob (see <xref target="messagedatafields"/>) with a value that it computed loca value that it computed locally for the PeerID received. This integrity
lly for the PeerID received. This integrity check ensures that the endpoints agr check ensures
ee on contents of the Initial Exchange. If the values are equal, the receiver mo that the endpoints agree on contents of the Initial Exchange. If the va
ves to the OOB Received (2) state. Otherwise, the receiver MUST reject the OOB m lues are
essage. For usability reasons, the OOB receiver SHOULD indicate the acceptance o equal, the receiver moves to the OOB Received (2) state. Otherwise, the
r rejection of the OOB message to the user. The receiver SHOULD reject invalid O receiver
OB messages without changing its state in the association state machine, until a <bcp14>MUST</bcp14> reject the OOB message. For usability reasons, the
n application-specific number of invalid messages (OobRetries) has been reached, OOB receiver
after which the receiver SHOULD consider it an error and go back to the Unregis <bcp14>SHOULD</bcp14> indicate the acceptance or rejection of the OOB m
tered (0) state. essage to the
</t> user. The receiver <bcp14>SHOULD</bcp14> reject invalid OOB messages wi
<t> thout
The server or peer MAY send multiple OOB messages with different Noo changing its state in the association state machine until an applicatio
b values while in the Waiting for OOB (1) state. The OOB sender SHOULD remember n-specific
the Noob values until they expire and accept any one of them in the following Co number of invalid messages (OobRetries) has been reached; after which,
mpletion Exchange. The Noob values sent by the server expire after an applicatio the receiver
n-dependent timeout (NoobTimeout), and the server MUST NOT accept Noob values ol <bcp14>SHOULD</bcp14> consider it an error and go back to the Unregiste
der than that in the Completion Exchange. The RECOMMENDED value for NoobTimeout red (0)
is 3600 seconds if there are no application-specific reasons for making it short state.</t>
er or longer. The Noob values sent by the peer expire as defined in <xref target <t>The server or peer <bcp14>MAY</bcp14> send multiple OOB messages wi
="waitingexchange"/>. th different
</t> Noob values while in the Waiting for OOB (1) state. The OOB sender
<t> <bcp14>SHOULD</bcp14> remember the Noob values until they expire and ac
The OOB receiver does not accept further OOB messages after it has a cept any one
ccepted one and moved to the OOB Received (2) state. However, the receiver MAY b of them in the following Completion Exchange. The Noob values sent by t
uffer redundant OOB messages in case an OOB message expiry or similar error dete he server
cted in the Completion Exchange causes it to return to the Waiting for OOB (1) s expire after an application-dependent timeout (NoobTimeout), and the se
tate. It is RECOMMENDED that the OOB receiver notifies the user about redundant rver
OOB messages, but it MAY instead discard them silently. <bcp14>MUST NOT</bcp14> accept Noob values older than that in the Compl
</t> etion
<t> Exchange. The <bcp14>RECOMMENDED</bcp14> value for NoobTimeout is 3600
The sender will typically generate a new Noob, and therefore a new O seconds if
OB message, at constant time intervals (NoobInterval). The RECOMMENDED interval there are no application-specific reasons for making it shorter or long
is NoobInterval = NoobTimeout / 2, in which case the receiver of the OOB will at er. The Noob
any given time accept either of the two latest Noob values. However, the timing values sent by the peer expire, as defined in <xref target="waitingexch
of the Noob generation may also be based on user interaction or on implementati ange"
on considerations. format="default"/>.</t>
</t> <t>The OOB receiver does not accept further OOB messages after it has
<t> accepted one
Even though not recommended (see <xref target="datafields"/>), this and moved to the OOB Received (2) state. However, the receiver <bcp14>M
specification allows both directions to be negotiated (Dirp=3) for the OOB chann AY</bcp14>
el. In that case, both sides SHOULD output the OOB message, and it is up to the buffer redundant OOB messages in case an OOB message expiry or similar
user to deliver at least one of them. error
</t> detected in the Completion Exchange causes it to return to the Waiting
<t> for OOB (1)
The details of the OOB channel implementation including the message state. It is <bcp14>RECOMMENDED</bcp14> that the OOB receiver notifies
encoding are defined by the application. <xref target="urloob"/> gives an exampl the user
e of how the OOB message can be encoded as a URL that may be embedded in a dynam about redundant OOB messages, but it <bcp14>MAY</bcp14> instead discard
ic QR code or NFC tag. them
</t> silently.</t>
<t>The sender will typically generate a new Noob, and therefore a new
OOB message,
at constant time intervals (NoobInterval). The <bcp14>RECOMMENDED</bcp1
4> interval
is</t>
<t indent="3">NoobInterval = NoobTimeout / 2</t>
<t>in which case, 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
implementation considerations.</t>
<t>Even though not recommended (see <xref target="datafields" format="
default"/>),
this specification allows both directions to be negotiated (Dirp=3) for
the OOB
channel. In that case, both sides <bcp14>SHOULD</bcp14> output the OOB
message, and
it is up to the user to deliver at least one of them.</t>
<t>The details of the OOB channel implementation including the message
encoding are
defined by the application. <xref target="urloob" format="default"/> gi
ves an
example of how the OOB message can be encoded as a URL that may be embe
dded in a
dynamic QR code or NFC (Near Field Communication) tag.</t>
</section> </section>
<section anchor="completionexchange" numbered="true" toc="default">
<section title="Completion Exchange" anchor="completionexchange"> <name>Completion Exchange</name>
<t> <t>After the Initial Exchange, if the OOB channel directions selected
After the Initial Exchange, if the OOB channel directions selected b by the peer
y the peer include the peer-to-server direction, the peer SHOULD initiate the EA include the peer-to-server direction, the peer <bcp14>SHOULD</bcp14> in
P-NOOB method again after an applications-specific waiting time in order to prob itiate the
e for completion of the OOB Step. If the OOB channel directions selected by the EAP-NOOB method again after an applications-specific waiting time in or
peer include the server-to-peer direction and the peer receives the OOB message, der to probe
it SHOULD initiate the EAP-NOOB method immediately. Depending on the combinatio for completion of the OOB Step. If the OOB channel directions selected
n of the peer and server states, the server continues with the Completion Exchan by the peer
ge or Waiting Exchange (see <xref target="commonhandshake"/> on how the server m include the server-to-peer direction and the peer receives the OOB mess
akes this decision). age, it
</t> <bcp14>SHOULD</bcp14> initiate the EAP-NOOB method immediately. Dependi
<t> ng on the
The Completion Exchange comprises the common handshake and one or tw combination of the peer and server states, the server continues with th
o further EAP-NOOB request-response pairs. If the peer is in the Waiting for OOB e Completion
(1) state, the OOB message has been sent in the peer-to-server direction. In th Exchange or Waiting Exchange (see <xref target="commonhandshake" format
at case, only one request-response pair (Type=6) takes place. In the request, th ="default"/>
e server sends the NoobId value (see <xref target="messagedatafields"/>), which on how the server makes this decision).</t>
the peer uses to identify the exact OOB message received by the server. On the o <t>The Completion Exchange comprises the common handshake and one or t
ther hand, if the peer is in the OOB Received (2) state, the direction of the OO wo further
B message is from server to peer. In this case, two request-response pairs (Type EAP-NOOB request-response pairs. If the peer is in the Waiting for OOB
=5 and Type=6) are needed. The purpose of the first request-response pair (Type= (1) state,
5) is that it enables the server to discover NoobId, which identifies the exact the OOB message has been sent in the peer-to-server direction. In that
OOB message received by the peer. The server returns the same NoobId to the peer case, only
in the latter request. one request-response pair (Type=6) takes place. In the request, the ser
</t> ver sends the
<t> NoobId value (see <xref target="messagedatafields" format="default"/>),
In the last request-response pair (Type=6) of the Completion Exchang which the
e, the server and peer exchange message authentication codes. Both sides MUST co peer uses to identify the exact OOB message received by the server. On
mpute the keys Kms and Kmp as defined in <xref target="keyderivation"/> and the the other
message authentication codes MACs and MACp as defined in <xref target="messageda hand, if the peer is in the OOB Received (2) state, the direction of th
tafields"/>. Both sides MUST compare the received message authentication code wi e OOB message
th a locally computed value. If the peer finds that it has received the correct is from server to peer. In this case, two request-response pairs (Type=
value of MACs and the server finds that it has received the correct value of MAC 5 and Type=6)
p, the Completion Exchange ends in EAP-Success. Otherwise, the endpoint where th are needed. The purpose of the first request-response pair (Type=5) is
e comparison fails indicates this with an error message (error code 4001, see <x that it
ref target="invalidmessages"/>) and the Completion Exchange ends in EAP-Failure. enables the server to discover NoobId, which identifies the exact OOB m
</t> essage
<t> received by the peer. The server returns the same NoobId to the peer in
After successful Completion Exchange, both the server and the peer m the latter
ove to the Registered (4) state. They also derive the output keying material and request.</t>
store the persistent EAP-NOOB association state as defined in <xref target="fas <t>In the last request-response pair (Type=6) of the Completion Exchan
treconnect"/> and <xref target="keyderivation"/>. ge, the server
</t> and peer exchange message authentication codes. Both sides <bcp14>MUST<
<t> /bcp14>
It is possible that the OOB message expires before it is received. I compute the keys Kms and Kmp, as defined in <xref target="keyderivation
n 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 format="default"/>, and the message authentication codes MACs and MACp,
not recognize the NoobId is if the received OOB message was spoofed and containe as defined
d an attacker-generated Noob value. The recipient of an unrecognized NoobId indi in <xref target="messagedatafields" format="default"/>. Both sides
cates this with an error message (error code 2003, see <xref target="invalidmess <bcp14>MUST</bcp14>
ages"/>), and the Completion Exchange ends in EAP-Failure. The recipient of the compare the received message authentication code with a locally compute
error message 2003 moves back to the Waiting for OOB (1) state. This state trans d value. If
ition is called OOB Reject in <xref target="fig-statemachine"/> (even though it the peer finds that it has received the correct value of MACs and the s
really is a specific type of failed Completion Exchange). The sender of the erro erver finds
r message, on the other hand, stays in its previous state. that it has received the correct value of MACp, the Completion Exchange
</t> ends in
<t> EAP-Success.
Although it is not expected to occur in practice, poor user interfac Otherwise, the endpoint where the comparison fails indicates this with
e design could lead to two OOB messages delivered simultaneously, one from the p an error message (error code 4001, see <xref target="cryptofailure"
eer to the server and the other from the server to the peer. The server detects format="default"/>), and the Completion Exchange ends in EAP-Failure.</
this event in the beginning of the Completion Exchange by observing that both th t>
e server and peer are in the OOB Received state (2). In that case, as a tiebreak <t>After the successful Completion Exchange, both the server and the p
er, the server MUST behave as if only the server-to-peer message had been delive eer move to
red. the
</t> Registered (4) state. They also derive the output keying material and s
<t> tore the
<figure anchor="fig-completion" title="Completion Exchange"> persistent EAP-NOOB association state, as defined in Sections <xref
<artwork align="center"> target="fastreconnect"
<![CDATA[ format="counter"/> and <xref target="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 r
eceives in
the Completion Exchange. Another reason why the OOB sender might not re
cognize 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 <xref target="invalidm
essages"
format="default"/>), and the Completion Exchange ends in EAP-Failure. T
he recipient
of the error message 2003 moves back to the Waiting for OOB (1) state.
This state
transition is called OOB Reject in <xref target="fig-statemachine"
format="default"/> (even though it really is a specific type of failed
Completion
Exchange). On the other hand, the sender of the error message stays in
its
previous state.</t>
<t>Although it is not expected to occur in practice, poor user interfa
ce design
could lead to two OOB messages delivered simultaneously, one from the p
eer to the
server and the other from the server to the peer. The server detects th
is event in
the beginning of the Completion Exchange by observing that both the ser
ver and peer
are in the OOB Received (2) state. In that case, as a tiebreaker, the s
erver
<bcp14>MUST</bcp14> behave as if only the server-to-peer message had be
en
delivered.</t>
<figure anchor="fig-completion">
<name>Completion Exchange</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
EAP Peer EAP Server EAP Peer EAP Server
| ...continuing from common handshake | | ...continuing from common handshake |
| | | |
|<----------- [ EAP-Request/EAP-NOOB ] ------------| |<----------- [ EAP-Request/EAP-NOOB ] ------------|
| (Type=5,PeerId) | | (Type=5,PeerId) |
| | | |
| | | |
|------------ [ EAP-Response/EAP-NOOB ] ---------->| |------------ [ EAP-Response/EAP-NOOB ] ---------->|
| (Type=5,PeerId,NoobId) | | (Type=5,PeerId,NoobId) |
| | | |
skipping to change at line 375 skipping to change at line 576
|<----------- EAP-Request/EAP-NOOB ----------------| |<----------- EAP-Request/EAP-NOOB ----------------|
| (Type=6,PeerId,NoobId,MACs) | | (Type=6,PeerId,NoobId,MACs) |
| | | |
| | | |
|------------ EAP-Response/EAP-NOOB -------------->| |------------ EAP-Response/EAP-NOOB -------------->|
| (Type=6,PeerId,MACp) | | (Type=6,PeerId,MACp) |
| | | |
| | | |
|<----------- EAP-Success -------------------------| |<----------- EAP-Success -------------------------|
| | | |
]]> ]]></artwork>
</artwork> </figure>
</figure>
</t>
</section> </section>
<section anchor="waitingexchange" numbered="true" toc="default">
<section title="Waiting Exchange" anchor="waitingexchange"> <name>Waiting Exchange</name>
<t> <t>As explained in <xref target="completionexchange" format="default"/
As explained in <xref target="completionexchange"/>, the peer SHOULD >, the peer
probe the server for completion of the OOB Step. When the combination of the pe <bcp14>SHOULD</bcp14> probe the server for completion of the OOB Step.
er and server states indicates that the OOB message has not yet been delivered, When the
the server chooses the Waiting Exchange (see <xref target="commonhandshake"/> on combination of the peer and server states indicates that the OOB messag
how the server makes this decision). The Waiting Exchange comprises the common e has not yet
handshake and one further request-response pair, and it always ends in EAP-Failu been delivered, the server chooses the Waiting Exchange (see <xref
re. target="commonhandshake" format="default"/> on how the server makes thi
</t> s decision).
<t> The Waiting Exchange comprises the common handshake and one further req
In order to limit the rate at which peers probe the server, the serv uest-response
er MAY send to the peer either in the Initial Exchange or in the Waiting Exchang pair, and it always ends in EAP-Failure.</t>
e a minimum time to wait before probing the server again. A peer that has not re <t>In order to limit the rate at which peers probe the server, the ser
ceived an OOB message SHOULD wait at least the server-specified minimum waiting ver
time in seconds (SleepTime) before initiating EAP again with the same server. Th <bcp14>MAY</bcp14> send to the peer either in the Initial Exchange or i
e peer uses the latest SleepTime value that it has received in or after the Init n the Waiting
ial Exchange. If the server has not sent any SleepTime value, the peer MUST wait Exchange a minimum time to wait before probing the server again. A peer
for an application-specified minimum time (SleepTimeDefault). that has not
</t> received an OOB message <bcp14>SHOULD</bcp14> wait at least the server-
<t> specified
After the Waiting Exchange, the peer MUST discard (from its local ep minimum waiting time in seconds (SleepTime) before initiating EAP again
hemeral storage) Noob values that it has sent to the server in OOB messages that with the
are older than the application-defined timeout NoobTimeout (see <xref target="o same server. The peer uses the latest SleepTime value that it has recei
obstep"/>). The peer SHOULD discard such expired Noob values even if the probing ved in or
failed, e.g., because of failure to connect to the EAP server or incorrect mess after the Initial Exchange. If the server has not sent any SleepTime va
age authentication code. The timeout of peer-generated Noob values is defined li lue, the peer
ke this in order to allow the peer to probe the server once after it has waited <bcp14>MUST</bcp14> wait for an application-specified minimum time
for the server-specified SleepTime. (SleepTimeDefault).</t>
</t> <t>After the Waiting Exchange, the peer <bcp14>MUST</bcp14> discard (f
<t> rom its local
If the server and peer have negotiated to use only the server-to-pee ephemeral storage) Noob values that it has sent to the server in OOB me
r direction for the OOB channel (Dirp=2), the peer SHOULD nevertheless probe the ssages that
server. The purpose of this is to keep the server informed about the peers that are older than the application-defined timeout NoobTimeout (see <xref
are still waiting for OOB messages. The server MAY set SleepTime to a high numb target="oobstep" format="default"/>). The peer <bcp14>SHOULD</bcp14> di
er (3600) to prevent the peer from probing the server frequently. scard such
</t> expired Noob values even if the probing failed because of, e.g., failur
<t> e to connect
<figure anchor="fig-waiting" title="Waiting Exchange"> to the EAP server or an incorrect message authentication code. The time
<artwork align="center"> out of
<![CDATA[ peer-generated Noob values is defined like this in order to allow the p
eer to probe
the server once after it has waited for the server-specified SleepTime.
</t>
<t>If the server and peer have negotiated to use only the server-to-pe
er direction
for the OOB channel (Dirp=2), the peer <bcp14>SHOULD</bcp14> neverthele
ss probe the
server. The purpose of this is to keep the server informed about the pe
ers that are
still waiting for OOB messages. The server <bcp14>MAY</bcp14> set Sleep
Time to a
high number (e.g., 3600) to prevent the peer from probing the server fr
equently.</t>
<figure anchor="fig-waiting">
<name>Waiting Exchange</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
EAP Peer EAP Server EAP Peer EAP Server
| ...continuing from common handshake | | ...continuing from common handshake |
| | | |
|<----------- EAP-Request/EAP-NOOB ----------------| |<----------- EAP-Request/EAP-NOOB ----------------|
| (Type=4,PeerId,[SleepTime]) | | (Type=4,PeerId,[SleepTime]) |
| | | |
| | | |
|------------ EAP-Response/EAP-NOOB -------------->| |------------ EAP-Response/EAP-NOOB -------------->|
| (Type=4,PeerId) | | (Type=4,PeerId) |
| | | |
| | | |
|<----------- EAP-Failure -------------------------| |<----------- EAP-Failure -------------------------|
| | | |
]]> ]]></artwork>
</artwork> </figure>
</figure>
</t>
</section> </section>
</section> </section>
<section anchor="datafields" numbered="true" toc="default">
<name>Protocol Data Fields</name>
<t>This section defines the various identifiers and data fields used in
the EAP-NOOB
method.</t>
<section anchor="nai" numbered="true" toc="default">
<name>Peer Identifier and NAI</name>
<t>The server allocates a new peer identifier (PeerId) for the peer in
the Initial
Exchange. The peer identifier <bcp14>MUST</bcp14> follow the syntax of
the
utf8-username specified in <xref target="RFC7542" format="default"/>. T
he server
<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 se
nds them to
the peer in the Initial Exchange. One way to generate the identifiers i
s to choose a
random 16-byte identifier and to base64url encode it without padding <x
ref
target="RFC4648" format="default"/> into a 22-character ASCII string. A
nother way to
generate the identifiers is to choose a random 22-character alphanumeri
c ASCII
string. It is <bcp14>RECOMMENDED</bcp14> to not use identifiers longer
than this
because they result in longer OOB messages.</t>
<t>The peer uses the allocated PeerId to identify itself to the server
in the
subsequent exchanges. The peer <bcp14>MUST</bcp14> copy the PeerId byte
by byte from
the message where it was allocated, and the server <bcp14>MUST</bcp14>
perform a
byte-by-byte comparison between the received and the previously allocat
ed PeerID.
The peer sets the PeerId value in response type 1 as follows. As stated
in <xref
target="commonhandshake" format="default"/>, when the peer is in the Un
registered
(0) state, it <bcp14>SHOULD</bcp14> omit the PeerId from response type
1. When the
peer is in one of the states 1..2, it <bcp14>MUST</bcp14> use the PeerI
d that the
server assigned to it in the latest Initial Exchange. When the peer is
in one of the
persistent states 3..4, it <bcp14>MUST</bcp14> use the PeerId from its
persistent
EAP-NOOB association. (The PeerId is written to the association when th
e peer moves
to the Registered (4) state after a Completion Exchange.)</t>
<t>The default NAI for the peer is "noob@eap-noob.arpa". The peer impl
ementation
<bcp14>MAY</bcp14> allow the user or application to configure a differe
nt NAI, which
overrides the default NAI. Furthermore, the server <bcp14>MAY</bcp14> a
ssign a new
NAI to the peer in the Initial Exchange or Reconnect Exchange in the Ne
wNAI field
of request types 2 and 7 to override any previous NAI value. When the p
eer 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 peer
<bcp14>MUST</bcp14> use the configured NAI or, if it does not exist, th
e default
NAI. When the peer is in one of the states 1..2 and the server sent a N
ewNAI in the
latest Initial Exchange, the peer <bcp14>MUST</bcp14> use this server-a
ssigned NAI.
When the peer moves to the Registered (4) state after the Completion Ex
change, it
writes to the persistent EAP-NOOB association the same NAI value that i
t used in the
Completion Exchange. When the peer is in the Reconnecting (3) or Regist
ered (4)
state, it <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 values <bcp14>MUST</bcp14> follow
the syntax
specified in <xref target="RFC7542" format="default"/>. </t>
<t>The purpose of the server-assigned NAI is to enable more flexible r
outing of the
EAP sessions over the AAA infrastructure, including roaming scenarios (
see <xref
target="roaming" format="default"/>). Moreover, some authenticators or
AAA servers
use the realm part of the assigned NAI to determine peer-specific conne
ction
parameters, such as isolating the peer to a specific VLAN. On 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 peer devices.</t>
<t>The peer's PeerId and server-assigned NAI are ephemeral until a suc
cessful
Completion Exchange takes place. Thereafter, the values become parts of
the
persistent EAP-NOOB association until the user resets the peer and serv
er or
until a new NAI is assigned in the Reconnect Exchange.</t>
</section>
<section anchor="messagedatafields" numbered="true" toc="default">
<name>Message Data Fields</name>
<t><xref target="tab-datafields" format="default"/> defines the data f
ields in the
protocol messages. The in-band messages are formatted as JSON objects <
xref
target="RFC8259" format="default"/> in UTF-8 encoding. The JSON member
names are in
the left-hand column of the table.</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 EAP
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.</td>
</tr>
<tr>
<td align="left">PeerId</td>
<td align="left">Peer identifier, as defined in <xref target="na
i"
format="default"/>.</td>
</tr>
<tr>
<td align="left">NAI, NewNAI</td>
<td align="left">Peer NAI and server-assigned new peer NAI, as d
efined in
<xref target="nai" format="default"/>.</td>
</tr>
<tr>
<td align="left">Type</td>
<td align="left">EAP-NOOB message type. The type is an integer i
n the range
0..9. EAP-NOOB requests and the corresponding responses share the
same type
value.</td>
</tr>
<tr>
<td align="left">PeerState</td>
<td align="left">Peer state is an integer in the range 0..4 (see
<xref
target="fig-statemachine" format="default"/>). However, only valu
es 0..3 are
ever sent in the protocol messages.</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 <xref
target="RFC7517" format="default"/>. The detailed format of the J
WK object is
defined by the cryptosuite.</td>
</tr>
<tr>
<td align="left">Cryptosuites, Cryptosuitep</td>
<td align="left">The identifiers of cryptosuites supported by th
e server and
of the cryptosuite selected by the peer. The server-supported cry
ptosuites in
Cryptosuites are formatted as a JSON array of the identifier inte
gers. The
server <bcp14>MUST</bcp14> send a nonempty array with no repeatin
g elements,
ordered by decreasing priority. The peer <bcp14>MUST</bcp14> resp
ond with
exactly one suite in the Cryptosuitep value, formatted as an iden
tifier
integer. Mandatory-to-implement cryptosuites and the registration
procedure
for new cryptosuites are specified in <xref target="cryptosuites"
format="default"/>. Example values are "[1]" and "1", respectivel
y.</td>
</tr>
<tr>
<td align="left">Dirs, Dirp</td>
<td align="left">An integer indicating the OOB channel direction
s 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=both directions.</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 fingerprin
t Hoob.</td>
</tr>
<tr>
<td align="left">Ns, Np</td>
<td align="left">32-byte nonces for the Initial Exchange.</td>
</tr>
<tr>
<td align="left">ServerInfo</td>
<td align="left">This field contains information about the serve
r to be passed
from the EAP method to the application layer in the peer. The inf
ormation is
specific to the application or to the OOB channel, and it is enco
ded as a JSON
object of at most 500 bytes. It could include, for example, the a
ccess-network
name and server name, a Uniform Resource Locator (URL) <xref
target="RFC3986" format="default"/>, or some other information th
at helps the
user deliver the OOB message to the server through the out-of-ban
d
channel.</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 i
nformation is
specific to the application or to the OOB channel, and it is enco
ded as a JSON
object of at most 500 bytes. It could include, for example, the p
eer brand,
model, and serial number, which help the user distinguish between
devices
and deliver the OOB message to the correct peer through the out-o
f-band
channel.</td>
</tr>
<tr>
<td align="left">SleepTime</td>
<td align="left">The number of seconds for which the peer <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 se
nding 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 range 0..3600.</td>
</tr>
<tr>
<td align="left">Noob</td>
<td align="left">16-byte secret nonce sent through the OOB chann
el and used
for the session key derivation. The endpoint that received the OO
B message
uses this secret in the Completion Exchange to authenticate the e
xchanged key
to the endpoint that sent the OOB message.</td>
</tr>
<tr>
<td align="left">Hoob</td>
<td align="left">16-byte cryptographic fingerprint (i.e., hash v
alue) computed
from all the parameters exchanged in the Initial Exchange and in
the OOB
message. Receiving this fingerprint over the OOB channel guarante
es the
integrity of the key exchange and parameter negotiation. Hence, i
t
authenticates the exchanged key to the endpoint that receives the
OOB
message.</td>
</tr>
<tr>
<td align="left">NoobId</td>
<td align="left">16-byte identifier for the OOB message, compute
d with a
one-way function from the nonce Noob in the message.</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 exch
anged
information. The input to the HMAC is defined below, and the key
for the HMAC
is defined in <xref target="keyderivation" format="default"/>.</t
d>
</tr>
<tr>
<td align="left">Ns2, Np2</td>
<td align="left">32-byte nonces for the Reconnect Exchange.</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 Reconnect Exchange.</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 JS
ON Web Key
(JWK) format <xref target="RFC7517" format="default"/>. The detai
led format of
the JWK object is defined by the cryptosuite.</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 Reco
nnect
Exchange. The input to the HMAC is defined below, and the key for
the HMAC is
defined in <xref target="keyderivation" format="default"/>.</td>
</tr>
<tr>
<td align="left">ErrorCode</td>
<td align="left">Integer indicating an error condition. Defined
in <xref
target="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 500 bytes.</td>
</tr>
</tbody>
</table>
<t>It is <bcp14>RECOMMENDED</bcp14> for servers to support both OOB ch
annel
directions (Dirs=3) unless the type of the OOB channel limits them to o
ne direction
(Dirs=1 or Dirs=2). On the other hand, it is <bcp14>RECOMMENDED</bcp14>
that the
peer selects only one direction (Dirp=1 or Dirp=2) even when both direc
tions
(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 ea
ch direction,
even though only one of them needs to be delivered. This can be confusi
ng to the
user. Nevertheless, the EAP-NOOB protocol is designed to also cope with
the value 3;
in which case, it uses the first delivered OOB message. In the unlikely
case of
simultaneously delivered OOB messages, the protocol prioritizes the ser
ver-to-peer
direction.</t>
<t>The nonces in the in-band messages (Ns, Np, Ns2, Np2) are 32-byte f
resh 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 the message.</t>
<t>The fingerprint Hoob and the identifier NoobId are computed with th
e
cryptographic hash function H, which is specified in the negotiated cry
ptosuite and
truncated to the 16 leftmost bytes of the output. The message authentic
ation codes
(MACs, MACp, MACs2, MACp2) are computed with the function HMAC, which i
s the hashed
message authentication code <xref target="RFC2104" format="default"/> b
ased on the
cryptographic hash function H and truncated to the 32 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 contain
ing a fixed
number (17) of elements. The array elements <bcp14>MUST</bcp14> be copi
ed to
the
array verbatim from the sent and received in-band messages. When the el
ement is a
JSON object, its members <bcp14>MUST NOT</bcp14> be reordered or reenco
ded.
White space <bcp14>MUST NOT</bcp14> be added anywhere in the JSON struc
ture.
Implementers should check that their JSON library copies the elements a
s UTF-8
strings, does not modify them in any way, and does not add white space
to
the HMAC input.</t>
<t>The inputs for computing the fingerprint and message authentication
codes are the
following:</t>
<sourcecode type="pseudocode">
Hoob = H(Dir,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,
Cryptosuitep,Dirp,NAI,PeerInfo,0,PKs,Ns,PKp,Np,Noob).
<section title="Protocol data fields" anchor="datafields"> NoobId = H("NoobId",Noob).
<t>
This section defines the various identifiers and data fields used in t
he EAP-NOOB protocol.
</t>
<section title="Peer identifier and NAI" anchor="nai"> MACs = HMAC(Kms; 2,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,
<t> Cryptosuitep,Dirp,NAI,PeerInfo,0,PKs,Ns,PKp,Np,Noob).
The server allocates a new peer identifier (PeerId) for the peer in
the Initial Exchange. The peer identifier MUST follow the syntax of the utf8-use
rname specified in <xref target="RFC7542"/>. The server MUST generate the identi
fiers 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 an
d to base64url encode it without padding <xref target="RFC4648"/> into a 22-char
acter ASCII string. Another way to generate the identifiers is to choose a rando
m 22-character alphanumeric ASCII string. It is RECOMMENDED to not use identifie
rs longer than this because they result in longer OOB messages.
</t>
<t>
The peer uses the allocated PeerId to identify itself to the server
in the subsequent exchanges. The peer MUST copy the PeerId byte-by-byte from the
message where it was allocated, and the server MUST perform a byte-by-byte comp
arison between the received and the previously allocated PeerID. The peer sets t
he PeerId value in response type 1 as follows. As stated in <xref target="common
handshake"/>, when the peer is in the Unregistered (0) state, it SHOULD omit the
PeerId from response type 1. When the peer is in one of the states 1..2, it MUS
T 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, it MUST use the PeerId fr
om its persistent EAP-NOOB association. (The PeerId is written to the associatio
n when the peer moves to the Registered (4) state after a Completion Exchange.)
</t>
<t>
The default NAI for the peer is "noob@eap-noob.arpa". The peer imple
mentation MAY allow the user or application to configure a different NAI, which
overrides the default NAI. Furthermore, the server MAY assign a new NAI to the p
eer in the Initial Exchange or Reconnect Exchange, in the NewNAI field of reques
t types 2 and 7, to override any previous NAI value. When the peer is in the Unr
egistered (0) state, or when the peer is in one of the states 1..2 and the serve
r did not send a NewNAI in the latest Initial Exchange, the peer MUST use the co
nfigured NAI, 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 peer MUST use this server-assigned NAI. When the peer moves to the Registere
d (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, it MUST use the NAI fr
om its persistent EAP-NOOB association. When the server sends NewNAI in the Reco
nnect 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 values MUST follow the syntax specified in <xref target="RFC7542"/>.
</t>
<t>
The purpose of the server-assigned NAI is to enable more flexible ro
uting of the EAP sessions over the AAA infrastructure, including roaming scenari
os (see <xref target="roaming"/>). Moreover, some Authenticators or AAA servers
use the realm part of the assigned NAI to determine peer-specific connection par
ameters, such as isolating the peer to a specific VLAN. The user or application
configured NAI, on the other hand, enables registration of new devices while roa
ming. It also enables manufacturers to set up their own AAA servers for bootstra
pping of new peer devices.
</t>
<t>
The peer's PeerId and server-assigned NAI are ephemeral until a succ
essful Completion Exchange takes place. Thereafter, the values become parts of t
he persistent EAP-NOOB association, until the user resets the peer and the serve
r or until a new NAI is assigned in the Reconnect Exchange.
</t>
</section>
<section title="Message data fields" anchor="messagedatafields"> MACp = HMAC(Kmp; 1,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,
<t> Cryptosuitep,Dirp,NAI,PeerInfo,0,PKs,Ns,PKp,Np,Noob).
<xref target="table-datafields"/> defines the data fields in the pro
tocol messages. The in-band messages are formatted as JSON objects <xref target=
"RFC8259"/> in UTF-8 encoding. The JSON member names are in the left-hand column
of the table.
</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-NOOB protocol versions supported by the EAP server, and the p
rotocol version chosen by the peer. Vers is a JSON array of unsigned integers, a
nd Verp is an unsigned integer. Example values are "[1]" and "1", respectively.<
/c>
<c></c><c></c>
<c>PeerId</c>
<c>Peer identifier as defined in <xref target="nai"/>.</c>
<c></c><c></c>
<c>NAI, NewNAI</c>
<c>Peer NAI and server-assigned new peer NAI as defined in <xref tar
get="nai"/>.</c>
<c></c><c></c>
<c>Type</c>
<c>EAP-NOOB message type. The type is an integer in the range 0..9.
EAP-NOOB requests and the corresponding responses share the same type value.</c>
<c></c><c></c>
<c>PeerState</c>
<c>Peer state is an integer in the range 0..4 (see <xref target="fig
-statemachine"/>). However, only values 0..3 are ever sent in the protocol messa
ges.</c>
<c></c><c></c>
<c>PKs, PKp</c>
<c>The public components of the ECDHE keys of the server and peer. P
Ks and PKp are sent in the JSON Web Key (JWK) format <xref target="RFC7517"/>. T
he detailed format of the JWK object is defined by the cryptosuite.</c>
<c></c><c></c>
<c>Cryptosuites, Cryptosuitep</c>
<c>The identifiers of cryptosuites supported by the server and of th
e cryptosuite selected by the peer. The server-supported cryptosuites in Cryptos
uites are formatted as a JSON array of the identifier integers. The server MUST
send a nonempty array with no repeating elements, ordered by decreasing priority
. The peer MUST respond with exactly one suite in the Cryptosuitep value, format
ted as an identifier integer. Mandatory to implement cryptosuites and the regist
ration procedure for new cryptosuites is specified in <xref target="cryptosuites
"/>. Example values are "[1]" and "1", respectively.</c>
<c></c><c></c>
<c>Dirs, Dirp</c>
<c>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, 3=both directions.</c>
<c></c><c></c>
<c>Dir</c>
<c>The actual direction of the OOB message (1=peer-to-server, 2=serv
er-to-peer). This value is not sent over any communication channel, but it is in
cluded in the computation of the cryptographic fingerprint Hoob.</c>
<c></c><c></c>
<c>Ns, Np</c>
<c>32-byte nonces for the Initial Exchange.</c>
<c></c><c></c>
<c>ServerInfo</c>
<c>This field contains information about the server to be passed fro
m the EAP method to the application layer in the peer. The information is specif
ic 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
server name or a Uniform Resource Locator (URL) <xref target="RFC3986"/> or som
e 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 information is specif
ic 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 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>SleepTime</c>
<c>The number of seconds for which the peer MUST NOT start a new exe
cution of the EAP-NOOB method with the authenticator, unless the peer receives t
he OOB message or the sending is triggered by an application-specific user actio
n. The server can use this field to limit the rate at which peers probe it. Slee
pTime is an unsigned integer in the range 0..3600.</c>
<c></c><c></c>
<c>Noob</c>
<c>16-byte secret nonce sent through the OOB channel and used for th
e session key derivation. The endpoint that received the OOB message uses this s
ecret in the Completion Exchange to authenticate the exchanged key to the endpoi
nt that sent the OOB message.</c>
<c></c><c></c>
<c>Hoob</c>
<c>16-byte cryptographic fingerprint (i.e., hash value) computed fro
m all the parameters exchanged in the Initial Exchange and in the OOB message. R
eceiving this fingerprint over the OOB channel guarantees the integrity of the k
ey exchange and parameter negotiation. Hence, it authenticates the exchanged key
to the endpoint that receives the OOB message.</c>
<c></c><c></c>
<c>NoobId</c>
<c>16-byte identifier for the OOB message, computed with a one-way f
unction from the nonce Noob in the message.</c>
<c></c><c></c>
<c>MACs, MACp</c>
<c>Message authentication codes (HMAC) for mutual authentication, ke
y confirmation, and integrity check on the exchanged information. The input to t
he HMAC is defined below, and the key for the HMAC is defined in <xref target="k
eyderivation"/>.</c>
<c></c><c></c>
<c>Ns2, Np2</c>
<c>32-byte nonces for the Reconnect Exchange.</c>
<c></c><c></c>
<c>KeyingMode</c>
<c>Integer indicating the key derivation method. 0 in the Completion
Exchange, and 1..3 in the Reconnect Exchange.</c>
<c></c><c></c>
<c>PKs2, PKp2</c>
<c>The public components of the ECDHE keys of the server and peer fo
r the Reconnect Exchange. PKp2 and PKs2 are sent in the JSON Web Key (JWK) forma
t <xref target="RFC7517"/>. The detailed format of the JWK object is defined by
the cryptosuite.</c>
<c></c><c></c>
<c>MACs2, MACp2</c>
<c>Message authentication codes (HMAC) for mutual authentication, ke
y 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="keyd
erivation"/>.</c>
<c></c><c></c>
<c>ErrorCode</c>
<c>Integer indicating an error condition. Defined in <xref target="e
rrorcodes"/>.</c>
<c></c><c></c>
<c>ErrorInfo</c>
<c>Textual error message for logging and debugging purposes. A UTF-8
string of at most 500 bytes.</c>
<c></c><c></c>
</texttable>
<t>
It is RECOMMENDED 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 is RECOMMENDED that the peer selects only on
e direction (Dirp=1 or Dirp=2) even when both directions (Dirp=3) would be techn
ically possible. The reason is that, if value 3 is negotiated, the user may be p
resented 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 to cope also with the value 3, in which case it u
ses the first delivered OOB message. In the unlikely case of simultaneously deli
vered OOB messages, the protocol prioritizes the server-to-peer direction.
</t>
<t>
The nonces in the in-band messages (Ns, Np, Ns2, Np2) are 32-byte fr
esh random byte strings, and the secret nonce Noob is a 16-byte fresh random byt
e string. All the nonces are generated by the endpoint that sends the message.
</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 authenticatio
n codes (MACs, MACp, MACs2, MACp2) are computed with the function HMAC, which is
the HMAC message authentication code <xref target="RFC2104"/> based on the cryp
tographic hash function H and truncated to the 32 leftmost bytes of the output.
</t>
<t>
The inputs to the hash function for computing the fingerprint Hoob a
nd to the HMAC for computing MACs, MACp, MACs2 and MACp2 are JSON arrays contain
ing a fixed number (17) of elements. The array elements MUST be copied to the ar
ray verbatim from the sent and received in-band messages. When the element is a
JSON object, its members MUST NOT be reordered or re-encoded. Whitespace MUST NO
T be added anywhere in the JSON structure. Implementers should check that their
JSON library copies the elements as UTF-8 strings and does not modify them in an
y way, and that it does not add whitespace to the HMAC input.
</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,Cryp
tosuitep,Dirp,NAI,PeerInfo,0,PKs,Ns,PKp,Np,Noob). </t>
<t>NoobId = H("NoobId",Noob). </t>
<t>MACs = HMAC(Kms; 2,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInf
o,Cryptosuitep,Dirp,NAI,PeerInfo,0,PKs,Ns,PKp,Np,Noob). </t>
<t>MACp = HMAC(Kmp; 1,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInf
o,Cryptosuitep,Dirp,NAI,PeerInfo,0,PKs,Ns,PKp,Np,Noob). </t>
<t>MACs2 = HMAC(Kms2; 2,Vers,Verp,PeerId,Cryptosuites,"",[ServerIn
fo],Cryptosuitep,"",NAI,[PeerInfo],KeyingMode,[PKs2],Ns2,[PKp2],Np2,"") </t>
<t>MACp2 = HMAC(Kmp2; 1,Vers,Verp,PeerId,Cryptosuites,"",[ServerIn
fo],Cryptosuitep,"",NAI,[PeerInfo],KeyingMode,[PKs2],Ns2,[PKp2],Np2,"") </t>
</list>
</t>
<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 Comp
letion Exchange or Reconnect Exchange succeeds. In the Completion Exchange, the
NAI is the NewNAI value assigned by the server in the preceding Initial Exchange
, 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 Reconnect Exchange, or if no NewNAI was sent, the unchanged NAI from t
he persistent EAP-NOOB association. Each of the values in brackets for the compu
tation of Macs2 and Macp2 MUST be included if it was sent or received in the sam
e Reconnect Exchange; otherwise, the value is replaced by an empty string "".
</t>
<t>
The parameter Dir indicates the direction in which the OOB message c
ontaining the Noob value is being sent (1=peer-to-server, 2=server-to-peer). Thi
s field is included in the Hoob input to prevent the user from accidentally deli
vering the OOB message back to its originator in the rare cases where both OOB d
irections have been negotiated. The keys (Kms, Kmp, Kms2, Kmp2) for the HMACs ar
e defined in <xref target="keyderivation"/>.
</t>
<t>
The nonces (Ns, Np, Ns2, Np2, Noob) and the hash value (NoobId) MUST
be base64url encoded <xref target="RFC4648"/> when they are used as input to th
e cryptographic functions H or HMAC. These values and the message authentication
codes (MACs, MACp, MACs2, MACp2) MUST also be base64url encoded when they are s
ent as JSON strings in the in-band messages. The values Noob and Hoob in the OOB
channel MAY be base64url encoded if that is appropriate for the application and
the OOB channel. All base64url encoding is done without padding. The base64url
encoded values will naturally consume more space than the number of bytes specif
ied above (22-character string for a 16-byte nonce and 43-character string for a
32-byte nonce or message authentication code). In the key derivation in <xref t
arget="keyderivation"/>, on the other hand, the unencoded nonces (raw bytes) are
used as input to the key derivation function.
</t>
<t>
The ServerInfo and PeerInfo are JSON objects with UTF-8 encoding. Th
e length of either encoded object as a byte array MUST NOT exceed 500 bytes. The
format and semantics of these objects MUST be defined by the application that u
ses the EAP-NOOB method.
</t>
</section>
</section>
<section title="Fast reconnect and rekeying" anchor="fastreconnect"> MACs2 = HMAC(Kms2; 2,Vers,Verp,PeerId,Cryptosuites,"",[ServerInfo],
<t> Cryptosuitep,"",NAI,[PeerInfo],KeyingMode,[PKs2],Ns2,[PKp2],Np2,"")
EAP-NOOB implements Fast Reconnect (<xref target="RFC3748"/>, section
7.2.1) that avoids repeated use of the user-assisted OOB channel.
</t>
<t>
The rekeying and the Reconnect Exchange may be needed for several reas
ons. 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, EAP server or
peer to lose its non-persistent state data. The failure would typically be dete
cted by the peer or authenticator when session keys are no longer accepted by th
e other endpoint. Changes in the supported cryptosuites in the EAP server or pee
r may also cause the need for a new key exchange. When the EAP server or peer de
tects any one of these events, it MUST change from the Registered to Reconnectin
g state. These state transitions are labeled Mobility/Timeout/Failure in <xref t
arget="fig-statemachine"/>. The EAP-NOOB method will then perform the Reconnect
Exchange the next time when EAP is triggered.
</t>
<section title="Persistent EAP-NOOB association" anchor="persistentassoc MACp2 = HMAC(Kmp2; 1,Vers,Verp,PeerId,Cryptosuites,"",[ServerInfo],
iation"> Cryptosuitep,"",NAI,[PeerInfo],KeyingMode,[PKs2],Ns2,[PKp2],Np2,"")
<t> </sourcecode>
To enable rekeying, the EAP server and peer store the session state <t>The inputs denoted with "" above are not present, and the values in
in persistent memory after a successful Completion Exchange. This state data, ca brackets
lled "persistent EAP-NOOB association", MUST include at least the data fields sh [] are optional. Both kinds of missing input values are represented by
own in <xref target="table-persistent"/>. They are used for identifying and auth empty strings
enticating the peer in the Reconnect Exchange. When a persistent EAP-NOOB associ "" in the HMAC input (JSON array). The NAI included in the inputs is th
ation exists, the EAP server and peer are in the Registered state (4) or Reconne e NAI value
cting state (3), as shown in <xref target="fig-statemachine"/>. that will be in the persistent EAP-NOOB association if the Completion E
</t> xchange or
<texttable title="Persistent EAP-NOOB association" anchor="table-persi Reconnect Exchange succeeds.
stent"> In the Completion Exchange, the NAI is the NewNAI value
<ttcol>Data Field</ttcol> assigned by the server in the preceding Initial Exchange or, if no NewN
<ttcol>Value</ttcol> AI was sent,
<ttcol>Type</ttcol> the NAI used by the client in the Initial Exchange. In the Reconnect Ex
<c>PeerId</c><c>Peer identifier allocated by server</c><c>UTF-8 stri change,
ng (typically 22 ASCII characters)</c> the NAI is the NewNAI value assigned by the server in the same Reconnec
<c></c><c></c><c></c> t Exchange
<c>Verp</c><c>Negotiated protocol version</c><c>integer</c> or, if
<c></c><c></c><c></c> no NewNAI was sent, the unchanged NAI from the persistent EAP-NOOB asso
<c>Cryptosuitep</c><c>Negotiated cryptosuite</c><c>integer</c> ciation. Each
<c></c><c></c><c></c> of the values in brackets for the computation of Macs2 and Macp2 <bcp14
<c>CryptosuitepPrev (at peer only)</c><c>Previous cryptosuite</c><c> >MUST</bcp14>
integer</c> be included if it was sent or received in the same Reconnect Exchange;
<c></c><c></c><c></c> otherwise,
<c>NAI</c><c>NAI assigned by server, configured by user, or the defa the value is replaced by an empty string "".</t>
ult NAI "noob@eap-noob.arpa"</c><c>UTF-8 string</c> <t>The parameter Dir indicates the direction in which the OOB message
<c>Kz</c><c>Persistent key material</c><c>32 bytes</c> containing the
<c></c><c></c><c></c> Noob value is being sent (1=peer-to-server, 2=server-to-peer). This fie
<c>KzPrev (at peer only)</c><c>Previous Kz value</c><c>32 bytes</c> ld is
</texttable> included in the Hoob input to prevent the user from accidentally delive
ring the OOB
message back to its originator in the rare cases where both OOB directi
ons have been
negotiated. The keys (Kms, Kmp, Kms2, and Kmp2) for the HMACs are defin
ed in <xref
target="keyderivation" format="default"/>.</t>
<t>The nonces (Ns, Np, Ns2, Np2, and Noob) and the hash value (NoobId)
<bcp14>MUST</bcp14> be base64url encoded <xref target="RFC4648" format=
"default"/>
when they are used as input to the cryptographic functions H or HMAC. T
hese values
and the message authentication codes (MACs, MACp, MACs2, and MACp2)
<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 channel <bcp14>MAY</bcp14
> be
base64url encoded if that is appropriate for the application and the OO
B channel.
All base64url encoding is done without padding. The base64url-encoded v
alues will
naturally consume more space than the number of bytes specified above (
e.g., a
22-character
string for a 16-byte nonce and a 43-character string for a 32-byte nonc
e or message
authentication code). In the key derivation in <xref target="keyderivat
ion"
format="default"/>, on the other hand, the unencoded nonces (raw bytes)
are used as
input to the key derivation function.</t>
<t>The ServerInfo and PeerInfo are JSON objects with UTF-8 encoding. T
he length of
either encoded object as a byte array <bcp14>MUST NOT</bcp14> exceed 50
0 bytes. The
format and semantics of these objects <bcp14>MUST</bcp14> be defined by
the
application that uses the EAP-NOOB method.</t>
</section> </section>
</section>
<section title="Reconnect Exchange" anchor="reconnectexchange"> <section anchor="fastreconnect" numbered="true" toc="default">
<t> <name>Fast Reconnect and Rekeying</name>
The server chooses the Reconnect Exchange when both the peer and the <t>EAP-NOOB implements fast reconnect (<xref target="RFC3748" sectionFor
server are in a persistent state and fast reconnection is needed (see <xref tar mat="comma"
get="commonhandshake"/> for details). section="7.2.1"/>), which avoids repeated use of the user-assisted OOB ch
</t> annel.</t>
<t> <t>The rekeying and the Reconnect Exchange may be needed for several rea
The Reconnect Exchange comprises the common handshake and three furt sons. New EAP
her EAP-NOOB request-response pairs, one for cryptosuite and parameter negotiati output values Main Session Key (MSK) and Extended Main Session Key (EMSK)
on, another for the nonce and ECDHE key exchange, and the last one for exchangin may be
g message authentication codes. In the first request and response (Type=7) the s needed because of mobility or timeout of session keys. Software or hardwa
erver and peer negotiate a protocol version and cryptosuite in the same way as i re failure or
n the Initial Exchange. The server SHOULD NOT offer and the peer MUST NOT accept user action may also cause the authenticator, EAP server, or peer to lose
protocol versions or cryptosuites that it knows to be weaker than the one curre its
ntly in the Cryptosuitep field of the persistent EAP-NOOB association. The serve nonpersistent state data. The failure would typically be detected by the
r SHOULD NOT needlessly change the cryptosuites it offers to the same peer becau peer or
se peer devices may have limited ability to update their persistent storage. How authenticator when session keys are no longer accepted by the other endpo
ever, if the peer has different values in the Cryptosuitep and CryptosuitepPrev int. Changes
fields, it SHOULD also accept offers that are not weaker than CryptosuitepPrev. in the supported cryptosuites in the EAP server or peer may also cause th
Note that Cryptosuitep and CryptosuitePrev from the persistent EAP-NOOB associat e need for a
ion are only used to support the negotiation as described above; all actual cryp new key exchange. When the EAP server or peer detects any one of these ev
tographic operations use the newly negotiated cryptosuite. The request and respo ents, it
nse (Type=7) MAY additionally contain PeerInfo and ServerInfo objects. <bcp14>MUST</bcp14> change from the Registered (4) state to the Reconnect
</t> ing (3)
<t> state. These state
The server then determines the KeyingMode (defined in <xref target=" transitions are labeled Mobility/Timeout/Failure in <xref target="fig-sta
keyderivation"/>) based on changes in the negotiated cryptosuite and whether it temachine"
desires to achieve forward secrecy or not. The server SHOULD only select KeyingM format="default"/>. The EAP-NOOB method will then perform the Reconnect E
ode 3 when the negotiated cryptosuite differs from the Cryptosuitep in the serve xchange the
r's persistent EAP-NOOB association, although it is technically possible to sele next time when EAP is triggered.</t>
ct this value without changing the cryptosuite. In the second request and respon <section anchor="persistentassociation" numbered="true" toc="default">
se (Type=8), the server informs the peer about the KeyingMode, and the server an <name>Persistent EAP-NOOB Association</name>
d peer exchange nonces (Ns2, Np2). When KeyingMode is 2 or 3 (rekeying with ECDH <t>To enable rekeying, the EAP server and peer store the session state
E), they also exchange public components of ECDHE keys (PKs2, PKp2). The server in persistent
ECDHE key MUST be fresh, i.e., not previously used with the same peer, and the p memory after a successful Completion Exchange. This state data, called
eer ECDHE key SHOULD be fresh, i.e., not previously used. "persistent
</t> EAP-NOOB association", <bcp14>MUST</bcp14> include at least the data fi
<t> elds shown in
In the third and final request and response (Type=9), the server and <xref target="tab-persistent" format="default"/>. They are used for ide
peer exchange message authentication codes. Both sides MUST compute the keys Km ntifying and
s2 and Kmp2 as defined in <xref target="keyderivation"/> and the message authent authenticating the peer in the Reconnect Exchange. When a persistent EA
ication codes MACs2 and MACp2 as defined in <xref target="messagedatafields"/>. P-NOOB
Both sides MUST compare the received message authentication code with a locally association exists, the EAP server and peer are in the Registered (4) s
computed value. tate or
</t> Reconnecting (3) state, as shown in <xref target="fig-statemachine"
<t> format="default"/>.</t>
The rules by which the peer compares the received MACs2 are non-triv <table anchor="tab-persistent" align="center">
ial because, in addition to authenticating the current exchange, MACs2 may confi <name>Persistent EAP-NOOB Association</name>
rm the success or failure of a recent cryptosuite upgrade. The peer processes th <thead>
e final request (Type=9) as follows: <tr>
</t> <th align="left">Data Field</th>
<t> <th align="left">Value</th>
<list style="numbers"> <th align="left">Type</th>
<t> </tr>
The peer first compares the received MACs2 value with one it com </thead>
puted using the Kz stored in the persistent EAP-NOOB association. If the receive <tbody>
d and computed values match, the peer deletes any data stored in the Cryptosuite <tr>
pPrev and KzPrev fields of the persistent EAP-NOOB association. It does this bec <td align="left">PeerId</td>
ause the received MACs2 confirms that the peer and server share the same Cryptos <td align="left">Peer identifier allocated by server</td>
uitep and Kz, and any previous values must no longer be accepted. <td align="left">UTF-8 string (typically 22 ASCII characters)</t
</t> d>
<t> </tr>
If, on the other hand, the peer finds that the received MACs2 va <tr>
lue does not match the one it computed locally with Kz, the peer checks whether <td align="left">Verp</td>
the KzPrev field in the persistent EAP-NOOB association stores a key. If it does <td align="left">Negotiated protocol version</td>
, the peer repeats the key derivation (<xref target="keyderivation"/>) and local <td align="left">integer</td>
MACs2 computation (<xref target="messagedatafields"/>) using KzPrev in place of </tr>
Kz. If this second computed MACs2 matches the received value, the match indicat <tr>
es synchronization failure caused by the loss of the last response (Type=9) in a <td align="left">Cryptosuitep</td>
previously attempted cryptosuite upgrade. In this case, the peer rolls back tha <td align="left">Negotiated cryptosuite</td>
t upgrade by overwriting Cryptosuitep with CryptosuitepPrev and Kz with KzPrev i <td align="left">integer</td>
n the persistent EAP-NOOB association. It also clears the CryptosuitepPrev and K </tr>
zPrev fields. <tr>
</t> <td align="left">CryptosuitepPrev (at peer only)</td>
<t> <td align="left">Previous cryptosuite</td>
If the received MACs2 matched one of the locally computed values <td align="left">integer</td>
, the peer proceeds to send the final response (Type=9). The peer also moves to </tr>
the Registered (4) state. When KeyingMode is 1 or 2, the peer stops here. When K <tr>
eyingMode is 3, the peer also updates the persistent EAP-NOOB association with t <td align="left">NAI</td>
he negotiated Cryptosuitep and the newly-derived Kz value. To prepare for possib <td align="left">NAI assigned by the server or configured by the
le synchronization failure caused by the loss of the final response (Type=9) dur user or the
ing cryptosuite upgrade, the peer copies the old Cryptosuitep and Kz values in t default NAI "noob@eap-noob.arpa"</td>
he persistent EAP-NOOB association to the CryptosuitepPrev and KzPrev fields. <td align="left">UTF-8 string</td>
</t> </tr>
<t> <tr>
Finally, if the peer finds that the received MACs2 does not matc <td align="left">Kz</td>
h either of the two values that it computed locally (or one value if no KzPrev w <td align="left">Persistent key material</td>
as stored), the peer sends an error message (error code 4001, see <xref target=" <td align="left">32 bytes</td>
invalidmessages"/>), which causes the Reconnect Exchange to end in EAP-Failure. </tr>
</t> <tr>
</list> <td align="left">KzPrev (at peer only)</td>
</t> <td align="left">Previous Kz value</td>
<t> <td align="left">32 bytes</td>
The server rules for processing the final message are simpler than t </tr>
he peer rules because the server does not store previous keys, and it never roll </tbody>
s back a cryptosuite upgrade. Upon receiving the final response (Type=9), the se </table>
rver compares the received value of MACp2 with one it computes locally. If the v </section>
alues match, the Reconnect Exchange ends in EAP-Success. When KeyingMode is 3, t <section anchor="reconnectexchange" numbered="true" toc="default">
he server also updates Cryptosuitep and Kz in the persistent EAP-NOOB associatio <name>Reconnect Exchange</name>
n. On the other hand, if the server finds that the values do not match, it sends <t>The server chooses the Reconnect Exchange when both the peer and th
an error message (error code 4001), and the Reconnect Exchange ends in EAP-Fail e server are
ure. in a persistent state and fast reconnection is needed (see <xref
</t> target="commonhandshake" format="default"/> for details).</t>
<t> <t>The Reconnect Exchange comprises the common handshake and three fur
The endpoints MAY send updated NewNAI, ServerInfo and PeerInfo objec ther EAP-NOOB
ts in the Reconnect Exchange. When there is no update to the values, they SHOULD request-response pairs: one for cryptosuite and parameter negotiation,
omit this information from the messages. If the NewNAI was sent, each side upda another for
tes NAI in the persistent EAP-NOOB association when moving to the Registered (4) the nonce and ECDHE key exchange, and the last one for exchanging messa
state. ge
</t> authentication codes. In the first request and response (Type=7), the s
<t> erver and peer
<figure anchor="fig-reconnect" title="Reconnect Exchange"> negotiate a protocol version and cryptosuite in the same way as in the
<artwork align="center"> Initial
<![CDATA[ Exchange. The server <bcp14>SHOULD NOT</bcp14> offer and the peer <bcp1
4>MUST
NOT</bcp14> accept protocol versions or cryptosuites that it knows to b
e weaker than
the one currently in the Cryptosuitep field of the persistent EAP-NOOB
association.
The server <bcp14>SHOULD NOT</bcp14> needlessly change the cryptosuites
it offers to
the same peer because peer devices may have limited ability to update t
heir
persistent storage. However, if the peer has different values in the Cr
yptosuitep
and CryptosuitepPrev fields, it <bcp14>SHOULD</bcp14> also accept offer
s that are
not weaker than CryptosuitepPrev. Note that Cryptosuitep and Cryptosuit
ePrev from
the persistent EAP-NOOB association are only used to support the negoti
ation as
described above; all actual cryptographic operations use the newly nego
tiated
cryptosuite. The request and response (Type=7) <bcp14>MAY</bcp14> addit
ionally
contain PeerInfo and ServerInfo objects.</t>
<t>The server then determines the KeyingMode (defined in <xref
target="keyderivation" format="default"/>) based on changes in the nego
tiated
cryptosuite and whether it desires to achieve forward secrecy or not. T
he server
<bcp14>SHOULD</bcp14> only select KeyingMode 3 when the negotiated cryp
tosuite
differs from the Cryptosuitep in the server's persistent EAP-NOOB assoc
iation,
although it is technically possible to select this value without changi
ng the
cryptosuite. In the second request and response (Type=8), the server in
forms the
peer about the KeyingMode and the server and peer exchange nonces (Ns2,
Np2). When
KeyingMode is 2 or 3 (rekeying with ECDHE), they also exchange public c
omponents of
ECDHE keys (PKs2, PKp2). The server ECDHE key <bcp14>MUST</bcp14> be fr
esh, i.e.,
not previously used with the same peer, and the peer ECDHE key <bcp14>S
HOULD</bcp14>
be fresh, i.e., not previously used.</t>
<t>In the third and final request and response (Type=9), the server an
d peer
exchange message authentication codes. Both sides <bcp14>MUST</bcp14> c
ompute the
keys Kms2 and Kmp2, as defined in <xref target="keyderivation" format="
default"/>,
and the message authentication codes MACs2 and MACp2, as defined in <xr
ef
target="messagedatafields" format="default"/>. Both sides <bcp14>MUST</
bcp14>
compare the received message authentication code with a locally compute
d value.</t>
<t>The rules by which the peer compares the received MACs2 are nontriv
ial because,
in addition to authenticating the current exchange, MACs2 may confirm t
he success or
failure of a recent cryptosuite upgrade. The peer processes the final r
equest
(Type=9) as follows:</t>
<ol spacing="normal" type="1">
<li>The peer first compares the received MACs2 value with one it comp
uted 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 CryptosuitepPre
v and KzPrev
fields of the persistent EAP-NOOB association. It does this because t
he received
MACs2 confirms that the peer and server share the same Cryptosuitep a
nd Kz, and
any previous values must no longer be accepted.</li>
<li>On the other hand, if the peer finds that the received MACs2 val
ue does not
match the one it computed locally with Kz, the peer checks whether th
e KzPrev
field in the persistent EAP-NOOB association stores a key. If it does
, the peer
repeats the key derivation (<xref target="keyderivation" format="defa
ult"/>) and
local MACs2 computation (<xref target="messagedatafields" format="def
ault"/>)
using KzPrev in place of Kz. If this second computed MACs2 matches th
e received
value, the match indicates synchronization failure caused by the loss
of the last
response (Type=9) in a previously attempted cryptosuite upgrade. In t
his case, the
peer rolls back that upgrade by overwriting Cryptosuitep with Cryptos
uitepPrev and
Kz with KzPrev in the persistent EAP-NOOB association. It also clears
the
CryptosuitepPrev and KzPrev fields.</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 associ
ation with
the negotiated Cryptosuitep and the newly derived Kz value. To prepar
e for
possible synchronization failure caused by the loss of the final resp
onse (Type=9)
during cryptosuite upgrade, the peer copies the old Cryptosuitep and
Kz values in
the persistent EAP-NOOB association to the CryptosuitepPrev and KzPre
v fields.</li>
<li>Finally, if the peer finds that the received MACs2 does not matc
h either of
the two values that it computed locally (or one value if no KzPrev wa
s stored),
the peer sends an error message (error code 4001, see <xref
target="cryptofailure" format="default"/>), which causes the Reconnec
t Exchange
to end in EAP-Failure.</li>
</ol>
<t>The server rules for processing the final message are simpler than
the peer rules
because the server does not store previous keys and it never rolls back
a
cryptosuite upgrade. Upon receiving the final response (Type=9), the se
rver 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 serve
r 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 err
or message
(error code 4001), and the Reconnect Exchange ends in EAP-Failure.</t>
<t>The endpoints <bcp14>MAY</bcp14> send updated NewNAI, ServerInfo, a
nd PeerInfo
objects in the Reconnect Exchange. When there is no update to the value
s, they
<bcp14>SHOULD</bcp14> omit this information from the messages. If the N
ewNAI was
sent, each side updates NAI in the persistent EAP-NOOB association when
moving to
the Registered (4) state.</t>
<figure anchor="fig-reconnect">
<name>Reconnect Exchange</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
EAP Peer EAP Server EAP Peer EAP Server
| ...continuing from common handshake | | ...continuing from common handshake |
| | | |
|<----------- EAP-Request/EAP-NOOB ----------------| |<----------- EAP-Request/EAP-NOOB ----------------|
| (Type=7,Vers,PeerId,Cryptosuites, | | (Type=7,Vers,PeerId,Cryptosuites, |
| [NewNAI],[ServerInfo]) | | [NewNAI],[ServerInfo]) |
| | | |
| | | |
|------------ EAP-Response/EAP-NOOB -------------->| |------------ EAP-Response/EAP-NOOB -------------->|
| (Type=7,Verp,PeerId,Cryptosuitep,[PeerInfo])| | (Type=7,Verp,PeerId,Cryptosuitep,[PeerInfo])|
skipping to change at line 659 skipping to change at line 1152
|<----------- EAP-Request/EAP-NOOB ----------------| |<----------- EAP-Request/EAP-NOOB ----------------|
| (Type=9,PeerId,MACs2) | | (Type=9,PeerId,MACs2) |
| | | |
| | | |
|------------ EAP-Response/EAP-NOOB -------------->| |------------ EAP-Response/EAP-NOOB -------------->|
| (Type=9,PeerId,MACp2) | | (Type=9,PeerId,MACp2) |
| | | |
| | | |
|<----------- EAP-Success -------------------------| |<----------- EAP-Success -------------------------|
| | | |
]]> ]]></artwork>
</artwork> </figure>
</figure>
</t>
</section> </section>
<section anchor="userreset" numbered="true" toc="default">
<section title="User reset" anchor="userreset"> <name>User Reset</name>
<t> <t>As shown in the association state machine in <xref target="fig-stat
As shown in the association state machine in <xref target="fig-state emachine"
machine"/>, the only specified way for the association to return from the Regist format="default"/>, the only specified way for the association to retur
ered state (4) to the Unregistered state (0) is through user-initiated reset. Af n from the
ter the reset, a new OOB message will be needed to establish a new association b Registered (4) state to the Unregistered (0) state is through user-init
etween the EAP server and peer. Typical situations in which the user reset is re iated reset.
quired are when the other side has accidentally lost the persistent EAP-NOOB ass After the reset, a new OOB message will be needed to establish a new as
ociation data, or when the peer device is decommissioned. sociation
</t> between the EAP server and peer. Typical situations in which the user r
<t> eset is
The server could detect that the peer is in the Registered or Reconn required are when the other side has accidentally lost the persistent E
ecting state but the server itself is in one of the ephemeral states 0..2 (inclu AP-NOOB
ding situations where the server does not recognize the PeerId). In this case, e association data or when the peer device is decommissioned.</t>
ffort should be made to recover the persistent server state, for example, from a <t>The server could detect that the peer is in the Registered or Recon
backup storage - especially if many peer devices are similarly affected. If tha necting state,
t is not possible, the EAP server SHOULD log the error or notify an administrato but the server itself is in one of the ephemeral states 0..2 (including
r. The only way to continue from such a situation is by having the user reset th situations
e peer device. where the server does not recognize the PeerId). In this case, effort s
</t> hould be made
<t> to recover the persistent server state, for example, from a backup stor
On the other hand, if the peer is in any of the ephemeral states 0.. age --
2, including the Unregistered state, the server will treat the peer as a new pee especially if many peer devices are similarly affected. If that is not
r device and allocate a new PeerId to it. The PeerInfo can be used by the user a possible, the
s a clue to which physical device has lost its state. However, there is no secur EAP server <bcp14>SHOULD</bcp14> log the error or notify an administrat
e way of matching the "new" peer with the old PeerId without repeating the OOB S or. The only
tep. This situation will be resolved when the user performs the OOB Step and, th way to continue from such a situation is by having the user reset the p
us, identifies the physical peer device. The server user interface MAY support s eer
ituations where the "new" peer is actually a previously registered peer that has device.</t>
been reset by a user or otherwise lost its persistent data. In those cases, the <t>On the other hand, if the peer is in any of the ephemeral states 0.
user could choose to merge the new peer identity with the old one in the server .2, including
. The alternative is to treat the device just like a new peer. the Unregistered state, the server will treat the peer as a new peer de
</t> vice 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 sit
uation will
be resolved when the user performs the OOB Step and thus identifies the
physical
peer device. The server user interface <bcp14>MAY</bcp14> support situa
tions where
the "new" peer is actually a previously registered peer that has been r
eset by a
user or otherwise lost its persistent data. In those cases, the user co
uld choose to
merge the new peer identity with the old one in the server. The alterna
tive is to
treat the device just like a new peer.</t>
</section> </section>
</section> </section>
<section anchor="keyderivation" numbered="true" toc="default">
<section title="Key derivation" anchor="keyderivation"> <name>Key Derivation</name>
<t> <t>EAP-NOOB derives the EAP output values MSK and EMSK and other secret
EAP-NOOB derives the EAP output values MSK and EMSK and other secret k keying
eying material from the output of an Ephemeral Elliptic Curve Diffie-Hellman (EC material from the output of an Ephemeral Elliptic Curve Diffie-Hellman (E
DHE) algorithm following the NIST specification <xref target="NIST-DH"/>. In NIS CDHE)
T terminology, we use a C(2e, 0s, ECC CDH) scheme, i.e., two ephemeral keys and algorithm following the NIST specification <xref target="NIST-DH" format=
no static keys. In the Initial and Reconnect Exchanges, the server and peer comp "default"/>.
ute the ECDHE shared secret Z as defined in <xref target="NIST-DH">section 6.1.2 In NIST terminology, we use a C(2e, 0s, ECC CDH) scheme, i.e., two epheme
of the NIST specification</xref>. In the Completion and Reconnect Exchanges, th ral keys and
e server and peer compute the secret keying material from Z with the one-step ke no static keys. In the Initial Exchange and Reconnect Exchange, the serve
y derivation function (KDF) defined in section 5.8.2.1 of the NIST specification r and peer
. The auxiliary function H is a hash function, and it is taken from the negotiat compute the ECDHE shared secret Z, as defined in Section 6.1.2 of the NIS
ed cryptosuite. T specification <xref target="NIST-DH" />. In the Completion
</t> Exchange and
<texttable title="Keying modes" anchor="keyingmodes"> Reconnect Exchange, the server and peer compute the secret keying materia
<ttcol>KeyingMode</ttcol> l from Z
<ttcol>Description</ttcol> with the one-step key derivation function (KDF) defined in Section 5.8.2.
<c>0</c><c>Completion Exchange (always with ECDHE)</c> 1 of the NIST
<c></c><c></c> specification. The auxiliary function H is a hash function, and it is tak
<c>1</c><c>Reconnect Exchange, rekeying without ECDHE</c> en from the
<c></c><c></c> negotiated cryptosuite.</t>
<c>2</c><c>Reconnect Exchange, rekeying with ECHDE, no change in crypt <table anchor="keyingmodes" align="center">
osuite</c> <name>Keying Modes</name>
<c></c><c></c> <thead>
<c>3</c><c>Reconnect Exchange, rekeying with ECDHE, new cryptosuite ne <tr>
gotiated</c> <th align="left">KeyingMode</th>
</texttable> <th align="left">Description</th>
<t> </tr>
The key derivation has four different modes (KeyingMode), which are sp </thead>
ecified in <xref target="keyingmodes"/>. <xref target="table-keyderivationinput" <tbody>
/> defines the inputs to KDF in each KeyingMode. <tr>
</t> <td align="left">0</td>
<t> <td align="left">Completion Exchange (always with ECDHE)</td>
In the Completion Exchange (KeyingMode=0), the input Z comes from the </tr>
preceding Initial exchange. KDF takes some additional inputs (FixedInfo), for wh <tr>
ich we use the concatenation format defined in <xref target="NIST-DH">section 5. <td align="left">1</td>
8.2.1.1 of the NIST specification</xref>. FixedInfo consists of the AlgorithmId, <td align="left">Reconnect Exchange, rekeying without ECDHE</td>
PartyUInfo, PartyVInfo, and SuppPrivInfo fields. The first three fields are fix </tr>
ed-length bit strings, and SuppPrivInfo is a variable-length string with a one-b <tr>
yte Datalength counter. AlgorithmId is the fixed-length 8-byte ASCII string "EAP <td align="left">2</td>
-NOOB". The other input values are the server and peer nonces. In the Completion <td align="left">Reconnect Exchange, rekeying with ECHDE, no chang
Exchange, the inputs also include the secret nonce Noob from the OOB message. e in
</t> cryptosuite</td>
<t> </tr>
In the simplest form of the Reconnect Exchange (KeyingMode=1), fresh n <tr>
onces are exchanged but no ECDHE keys are sent. In this case, input Z to the KDF <td align="left">3</td>
is replaced with the shared key Kz from the persistent EAP-NOOB association. Th <td align="left">Reconnect Exchange, rekeying with ECDHE, new cryp
e result is rekeying without the computational cost of the ECDHE exchange, but a tosuite
lso without forward secrecy. negotiated</td>
</t> </tr>
<t> </tbody>
When forward secrecy is desired in the Reconnect Exchange (KeyingMode= </table>
2 or KeyingMode=3), both nonces and ECDHE keys are exchanged. Input Z is the fre <t>The key derivation has four different modes (KeyingMode), which are s
sh shared secret from the ECDHE exchange with PKs2 and PKp2. The inputs also inc pecified in
lude the shared secret Kz from the persistent EAP-NOOB association. This binds t <xref target="keyingmodes" format="default"/>. <xref target="tab-keyderiv
he rekeying output to the previously authenticated keys. ationinput"
</t> format="default"/> defines the inputs to KDF in each KeyingMode.</t>
<texttable title="Key derivation input" anchor="table-keyderivationinput <t>In the Completion Exchange (KeyingMode=0), the input Z comes from the
"> preceding
<ttcol>KeyingMode</ttcol> Initial exchange. The KDF takes some additional inputs (FixedInfo), for w
<ttcol>KDF input field</ttcol> hich we use
<ttcol>Value</ttcol> the
<ttcol>Length (bytes)</ttcol> concatenation format defined in Section
<c>0 Completion</c><c>Z</c><c>ECDHE shared secret from PKs and PKp</ 5.8.2.1.1 of the NIST specification <xref target="NIST-DH" />. FixedInfo
c><c>variable</c> consists of the AlgorithmId,
<c></c><c>AlgorithmId</c><c>"EAP-NOOB"</c><c>8</c> PartyUInfo, PartyVInfo, and SuppPrivInfo fields. The first three fields a
<c></c><c>PartyUInfo</c><c>Np</c><c>32</c> re
<c></c><c>PartyVInfo</c><c>Ns</c><c>32</c> fixed-length bit strings, and SuppPrivInfo is a variable-length string wi
<c></c><c>SuppPubInfo</c><c>(not allowed)</c><c></c> th a one-byte
<c></c><c>SuppPrivInfo</c><c>Noob</c><c>16</c> Datalength counter. AlgorithmId is the fixed-length, 8-byte ASCII string
<c></c><c></c><c></c><c></c> "EAP-NOOB".
<c>1</c><c>Z</c><c>Kz</c><c>32</c> The other input values are the server and peer nonces. In the Completion
<c>Reconnect,</c><c>AlgorithmId</c><c>"EAP-NOOB"</c><c>8</c> Exchange, the
<c>rekeying</c><c>PartyUInfo</c><c>Np2</c><c>32</c> inputs also include the secret nonce Noob from the OOB message.</t>
<c>without</c><c>PartyVInfo</c><c>Ns2</c><c>32</c> <t>In the simplest form of the Reconnect Exchange (KeyingMode=1), fresh
<c>ECDHE</c><c>SuppPubInfo</c><c>(not allowed)</c><c></c> nonces are
<c></c><c>SuppPrivInfo</c><c>(null)</c><c>0</c> exchanged, but no ECDHE keys are sent. In this case, input Z to the KDF i
<c></c><c></c><c></c><c></c> s replaced
<c>2 or 3 Reconnect,</c><c>Z</c><c>ECDHE shared secret from PKs2 and P with the shared key Kz from the persistent EAP-NOOB association. The resu
Kp2</c><c>variable</c> lt is
<c>rekeying,</c><c>AlgorithmId</c><c>"EAP-NOOB"</c><c>8</c> rekeying without the computational cost of the ECDHE exchange but also wi
<c>with ECDHE,</c><c>PartyUInfo</c><c>Np2</c><c>32</c> thout
<c>same or new</c><c>PartyVInfo</c><c>Ns2</c><c>32</c> forward secrecy.</t>
<c>cryptosuite</c><c>SuppPubInfo</c><c>(not allowed)</c><c></c> <t>When forward secrecy is desired in the Reconnect Exchange (KeyingMode
<c></c><c>SuppPrivInfo</c><c>Kz</c><c>32</c> =2 or
</texttable> KeyingMode=3), both nonces and ECDHE keys are exchanged. Input Z is the f
<t> resh shared
<xref target="table-keyderivationoutput"/> defines how the output byte secret from the ECDHE exchange with PKs2 and PKp2. The inputs also includ
s of KDF are used. In addition to the EAP output values MSK and EMSK, the server e the shared
and peer derive another shared secret key AMSK, which MAY be used for applicati secret Kz from the persistent EAP-NOOB association. This binds the rekeyi
on-layer security. Further output bytes are used internally by EAP-NOOB for the ng output to
message authentication keys (Kms, Kmp, Kms2, Kmp2). the previously authenticated keys.</t>
</t> <table anchor="tab-keyderivationinput" align="center">
<t> <name>Key Derivation Input</name>
The Completion Exchange (KeyingMode=0) produces the shared secret Kz, <thead>
which the server and peer store in the persistent EAP-NOOB association. When a n <tr>
ew cryptosuite is negotiated in the Reconnect Exchange (KeyingMode=3), it simila <th align="left">KeyingMode</th>
rly produces a new Kz. In that case, the server and peer update both the cryptos <th align="left">KDF input field</th>
uite and Kz in the persistent EAP-NOOB association. Additionally, the peer store <th align="left">Value</th>
s the previous Cryptosuitep and Kz values in the CryptosuitepPrev and KzPrev fie <th align="left">Length (bytes)</th>
lds of the persistent EAP-NOOB association. </tr>
</t> </thead>
<texttable title="Key derivation output" anchor="table-keyderivationoutp <tbody>
ut"> <tr>
<ttcol>KeyingMode</ttcol> <td align="left" rowspan="6">0 Completion</td>
<ttcol>KDF output bytes</ttcol> <td align="left">Z</td>
<ttcol>Used as</ttcol> <td align="left">ECDHE shared secret from PKs and PKp</td>
<ttcol>Length (bytes)</ttcol> <td align="left">variable</td>
<c>0</c><c>0..63</c><c>MSK</c><c>64</c> </tr>
<c>Completion</c><c>64..127</c><c>EMSK</c><c>64</c> <tr>
<c></c><c>128..191</c><c>AMSK</c><c>64</c> <td align="left">AlgorithmId</td>
<c></c><c>192..223</c><c>MethodId</c><c>32</c> <td align="left">"EAP-NOOB"</td>
<c></c><c>224..255</c><c>Kms</c><c>32</c> <td align="left">8</td>
<c></c><c>256..287</c><c>Kmp</c><c>32</c> </tr>
<c></c><c>288..319</c><c>Kz</c><c>32</c> <tr>
<c></c><c></c><c></c><c></c> <td align="left">PartyUInfo</td>
<c>1 or 2</c><c>0..63</c><c>MSK</c><c>64</c> <td align="left">Np</td>
<c>Reconnect,</c><c>64..127</c><c>EMSK</c><c>64</c> <td align="left">32</td>
<c>rekeying</c><c>128..191</c><c>AMSK</c><c>64</c> </tr>
<c>without ECDHE,</c><c>192..223</c><c>MethodId</c><c>32</c> <tr>
<c>or with ECDHE</c><c>224..255</c><c>Kms2</c><c>32</c> <td align="left">PartyVInfo</td>
<c>and unchanged</c><c>256..287</c><c>Kmp2</c><c>32</c> <td align="left">Ns</td>
<c>cryptosuite</c><c></c><c></c><c></c> <td align="left">32</td>
<c></c><c></c><c></c><c></c> </tr>
<c></c><c></c><c></c><c></c> <tr>
<c>3 Reconnect,</c><c>0..63</c><c>MSK</c><c>64</c> <td align="left">SuppPubInfo</td>
<c>rekeying</c><c>64..127</c><c>EMSK</c><c>64</c> <td align="left">(not allowed)</td>
<c>with ECDHE,</c><c>128..191</c><c>AMSK</c><c>64</c> <td align="left"/>
<c>new cryptosuite</c><c>192..223</c><c>MethodId</c><c>32</c> </tr>
<c></c><c>224..255</c><c>Kms2</c><c>32</c> <tr>
<c></c><c>256..287</c><c>Kmp2</c><c>32</c> <td align="left">SuppPrivInfo</td>
<c></c><c>288..319</c><c>Kz</c><c>32</c> <td align="left">Noob</td>
</texttable> <td align="left">16</td>
<t> </tr>
Finally, every EAP method must export a Server-Id, Peer-Id, and Sessio <tr>
n-Id <xref target="RFC5247"/>. In EAP-NOOB, the exported Peer-Id is the PeerId w <td align="left" rowspan="6">1 Reconnect, rekeying without ECDHE</
hich the server has assigned to the peer. The exported Server-Id is a zero-lengt td>
h string (i.e., null string) because EAP-NOOB neither knows nor assigns any serv <td align="left">Z</td>
er identifier. The exported Session-Id is created by concatenating the Type-Code <td align="left">Kz</td>
xxx (TBA) with the MethodId, which is obtained from the KDF output as shown in <td align="left">32</td>
<xref target="table-keyderivationoutput"/>. </tr>
</t> <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 3 Reconnect, rekeying, with ECDH
E, same or new cryptosuite</td>
<td align="left">Z</td>
<td align="left">ECDHE shared secret from PKs2 and 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 E
MSK, the
server and peer derive another shared secret key AMSK (Application Main S
ession Key),
which <bcp14>MAY</bcp14> be used for
application-layer security. Further output bytes are used internally by E
AP-NOOB for
the message authentication keys (Kms, Kmp, Kms2, and 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 prod
uces 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 previo
us
Cryptosuitep and Kz values in the CryptosuitepPrev and KzPrev fields of t
he persistent
EAP-NOOB association.</t>
<table anchor="tab-keyderivationoutput" align="center">
<name>Key Derivation Output</name>
<thead>
<tr>
<th align="left">KeyingMode</th>
<th align="left">KDF output 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 EC
DHE, 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 Sessi
on-Id <xref
target="RFC5247" format="default"/>. In EAP-NOOB, the exported Peer-Id is
the PeerId
that the server has assigned to the peer. The exported Server-Id is a zer
o-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-Code 0x38
(decimal value 56) with the
MethodId, which is obtained from the KDF output, as shown in <xref
target="tab-keyderivationoutput" format="default"/>.</t>
</section> </section>
<section anchor="failure" numbered="true" toc="default">
<section title="Error handling" anchor="failure"> <name>Error Handling</name>
<t> <t>Various error conditions in EAP-NOOB are handled by sending an error
Various error conditions in EAP-NOOB are handled by sending an error n notification
otification message (Type=0) instead of a next EAP request or response message. message (Type=0) instead of a next EAP request or response message. Both
Both the EAP server and the peer may send the error notification, as shown in <x the EAP
ref target="fig-servererror"/> and <xref target="fig-peererror"/>. After sending server and the peer may send the error notification, as shown in Figures
or receiving an error notification, the server MUST send an EAP-Failure (as req <xref
uired by <xref target="RFC3748"/> section 4.2). The notification MAY contain an target="fig-servererror" format="counter"/> and <xref target="fig-peererr
ErrorInfo field, which is a UTF-8 encoded text string with a maximum length of 5 or"
00 bytes. It is used for sending descriptive information about the error for log format="counter"/>. After sending or receiving an error notification, the
ging and debugging purposes. server
</t> <bcp14>MUST</bcp14> send an EAP-Failure (as required by <xref target="RFC
<t> 3748"
<figure anchor="fig-servererror" title="Error notification from server sectionFormat="comma" section="4.2"/>). The notification <bcp14>MAY</bcp1
to peer"> 4> contain an
<artwork align="center"> ErrorInfo field, which is a UTF-8-encoded text string with a maximum leng
<![CDATA[ th of 500
bytes. It is used for sending descriptive information about the error for
logging and
debugging purposes.</t>
<figure anchor="fig-servererror">
<name>Error Notification from Server to Peer</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
EAP Peer EAP Server EAP Peer EAP Server
... ... ... ...
| | | |
|<----------- EAP-Request/EAP-NOOB ----------------| |<----------- EAP-Request/EAP-NOOB ----------------|
| (Type=0,[PeerId],ErrorCode,[ErrorInfo]) | | (Type=0,[PeerId],ErrorCode,[ErrorInfo]) |
| | | |
| | | |
|<----------- EAP-Failure -------------------------| |<----------- EAP-Failure -------------------------|
| | | |
]]> ]]></artwork>
</artwork> </figure>
</figure> <figure anchor="fig-peererror">
</t> <name>Error Notification from Peer to Server</name>
<t> <artwork align="center" name="" type="" alt=""><![CDATA[
<figure anchor="fig-peererror" title="Error notification from peer to
server">
<artwork align="center">
<![CDATA[
EAP Peer EAP Server EAP Peer EAP Server
... ... ... ...
| | | |
|------------ EAP-Response/EAP-NOOB -------------->| |------------ EAP-Response/EAP-NOOB -------------->|
| (Type=0,[PeerId],ErrorCode,[ErrorInfo]) | | (Type=0,[PeerId],ErrorCode,[ErrorInfo]) |
| | | |
| | | |
|<----------- EAP-Failure -------------------------| |<----------- EAP-Failure -------------------------|
| | | |
]]> ]]></artwork>
</artwork> </figure>
</figure> <t>After the exchange fails due to an error notification, the server and
</t> peer set the
<t> association state as follows. In the Initial Exchange, both the sender an
After the exchange fails due to an error notification, the server and d recipient
peer set the association state as follows. In the Initial Exchange, both the sen of the error notification <bcp14>MUST</bcp14> set the association state t
der and recipient of the error notification MUST set the association state to th o the
e Unregistered (0) state. In the Waiting and Completion Exchanges, each side MUS Unregistered (0) state. In the Waiting Exchange and Completion Exchange,
T remain in its old state as if the failed exchange had not taken place, with th each side
e exception that the recipient of error code 2003 processes it as specified in < <bcp14>MUST</bcp14> remain in its old state as if the failed exchange had
xref target="completionexchange"/>. In the Reconnect Exchange, both sides MUST s not taken
et the association state to the Reconnecting (3) state. place, with the exception that the recipient of error code 2003 processes
</t> it as
<t> specified in <xref target="completionexchange" format="default"/>. In the
Errors that occur in the OOB channel are not explicitly notified in-ba Reconnect
nd. Exchange, both sides <bcp14>MUST</bcp14> set the association state to the
</t> Reconnecting
(3) state.</t>
<section title="Invalid messages" anchor="invalidmessages"> <t>Errors that occur in the OOB channel are not explicitly notified in-b
<t> and.</t>
If the NAI structure is invalid, the server SHOULD send the error co <section anchor="invalidmessages" numbered="true" toc="default">
de 1001 to the peer. The recipient of an EAP-NOOB request or response SHOULD sen <name>Invalid Messages</name>
d the following error codes back to the sender: 1002 if it cannot parse the mess <t>If the NAI structure is invalid, the server <bcp14>SHOULD</bcp14> s
age as a JSON object or the top-level JSON object has missing or unrecognized me end the error
mbers; 1003 if a data field has an invalid value, such as an integer out of rang code 1001 to the peer. The recipient of an EAP-NOOB request or response
e, and there is no more specific error code available; 1004 if the received mess <bcp14>SHOULD</bcp14> send the following error codes back to the sender
age type was unexpected in the current state; 2004 if the PeerId has an unexpect : 1002 if it
ed value; 2003 if the NoobId is not recognized; and 1005 if the ECDHE key is inv cannot parse the message as a JSON object or the top-level JSON object
alid. has missing
</t> or unrecognized members; 1003 if a data field has an invalid value, suc
h as an
integer out of range, and there is no more specific error code availabl
e; 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 is invalid.</t>
</section> </section>
<section anchor="unwantedpeer" numbered="true" toc="default">
<section title="Unwanted peer" anchor="unwantedpeer"> <name>Unwanted Peer</name>
<t> <t>The preferred way for the EAP server to rate limit EAP-NOOB connect
The preferred way for the EAP server to rate limit EAP-NOOB connecti ions from a
ons from a peer is to use the SleepTime parameter in the Waiting Exchange. Howev peer is to use the SleepTime parameter in the Waiting Exchange. However
er, if the EAP server receives repeated EAP-NOOB connections from a peer which a , if the EAP
pparently should not connect to this server, the server MAY indicate that the co server receives repeated EAP-NOOB connections from a peer that apparent
nnections are unwanted by sending the error code 2001. After receiving this erro ly should
r message, the peer MAY refrain from reconnecting to the same EAP server and, if not connect to this server, the server <bcp14>MAY</bcp14> indicate that
possible, both the EAP server and peer SHOULD indicate this error condition to the
the user or server administrator. However, in order to avoid persistent denial o connections are unwanted by sending the error code 2001. After receivin
f service, peer devices that are unable to alert a user SHOULD continue to try t g this error
o reconnect infrequently (e.g., approximately every 3600 seconds). message, the peer <bcp14>MAY</bcp14> refrain from reconnecting to the s
</t> ame EAP
server, and, if possible, both the EAP server and peer <bcp14>SHOULD</b
cp14>
indicate
this error condition to the user or server administrator. However, in o
rder to avoid
persistent denial of service, peer devices that are unable to alert a u
ser
<bcp14>SHOULD</bcp14> continue to try to reconnect infrequently (e.g.,
approximately
every 3600 seconds). </t>
</section> </section>
<section anchor="statemismatch" numbered="true" toc="default">
<section title="State mismatch" anchor="statemismatch"> <name>State Mismatch</name>
<t> <t>In the states indicated by "-" in <xref target="tab-exchanges" form
In the states indicated by "-" in <xref target="table-exchanges"/> i at="default"/>
n <xref target="exchangeappendix"/>, user action is required to reset the associ in <xref target="exchangeappendix" format="default"/>, user action is r
ation state or to recover it, for example, from backup storage. In those cases, equired to
the server sends the error code 2002 to the peer. If possible, both the EAP serv reset the association state or to recover it, for example, from backup
er and peer SHOULD indicate this error condition to the user or server administr storage. In
ator. those cases, the server sends the error code 2002 to the peer. If possi
</t> ble, both the
EAP server and peer <bcp14>SHOULD</bcp14> indicate this error condition
to the user
or server administrator.</t>
</section> </section>
<section anchor="negotiationfailure" numbered="true" toc="default">
<section title="Negotiation failure" anchor="negotiationfailure"> <name>Negotiation Failure</name>
<t> <t>If there is no matching protocol version, the peer sends the error
If there is no matching protocol version, the peer sends the error c code 3001 to
ode 3001 to the server. If there is no matching cryptosuite, the peer sends the the server. If there is no matching cryptosuite, the peer sends the err
error code 3002 to the server. If there is no matching OOB direction, the peer s or code 3002
ends the error code 3003 to the server. to the server. If there is no matching OOB direction, the peer sends th
</t> e error code
<t> 3003 to the server.</t>
In practice, there is no way of recovering from these errors without <t>In practice, there is no way of recovering from these errors withou
software or hardware changes. If possible, both the EAP server and peer SHOULD t software or
indicate these error conditions to the user. hardware changes. If possible, both the EAP server and peer <bcp14>SHOU
</t> LD</bcp14>
indicate these error conditions to the user.</t>
</section> </section>
<section anchor="cryptofailure" numbered="true" toc="default">
<section title="Cryptographic verification failure" anchor="cryptofailur <name>Cryptographic Verification Failure</name>
e"> <t>If the receiver of the OOB message detects an unrecognized PeerId o
<t> r incorrect
If the receiver of the OOB message detects an unrecognized PeerId or fingerprint (Hoob) in the OOB message, the receiver <bcp14>MUST</bcp14>
incorrect fingerprint (Hoob) in the OOB message, the receiver MUST remain in th remain in
e Waiting for OOB state (1) as if no OOB message was received. The receiver SHOU the Waiting for OOB (1) state as if no OOB message was received. The re
LD indicate the failure to accept the OOB message to the user. No in-band error ceiver
message is sent. <bcp14>SHOULD</bcp14> indicate the failure to accept the OOB message to
</t> the user. No
<t> in-band error message is sent.</t>
Note that if the OOB message was delivered from the server to the pe <t>Note that if the OOB message was delivered from the server to the p
er and the peer does not recognize the PeerId, the likely cause is that the user eer and the
has unintentionally delivered the OOB message to the wrong peer device. If poss peer does not recognize the PeerId, the likely cause is that the user h
ible, the peer SHOULD indicate this to the user; however, the peer device may no as
t have the capability for many different error indications to the user, and it M unintentionally delivered the OOB message to the wrong peer device. If
AY use the same indication as in the case of an incorrect fingerprint. possible, the
</t> peer <bcp14>SHOULD</bcp14> indicate this to the user; however, the peer
<t> device may
The rationale for the above is that the invalid OOB message could ha not have the capability for many different error indications to the use
ve been presented to the receiver by mistake or intentionally by a malicious par r, and it
ty and, thus, it should be ignored in the hope that the honest user will soon de <bcp14>MAY</bcp14> use the same indication as in the case of an incorre
liver a correct OOB message. ct
</t> fingerprint.</t>
<t> <t>The rationale for the above is that the invalid OOB message could h
If the EAP server or peer detects an incorrect message authenticatio ave been
n code (MACs, MACp, MACs2, MACp2), it sends the error code 4001 to the other sid presented to the receiver by mistake or intentionally by a malicious pa
e. As specified in the beginning of <xref target="failure"/>, the failed Complet rty;
ion Exchange will not result in server or peer state changes while an error in t thus, it should be ignored in the hope that the honest user will soon d
he Reconnect Exchange will put both sides to the Reconnecting (3) state and thus eliver a
lead to another reconnect attempt. correct OOB message.</t>
</t> <t>If the EAP server or peer detects an incorrect message authenticati
<t> on code (MACs,
The rationale for this is that the invalid cryptographic message may MACp, MACs2, or MACp2), it sends the error code 4001 to the other side.
have been spoofed by a malicious party and, thus, it should be ignored. In part As
icular, a spoofed message on the in-band channel should not force the honest use specified in
r to perform the OOB Step again. In practice, however, the error may be caused b the beginning of <xref target="failure" format="default"/>, the failed
y other failures, such as a software bug. For this reason, the EAP server MAY li Completion
mit the rate of peer connections with SleepTime after the above error. Also, the Exchange will not result in server or peer state changes, while an erro
re SHOULD be a way for the user to reset the peer to the Unregistered state (0), r in the
so that the OOB Step can be repeated as the last resort. Reconnect Exchange will put both sides to the Reconnecting (3) state an
</t> d thus lead
to another reconnect attempt.</t>
<t>The rationale for this is that the invalid cryptographic message ma
y have been
spoofed by a malicious 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 ot
her failures,
such as a software bug. For this reason, the EAP server <bcp14>MAY</bcp
14> limit the
rate of peer connections with SleepTime after the above error. Also, th
ere
<bcp14>SHOULD</bcp14> be a way for the user to reset the peer to the Un
registered
(0) state so that the OOB Step can be repeated as the last resort.</t>
</section> </section>
<section anchor="appfailure" numbered="true" toc="default">
<section title="Application-specific failure" anchor="appfailure"> <name>Application-Specific Failure</name>
<t> <t>Applications <bcp14>MAY</bcp14> define new error messages for failu
Applications MAY define new error messages for failures that are spe res that are
cific to the application or to one type of OOB channel. They MAY also use the ge specific to the application or to one type of OOB channel. They <bcp14>
neric application-specific error code 5001, or the error codes 5002 and 5004, wh MAY</bcp14>
ich have been reserved for indicating invalid data in the ServerInfo and PeerInf also use the generic application-specific error code 5001 or the error
o fields, respectively. Additionally, anticipating OOB channels that make use of codes 5002
a URL, the error code 5003 has been reserved for indicating an invalid server U and 5004, which have been reserved for indicating invalid data in the S
RL. erverInfo and
</t> PeerInfo fields, respectively. Additionally, anticipating OOB channels
that make use
of a URL, the error code 5003 has been reserved for indicating an inval
id server
URL.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="serverinfo-peerinfo-meaning" numbered="true" toc="default">
<section title="ServerInfo and PeerInfo contents" anchor="serverinfo-peerinf <name>ServerInfo and PeerInfo Contents</name>
o-meaning"> <t>The ServerInfo and PeerInfo fields in the Initial Exchange and Reconnec
<t> t Exchange
The ServerInfo and PeerInfo fields in the Initial Exchange and Reconnect enable the server and peer, respectively, to send information about themse
Exchange enable the server and peer, respectively, to send information about th lves to the
emselves to the other endpoint. They contain JSON objects whose structure may be other endpoint. They contain JSON objects whose structure may be specified
specified separately for each application and each type of OOB channel. ServerI separately
nfo and PeerInfo MAY contain auxiliary data needed for the OOB channel messaging for each application and each type of OOB channel. ServerInfo and PeerInfo
and for EAP channel binding (see <xref target="channel-binding"/>). This sectio <bcp14>MAY</bcp14> contain auxiliary data needed for the OOB channel messa
n describes the optional initial data fields for ServerInfo and PeerInfo registe ging and for
red by this specification. Further specifications may request new application-sp EAP channel binding (see <xref target="channel-binding" format="default"/>
ecific ServerInfo and PeerInfo data fields from IANA (see <xref target="serverin ). This
fo-data-fields"/> and <xref target="peerinfo-data-fields"/>). section describes the optional initial data fields for ServerInfo and Peer
Info
registered by this specification. Further specifications may request new
application-specific ServerInfo and PeerInfo data fields from IANA (see Se
ctions <xref
target="serverinfo-data-fields" format="counter"/> and <xref
target="peerinfo-data-fields" format="counter"/>).
</t> </t>
<texttable title="ServerInfo data fields" anchor="table-serverinfo-meaning <table anchor="tab-serverinfo-meaning" align="center">
"> <name>ServerInfo Data Fields</name>
<ttcol>Data Field</ttcol> <thead>
<ttcol>Description</ttcol> <tr>
<c>Type</c><c>Type-tag string that can be used by the peer as a hint for <th align="left">Data Field</th>
how to interpret the ServerInfo contents.</c> <th align="left">Description</th>
<c></c><c></c> </tr>
<c>ServerName</c><c>String that may be used to aid human identification </thead>
of the server.</c> <tbody>
<c></c><c></c> <tr>
<c>ServerURL</c><c>Prefix string when the OOB message is formatted as a <td align="left">Type</td>
URL, as suggested in <xref target="urloob"/>.</c> <td align="left">Type-tag string that can be used by the peer as a h
<c></c><c></c> int for how to
<c>SSIDList</c><c>List of IEEE 802.11 wireless network identifier (SSID) interpret the ServerInfo contents.</td>
strings used for roaming support, as suggested in <xref target="roaming"/>. JSO </tr>
N array of ASCII encoded SSID strings.</c> <tr>
<c></c><c></c> <td align="left">ServerName</td>
<c>Base64SSIDList</c><c>List of IEEE 802.11 wireless network identifier <td align="left">String that may be used to aid human identification
(SSID) strings used for roaming support, as suggested in <xref target="roaming"/ of the
>. JSON array of SSIDs, each of which is base64url encoded without padding. Peer server.</td>
s SHOULD send at most one of the fields SSIDList and Base64SSIDList in PeerInfo, </tr>
and the server SHOULD ignore SSIDList if Base64SSIDList is included.</c> <tr>
</texttable> <td align="left">ServerURL</td>
<texttable title="PeerInfo data fields" anchor="table-peerinfo-meaning"> <td align="left">Prefix string when the OOB message is formatted as
<ttcol>Data Field</ttcol> a URL, as
<ttcol>Description</ttcol> suggested in <xref target="urloob" format="default"/>.</td>
<c>Type</c><c>Type-tag string that can be used by the server as a hint f </tr>
or how to interpret the PeerInfo contents.</c> <tr>
<c></c><c></c> <td align="left">SSIDList</td>
<c>PeerName</c><c>String that may be used to aid human identification of <td align="left">List of IEEE 802.11 wireless network service set id
the peer.</c> entifier
<c></c><c></c> (SSID) strings
<c>Manufacturer</c><c>Manufacturer or brand string.</c> used for roaming support, as suggested in <xref target="roaming"
<c></c><c></c> format="default"/>. JSON array of ASCII-encoded SSID strings.</td>
<c>Model</c><c>Manufacturer-specified model string.</c> </tr>
<c></c><c></c> <tr>
<c>SerialNumber</c><c>Manufacturer-assigned serial number.</c> <td align="left">Base64SSIDList</td>
<c></c><c></c> <td align="left">List of IEEE 802.11 wireless network identifier (SS
<c>MACAddress</c><c>Peer link-layer identifier (EUI-48) in the 12-digit ID) strings
base-16 form <xref target="EUI-48"/>. The string MAY be in upper or lower case a used for roaming support, as suggested in <xref target="roaming"
nd MAY include additional colon ':' or dash '-' characters that MUST be ignored format="default"/>. JSON array of SSIDs, each of which is base64url-e
by the server.</c> ncoded
<c></c><c></c> without padding. Peers <bcp14>SHOULD</bcp14> send at most one of the
<c>SSID</c><c>IEEE 802.11 network SSID for channel binding. The SSID is fields
an ASCII string.</c> SSIDList and Base64SSIDList in PeerInfo, and the server <bcp14>SHOULD
<c></c><c></c> </bcp14>
<c>Base64SSID</c><c>IEEE 802.11 network SSID for channel binding. The SS ignore SSIDList if Base64SSIDList is included.</td>
ID is base64url encoded. Peer SHOULD send at most one of the fields SSID and Bas </tr>
e64SSID in PeerInfo, and the server SHOULD ignore SSID if Base64SSID is included </tbody>
.</c> </table>
<c></c><c></c> <table anchor="tab-peerinfo-meaning" align="center">
<c>BSSID</c><c>Wireless network BSSID (EUI-48) in the 12-digit base-16 f <name>PeerInfo Data Fields</name>
orm <xref target="EUI-48"/> for channel binding. The string MAY be in upper or l <thead>
ower case and MAY include additional colon ':' or dash '-' characters that MUST <tr>
be ignored by the server.</c> <th align="left">Data Field</th>
<c></c><c></c> <th align="left">Description</th>
</texttable> </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 PeerInfo contents.</td>
</tr>
<tr>
<td align="left">PeerName</td>
<td align="left">String that may be used to aid human identification
of the
peer.</td>
</tr>
<tr>
<td align="left">Manufacturer</td>
<td align="left">Manufacturer or brand string.</td>
</tr>
<tr>
<td align="left">Model</td>
<td align="left">Manufacturer-specified model string.</td>
</tr>
<tr>
<td align="left">SerialNumber</td>
<td align="left">Manufacturer-assigned serial number.</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
<xref target="EUI-48" format="default"/>. The string <bcp14>MAY</bcp1
4> be in
upper or lower case and <bcp14>MAY</bcp14> include additional colon '
:' or dash
'-' characters that <bcp14>MUST</bcp14> be ignored by the server.</td
>
</tr>
<tr>
<td align="left">SSID</td>
<td align="left">IEEE 802.11 network SSID for channel binding. The S
SID is an
ASCII string.</td>
</tr>
<tr>
<td align="left">Base64SSID</td>
<td align="left">IEEE 802.11 network SSID for channel binding. The S
SID is
base64url encoded. Peer <bcp14>SHOULD</bcp14> send at most one of the
fields SSID
and Base64SSID in PeerInfo, and the server <bcp14>SHOULD</bcp14> igno
re SSID if
Base64SSID is included.</td>
</tr>
<tr>
<td align="left">BSSID</td>
<td align="left">Wireless network basic service set identifier (BSSI
D) (EUI-48)
in the 12-digit base-16 form
<xref target="EUI-48" format="default"/> for channel binding. The str
ing
<bcp14>MAY</bcp14> be in upper or lower case and <bcp14>MAY</bcp14> i
nclude
additional colon ':' or dash '-' characters that <bcp14>MUST</bcp14>
be ignored by
the server.</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="iana" numbered="true" toc="default">
<section title="IANA Considerations" anchor="iana"> <name>IANA Considerations</name>
<t> <t>This section provides information
This section provides guidance to the Internet Assigned Numbers Authorit regarding registration of values related to the EAP-NOOB method, in accord
y (IANA) regarding registration of values related to the EAP-NOOB protocol, in a ance with
ccordance with <xref target="RFC8126"/>. <xref target="RFC8126" format="default"/>.</t>
</t> <t>The EAP Method Type for EAP-NOOB (value 56) has been assigned in the "M
<t> ethod Types"
The EAP Method Type number for EAP-NOOB needs to be assigned in the Meth subregistry of the "Extensible Authentication Protocol (EAP) Registry".</t
od Types sub-registry of the Extensible Authentication Protocol (EAP) registry ( >
requested value = 56). <t>Per this memo, IANA has created and will maintain a new registry entitl
</t> ed "Nimble
<t> Out-of-Band Authentication for EAP Parameters (EAP-NOOB)" in the Extensibl
This memo also requires IANA to create and maintain a new registry entit e Authentication Protocol
led "Nimble out-of-band authentication for EAP Parameters" in the Extensible Aut (EAP) category. Also, IANA has created and will maintain the subregistries
hentication Protocol (EAP) registry. IANA is also requested to create and mainta defined in
in sub-registries defined in the following subsections. the following subsections. </t>
</t> <section anchor="cryptosuites" numbered="true" toc="default">
<section title="Cryptosuites" anchor="cryptosuites"> <name>Cryptosuites</name>
<t> <t>IANA has created and will maintain a new subregistry entitled "EAP-NO
IANA is requested to create and maintain a new sub-registry entitled OB
"EAP-NOOB Cryptosuites" in the "Nimble out-of-band authentication for EAP Parame Cryptosuites" in the "Nimble Out-of-Band Authentication for EAP Parameter
ters" registry. Cryptosuites are identified by an integer. Each cryptosuite MUST s (EAP-NOOB)" registry.
specify an ECDHE curve for the key exchange, encoding of the ECDHE public key a Cryptosuites are identified by an integer. Each cryptosuite <bcp14>MUST</
s a JWK object, and a cryptographic hash function for the fingerprint and HMAC c bcp14>
omputation and key derivation. The hash value output by the cryptographic hash f specify an ECDHE curve for the key exchange, encoding of the ECDHE public
unction MUST be at least 32 bytes in length. The initial values for this registr key as a JWK
y are: object, and a cryptographic hash function for the fingerprint and HMAC co
</t> mputation and
<texttable title="EAP-NOOB cryptosuites" anchor="table-cryptosuites"> key derivation. The hash value output by the cryptographic hash function
<ttcol>Cryptosuite</ttcol> <bcp14>MUST</bcp14> be at least 32 bytes in length. The initial values fo
<ttcol>Algorithms</ttcol> r this
<c>1</c><c>ECDHE curve Curve25519 <xref target="RFC7748"/>, public-key registry are:</t>
format <xref target="RFC7517"/>, hash function SHA-256 <xref target="RFC6234"/> <table anchor="tab-cryptosuites" align="center">
. The JWK encoding of Curve25519 public key is defined in <xref target="RFC8037" <name>EAP-NOOB Cryptosuites</name>
/>. For clarity: the "crv" parameter is "X25519", the "kty" parameter is "OKP", <thead>
and the public-key encoding contains only an x-coordinate.</c> <tr>
<c>2</c><c>ECDHE curve NIST P-256 <xref target="FIPS186-4"/>, public-k <th align="left">Cryptosuite</th>
ey format <xref target="RFC7517"/>, hash function SHA-256 <xref target="RFC6234" <th align="left">Algorithms</th>
/>. The JWK encoding of NIST P-256 public key is defined in <xref target="RFC751 </tr>
8"/>. For clarity: the "crv" parameter is "P-256", the "kty" parameter is "EC", </thead>
and the public-key encoding has both an x and y coordinates as defined in Sectio <tbody>
n 6.2.1 of <xref target="RFC7518"/>.</c> <tr>
</texttable> <td align="left">0</td>
<t> <td align="left">Reserved</td>
EAP-NOOB implementations MUST support Cryptosuite 1. Support for Crypt </tr>
osuite 2 is RECOMMENDED. An example of Cryptosuite 1 public-key encoded as a JWK <tr>
object is given below (line breaks are for readability only). <td align="left">1</td>
</t> <td align="left">ECDHE curve Curve25519 <xref target="RFC7748"
<t> format="default"/>, public-key format <xref target="RFC7517" format
"jwk":{"kty":"OKP","crv":"X25519","x":"3p7bfXt9wbTTW2HC7OQ1Nz-DQ8hbeGd ="default"/>,
Nrfx-FG-IK08"} hash function SHA-256 <xref target="RFC6234" format="default"/>. Th
</t> e JWK
<t> encoding of Curve25519 public key is defined in <xref target="RFC80
Assignment of new values for new cryptosuites MUST be done through IAN 37"
A with "Specification Required" as defined in <xref target="RFC8126"/>. format="default"/>. For clarity, the "crv" parameter is "X25519", t
</t> he "kty"
parameter is "OKP", and the public-key encoding contains only an
x-coordinate.</td>
</tr>
<tr>
<td align="left">2</td>
<td align="left">ECDHE curve NIST P-256 <xref target="FIPS186-4"
format="default"/>, public-key format <xref target="RFC7517" format
="default"/>,
hash function SHA-256 <xref target="RFC6234" format="default"/>. Th
e JWK
encoding of NIST P-256 public key is defined in <xref target="RFC75
18"
format="default"/>. For clarity, the "crv" parameter is "P-256", th
e "kty"
parameter is "EC", and the public-key encoding has both an x and y
coordinate,
as defined in <xref target="RFC7518" sectionFormat="of" section="6.
2.1"/>.</td>
</tr>
</tbody>
</table>
<t>EAP-NOOB implementations <bcp14>MUST</bcp14> support Cryptosuite 1. S
upport for
Cryptosuite 2 is <bcp14>RECOMMENDED</bcp14>. An example of a Cryptosuite
1 public-key
encoded as a JWK object is given below. (Line breaks are for readability
only.)</t>
<sourcecode type="json">
"jwk":{"kty":"OKP","crv":"X25519","x":"3p7bfXt9wbTTW2HC7OQ1Nz-
DQ8hbeGdNrfx-FG-IK08"}
</sourcecode>
<t>Assignment of new values for new cryptosuites <bcp14>MUST</bcp14> b
e done through
IANA with "Specification Required", as defined in <xref target="RFC812
6"
format="default"/>.</t>
</section> </section>
<section anchor="messagetypes" numbered="true" toc="default">
<section title="Message Types" anchor="messagetypes"> <name>Message Types</name>
<t> <t>IANA has created and will maintain a new subregistry entitled "EAP-NO
IANA is requested to create and maintain a new sub-registry entitled " OB
EAP-NOOB Message Types" in the "Nimble out-of-band authentication for EAP Parame Message Types" in the "Nimble Out-of-Band Authentication for EAP Paramete
ters" registry. EAP-NOOB request and response pairs are identified by an integer rs (EAP-NOOB)" registry.
Message Type. The initial values for this registry are: EAP-NOOB request and response pairs are identified by an integer Message
</t> Type. The
<texttable title="EAP-NOOB Message Types" anchor="table-messagetypes"> initial values for this registry are:</t>
<ttcol>Message Type</ttcol> <table anchor="tab-messagetypes" align="center">
<ttcol>Used in Exchange</ttcol> <name>EAP-NOOB Message Types</name>
<ttcol>Purpose</ttcol> <thead>
<c>1</c><c>All exchanges</c><c>PeerId and PeerState discovery</c> <tr>
<c></c><c></c><c></c> <th align="left">Message Type</th>
<c>2</c><c>Initial</c><c>Version, cryptosuite and parameter negotiatio <th align="left">Used in Exchange</th>
n</c> <th align="left">Purpose</th>
<c></c><c></c><c></c> </tr>
<c>3</c><c>Initial</c><c>Exchange of ECDHE keys and nonces</c> </thead>
<c></c><c></c><c></c> <tbody>
<c>4</c><c>Waiting</c><c>Indication to peer that the server has not ye <tr>
t received an OOB message</c> <td align="left">0</td>
<c></c><c></c><c></c> <td align="left">Error</td>
<c>5</c><c>Completion</c><c>NoobId discovery</c> <td align="left">Error notification</td>
<c></c><c></c><c></c> </tr>
<c>6</c><c>Completion</c><c>Authentication and key confirmation with H <tr>
MAC</c> <td align="left">1</td>
<c></c><c></c><c></c> <td align="left">All exchanges</td>
<c>7</c><c>Reconnect</c><c>Version, cryptosuite, and parameter negotia <td align="left">PeerId and PeerState discovery</td>
tion</c> </tr>
<c></c><c></c><c></c> <tr>
<c>8</c><c>Reconnect</c><c>Exchange of ECDHE keys and nonces</c> <td align="left">2</td>
<c></c><c></c><c></c> <td align="left">Initial</td>
<c>9</c><c>Reconnect</c><c>Authentication and key confirmation with HM <td align="left">Version, cryptosuite, and parameter negotiation</
AC</c> td>
<c></c><c></c><c></c> </tr>
<c>0</c><c>Error</c><c>Error notification</c> <tr>
<c></c><c></c><c></c> <td align="left">3</td>
</texttable> <td align="left">Initial</td>
<t> <td align="left">Exchange of ECDHE keys and nonces</td>
Assignment of new values for new Message Types MUST be done through IA </tr>
NA with "Specification Required" as defined in <xref target="RFC8126"/>. <tr>
</t> <td align="left">4</td>
<td align="left">Waiting</td>
<td align="left">Indication to the peer that the server has not ye
t received an
OOB message</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 with HMAC</td
>
</tr>
<tr>
<td align="left">7</td>
<td align="left">Reconnect</td>
<td align="left">Version, cryptosuite, and parameter negotiation</
td>
</tr>
<tr>
<td align="left">8</td>
<td align="left">Reconnect</td>
<td align="left">Exchange of ECDHE keys and nonces</td>
</tr>
<tr>
<td align="left">9</td>
<td align="left">Reconnect</td>
<td align="left">Authentication and key confirmation with HMAC</td
>
</tr>
</tbody>
</table>
<t>Assignment of new values for new Message Types <bcp14>MUST</bcp14> be
done through
IANA with "Specification Required", as defined in <xref target="RFC8126"
format="default"/>.</t>
</section> </section>
<section anchor="errorcodes" numbered="true" toc="default">
<section title="Error codes" anchor="errorcodes"> <name>Error Codes</name>
<t> <t>IANA has created and will maintain a new subregistry entitled "EAP-NO
IANA is requested to create and maintain a new sub-registry entitled " OB
EAP-NOOB Error codes" in the "Nimble out-of-band authentication for EAP Paramete Error codes" in the "Nimble Out-of-Band Authentication for EAP Parameters
rs" registry. Cryptosuites are identified by an integer. The initial values for (EAP-NOOB)" registry.
this registry are: Cryptosuites are identified by an integer. The initial values for this re
</t> gistry
<texttable title="EAP-NOOB error codes" anchor="table-errors"> are:</t>
<ttcol>Error code</ttcol> <table anchor="tab-errors" align="center">
<ttcol>Purpose</ttcol> <name>EAP-NOOB Error Codes</name>
<c>1001</c> <thead>
<c>Invalid NAI</c> <tr>
<c>1002</c> <th align="left">Error code</th>
<c>Invalid message structure</c> <th align="left">Purpose</th>
<c>1003</c> </tr>
<c>Invalid data</c> </thead>
<c>1004</c> <tbody>
<c>Unexpected message type</c> <tr>
<c>1005</c> <td align="left">1001</td>
<c>Invalid ECDHE key</c> <td align="left">Invalid NAI</td>
<c>2001</c> </tr>
<c>Unwanted peer</c> <tr>
<c>2002</c> <td align="left">1002</td>
<c>State mismatch, user action required</c> <td align="left">Invalid message structure</td>
<c>2003</c> </tr>
<c>Unrecognized OOB message identifier</c> <tr>
<c>2004</c> <td align="left">1003</td>
<c>Unexpected peer identifier</c> <td align="left">Invalid data</td>
<c>3001</c> </tr>
<c>No mutually supported protocol version</c> <tr>
<c>3002</c> <td align="left">1004</td>
<c>No mutually supported cryptosuite</c> <td align="left">Unexpected message type</td>
<c>3003</c> </tr>
<c>No mutually supported OOB direction</c> <tr>
<c>4001</c> <td align="left">1005</td>
<c>HMAC verification failure</c> <td align="left">Invalid ECDHE key</td>
<c>5001</c> </tr>
<c>Application-specific error</c> <tr>
<c>5002</c> <td align="left">2001</td>
<c>Invalid server info</c> <td align="left">Unwanted peer</td>
<c>5003</c> </tr>
<c>Invalid server URL</c> <tr>
<c>5004</c> <td align="left">2002</td>
<c>Invalid peer info</c> <td align="left">State mismatch, user action required</td>
<c>6001-6999</c> </tr>
<c>Private and experimental use</c> <tr>
</texttable> <td align="left">2003</td>
<t> <td align="left">Unrecognized OOB message identifier</td>
Assignment of new error codes MUST be done through IANA with "Specific </tr>
ation Required" as defined in <xref target="RFC8126"/>, except for the range 600 <tr>
1-6999. This range is reserved for "Private Use" and "Experimental Use", both lo <td align="left">2004</td>
cally and on the open Internet. <td align="left">Unexpected peer identifier</td>
</t> </tr>
<tr>
<td align="left">3001</td>
<td align="left">No mutually supported protocol version</td>
</tr>
<tr>
<td align="left">3002</td>
<td align="left">No mutually supported cryptosuite</td>
</tr>
<tr>
<td align="left">3003</td>
<td align="left">No mutually supported OOB direction</td>
</tr>
<tr>
<td align="left">4001</td>
<td align="left">HMAC verification failure</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 codes <bcp14>MUST</bcp14> be done through IAN
A with
"Specification Required", as defined in <xref target="RFC8126" format="de
fault"/>,
except for the range 6001-6999. This range is reserved for "Private Use"
and
"Experimental Use", both locally and on the open Internet.</t>
</section> </section>
<section anchor="serverinfo-data-fields" numbered="true" toc="default">
<section title="ServerInfo data fields" anchor="serverinfo-data-fields"> <name>ServerInfo Data Fields</name>
<t> <t>IANA has created and will maintain a new subregistry entitled "EAP-NO
IANA is requested to create and maintain a new sub-registry entitled OB
"EAP-NOOB ServerInfo data fields" in the "Nimble out-of-band authentication for ServerInfo Data Fields" in the "Nimble Out-of-Band Authentication for EAP
EAP Parameters" registry. The initial values for this registry are: Parameters (EAP-NOOB)"
</t> registry. The initial values for this registry are:</t>
<texttable title="ServerInfo data fields" anchor="table-serverinfo-data- <table anchor="tab-serverinfo-data-fields" align="center">
fields"> <name>ServerInfo Data Fields</name>
<ttcol>Data Field</ttcol> <thead>
<ttcol>Specification</ttcol> <tr>
<c>Type</c><c>This RFC <xref target="serverinfo-peerinfo-meaning"/></c <th align="left">Data Field</th>
> <th align="left">Specification</th>
<c></c><c></c> </tr>
<c>ServerName</c><c>This RFC <xref target="serverinfo-peerinfo-meaning </thead>
"/></c> <tbody>
<c></c><c></c> <tr>
<c>ServerURL</c><c>This RFC <xref target="serverinfo-peerinfo-meaning" <td align="left">Type</td>
/></c> <td align="left">RFC 9140, <xref target="serverinfo-peerinfo-meani
<c></c><c></c> ng"
<c>SSIDList</c><c>This RFC <xref target="serverinfo-peerinfo-meaning"/ format="default"/></td>
></c> </tr>
<c></c><c></c> <tr>
<c>Base64SSIDList</c><c>This RFC <xref target="serverinfo-peerinfo-mea <td align="left">ServerName</td>
ning"/></c> <td align="left">RFC 9140, <xref target="serverinfo-peerinfo-meani
</texttable> ng"
<t> format="default"/></td>
Assignment of new values for new ServerInfo data fields MUST be done t </tr>
hrough IANA with "Specification Required" as defined in <xref target="RFC8126"/> <tr>
. <td align="left">ServerURL</td>
</t> <td align="left">RFC 9140, <xref target="serverinfo-peerinfo-meani
ng"
format="default"/></td>
</tr>
<tr>
<td align="left">SSIDList</td>
<td align="left">RFC 9140, <xref target="serverinfo-peerinfo-meani
ng"
format="default"/></td>
</tr>
<tr>
<td align="left">Base64SSIDList</td>
<td align="left">RFC 9140, <xref target="serverinfo-peerinfo-meani
ng"
format="default"/></td>
</tr>
</tbody>
</table>
<t>Assignment of new values for new ServerInfo data fields <bcp14>MUST</
bcp14> be done
through IANA with "Specification Required", as defined in <xref target="R
FC8126"
format="default"/>. </t>
</section> </section>
<section anchor="peerinfo-data-fields" numbered="true" toc="default">
<section title="PeerInfo data fields" anchor="peerinfo-data-fields"> <name>PeerInfo Data Fields</name>
<t> <t>IANA is requested to create and maintain a new subregistry entitled "
IANA is requested to create and maintain a new sub-registry entitled EAP-NOOB
"EAP-NOOB PeerInfo data fields" in the "Nimble out-of-band authentication for EA PeerInfo Data Fields" in the "Nimble Out-of-Band Authentication for EAP P
P Parameters" registry. The initial values for this registry are: arameters (EAP-NOOB)"
</t> registry. The initial values for this registry are:</t>
<texttable title="PeerInfo data fields" anchor="peerinfo-data-fields-tab <table anchor="peerinfo-data-fields-table" align="center">
le"> <name>PeerInfo Data Fields</name>
<ttcol>Data Field</ttcol> <thead>
<ttcol>Specification</ttcol> <tr>
<c>Type</c><c>This RFC <xref target="serverinfo-peerinfo-meaning"/></c <th align="left">Data Field</th>
> <th align="left">Specification</th>
<c></c><c></c> </tr>
<c>PeerName</c><c>This RFC <xref target="serverinfo-peerinfo-meaning"/ </thead>
></c> <tbody>
<c></c><c></c> <tr>
<c>Manufacturer</c><c>This RFC <xref target="serverinfo-peerinfo-meani <td align="left">Type</td>
ng"/></c> <td align="left">RFC 9140, <xref target="serverinfo-peerinfo-meani
<c></c><c></c> ng"
<c>Model</c><c>This RFC <xref target="serverinfo-peerinfo-meaning"/></ format="default"/></td>
c> </tr>
<c></c><c></c> <tr>
<c>SerialNumber</c><c>This RFC <xref target="serverinfo-peerinfo-meani <td align="left">PeerName</td>
ng"/></c> <td align="left">RFC 9140, <xref target="serverinfo-peerinfo-meani
<c></c><c></c> ng"
<c>MACAddress</c><c>This RFC <xref target="serverinfo-peerinfo-meaning format="default"/></td>
"/></c> </tr>
<c></c><c></c> <tr>
<c>SSID</c><c>This RFC <xref target="serverinfo-peerinfo-meaning"/></c <td align="left">Manufacturer</td>
> <td align="left">RFC 9140, <xref target="serverinfo-peerinfo-meani
<c></c><c></c> ng"
<c>Base64SSID</c><c>This RFC <xref target="serverinfo-peerinfo-meaning format="default"/></td>
"/></c> </tr>
<c></c><c></c> <tr>
<c>BSSID</c><c>This RFC <xref target="serverinfo-peerinfo-meaning"/></ <td align="left">Model</td>
c> <td align="left">RFC 9140, <xref target="serverinfo-peerinfo-meani
<c></c><c></c> ng"
</texttable> format="default"/></td>
<t> </tr>
Assignment of new values for new PeerInfo data fields MUST be done thr <tr>
ough IANA with "Specification Required" as defined in <xref target="RFC8126"/>. <td align="left">SerialNumber</td>
</t> <td align="left">RFC 9140, <xref target="serverinfo-peerinfo-meani
ng"
format="default"/></td>
</tr>
<tr>
<td align="left">MACAddress</td>
<td align="left">RFC 9140, <xref target="serverinfo-peerinfo-meani
ng"
format="default"/></td>
</tr>
<tr>
<td align="left">SSID</td>
<td align="left">RFC 9140, <xref target="serverinfo-peerinfo-meani
ng"
format="default"/></td>
</tr>
<tr>
<td align="left">Base64SSID</td>
<td align="left">RFC 9140, <xref target="serverinfo-peerinfo-meani
ng"
format="default"/></td>
</tr>
<tr>
<td align="left">BSSID</td>
<td align="left">RFC 9140, <xref target="serverinfo-peerinfo-meani
ng"
format="default"/></td>
</tr>
</tbody>
</table>
<t>Assignment of new values for new PeerInfo data fields <bcp14>MUST</bc
p14> be done
through IANA with "Specification Required", as defined in <xref target="R
FC8126"
format="default"/>.</t>
</section> </section>
<section anchor="specialdomainname" numbered="true" toc="default">
<section title="Domain name reservation" anchor="specialdomainname"> <name>Domain Name Reservation</name>
<t> <t>The special-use domain "eap-noob.arpa" has been registered in the .ar
The special-use domain "eap-noob.arpa" should be registered in the .arp pa registry
a registry (<eref target="https://www.iana.org/domains/arpa"/>). No A, AAAA, or (<eref target="https://www.iana.org/domains/arpa"/>) and the "Special-Use
PTR records are requested. Domain
</t> Names" registry (<eref target="https://www.iana.org/assignments/special-u
se-domain-names"/>).</t>
</section> </section>
<section anchor="expertguidance" numbered="true" toc="default">
<section title="Guidance for Designated Experts" anchor="expertguidance"> <name>Guidance for Designated Experts</name>
<t>Experts SHOULD be conservative in the allocation of new Cryptosuites. <t>Experts <bcp14>SHOULD</bcp14> be conservative in the allocation of ne
Experts MUST ascertain that the requested values match the current Crypto Forum w
Research Group (CFRG) guidance on cryptographic algorithm security. Experts MUST Cryptosuites. Experts <bcp14>MUST</bcp14> ascertain that the requested va
ensure that any new Cryptosuites fully specify the encoding of the ECDHE public lues match
key and should include details such as the value of "kty" (key type) parameter the current Crypto Forum Research Group (CFRG) guidance on cryptographic
when JWK <xref target="RFC7517"/> encoding is used.</t> algorithm
<t>Experts SHOULD be conservative in the allocation of new Message Types. security. Experts <bcp14>MUST</bcp14> ensure that any new Cryptosuites fu
Experts SHOULD ascertain that a well-defined specification for the new Message lly specify
Type is permanently and publicly available.</t> the encoding of the ECDHE public key and should include details, such as
<t>Experts SHOULD be conservative in the allocation of new Error codes si the value of
nce the 6001-6999 range is already allocated for private and experimental use.</ the "kty" (key type) parameter when JWK <xref target="RFC7517" format="de
t> fault"/> encoding
<t>Experts MAY be liberal in the allocation of new ServerInfo and PeerInf is used.</t>
o data fields. Experts MUST ensure that the Data Field requested has a unique na <t>Experts <bcp14>SHOULD</bcp14> be conservative in the allocation of ne
me that is not easily confused with existing registrations. For example, request w Message
s for a new PeerInfo data field "ssid" should be rejected even though it is uniq Types. Experts <bcp14>SHOULD</bcp14> ascertain that a well-defined specif
ue because it can be confused with the existing registration of "SSID". Experts ication for
MUST ensure that a suitable Description for the data field is available.</t> the new Message Type is permanently and publicly available.</t>
<t>Experts <bcp14>SHOULD</bcp14> be conservative in the allocation of ne
w Error codes,
since the 6001-6999 range is already reserved for private and experimenta
l use.</t>
<t>Experts <bcp14>MAY</bcp14> be liberal in the allocation of new Server
Info and
PeerInfo data fields. Experts <bcp14>MUST</bcp14> ensure that the data fi
eld 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".
Experts <bcp14>MUST</bcp14> ensure that a suitable Description for the da
ta field is
available.</t>
</section> </section>
</section> </section>
<section anchor="securityconsiderations" numbered="true" toc="default">
<section title="Implementation Status" anchor="implementationstatus"> <name>Security Considerations</name>
<t>Note to RFC Editor: Please remove this entire section and the refere <t>EAP-NOOB is an authentication and key derivation protocol; thus, securi
nce to RFC7942 before publication.</t> ty
<t> considerations can be found in most sections of this specification. In the
This section records the status of known implementations of the protocol following, we
defined by this specification at the time of posting of this Internet-Draft and explain the protocol design and highlight some other special consideration
is based on a proposal described in <xref target="RFC7942"/>. The description o s.</t>
f implementations in this section is intended to assist the IETF in its decision <section anchor="authenticationprinciple" numbered="true" toc="default">
processes in progressing drafts to RFCs. Please note that the listing of any in <name>Authentication Principle</name>
dividual implementation here does not imply endorsement by the IETF. Furthermore <t>EAP-NOOB establishes a shared secret with an authenticated ECDHE key
, no effort has been spent to verify the information presented here that was sup exchange. The
plied by IETF contributors. This is not intended as, and must not be construed t mutual authentication in EAP-NOOB is based on two separate features, both
o be, a catalog of available implementations or their features. Readers are advi conveyed in
sed to note that other implementations may exist. the OOB message. The first authentication feature is the secret nonce Noo
</t> b. The peer
and server use this secret in the Completion Exchange to mutually authent
<section title="Implementation with wpa_supplicant and hostapd" anchor="aa icate the
ltoimplementation"> session key previously created with ECDHE. The message authentication cod
<t> es computed
<list style="symbols"> with the secret nonce Noob are alone sufficient for authenticating the ke
<t>Responsible Organization: Aalto University</t> y exchange.
<t>Location: <eref target="https://github.com/tuomaura/eap-noob"/></ The second authentication feature is the integrity-protecting fingerprint
t> Hoob. Its
<t>Coverage: This implementation includes all the features described purpose is to prevent impersonation attacks even in situations where the
in the current specification. The implementation supports two-dimensional QR co attacker is
des and NFC as example out-of-band (OOB) channels.</t> able to eavesdrop on the OOB channel and the nonce Noob is compromised. I
<t>Level of Maturity: Alpha</t> n some
<t>Version compatibility: Version 08 of the individual draft impleme human-assisted OOB channels, such as human-perceptible audio or a user-ty
nted</t> ped URL, it
<t>Licensing: BSD</t> may be easier to detect tampering than disclosure of the OOB message, and
<t>Contact Information: Tuomas Aura, tuomas.aura@aalto.fi</t> such
</list> applications benefit from the second authentication feature.</t>
</t> <t>The additional security provided by the cryptographic fingerprint Hoo
b 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 de
tect
impersonation attacks that may have happened on the in-band channel. The
other
endpoint, however, is not equally protected because the OOB message and f
ingerprint
are sent only in one direction. Some protection to the OOB sender is affo
rded by the
fact that the user may notice the failure of the association at the OOB r
eceiver and
therefore reset the OOB sender. Other device-pairing protocols have solve
d similar
situations by requiring the user to confirm to the OOB sender that the as
sociation was
accepted by the OOB receiver, e.g., with a button press on the sender sid
e.
Applications <bcp14>MAY</bcp14> implement EAP-NOOB in this way. Neverthel
ess, since
EAP-NOOB was designed to work with strictly one-directional OOB communica
tion and the
fingerprint is only the second authentication feature, the EAP-NOOB speci
fication does
not mandate such explicit confirmation to the OOB sender.</t>
<t>To summarize, EAP-NOOB uses the combined protection of the secret non
ce 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 ca
n eavesdrop
on it from the OOB channel. Even if an attacker is able to eavesdrop on t
he 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, w
hich would
reject the OOB message. The attacker that eavesdropped on the secret nonc
e can
impersonate the OOB receiver to the OOB sender. If it does, the associati
on will
appear to be complete only on the OOB sender side, and such situations ha
ve to be
resolved by the user by resetting the OOB sender to the initial state.</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 E
AP, the
user-entered credential is often a passphrase that is shared by all the n
etwork
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 t
he system
more resilient against device compromise. Another advantage is that it is
possible to
revoke the security association for an individual device on the server si
de.</t>
<t>Forward secrecy during fast reconnect in EAP-NOOB is optional. The Re
connect
Exchange in EAP-NOOB provides forward secrecy only if both the server and
peer send
their fresh ECDHE keys. This allows both the server and peer to limit the
frequency of the costly computation that is required for forward secrecy.
The server
<bcp14>MAY</bcp14> adjust the frequency of its attempts at ECDHE rekeying
based on
what it knows about the peer's computational capabilities.</t>
<t>Another way in which some servers may control their computational loa
d 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. How
ever, the
server <bcp14>MUST NOT</bcp14> reuse the same ECDHE key with the same pee
r when
rekeying with ECDHE (KeyingMode=2 or KeyingMode=3). Instead, it can simpl
y not send an
ECDHE key (KeyingMode=1).</t>
<t>The users delivering the OOB messages will often authenticate themsel
ves 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 u
se of
EAP-NOOB can use this information for configuring the initial owner of th
e
freshly registered device.</t>
</section> </section>
<section anchor="deviceidentification" numbered="true" toc="default">
<section title="Implementation on Contiki" anchor="murciaimplementation_co <name>Identifying Correct Endpoints</name>
ntiki"> <t>Potential weaknesses in EAP-NOOB arise from the fact that the user mu
<t> st physically
<list style="symbols"> identify the correct peer device. If the user mistakenly delivers the OOB
<t>Responsible Organization: University of Murcia and Aalto Universi message
ty</t> from the wrong peer device to the server, the server may create an associ
<t>Location: <eref target="https://github.com/eduingles/coap-eap-noo ation with
b"/></t> the wrong peer. The reliance on the user in identifying the correct endpo
<t>Coverage: This implementation includes all the features described ints is an
in the current specification. The implementation uses a blinking LED light as t inherent property of user-assisted, out-of-band authentication. To unders
he out-of-band (OOB) channel.</t> tand the
<t>Level of Maturity: Alpha</t> potential consequences of the user mistake, we need to consider a few dif
<t>Version compatibility: Version 06 of the draft implemented</t> ferent
<t>Licensing: BSD</t> scenarios. In the first scenario, there is no malicious party, and the us
<t>Contact Information: Eduardo Ingles, eduardo.ingles@um.es</t> er makes an
</list> accidental mistake between two out-of-the-box devices that are both ready
</t> to be
registered to a server. If the user delivers the OOB message from the wro
ng device to
the server, confusion may arise but usually no security issues. In the se
cond
scenario, an attacker intentionally tricks the user, for example, by subs
tituting 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 is also a third scenario, in which an opportunistic attacker tr
ies to take
advantage of the user's accidental mistake. For example, the user could p
lay an audio
or a blinking LED message to a device that is not expecting to receive it
. In simple
security bootstrapping solutions that transfer a primary key to the devic
e via the OOB
channel, the device could misuse or leak the accidentally received primar
y key.
EAP-NOOB is not vulnerable to such opportunistic attackers because the OO
B message has
no value to anyone who did not take part in the corresponding Initial Exc
hange.</t>
<t>One mechanism that can mitigate user mistakes is certification of pee
r devices. A
certificate or an attestation token (e.g., <xref target="I-D.tschofenig-t
ls-cwt"
format="default"/> and <xref target="I-D.ietf-rats-eat" format="default"/
>) can convey
to the server authentic identifiers and attributes, such as model and ser
ial 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 t
he user to
know any identifier of the peer device; physical access to the device is
sufficient
for bootstrapping with EAP-NOOB.</t>
<t>Similarly, the attacker can try to trick the user into delivering the
OOB message
to
the wrong server so that the peer device becomes associated with the wron
g server. If
the EAP server is accessed through a web user interface, the attack is ak
in to
phishing attacks where the user is tricked into accessing the wrong URL a
nd wrong web
page. OOB implementation with a dedicated app on a mobile device, which c
ommunicates
with a server API at a preconfigured URL, can protect against such attack
s. </t>
<t>After the device registration, an attacker could clone the device ide
ntity by
copying the keys from the persistent EAP-NOOB association into another de
vice. The
attacker can be an outsider who gains access to the keys or the device ow
ner who wants
to have two devices matching the same registration. The cloning threats c
an be
mitigated by creating the cryptographic keys and storing the persistent E
AP-NOOB
association on the peer device in a secure hardware component such as a t
rusted
execution environment (TEE). Furthermore, remote attestation on the appli
cation 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 b
ut the first
clone that performs the update.</t>
</section> </section>
<section anchor="trustedpath" numbered="true" toc="default">
<section title="Implementation with wpa_supplicant and hostapd" anchor="mu <name>Trusted Path Issues and Misbinding Attacks</name>
rciaimplementation_linux"> <t>Another potential threat is spoofed user input or output on the peer
<t> device. When
<list style="symbols"> the user is delivering the OOB message to or from the correct peer device
<t>Responsible Organization: Ericsson</t> , a trusted
<t>Location: <eref target="https://github.com/Vogeltak/hostap"/></t> path between the user and the peer device is needed. That is, the user mu
<t>Coverage: This implementation is the most up-to-date one. The imp st
lementation only provides a minimal API interface for transferring OOB messages. communicate directly with an authentic operating system and EAP-NOOB impl
</t> ementation in
<t>Level of Maturity: Alpha</t> the peer device and not with a spoofed user interface. Otherwise, a regis
<t>Version compatibility: Version 02 of the working group adopted dr tered device
aft is implemented</t> that is under the control of the attacker could emulate the behavior of a
<t>Licensing: BSD</t> n
</list> unregistered device. The secure path can be implemented, for example, by
</t> having the
user press a reset button to return the device to the Unregistered (0) st
ate and to
invoke
a trusted UI. The problem with such trusted paths is that they are not st
andardized
across devices.</t>
<t>Another potential consequence of a spoofed UI is the misbinding attac
k where the
user tries to register a correct but compromised device, which tricks the
user into
registering another (uncompromised) device instead. For example, the comp
romised
device might have a malicious, full-screen app running, which presents to
the user QR
codes copied, in real time, from another device's screen. If the unwittin
g user scans
the QR code and delivers the OOB message in it to the server, the wrong d
evice may
become registered in the server. Such misbinding vulnerabilities arise be
cause the
user does not have any secure way of verifying that the in-band cryptogra
phic
handshake and the out-of-band physical access are terminated at the same
physical
device. Sethi et al. <xref target="Sethi19" format="default"/> analyze th
e misbinding
threat against device-pairing protocols and also EAP-NOOB. Essentially, a
ll protocols
where the authentication relies on the user's physical access to the devi
ce are
vulnerable to misbinding, including EAP-NOOB.</t>
<t>A standardized trusted path for communicating directly with the trust
ed 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 pre
vent 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. Devic
e
certification by the manufacturer can further strengthen the asset tracki
ng.</t>
</section> </section>
<section anchor="peeridentifiers" numbered="true" toc="default">
<section title="Protocol modeling " anchor="modeling"> <name>Peer Identifiers and Attributes</name>
<t> <t>The PeerId value in the protocol is a server-allocated identifier for
The current EAP-NOOB specification has been modeled with the mCRL2 for its
mal specification language <xref target="mcrl2"/>. The model <xref target="noob- association with the peer and <bcp14>SHOULD NOT</bcp14> be shown to the u
mcrl2"/> was used mainly for simulating the protocol behavior and for verifying ser because
basic safety and liveness properties as part of the specification process. For e its value is initially ephemeral. Since the PeerId is allocated by the se
xample, we verified the correctness of the tiebreaking mechanism when two OOB me rver and the
ssages are received simultaneously, one in each direction. We also verified that scope of the identifier is the single server, the so-called identifier sq
an on-path attacker cannot cause persistent failure by spoofing a finite number uatting
of messages in the Reconnect Exchange. Additionally, the protocol has been mode attacks, where a malicious peer could reserve another peer's identifier,
led with the ProVerif <xref target="proverif"/> tool. This model <xref target="n are not
oob-proverif"/> was used to verify security properties such as mutual authentica possible in EAP-NOOB. The server <bcp14>SHOULD</bcp14> assign a random or
tion. pseudorandom PeerId to each new peer. It <bcp14>SHOULD NOT</bcp14> select
</t> the PeerId
based on any peer characteristics that it may know, such as the peer's li
nk-layer
network address.</t>
<t>User reset or failure in the OOB Step can cause the peer to perform m
any 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 e
phemeral
associations. There is no security reason to delete them early, and the s
erver 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 server <bcp14
>SHOULD
NOT</bcp14> delete the ephemeral state before all the related Noob values
have
expired.</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 PeerInfo that it sends
to the
server. If the server stores any information about the peer, it is import
ant 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 n
ot
authenticated information and should not be relied on. One possible use f
or the
PeerInfo field is EAP channel binding (see <xref target="channel-binding"
format="default"/>).</t>
</section> </section>
</section> <section anchor="downgrading" numbered="true" toc="default">
<name>Downgrading Threats</name>
<section title="Security considerations" anchor="securityconsiderations"> <t>The fingerprint Hoob protects all the information exchanged in the In
<t> itial
EAP-NOOB is an authentication and key derivation protocol and, thus, sec Exchange, including the cryptosuite negotiation. The message authenticati
urity considerations can be found in most sections of this specification. In the on codes MACs
following, we explain the protocol design and highlight some other special cons and MACp also protect the same information. The message authentication co
iderations. des MACs2 and
</t> MACp2 protect information exchanged during key renegotiation in the Recon
nect
<section title="Authentication principle" anchor="authenticationprinciple" Exchange. This prevents downgrading attacks to weaker cryptosuites, as lo
> ng as the
<t> possible attacks take more time than the maximum time allowed for the EAP
EAP-NOOB establishes a shared secret with an authenticated ECDHE key e -NOOB
xchange. The mutual authentication in EAP-NOOB is based on two separate features completion. This is typically the case for recently discovered cryptanaly
, both conveyed in the OOB message. The first authentication feature is the secr tic
et nonce Noob. The peer and server use this secret in the Completion Exchange to attacks.</t>
mutually authenticate the session key previously created with ECDHE. The messag <t>As an additional precaution, the EAP server and peer <bcp14>MUST</bcp
e authentication codes computed with the secret nonce Noob are alone sufficient 14> check for
for authenticating the key exchange. The second authentication feature is the in downgrading attacks in the Reconnect Exchange as follows. As long as the
tegrity-protecting fingerprint Hoob. Its purpose is to prevent impersonation att server or
acks even in situations where the attacker is able to eavesdrop on the OOB chann peer saves any information about the other endpoint, it <bcp14>MUST</bcp1
el and the nonce Noob is compromised. In some human-assisted OOB channels, such 4> also
as human-perceptible audio or a user-typed URL, it may be easier to detect tampe remember the previously negotiated cryptosuite and <bcp14>MUST NOT</bcp14
ring than disclosure of the OOB message, and such applications benefit from the > accept
second authentication feature. renegotiation of any cryptosuite that is known to be weaker than the prev
</t> ious one,
<t> such as a deprecated cryptosuite. Determining the relative strength of th
The additional security provided by the cryptographic fingerprint Hoob e
is somewhat intricate to understand. The endpoint that receives the OOB message cryptosuites is out of scope of this specification and may be managed by
uses Hoob to verify the integrity of the ECDHE exchange. Thus, the OOB receiver implementations or by local policies at the peer and server.</t>
can detect impersonation attacks that may have happened on the in-band channel. <t>Integrity of the direction negotiation cannot be verified in the same
The other endpoint, however, is not equally protected because the OOB message a way as the
nd fingerprint are sent only in one direction. Some protection to the OOB sender integrity of the cryptosuite negotiation. That is, if the OOB channel use
is afforded by the fact that the user may notice the failure of the association d in an
at the OOB receiver and therefore reset the OOB sender. Other device-pairing pr application is critically insecure in one direction, an on-path attacker
otocols have solved similar situations by requiring the user to confirm to the O could modify
OB sender that the association was accepted by the OOB receiver, e.g., with a bu the negotiation messages and thereby cause that direction to be used. App
tton press on the sender side. Applications MAY implement EAP-NOOB in this way. lications
Nevertheless, since EAP-NOOB was designed to work with strictly one-directional that support OOB messages in both directions <bcp14>SHOULD</bcp14>, there
OOB communication and the fingerprint is only the second authentication feature, fore, ensure
the EAP-NOOB specification does not mandate such explicit confirmation to the O that the OOB channel has sufficiently strong security in both directions.
OB sender. While this
</t> is a theoretical vulnerability, it could arise in practice if EAP-NOOB is
<t> deployed in
To summarize, EAP-NOOB uses the combined protection of the secret nonc new applications. Currently, we expect most peer devices to support only
e Noob and the cryptographic fingerprint Hoob, both conveyed in the OOB message. one OOB
The secret nonce Noob alone is sufficient for mutual authentication unless the direction; in which case, interfering with the direction negotiation can
attacker can eavesdrop on it from the OOB channel. Even if an attacker is able t only prevent
o eavesdrop on the secret nonce Noob, it nevertheless cannot perform a full impe the completion of the protocol.</t>
rsonation attack on the in-band channel because a mismatching fingerprint would <t>The long-term shared key material Kz in the persistent EAP-NOOB assoc
alert the OOB receiver, which would reject the OOB message. The attacker that ea iation is
vesdropped on the secret nonce can impersonate the OOB receiver to the OOB sende established with an ECDHE key exchange when the peer and server are first
r. If it does, the association will appear to be complete only on the OOB sender associated.
side, and such situations have to be resolved by the user by resetting the OOB It is a weaker secret than a manually configured random shared key becaus
sender to the initial state. e advances in
</t> cryptanalysis against the used ECDHE curve could eventually enable the at
<t> tacker to
The expected use cases for EAP-NOOB are ones where it replaces a user- recover Kz. EAP-NOOB protects against such attacks by allowing cryptosuit
entered access credential in IoT appliances. In wireless network access without e upgrades in
EAP, the user-entered credential is often a passphrase that is shared by all the the Reconnect Exchange and by updating the shared key material Kz wheneve
network stations. The advantage of an EAP-based solution, including EAP-NOOB, i r the
s that it establishes a different shared secret for each peer device, which make cryptosuite is upgraded. We do not expect the cryptosuite upgrades to be
s the system more resilient against device compromise. Another advantage is that frequent,
it is possible to revoke the security association for an individual device on t but,
he server side. if an upgrade becomes necessary, it can be done without manual reset and
</t> reassociation
<t> of the peer devices.</t>
Forward secrecy during fast reconnect in EAP-NOOB is optional. The Rec
onnect Exchange in EAP-NOOB provides forward secrecy only if both the server and
peer send their fresh ECDHE keys. This allows both the server and the peer to l
imit the frequency of the costly computation that is required for forward secrec
y. The server MAY adjust the frequency of its attempts at ECDHE rekeying based o
n what it knows about the peer's computational capabilities.
</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 upd
ates its ECDHE key, which may be a reasonable trade-off between security and per
formance. However, the server MUST NOT reuse the same ECDHE key with the same pe
er when rekeying with ECDHE (KeyingMode=2 or KeyingMode=3). Instead, it can simp
ly not send an ECDHE key (KeyingMode=1).
</t>
<t>
The users delivering the OOB messages will often authenticate themselv
es to the EAP server, e.g., by logging into a secure web page or API. In this ca
se, 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 the freshly-registered device.
</t>
</section> </section>
<section anchor="indicators" numbered="true" toc="default">
<section title="Identifying correct endpoints" anchor="deviceidentificatio <name>Protected Success and Failure Indications</name>
n"> <t><xref target="RFC3748" sectionFormat="of" section="7.16"/> allows EAP
<t> methods to
Potential weaknesses in EAP-NOOB arise from the fact that the user mus specify protected result indications because EAP-Success and EAP-Failure
t identify physically the correct peer device. If the user mistakenly delivers t packets are
he OOB message from the wrong peer device to the server, the server may create a neither acknowledged nor integrity protected. <xref target="RFC3748"
n association with the wrong peer. The reliance on the user in identifying the c format="default"/> notes that these indications may be explicit or implic
orrect endpoints is an inherent property of user-assisted out-of-band authentica it.</t>
tion. To understand the potential consequences of the user mistake, we need to c <t>EAP-NOOB relies on implicit, protected success indicators in the Comp
onsider a few different scenarios. In the first scenario, there is no malicious letion
party, and the user makes an accidental mistake between two out-of-the-box devic Exchange and
es that are both ready to be registered to a server. If the user delivers the OO Reconnect Exchange. Successful verification of MACs and MACs2 in the EAP-
B message from the wrong device to the server, confusion may arise but usually n Request
o security issues. In the second scenario, an attacker intentionally tricks the message from the server (message type 6 and message type 9, respectively)
user, for example, by substituting the original peer device with a compromised o acts as an
ne. This is essentially a supply chain attack where the user accepts a compromis implicit, protected success indication to the peer. Similarly, successful
ed physical device. verification
</t> of MACp and MACp2 in the EAP-Response message from the peer (message type
<t> 6 and
There is also a third scenario, in which an opportunistic attacker tri message type 9, respectively) act as an implicit, protected success indic
es to take advantage of the user's accidental mistake. For example, the user cou ation to the
ld play an audio or a blinking LED message to a device that is not expecting to server. </t>
receive it. In simple security bootstrapping solutions that transfer a master ke <t>EAP-NOOB failure messages are not protected. Protected failure result
y to the device via the OOB channel, the device could misuse or leak the acciden indications
tally received master key. EAP-NOOB is not vulnerable to such opportunistic atta would not significantly improve availability since EAP-NOOB reacts to mos
ckers because the OOB message has no value to anyone who did not take part in th t malformed
e corresponding Initial Exchange. data by ending the current EAP conversation in EAP-Failure. However, sinc
</t> e EAP-NOOB
<t> spans multiple conversations, failure in one conversation usually means n
One mechanism that can mitigate user mistakes is certification of peer o state
devices. A certificate or an attestation token (e.g.,<xref target="I-D.tschofen change on the level of the EAP-NOOB state machine.</t>
ig-tls-cwt"/> and <xref target="I-D.ietf-rats-eat"/>) can convey to the server a
uthentic identifiers and attributes, such as model and serial number, of the pee
r device. Compared to a fully certificate-based authentication, however, EAP-NOO
B can be used without trusted third parties and does not require the user to kno
w any identifier of the peer device; physical access to the device is sufficient
for bootstrapping with EAP-NOOB.
</t>
<t>
Similarly, the attacker can try to trick the user into delivering the
OOB message to the wrong server, so that the peer device becomes associated with
the wrong server. If the EAP server is accessed through a web user interface, t
he attack is akin to phishing attacks where the user is tricked into accessing t
he wrong URL and wrong web page. OOB implementation with a dedicated app on a mo
bile device, which communicates with a server API at a pre-configured URL, can p
rotect against such attacks.
</t>
<t>
After the device registration, an attacker could clone the device iden
tity by copying the keys from the persistent EAP-NOOB association into another d
evice. The attacker can be an outsider who gains access to the keys or the devic
e owner who wants to have two devices matching the same registration. The clonin
g threats can be mitigated by creating the cryptographic keys and storing the pe
rsistent EAP-NOOB association on the peer device in a secure hardware component
such as a trusted execution environment (TEE). Furthermore, remote attestation o
n the application level could provide assurance to the server that the device ha
s not been cloned. Reconnect Exchange with a new cryptosuite (KeyingMode=3) will
also disconnect all but the first clone that performs the update.
</t>
</section> </section>
<section anchor="channel-binding" numbered="true" toc="default">
<section title="Trusted path issues and misbinding attacks" anchor="truste <name>Channel Binding</name>
dpath"> <t>EAP channel binding, defined in <xref target="RFC6677" format="defaul
<t> t"/>, means
Another potential threat is spoofed user input or output on the peer d that the endpoints compare their perceptions of network properties, such
evice. When the user is delivering the OOB message to or from the correct peer d as
evice, a trusted path between the user and the peer device is needed. That is, t lower-layer identifiers, over the secure channel established by EAP authe
he user must communicate directly with an authentic operating system and EAP-NOO ntication.
B implementation in the peer device and not with a spoofed user interface. Other <xref target="RFC6677" sectionFormat="of" section="4.1"/> defines two app
wise, a registered device that is under the control of the attacker could emulat roaches to
e the behavior of an unregistered device. The secure path can be implemented, fo channel binding. EAP-NOOB follows the first approach, in which the peer a
r example, by having the user press a reset button to return the device to the U nd server
nregistered state and to invoke a trusted UI. The problem with such trusted path exchange plaintext information about the network over a channel that is i
s is that they are not standardized across devices. ntegrity
</t> protected with keys derived during the EAP execution. More specifically,
<t> channel
Another potential consequence of a spoofed UI is the misbinding attack information is exchanged in the plaintext PeerInfo and ServerInfo objects
where the user tries to register a correct but compromised device, which tricks and is later
the user into registering another (uncompromised) device instead. For example, verified with message authentication codes (MACp, MACs, MACp2, and MACs2)
the compromised device might have a malicious full-screen app running, which pre . This allows
sents to the user QR codes copied, in real time, from another device's screen. I policy-based comparison with locally perceived network properties on eith
f the unwitting user scans the QR code and delivers the OOB message in it to the er side, as
server, the wrong device may become registered in the server. Such misbinding v well as logging for debugging purposes. The peer <bcp14>MAY</bcp14> inclu
ulnerabilities arise because the user does not have any secure way of verifying de in
that the in-band cryptographic handshake and the out-of-band physical access are PeerInfo any data items that it wants to bind to the EAP-NOOB association
terminated at the same physical device. Sethi et al. <xref target="Sethi19"/> a and to the
nalyze the misbinding threat against device-pairing protocols and also EAP-NOOB. exported keys. These can be properties of the authenticator or the access
Essentially, all protocols where the authentication relies on the user's physic link, such
al access to the device are vulnerable to misbinding, including EAP-NOOB. as the SSID and BSSID of the wireless network (see <xref
</t> target="tab-serverinfo-meaning" format="default"/>). As noted in <xref
<t> target="RFC6677" sectionFormat="of" section="4.3"/>, the scope of the cha
A standardized trusted path for communicating directly with the truste nnel binding
d computing base in a physical device would mitigate the misbinding threat, but varies between deployments. For example, the server may have less link-la
such paths rarely exist in practice. Careful asset tracking on the server side c yer
an also prevent most misbinding attacks if the peer device sends its identifiers information available from roaming networks than from a local enterprise
or attributes in the PeerInfo field and the server compares them with the expec network, and
ted values. The wrong but uncompromised device's PeerInfo will not match the exp it may be unable to verify all the network properties received in PeerInf
ected values. Device certification by the manufacturer can further strengthen th o. There are
e asset tracking. also privacy considerations related to exchanging the ServerInfo and Peer
</t> Info while
roaming (see <xref target="privacyconsiderations" format="default"/>). </
t>
<t>Channel binding to secure channels, defined in <xref 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 se
ssion 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 cr
eated by
EAP-NOOB and to the session keys MSK and EMSK.</t>
</section> </section>
<section anchor="dos" numbered="true" toc="default">
<section title="Peer identifiers and attributes" anchor="peeridentifiers"> <name>Denial of Service</name>
<t> <t>While denial-of-service (DoS) attacks by on-link attackers cannot be
The PeerId value in the protocol is a server-allocated identifier for fully
its association with the peer and SHOULD NOT be shown to the user because its va prevented, the design goal in EAP-NOOB is to void long-lasting failure ca
lue is initially ephemeral. Since the PeerId is allocated by the server and the used by an
scope of the identifier is the single server, the so-called identifier squatting attacker who is present only temporarily or intermittently. The main defe
attacks, where a malicious peer could reserve another peer's identifier, are no nse mechanism
t possible in EAP-NOOB. The server SHOULD assign a random or pseudo-random PeerI is the persistent EAP-NOOB association, which is never deleted automatica
d to each new peer. It SHOULD NOT select the PeerId based on any peer characteri lly due to
stics that it may know, such as the peer's link-layer network address. in-band messages or error indications. Thus, the endpoints can always use
</t> the
<t> persistent association for reconnecting after the DoS attacker leaves the
User reset or failure in the OOB Step can cause the peer to perform ma network. In
ny Initial Exchanges with the server, which allocates many PeerId values and sto this sense, the persistent association serves the same function in EAP-NO
res the ephemeral protocol state for them. The peer will typically only remember OB as a
the latest ones. EAP-NOOB leaves it to the implementation to decide when to del permanent primary key or certificate in other authentication protocols. W
ete these ephemeral associations. There is no security reason to delete them ear e discuss
ly, and the server does not have any way to verify that the peers are actually t logical attacks against the updates of the persistent association in <xre
he same one. Thus, it is safest to store the ephemeral states on the server for f
at least one day. If the OOB messages are sent only in the server-to-peer direct target="completion-loss" format="default"/>. </t>
ion, the server SHOULD NOT delete the ephemeral state before all the related Noo <t>In addition to logical DoS attacks, it is necessary to consider resou
b values have expired. rce exhaustion
</t> attacks against the EAP server. The number of persistent EAP-NOOB associa
<t> tions created
After completion of EAP-NOOB, the server may store the PeerInfo data, in the server is limited by the need for a user to assist in delivering t
and the user may use it to identify the peer and its attributes, such as the mak he OOB
e and model or serial number. A compromised peer could lie in the PeerInfo which message. The users can be authenticated for the input or output of the OO
it sends to the server. If the server stores any information about the peer, it B message at
is important that this information is approved by the user during or after the the EAP server, and any users who create excessive numbers of persistent
OOB Step. Without verification by the user or authentication on the application associations
level, the PeerInfo is not authenticated information and should not be relied on can be held accountable and their associations can be deleted by the serv
. One possible use for the PeerInfo field is EAP channel binding (see <xref targ er
et="channel-binding"/>). administrator. What the attacker can do without user authentication is to
</t> perform the
Initial Exchange repeatedly and create a large number of ephemeral associ
ations
(server in Waiting for OOB (1) state) without ever delivering the OOB mes
sage. In
<xref target="peeridentifiers" format="default"/>, it was suggested that
the server
should store the ephemeral states for at least a day. This may require of
f-loading the
state storage from memory to disk during a DoS attack. However, if the se
rver
implementation is unable to keep up with a rate of Initial Exchanges perf
ormed by a
DoS attacker and needs to drop some ephemeral states, no damage is caused
to
already-created persistent associations, and the honest users can resume
registering
new peers when the DoS attacker leaves the network.</t>
<t>There are some trade-offs in the protocol design between politely bac
king off and
giving
way to DoS attackers. An on-link DoS attacker could spoof the SleepTime v
alue 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 attac
ker 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 fu
nctional.
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 a
bout 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 mention
ed in <xref
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 reaso
nable 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 r
easonable
limits will increase the acceptance of the protocol. The maximum backoff
times could
be updated to be shorter as the protocol implementations mature.</t>
</section> </section>
<section anchor="completion-loss" numbered="true" toc="default">
<section title="Downgrading threats" anchor="downgrading"> <name>Recovery from Loss of Last Message</name>
<t> <t>The EAP-NOOB Completion Exchange, as well as the Reconnect Exchange w
The fingerprint Hoob protects all the information exchanged in the Ini ith
tial Exchange, including the cryptosuite negotiation. The message authentication cryptosuite update, results in a persistent state change that should take
codes MACs and MACp also protect the same information. The message authenticati place either
on codes MACs2 and MACp2 protect information exchanged during key renegotiation on both endpoints or on neither; otherwise, the result is a state mismatc
in the Reconnect Exchange. This prevents downgrading attacks to weaker cryptosui h that
tes as long as the possible attacks take more time than the maximum time allowed requires user action to resolve. The state mismatch can occur if the fina
for the EAP-NOOB completion. This is typically the case for recently discovered l EAP
cryptanalytic attacks. response of the exchanges is lost. In the Completion Exchange, the loss o
</t> f the final
<t> response (Type=6) results in the peer moving to the Registered (4) state
As an additional precaution, the EAP server and peer MUST check for do and creating
wngrading attacks in the Reconnect Exchange as follows. As long as the server or a persistent EAP-NOOB association while the server stays in an ephemeral
peer saves any information about the other endpoint, it MUST also remember the state (1 or
previously negotiated cryptosuite and MUST NOT accept renegotiation of any crypt 2). In the Reconnect Exchange, the loss of the final response (Type=9) re
osuite that is known to be weaker than the previous one, such as a deprecated cr sults in the
yptosuite. Determining the relative strength of the cryptosuites is out of scope peer moving to the Registered (4) state and updating its persistent key m
of this specification and may be managed by implementations or by local policie aterial Kz
s at the peer and server. while the server stays in the Reconnecting (3) state and keeps the old ke
</t> y
<t> material.</t>
Integrity of the direction negotiation cannot be verified in the same <t>The state mismatch is an example of an unavoidable problem in distrib
way as the integrity of the cryptosuite negotiation. That is, if the OOB channel uted systems:
used in an application is critically insecure in one direction, an on-path atta it is theoretically impossible to guarantee synchronous state changes in
cker could modify the negotiation messages and thereby cause that direction to b endpoints
e used. Applications that support OOB messages in both directions SHOULD therefo that communicate asynchronously. The protocol will always have one critic
re ensure that the OOB channel has sufficiently strong security in both directio al message
ns. While this is a theoretical vulnerability, it could arise in practice if EAP that may get lost, so that one side commits to the state change and the o
-NOOB is deployed in new applications. Currently, we expect most peer devices to ther side
support only one OOB direction, in which case interfering with the direction ne does not. In EAP, the critical message is the final response from the pee
gotiation can only prevent the completion of the protocol. r to the
</t> server. While the final response is normally followed by EAP-Success, <xr
<t> ef
The long-term shared key material Kz in the persistent EAP-NOOB associ target="RFC3748" sectionFormat="comma" section="4.2"/> states that the pe
ation is established with an ECDHE key exchange when the peer and server are fir er
st associated. It is a weaker secret than a manually configured random shared ke <bcp14>MAY</bcp14> assume that the EAP-Success was lost and the authentic
y because advances in cryptanalysis against the used ECDHE curve could eventuall ation was
y enable the attacker to recover Kz. EAP-NOOB protects against such attacks by a successful. Furthermore, EAP method implementations in the peer do not re
llowing cryptosuite upgrades in the Reconnect Exchange and by updating the share ceive
d key material Kz whenever the cryptosuite is upgraded. We do not expect the cry notification of the EAP-Success message from the parent EAP state machine
ptosuite upgrades to be frequent, but if an upgrade becomes necessary, it can be <xref
done without manual reset and reassociation of the peer devices. target="RFC4137" format="default"/>. For these reasons, EAP-NOOB on the p
</t> eer side
commits to a state change already when it sends the final response.</t>
<t>The best available solution to the loss of the critical message is to
keep trying.
EAP retransmission behavior defined in <xref target="RFC3748" sectionForm
at="of"
section="4.3"/> suggests 3-5 retransmissions. In the absence of an attack
er, 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 (K
eyingMode=0)
and Reconnect Exchange with cryptosuite upgrade (KeyingMode=3), this coul
d
result in a state mismatch and persistent denial of service until the use
r resets the
peer state.</t>
<t>EAP-NOOB implements its own recovery mechanism that allows unlimited
retries of the
Reconnect Exchange. When the DoS attacker eventually stops dropping packe
ts on the
in-band channel, the protocol will recover. The logic for this recovery m
echanism is
specified in <xref target="reconnectexchange" format="default"/>.</t>
<t>EAP-NOOB does not implement the same kind of retry mechanism in the C
ompletion
Exchange. The reason is that there is always a user involved in the initi
al
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 ne
eds to work
without user involvement.</t>
</section> </section>
<section anchor="privacyconsiderations" numbered="true" toc="default">
<section title="Protected success and failure indications" anchor="indicat <name>Privacy Considerations</name>
ors"> <t>There are privacy considerations related to performing the Reconnect
<t> Exchange while
Section 7.16 of <xref target="RFC3748"/> allows EAP methods to specify roaming. The peer and server may send updated PeerInfo and ServerInfo fie
protected result indications because EAP-Success and EAP-Failure packets are ne lds in the
ither acknowledged nor integrity protected. <xref target="RFC3748"/> notes that Reconnect Exchange. This data is sent unencrypted between the peer and th
these indications may be explicit or implicit. e EAP
</t> authenticator, such as a wireless access point. Thus, it can be observed
<t> by both
EAP-NOOB relies on implicit protected success indicators in the Comple outsiders and the access network. The PeerInfo field contains identifiers
tion and Reconnect exchange. Successful verification of MACs and MACs2 in the EA and other
P-Request message from the server (message type 6 and message type 9, respective information about the peer device (see <xref target="tab-serverinfo-meani
ly) acts as an implicit protected success indication to the peer. Similarly, suc ng"
cessful verification of MACp and MACp2 in the EAP-Response message from the peer format="default"/>). While the information refers to the peer device and
(message type 6 and message type 9, respectively) act as an implicit protected not directly
success indication to the server. to the user, it can leak information about the user to the access network
</t> and to
<t> outside observers. The ServerInfo, on the other hand, can leak informatio
EAP-NOOB failure messages are not protected. Protected failure result n about the
indications would not significantly improve availability since EAP-NOOB reacts t peer's affiliation with the home network. For this reason, the optional P
o most malformed data by ending the current EAP conversation in EAP-Failure. How eerInfo and
ever, since EAP-NOOB spans multiple conversations, failure in one conversation u ServerInfo in the Reconnect Exchange <bcp14>SHOULD</bcp14> be omitted unl
sually means no state change on the level of the EAP-NOOB state machine. ess some
</t> critical data has changed and it cannot be updated on the application lay
er.</t>
<t>Peer devices that randomize their Layer 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 upd
ating the
PeerId at each Reconnect Exchange. In that case, it is necessary to consi
der how the
authenticator and access-network administrators can recognize and add mis
behaving peer
devices to a deny list, as well as how to avoid loss of synchronization b
etween the
server and the peer if messages are lost during the identifier update.</t
>
<t>To enable stronger identity protection in later versions of EAP-NOOB,
the optional
server-assigned NAI (NewNAI) <bcp14>SHOULD</bcp14> have a constant userna
me part. The
<bcp14>RECOMMENDED</bcp14> username is "noob". The server <bcp14>MAY</bcp
14>, however,
send a different username in NewNAI to avoid username collisions within i
ts realm or
to conform to a local policy on usernames. </t>
</section>
<section anchor="securityclaims" numbered="true" toc="default">
<name>EAP Security Claims</name>
<t>EAP security claims are defined in <xref target="RFC3748" sectionForm
at="of"
section="7.2.1"/>. The security claims for EAP-NOOB are listed in <xref
target="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-band authenticatio
n</td>
</tr>
<tr>
<td align="left">Protected cryptosuite negotiation</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 o
f at least 128
bits.</td>
</tr>
<tr>
<td align="left">Dictionary attack protection</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 c
onvey
integrity-protected channel properties, such as network SSID or pee
r MAC
address.)</td>
</tr>
</tbody>
</table>
</section> </section>
</section>
</middle>
<back>
<section title="Channel Binding" anchor="channel-binding"> <displayreference target="I-D.tschofenig-tls-cwt" to="TLS-CWT"/>
<t> <displayreference target="I-D.ietf-rats-eat" to="RATS-EAT"/>
EAP channel binding, defined in <xref target="RFC6677"/>, means that t
he endpoints compare their perceptions of network properties, such as lower-laye
r identifiers, over the secure channel established by EAP authentication. Sectio
n 4.1 of <xref target="RFC6677"/> defines two approaches to channel binding. EAP
-NOOB follows the first approach, in which the peer and server exchange plaintex
t 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 verifie
d with message authentication codes (MACp, MACs, MACp2, MACs2). This allows poli
cy-based comparison with locally perceived network properties on either side, as
well as logging for debugging purposes. The peer MAY include in PeerInfo any da
ta items that it wants to bind to the EAP-NOOB association and to the exported k
eys. These can be properties of the authenticator or the access link, such as th
e SSID and BSSID of the wireless network (see <xref target="table-serverinfo-mea
ning"/>). As noted in Section 4.3 of <xref target="RFC6677"/>, the scope of the
channel binding varies between deployments. For example, the server may have les
s link-layer information available from roaming networks than from a local enter
prise network, and it may be unable to verify all the network properties receive
d in PeerInfo. There are also privacy considerations related to exchanging the S
erverInfo and PeerInfo while roaming (see <xref target="privacyconsiderations"/>
).
</t>
<t>
Channel binding to secure channels, defined in <xref target="RFC5056"/
>, binds authentication at a higher protocol layer to a secure channel at a lowe
r 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 t
hese keys. Additionally, EAP-NOOB exports the key AMSK, which may be used to bin
d application-layer authentication to the secure channel created by EAP-NOOB and
to the session keys MSK and EMSK.
</t>
</section>
<section title="Denial of Service" anchor="dos"> <references>
<t> <name>References</name>
While denial-of-service (DoS) attacks by on-link attackers cannot be f <references>
ully prevented, the design goal in EAP-NOOB is to void long-lasting failure caus <name>Normative References</name>
ed by an attacker who is present only temporarily or intermittently. The main de <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
fense mechanism is the persistent EAP-NOOB association, which is never deleted a .2104.xml"/>
utomatically due to in-band messages or error indications. Thus, the endpoints c <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
an always use the persistent association for reconnecting after the DoS attacker .2119.xml"/>
leaves the network. In this sense, the persistent association serves the same f <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
unction in EAP-NOOB as a permanent master key or certificate in other authentica .3748.xml"/>
tion protocols. We discuss logical attacks against the updates of the persistent <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
association in <xref target="completion-loss"/>. .4648.xml"/>
</t> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
<t> .5247.xml"/>
In addition to logical DoS attacks, it is necessary to consider resour <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
ce exhaustion attacks against the EAP server. The number of persistent EAP-NOOB .6234.xml"/>
associations created in the server is limited by the need for a user to assist i <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
n delivering the OOB message. The users can be authenticated for the input or ou .7517.xml"/>
tput of the OOB message at the EAP server, and any users who create excessive nu <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
mbers of persistent associations can be held accountable and their associations .7518.xml"/>
can be deleted by the server administrator. What the attacker can do without use <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
r authentication is to perform the Initial Exchange repeatedly and create a larg .7542.xml"/>
e number of ephemeral associations (server in state 1, Waiting for OOB) without <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
ever delivering the OOB message. Above in <xref target="peeridentifiers"/>, it w .7748.xml"/>
as suggested that the server should store the ephemeral states for at least a da <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
y. This may require off-loading the state storage from memory to disk during a D .8037.xml"/>
oS attack. However, if the server implementation is unable to keep up with a rat <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
e of Initial Exchanges performed by a DoS attacker and needs to drop some epheme .8174.xml"/>
ral states, no damage is caused to already created persistent associations, and <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
the honest users can resume registering new peers when the DoS attacker leaves t .8126.xml"/>
he network. <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
</t> .8259.xml"/>
<t>
There are some trade-offs in the protocol design between polite back-o
ff and giving way to DoS attackers. An on-link DoS attacker could spoof the Slee
pTime value in the Initial Exchange or Waiting Exchange to cause denial of servi
ce against a specific peer device. There is an upper limit on the SleepTime (360
0 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 a
fter the delivery of the OOB message before the device performs the Completion E
xchange and becomes functional. Similarly, the Unwanted peer error (error code 2
001) 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 connecti
ng to the server and wait for the user to trigger a reconnection attempt, e.g.,
by resetting the device. As mentioned in <xref target="unwantedpeer"/>, peer dev
ices that are unable to alert the user should continue to retry the Initial Exch
ange infrequently to avoid a permanent DoS condition. We believe a maximum backo
ff 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 att
acks, and politely backing off within some reasonable limits will increase the a
cceptance of the protocol. The maximum backoff times could be updated to be shor
ter as the protocol implementations mature.
</t>
</section>
<section title="Recovery from loss of last message" anchor="completion-los <reference anchor="NIST-DH" target="https://nvlpubs.nist.gov/
s"> nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pdf">
<t> <front>
The EAP-NOOB Completion Exchange, as well as the Reconnect Exchange wi <title>Recommendation for Pair-Wise Key-Establishment Schemes Using
th cryptosuite update, result in a persistent state change that should take plac Discrete
e either on both endpoints or on neither; otherwise, the result is a state misma Logarithm Cryptography</title>
tch that requires user action to resolve. The state mismatch can occur if the fi <author initials="E." surname="Barker" fullname="Elaine Barker">
nal EAP response of the exchanges is lost. In the Completion Exchange, the loss <organization>National Institute of Standards and Technology</orga
of the final response (Type=6) results in the peer moving to Registered (4) stat nization>
e and creating a persistent EAP-NOOB association while the server stays in an ep </author>
hemeral state (1 or 2). In the Reconnect Exchange, the loss of the final respons <author initials="L." surname="Chen" fullname="Lily Chen">
e (Type=9) results in the peer moving to the Registered (4) state and updating i <organization>National Institute of Standards and Technology</orga
ts persistent key material Kz while the server stays in the Reconnecting (3) sta nization>
te and keeps the old key material. </author>
</t> <author initials="A." surname="Roginsky" fullname="Allen Roginsky">
<t> <organization>National Institute of Standards and Technology</orga
The state mismatch is an example of an unavoidable problem in distribu nization>
ted systems: it is theoretically impossible to guarantee synchronous state chang </author>
es in endpoints that communicate asynchronously. The protocol will always have o <author initials="A." surname="Vassilev" fullname="Apostol Vassilev"
ne critical message that may get lost, so that one side commits to the state cha >
nge and the other side does not. In EAP, the critical message is the final respo <organization>National Institute of Standards and Technology</orga
nse from the peer to the server. While the final response is normally followed b nization>
y EAP-Success, <xref target="RFC3748"/> section 4.2 states that the peer MAY ass </author>
ume that the EAP-Success was lost and the authentication was successful. Further <author initials="R." surname="Davis" fullname="Richard Davis">
more, EAP method implementations in the peer do not receive notification of the <organization>National Security Agency</organization>
EAP-Success message from the parent EAP state machine <xref target="RFC4137"/>. </author>
For these reasons, EAP-NOOB on the peer side commits to a state change already w <date month="April" year="2018"/>
hen it sends the final response. </front>
</t> <seriesInfo name="DOI" value="10.6028/NIST.SP.800-56Ar3"/>
<t> <seriesInfo name="NIST Special Publication" value="800-56A Revision 3"
The best available solution to the loss of the critical message is to />
keep trying. EAP retransmission behavior defined in Section 4.3 of <xref target= </reference>
"RFC3748"/> suggests 3-5 retransmissions. In the absence of an attacker, this wo
uld be sufficient to reduce the probability of failure to an acceptable level. H
owever, a determined attacker on the in-band channel can drop the final EAP-Resp
onse message and all subsequent retransmissions. In the Completion Exchange (Key
ingMode=0) and in the Reconnect Exchange with cryptosuite upgrade (KeyingMode=3)
, this could result in a state mismatch and persistent denial of service until t
he user resets the peer state.
</t>
<t>
EAP-NOOB implements its own recovery mechanism that allows unlimited r
etries of the Reconnect Exchange. When the DoS attacker eventually stops droppin
g packets on the in-band channel, the protocol will recover. The logic for this
recovery mechanism is specified in <xref target="reconnectexchange"/>.
</t>
<t>
EAP-NOOB does not implement the same kind of retry mechanism in the Co
mpletion Exchange. The reason is that there is always a user involved in the ini
tial association process, and the user can repeat the OOB Step to complete the a
ssociation after the DoS attacker has left. On the other hand, Reconnect Exchang
e needs to work without user involvement.
</t>
</section>
<section title="Privacy considerations" anchor="privacyconsiderations"> <reference anchor="FIPS186-4">
<t> <front>
There are privacy considerations related to performing the Reconnect E <title>Digital Signature Standard (DSS)</title>
xchange while roaming. The peer and server may send updated PeerInfo and ServerI <author>
nfo fields in the Reconnect Exchange. This data is sent unencrypted between the <organization>National Institute of Standards and Technology (NIST
peer and the EAP authenticator, such as a wireless access point. Thus, it can be )</organization>
observed by both outsiders and the access network. The PeerInfo field contains </author>
identifiers and other information about the peer device (see <xref target="table <date month="July" year="2013"/>
-serverinfo-meaning" />). While the information refers to the peer device and no </front>
t directly to the user, it can leak information about the user to the access net <seriesInfo name="DOI" value="10.6028/NIST.FIPS.186-4"/>
work and to outside observers. The ServerInfo, on the other hand, can leak infor <seriesInfo name="FIPS" value="186-4"/>
mation about the peer's affiliation with the home network. For this reason, the </reference>
optional PeerInfo and ServerInfo in the Reconnect Exchange SHOULD be omitted unl
ess some critical data has changed and it cannot be updated on the application l
ayer.
</t>
<t>
Peer devices that randomize their layer-2 address to prevent tracking
can do this whenever the user resets the EAP-NOOB association. During the lifeti
me of the association, the PeerId is a unique identifier that can be used to tra
ck the peer in the access network. Later versions of this specification may cons
ider updating the PeerId at each Reconnect Exchange. In that case, it is necessa
ry to consider how the authenticator and access-network administrators can recog
nize and add misbehaving peer devices to a deny list, as well as, how to avoid l
oss of synchronization between the server and the peer if messages are lost duri
ng the identifier update.
</t>
<t>
To enable stronger identity protection in later versions of EAP-NOOB,
the optional server-assigned NAI (NewNAI) SHOULD have a constant username part.
The RECOMMENDED username is "noob". The server MAY, however, send a different us
ername in NewNAI to avoid username collisions within its realm or to conform to
a local policy on usernames.
</t>
</section>
<section title="EAP security claims" anchor="securityclaims"> <reference anchor="EUI-48">
<t> <front>
EAP security claims are defined in section 7.2.1 of <xref target="RFC3 <title>IEEE Standard for Local and Metropolitan Area Networks: Overv
748"/>. The security claims for EAP-NOOB are listed in <xref target="table-secur iew and
ityclaims"/>. Architecture</title>
</t> <author>
<texttable title="EAP security claims" anchor="table-securityclaims"> <organization>IEEE</organization>
<ttcol>Security property</ttcol> </author>
<ttcol>EAP-NOOB claim</ttcol> <date month="June" year="2014"/>
<c>Authentication mechanism</c> </front>
<c>ECDHE key exchange with out-of-band authentication</c> <seriesInfo name="DOI" value="10.1109/IEEESTD.2014.6847097"/>
<c></c><c></c> <seriesInfo name="IEEE Standard" value="802-2014"/>
<c>Protected cryptosuite negotiation</c> </reference>
<c>yes</c> </references>
<c></c><c></c> <references>
<c>Mutual authentication</c> <name>Informative References</name>
<c>yes</c> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<c></c><c></c> FC.2904.xml"/>
<c>Integrity protection</c> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
<c>yes</c> C.4137.xml"/>
<c></c><c></c> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
<c>Replay protection</c> C.3986.xml"/>
<c>yes</c> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
<c></c><c></c> C.5056.xml"/>
<c>Confidentiality</c> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
<c>no</c> C.6677.xml"/>
<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 bit
s.</c>
<c></c><c></c>
<c>Dictionary attack protection</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>yes (The ServerInfo and PeerInfo can be used to convey integrity-pr
otected channel properties such as network SSID or peer MAC address.)</c>
</texttable>
</section>
</section>
</middle> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.t
<back> schofenig-tls-cwt.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.i
etf-rats-eat.xml"/>
<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 -->
<reference anchor="NIST-DH" target="https://nvlpubs.nist.gov/nistpubs/Spec
ialPublications/NIST.SP.800-56Ar3.pdf">
<front>
<title>Recommendation for Pair-Wise Key Establishment Schemes Using Di
screte Logarithm Cryptography</title>
<author initials="E." surname="Barker" fullname="Elaine Barker">
<organization>National Institute of Standards and Technology</organi
zation>
</author>
<author initials="L." surname="Chen" fullname="Lily Chen">
<organization>National Institute of Standards and Technology</organi
zation>
</author>
<author initials="A." surname="Roginsky" fullname="Allen Roginsky">
<organization>National Institute of Standards and Technology</organi
zation>
</author>
<author initials="A." surname="Vassilev" fullname="Apostol Vassilev">
<organization>National Institute of Standards and Technology</organi
zation>
</author>
<author initials="R." surname="Davis" fullname="Richard Davis">
<organization>National Security Agency</organization>
</author>
<date month="April" year="2018" />
</front>
<seriesInfo name="NIST Special Publication 800-56A Revision 3" value=""
/>
</reference>
<reference anchor='FIPS186-4'>
<front>
<title>Digital Signature Standard (DSS)</title>
<author>
<organization>National Institute of Standards and Technology</organiza
tion>
</author>
<date month='July' year='2013'/>
</front>
<seriesInfo name='FIPS 186-4' value=''/>
</reference>
<reference anchor="EUI-48">
<front>
<title>802-2014 IEEE Standard for Local and Metropolitan Area Networks
: Overview and Architecture.</title>
<author>
<organization>Institute of Electrical and Electronics Engineers</org
anization>
</author>
<date month="June" year="2014" />
</front>
<seriesInfo name=" IEEE Standard 802-2014." value="" />
</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 certificat
es -->
<?rfc include='reference.I-D.ietf-rats-eat'?> <!-- Entity attestation toke
n -->
<reference anchor="IEEE-802.1X"> <reference anchor="IEEE-802.1X">
<front> <front>
<title>Local and Metropolitan Area Networks: Port-Based Network Access <title>IEEE Standard for Local and Metropolitan Area Networks--Port-
Control</title> Based
<author> Network Access Control</title>
<organization>Institute of Electrical and Electronics Engineers</org <author>
anization> <organization>IEEE</organization>
</author> </author>
<date month="December" year="2004" /> <date month="February" year="2020"/>
</front> </front>
<seriesInfo name=" IEEE Standard 802.1X-2004." value="" /> <seriesInfo name="IEEE Standard" value="802.1X-2020"/>
</reference> </reference>
<reference anchor="Sethi14" target="http://dx.doi.org/10.1145/2632048.2632
049"> <reference anchor="Sethi14" target="http://dx.doi.org/10.1145/2632048.26
<front> 32049">
<title>Secure Bootstrapping of Cloud-Managed Ubiquitous Displays</titl <front>
e> <title>Secure bootstrapping of cloud-managed ubiquitous displays</ti
<author initials="M." surname="Sethi" fullname="Mohit Sethi"> tle>
<organization>Ericsson</organization> <author initials="M." surname="Sethi" fullname="Mohit Sethi">
</author> <organization>Ericsson</organization>
<author initials="E." surname="Oat" fullname="Elena Oat"> </author>
<organization>Aalto University</organization> <author initials="E." surname="Oat" fullname="Elena Oat">
</author> <organization>Aalto University</organization>
<author initials="M." surname="Di Francesco" fullname="Mario Di France </author>
sco"> <author initials="M." surname="Di Francesco" fullname="Mario Di Fran
<organization>Aalto University</organization> cesco">
</author> <organization>Aalto University</organization>
<author initials="T." surname="Aura" fullname="Tuomas Aura"> </author>
<organization>Aalto University</organization> <author initials="T." surname="Aura" fullname="Tuomas Aura">
</author> <organization>Aalto University</organization>
<date month="September" year="2014" /> </author>
</front> <date month="September" year="2014"/>
<seriesInfo name="Proceedings of ACM International Joint Conference on P </front>
ervasive and Ubiquitous Computing (UbiComp 2014), pp. 739-750, Seattle, USA" val <seriesInfo name="DOI" value="10.1145/2632048.2632049"/>
ue="" /> <refcontent>Proceedings of ACM International Joint Conference on Perva
</reference> sive and
<reference anchor="BluetoothPairing"> Ubiquitous Computing (UbiComp 2014), pp. 739-750, Seattle, USA</refcont
<front> ent>
<title>Simple pairing whitepaper</title> </reference>
<author>
<organization>Bluetooth, SIG</organization> <reference anchor="Bluetooth" target="https://www.bluetooth.com/specific
</author> ations/bluetooth-core-specification">
<date year="2007" /> <front>
</front> <title>Bluetooth Core Specification Version 5.3</title>
<seriesInfo name=" Technical report" value="" /> <author>
</reference> <organization>Bluetooth Special Interest Group</organization>
<reference anchor="mcrl2" target="https://mitpress.mit.edu/books/modeling- </author>
and-analysis-communicating-systems"> <date year="2021" month="July"/>
<front> </front>
<title>Modeling and analysis of communicating systems</title> </reference>
<author initials="J.F." surname="Groote" fullname="Jan Friso Groote">
<organization>Eindhoven University of Technology</organization> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</author> FC.5216.xml"/>
<author initials="M.R." surname="Mousavi" fullname="Mohammad Reza Mous
avi">
<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-noo
b/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">
</author>
<date year="2021" />
</front>
</reference>
<reference anchor="proverif" target="http://prosecco.gforge.inria.fr/perso
nal/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 -->
<reference anchor="Sethi19" target="https://arxiv.org/abs/1902.07550"> <reference anchor="Sethi19" target="https://arxiv.org/abs/1902.07550">
<front> <front>
<title>Misbinding Attacks on Secure Device Pairing</title> <title>Misbinding Attacks on Secure Device Pairing and Bootstrapping
<author initials="M." surname="Sethi" fullname="Mohit Sethi"> </title>
<author initials="M." surname="Sethi" fullname="Mohit Sethi">
</author> </author>
<author initials="A." surname="Peltonen" fullname="Aleksi Peltonen"> <author initials="A." surname="Peltonen" fullname="Aleksi Peltonen">
</author> </author>
<author initials="T." surname="Aura" fullname="Tuomas"> <author initials="T." surname="Aura" fullname="Tuomas Aura">
</author> </author>
<date year="2019" /> <date year="2019" month="February"/>
</front> </front>
</reference> <seriesInfo name="DOI" value="10.1145/3321705.3329813"/>
</reference>
</references>
</references> </references>
<section anchor="exchangeappendix" numbered="true" toc="default">
<name>Exchanges and Events per State</name>
<t><xref target="tab-exchanges" format="default"/> shows how the EAP serve
r chooses the
exchange type depending on the server and peer states. In the state combin
ations
marked with hyphen "-", there is no possible exchange and user action is r
equired to
make progress. Note that peer state 4 is omitted from the table because th
e peer never
connects to the server when the peer is in that state. The table also show
s the
handling of errors in each exchange. A notable detail is that the recipien
t of error
code 2003 moves to state 1.</t>
<table anchor="tab-exchanges">
<name>How the Server Chooses the Exchange Type</name>
<thead>
<tr>
<th>Peer States</th>
<th>Exchange Chosen by the Server</th>
<th>Next Peer and Server States</th>
</tr>
</thead>
<tbody>
<tr>
<td colspan="3" align="center">Server State: Unregistered (0)</td>
</tr>
<tr>
<td>0..2</td>
<td>Initial Exchange</td>
<td>both 1 (0 on error)</td>
</tr>
<tr>
<td>3</td>
<td>-</td>
<td>no change, notify user</td></tr>
<tr>
<td colspan="3" align="center">Server State: Waiting for OOB (1)</td>
</tr>
<tr>
<td>0</td>
<td>Initial Exchange</td>
<td>both 1 (0 on error)</td>
</tr>
<section title="Exchanges and events per state" anchor="exchangeappendix"> <tr>
<t> <td>1</td>
<xref target="table-exchanges"/> shows how the EAP server chooses the ex <td>Waiting Exchange</td>
change type depending on the server and peer states. In the state combinations m <td>both 1 (no change on error)</td>
arked with hyphen "-", there is no possible exchange and user action is required </tr>
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 rec
ipient of error code 2003 moves to state 1.
</t>
<t>
<figure title="How server chooses the exchange type" anchor="table-excha
nges">
<artwork align="center">
<![CDATA[
+--------+---------------------------+------------------------------+
| peer | exchange chosen by | next peer and |
| states | server | server states |
+========+===========================+==============================+
| server state: Unregistered (0) |
+--------+---------------------------+------------------------------+
| 0..2 | Initial Exchange | both 1 (0 on error) |
| 3 | - | no change, notify user |
+--------+---------------------------+------------------------------+
| server state: Waiting for OOB (1) |
+--------+---------------------------+------------------------------+
| 0 | Initial Exchange | both 1 (0 on error) |
| 1 | Waiting Exchange | both 1 (no change on error) |
| 2 | Completion Exchange | both 4 (A) |
| 3 | - | no change, notify user |
+--------+---------------------------+------------------------------+
| server state: OOB Received (2) |
+--------+---------------------------+------------------------------+
| 0 | Initial Exchange | both 1 (0 on error) |
| 1 | Completion Exchange | both 4 (B) |
| 2 | Completion Exchange | both 4 (A) |
| 3 | - | no change, notify user |
+--------+---------------------------+------------------------------+
| server state: Reconnecting (3) or Registered (4) |
+--------+---------------------------+------------------------------+
| 0..2 | - | no change, notify user |
| 3 | Reconnect Exchange | both 4 (3 on error) |
+--------+---------------------------+------------------------------+
(A) peer to 1 on error 2003, no other changes on error
(B) server to 1 on error 2003, no other changes on error
]]>
</artwork>
</figure>
</t>
<t>
<xref target="table-localevents"/> lists the local events that can take
place in the server or peer. Both the server and peer output and accept OOB mess
ages in association state 1, leading the receiver to state 2. Communication erro
rs and timeouts in states 0..2 lead back to state 0, while similar errors in sta
tes 3..4 lead to state 3. Application request for rekeying (e.g., to refresh ses
sion keys or to upgrade cryptosuite) also takes the association from state 3..4
to state 3. User can always reset the association state to 0. Recovering associa
tion data, e.g., from a backup, leads to state 3.
</t>
<t>
<figure anchor="table-localevents" title="Local events on server and pee
r">
<artwork align="center">
<![CDATA[
+--------+----------------------------------+--------------------+
| server/| possible local events | next state |
| peer | on server and peer | |
| state | | |
+========+==================================+====================+
| 1 | OOB Output | 1 |
| 1 | OOB Input | 2 (1 on error) |
| 0..2 | Mobility/timeout/network failure | 0 |
| 3..4 | Mobility/timeout/network failure | 3 |
| 3..4 | Rekeying request | 3 |
| 0..4 | User resets association | 0 |
| 0..4 | Association state recovery | 3 |
+--------+----------------------------------+--------------------+
]]>
</artwork>
</figure>
</t>
</section>
<section title="Application-specific parameters" anchor="oobchannelappendix" <tr>
> <td>2</td>
<t> <td>Completion Exchange</td>
<xref target="table-oobchannel"/> lists OOB channel parameters that need <td>both 4 (A)</td>
to be specified in each application that makes use of EAP-NOOB. The list is not </tr>
exhaustive and is included for the convenience of implementers only.
</t>
<texttable title="OOB channel characteristics" anchor="table-oobchannel">
<ttcol>Parameter</ttcol>
<ttcol>Description</ttcol>
<c>OobDirs</c><c>Allowed directions of the OOB channel</c>
<c></c><c></c>
<c>OobMessageEncoding</c><c>How the OOB message data fields are encoded
for the OOB channel</c>
<c></c><c></c>
<c>SleepTimeDefault</c><c>Default minimum time in seconds that the peer
should sleep before the next Waiting Exchange</c>
<c></c><c></c>
<c>OobRetries</c><c>Number of received OOB messages with invalid Hoob af
ter which the receiver moves to Unregistered (0) state. When the OOB channel has
error detection or correction, the RECOMMENDED value is 5.</c>
<c></c><c></c>
<c>NoobTimeout</c><c>How many seconds the sender of the OOB message reme
mbers the sent Noob value. The RECOMMENDED value is 3600 seconds.</c>
<c></c><c></c>
<c>ServerInfoType</c><c>The value of the Type field and the other requir
ed fields in ServerInfo</c>
<c></c><c></c>
<c>PeerInfoType</c><c>The value of the Type field and the other required
fields in PeerInfo</c>
</texttable>
</section>
<section title="EAP-NOOB roaming" anchor="roaming"> <tr>
<t> <td>3</td>
AAA architectures <xref target="RFC2904"/> allow for roaming of network- <td>-</td>
connected appliances that are authenticated over EAP. While the peer is roaming <td>no change, notify user</td>
in a visited network, authentication still takes place between the peer and an a </tr>
uthentication server at its home network. EAP-NOOB supports such roaming by allo
wing 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 AAA ser
ver.
</t>
<t>
A peer device that is new or has gone through a hard reset should be con
nected 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 Reconn
ect Exchange from the visited network.
</t>
<t>
Alternatively, the device may provide some method for the user to config
ure the NAI of the home network. This is the user or application configured NAI
mentioned in <xref target="nai"/>. 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 roaming, the device needs to identify the networks where the EAP-N
OOB association can be used to gain network access. For 802.11 access networks,
the server MAY send a list of SSID strings in the ServerInfo field called either
SSIDList or Base64SSIDList. The list is formatted as explained in <xref target=
"table-serverinfo-meaning"/>. If present, the peer MAY use this list as a hint t
o determine the networks where the EAP-NOOB association can be used for access a
uthorization, in addition to the access network where the Initial Exchange took
place.
</t>
</section>
<section title="OOB message as URL" anchor="urloob"> <tr>
<t> <td colspan="3" align="center">Server State: OOB Received (2)</td>
While EAP-NOOB does not mandate any particular OOB communication channel </tr>
, 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 UR
L, which is then encoded as a QR code for displays and printers or as an NDEF re
cord for dynamic NFC tags. A user can then simply scan the QR code or NFC tag an
d open the URL, which causes the OOB message to be delivered to the authenticati
on server. The URL MUST specify https or another server-authenticated scheme, so
that there is a secure connection to the server and the on-path attacker cannot
read or modify the OOB message.
</t>
<t>
The ServerInfo in this case includes a field called ServerURL of the fol
lowing format with RECOMMENDED length of at most 60 characters:
</t>
<t>
https://&lt;host&gt;[:&lt;port&gt;]/[&lt;path&gt;]
</t>
<t>
To this, the peer appends the OOB message fields (PeerId, Noob, Hoob) as
a query string. PeerId is provided to the peer by the server and 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 parameters MAY
be in any order. The resulting URL is of the following format:
</t>
<t>
https://&lt;host&gt;[:&lt;port&gt;]/[&lt;path&gt;]?P=&lt;PeerId&gt;&amp;
N=&lt;Noob&gt;&amp;H=&lt;Hoob&gt;
</t>
<t>
The following is an example of a well-formed URL encoding the OOB messag
e (without line breaks):
</t>
<t>
https://aaa.example.com/eapnoob?P=mcm5BSCDZ45cYPlAr1ghNw&amp;N=rMinS0-F4
EfCU8D9ljxX_A&amp;H=QvnMp4UGxuQVFaXPW_14UW
</t>
</section>
<section title="Version history" anchor="vertrack"> <tr>
<t> <td>0</td>
<list style="symbols"> <td>Initial Exchange</td>
<t> <td>both 1 (0 on error)</td>
Version 01: </tr>
<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 lengt
hs 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 dire
ction. </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 unrecogn
ized 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 fut
ure.</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 avo
id 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 directo
rate 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 u
sername 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, cha
nnel 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 endpoint
s.</t>
<t>Example messages removed.</t>
</list>
</t>
</list>
</t>
</section>
<section title="Acknowledgments" anchor="acks"> <tr>
<t> <td>1</td>
Max Crone, Shiva Prasad TP, and Raghavendra MS implemented parts of this <td>Completion Exchange</td>
protocol with wpa_supplicant and hostapd. Eduardo Ingles (RFC editor: please ad <td>both 4 (B)</td>
d an accented e in Ingles) and Dan Garcia-Carrillo were involved in the implemen </tr>
tation of this protocol on Contiki. Their inputs helped us in improving the spec
ification. <tr>
</t> <td>2</td>
<t> <td>Completion Exchange</td>
The authors would like to thank Rhys Smith and Josh Howlett for providin <td>both 4 (A)</td>
g valuable feedback as well as new use cases and requirements for the protocol. </tr>
Thanks to Eric Rescorla, Alan Dekok, Darshak Thakore, Stefan Winter, Hannes Tsch
ofenig, Daniel Migault, Roman Danyliw, Benjamin Kaduk, Francesca Palombini, Stev <tr>
e Hanna, Lars Eggert, and Eric Vyncke for their comments and reviews. <td>3</td>
</t> <td>-</td>
<t> <td>no change, notify user</td>
We would also like to express our sincere gratitude to Dave Thaler for hi </tr>
s thorough review of the document.
</t> <tr>
<td colspan="3" align="center">Server State: Reconnecting (3) or Regi
stered
(4)</td>
</tr>
<tr>
<td>0..2</td>
<td>-</td>
<td>no change, notify user</td>
</tr>
<tr>
<td>3</td>
<td>Reconnect Exchange</td>
<td>both 4 (3 on error)</td></tr>
</tbody>
</table>
<dl>
<dt>(A)</dt>
<dd>peer to 1 on error 2003; no other changes on error</dd>
<dt>(B)</dt>
<dd>server to 1 on error 2003; no other changes on error</dd>
</dl>
<t><xref target="tab-localevents" format="default"/> lists the local event
s that can
take place in the server or peer. Both the server and peer output and acce
pt OOB
messages in association state 1, leading the receiver to state 2. Communic
ation errors
and timeouts in states 0..2 lead back to state 0, while similar errors in
states 3..4
lead to state 3. An application request for rekeying (e.g., to refresh ses
sion keys or
to upgrade cryptosuite) also takes the association from state 3..4 to stat
e 3. The user
can always reset the association state to 0. Recovering association data,
e.g., from a
backup, leads to state 3.</t>
<table anchor="tab-localevents">
<name>Local Events in the Server and Peer</name>
<thead>
<tr>
<th>Server/Peer State</th>
<th>Possible Local Events in the Server and Peer</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 on error)</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 resets association</td>
<td>0</td>
</tr>
<tr>
<td>0..4</td>
<td>Association state recovery</td>
<td>3</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="oobchannelappendix" numbered="true" toc="default">
<name>Application-Specific Parameters</name>
<t><xref target="tab-oobchannel" format="default"/> lists OOB channel para
meters that
need to be specified in each application that makes use of EAP-NOOB. The l
ist is not
exhaustive and is included for the convenience of implementers only.</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 OOB channel.</td>
</tr>
<tr>
<td align="left">OobMessageEncoding</td>
<td align="left">How the OOB message data fields are encoded for the
OOB
channel.</td>
</tr>
<tr>
<td align="left">SleepTimeDefault</td>
<td align="left">Default minimum time in seconds that the peer shoul
d sleep before
the next Waiting Exchange.</td>
</tr>
<tr>
<td align="left">OobRetries</td>
<td align="left">Number of received OOB messages with invalid Hoob,
after which the
receiver moves to Unregistered (0) state. When the OOB channel has er
ror detection
or correction, the <bcp14>RECOMMENDED</bcp14> value is 5.</td>
</tr>
<tr>
<td align="left">NoobTimeout</td>
<td align="left">How many seconds the sender of the OOB message reme
mbers the sent
Noob value. The <bcp14>RECOMMENDED</bcp14> value is 3600 seconds.</td
>
</tr>
<tr>
<td align="left">ServerInfoType</td>
<td align="left">The value of the Type field and the other required
fields in
ServerInfo.</td>
</tr>
<tr>
<td align="left">PeerInfoType</td>
<td align="left">The value of the Type field and the other required
fields in
PeerInfo.</td>
</tr>
</tbody>
</table>
</section>
<section anchor="roaming" numbered="true" toc="default">
<name>EAP-NOOB Roaming</name>
<t>AAA architectures <xref target="RFC2904" format="default"/> allow for r
oaming of
network-connected appliances that are authenticated over EAP. While the pe
er is roaming
in a visited network, authentication still takes place between the peer an
d 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, i
t enables the
visited network to route the EAP session to the peer's home AAA server.</t
>
<t>A peer device that is new or has gone through a hard reset should be co
nnected first
to the home network and establish an EAP-NOOB association with its home AA
A server
before it is able to roam. After that, it can perform the Reconnect Exchan
ge from the
visited network.</t>
<t>Alternatively, the device may provide some method for the user to confi
gure the NAI
of the home network. This is the user or application-configured NAI mentio
ned in <xref
target="nai" format="default"/>. In that case, the EAP-NOOB association ca
n be created
while roaming. The configured NAI enables the EAP messages to be routed co
rrectly to the
home AAA server. </t>
<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 server
<bcp14>MAY</bcp14> send a list of SSID strings in the ServerInfo field, ca
lled either
SSIDList or Base64SSIDList. The list is formatted as explained in <xref
target="tab-serverinfo-meaning" format="default"/>. If present, the peer
<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 acces
s network
where the Initial Exchange took place.</t>
</section>
<section anchor="urloob" numbered="true" toc="default">
<name>OOB Message as a URL</name>
<t>While EAP-NOOB does not mandate any particular OOB communication channe
l, 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 an NFC 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 URL
<bcp14>MUST</bcp14> specify https or another server-authenticated scheme s
o that there
is a secure connection to the server and the on-path attacker cannot read
or modify the
OOB message.</t>
<t>The ServerInfo in this case includes a field called ServerURL of the fo
llowing format
with a <bcp14>RECOMMENDED</bcp14> length of at most 60 characters:</t>
<t><tt>https://&lt;host&gt;[:&lt;port&gt;]/[&lt;path&gt;]</tt></t>
<t>To this, the peer appends the OOB message fields (PeerId, Noob, and Hoo
b) as a query
string. PeerId is provided to the peer by the server and might be a 22-cha
racter ASCII
string. The peer base64url encodes, without padding, the 16-byte values No
ob and Hoob
into 22-character ASCII strings. The query parameters <bcp14>MAY</bcp14> b
e in any
order. The resulting URL is of the following format:</t>
<t><tt>https://&lt;host&gt;[:&lt;port&gt;]/[&lt;path&gt;]?P=&lt;PeerId&gt;
&amp;N=&lt;Noob&gt;&amp;H=&lt;Hoob&gt;</tt> </t>
<t>The following is an example of a well-formed URL encoding the OOB messa
ge (without
line breaks):</t>
<t><tt>https://aaa.example.com/eapnoob?P=mcm5BSCDZ45cYPlAr1ghNw&amp;N=rMin
S0-F4EfCU8D9ljxX_A&amp;H=QvnMp4UGxuQVFaXPW_14UW</tt></t>
</section>
<section anchor="acks" numbered="false" toc="default">
<name>Acknowledgments</name>
<t><contact fullname="Max Crone"/>, <contact fullname="Shiva Prasad TP"/>,
and <contact
fullname="Raghavendra MS"/> implemented parts of this protocol with wpa_su
pplicant and
hostapd. <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 impr
oving the
specification.</t>
<t>The authors would like to thank <contact fullname="Rhys Smith"/> and <c
ontact
fullname="Josh Howlett"/> for providing valuable feedback, as well as new
use cases and
requirements for the protocol. Thanks to <contact fullname="Eric Rescorla"
/>, <contact
fullname="Alan Dekok"/>, <contact fullname="Darshak Thakore"/>, <contact
fullname="Stefan Winter"/>, <contact fullname="Hannes Tschofenig"/>, <cont
act
fullname="Daniel Migault"/>, <contact fullname="Roman Danyliw"/>, <contact
fullname="Benjamin Kaduk"/>, <contact fullname="Francesca Palombini"/>, <c
ontact
fullname="Steve Hanna"/>, <contact fullname="Lars Eggert"/>, and <contact
fullname="Éric
Vyncke"/> for their comments and reviews.</t>
<t>We would also like to express our sincere gratitude to <contact fullnam
e="Dave
Thaler"/> for his thorough review of the document.</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 87 change blocks. 
2842 lines changed or deleted 4001 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/