rfc9140.original   rfc9140.txt 
Network Working Group T. Aura Internet Engineering Task Force (IETF) T. Aura
Internet-Draft Aalto University Request for Comments: 9140 Aalto University
Intended status: Standards Track M. Sethi Category: Standards Track M. Sethi
Expires: March 7, 2022 Ericsson ISSN: 2070-1721 Ericsson
A. Peltonen A. Peltonen
Aalto University Aalto University
September 3, 2021 December 2021
Nimble out-of-band authentication for EAP (EAP-NOOB) Nimble Out-of-Band Authentication for EAP (EAP-NOOB)
draft-ietf-emu-eap-noob-06
Abstract Abstract
The Extensible Authentication Protocol (EAP) provides support for The Extensible Authentication Protocol (EAP) provides support for
multiple authentication methods. This document defines the EAP-NOOB multiple authentication methods. This document defines the EAP-NOOB
authentication method for nimble out-of-band (OOB) authentication, authentication method for nimble out-of-band (OOB) authentication and
and key derivation. The EAP method is intended for bootstrapping all key derivation. The EAP method is intended for bootstrapping all
kinds of Internet-of-Things (IoT) devices that have no pre-configured kinds of Internet-of-Things (IoT) devices that have no preconfigured
authentication credentials. The method makes use of a user-assisted authentication credentials. The method makes use of a user-assisted,
one-directional OOB message between the peer device and one-directional, out-of-band (OOB) message between the peer device
authentication server to authenticate the in-band key exchange. The and authentication server to authenticate the in-band key exchange.
device must have a non-network input or output interface, such as a The device must have a nonnetwork input or output interface, such as
display, microphone, speaker, or blinking light, which can send or a display, microphone, speaker, or blinking light, that can send or
receive dynamically generated messages of tens of bytes in length. receive dynamically generated messages of tens of bytes in length.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on March 7, 2022. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9140.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Revised BSD License text as described in Section 4.e of the
the Trust Legal Provisions and are provided without warranty as Trust Legal Provisions and are provided without warranty as described
described in the Simplified BSD License. in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology
3. EAP-NOOB protocol . . . . . . . . . . . . . . . . . . . . . . 5 3. EAP-NOOB Method
3.1. Protocol overview . . . . . . . . . . . . . . . . . . . . 5 3.1. Protocol Overview
3.2. Protocol messages and sequences . . . . . . . . . . . . . 8 3.2. Protocol Messages and Sequences
3.2.1. Common handshake in all EAP-NOOB exchanges . . . . . 8 3.2.1. Common Handshake in All EAP-NOOB Exchanges
3.2.2. Initial Exchange . . . . . . . . . . . . . . . . . . 10 3.2.2. Initial Exchange
3.2.3. OOB Step . . . . . . . . . . . . . . . . . . . . . . 11 3.2.3. OOB Step
3.2.4. Completion Exchange . . . . . . . . . . . . . . . . . 13 3.2.4. Completion Exchange
3.2.5. Waiting Exchange . . . . . . . . . . . . . . . . . . 15 3.2.5. Waiting Exchange
3.3. Protocol data fields . . . . . . . . . . . . . . . . . . 16 3.3. Protocol Data Fields
3.3.1. Peer identifier and NAI . . . . . . . . . . . . . . . 16 3.3.1. Peer Identifier and NAI
3.3.2. Message data fields . . . . . . . . . . . . . . . . . 18 3.3.2. Message Data Fields
3.4. Fast reconnect and rekeying . . . . . . . . . . . . . . . 23 3.4. Fast Reconnect and Rekeying
3.4.1. Persistent EAP-NOOB association . . . . . . . . . . . 24 3.4.1. Persistent EAP-NOOB Association
3.4.2. Reconnect Exchange . . . . . . . . . . . . . . . . . 24 3.4.2. Reconnect Exchange
3.4.3. User reset . . . . . . . . . . . . . . . . . . . . . 27 3.4.3. User Reset
3.5. Key derivation . . . . . . . . . . . . . . . . . . . . . 28 3.5. Key Derivation
3.6. Error handling . . . . . . . . . . . . . . . . . . . . . 31 3.6. Error Handling
3.6.1. Invalid messages . . . . . . . . . . . . . . . . . . 33 3.6.1. Invalid Messages
3.6.2. Unwanted peer . . . . . . . . . . . . . . . . . . . . 33 3.6.2. Unwanted Peer
3.6.3. State mismatch . . . . . . . . . . . . . . . . . . . 33 3.6.3. State Mismatch
3.6.4. Negotiation failure . . . . . . . . . . . . . . . . . 33 3.6.4. Negotiation Failure
3.6.5. Cryptographic verification failure . . . . . . . . . 34 3.6.5. Cryptographic Verification Failure
3.6.6. Application-specific failure . . . . . . . . . . . . 34 3.6.6. Application-Specific Failure
4. ServerInfo and PeerInfo contents . . . . . . . . . . . . . . 35 4. ServerInfo and PeerInfo Contents
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 5. IANA Considerations
5.1. Cryptosuites . . . . . . . . . . . . . . . . . . . . . . 37 5.1. Cryptosuites
5.2. Message Types . . . . . . . . . . . . . . . . . . . . . . 38 5.2. Message Types
5.3. Error codes . . . . . . . . . . . . . . . . . . . . . . . 39 5.3. Error Codes
5.4. ServerInfo data fields . . . . . . . . . . . . . . . . . 39 5.4. ServerInfo Data Fields
5.5. PeerInfo data fields . . . . . . . . . . . . . . . . . . 40 5.5. PeerInfo Data Fields
5.6. Domain name reservation . . . . . . . . . . . . . . . . . 41 5.6. Domain Name Reservation
5.7. Guidance for Designated Experts . . . . . . . . . . . . . 41 5.7. Guidance for Designated Experts
6. Implementation Status . . . . . . . . . . . . . . . . . . . . 42 6. Security Considerations
6.1. Implementation with wpa_supplicant and hostapd . . . . . 42 6.1. Authentication Principle
6.2. Implementation on Contiki . . . . . . . . . . . . . . . . 43 6.2. Identifying Correct Endpoints
6.3. Implementation with wpa_supplicant and hostapd . . . . . 43 6.3. Trusted Path Issues and Misbinding Attacks
6.4. Protocol modeling . . . . . . . . . . . . . . . . . . . . 43 6.4. Peer Identifiers and Attributes
7. Security considerations . . . . . . . . . . . . . . . . . . . 44 6.5. Downgrading Threats
7.1. Authentication principle . . . . . . . . . . . . . . . . 44 6.6. Protected Success and Failure Indications
7.2. Identifying correct endpoints . . . . . . . . . . . . . . 46 6.7. Channel Binding
7.3. Trusted path issues and misbinding attacks . . . . . . . 47 6.8. Denial of Service
7.4. Peer identifiers and attributes . . . . . . . . . . . . . 48 6.9. Recovery from Loss of Last Message
7.5. Downgrading threats . . . . . . . . . . . . . . . . . . . 49 6.10. Privacy Considerations
7.6. Protected success and failure indications . . . . . . . . 50 6.11. EAP Security Claims
7.7. Channel Binding . . . . . . . . . . . . . . . . . . . . . 50 7. References
7.8. Denial of Service . . . . . . . . . . . . . . . . . . . . 51 7.1. Normative References
7.9. Recovery from loss of last message . . . . . . . . . . . 52 7.2. Informative References
7.10. Privacy considerations . . . . . . . . . . . . . . . . . 53 Appendix A. Exchanges and Events per State
7.11. EAP security claims . . . . . . . . . . . . . . . . . . . 54 Appendix B. Application-Specific Parameters
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 56 Appendix C. EAP-NOOB Roaming
8.1. Normative references . . . . . . . . . . . . . . . . . . 56 Appendix D. OOB Message as a URL
8.2. Informative references . . . . . . . . . . . . . . . . . 57 Acknowledgments
Appendix A. Exchanges and events per state . . . . . . . . . . . 60 Authors' Addresses
Appendix B. Application-specific parameters . . . . . . . . . . 61
Appendix C. EAP-NOOB roaming . . . . . . . . . . . . . . . . . . 62
Appendix D. OOB message as URL . . . . . . . . . . . . . . . . . 63
Appendix E. Version history . . . . . . . . . . . . . . . . . . 64
Appendix F. Acknowledgments . . . . . . . . . . . . . . . . . . 67
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 68
1. Introduction 1. Introduction
This document describes a method for registration, authentication and This document describes a method for registration, authentication,
key derivation for network-connected smart devices, such as consumer and key derivation for network-connected smart devices, such as
and enterprise appliances that are part of the Internet of Things consumer and enterprise appliances that are part of the Internet of
(IoT). These devices may be off-the-shelf hardware that is sold and Things (IoT). These devices may be off-the-shelf hardware that is
distributed without any prior registration or credential-provisioning sold and distributed without any prior registration or credential-
process, or they may be recycled devices after a hard reset. Thus, provisioning process, or they may be recycled devices after a hard
the device registration in a server database, ownership of the reset. Thus, the device registration in a server database, ownership
device, and the authentication credentials for both network access of the device, and the authentication credentials for both network
and application-level security must all be established at the time of access and application-level security must all be established at the
the device deployment. Furthermore, many such devices have only time of the device deployment. Furthermore, many such devices have
limited user interfaces that could be used for their configuration. only limited user interfaces that could be used for their
Often, the user interfaces are limited to either only input (e.g., configuration. Often, the user interfaces are limited to either only
camera) or output (e.g., display screen). The device configuration input (e.g., a camera) or output (e.g., a display screen). The
is made more challenging by the fact that the devices may exist in device configuration is made more challenging by the fact that the
large numbers and may have to be deployed or re-configured nimbly devices may exist in large numbers and may have to be deployed or
based on user needs. reconfigured nimbly based on user needs.
To summarize, devices may have the following characteristics: To summarize, devices may have the following characteristics:
o no pre-established relation with the intended server or user, * no preestablished relation with the intended server or user,
o no pre-provisioned device identifier or authentication
credentials,
o input or output interface that may be capable of only one- * no preprovisioned device identifier or authentication credentials,
or
* an input or output interface that may be capable of only one-
directional out-of-band communication. directional out-of-band communication.
Many proprietary out-of-band (OOB) configuration methods exist for Many proprietary out-of-band (OOB) configuration methods exist for
specific IoT devices. The goal of this specification is to provide specific IoT devices. The goal of this specification is to provide
an open standard and a generic protocol for bootstrapping the an open standard and a generic protocol for bootstrapping the
security of network-connected appliances, such as displays, printers, security of network-connected appliances, such as displays, printers,
speakers, and cameras. The security bootstrapping in this speakers, and cameras. The security bootstrapping in this
specification makes use of a user-assisted OOB channel. The device specification makes use of a user-assisted OOB channel. The device
authentication relies on a user having physical access to the device, authentication relies on a user having physical access to the device,
and the key exchange security is based on the assumption that and the key exchange security is based on the assumption that
attackers are not able to observe or modify the messages conveyed attackers are not able to observe or modify the messages conveyed
through the OOB channel. We follow the common approach taken in through the OOB channel. We follow the common approach taken in
pairing protocols: performing a Diffie-Hellman key exchange over the pairing protocols: performing a Diffie-Hellman key exchange over the
insecure network and authenticating the established key with the help insecure network and authenticating the established key with the help
of the OOB channel in order to prevent impersonation attacks. of the OOB channel in order to prevent impersonation attacks.
The solution presented here is intended for devices that have either The solution presented here is intended for devices that have either
a non-network input or output interface, such as a camera, a nonnetwork input or output interface, such as a camera, microphone,
microphone, display screen, speakers or blinking LED light, which is display screen, speaker, or blinking Light Emitting Diode (LED)
able to send or receive dynamically generated messages of tens of light, that is able to send or receive dynamically generated messages
bytes in length. Naturally, this solution may not be appropriate for of tens of bytes in length. Naturally, this solution may not be
very small sensors or actuators that have no user interface at all or appropriate for very small sensors or actuators that have no user
for devices that are inaccessible to the user. We also assume that interface at all or for devices that are inaccessible to the user.
the OOB channel is at least partly automated (e.g., camera scanning a We also assume that the OOB channel is at least partly automated
bar code) and, thus, there is no need to absolutely minimize the (e.g., a camera scanning a bar code); thus, there is no need to
length of the data transferred through the OOB channel. This absolutely minimize the length of the data transferred through the
differs, for example, from Bluetooth pairing [BluetoothPairing], OOB channel. This differs, for example, from Bluetooth pairing
where it is essential to minimize the length of the manually [Bluetooth], where it is essential to minimize the length of the
transferred or compared codes. The OOB messages in this manually transferred or compared codes. The OOB messages in this
specification are dynamically generated. We thus do not support specification are dynamically generated. Thus, we do not support
static printed registration codes. One reason for requiring dynamic static printed registration codes. One reason for requiring dynamic
OOB messages is that the receipt of the OOB message authorizes the OOB messages is that the receipt of the OOB message authorizes the
server to take ownership of the device. Dynamic OOB messages are server to take ownership of the device. Dynamic OOB messages are
more secure than static printed codes, which could be leaked and more secure than static printed codes, which could be leaked and
later misused. later misused.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in BCP 14 [RFC2119] "OPTIONAL" in this document are to be interpreted as described in
[RFC8174] when, and only when, they appear in all capitals, as shown BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
here. capitals, as shown here.
In addition, this document frequently uses the following terms as In addition, this document frequently uses the following terms as
they have been defined in [RFC5216]: they have been defined in [RFC5216]:
authenticator The entity initiating EAP authentication. authenticator
The entity initiating EAP authentication.
peer The entity that responds to the authenticator. In peer
The entity that responds to the authenticator. In
[IEEE-802.1X], this entity is known as the supplicant. (We use [IEEE-802.1X], this entity is known as the supplicant. (We use
the terms peer, device, and peer device interchangeably.) the terms peer, device, and peer device interchangeably.)
server The entity that terminates the EAP authentication method with server
The entity that terminates the EAP authentication method with
the peer. In the case where no backend authentication server the peer. In the case where no backend authentication server
is used, the EAP server is part of the authenticator. In the is used, the EAP server is part of the authenticator. In the
case where the authenticator operates in pass-through mode, the case where the authenticator operates in pass-through mode, the
EAP server is located on the backend authentication server. EAP server is located on the backend authentication server.
3. EAP-NOOB protocol 3. EAP-NOOB Method
This section defines the EAP-NOOB protocol. The protocol is a This section defines the EAP-NOOB method. The protocol is a
generalized version of the original idea presented by Sethi et al. generalized version of the original idea presented by Sethi et al.
[Sethi14]. [Sethi14].
3.1. Protocol overview 3.1. Protocol Overview
One EAP-NOOB protocol execution spans two or more EAP conversations, One EAP-NOOB method execution spans two or more EAP conversations,
called Exchanges in this specification. Each Exchange consists of called Exchanges in this specification. Each Exchange consists of
several EAP request-response pairs. At least two separate EAP several EAP request-response pairs. At least two separate EAP
conversations are needed to give the human user time to deliver the conversations are needed to give the human user time to deliver the
OOB message between them. OOB message between them.
The overall protocol starts with the Initial Exchange, which The overall protocol starts with the Initial Exchange, which
comprises four EAP request-response pairs. In the Initial Exchange, comprises four EAP request-response pairs. In the Initial Exchange,
the server allocates an identifier to the peer, and the server and the server allocates an identifier to the peer, and the server and
peer negotiate the protocol version and cryptosuite (i.e., peer negotiate the protocol version and cryptosuite (i.e.,
cryptographic algorithm suite), exchange nonces and perform an cryptographic algorithm suite), exchange nonces, and perform an
Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key exchange. The Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key exchange. The
user-assisted OOB Step then takes place. This step requires only one user-assisted OOB Step then takes place. This step requires only one
out-of-band message either from the peer to the server or from the out-of-band message, either from the peer to the server or from the
server to the peer. While waiting for the OOB Step action, the peer server to the peer. While waiting for the OOB Step action, the peer
MAY probe the server by reconnecting to it with EAP-NOOB. If the OOB MAY probe the server by reconnecting to it with EAP-NOOB. If the OOB
Step has already taken place, the probe leads to the Completion Step has already taken place, the probe leads to the Completion
Exchange, which completes the mutual authentication and key Exchange, which completes the mutual authentication and key
confirmation. On the other hand, if the OOB Step has not yet taken confirmation. On the other hand, if the OOB Step has not yet taken
place, the probe leads to the Waiting Exchange, and the peer will place, the probe leads to the Waiting Exchange, and the peer will
perform another probe after a server-defined minimum waiting time. perform another probe after a server-defined minimum waiting time.
The Initial Exchange and Waiting Exchange always end in EAP-Failure, The Initial Exchange and Waiting Exchange always end in EAP-Failure,
while the Completion Exchange may result in EAP-Success. Once the while the Completion Exchange may result in EAP-Success. Once the
peer and server have performed a successful Completion Exchange, both peer and server have performed a successful Completion Exchange, both
skipping to change at page 6, line 44 skipping to change at line 275
| Failure Exchange | Failure Exchange
| | | | | |
| v | | v |
| .------------------. | .------------------.
| | | | | |
'--| Reconnecting (3) | '--| Reconnecting (3) |
| (persistent) | | (persistent) |
| | | |
'------------------' '------------------'
Figure 1: EAP-NOOB server-peer association state machine Figure 1: EAP-NOOB Server-Peer Association State Machine
Figure 1 shows the association state machine, which is the same for Figure 1 shows the association state machine, which is the same for
the server and for the peer. (For readability, only the main state the server and for the peer. (For readability, only the main state
transitions are shown. The complete table of transitions can be transitions are shown. The complete table of transitions can be
found in Appendix A.) When the peer initiates the EAP-NOOB method, found in Appendix A.) When the peer initiates the EAP-NOOB method,
the server chooses the ensuing message exchange based on the the server chooses the ensuing message exchange based on the
combination of the server and peer states. The EAP server and peer combination of the server and peer states. The EAP server and peer
are initially in the Unregistered state, in which no state are initially in the Unregistered (0) state, in which no state
information needs to be stored. Before a successful Completion information needs to be stored. Before a successful Completion
Exchange, the server-peer association state is ephemeral in both the Exchange, the server-peer association state is ephemeral in both the
server and peer (ephemeral states 0..2), and a timeout or error may server and peer (ephemeral states 0..2), and a timeout or error may
cause one or both endpoints to go back to the Unregistered state so cause one or both endpoints to go back to the Unregistered (0) state
that the Initial Exchange is repeated. After the Completion Exchange so that the Initial Exchange is repeated. After the Completion
has resulted in EAP-Success, the association state becomes persistent Exchange has resulted in EAP-Success, the association state becomes
(persistent states 3..4). Only user reset or memory failure can persistent (persistent states 3..4). Only user reset or memory
cause the return of the server or the peer from the persistent states failure can cause the return of the server or the peer from the
to the ephemeral states and to the Initial Exchange. persistent states to the ephemeral states and to the Initial
Exchange.
The server MUST NOT repeat a successful OOB Step with the same peer The server MUST NOT repeat a successful OOB Step with the same peer
except if the association with the peer is explicitly reset by the except if the association with the peer is explicitly reset by the
user or lost due to failure of the persistent storage in the server. user or lost due to failure of the persistent storage in the server.
More specifically, once the association has entered the Registered More specifically, once the association has entered the Registered
state, the server MUST NOT delete the association or go back to the (4) state, the server MUST NOT delete the association or go back to
ephemeral states 0..2 without explicit user approval. Similarly, the the ephemeral states 0..2 without explicit user approval. Similarly,
peer MUST NOT repeat the OOB Step unless the user explicitly deletes the peer MUST NOT repeat the OOB Step unless the user explicitly
from the peer the association with the server or resets the peer to deletes the association with the server from the peer or resets the
the Unregistered state. The server and peer MAY implement user reset peer to the Unregistered (0) state. The server and peer MAY
of the association by deleting the state data from that endpoint. If implement user reset of the association by deleting the state data
an endpoint continues to store data about the association after the from that endpoint. If an endpoint continues to store data about the
user reset, its behavior MUST be equivalent to having deleted the association after the user reset, its behavior MUST be equivalent to
association data. having deleted the association data.
It can happen that the peer accidentally or through user reset loses It can happen that the peer accidentally (or through user reset)
its persistent state and reconnects to the server without a loses its persistent state and reconnects to the server without a
previously allocated peer identifier. In that case, the server MUST previously allocated peer identifier. In that case, the server MUST
treat the peer as a new peer. The server MAY use auxiliary treat the peer as a new peer. The server MAY use auxiliary
information, such as the PeerInfo field received in the Initial information, such as the PeerInfo field received in the Initial
Exchange, to detect multiple associations with the same peer. Exchange, to detect multiple associations with the same peer.
However, it MUST NOT delete or merge redundant associations without However, it MUST NOT delete or merge redundant associations without
user or application approval because EAP-NOOB internally has no user or application approval because EAP-NOOB internally has no
secure way of verifying that the two peers are the same physical secure way of verifying that the two peers are the same physical
device. Similarly, the server might lose the association state device. Similarly, the server might lose the association state
because of a memory failure or user reset. In that case, the only because of a memory failure or user reset. In that case, the only
way to recover is that the user also resets the peer. way to recover is that the user also resets the peer.
A special feature of the EAP-NOOB method is that the server is not A special feature of the EAP-NOOB method is that the server is not
assumed to have any a-priori knowledge of the peer. Therefore, the assumed to have any a priori knowledge of the peer. Therefore, the
peer initially uses the generic identity string "noob@eap-noob.arpa" peer initially uses the generic identity string "noob@eap-noob.arpa"
as its network access identifier (NAI). The server then allocates a as its Network Access Identifier (NAI). The server then allocates a
server-specific identifier to the peer. The generic NAI serves two server-specific identifier to the peer. The generic NAI serves two
purposes: firstly, it tells the server that the peer supports and purposes: firstly, it tells the server that the peer supports and
expects the EAP-NOOB method and, secondly, it allows routing of the expects the EAP-NOOB method; secondly, it allows routing of the EAP-
EAP-NOOB sessions to a specific authentication server in an NOOB sessions to a specific authentication server in an
Authentication, Authorization and Accounting (AAA) architecture. Authentication, Authorization, and Accounting (AAA) architecture.
EAP-NOOB is an unusual EAP method in that the peer has to have EAP-NOOB is an unusual EAP method in that the peer has to have
multiple EAP conversations with the server before it can receive EAP- multiple EAP conversations with the server before it can receive EAP-
Success. The reason is that, while EAP allows delays between the Success. The reason is that, while EAP allows delays between the
request-response pairs, e.g., for repeated password entry, the user request-response pairs, e.g., for repeated password entry, the user
delays in OOB authentication can be much longer than in password delays in OOB authentication can be much longer than in password
trials. Moreover, EAP-NOOB supports peers with no input capability trials. Moreover, EAP-NOOB supports peers with no input capability
in the user interface (e.g., LED light bulbs). Since users cannot in the user interface (e.g., LED light bulbs). Since users cannot
initiate the protocol in these devices, the devices have to perform initiate the protocol in these devices, the devices have to perform
the Initial Exchange opportunistically and hope for the OOB Step to the Initial Exchange opportunistically and hope for the OOB Step to
take place within a timeout period (NoobTimeout), which is why the take place within a timeout period (NoobTimeout), which is why the
timeout needs to be several minutes rather than seconds. To support timeout needs to be several minutes rather than seconds. To support
such high-latency OOB channels, the peer and server perform the such high-latency OOB channels, the peer and server perform the
Initial Exchange in one EAP conversation, then allow time for the OOB Initial Exchange in one EAP conversation, then allow time for the OOB
message to be delivered, and later perform the Waiting and Completion message to be delivered, and later perform the Waiting Exchange and
Exchanges in different EAP conversations. Completion Exchange in different EAP conversations.
3.2. Protocol messages and sequences 3.2. Protocol Messages and Sequences
This section defines the EAP-NOOB exchanges, which correspond to EAP This section defines the EAP-NOOB exchanges, which correspond to EAP
conversations. The exchanges start with a common handshake, which conversations. The exchanges start with a common handshake, which
determines the type of the following exchange. The common handshake determines the type of the following exchange. The common handshake
messages and the subsequent messages for each exchange type are messages and the subsequent messages for each exchange type are
listed in the diagrams below. The diagrams also specify the data listed in the diagrams below. The diagrams also specify the data
fields present in each message. Each exchange comprises multiple EAP fields present in each message. Each exchange comprises multiple EAP
request-response pairs and ends in either EAP-Failure, indicating request-response pairs and ends in either EAP-Failure, indicating
that authentication is not (yet) successful, or in EAP-Success. that authentication is not (yet) successful, or in EAP-Success.
3.2.1. Common handshake in all EAP-NOOB exchanges 3.2.1. Common Handshake in All EAP-NOOB Exchanges
All EAP-NOOB exchanges start with common handshake messages. The All EAP-NOOB exchanges start with common handshake messages. The
handshake begins with the identity request and response that are handshake begins with the identity request and response that are
common to all EAP methods. Their purpose is to enable the AAA common to all EAP methods. Their purpose is to enable the AAA
architecture to route the EAP conversation to the EAP server and to architecture to route the EAP conversation to the EAP server and to
enable the EAP server to select the EAP method. The handshake then enable the EAP server to select the EAP method. The handshake then
continues with one EAP-NOOB request-response pair in which the server continues with one EAP-NOOB request-response pair in which the server
discovers the peer identifier used in EAP-NOOB and the peer state. discovers the peer identifier used in EAP-NOOB and the peer state.
In more detail, each EAP-NOOB exchange begins with the authenticator In more detail, each EAP-NOOB exchange begins with the authenticator
sending an EAP-Request/Identity packet to the peer. From this point sending an EAP-Request/Identity packet to the peer. From this point
on, the EAP conversation occurs between the server and the peer, and on, the EAP conversation occurs between the server and the peer, and
the authenticator acts as a pass-through device. The peer responds the authenticator acts as a pass-through device. The peer responds
to the authenticator with an EAP-Response/Identity packet, which to the authenticator with an EAP-Response/Identity packet, which
contains the network access identifier (NAI). The authenticator, contains the Network Access Identifier (NAI). The authenticator,
acting as a pass-through device, forwards this response and the acting as a pass-through device, forwards this response and the
following EAP conversation between the peer and the AAA architecture. following EAP conversation between the peer and the AAA architecture.
The AAA architecture routes the conversation to a specific AAA server The AAA architecture routes the conversation to a specific AAA server
(called "EAP server" or simply "server" in this specification) based (called "EAP server" or simply "server" in this specification) based
on the realm part of the NAI. The server selects the EAP-NOOB method on the realm part of the NAI. The server selects the EAP-NOOB method
based on the user part of the NAI, as defined in Section 3.3.1. based on the user part of the NAI, as defined in Section 3.3.1.
After receiving the EAP-Response/Identity message, the server sends After receiving the EAP-Response/Identity message, the server sends
the first EAP-NOOB request (Type=1) to the peer, which responds with the first EAP-NOOB request (Type=1) to the peer, which responds with
the peer identifier (PeerId) and state (PeerState) in the range 0..3. the peer identifier (PeerId) and state (PeerState) in the range 0..3.
However, the peer SHOULD omit the PeerId from the response (Type=1) However, the peer SHOULD omit the PeerId from the response (Type=1)
when PeerState=0. The server then chooses the EAP-NOOB exchange, when PeerState=0. The server then chooses the EAP-NOOB exchange,
i.e., the ensuing message sequence, as explained below. The peer i.e., the ensuing message sequence, as explained below. The peer
recognizes the exchange based on the message type field (Type) of the recognizes the exchange based on the message type field (Type) of the
next EAP-NOOB request received from the server. next EAP-NOOB request received from the server.
The server MUST determine the exchange type based on the combination The server MUST determine the exchange type based on the combination
of the peer and server states as follows (also summarized in of the peer and server states as follows (also summarized in
Figure 11). If either the peer or server is in the Unregistered (0) Table 14). If either the peer or server is in the Unregistered (0)
state and the other is in one of the ephemeral states (0..2), the state and the other is in one of the ephemeral states (0..2), the
server chooses the Initial Exchange. If one of the peer or server is server chooses the Initial Exchange. If either the peer or server is
in the OOB Received (2) state and the other is either in the Waiting in the OOB Received (2) state and the other is either in the Waiting
for OOB (1) or OOB Received (2) state, the OOB Step has taken place for OOB (1) or OOB Received (2) state, the OOB Step has taken place
and the server chooses the Completion Exchange. If both the server 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 and peer are in the Waiting for OOB (1) state, the server chooses the
Waiting Exchange. If the peer is in the Reconnecting (3) state and Waiting Exchange. If the peer is in the Reconnecting (3) state and
the server is in the Registered (4) or Reconnecting (3) state, the the server is in the Registered (4) or Reconnecting (3) state, the
server chooses the Reconnect Exchange. All other state combinations server chooses the Reconnect Exchange. All other state combinations
are error situations where user action is required, and the server are error situations where user action is required, and the server
SHOULD indicate such errors to the peer with the error code 2002 (see SHOULD indicate such errors to the peer with the error code 2002 (see
Section 3.6.3). Note also that the peer MUST NOT initiate EAP-NOOB Section 3.6.3). Note also that the peer MUST NOT initiate EAP-NOOB
skipping to change at page 10, line 23 skipping to change at line 426
| | | |
|<----------- EAP-Request/EAP-NOOB ----------------| |<----------- EAP-Request/EAP-NOOB ----------------|
| (Type=1) | | (Type=1) |
| | | |
| | | |
|------------ EAP-Response/EAP-NOOB -------------->| |------------ EAP-Response/EAP-NOOB -------------->|
| (Type=1,[PeerId],PeerState=1) | | (Type=1,[PeerId],PeerState=1) |
| | | |
| continuing with exchange-specific messages... | | continuing with exchange-specific messages... |
Figure 2: Common handshake in all EAP-NOOB exchanges Figure 2: Common Handshake in All EAP-NOOB Exchanges
3.2.2. Initial Exchange 3.2.2. Initial Exchange
The Initial Exchange comprises the common handshake and two further The Initial Exchange comprises the common handshake and two further
EAP-NOOB request-response pairs, one for version, cryptosuite and EAP-NOOB request-response pairs: one for version, cryptosuite, and
parameter negotiation and the other for the ECDHE key exchange. The parameter negotiation and the other for the ECDHE key exchange. The
first EAP-NOOB request (Type=2) from the server contains a newly first EAP-NOOB request (Type=2) from the server contains a newly
allocated PeerId for the peer and an optional NewNAI for assigning a allocated PeerId for the peer and an optional NewNAI for assigning a
new NAI to the peer. The server allocates a new PeerId in the new NAI to the peer. The server allocates a new PeerId in the
Initial Exchange regardless of any old PeerId received in the Initial Exchange regardless of any old PeerId received in the
previous response (Type=1). The server also sends in the request a previous response (Type=1). The server also sends in the request a
list of the protocol versions (Vers) and cryptosuites (Cryptosuites) list of the protocol versions (Vers) and cryptosuites (Cryptosuites)
it supports, an indicator of the OOB channel directions it supports it supports, an indicator of the OOB channel directions it supports
(Dirs), and a ServerInfo object. The peer chooses one of the (Dirs), and a ServerInfo object. The peer chooses one of the
versions and cryptosuites. The peer sends a response (Type=2) with versions and cryptosuites. The peer sends a response (Type=2) with
the selected protocol version (Verp), the received PeerId, the the selected protocol version (Verp), the received PeerId, the
selected cryptosuite (Cryptosuitep), an indicator of the OOB channel selected cryptosuite (Cryptosuitep), an indicator of the OOB channel
direction(s) selected by the peer (Dirp), and a PeerInfo object. In direction(s) selected by the peer (Dirp), and a PeerInfo object. In
the second EAP-NOOB request and response (Type=3), the server and the second EAP-NOOB request and response (Type=3), the server and
peer exchange the public components of their ECDHE keys and nonces peer exchange the public components of their ECDHE keys and nonces
(PKs,Ns,PKp,Np). The ECDHE keys MUST be based on the negotiated (PKs, Ns, PKp, and Np). The ECDHE keys MUST be based on the
cryptosuite, i.e., Cryptosuitep. The Initial Exchange always ends negotiated cryptosuite, i.e., Cryptosuitep. The Initial Exchange
with EAP-Failure from the server because the authentication cannot always ends with EAP-Failure from the server because the
yet be completed. authentication cannot yet be completed.
EAP Peer EAP Server EAP Peer EAP Server
| ...continuing from common handshake | | ...continuing from common handshake |
| | | |
|<----------- EAP-Request/EAP-NOOB ----------------| |<----------- EAP-Request/EAP-NOOB ----------------|
| (Type=2,Vers,PeerId,[NewNAI], | | (Type=2,Vers,PeerId,[NewNAI], |
| Cryptosuites,Dirs,ServerInfo) | | Cryptosuites,Dirs,ServerInfo) |
| | | |
| | | |
|------------ EAP-Response/EAP-NOOB -------------->| |------------ EAP-Response/EAP-NOOB -------------->|
skipping to change at page 11, line 29 skipping to change at line 476
| (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 -------------------------|
| | | |
Figure 3: Initial Exchange Figure 3: Initial Exchange
At the conclusion of the Initial Exchange, both the server and the At the conclusion of the Initial Exchange, both the server and the
peer move to the Waiting for OOB (1) state. peer move to the Waiting for OOB (1) state.
3.2.3. OOB Step 3.2.3. OOB Step
The OOB Step, labeled as OOB Output and OOB Input in Figure 1, takes The OOB Step, labeled as OOB Output and OOB Input in Figure 1, takes
place after the Initial Exchange. Depending on the negotiated OOB place after the Initial Exchange. Depending on the negotiated OOB
channel direction, the peer or the server outputs the OOB message as channel direction, the peer or the server outputs the OOB message as
shown in Figure 4 or Figure 5, respectively. The data fields are the shown in Figures 4 or 5, respectively. The data fields are the
PeerId, the secret nonce Noob, and the cryptographic fingerprint PeerId, the secret nonce Noob, and the cryptographic fingerprint
Hoob. The contents of the data fields are defined in Section 3.3.2. Hoob. The contents of the data fields are defined in Section 3.3.2.
The OOB message is delivered to the other endpoint via a user- The OOB message is delivered to the other endpoint via a user-
assisted OOB channel. assisted OOB channel.
For brevity, we will use the terms OOB sender and OOB receiver in For brevity, we will use the terms OOB sender and OOB receiver in
addition to the already familiar EAP server and EAP peer. If the OOB addition to the already familiar EAP server and EAP peer. If the OOB
message is sent in the server-to-peer direction, the OOB sender is message is sent in the server-to-peer direction, the OOB sender is
the server and the OOB receiver is the peer. On the other hand, if the server and the OOB receiver is the peer. On the other hand, if
the OOB message is sent in the peer-to-server direction, the OOB the OOB message is sent in the peer-to-server direction, the OOB
sender is the peer and the OOB receiver is the server. sender is the peer and the OOB receiver is the server.
EAP Peer EAP Server EAP Peer EAP Server
| | | |
|=================OOB=============================>| |=================OOB=============================>|
| (PeerId,Noob,Hoob) | | (PeerId,Noob,Hoob) |
| | | |
Figure 4: OOB Step, from peer to EAP server Figure 4: OOB Step, from Peer to EAP Server
EAP Peer EAP Server EAP Peer EAP Server
| | | |
|<================OOB==============================| |<================OOB==============================|
| (PeerId,Noob,Hoob) | | (PeerId,Noob,Hoob) |
| | | |
Figure 5: OOB Step, from EAP server to peer Figure 5: OOB Step, from EAP Server to Peer
The OOB receiver MUST compare the received value of the fingerprint The OOB receiver MUST compare the received value of the fingerprint
Hoob (see Section 3.3.2) with a value that it computed locally for Hoob (see Section 3.3.2) with a value that it computed locally for
the PeerID received. This integrity check ensures that the endpoints the PeerID received. This integrity check ensures that the endpoints
agree on contents of the Initial Exchange. If the values are equal, agree on contents of the Initial Exchange. If the values are equal,
the receiver moves to the OOB Received (2) state. Otherwise, the the receiver moves to the OOB Received (2) state. Otherwise, the
receiver MUST reject the OOB message. For usability reasons, the OOB receiver MUST reject the OOB message. For usability reasons, the OOB
receiver SHOULD indicate the acceptance or rejection of the OOB receiver SHOULD indicate the acceptance or rejection of the OOB
message to the user. The receiver SHOULD reject invalid OOB messages message to the user. The receiver SHOULD reject invalid OOB messages
without changing its state in the association state machine, until an without changing its state in the association state machine until an
application-specific number of invalid messages (OobRetries) has been application-specific number of invalid messages (OobRetries) has been
reached, after which the receiver SHOULD consider it an error and go reached; after which, the receiver SHOULD consider it an error and go
back to the Unregistered (0) state. back to the Unregistered (0) state.
The server or peer MAY send multiple OOB messages with different Noob The server or peer MAY send multiple OOB messages with different Noob
values while in the Waiting for OOB (1) state. The OOB sender SHOULD values while in the Waiting for OOB (1) state. The OOB sender SHOULD
remember the Noob values until they expire and accept any one of them remember the Noob values until they expire and accept any one of them
in the following Completion Exchange. The Noob values sent by the in the following Completion Exchange. The Noob values sent by the
server expire after an application-dependent timeout (NoobTimeout), server expire after an application-dependent timeout (NoobTimeout),
and the server MUST NOT accept Noob values older than that in the and the server MUST NOT accept Noob values older than that in the
Completion Exchange. The RECOMMENDED value for NoobTimeout is 3600 Completion Exchange. The RECOMMENDED value for NoobTimeout is 3600
seconds if there are no application-specific reasons for making it seconds if there are no application-specific reasons for making it
shorter or longer. The Noob values sent by the peer expire as shorter or longer. The Noob values sent by the peer expire, as
defined in Section 3.2.5. defined in Section 3.2.5.
The OOB receiver does not accept further OOB messages after it has The OOB receiver does not accept further OOB messages after it has
accepted one and moved to the OOB Received (2) state. However, the accepted one and moved to the OOB Received (2) state. However, the
receiver MAY buffer redundant OOB messages in case an OOB message receiver MAY buffer redundant OOB messages in case an OOB message
expiry or similar error detected in the Completion Exchange causes it expiry or similar error detected in the Completion Exchange causes it
to return to the Waiting for OOB (1) state. It is RECOMMENDED that to return to the Waiting for OOB (1) state. It is RECOMMENDED that
the OOB receiver notifies the user about redundant OOB messages, but the OOB receiver notifies the user about redundant OOB messages, but
it MAY instead discard them silently. it MAY instead discard them silently.
The sender will typically generate a new Noob, and therefore a new The sender will typically generate a new Noob, and therefore a new
OOB message, at constant time intervals (NoobInterval). The OOB message, at constant time intervals (NoobInterval). The
RECOMMENDED interval is NoobInterval = NoobTimeout / 2, in which case RECOMMENDED interval is
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 NoobInterval = NoobTimeout / 2
may also be based on user interaction or on implementation
considerations. 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.
Even though not recommended (see Section 3.3), this specification Even though not recommended (see Section 3.3), this specification
allows both directions to be negotiated (Dirp=3) for the OOB channel. allows both directions to be negotiated (Dirp=3) for the OOB channel.
In that case, both sides SHOULD output the OOB message, and it is up In that case, both sides SHOULD output the OOB message, and it is up
to the user to deliver at least one of them. to the user to deliver at least one of them.
The details of the OOB channel implementation including the message The details of the OOB channel implementation including the message
encoding are defined by the application. Appendix D gives an example encoding are defined by the application. Appendix D gives an example
of how the OOB message can be encoded as a URL that may be embedded of how the OOB message can be encoded as a URL that may be embedded
in a dynamic QR code or NFC tag. in a dynamic QR code or NFC (Near Field Communication) tag.
3.2.4. Completion Exchange 3.2.4. Completion Exchange
After the Initial Exchange, if the OOB channel directions selected by After the Initial Exchange, if the OOB channel directions selected by
the peer include the peer-to-server direction, the peer SHOULD the peer include the peer-to-server direction, the peer SHOULD
initiate the EAP-NOOB method again after an applications-specific initiate the EAP-NOOB method again after an applications-specific
waiting time in order to probe for completion of the OOB Step. If waiting time in order to probe for completion of the OOB Step. If
the OOB channel directions selected by the peer include the server- the OOB channel directions selected by the peer include the server-
to-peer direction and the peer receives the OOB message, it SHOULD to-peer direction and the peer receives the OOB message, it SHOULD
initiate the EAP-NOOB method immediately. Depending on the initiate the EAP-NOOB method immediately. Depending on the
skipping to change at page 14, line 7 skipping to change at line 597
OOB message received by the server. On the other hand, if the peer OOB message received by the server. On the other hand, if the peer
is in the OOB Received (2) state, the direction of the OOB message is is in the OOB Received (2) state, the direction of the OOB message is
from server to peer. In this case, two request-response pairs from server to peer. In this case, two request-response pairs
(Type=5 and Type=6) are needed. The purpose of the first request- (Type=5 and Type=6) are needed. The purpose of the first request-
response pair (Type=5) is that it enables the server to discover response pair (Type=5) is that it enables the server to discover
NoobId, which identifies the exact OOB message received by the peer. NoobId, which identifies the exact OOB message received by the peer.
The server returns the same NoobId to the peer in the latter request. The server returns the same NoobId to the peer in the latter request.
In the last request-response pair (Type=6) of the Completion In the last request-response pair (Type=6) of the Completion
Exchange, the server and peer exchange message authentication codes. Exchange, the server and peer exchange message authentication codes.
Both sides MUST compute the keys Kms and Kmp as defined in Both sides MUST compute the keys Kms and Kmp, as defined in
Section 3.5 and the message authentication codes MACs and MACp as Section 3.5, and the message authentication codes MACs and MACp, as
defined in Section 3.3.2. Both sides MUST compare the received defined in Section 3.3.2. Both sides MUST compare the received
message authentication code with a locally computed value. If the message authentication code with a locally computed value. If the
peer finds that it has received the correct value of MACs and the peer finds that it has received the correct value of MACs and the
server finds that it has received the correct value of MACp, the server finds that it has received the correct value of MACp, the
Completion Exchange ends in EAP-Success. Otherwise, the endpoint Completion Exchange ends in EAP-Success. Otherwise, the endpoint
where the comparison fails indicates this with an error message where the comparison fails indicates this with an error message
(error code 4001, see Section 3.6.1) and the Completion Exchange ends (error code 4001, see Section 3.6.5), and the Completion Exchange
in EAP-Failure. ends in EAP-Failure.
After successful Completion Exchange, both the server and the peer After the successful Completion Exchange, both the server and the
move to the Registered (4) state. They also derive the output keying peer move to the Registered (4) state. They also derive the output
material and store the persistent EAP-NOOB association state as keying material and store the persistent EAP-NOOB association state,
defined in Section 3.4 and Section 3.5. as defined in Sections 3.4 and 3.5.
It is possible that the OOB message expires before it is received. It is possible that the OOB message expires before it is received.
In that case, the sender of the OOB message no longer recognizes the In that case, the sender of the OOB message no longer recognizes the
NoobId that it receives in the Completion Exchange. Another reason NoobId that it receives in the Completion Exchange. Another reason
why the OOB sender might not recognize the NoobId is if the received why the OOB sender might not recognize the NoobId is if the received
OOB message was spoofed and contained an attacker-generated Noob OOB message was spoofed and contained an attacker-generated Noob
value. The recipient of an unrecognized NoobId indicates this with value. The recipient of an unrecognized NoobId indicates this with
an error message (error code 2003, see Section 3.6.1), and the an error message (error code 2003, see Section 3.6.1), and the
Completion Exchange ends in EAP-Failure. The recipient of the error Completion Exchange ends in EAP-Failure. The recipient of the error
message 2003 moves back to the Waiting for OOB (1) state. This state message 2003 moves back to the Waiting for OOB (1) state. This state
transition is called OOB Reject in Figure 1 (even though it really is transition is called OOB Reject in Figure 1 (even though it really is
a specific type of failed Completion Exchange). The sender of the a specific type of failed Completion Exchange). On the other hand,
error message, on the other hand, stays in its previous state. the sender of the error message stays in its previous state.
Although it is not expected to occur in practice, poor user interface Although it is not expected to occur in practice, poor user interface
design could lead to two OOB messages delivered simultaneously, one design could lead to two OOB messages delivered simultaneously, one
from the peer to the server and the other from the server to the from the peer to the server and the other from the server to the
peer. The server detects this event in the beginning of the peer. The server detects this event in the beginning of the
Completion Exchange by observing that both the server and peer are in Completion Exchange by observing that both the server and peer are in
the OOB Received state (2). In that case, as a tiebreaker, the the OOB Received (2) state. In that case, as a tiebreaker, the
server MUST behave as if only the server-to-peer message had been server MUST behave as if only the server-to-peer message had been
delivered. delivered.
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) |
| | | |
| | | |
skipping to change at page 16, line 6 skipping to change at line 684
(SleepTime) before initiating EAP again with the same server. The (SleepTime) before initiating EAP again with the same server. The
peer uses the latest SleepTime value that it has received in or after peer uses the latest SleepTime value that it has received in or after
the Initial Exchange. If the server has not sent any SleepTime the Initial Exchange. If the server has not sent any SleepTime
value, the peer MUST wait for an application-specified minimum time value, the peer MUST wait for an application-specified minimum time
(SleepTimeDefault). (SleepTimeDefault).
After the Waiting Exchange, the peer MUST discard (from its local After the Waiting Exchange, the peer MUST discard (from its local
ephemeral storage) Noob values that it has sent to the server in OOB ephemeral storage) Noob values that it has sent to the server in OOB
messages that are older than the application-defined timeout messages that are older than the application-defined timeout
NoobTimeout (see Section 3.2.3). The peer SHOULD discard such NoobTimeout (see Section 3.2.3). The peer SHOULD discard such
expired Noob values even if the probing failed, e.g., because of expired Noob values even if the probing failed because of, e.g.,
failure to connect to the EAP server or incorrect message failure to connect to the EAP server or an incorrect message
authentication code. The timeout of peer-generated Noob values is authentication code. The timeout of peer-generated Noob values is
defined like this in order to allow the peer to probe the server once defined like this in order to allow the peer to probe the server once
after it has waited for the server-specified SleepTime. after it has waited for the server-specified SleepTime.
If the server and peer have negotiated to use only the server-to-peer If the server and peer have negotiated to use only the server-to-peer
direction for the OOB channel (Dirp=2), the peer SHOULD nevertheless direction for the OOB channel (Dirp=2), the peer SHOULD nevertheless
probe the server. The purpose of this is to keep the server informed probe the server. The purpose of this is to keep the server informed
about the peers that are still waiting for OOB messages. The server about the peers that are still waiting for OOB messages. The server
MAY set SleepTime to a high number (3600) to prevent the peer from MAY set SleepTime to a high number (e.g., 3600) to prevent the peer
probing the server frequently. from probing the server frequently.
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 -------------------------|
| | | |
Figure 7: Waiting Exchange Figure 7: Waiting Exchange
3.3. Protocol data fields 3.3. Protocol Data Fields
This section defines the various identifiers and data fields used in This section defines the various identifiers and data fields used in
the EAP-NOOB protocol. the EAP-NOOB method.
3.3.1. Peer identifier and NAI 3.3.1. Peer Identifier and NAI
The server allocates a new peer identifier (PeerId) for the peer in The server allocates a new peer identifier (PeerId) for the peer in
the Initial Exchange. The peer identifier MUST follow the syntax of the Initial Exchange. The peer identifier MUST follow the syntax of
the utf8-username specified in [RFC7542]. The server MUST generate the utf8-username specified in [RFC7542]. The server MUST generate
the identifiers in such a way that they do not repeat and cannot be the identifiers in such a way that they do not repeat and cannot be
guessed by the peer or third parties before the server sends them to guessed by the peer or third parties before the server sends them to
the peer in the Initial Exchange. One way to generate the the peer in the Initial Exchange. One way to generate the
identifiers is to choose a random 16-byte identifier and to base64url identifiers is to choose a random 16-byte identifier and to base64url
encode it without padding [RFC4648] into a 22-character ASCII string. encode it without padding [RFC4648] into a 22-character ASCII string.
Another way to generate the identifiers is to choose a random Another way to generate the identifiers is to choose a random
22-character alphanumeric ASCII string. It is RECOMMENDED to not use 22-character alphanumeric ASCII string. It is RECOMMENDED to not use
identifiers longer than this because they result in longer OOB identifiers longer than this because they result in longer OOB
messages. messages.
The peer uses the allocated PeerId to identify itself to the server The peer uses the allocated PeerId to identify itself to the server
in the subsequent exchanges. The peer MUST copy the PeerId byte-by- in the subsequent exchanges. The peer MUST copy the PeerId byte by
byte from the message where it was allocated, and the server MUST byte from the message where it was allocated, and the server MUST
perform a byte-by-byte comparison between the received and the perform a byte-by-byte comparison between the received and the
previously allocated PeerID. The peer sets the PeerId value in previously allocated PeerID. The peer sets the PeerId value in
response type 1 as follows. As stated in Section 3.2.1, when the response type 1 as follows. As stated in Section 3.2.1, when the
peer is in the Unregistered (0) state, it SHOULD omit the PeerId from 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 MUST response type 1. When the peer is in one of the states 1..2, it MUST
use the PeerId that the server assigned to it in the latest Initial 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 Exchange. When the peer is in one of the persistent states 3..4, it
MUST use the PeerId from its persistent EAP-NOOB association. (The MUST use the PeerId from its persistent EAP-NOOB association. (The
PeerId is written to the association when the peer moves to the PeerId is written to the association when the peer moves to the
Registered (4) state after a Completion Exchange.) Registered (4) state after a Completion Exchange.)
The default NAI for the peer is "noob@eap-noob.arpa". The peer The default NAI for the peer is "noob@eap-noob.arpa". The peer
implementation MAY allow the user or application to configure a implementation MAY allow the user or application to configure a
different NAI, which overrides the default NAI. Furthermore, the different NAI, which overrides the default NAI. Furthermore, the
server MAY assign a new NAI to the peer in the Initial Exchange or server MAY assign a new NAI to the peer in the Initial Exchange or
Reconnect Exchange, in the NewNAI field of request types 2 and 7, to Reconnect Exchange in the NewNAI field of request types 2 and 7 to
override any previous NAI value. When the peer is in the override any previous NAI value. When the peer is in the
Unregistered (0) state, or when the peer is in one of the states 1..2 Unregistered (0) state, or when the peer is in one of the states 1..2
and the server did not send a NewNAI in the latest Initial Exchange, and the server did not send a NewNAI in the latest Initial Exchange,
the peer MUST use the configured NAI, or if it does not exist, the the peer MUST use the configured NAI or, if it does not exist, the
default NAI. When the peer is in one of the states 1..2 and 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 server sent a NewNAI in the latest Initial Exchange, the peer MUST
use this server-assigned NAI. When the peer moves to the Registered use this server-assigned NAI. When the peer moves to the Registered
(4) state after the Completion Exchange, it writes to the persistent (4) state after the Completion Exchange, it writes to the persistent
EAP-NOOB association the same NAI value that it used in the EAP-NOOB association the same NAI value that it used in the
Completion Exchange. When the peer is in the Reconnecting (3) or Completion Exchange. When the peer is in the Reconnecting (3) or
Registered (4) state, it MUST use the NAI from its persistent EAP- Registered (4) state, it MUST use the NAI from its persistent EAP-
NOOB association. When the server sends NewNAI in the Reconnect NOOB association. When the server sends NewNAI in the Reconnect
Exchange, the peer writes its value to the persistent EAP-NOOB Exchange, the peer writes its value to the persistent EAP-NOOB
association when it moves from the Reconnecting (3) state to the association when it moves from the Reconnecting (3) state to the
Registered (4) state. All the NAI values MUST follow the syntax Registered (4) state. All the NAI values MUST follow the syntax
specified in [RFC7542]. specified in [RFC7542].
The purpose of the server-assigned NAI is to enable more flexible The purpose of the server-assigned NAI is to enable more flexible
routing of the EAP sessions over the AAA infrastructure, including routing of the EAP sessions over the AAA infrastructure, including
roaming scenarios (see Appendix C). Moreover, some Authenticators or roaming scenarios (see Appendix C). Moreover, some authenticators or
AAA servers use the realm part of the assigned NAI to determine peer- AAA servers use the realm part of the assigned NAI to determine peer-
specific connection parameters, such as isolating the peer to a specific connection parameters, such as isolating the peer to a
specific VLAN. The user or application configured NAI, on the other specific VLAN. On the other hand, the user- or application-
hand, enables registration of new devices while roaming. It also configured NAI enables registration of new devices while roaming. It
enables manufacturers to set up their own AAA servers for also enables manufacturers to set up their own AAA servers for
bootstrapping of new peer devices. bootstrapping of new peer devices.
The peer's PeerId and server-assigned NAI are ephemeral until a The peer's PeerId and server-assigned NAI are ephemeral until a
successful Completion Exchange takes place. Thereafter, the values successful Completion Exchange takes place. Thereafter, the values
become parts of the persistent EAP-NOOB association, until the user become parts of the persistent EAP-NOOB association until the user
resets the peer and the server or until a new NAI is assigned in the resets the peer and server or until a new NAI is assigned in the
Reconnect Exchange. Reconnect Exchange.
3.3.2. Message data fields 3.3.2. Message Data Fields
Table 1 defines the data fields in the protocol messages. The in- Table 1 defines the data fields in the protocol messages. The in-
band messages are formatted as JSON objects [RFC8259] in UTF-8 band messages are formatted as JSON objects [RFC8259] in UTF-8
encoding. The JSON member names are in the left-hand column of the encoding. The JSON member names are in the left-hand column of the
table. table.
+------------------+------------------------------------------------+ +===============+=================================================+
| Data field | Description | | Data Field | Description |
+------------------+------------------------------------------------+ +===============+=================================================+
| Vers, Verp | EAP-NOOB protocol versions supported by the | | Vers, Verp | EAP-NOOB protocol versions supported by the EAP |
| | EAP server, and the protocol version chosen by | | | server and the protocol version chosen by the |
| | the peer. Vers is a JSON array of unsigned | | | peer. Vers is a JSON array of unsigned |
| | integers, and Verp is an unsigned integer. | | | integers, and Verp is an unsigned integer. |
| | Example values are "[1]" and "1", | | | Example values are "[1]" and "1", respectively. |
| | respectively. | +---------------+-------------------------------------------------+
| | | | PeerId | Peer identifier, as defined in Section 3.3.1. |
| PeerId | Peer identifier as defined in Section 3.3.1. | +---------------+-------------------------------------------------+
| | | | NAI, NewNAI | Peer NAI and server-assigned new peer NAI, as |
| NAI, NewNAI | Peer NAI and server-assigned new peer NAI as | | | defined in Section 3.3.1. |
| | defined in Section 3.3.1. | +---------------+-------------------------------------------------+
| | | | Type | EAP-NOOB message type. The type is an integer |
| Type | EAP-NOOB message type. The type is an integer | | | in the range 0..9. EAP-NOOB requests and the |
| | in the range 0..9. EAP-NOOB requests and the | | | corresponding responses share the same type |
| | corresponding responses share the same type | | | value. |
| | value. | +---------------+-------------------------------------------------+
| | | | PeerState | Peer state is an integer in the range 0..4 (see |
| PeerState | Peer state is an integer in the range 0..4 | | | Figure 1). However, only values 0..3 are ever |
| | (see Figure 1). However, only values 0..3 are | | | sent in the protocol messages. |
| | ever sent in the protocol messages. | +---------------+-------------------------------------------------+
| | | | PKs, PKp | The public components of the ECDHE keys of the |
| PKs, PKp | The public components of the ECDHE keys of the | | | server and peer. PKs and PKp are sent in the |
| | server and peer. PKs and PKp are sent in the | | | JSON Web Key (JWK) format [RFC7517]. The |
| | JSON Web Key (JWK) format [RFC7517]. The | | | detailed format of the JWK object is defined by |
| | detailed format of the JWK object is defined | | | the cryptosuite. |
| | by the cryptosuite. | +---------------+-------------------------------------------------+
| | | | Cryptosuites, | The identifiers of cryptosuites supported by |
| Cryptosuites, | The identifiers of cryptosuites supported by | | Cryptosuitep | the server and of the cryptosuite selected by |
| Cryptosuitep | the server and of the cryptosuite selected by | | | the peer. The server-supported cryptosuites in |
| | the peer. The server-supported cryptosuites in | | | Cryptosuites are formatted as a JSON array of |
| | Cryptosuites are formatted as a JSON array of | | | the identifier integers. The server MUST send |
| | the identifier integers. The server MUST send | | | a nonempty array with no repeating elements, |
| | a nonempty array with no repeating elements, | | | ordered by decreasing priority. The peer MUST |
| | ordered by decreasing priority. The peer MUST | | | respond with exactly one suite in the |
| | respond with exactly one suite in the | | | Cryptosuitep value, formatted as an identifier |
| | Cryptosuitep value, formatted as an identifier | | | integer. Mandatory-to-implement cryptosuites |
| | integer. Mandatory to implement cryptosuites | | | and the registration procedure for new |
| | and the registration procedure for new | | | cryptosuites are specified in Section 5.1. |
| | cryptosuites is specified in Section 5.1. | | | Example values are "[1]" and "1", respectively. |
| | Example values are "[1]" and "1", | +---------------+-------------------------------------------------+
| | respectively. | | Dirs, Dirp | An integer indicating the OOB channel |
| | | | | directions supported by the server and the |
| Dirs, Dirp | An integer indicating the OOB channel | | | directions selected by the peer. The possible |
| | directions supported by the server and the | | | values are 1=peer-to-server, 2=server-to-peer, |
| | directions selected by the peer. The possible | | | and 3=both directions. |
| | values are 1=peer-to-server, 2=server-to-peer, | +---------------+-------------------------------------------------+
| | 3=both directions. | | Dir | The actual direction of the OOB message |
| | | | | (1=peer-to-server, 2=server-to-peer). This |
| Dir | The actual direction of the OOB message | | | value is not sent over any communication |
| | (1=peer-to-server, 2=server-to-peer). This | | | channel, but it is included in the computation |
| | value is not sent over any communication | | | of the cryptographic fingerprint Hoob. |
| | channel, but it is included in the computation | +---------------+-------------------------------------------------+
| | of the cryptographic fingerprint Hoob. | | Ns, Np | 32-byte nonces for the Initial Exchange. |
| | | +---------------+-------------------------------------------------+
| Ns, Np | 32-byte nonces for the Initial Exchange. | | ServerInfo | This field contains information about the |
| | | | | server to be passed from the EAP method to the |
| ServerInfo | This field contains information about the | | | application layer in the peer. The information |
| | server to be passed from the EAP method to the | | | is specific to the application or to the OOB |
| | application layer in the peer. The information | | | channel, and it is encoded as a JSON object of |
| | is specific to the application or to the OOB | | | at most 500 bytes. It could include, for |
| | channel, and it is encoded as a JSON object of | | | example, the access-network name and server |
| | at most 500 bytes. It could include, for | | | name, a Uniform Resource Locator (URL) |
| | example, the access-network name and server | | | [RFC3986], or some other information that helps |
| | name or a Uniform Resource Locator (URL) | | | the user deliver the OOB message to the server |
| | [RFC3986] or some other information that helps | | | through the out-of-band channel. |
| | the user to deliver the OOB message to the | +---------------+-------------------------------------------------+
| | server through the out-of-band channel. | | PeerInfo | This field contains information about the peer |
| | | | | to be passed from the EAP method to the |
| PeerInfo | This field contains information about the peer | | | application layer in the server. The |
| | to be passed from the EAP method to the | | | information is specific to the application or |
| | application layer in the server. The | | | to the OOB channel, and it is encoded as a JSON |
| | information is specific to the application or | | | object of at most 500 bytes. It could include, |
| | to the OOB channel, and it is encoded as a | | | for example, the peer brand, model, and serial |
| | JSON object of at most 500 bytes. It could | | | number, which help the user distinguish between |
| | include, for example, the peer brand, model, | | | devices and deliver the OOB message to the |
| | and serial number, which help the user to | | | correct peer through the out-of-band channel. |
| | distinguish between devices and to deliver the | +---------------+-------------------------------------------------+
| | OOB message to the correct peer through the | | SleepTime | The number of seconds for which the peer MUST |
| | out-of-band channel. | | | NOT start a new execution of the EAP-NOOB |
| | | | | method with the authenticator, unless the peer |
| SleepTime | The number of seconds for which the peer MUST | | | receives the OOB message or the sending is |
| | NOT start a new execution of the EAP-NOOB | | | triggered by an application-specific user |
| | method with the authenticator, unless the peer | | | action. The server can use this field to limit |
| | receives the OOB message or the sending is | | | the rate at which peers probe it. SleepTime is |
| | triggered by an application-specific user | | | an unsigned integer in the range 0..3600. |
| | action. The server can use this field to limit | +---------------+-------------------------------------------------+
| | the rate at which peers probe it. SleepTime is | | Noob | 16-byte secret nonce sent through the OOB |
| | an unsigned integer in the range 0..3600. | | | channel and used for the session key |
| | | | | derivation. The endpoint that received the OOB |
| Noob | 16-byte secret nonce sent through the OOB | | | message uses this secret in the Completion |
| | channel and used for the session key | | | Exchange to authenticate the exchanged key to |
| | derivation. The endpoint that received the OOB | | | the endpoint that sent the OOB message. |
| | message uses this secret in the Completion | +---------------+-------------------------------------------------+
| | Exchange to authenticate the exchanged key to | | Hoob | 16-byte cryptographic fingerprint (i.e., hash |
| | the endpoint that sent the OOB message. | | | value) computed from all the parameters |
| | | | | exchanged in the Initial Exchange and in the |
| Hoob | 16-byte cryptographic fingerprint (i.e., hash | | | OOB message. Receiving this fingerprint over |
| | value) computed from all the parameters | | | the OOB channel guarantees the integrity of the |
| | exchanged in the Initial Exchange and in the | | | key exchange and parameter negotiation. Hence, |
| | OOB message. Receiving this fingerprint over | | | it authenticates the exchanged key to the |
| | the OOB channel guarantees the integrity of | | | endpoint that receives the OOB message. |
| | the key exchange and parameter negotiation. | +---------------+-------------------------------------------------+
| | Hence, it authenticates the exchanged key to | | NoobId | 16-byte identifier for the OOB message, |
| | the endpoint that receives the OOB message. | | | computed with a one-way function from the nonce |
| | | | | Noob in the message. |
| NoobId | 16-byte identifier for the OOB message, | +---------------+-------------------------------------------------+
| | computed with a one-way function from the | | MACs, MACp | Message authentication codes (HMAC) for mutual |
| | nonce Noob in the message. | | | authentication, key confirmation, and integrity |
| | | | | check on the exchanged information. The input |
| MACs, MACp | Message authentication codes (HMAC) for mutual | | | to the HMAC is defined below, and the key for |
| | authentication, key confirmation, and | | | the HMAC is defined in Section 3.5. |
| | integrity check on the exchanged information. | +---------------+-------------------------------------------------+
| | The input to the HMAC is defined below, and | | Ns2, Np2 | 32-byte nonces for the Reconnect Exchange. |
| | the key for the HMAC is defined in | +---------------+-------------------------------------------------+
| | Section 3.5. | | KeyingMode | Integer indicating the key derivation method. 0 |
| | | | | in the Completion Exchange, and 1..3 in the |
| Ns2, Np2 | 32-byte nonces for the Reconnect Exchange. | | | Reconnect Exchange. |
| | | +---------------+-------------------------------------------------+
| KeyingMode | Integer indicating the key derivation method. | | PKs2, PKp2 | The public components of the ECDHE keys of the |
| | 0 in the Completion Exchange, and 1..3 in the | | | server and peer for the Reconnect Exchange. |
| | Reconnect Exchange. | | | PKp2 and PKs2 are sent in the JSON Web Key |
| | | | | (JWK) format [RFC7517]. The detailed format of |
| PKs2, PKp2 | The public components of the ECDHE keys of the | | | the JWK object is defined by the cryptosuite. |
| | server and peer for the Reconnect Exchange. | +---------------+-------------------------------------------------+
| | PKp2 and PKs2 are sent in the JSON Web Key | | MACs2, MACp2 | Message authentication codes (HMAC) for mutual |
| | (JWK) format [RFC7517]. The detailed format of | | | authentication, key confirmation, and integrity |
| | the JWK object is defined by the cryptosuite. | | | check on the Reconnect Exchange. The input to |
| | | | | the HMAC is defined below, and the key for the |
| MACs2, MACp2 | Message authentication codes (HMAC) for mutual | | | HMAC is defined in Section 3.5. |
| | authentication, key confirmation, and | +---------------+-------------------------------------------------+
| | integrity check on the Reconnect Exchange. The | | ErrorCode | Integer indicating an error condition. Defined |
| | input to the HMAC is defined below, and the | | | in Section 5.3. |
| | key for the HMAC is defined in Section 3.5. | +---------------+-------------------------------------------------+
| | | | ErrorInfo | Textual error message for logging and debugging |
| ErrorCode | Integer indicating an error condition. Defined | | | purposes. A UTF-8 string of at most 500 bytes. |
| | in Section 5.3. | +---------------+-------------------------------------------------+
| | |
| ErrorInfo | Textual error message for logging and |
| | debugging purposes. A UTF-8 string of at most |
| | 500 bytes. |
| | |
+------------------+------------------------------------------------+
Table 1: Message data fields Table 1: Message Data Fields
It is RECOMMENDED for servers to support both OOB channel directions It is RECOMMENDED for servers to support both OOB channel directions
(Dirs=3) unless the type of the OOB channel limits them to one (Dirs=3) unless the type of the OOB channel limits them to one
direction (Dirs=1 or Dirs=2). On the other hand, it is RECOMMENDED direction (Dirs=1 or Dirs=2). On the other hand, it is RECOMMENDED
that the peer selects only one direction (Dirp=1 or Dirp=2) even when that the peer selects only one direction (Dirp=1 or Dirp=2) even when
both directions (Dirp=3) would be technically possible. The reason both directions (Dirp=3) would be technically possible. The reason
is that, if value 3 is negotiated, the user may be presented with two is that, if value 3 is negotiated, the user may be presented with two
OOB messages, one for each direction, even though only one of them OOB messages, one for each direction, even though only one of them
needs to be delivered. This can be confusing to the user. needs to be delivered. This can be confusing to the user.
Nevertheless, the EAP-NOOB protocol is designed to cope also with the Nevertheless, the EAP-NOOB protocol is designed to also cope with the
value 3, in which case it uses the first delivered OOB message. In value 3; in which case, it uses the first delivered OOB message. In
the unlikely case of simultaneously delivered OOB messages, the the unlikely case of simultaneously delivered OOB messages, the
protocol prioritizes the server-to-peer direction. protocol prioritizes the server-to-peer direction.
The nonces in the in-band messages (Ns, Np, Ns2, Np2) are 32-byte The nonces in the in-band messages (Ns, Np, Ns2, Np2) are 32-byte
fresh random byte strings, and the secret nonce Noob is a 16-byte fresh random byte strings, and the secret nonce Noob is a 16-byte
fresh random byte string. All the nonces are generated by the fresh random byte string. All the nonces are generated by the
endpoint that sends the message. endpoint that sends the message.
The fingerprint Hoob and the identifier NoobId are computed with the The fingerprint Hoob and the identifier NoobId are computed with the
cryptographic hash function H, which is specified in the negotiated cryptographic hash function H, which is specified in the negotiated
cryptosuite and truncated to the 16 leftmost bytes of the output. cryptosuite and truncated to the 16 leftmost bytes of the output.
The message authentication codes (MACs, MACp, MACs2, MACp2) are The message authentication codes (MACs, MACp, MACs2, MACp2) are
computed with the function HMAC, which is the HMAC message computed with the function HMAC, which is the hashed message
authentication code [RFC2104] based on the cryptographic hash authentication code [RFC2104] based on the cryptographic hash
function H and truncated to the 32 leftmost bytes of the output. function H and truncated to the 32 leftmost bytes of the output.
The inputs to the hash function for computing the fingerprint Hoob The inputs to the hash function for computing the fingerprint Hoob
and to the HMAC for computing MACs, MACp, MACs2 and MACp2 are JSON and to the HMAC for computing MACs, MACp, MACs2, and MACp2 are JSON
arrays containing a fixed number (17) of elements. The array arrays containing a fixed number (17) of elements. The array
elements MUST be copied to the array verbatim from the sent and elements MUST be copied to the array verbatim from the sent and
received in-band messages. When the element is a JSON object, its received in-band messages. When the element is a JSON object, its
members MUST NOT be reordered or re-encoded. Whitespace MUST NOT be members MUST NOT be reordered or reencoded. White space MUST NOT be
added anywhere in the JSON structure. Implementers should check that added anywhere in the JSON structure. Implementers should check that
their JSON library copies the elements as UTF-8 strings and does not their JSON library copies the elements as UTF-8 strings, does not
modify them in any way, and that it does not add whitespace to the modify them in any way, and does not add white space to the HMAC
HMAC input. input.
The inputs for computing the fingerprint and message authentication The inputs for computing the fingerprint and message authentication
codes are the following: codes are the following:
Hoob = H(Dir,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,Cryptos Hoob = H(Dir,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,
uitep,Dirp,NAI,PeerInfo,0,PKs,Ns,PKp,Np,Noob). Cryptosuitep,Dirp,NAI,PeerInfo,0,PKs,Ns,PKp,Np,Noob).
NoobId = H("NoobId",Noob). NoobId = H("NoobId",Noob).
MACs = HMAC(Kms; 2,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,C MACs = HMAC(Kms; 2,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,
ryptosuitep,Dirp,NAI,PeerInfo,0,PKs,Ns,PKp,Np,Noob). Cryptosuitep,Dirp,NAI,PeerInfo,0,PKs,Ns,PKp,Np,Noob).
MACp = HMAC(Kmp; 1,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,C MACp = HMAC(Kmp; 1,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,
ryptosuitep,Dirp,NAI,PeerInfo,0,PKs,Ns,PKp,Np,Noob). Cryptosuitep,Dirp,NAI,PeerInfo,0,PKs,Ns,PKp,Np,Noob).
MACs2 = HMAC(Kms2; 2,Vers,Verp,PeerId,Cryptosuites,"",[ServerInfo] MACs2 = HMAC(Kms2; 2,Vers,Verp,PeerId,Cryptosuites,"",[ServerInfo],
,Cryptosuitep,"",NAI,[PeerInfo],KeyingMode,[PKs2],Ns2,[PKp2],Np2," Cryptosuitep,"",NAI,[PeerInfo],KeyingMode,[PKs2],Ns2,[PKp2],Np2,"")
")
MACp2 = HMAC(Kmp2; 1,Vers,Verp,PeerId,Cryptosuites,"",[ServerInfo] MACp2 = HMAC(Kmp2; 1,Vers,Verp,PeerId,Cryptosuites,"",[ServerInfo],
,Cryptosuitep,"",NAI,[PeerInfo],KeyingMode,[PKs2],Ns2,[PKp2],Np2," Cryptosuitep,"",NAI,[PeerInfo],KeyingMode,[PKs2],Ns2,[PKp2],Np2,"")
")
The inputs denoted with "" above are not present, and the values in The inputs denoted with "" above are not present, and the values in
brackets [] are optional. Both kinds of missing input values are brackets [] are optional. Both kinds of missing input values are
represented by empty strings "" in the HMAC input (JSON array). The 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 NAI included in the inputs is the NAI value that will be in the
persistent EAP-NOOB association if the Completion Exchange or persistent EAP-NOOB association if the Completion Exchange or
Reconnect Exchange succeeds. In the Completion Exchange, the NAI is Reconnect Exchange succeeds. In the Completion Exchange, the NAI is
the NewNAI value assigned by the server in the preceding Initial 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 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 Initial Exchange. In the Reconnect Exchange, the NAI is the NewNAI
value assigned by the server in the same Reconnect Exchange, or if no value assigned by the server in the same Reconnect Exchange or, if no
NewNAI was sent, the unchanged NAI from the persistent EAP-NOOB NewNAI was sent, the unchanged NAI from the persistent EAP-NOOB
association. Each of the values in brackets for the computation of association. Each of the values in brackets for the computation of
Macs2 and Macp2 MUST be included if it was sent or received in the Macs2 and Macp2 MUST be included if it was sent or received in the
same Reconnect Exchange; otherwise, the value is replaced by an empty same Reconnect Exchange; otherwise, the value is replaced by an empty
string "". string "".
The parameter Dir indicates the direction in which the OOB message The parameter Dir indicates the direction in which the OOB message
containing the Noob value is being sent (1=peer-to-server, 2=server- containing the Noob value is being sent (1=peer-to-server, 2=server-
to-peer). This field is included in the Hoob input to prevent the to-peer). This field is included in the Hoob input to prevent the
user from accidentally delivering the OOB message back to its user from accidentally delivering the OOB message back to its
originator in the rare cases where both OOB directions have been originator in the rare cases where both OOB directions have been
negotiated. The keys (Kms, Kmp, Kms2, Kmp2) for the HMACs are negotiated. The keys (Kms, Kmp, Kms2, and Kmp2) for the HMACs are
defined in Section 3.5. defined in Section 3.5.
The nonces (Ns, Np, Ns2, Np2, Noob) and the hash value (NoobId) MUST The nonces (Ns, Np, Ns2, Np2, and Noob) and the hash value (NoobId)
be base64url encoded [RFC4648] when they are used as input to the MUST be base64url encoded [RFC4648] when they are used as input to
cryptographic functions H or HMAC. These values and the message the cryptographic functions H or HMAC. These values and the message
authentication codes (MACs, MACp, MACs2, MACp2) MUST also be authentication codes (MACs, MACp, MACs2, and MACp2) MUST also be
base64url encoded when they are sent as JSON strings in the in-band base64url encoded when they are sent as JSON strings in the in-band
messages. The values Noob and Hoob in the OOB channel MAY be messages. The values Noob and Hoob in the OOB channel MAY be
base64url encoded if that is appropriate for the application and the base64url encoded if that is appropriate for the application and the
OOB channel. All base64url encoding is done without padding. The OOB channel. All base64url encoding is done without padding. The
base64url encoded values will naturally consume more space than the base64url-encoded values will naturally consume more space than the
number of bytes specified above (22-character string for a 16-byte number of bytes specified above (e.g., a 22-character string for a
nonce and 43-character string for a 32-byte nonce or message 16-byte nonce and a 43-character string for a 32-byte nonce or
authentication code). In the key derivation in Section 3.5, on the message authentication code). In the key derivation in Section 3.5,
other hand, the unencoded nonces (raw bytes) are used as input to the on the other hand, the unencoded nonces (raw bytes) are used as input
key derivation function. to the key derivation function.
The ServerInfo and PeerInfo are JSON objects with UTF-8 encoding. The ServerInfo and PeerInfo are JSON objects with UTF-8 encoding.
The length of either encoded object as a byte array MUST NOT exceed The length of either encoded object as a byte array MUST NOT exceed
500 bytes. The format and semantics of these objects MUST be defined 500 bytes. The format and semantics of these objects MUST be defined
by the application that uses the EAP-NOOB method. by the application that uses the EAP-NOOB method.
3.4. Fast reconnect and rekeying 3.4. Fast Reconnect and Rekeying
EAP-NOOB implements Fast Reconnect ([RFC3748], section 7.2.1) that EAP-NOOB implements fast reconnect ([RFC3748], Section 7.2.1), which
avoids repeated use of the user-assisted OOB channel. avoids repeated use of the user-assisted OOB channel.
The rekeying and the Reconnect Exchange may be needed for several The rekeying and the Reconnect Exchange may be needed for several
reasons. New EAP output values Main Session Key (MSK) and Extended reasons. New EAP output values Main Session Key (MSK) and Extended
Main Session Key (EMSK) may be needed because of mobility or timeout Main Session Key (EMSK) may be needed because of mobility or timeout
of session keys. Software or hardware failure or user action may of session keys. Software or hardware failure or user action may
also cause the authenticator, EAP server or peer to lose its non- also cause the authenticator, EAP server, or peer to lose its
persistent state data. The failure would typically be detected by nonpersistent state data. The failure would typically be detected by
the peer or authenticator when session keys are no longer accepted by the peer or authenticator when session keys are no longer accepted by
the other endpoint. Changes in the supported cryptosuites in the EAP the other endpoint. Changes in the supported cryptosuites in the EAP
server or peer may also cause the need for a new key exchange. When server or peer may also cause the need for a new key exchange. When
the EAP server or peer detects any one of these events, it MUST the EAP server or peer detects any one of these events, it MUST
change from the Registered to Reconnecting state. These state change from the Registered (4) state to the Reconnecting (3) state.
transitions are labeled Mobility/Timeout/Failure in Figure 1. The These state transitions are labeled Mobility/Timeout/Failure in
EAP-NOOB method will then perform the Reconnect Exchange the next Figure 1. The EAP-NOOB method will then perform the Reconnect
time when EAP is triggered. Exchange the next time when EAP is triggered.
3.4.1. Persistent EAP-NOOB association 3.4.1. Persistent EAP-NOOB Association
To enable rekeying, the EAP server and peer store the session state To enable rekeying, the EAP server and peer store the session state
in persistent memory after a successful Completion Exchange. This in persistent memory after a successful Completion Exchange. This
state data, called "persistent EAP-NOOB association", MUST include at state data, called "persistent EAP-NOOB association", MUST include at
least the data fields shown in Table 2. They are used for least the data fields shown in Table 2. They are used for
identifying and authenticating the peer in the Reconnect Exchange. identifying and authenticating the peer in the Reconnect Exchange.
When a persistent EAP-NOOB association exists, the EAP server and When a persistent EAP-NOOB association exists, the EAP server and
peer are in the Registered state (4) or Reconnecting state (3), as peer are in the Registered (4) state or Reconnecting (3) state, as
shown in Figure 1. shown in Figure 1.
+------------------+----------------------------+-------------------+ +==================+==========================+===================+
| Data Field | Value | Type | | Data Field | Value | Type |
+------------------+----------------------------+-------------------+ +==================+==========================+===================+
| PeerId | Peer identifier allocated | UTF-8 string | | PeerId | Peer identifier | UTF-8 string |
| | by server | (typically 22 | | | allocated by server | (typically 22 |
| | | ASCII characters) | | | | ASCII characters) |
| | | | +------------------+--------------------------+-------------------+
| Verp | Negotiated protocol | integer | | Verp | Negotiated protocol | integer |
| | version | | | | version | |
| | | | +------------------+--------------------------+-------------------+
| Cryptosuitep | Negotiated cryptosuite | integer | | Cryptosuitep | Negotiated cryptosuite | integer |
| | | | +------------------+--------------------------+-------------------+
| CryptosuitepPrev | Previous cryptosuite | integer | | CryptosuitepPrev | Previous cryptosuite | integer |
| (at peer only) | | | | (at peer only) | | |
| | | | +------------------+--------------------------+-------------------+
| NAI | NAI assigned by server, | UTF-8 string | | NAI | NAI assigned by the | UTF-8 string |
| | configured by user, or the | | | | server or configured by | |
| | default NAI "noob@eap- | | | | the user or the default | |
| | noob.arpa" | | | | NAI "noob@eap-noob.arpa" | |
| Kz | Persistent key material | 32 bytes | +------------------+--------------------------+-------------------+
| | | | | Kz | Persistent key material | 32 bytes |
| KzPrev (at peer | Previous Kz value | 32 bytes | +------------------+--------------------------+-------------------+
| only) | | | | KzPrev (at peer | Previous Kz value | 32 bytes |
+------------------+----------------------------+-------------------+ | only) | | |
+------------------+--------------------------+-------------------+
Table 2: Persistent EAP-NOOB association Table 2: Persistent EAP-NOOB Association
3.4.2. Reconnect Exchange 3.4.2. Reconnect Exchange
The server chooses the Reconnect Exchange when both the peer and the The server chooses the Reconnect Exchange when both the peer and the
server are in a persistent state and fast reconnection is needed (see server are in a persistent state and fast reconnection is needed (see
Section 3.2.1 for details). Section 3.2.1 for details).
The Reconnect Exchange comprises the common handshake and three The Reconnect Exchange comprises the common handshake and three
further EAP-NOOB request-response pairs, one for cryptosuite and further EAP-NOOB request-response pairs: one for cryptosuite and
parameter negotiation, another for the nonce and ECDHE key exchange, parameter negotiation, another for the nonce and ECDHE key exchange,
and the last one for exchanging message authentication codes. In the and the last one for exchanging message authentication codes. In the
first request and response (Type=7) the server and peer negotiate a first request and response (Type=7), the server and peer negotiate a
protocol version and cryptosuite in the same way as in the Initial protocol version and cryptosuite in the same way as in the Initial
Exchange. The server SHOULD NOT offer and the peer MUST NOT accept Exchange. The server SHOULD NOT offer and the peer MUST NOT accept
protocol versions or cryptosuites that it knows to be weaker than the protocol versions or cryptosuites that it knows to be weaker than the
one currently in the Cryptosuitep field of the persistent EAP-NOOB one currently in the Cryptosuitep field of the persistent EAP-NOOB
association. The server SHOULD NOT needlessly change the association. The server SHOULD NOT needlessly change the
cryptosuites it offers to the same peer because peer devices may have cryptosuites it offers to the same peer because peer devices may have
limited ability to update their persistent storage. However, if the limited ability to update their persistent storage. However, if the
peer has different values in the Cryptosuitep and CryptosuitepPrev peer has different values in the Cryptosuitep and CryptosuitepPrev
fields, it SHOULD also accept offers that are not weaker than fields, it SHOULD also accept offers that are not weaker than
CryptosuitepPrev. Note that Cryptosuitep and CryptosuitePrev from CryptosuitepPrev. Note that Cryptosuitep and CryptosuitePrev from
skipping to change at page 25, line 27 skipping to change at line 1127
use the newly negotiated cryptosuite. The request and response use the newly negotiated cryptosuite. The request and response
(Type=7) MAY additionally contain PeerInfo and ServerInfo objects. (Type=7) MAY additionally contain PeerInfo and ServerInfo objects.
The server then determines the KeyingMode (defined in Section 3.5) The server then determines the KeyingMode (defined in Section 3.5)
based on changes in the negotiated cryptosuite and whether it desires based on changes in the negotiated cryptosuite and whether it desires
to achieve forward secrecy or not. The server SHOULD only select to achieve forward secrecy or not. The server SHOULD only select
KeyingMode 3 when the negotiated cryptosuite differs from the KeyingMode 3 when the negotiated cryptosuite differs from the
Cryptosuitep in the server's persistent EAP-NOOB association, Cryptosuitep in the server's persistent EAP-NOOB association,
although it is technically possible to select this value without although it is technically possible to select this value without
changing the cryptosuite. In the second request and response changing the cryptosuite. In the second request and response
(Type=8), the server informs the peer about the KeyingMode, and the (Type=8), the server informs the peer about the KeyingMode and the
server and peer exchange nonces (Ns2, Np2). When KeyingMode is 2 or server and peer exchange nonces (Ns2, Np2). When KeyingMode is 2 or
3 (rekeying with ECDHE), they also exchange public components of 3 (rekeying with ECDHE), they also exchange public components of
ECDHE keys (PKs2, PKp2). The server ECDHE key MUST be fresh, i.e., ECDHE keys (PKs2, PKp2). The server ECDHE key MUST be fresh, i.e.,
not previously used with the same peer, and the peer ECDHE key SHOULD not previously used with the same peer, and the peer ECDHE key SHOULD
be fresh, i.e., not previously used. be fresh, i.e., not previously used.
In the third and final request and response (Type=9), the server and In the third and final request and response (Type=9), the server and
peer exchange message authentication codes. Both sides MUST compute peer exchange message authentication codes. Both sides MUST compute
the keys Kms2 and Kmp2 as defined in Section 3.5 and the message the keys Kms2 and Kmp2, as defined in Section 3.5, and the message
authentication codes MACs2 and MACp2 as defined in Section 3.3.2. authentication codes MACs2 and MACp2, as defined in Section 3.3.2.
Both sides MUST compare the received message authentication code with Both sides MUST compare the received message authentication code with
a locally computed value. a locally computed value.
The rules by which the peer compares the received MACs2 are non- The rules by which the peer compares the received MACs2 are
trivial because, in addition to authenticating the current exchange, nontrivial because, in addition to authenticating the current
MACs2 may confirm the success or failure of a recent cryptosuite exchange, MACs2 may confirm the success or failure of a recent
upgrade. The peer processes the final request (Type=9) as follows: cryptosuite upgrade. The peer processes the final request (Type=9)
as follows:
1. The peer first compares the received MACs2 value with one it 1. The peer first compares the received MACs2 value with one it
computed using the Kz stored in the persistent EAP-NOOB computed using the Kz stored in the persistent EAP-NOOB
association. If the received and computed values match, the peer association. If the received and computed values match, the peer
deletes any data stored in the CryptosuitepPrev and KzPrev fields deletes any data stored in the CryptosuitepPrev and KzPrev fields
of the persistent EAP-NOOB association. It does this because the of the persistent EAP-NOOB association. It does this because the
received MACs2 confirms that the peer and server share the same received MACs2 confirms that the peer and server share the same
Cryptosuitep and Kz, and any previous values must no longer be Cryptosuitep and Kz, and any previous values must no longer be
accepted. accepted.
2. If, on the other hand, the peer finds that the received MACs2 2. On the other hand, if the peer finds that the received MACs2
value does not match the one it computed locally with Kz, the value does not match the one it computed locally with Kz, the
peer checks whether the KzPrev field in the persistent EAP-NOOB peer checks whether the KzPrev field in the persistent EAP-NOOB
association stores a key. If it does, the peer repeats the key association stores a key. If it does, the peer repeats the key
derivation (Section 3.5) and local MACs2 computation derivation (Section 3.5) and local MACs2 computation
(Section 3.3.2) using KzPrev in place of Kz. If this second (Section 3.3.2) using KzPrev in place of Kz. If this second
computed MACs2 matches the received value, the match indicates computed MACs2 matches the received value, the match indicates
synchronization failure caused by the loss of the last response synchronization failure caused by the loss of the last response
(Type=9) in a previously attempted cryptosuite upgrade. In this (Type=9) in a previously attempted cryptosuite upgrade. In this
case, the peer rolls back that upgrade by overwriting case, the peer rolls back that upgrade by overwriting
Cryptosuitep with CryptosuitepPrev and Kz with KzPrev in the Cryptosuitep with CryptosuitepPrev and Kz with KzPrev in the
persistent EAP-NOOB association. It also clears the persistent EAP-NOOB association. It also clears the
CryptosuitepPrev and KzPrev fields. CryptosuitepPrev and KzPrev fields.
3. If the received MACs2 matched one of the locally computed values, 3. If the received MACs2 matched one of the locally computed values,
the peer proceeds to send the final response (Type=9). The peer the peer proceeds to send the final response (Type=9). The peer
also moves to the Registered (4) state. When KeyingMode is 1 or also moves to the Registered (4) state. When KeyingMode is 1 or
2, the peer stops here. When KeyingMode is 3, the peer also 2, the peer stops here. When KeyingMode is 3, the peer also
updates the persistent EAP-NOOB association with the negotiated updates the persistent EAP-NOOB association with the negotiated
Cryptosuitep and the newly-derived Kz value. To prepare for Cryptosuitep and the newly derived Kz value. To prepare for
possible synchronization failure caused by the loss of the final possible synchronization failure caused by the loss of the final
response (Type=9) during cryptosuite upgrade, the peer copies the response (Type=9) during cryptosuite upgrade, the peer copies the
old Cryptosuitep and Kz values in the persistent EAP-NOOB old Cryptosuitep and Kz values in the persistent EAP-NOOB
association to the CryptosuitepPrev and KzPrev fields. association to the CryptosuitepPrev and KzPrev fields.
4. Finally, if the peer finds that the received MACs2 does not match 4. Finally, if the peer finds that the received MACs2 does not match
either of the two values that it computed locally (or one value either of the two values that it computed locally (or one value
if no KzPrev was stored), the peer sends an error message (error if no KzPrev was stored), the peer sends an error message (error
code 4001, see Section 3.6.1), which causes the Reconnect code 4001, see Section 3.6.5), which causes the Reconnect
Exchange to end in EAP-Failure. Exchange to end in EAP-Failure.
The server rules for processing the final message are simpler than The server rules for processing the final message are simpler than
the peer rules because the server does not store previous keys, and the peer rules because the server does not store previous keys and it
it never rolls back a cryptosuite upgrade. Upon receiving the final never rolls back a cryptosuite upgrade. Upon receiving the final
response (Type=9), the server compares the received value of MACp2 response (Type=9), the server compares the received value of MACp2
with one it computes locally. If the values match, the Reconnect with one it computes locally. If the values match, the Reconnect
Exchange ends in EAP-Success. When KeyingMode is 3, the server also Exchange ends in EAP-Success. When KeyingMode is 3, the server also
updates Cryptosuitep and Kz in the persistent EAP-NOOB association. updates Cryptosuitep and Kz in the persistent EAP-NOOB association.
On the other hand, if the server finds that the values do not match, On the other hand, if the server finds that the values do not match,
it sends an error message (error code 4001), and the Reconnect it sends an error message (error code 4001), and the Reconnect
Exchange ends in EAP-Failure. Exchange ends in EAP-Failure.
The endpoints MAY send updated NewNAI, ServerInfo and PeerInfo The endpoints MAY send updated NewNAI, ServerInfo, and PeerInfo
objects in the Reconnect Exchange. When there is no update to the objects in the Reconnect Exchange. When there is no update to the
values, they SHOULD omit this information from the messages. If the values, they SHOULD omit this information from the messages. If the
NewNAI was sent, each side updates NAI in the persistent EAP-NOOB NewNAI was sent, each side updates NAI in the persistent EAP-NOOB
association when moving to the Registered (4) state. association when moving to the Registered (4) state.
EAP Peer EAP Server EAP Peer EAP Server
| ...continuing from common handshake | | ...continuing from common handshake |
| | | |
|<----------- EAP-Request/EAP-NOOB ----------------| |<----------- EAP-Request/EAP-NOOB ----------------|
| (Type=7,Vers,PeerId,Cryptosuites, | | (Type=7,Vers,PeerId,Cryptosuites, |
skipping to change at page 27, line 38 skipping to change at line 1235
| (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 -------------------------|
| | | |
Figure 8: Reconnect Exchange Figure 8: Reconnect Exchange
3.4.3. User reset 3.4.3. User Reset
As shown in the association state machine in Figure 1, the only As shown in the association state machine in Figure 1, the only
specified way for the association to return from the Registered state specified way for the association to return from the Registered (4)
(4) to the Unregistered state (0) is through user-initiated reset. state to the Unregistered (0) state is through user-initiated reset.
After the reset, a new OOB message will be needed to establish a new After the reset, a new OOB message will be needed to establish a new
association between the EAP server and peer. Typical situations in association between the EAP server and peer. Typical situations in
which the user reset is required are when the other side has which the user reset is required are when the other side has
accidentally lost the persistent EAP-NOOB association data, or when accidentally lost the persistent EAP-NOOB association data or when
the peer device is decommissioned. the peer device is decommissioned.
The server could detect that the peer is in the Registered or The server could detect that the peer is in the Registered or
Reconnecting state but the server itself is in one of the ephemeral Reconnecting state, but the server itself is in one of the ephemeral
states 0..2 (including situations where the server does not recognize states 0..2 (including situations where the server does not recognize
the PeerId). In this case, effort should be made to recover the the PeerId). In this case, effort should be made to recover the
persistent server state, for example, from a backup storage - persistent server state, for example, from a backup storage --
especially if many peer devices are similarly affected. If that is especially if many peer devices are similarly affected. If that is
not possible, the EAP server SHOULD log the error or notify an not possible, the EAP server SHOULD log the error or notify an
administrator. The only way to continue from such a situation is by administrator. The only way to continue from such a situation is by
having the user reset the peer device. having the user reset the peer device.
On the other hand, if the peer is in any of the ephemeral states On the other hand, if the peer is in any of the ephemeral states
0..2, including the Unregistered state, the server will treat the 0..2, including the Unregistered state, the server will treat the
peer as a new peer device and allocate a new PeerId to it. The peer as a new peer device and allocate a new PeerId to it. The
PeerInfo can be used by the user as a clue to which physical device 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 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 "new" peer with the old PeerId without repeating the OOB Step. This
situation will be resolved when the user performs the OOB Step and, situation will be resolved when the user performs the OOB Step and
thus, identifies the physical peer device. The server user interface thus identifies the physical peer device. The server user interface
MAY support situations where the "new" peer is actually a previously MAY support situations where the "new" peer is actually a previously
registered peer that has been reset by a user or otherwise lost its registered peer that has been reset by a user or otherwise lost its
persistent data. In those cases, the user could choose to merge the persistent data. In those cases, the user could choose to merge the
new peer identity with the old one in the server. The alternative is new peer identity with the old one in the server. The alternative is
to treat the device just like a new peer. to treat the device just like a new peer.
3.5. Key derivation 3.5. Key Derivation
EAP-NOOB derives the EAP output values MSK and EMSK and other secret EAP-NOOB derives the EAP output values MSK and EMSK and other secret
keying material from the output of an Ephemeral Elliptic Curve keying material from the output of an Ephemeral Elliptic Curve
Diffie-Hellman (ECDHE) algorithm following the NIST specification Diffie-Hellman (ECDHE) algorithm following the NIST specification
[NIST-DH]. In NIST terminology, we use a C(2e, 0s, ECC CDH) scheme, [NIST-DH]. In NIST terminology, we use a C(2e, 0s, ECC CDH) scheme,
i.e., two ephemeral keys and no static keys. In the Initial and i.e., two ephemeral keys and no static keys. In the Initial Exchange
Reconnect Exchanges, the server and peer compute the ECDHE shared and Reconnect Exchange, the server and peer compute the ECDHE shared
secret Z as defined in section 6.1.2 of the NIST specification secret Z, as defined in Section 6.1.2 of the NIST specification
[NIST-DH]. In the Completion and Reconnect Exchanges, the server and [NIST-DH]. In the Completion Exchange and Reconnect Exchange, the
peer compute the secret keying material from Z with the one-step key server and peer compute the secret keying material from Z with the
derivation function (KDF) defined in section 5.8.2.1 of the NIST one-step key derivation function (KDF) defined in Section 5.8.2.1 of
specification. The auxiliary function H is a hash function, and it the NIST specification. The auxiliary function H is a hash function,
is taken from the negotiated cryptosuite. and it is taken from the negotiated cryptosuite.
+------------+------------------------------------------------------+ +============+============================================+
| KeyingMode | Description | | KeyingMode | Description |
+------------+------------------------------------------------------+ +============+============================================+
| 0 | Completion Exchange (always with ECDHE) | | 0 | Completion Exchange (always with ECDHE) |
| | | +------------+--------------------------------------------+
| 1 | Reconnect Exchange, rekeying without ECDHE | | 1 | Reconnect Exchange, rekeying without ECDHE |
| | | +------------+--------------------------------------------+
| 2 | Reconnect Exchange, rekeying with ECHDE, no change | | 2 | Reconnect Exchange, rekeying with ECHDE, |
| | in cryptosuite | | | no change in cryptosuite |
| | | +------------+--------------------------------------------+
| 3 | Reconnect Exchange, rekeying with ECDHE, new | | 3 | Reconnect Exchange, rekeying with ECDHE, |
| | cryptosuite negotiated | | | new cryptosuite negotiated |
+------------+------------------------------------------------------+ +------------+--------------------------------------------+
Table 3: Keying modes Table 3: Keying Modes
The key derivation has four different modes (KeyingMode), which are The key derivation has four different modes (KeyingMode), which are
specified in Table 3. Table 4 defines the inputs to KDF in each specified in Table 3. Table 4 defines the inputs to KDF in each
KeyingMode. KeyingMode.
In the Completion Exchange (KeyingMode=0), the input Z comes from the In the Completion Exchange (KeyingMode=0), the input Z comes from the
preceding Initial exchange. KDF takes some additional inputs preceding Initial exchange. The KDF takes some additional inputs
(FixedInfo), for which we use the concatenation format defined in (FixedInfo), for which we use the concatenation format defined in
section 5.8.2.1.1 of the NIST specification [NIST-DH]. FixedInfo Section 5.8.2.1.1 of the NIST specification [NIST-DH]. FixedInfo
consists of the AlgorithmId, PartyUInfo, PartyVInfo, and SuppPrivInfo consists of the AlgorithmId, PartyUInfo, PartyVInfo, and SuppPrivInfo
fields. The first three fields are fixed-length bit strings, and fields. The first three fields are fixed-length bit strings, and
SuppPrivInfo is a variable-length string with a one-byte Datalength SuppPrivInfo is a variable-length string with a one-byte Datalength
counter. AlgorithmId is the fixed-length 8-byte ASCII string "EAP- counter. AlgorithmId is the fixed-length, 8-byte ASCII string "EAP-
NOOB". The other input values are the server and peer nonces. In NOOB". The other input values are the server and peer nonces. In
the Completion Exchange, the inputs also include the secret nonce the Completion Exchange, the inputs also include the secret nonce
Noob from the OOB message. Noob from the OOB message.
In the simplest form of the Reconnect Exchange (KeyingMode=1), fresh In the simplest form of the Reconnect Exchange (KeyingMode=1), fresh
nonces are exchanged but no ECDHE keys are sent. In this case, input nonces are exchanged, but no ECDHE keys are sent. In this case,
Z to the KDF is replaced with the shared key Kz from the persistent input Z to the KDF is replaced with the shared key Kz from the
EAP-NOOB association. The result is rekeying without the persistent EAP-NOOB association. The result is rekeying without the
computational cost of the ECDHE exchange, but also without forward computational cost of the ECDHE exchange but also without forward
secrecy. secrecy.
When forward secrecy is desired in the Reconnect Exchange When forward secrecy is desired in the Reconnect Exchange
(KeyingMode=2 or KeyingMode=3), both nonces and ECDHE keys are (KeyingMode=2 or KeyingMode=3), both nonces and ECDHE keys are
exchanged. Input Z is the fresh shared secret from the ECDHE exchanged. Input Z is the fresh shared secret from the ECDHE
exchange with PKs2 and PKp2. The inputs also include the shared exchange with PKs2 and PKp2. The inputs also include the shared
secret Kz from the persistent EAP-NOOB association. This binds the secret Kz from the persistent EAP-NOOB association. This binds the
rekeying output to the previously authenticated keys. rekeying output to the previously authenticated keys.
+--------------+--------------+------------------------+------------+ +=========================+==============+===============+==========+
| KeyingMode | KDF input | Value | Length | | KeyingMode | KDF input | Value | Length |
| | field | | (bytes) | | | field | | (bytes) |
+--------------+--------------+------------------------+------------+ +=========================+==============+===============+==========+
| 0 | Z | ECDHE shared secret | variable | | 0 Completion | Z | ECDHE shared | variable |
| Completion | | from PKs and PKp | | | | | secret from | |
| | AlgorithmId | "EAP-NOOB" | 8 | | | | PKs and PKp | |
| | PartyUInfo | Np | 32 | | +--------------+---------------+----------+
| | PartyVInfo | Ns | 32 | | | AlgorithmId | "EAP-NOOB" | 8 |
| | SuppPubInfo | (not allowed) | | | +--------------+---------------+----------+
| | SuppPrivInfo | Noob | 16 | | | PartyUInfo | Np | 32 |
| | | | | | +--------------+---------------+----------+
| 1 | Z | Kz | 32 | | | PartyVInfo | Ns | 32 |
| Reconnect, | AlgorithmId | "EAP-NOOB" | 8 | | +--------------+---------------+----------+
| rekeying | PartyUInfo | Np2 | 32 | | | SuppPubInfo | (not | |
| without | PartyVInfo | Ns2 | 32 | | | | allowed) | |
| ECDHE | SuppPubInfo | (not allowed) | | | +--------------+---------------+----------+
| | SuppPrivInfo | (null) | 0 | | | SuppPrivInfo | Noob | 16 |
| | | | | +-------------------------+--------------+---------------+----------+
| 2 or 3 | Z | ECDHE shared secret | variable | | 1 Reconnect, rekeying | Z | Kz | 32 |
| Reconnect, | | from PKs2 and PKp2 | | | without ECDHE +--------------+---------------+----------+
| rekeying, | AlgorithmId | "EAP-NOOB" | 8 | | | AlgorithmId | "EAP-NOOB" | 8 |
| with ECDHE, | PartyUInfo | Np2 | 32 | | +--------------+---------------+----------+
| same or new | PartyVInfo | Ns2 | 32 | | | PartyUInfo | Np2 | 32 |
| cryptosuite | SuppPubInfo | (not allowed) | | | +--------------+---------------+----------+
| | SuppPrivInfo | Kz | 32 | | | PartyVInfo | Ns2 | 32 |
+--------------+--------------+------------------------+------------+ | +--------------+---------------+----------+
| | SuppPubInfo | (not | |
| | | allowed) | |
| +--------------+---------------+----------+
| | SuppPrivInfo | (null) | 0 |
+-------------------------+--------------+---------------+----------+
| 2 or 3 Reconnect, | Z | ECDHE shared | variable |
| rekeying, with ECDHE, | | secret from | |
| same or new cryptosuite | | PKs2 and | |
| | | PKp2 | |
| +--------------+---------------+----------+
| | AlgorithmId | "EAP-NOOB" | 8 |
| +--------------+---------------+----------+
| | PartyUInfo | Np2 | 32 |
| +--------------+---------------+----------+
| | PartyVInfo | Ns2 | 32 |
| +--------------+---------------+----------+
| | SuppPubInfo | (not | |
| | | allowed) | |
| +--------------+---------------+----------+
| | SuppPrivInfo | Kz | 32 |
+-------------------------+--------------+---------------+----------+
Table 4: Key derivation input Table 4: Key Derivation Input
Table 5 defines how the output bytes of KDF are used. In addition to Table 5 defines how the output bytes of the KDF are used. In
the EAP output values MSK and EMSK, the server and peer derive addition to the EAP output values MSK and EMSK, the server and peer
another shared secret key AMSK, which MAY be used for application- derive another shared secret key AMSK (Application Main Session Key),
layer security. Further output bytes are used internally by EAP-NOOB which MAY be used for application-layer security. Further output
for the message authentication keys (Kms, Kmp, Kms2, Kmp2). bytes are used internally by EAP-NOOB for the message authentication
keys (Kms, Kmp, Kms2, and Kmp2).
The Completion Exchange (KeyingMode=0) produces the shared secret Kz, The Completion Exchange (KeyingMode=0) produces the shared secret Kz,
which the server and peer store in the persistent EAP-NOOB which the server and peer store in the persistent EAP-NOOB
association. When a new cryptosuite is negotiated in the Reconnect association. When a new cryptosuite is negotiated in the Reconnect
Exchange (KeyingMode=3), it similarly produces a new Kz. In that Exchange (KeyingMode=3), it similarly produces a new Kz. In that
case, the server and peer update both the cryptosuite and Kz in the case, the server and peer update both the cryptosuite and Kz in the
persistent EAP-NOOB association. Additionally, the peer stores the persistent EAP-NOOB association. Additionally, the peer stores the
previous Cryptosuitep and Kz values in the CryptosuitepPrev and previous Cryptosuitep and Kz values in the CryptosuitepPrev and
KzPrev fields of the persistent EAP-NOOB association. KzPrev fields of the persistent EAP-NOOB association.
+-----------------+------------------+----------+----------------+ +==============================+============+==========+=========+
| KeyingMode | KDF output bytes | Used as | Length (bytes) | | KeyingMode | KDF output | Used as | Length |
+-----------------+------------------+----------+----------------+ | | bytes | | (bytes) |
| 0 | 0..63 | MSK | 64 | +==============================+============+==========+=========+
| Completion | 64..127 | EMSK | 64 | | 0 Completion | 0..63 | MSK | 64 |
| | 128..191 | AMSK | 64 | | +------------+----------+---------+
| | 192..223 | MethodId | 32 | | | 64..127 | EMSK | 64 |
| | 224..255 | Kms | 32 | | +------------+----------+---------+
| | 256..287 | Kmp | 32 | | | 128..191 | AMSK | 64 |
| | 288..319 | Kz | 32 | | +------------+----------+---------+
| | | | | | | 192..223 | MethodId | 32 |
| 1 or 2 | 0..63 | MSK | 64 | | +------------+----------+---------+
| Reconnect, | 64..127 | EMSK | 64 | | | 224..255 | Kms | 32 |
| rekeying | 128..191 | AMSK | 64 | | +------------+----------+---------+
| without ECDHE, | 192..223 | MethodId | 32 | | | 256..287 | Kmp | 32 |
| or with ECDHE | 224..255 | Kms2 | 32 | | +------------+----------+---------+
| and unchanged | 256..287 | Kmp2 | 32 | | | 288..319 | Kz | 32 |
| cryptosuite | | | | +------------------------------+------------+----------+---------+
| | | | | | 1 or 2 Reconnect, rekeying | 0..63 | MSK | 64 |
| | | | | | without ECDHE, or with ECDHE +------------+----------+---------+
| 3 Reconnect, | 0..63 | MSK | 64 | | and unchanged cryptosuite | 64..127 | EMSK | 64 |
| rekeying | 64..127 | EMSK | 64 | | +------------+----------+---------+
| with ECDHE, | 128..191 | AMSK | 64 | | | 128..191 | AMSK | 64 |
| new cryptosuite | 192..223 | MethodId | 32 | | +------------+----------+---------+
| | 224..255 | Kms2 | 32 | | | 192..223 | MethodId | 32 |
| | 256..287 | Kmp2 | 32 | | +------------+----------+---------+
| | 288..319 | Kz | 32 | | | 224..255 | Kms2 | 32 |
+-----------------+------------------+----------+----------------+ | +------------+----------+---------+
| | 256..287 | Kmp2 | 32 |
+------------------------------+------------+----------+---------+
| 3 Reconnect, rekeying with | 0..63 | MSK | 64 |
| ECDHE, new cryptosuite +------------+----------+---------+
| | 64..127 | EMSK | 64 |
| +------------+----------+---------+
| | 128..191 | AMSK | 64 |
| +------------+----------+---------+
| | 192..223 | MethodId | 32 |
| +------------+----------+---------+
| | 224..255 | Kms2 | 32 |
| +------------+----------+---------+
| | 256..287 | Kmp2 | 32 |
| +------------+----------+---------+
| | 288..319 | Kz | 32 |
+------------------------------+------------+----------+---------+
Table 5: Key derivation output Table 5: Key Derivation Output
Finally, every EAP method must export a Server-Id, Peer-Id, and Finally, every EAP method must export a Server-Id, Peer-Id, and
Session-Id [RFC5247]. In EAP-NOOB, the exported Peer-Id is the Session-Id [RFC5247]. In EAP-NOOB, the exported Peer-Id is the
PeerId which the server has assigned to the peer. The exported PeerId that the server has assigned to the peer. The exported
Server-Id is a zero-length string (i.e., null string) because EAP- Server-Id is a zero-length string (i.e., null string) because EAP-
NOOB neither knows nor assigns any server identifier. The exported NOOB neither knows nor assigns any server identifier. The exported
Session-Id is created by concatenating the Type-Code xxx (TBA) with Session-Id is created by concatenating the one-byte Type-Code 0x38
the MethodId, which is obtained from the KDF output as shown in (decimal value 56) with the MethodId, which is obtained from the KDF
Table 5. output, as shown in Table 5.
3.6. Error handling 3.6. Error Handling
Various error conditions in EAP-NOOB are handled by sending an error Various error conditions in EAP-NOOB are handled by sending an error
notification message (Type=0) instead of a next EAP request or notification message (Type=0) instead of a next EAP request or
response message. Both the EAP server and the peer may send the response message. Both the EAP server and the peer may send the
error notification, as shown in Figure 9 and Figure 10. After error notification, as shown in Figures 9 and 10. After sending or
sending or receiving an error notification, the server MUST send an receiving an error notification, the server MUST send an EAP-Failure
EAP-Failure (as required by [RFC3748] section 4.2). The notification (as required by [RFC3748], Section 4.2). The notification MAY
MAY contain an ErrorInfo field, which is a UTF-8 encoded text string contain an ErrorInfo field, which is a UTF-8-encoded text string with
with a maximum length of 500 bytes. It is used for sending a maximum length of 500 bytes. It is used for sending descriptive
descriptive information about the error for logging and debugging information about the error for logging and debugging purposes.
purposes.
EAP Peer EAP Server EAP Peer EAP Server
... ... ... ...
| | | |
|<----------- EAP-Request/EAP-NOOB ----------------| |<----------- EAP-Request/EAP-NOOB ----------------|
| (Type=0,[PeerId],ErrorCode,[ErrorInfo]) | | (Type=0,[PeerId],ErrorCode,[ErrorInfo]) |
| | | |
| | | |
|<----------- EAP-Failure -------------------------| |<----------- EAP-Failure -------------------------|
| | | |
Figure 9: Error notification from server to peer Figure 9: Error Notification from Server to Peer
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 -------------------------|
| | | |
Figure 10: Error notification from peer to server Figure 10: Error Notification from Peer to Server
After the exchange fails due to an error notification, the server and After the exchange fails due to an error notification, the server and
peer set the association state as follows. In the Initial Exchange, peer set the association state as follows. In the Initial Exchange,
both the sender and recipient of the error notification MUST set the both the sender and recipient of the error notification MUST set the
association state to the Unregistered (0) state. In the Waiting and association state to the Unregistered (0) state. In the Waiting
Completion Exchanges, each side MUST remain in its old state as if Exchange and Completion Exchange, each side MUST remain in its old
the failed exchange had not taken place, with the exception that the state as if the failed exchange had not taken place, with the
recipient of error code 2003 processes it as specified in exception that the recipient of error code 2003 processes it as
Section 3.2.4. In the Reconnect Exchange, both sides MUST set the specified in Section 3.2.4. In the Reconnect Exchange, both sides
association state to the Reconnecting (3) state. MUST set the association state to the Reconnecting (3) state.
Errors that occur in the OOB channel are not explicitly notified in- Errors that occur in the OOB channel are not explicitly notified in-
band. band.
3.6.1. Invalid messages 3.6.1. Invalid Messages
If the NAI structure is invalid, the server SHOULD send the error If the NAI structure is invalid, the server SHOULD send the error
code 1001 to the peer. The recipient of an EAP-NOOB request or code 1001 to the peer. The recipient of an EAP-NOOB request or
response SHOULD send the following error codes back to the sender: response SHOULD send the following error codes back to the sender:
1002 if it cannot parse the message as a JSON object or the top-level 1002 if it cannot parse the message as a JSON object or the top-level
JSON object has missing or unrecognized members; 1003 if a data field JSON object has missing or unrecognized members; 1003 if a data field
has an invalid value, such as an integer out of range, and there is has an invalid value, such as an integer out of range, and there is
no more specific error code available; 1004 if the received message no more specific error code available; 1004 if the received message
type was unexpected in the current state; 2004 if the PeerId has an 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 unexpected value; 2003 if the NoobId is not recognized; and 1005 if
the ECDHE key is invalid. the ECDHE key is invalid.
3.6.2. Unwanted peer 3.6.2. Unwanted Peer
The preferred way for the EAP server to rate limit EAP-NOOB The preferred way for the EAP server to rate limit EAP-NOOB
connections from a peer is to use the SleepTime parameter in the connections from a peer is to use the SleepTime parameter in the
Waiting Exchange. However, if the EAP server receives repeated EAP- Waiting Exchange. However, if the EAP server receives repeated EAP-
NOOB connections from a peer which apparently should not connect to NOOB connections from a peer that apparently should not connect to
this server, the server MAY indicate that the connections are this server, the server MAY indicate that the connections are
unwanted by sending the error code 2001. After receiving this error unwanted by sending the error code 2001. After receiving this error
message, the peer MAY refrain from reconnecting to the same EAP message, the peer MAY refrain from reconnecting to the same EAP
server and, if possible, both the EAP server and peer SHOULD indicate server, and, if possible, both the EAP server and peer SHOULD
this error condition to the user or server administrator. However, indicate this error condition to the user or server administrator.
in order to avoid persistent denial of service, peer devices that are However, in order to avoid persistent denial of service, peer devices
unable to alert a user SHOULD continue to try to reconnect that are unable to alert a user SHOULD continue to try to reconnect
infrequently (e.g., approximately every 3600 seconds). infrequently (e.g., approximately every 3600 seconds).
3.6.3. State mismatch 3.6.3. State Mismatch
In the states indicated by "-" in Figure 11 in Appendix A, user In the states indicated by "-" in Table 14 in Appendix A, user action
action is required to reset the association state or to recover it, is required to reset the association state or to recover it, for
for example, from backup storage. In those cases, the server sends example, from backup storage. In those cases, the server sends the
the error code 2002 to the peer. If possible, both the EAP server error code 2002 to the peer. If possible, both the EAP server and
and peer SHOULD indicate this error condition to the user or server peer SHOULD indicate this error condition to the user or server
administrator. administrator.
3.6.4. Negotiation failure 3.6.4. Negotiation Failure
If there is no matching protocol version, the peer sends the error If there is no matching protocol version, the peer sends the error
code 3001 to the server. If there is no matching cryptosuite, the code 3001 to the server. If there is no matching cryptosuite, the
peer sends the error code 3002 to the server. If there is no peer sends the error code 3002 to the server. If there is no
matching OOB direction, the peer sends the error code 3003 to the matching OOB direction, the peer sends the error code 3003 to the
server. server.
In practice, there is no way of recovering from these errors without In practice, there is no way of recovering from these errors without
software or hardware changes. If possible, both the EAP server and software or hardware changes. If possible, both the EAP server and
peer SHOULD indicate these error conditions to the user. peer SHOULD indicate these error conditions to the user.
3.6.5. Cryptographic verification failure 3.6.5. Cryptographic Verification Failure
If the receiver of the OOB message detects an unrecognized PeerId or If the receiver of the OOB message detects an unrecognized PeerId or
incorrect fingerprint (Hoob) in the OOB message, the receiver MUST incorrect fingerprint (Hoob) in the OOB message, the receiver MUST
remain in the Waiting for OOB state (1) as if no OOB message was remain in the Waiting for OOB (1) state as if no OOB message was
received. The receiver SHOULD indicate the failure to accept the OOB received. The receiver SHOULD indicate the failure to accept the OOB
message to the user. No in-band error message is sent. message to the user. No in-band error message is sent.
Note that if the OOB message was delivered from the server to the Note that if the OOB message was delivered from the server to the
peer and the peer does not recognize the PeerId, the likely cause is peer and the peer does not recognize the PeerId, the likely cause is
that the user has unintentionally delivered the OOB message to the that the user has unintentionally delivered the OOB message to the
wrong peer device. If possible, the peer SHOULD indicate this to the wrong peer device. If possible, the peer SHOULD indicate this to the
user; however, the peer device may not have the capability for many user; however, the peer device may not have the capability for many
different error indications to the user, and it MAY use the same different error indications to the user, and it MAY use the same
indication as in the case of an incorrect fingerprint. indication as in the case of an incorrect fingerprint.
The rationale for the above is that the invalid OOB message could The rationale for the above is that the invalid OOB message could
have been presented to the receiver by mistake or intentionally by a have been presented to the receiver by mistake or intentionally by a
malicious party and, thus, it should be ignored in the hope that the malicious party; thus, it should be ignored in the hope that the
honest user will soon deliver a correct OOB message. honest user will soon deliver a correct OOB message.
If the EAP server or peer detects an incorrect message authentication If the EAP server or peer detects an incorrect message authentication
code (MACs, MACp, MACs2, MACp2), it sends the error code 4001 to the code (MACs, MACp, MACs2, or MACp2), it sends the error code 4001 to
other side. As specified in the beginning of Section 3.6, the failed the other side. As specified in the beginning of Section 3.6, the
Completion Exchange will not result in server or peer state changes failed Completion Exchange will not result in server or peer state
while an error in the Reconnect Exchange will put both sides to the changes, while an error in the Reconnect Exchange will put both sides
Reconnecting (3) state and thus lead to another reconnect attempt. to the Reconnecting (3) state and thus lead to another reconnect
attempt.
The rationale for this is that the invalid cryptographic message may The rationale for this is that the invalid cryptographic message may
have been spoofed by a malicious party and, thus, it should be have been spoofed by a malicious party; thus, it should be ignored.
ignored. In particular, a spoofed message on the in-band channel In particular, a spoofed message on the in-band channel should not
should not force the honest user to perform the OOB Step again. In force the honest user to perform the OOB Step again. In practice,
practice, however, the error may be caused by other failures, such as however, the error may be caused by other failures, such as a
a software bug. For this reason, the EAP server MAY limit the rate software bug. For this reason, the EAP server MAY limit the rate of
of peer connections with SleepTime after the above error. Also, peer connections with SleepTime after the above error. Also, there
there SHOULD be a way for the user to reset the peer to the SHOULD be a way for the user to reset the peer to the Unregistered
Unregistered state (0), so that the OOB Step can be repeated as the (0) state so that the OOB Step can be repeated as the last resort.
last resort.
3.6.6. Application-specific failure 3.6.6. Application-Specific Failure
Applications MAY define new error messages for failures that are Applications MAY define new error messages for failures that are
specific to the application or to one type of OOB channel. They MAY specific to the application or to one type of OOB channel. They MAY
also use the generic application-specific error code 5001, or the also use the generic application-specific error code 5001 or the
error codes 5002 and 5004, which have been reserved for indicating error codes 5002 and 5004, which have been reserved for indicating
invalid data in the ServerInfo and PeerInfo fields, respectively. invalid data in the ServerInfo and PeerInfo fields, respectively.
Additionally, anticipating OOB channels that make use of a URL, the Additionally, anticipating OOB channels that make use of a URL, the
error code 5003 has been reserved for indicating an invalid server error code 5003 has been reserved for indicating an invalid server
URL. URL.
4. ServerInfo and PeerInfo contents 4. ServerInfo and PeerInfo Contents
The ServerInfo and PeerInfo fields in the Initial Exchange and The ServerInfo and PeerInfo fields in the Initial Exchange and
Reconnect Exchange enable the server and peer, respectively, to send Reconnect Exchange enable the server and peer, respectively, to send
information about themselves to the other endpoint. They contain information about themselves to the other endpoint. They contain
JSON objects whose structure may be specified separately for each JSON objects whose structure may be specified separately for each
application and each type of OOB channel. ServerInfo and PeerInfo application and each type of OOB channel. ServerInfo and PeerInfo
MAY contain auxiliary data needed for the OOB channel messaging and MAY contain auxiliary data needed for the OOB channel messaging and
for EAP channel binding (see Section 7.7). This section describes for EAP channel binding (see Section 6.7). This section describes
the optional initial data fields for ServerInfo and PeerInfo the optional initial data fields for ServerInfo and PeerInfo
registered by this specification. Further specifications may request registered by this specification. Further specifications may request
new application-specific ServerInfo and PeerInfo data fields from new application-specific ServerInfo and PeerInfo data fields from
IANA (see Section 5.4 and Section 5.5). IANA (see Sections 5.4 and 5.5).
+----------------+--------------------------------------------------+ +================+=================================================+
| Data Field | Description | | Data Field | Description |
+----------------+--------------------------------------------------+ +================+=================================================+
| Type | Type-tag string that can be used by the peer as | | Type | Type-tag string that can be used by the peer as |
| | a hint for how to interpret the ServerInfo | | | a hint for how to interpret the ServerInfo |
| | contents. | | | contents. |
| | | +----------------+-------------------------------------------------+
| ServerName | String that may be used to aid human | | ServerName | String that may be used to aid human |
| | identification of the server. | | | identification of the server. |
| | | +----------------+-------------------------------------------------+
| ServerURL | Prefix string when the OOB message is formatted | | ServerURL | Prefix string when the OOB message is formatted |
| | as a URL, as suggested in Appendix D. | | | as a URL, as suggested in Appendix D. |
| | | +----------------+-------------------------------------------------+
| SSIDList | List of IEEE 802.11 wireless network identifier | | SSIDList | List of IEEE 802.11 wireless network service |
| | (SSID) strings used for roaming support, as | | | set identifier (SSID) strings used for roaming |
| | suggested in Appendix C. JSON array of ASCII | | | support, as suggested in Appendix C. JSON |
| | encoded SSID strings. | | | array of ASCII-encoded SSID strings. |
| | | +----------------+-------------------------------------------------+
| Base64SSIDList | List of IEEE 802.11 wireless network identifier | | Base64SSIDList | List of IEEE 802.11 wireless network identifier |
| | (SSID) strings used for roaming support, as | | | (SSID) strings used for roaming support, as |
| | suggested in Appendix C. JSON array of SSIDs, | | | suggested in Appendix C. JSON array of SSIDs, |
| | each of which is base64url encoded without | | | each of which is base64url-encoded without |
| | padding. Peers SHOULD send at most one of the | | | padding. Peers SHOULD send at most one of the |
| | fields SSIDList and Base64SSIDList in PeerInfo, | | | fields SSIDList and Base64SSIDList in PeerInfo, |
| | and the server SHOULD ignore SSIDList if | | | and the server SHOULD ignore SSIDList if |
| | Base64SSIDList is included. | | | Base64SSIDList is included. |
+----------------+--------------------------------------------------+ +----------------+-------------------------------------------------+
Table 6: ServerInfo data fields Table 6: ServerInfo Data Fields
+--------------+----------------------------------------------------+ +==============+===================================================+
| Data Field | Description | | Data Field | Description |
+--------------+----------------------------------------------------+ +==============+===================================================+
| Type | Type-tag string that can be used by the server as | | Type | Type-tag string that can be used by the server as |
| | a hint for how to interpret the PeerInfo contents. | | | a hint for how to interpret the PeerInfo |
| | | | | contents. |
| PeerName | String that may be used to aid human | +--------------+---------------------------------------------------+
| | identification of the peer. | | PeerName | String that may be used to aid human |
| | | | | identification of the peer. |
| Manufacturer | Manufacturer or brand string. | +--------------+---------------------------------------------------+
| | | | Manufacturer | Manufacturer or brand string. |
| Model | Manufacturer-specified model string. | +--------------+---------------------------------------------------+
| | | | Model | Manufacturer-specified model string. |
| SerialNumber | Manufacturer-assigned serial number. | +--------------+---------------------------------------------------+
| | | | SerialNumber | Manufacturer-assigned serial number. |
| MACAddress | Peer link-layer identifier (EUI-48) in the | +--------------+---------------------------------------------------+
| | 12-digit base-16 form [EUI-48]. The string MAY be | | MACAddress | Peer link-layer 48-bit extended unique identifier |
| | in upper or lower case and MAY include additional | | | (EUI-48) in the 12-digit base-16 form [EUI-48]. |
| | colon ':' or dash '-' characters that MUST be | | | The string MAY be in upper or lower case and MAY |
| | ignored by the server. | | | include additional colon ':' or dash '-' |
| | | | | characters that MUST be ignored by the server. |
| SSID | IEEE 802.11 network SSID for channel binding. The | +--------------+---------------------------------------------------+
| | SSID is an ASCII string. | | SSID | IEEE 802.11 network SSID for channel binding. |
| | | | | The SSID is an ASCII string. |
| Base64SSID | IEEE 802.11 network SSID for channel binding. The | +--------------+---------------------------------------------------+
| | SSID is base64url encoded. Peer SHOULD send at | | Base64SSID | IEEE 802.11 network SSID for channel binding. |
| | most one of the fields SSID and Base64SSID in | | | The SSID is base64url encoded. Peer SHOULD send |
| | PeerInfo, and the server SHOULD ignore SSID if | | | at most one of the fields SSID and Base64SSID in |
| | Base64SSID is included. | | | PeerInfo, and the server SHOULD ignore SSID if |
| | | | | Base64SSID is included. |
| BSSID | Wireless network BSSID (EUI-48) in the 12-digit | +--------------+---------------------------------------------------+
| | base-16 form [EUI-48] for channel binding. The | | BSSID | Wireless network basic service set identifier |
| | string MAY be in upper or lower case and MAY | | | (BSSID) (EUI-48) in the 12-digit base-16 form |
| | include additional colon ':' or dash '-' | | | [EUI-48] for channel binding. The string MAY be |
| | characters that MUST be ignored by the server. | | | in upper or lower case and MAY include additional |
| | | | | colon ':' or dash '-' characters that MUST be |
+--------------+----------------------------------------------------+ | | ignored by the server. |
+--------------+---------------------------------------------------+
Table 7: PeerInfo data fields Table 7: PeerInfo Data Fields
5. IANA Considerations 5. IANA Considerations
This section provides guidance to the Internet Assigned Numbers This section provides information regarding registration of values
Authority (IANA) regarding registration of values related to the EAP- related to the EAP-NOOB method, in accordance with [RFC8126].
NOOB protocol, in accordance with [RFC8126].
The EAP Method Type number for EAP-NOOB needs to be assigned in the The EAP Method Type for EAP-NOOB (value 56) has been assigned in the
Method Types sub-registry of the Extensible Authentication Protocol "Method Types" subregistry of the "Extensible Authentication Protocol
(EAP) registry (requested value = 56). (EAP) Registry".
This memo also requires IANA to create and maintain a new registry Per this memo, IANA has created and will maintain a new registry
entitled "Nimble out-of-band authentication for EAP Parameters" in entitled "Nimble Out-of-Band Authentication for EAP Parameters (EAP-
the Extensible Authentication Protocol (EAP) registry. IANA is also NOOB)" in the Extensible Authentication Protocol (EAP) category.
requested to create and maintain sub-registries defined in the Also, IANA has created and will maintain the subregistries defined in
following subsections. the following subsections.
5.1. Cryptosuites 5.1. Cryptosuites
IANA is requested to create and maintain a new sub-registry entitled IANA has created and will maintain a new subregistry entitled "EAP-
"EAP-NOOB Cryptosuites" in the "Nimble out-of-band authentication for NOOB Cryptosuites" in the "Nimble Out-of-Band Authentication for EAP
EAP Parameters" registry. Cryptosuites are identified by an integer. Parameters (EAP-NOOB)" registry. Cryptosuites are identified by an
Each cryptosuite MUST specify an ECDHE curve for the key exchange, integer. Each cryptosuite MUST specify an ECDHE curve for the key
encoding of the ECDHE public key as a JWK object, and a cryptographic exchange, encoding of the ECDHE public key as a JWK object, and a
hash function for the fingerprint and HMAC computation and key cryptographic hash function for the fingerprint and HMAC computation
derivation. The hash value output by the cryptographic hash function and key derivation. The hash value output by the cryptographic hash
MUST be at least 32 bytes in length. The initial values for this function MUST be at least 32 bytes in length. The initial values for
registry are: this registry are:
+-------------+-----------------------------------------------------+ +=============+===============================================+
| Cryptosuite | Algorithms | | Cryptosuite | Algorithms |
+-------------+-----------------------------------------------------+ +=============+===============================================+
| 1 | ECDHE curve Curve25519 [RFC7748], public-key format | | 0 | Reserved |
| | [RFC7517], hash function SHA-256 [RFC6234]. The JWK | +-------------+-----------------------------------------------+
| | encoding of Curve25519 public key is defined in | | 1 | ECDHE curve Curve25519 [RFC7748], public-key |
| | [RFC8037]. For clarity: the "crv" parameter is | | | format [RFC7517], hash function SHA-256 |
| | "X25519", the "kty" parameter is "OKP", and the | | | [RFC6234]. The JWK encoding of Curve25519 |
| | public-key encoding contains only an x-coordinate. | | | public key is defined in [RFC8037]. For |
| 2 | ECDHE curve NIST P-256 [FIPS186-4], public-key | | | clarity, the "crv" parameter is "X25519", the |
| | format [RFC7517], hash function SHA-256 [RFC6234]. | | | "kty" parameter is "OKP", and the public-key |
| | The JWK encoding of NIST P-256 public key is | | | encoding contains only an x-coordinate. |
| | defined in [RFC7518]. For clarity: the "crv" | +-------------+-----------------------------------------------+
| | parameter is "P-256", the "kty" parameter is "EC", | | 2 | ECDHE curve NIST P-256 [FIPS186-4], public- |
| | and the public-key encoding has both an x and y | | | key format [RFC7517], hash function SHA-256 |
| | coordinates as defined in Section 6.2.1 of | | | [RFC6234]. The JWK encoding of NIST P-256 |
| | [RFC7518]. | | | public key is defined in [RFC7518]. For |
+-------------+-----------------------------------------------------+ | | clarity, the "crv" parameter is "P-256", the |
| | "kty" parameter is "EC", and the public-key |
| | encoding has both an x and y coordinate, as |
| | defined in Section 6.2.1 of [RFC7518]. |
+-------------+-----------------------------------------------+
Table 8: EAP-NOOB cryptosuites Table 8: EAP-NOOB Cryptosuites
EAP-NOOB implementations MUST support Cryptosuite 1. Support for EAP-NOOB implementations MUST support Cryptosuite 1. Support for
Cryptosuite 2 is RECOMMENDED. An example of Cryptosuite 1 public-key Cryptosuite 2 is RECOMMENDED. An example of a Cryptosuite 1 public-
encoded as a JWK object is given below (line breaks are for key encoded as a JWK object is given below. (Line breaks are for
readability only). readability only.)
"jwk":{"kty":"OKP","crv":"X25519","x":"3p7bfXt9wbTTW2HC7OQ1Nz- "jwk":{"kty":"OKP","crv":"X25519","x":"3p7bfXt9wbTTW2HC7OQ1Nz-
DQ8hbeGdNrfx-FG-IK08"} DQ8hbeGdNrfx-FG-IK08"}
Assignment of new values for new cryptosuites MUST be done through Assignment of new values for new cryptosuites MUST be done through
IANA with "Specification Required" as defined in [RFC8126]. IANA with "Specification Required", as defined in [RFC8126].
5.2. Message Types 5.2. Message Types
IANA is requested to create and maintain a new sub-registry entitled IANA has created and will maintain a new subregistry entitled "EAP-
"EAP-NOOB Message Types" in the "Nimble out-of-band authentication NOOB Message Types" in the "Nimble Out-of-Band Authentication for EAP
for EAP Parameters" registry. EAP-NOOB request and response pairs Parameters (EAP-NOOB)" registry. EAP-NOOB request and response pairs
are identified by an integer Message Type. The initial values for are identified by an integer Message Type. The initial values for
this registry are: this registry are:
+----------+------------+-------------------------------------------+ +=========+============+========================================+
| Message | Used in | Purpose | | Message | Used in | Purpose |
| Type | Exchange | | | Type | Exchange | |
+----------+------------+-------------------------------------------+ +=========+============+========================================+
| 1 | All | PeerId and PeerState discovery | | 0 | Error | Error notification |
| | exchanges | | +---------+------------+----------------------------------------+
| | | | | 1 | All | PeerId and PeerState discovery |
| 2 | Initial | Version, cryptosuite and parameter | | | exchanges | |
| | | negotiation | +---------+------------+----------------------------------------+
| | | | | 2 | Initial | Version, cryptosuite, and parameter |
| 3 | Initial | Exchange of ECDHE keys and nonces | | | | negotiation |
| | | | +---------+------------+----------------------------------------+
| 4 | Waiting | Indication to peer that the server has | | 3 | Initial | Exchange of ECDHE keys and nonces |
| | | not yet received an OOB message | +---------+------------+----------------------------------------+
| | | | | 4 | Waiting | Indication to the peer that the server |
| 5 | Completion | NoobId discovery | | | | has not yet received an OOB message |
| | | | +---------+------------+----------------------------------------+
| 6 | Completion | Authentication and key confirmation with | | 5 | Completion | NoobId discovery |
| | | HMAC | +---------+------------+----------------------------------------+
| | | | | 6 | Completion | Authentication and key confirmation |
| 7 | Reconnect | Version, cryptosuite, and parameter | | | | with HMAC |
| | | negotiation | +---------+------------+----------------------------------------+
| | | | | 7 | Reconnect | Version, cryptosuite, and parameter |
| 8 | Reconnect | Exchange of ECDHE keys and nonces | | | | negotiation |
| | | | +---------+------------+----------------------------------------+
| 9 | Reconnect | Authentication and key confirmation with | | 8 | Reconnect | Exchange of ECDHE keys and nonces |
| | | HMAC | +---------+------------+----------------------------------------+
| | | | | 9 | Reconnect | Authentication and key confirmation |
| 0 | Error | Error notification | | | | with HMAC |
| | | | +---------+------------+----------------------------------------+
+----------+------------+-------------------------------------------+
Table 9: EAP-NOOB Message Types Table 9: EAP-NOOB Message Types
Assignment of new values for new Message Types MUST be done through Assignment of new values for new Message Types MUST be done through
IANA with "Specification Required" as defined in [RFC8126]. IANA with "Specification Required", as defined in [RFC8126].
5.3. Error codes 5.3. Error Codes
IANA is requested to create and maintain a new sub-registry entitled IANA has created and will maintain a new subregistry entitled "EAP-
"EAP-NOOB Error codes" in the "Nimble out-of-band authentication for NOOB Error codes" in the "Nimble Out-of-Band Authentication for EAP
EAP Parameters" registry. Cryptosuites are identified by an integer. Parameters (EAP-NOOB)" registry. Cryptosuites are identified by an
The initial values for this registry are: integer. The initial values for this registry are:
+------------+----------------------------------------+ +============+===========================================+
| Error code | Purpose | | Error code | Purpose |
+------------+----------------------------------------+ +============+===========================================+
| 1001 | Invalid NAI | | 1001 | Invalid NAI |
| 1002 | Invalid message structure | +------------+-------------------------------------------+
| 1003 | Invalid data | | 1002 | Invalid message structure |
| 1004 | Unexpected message type | +------------+-------------------------------------------+
| 1005 | Invalid ECDHE key | | 1003 | Invalid data |
| 2001 | Unwanted peer | +------------+-------------------------------------------+
| 2002 | State mismatch, user action required | | 1004 | Unexpected message type |
| 2003 | Unrecognized OOB message identifier | +------------+-------------------------------------------+
| 2004 | Unexpected peer identifier | | 1005 | Invalid ECDHE key |
| 3001 | No mutually supported protocol version | +------------+-------------------------------------------+
| 3002 | No mutually supported cryptosuite | | 2001 | Unwanted peer |
| 3003 | No mutually supported OOB direction | +------------+-------------------------------------------+
| 4001 | HMAC verification failure | | 2002 | State mismatch, user action required |
| 5001 | Application-specific error | +------------+-------------------------------------------+
| 5002 | Invalid server info | | 2003 | Unrecognized OOB message identifier |
| 5003 | Invalid server URL | +------------+-------------------------------------------+
| 5004 | Invalid peer info | | 2004 | Unexpected peer identifier |
| 6001-6999 | Private and experimental use | +------------+-------------------------------------------+
+------------+----------------------------------------+ | 3001 | No mutually supported protocol version |
+------------+-------------------------------------------+
| 3002 | No mutually supported cryptosuite |
+------------+-------------------------------------------+
| 3003 | No mutually supported OOB direction |
+------------+-------------------------------------------+
| 4001 | HMAC verification failure |
+------------+-------------------------------------------+
| 5001 | Application-specific error |
+------------+-------------------------------------------+
| 5002 | Invalid server info |
+------------+-------------------------------------------+
| 5003 | Invalid server URL |
+------------+-------------------------------------------+
| 5004 | Invalid peer info |
+------------+-------------------------------------------+
| 6001-6999 | Reserved for Private and Experimental Use |
+------------+-------------------------------------------+
Table 10: EAP-NOOB error codes Table 10: EAP-NOOB Error Codes
Assignment of new error codes MUST be done through IANA with Assignment of new error codes MUST be done through IANA with
"Specification Required" as defined in [RFC8126], except for the "Specification Required", as defined in [RFC8126], except for the
range 6001-6999. This range is reserved for "Private Use" and range 6001-6999. This range is reserved for "Private Use" and
"Experimental Use", both locally and on the open Internet. "Experimental Use", both locally and on the open Internet.
5.4. ServerInfo data fields 5.4. ServerInfo Data Fields
IANA is requested to create and maintain a new sub-registry entitled IANA has created and will maintain a new subregistry entitled "EAP-
"EAP-NOOB ServerInfo data fields" in the "Nimble out-of-band NOOB ServerInfo Data Fields" in the "Nimble Out-of-Band
authentication for EAP Parameters" registry. The initial values for Authentication for EAP Parameters (EAP-NOOB)" registry. The initial
this registry are: values for this registry are:
+----------------+--------------------+ +================+=====================+
| Data Field | Specification | | Data Field | Specification |
+----------------+--------------------+ +================+=====================+
| Type | This RFC Section 4 | | Type | RFC 9140, Section 4 |
| | | +----------------+---------------------+
| ServerName | This RFC Section 4 | | ServerName | RFC 9140, Section 4 |
| | | +----------------+---------------------+
| ServerURL | This RFC Section 4 | | ServerURL | RFC 9140, Section 4 |
| | | +----------------+---------------------+
| SSIDList | This RFC Section 4 | | SSIDList | RFC 9140, Section 4 |
| | | +----------------+---------------------+
| Base64SSIDList | This RFC Section 4 | | Base64SSIDList | RFC 9140, Section 4 |
+----------------+--------------------+ +----------------+---------------------+
Table 11: ServerInfo data fields Table 11: ServerInfo Data Fields
Assignment of new values for new ServerInfo data fields MUST be done Assignment of new values for new ServerInfo data fields MUST be done
through IANA with "Specification Required" as defined in [RFC8126]. through IANA with "Specification Required", as defined in [RFC8126].
5.5. PeerInfo data fields 5.5. PeerInfo Data Fields
IANA is requested to create and maintain a new sub-registry entitled IANA is requested to create and maintain a new subregistry entitled
"EAP-NOOB PeerInfo data fields" in the "Nimble out-of-band "EAP-NOOB PeerInfo Data Fields" in the "Nimble Out-of-Band
authentication for EAP Parameters" registry. The initial values for Authentication for EAP Parameters (EAP-NOOB)" registry. The initial
this registry are: values for this registry are:
+--------------+--------------------+ +==============+=====================+
| Data Field | Specification | | Data Field | Specification |
+--------------+--------------------+ +==============+=====================+
| Type | This RFC Section 4 | | Type | RFC 9140, Section 4 |
| | | +--------------+---------------------+
| PeerName | This RFC Section 4 | | PeerName | RFC 9140, Section 4 |
| | | +--------------+---------------------+
| Manufacturer | This RFC Section 4 | | Manufacturer | RFC 9140, Section 4 |
| | | +--------------+---------------------+
| Model | This RFC Section 4 | | Model | RFC 9140, Section 4 |
| | | +--------------+---------------------+
| SerialNumber | This RFC Section 4 | | SerialNumber | RFC 9140, Section 4 |
| | | +--------------+---------------------+
| MACAddress | This RFC Section 4 | | MACAddress | RFC 9140, Section 4 |
| | | +--------------+---------------------+
| SSID | This RFC Section 4 | | SSID | RFC 9140, Section 4 |
| | | +--------------+---------------------+
| Base64SSID | This RFC Section 4 | | Base64SSID | RFC 9140, Section 4 |
| | | +--------------+---------------------+
| BSSID | This RFC Section 4 | | BSSID | RFC 9140, Section 4 |
| | | +--------------+---------------------+
+--------------+--------------------+
Table 12: PeerInfo data fields Table 12: PeerInfo Data Fields
Assignment of new values for new PeerInfo data fields MUST be done Assignment of new values for new PeerInfo data fields MUST be done
through IANA with "Specification Required" as defined in [RFC8126]. through IANA with "Specification Required", as defined in [RFC8126].
5.6. Domain name reservation 5.6. Domain Name Reservation
The special-use domain "eap-noob.arpa" should be registered in the The special-use domain "eap-noob.arpa" has been registered in the
.arpa registry (<https://www.iana.org/domains/arpa>). No A, AAAA, or .arpa registry (https://www.iana.org/domains/arpa) and the "Special-
PTR records are requested. Use Domain Names" registry (https://www.iana.org/assignments/special-
use-domain-names).
5.7. Guidance for Designated Experts 5.7. Guidance for Designated Experts
Experts SHOULD be conservative in the allocation of new Cryptosuites. Experts SHOULD be conservative in the allocation of new Cryptosuites.
Experts MUST ascertain that the requested values match the current Experts MUST ascertain that the requested values match the current
Crypto Forum Research Group (CFRG) guidance on cryptographic Crypto Forum Research Group (CFRG) guidance on cryptographic
algorithm security. Experts MUST ensure that any new Cryptosuites algorithm security. Experts MUST ensure that any new Cryptosuites
fully specify the encoding of the ECDHE public key and should include fully specify the encoding of the ECDHE public key and should include
details such as the value of "kty" (key type) parameter when JWK details, such as the value of the "kty" (key type) parameter when JWK
[RFC7517] encoding is used. [RFC7517] encoding is used.
Experts SHOULD be conservative in the allocation of new Message Experts SHOULD be conservative in the allocation of new Message
Types. Experts SHOULD ascertain that a well-defined specification Types. Experts SHOULD ascertain that a well-defined specification
for the new Message Type is permanently and publicly available. for the new Message Type is permanently and publicly available.
Experts SHOULD be conservative in the allocation of new Error codes Experts SHOULD be conservative in the allocation of new Error codes,
since the 6001-6999 range is already allocated for private and since the 6001-6999 range is already reserved for private and
experimental use. experimental use.
Experts MAY be liberal in the allocation of new ServerInfo and Experts MAY be liberal in the allocation of new ServerInfo and
PeerInfo data fields. Experts MUST ensure that the Data Field PeerInfo data fields. Experts MUST ensure that the data field
requested has a unique name that is not easily confused with existing requested has a unique name that is not easily confused with existing
registrations. For example, requests for a new PeerInfo data field registrations. For example, requests for a new PeerInfo data field
"ssid" should be rejected even though it is unique because it can be "ssid" should be rejected even though it is unique because it can be
confused with the existing registration of "SSID". Experts MUST confused with the existing registration of "SSID". Experts MUST
ensure that a suitable Description for the data field is available. ensure that a suitable Description for the data field is available.
6. Implementation Status 6. Security Considerations
Note to RFC Editor: Please remove this entire section and the
reference to RFC7942 before publication.
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist.
6.1. Implementation with wpa_supplicant and hostapd
o Responsible Organization: Aalto University
o Location: <https://github.com/tuomaura/eap-noob>
o Coverage: This implementation includes all the features described
in the current specification. The implementation supports two-
dimensional QR codes and NFC as example out-of-band (OOB)
channels.
o Level of Maturity: Alpha
o Version compatibility: Version 08 of the individual draft
implemented
o Licensing: BSD
o Contact Information: Tuomas Aura, tuomas.aura@aalto.fi
6.2. Implementation on Contiki
o Responsible Organization: University of Murcia and Aalto
University
o Location: <https://github.com/eduingles/coap-eap-noob>
o Coverage: This implementation includes all the features described
in the current specification. The implementation uses a blinking
LED light as the out-of-band (OOB) channel.
o Level of Maturity: Alpha
o Version compatibility: Version 06 of the draft implemented
o Licensing: BSD
o Contact Information: Eduardo Ingles, eduardo.ingles@um.es
6.3. Implementation with wpa_supplicant and hostapd
o Responsible Organization: Ericsson
o Location: <https://github.com/Vogeltak/hostap>
o Coverage: This implementation is the most up-to-date one. The
implementation only provides a minimal API interface for
transferring OOB messages.
o Level of Maturity: Alpha
o Version compatibility: Version 02 of the working group adopted
draft is implemented
o Licensing: BSD
6.4. Protocol modeling
The current EAP-NOOB specification has been modeled with the mCRL2
formal specification language [mcrl2]. The model [noob-mcrl2] was
used mainly for simulating the protocol behavior and for verifying
basic safety and liveness properties as part of the specification
process. For example, we verified the correctness of the tiebreaking
mechanism when two OOB messages are received simultaneously, one in
each direction. We also verified that an on-path attacker cannot
cause persistent failure by spoofing a finite number of messages in
the Reconnect Exchange. Additionally, the protocol has been modeled
with the ProVerif [proverif] tool. This model [noob-proverif] was
used to verify security properties such as mutual authentication.
7. Security considerations
EAP-NOOB is an authentication and key derivation protocol and, thus, EAP-NOOB is an authentication and key derivation protocol; thus,
security considerations can be found in most sections of this security considerations can be found in most sections of this
specification. In the following, we explain the protocol design and specification. In the following, we explain the protocol design and
highlight some other special considerations. highlight some other special considerations.
7.1. Authentication principle 6.1. Authentication Principle
EAP-NOOB establishes a shared secret with an authenticated ECDHE key EAP-NOOB establishes a shared secret with an authenticated ECDHE key
exchange. The mutual authentication in EAP-NOOB is based on two exchange. The mutual authentication in EAP-NOOB is based on two
separate features, both conveyed in the OOB message. The first separate features, both conveyed in the OOB message. The first
authentication feature is the secret nonce Noob. The peer and server authentication feature is the secret nonce Noob. The peer and server
use this secret in the Completion Exchange to mutually authenticate use this secret in the Completion Exchange to mutually authenticate
the session key previously created with ECDHE. The message the session key previously created with ECDHE. The message
authentication codes computed with the secret nonce Noob are alone authentication codes computed with the secret nonce Noob are alone
sufficient for authenticating the key exchange. The second sufficient for authenticating the key exchange. The second
authentication feature is the integrity-protecting fingerprint Hoob. authentication feature is the integrity-protecting fingerprint Hoob.
skipping to change at page 45, line 32 skipping to change at line 2013
passphrase that is shared by all the network stations. The advantage passphrase that is shared by all the network stations. The advantage
of an EAP-based solution, including EAP-NOOB, is that it establishes of an EAP-based solution, including EAP-NOOB, is that it establishes
a different shared secret for each peer device, which makes the a different shared secret for each peer device, which makes the
system more resilient against device compromise. Another advantage system more resilient against device compromise. Another advantage
is that it is possible to revoke the security association for an is that it is possible to revoke the security association for an
individual device on the server side. individual device on the server side.
Forward secrecy during fast reconnect in EAP-NOOB is optional. The Forward secrecy during fast reconnect in EAP-NOOB is optional. The
Reconnect Exchange in EAP-NOOB provides forward secrecy only if both Reconnect Exchange in EAP-NOOB provides forward secrecy only if both
the server and peer send their fresh ECDHE keys. This allows both the server and peer send their fresh ECDHE keys. This allows both
the server and the peer to limit the frequency of the costly the server and peer to limit the frequency of the costly computation
computation that is required for forward secrecy. The server MAY that is required for forward secrecy. The server MAY adjust the
adjust the frequency of its attempts at ECDHE rekeying based on what frequency of its attempts at ECDHE rekeying based on what it knows
it knows about the peer's computational capabilities. about the peer's computational capabilities.
Another way in which some servers may control their computational Another way in which some servers may control their computational
load is to reuse the same ECDHE key for all peers over a short 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 server-specific time window. In that case, forward secrecy will be
achieved only after the server updates its ECDHE key, which may be a achieved only after the server updates its ECDHE key, which may be a
reasonable trade-off between security and performance. However, the reasonable trade-off between security and performance. However, the
server MUST NOT reuse the same ECDHE key with the same peer when server MUST NOT reuse the same ECDHE key with the same peer when
rekeying with ECDHE (KeyingMode=2 or KeyingMode=3). Instead, it can rekeying with ECDHE (KeyingMode=2 or KeyingMode=3). Instead, it can
simply not send an ECDHE key (KeyingMode=1). simply not send an ECDHE key (KeyingMode=1).
The users delivering the OOB messages will often authenticate The users delivering the OOB messages will often authenticate
themselves to the EAP server, e.g., by logging into a secure web page themselves to the EAP server, e.g., by logging into a secure web page
or API. In this case, the server can associate the peer device with or API. In this case, the server can associate the peer device with
the user account. Applications that make use of EAP-NOOB can use the user account. Applications that make use of EAP-NOOB can use
this information for configuring the initial owner of the freshly- this information for configuring the initial owner of the freshly
registered device. registered device.
7.2. Identifying correct endpoints 6.2. Identifying Correct Endpoints
Potential weaknesses in EAP-NOOB arise from the fact that the user Potential weaknesses in EAP-NOOB arise from the fact that the user
must identify physically the correct peer device. If the user must physically identify the correct peer device. If the user
mistakenly delivers the OOB message from the wrong peer device to the mistakenly delivers the OOB message from the wrong peer device to the
server, the server may create an association with the wrong peer. server, the server may create an association with the wrong peer.
The reliance on the user in identifying the correct endpoints is an The reliance on the user in identifying the correct endpoints is an
inherent property of user-assisted out-of-band authentication. To inherent property of user-assisted, out-of-band authentication. To
understand the potential consequences of the user mistake, we need to understand the potential consequences of the user mistake, we need to
consider a few different scenarios. In the first scenario, there is consider a few different scenarios. In the first scenario, there is
no malicious party, and the user makes an accidental mistake between no malicious party, and the user makes an accidental mistake between
two out-of-the-box devices that are both ready to be registered to a two out-of-the-box devices that are both ready to be registered to a
server. If the user delivers the OOB message from the wrong device server. If the user delivers the OOB message from the wrong device
to the server, confusion may arise but usually no security issues. to the server, confusion may arise but usually no security issues.
In the second scenario, an attacker intentionally tricks the user, In the second scenario, an attacker intentionally tricks the user,
for example, by substituting the original peer device with a for example, by substituting the original peer device with a
compromised one. This is essentially a supply chain attack where the compromised one. This is essentially a supply chain attack where the
user accepts a compromised physical device. user accepts a compromised physical device.
There is also a third scenario, in which an opportunistic attacker There is also a third scenario, in which an opportunistic attacker
tries to take advantage of the user's accidental mistake. For tries to take advantage of the user's accidental mistake. For
example, the user could play an audio or a blinking LED message to a example, the user could play an audio or a blinking LED message to a
device that is not expecting to receive it. In simple security device that is not expecting to receive it. In simple security
bootstrapping solutions that transfer a master key to the device via bootstrapping solutions that transfer a primary key to the device via
the OOB channel, the device could misuse or leak the accidentally the OOB channel, the device could misuse or leak the accidentally
received master key. EAP-NOOB is not vulnerable to such received primary key. EAP-NOOB is not vulnerable to such
opportunistic attackers because the OOB message has no value to opportunistic attackers because the OOB message has no value to
anyone who did not take part in the corresponding Initial Exchange. anyone who did not take part in the corresponding Initial Exchange.
One mechanism that can mitigate user mistakes is certification of One mechanism that can mitigate user mistakes is certification of
peer devices. A certificate or an attestation token peer devices. A certificate or an attestation token (e.g., [TLS-CWT]
(e.g.,[I-D.tschofenig-tls-cwt] and [I-D.ietf-rats-eat]) can convey to and [RATS-EAT]) can convey to the server authentic identifiers and
the server authentic identifiers and attributes, such as model and attributes, such as model and serial number, of the peer device.
serial number, of the peer device. Compared to a fully certificate- Compared to a fully certificate-based authentication, however, EAP-
based authentication, however, EAP-NOOB can be used without trusted NOOB can be used without trusted third parties and does not require
third parties and does not require the user to know any identifier of the user to know any identifier of the peer device; physical access
the peer device; physical access to the device is sufficient for to the device is sufficient for bootstrapping with EAP-NOOB.
bootstrapping with EAP-NOOB.
Similarly, the attacker can try to trick the user into delivering the Similarly, the attacker can try to trick the user into delivering the
OOB message to the wrong server, so that the peer device becomes OOB message to the wrong server so that the peer device becomes
associated with the wrong server. If the EAP server is accessed associated with the wrong server. If the EAP server is accessed
through a web user interface, the attack is akin to phishing attacks through a web user interface, the attack is akin to phishing attacks
where the user is tricked into accessing the wrong URL and wrong web where the user is tricked into accessing the wrong URL and wrong web
page. OOB implementation with a dedicated app on a mobile device, page. OOB implementation with a dedicated app on a mobile device,
which communicates with a server API at a pre-configured URL, can which communicates with a server API at a preconfigured URL, can
protect against such attacks. protect against such attacks.
After the device registration, an attacker could clone the device After the device registration, an attacker could clone the device
identity by copying the keys from the persistent EAP-NOOB association identity by copying the keys from the persistent EAP-NOOB association
into another device. The attacker can be an outsider who gains into another device. The attacker can be an outsider who gains
access to the keys or the device owner who wants to have two devices access to the keys or the device owner who wants to have two devices
matching the same registration. The cloning threats can be mitigated matching the same registration. The cloning threats can be mitigated
by creating the cryptographic keys and storing the persistent EAP- by creating the cryptographic keys and storing the persistent EAP-
NOOB association on the peer device in a secure hardware component NOOB association on the peer device in a secure hardware component
such as a trusted execution environment (TEE). Furthermore, remote such as a trusted execution environment (TEE). Furthermore, remote
attestation on the application level could provide assurance to the attestation on the application level could provide assurance to the
server that the device has not been cloned. Reconnect Exchange with server that the device has not been cloned. Reconnect Exchange with
a new cryptosuite (KeyingMode=3) will also disconnect all but the a new cryptosuite (KeyingMode=3) will also disconnect all but the
first clone that performs the update. first clone that performs the update.
7.3. Trusted path issues and misbinding attacks 6.3. Trusted Path Issues and Misbinding Attacks
Another potential threat is spoofed user input or output on the peer Another potential threat is spoofed user input or output on the peer
device. When the user is delivering the OOB message to or from the device. When the user is delivering the OOB message to or from the
correct peer device, a trusted path between the user and the peer correct peer device, a trusted path between the user and the peer
device is needed. That is, the user must communicate directly with device is needed. That is, the user must communicate directly with
an authentic operating system and EAP-NOOB implementation in the peer an authentic operating system and EAP-NOOB implementation in the peer
device and not with a spoofed user interface. Otherwise, a device and not with a spoofed user interface. Otherwise, a
registered device that is under the control of the attacker could registered device that is under the control of the attacker could
emulate the behavior of an unregistered device. The secure path can emulate the behavior of an unregistered device. The secure path can
be implemented, for example, by having the user press a reset button be implemented, for example, by having the user press a reset button
to return the device to the Unregistered state and to invoke a to return the device to the Unregistered (0) state and to invoke a
trusted UI. The problem with such trusted paths is that they are not trusted UI. The problem with such trusted paths is that they are not
standardized across devices. standardized across devices.
Another potential consequence of a spoofed UI is the misbinding Another potential consequence of a spoofed UI is the misbinding
attack where the user tries to register a correct but compromised attack where the user tries to register a correct but compromised
device, which tricks the user into registering another device, which tricks the user into registering another
(uncompromised) device instead. For example, the compromised device (uncompromised) device instead. For example, the compromised device
might have a malicious full-screen app running, which presents to the might have a malicious, full-screen app running, which presents to
user QR codes copied, in real time, from another device's screen. If the user QR codes copied, in real time, from another device's screen.
the unwitting user scans the QR code and delivers the OOB message in If the unwitting user scans the QR code and delivers the OOB message
it to the server, the wrong device may become registered in the in it to the server, the wrong device may become registered in the
server. Such misbinding vulnerabilities arise because the user does server. Such misbinding vulnerabilities arise because the user does
not have any secure way of verifying that the in-band cryptographic not have any secure way of verifying that the in-band cryptographic
handshake and the out-of-band physical access are terminated at the handshake and the out-of-band physical access are terminated at the
same physical device. Sethi et al. [Sethi19] analyze the misbinding same physical device. Sethi et al. [Sethi19] analyze the misbinding
threat against device-pairing protocols and also EAP-NOOB. threat against device-pairing protocols and also EAP-NOOB.
Essentially, all protocols where the authentication relies on the Essentially, all protocols where the authentication relies on the
user's physical access to the device are vulnerable to misbinding, user's physical access to the device are vulnerable to misbinding,
including EAP-NOOB. including EAP-NOOB.
A standardized trusted path for communicating directly with the A standardized trusted path for communicating directly with the
trusted computing base in a physical device would mitigate the trusted computing base in a physical device would mitigate the
misbinding threat, but such paths rarely exist in practice. Careful misbinding threat, but such paths rarely exist in practice. Careful
asset tracking on the server side can also prevent most misbinding asset tracking on the server side can also prevent most misbinding
attacks if the peer device sends its identifiers or attributes in the attacks if the peer device sends its identifiers or attributes in the
PeerInfo field and the server compares them with the expected values. PeerInfo field and the server compares them with the expected values.
The wrong but uncompromised device's PeerInfo will not match the The wrong but uncompromised device's PeerInfo will not match the
expected values. Device certification by the manufacturer can expected values. Device certification by the manufacturer can
further strengthen the asset tracking. further strengthen the asset tracking.
7.4. Peer identifiers and attributes 6.4. Peer Identifiers and Attributes
The PeerId value in the protocol is a server-allocated identifier for The PeerId value in the protocol is a server-allocated identifier for
its association with the peer and SHOULD NOT be shown to the user its association with the peer and SHOULD NOT be shown to the user
because its value is initially ephemeral. Since the PeerId is because its value is initially ephemeral. Since the PeerId is
allocated by the server and the scope of the identifier is the single allocated by the server and the scope of the identifier is the single
server, the so-called identifier squatting attacks, where a malicious server, the so-called identifier squatting attacks, where a malicious
peer could reserve another peer's identifier, are not possible in peer could reserve another peer's identifier, are not possible in
EAP-NOOB. The server SHOULD assign a random or pseudo-random PeerId EAP-NOOB. The server SHOULD assign a random or pseudorandom PeerId
to each new peer. It SHOULD NOT select the PeerId based on any peer to each new peer. It SHOULD NOT select the PeerId based on any peer
characteristics that it may know, such as the peer's link-layer characteristics that it may know, such as the peer's link-layer
network address. network address.
User reset or failure in the OOB Step can cause the peer to perform User reset or failure in the OOB Step can cause the peer to perform
many Initial Exchanges with the server, which allocates many PeerId many Initial Exchanges with the server, which allocates many PeerId
values and stores the ephemeral protocol state for them. The peer values and stores the ephemeral protocol state for them. The peer
will typically only remember the latest ones. EAP-NOOB leaves it to will typically only remember the latest ones. EAP-NOOB leaves it to
the implementation to decide when to delete these ephemeral the implementation to decide when to delete these ephemeral
associations. There is no security reason to delete them early, and associations. There is no security reason to delete them early, and
the server does not have any way to verify that the peers are the server does not have any way to verify that the peers are
actually the same one. Thus, it is safest to store the ephemeral 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 states on the server for at least one day. If the OOB messages are
sent only in the server-to-peer direction, the server SHOULD NOT sent only in the server-to-peer direction, the server SHOULD NOT
delete the ephemeral state before all the related Noob values have delete the ephemeral state before all the related Noob values have
expired. expired.
After completion of EAP-NOOB, the server may store the PeerInfo data, 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 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 as the make and model or serial number. A compromised peer could lie
in the PeerInfo which it sends to the server. If the server stores in the PeerInfo that it sends to the server. If the server stores
any information about the peer, it is important that this information any information about the peer, it is important that this information
is approved by the user during or after the OOB Step. Without is approved by the user during or after the OOB Step. Without
verification by the user or authentication on the application level, verification by the user or authentication on the application level,
the PeerInfo is not authenticated information and should not be the PeerInfo is not authenticated information and should not be
relied on. One possible use for the PeerInfo field is EAP channel relied on. One possible use for the PeerInfo field is EAP channel
binding (see Section 7.7). binding (see Section 6.7).
7.5. Downgrading threats 6.5. Downgrading Threats
The fingerprint Hoob protects all the information exchanged in the The fingerprint Hoob protects all the information exchanged in the
Initial Exchange, including the cryptosuite negotiation. The message Initial Exchange, including the cryptosuite negotiation. The message
authentication codes MACs and MACp also protect the same information. authentication codes MACs and MACp also protect the same information.
The message authentication codes MACs2 and MACp2 protect information The message authentication codes MACs2 and MACp2 protect information
exchanged during key renegotiation in the Reconnect Exchange. This exchanged during key renegotiation in the Reconnect Exchange. This
prevents downgrading attacks to weaker cryptosuites as long as the prevents downgrading attacks to weaker cryptosuites, as long as the
possible attacks take more time than the maximum time allowed for the possible attacks take more time than the maximum time allowed for the
EAP-NOOB completion. This is typically the case for recently EAP-NOOB completion. This is typically the case for recently
discovered cryptanalytic attacks. discovered cryptanalytic attacks.
As an additional precaution, the EAP server and peer MUST check for As an additional precaution, the EAP server and peer MUST check for
downgrading attacks in the Reconnect Exchange as follows. As long as downgrading attacks in the Reconnect Exchange as follows. As long as
the server or peer saves any information about the other endpoint, it the server or peer saves any information about the other endpoint, it
MUST also remember the previously negotiated cryptosuite and MUST NOT MUST also remember the previously negotiated cryptosuite and MUST NOT
accept renegotiation of any cryptosuite that is known to be weaker accept renegotiation of any cryptosuite that is known to be weaker
than the previous one, such as a deprecated cryptosuite. Determining than the previous one, such as a deprecated cryptosuite. Determining
the relative strength of the cryptosuites is out of scope of this the relative strength of the cryptosuites is out of scope of this
specification and may be managed by implementations or by local specification and may be managed by implementations or by local
policies at the peer and server. policies at the peer and server.
Integrity of the direction negotiation cannot be verified in the same Integrity of the direction negotiation cannot be verified in the same
way as the integrity of the cryptosuite negotiation. That is, if the way as the integrity of the cryptosuite negotiation. That is, if the
OOB channel used in an application is critically insecure in one OOB channel used in an application is critically insecure in one
direction, an on-path attacker could modify the negotiation messages direction, an on-path attacker could modify the negotiation messages
and thereby cause that direction to be used. Applications that and thereby cause that direction to be used. Applications that
support OOB messages in both directions SHOULD therefore ensure that support OOB messages in both directions SHOULD, therefore, ensure
the OOB channel has sufficiently strong security in both directions. that the OOB channel has sufficiently strong security in both
While this is a theoretical vulnerability, it could arise in practice directions. While this is a theoretical vulnerability, it could
if EAP-NOOB is deployed in new applications. Currently, we expect arise in practice if EAP-NOOB is deployed in new applications.
most peer devices to support only one OOB direction, in which case Currently, we expect most peer devices to support only one OOB
interfering with the direction negotiation can only prevent the direction; in which case, interfering with the direction negotiation
completion of the protocol. can only prevent the completion of the protocol.
The long-term shared key material Kz in the persistent EAP-NOOB The long-term shared key material Kz in the persistent EAP-NOOB
association is established with an ECDHE key exchange when the peer association is established with an ECDHE key exchange when the peer
and server are first associated. It is a weaker secret than a and server are first associated. It is a weaker secret than a
manually configured random shared key because advances in manually configured random shared key because advances in
cryptanalysis against the used ECDHE curve could eventually enable cryptanalysis against the used ECDHE curve could eventually enable
the attacker to recover Kz. EAP-NOOB protects against such attacks the attacker to recover Kz. EAP-NOOB protects against such attacks
by allowing cryptosuite upgrades in the Reconnect Exchange and by by allowing cryptosuite upgrades in the Reconnect Exchange and by
updating the shared key material Kz whenever the cryptosuite is updating the shared key material Kz whenever the cryptosuite is
upgraded. We do not expect the cryptosuite upgrades to be frequent, upgraded. We do not expect the cryptosuite upgrades to be frequent,
but if an upgrade becomes necessary, it can be done without manual but, if an upgrade becomes necessary, it can be done without manual
reset and reassociation of the peer devices. reset and reassociation of the peer devices.
7.6. Protected success and failure indications 6.6. Protected Success and Failure Indications
Section 7.16 of [RFC3748] allows EAP methods to specify protected Section 7.16 of [RFC3748] allows EAP methods to specify protected
result indications because EAP-Success and EAP-Failure packets are result indications because EAP-Success and EAP-Failure packets are
neither acknowledged nor integrity protected. [RFC3748] notes that neither acknowledged nor integrity protected. [RFC3748] notes that
these indications may be explicit or implicit. these indications may be explicit or implicit.
EAP-NOOB relies on implicit protected success indicators in the EAP-NOOB relies on implicit, protected success indicators in the
Completion and Reconnect exchange. Successful verification of MACs Completion Exchange and Reconnect Exchange. Successful verification
and MACs2 in the EAP-Request message from the server (message type 6 of MACs and MACs2 in the EAP-Request message from the server (message
and message type 9, respectively) acts as an implicit protected type 6 and message type 9, respectively) acts as an implicit,
success indication to the peer. Similarly, successful verification protected success indication to the peer. Similarly, successful
of MACp and MACp2 in the EAP-Response message from the peer (message verification of MACp and MACp2 in the EAP-Response message from the
type 6 and message type 9, respectively) act as an implicit protected peer (message type 6 and message type 9, respectively) act as an
success indication to the server. implicit, protected success indication to the server.
EAP-NOOB failure messages are not protected. Protected failure EAP-NOOB failure messages are not protected. Protected failure
result indications would not significantly improve availability since result indications would not significantly improve availability since
EAP-NOOB reacts to most malformed data by ending the current EAP EAP-NOOB reacts to most malformed data by ending the current EAP
conversation in EAP-Failure. However, since EAP-NOOB spans multiple conversation in EAP-Failure. However, since EAP-NOOB spans multiple
conversations, failure in one conversation usually means no state conversations, failure in one conversation usually means no state
change on the level of the EAP-NOOB state machine. change on the level of the EAP-NOOB state machine.
7.7. Channel Binding 6.7. Channel Binding
EAP channel binding, defined in [RFC6677], means that the endpoints EAP channel binding, defined in [RFC6677], means that the endpoints
compare their perceptions of network properties, such as lower-layer compare their perceptions of network properties, such as lower-layer
identifiers, over the secure channel established by EAP identifiers, over the secure channel established by EAP
authentication. Section 4.1 of [RFC6677] defines two approaches to authentication. Section 4.1 of [RFC6677] defines two approaches to
channel binding. EAP-NOOB follows the first approach, in which the channel binding. EAP-NOOB follows the first approach, in which the
peer and server exchange plaintext information about the network over peer and server exchange plaintext information about the network over
a channel that is integrity protected with keys derived during the a channel that is integrity protected with keys derived during the
EAP execution. More specifically, channel information is exchanged EAP execution. More specifically, channel information is exchanged
in the plaintext PeerInfo and ServerInfo objects and is later in the plaintext PeerInfo and ServerInfo objects and is later
verified with message authentication codes (MACp, MACs, MACp2, verified with message authentication codes (MACp, MACs, MACp2, and
MACs2). This allows policy-based comparison with locally perceived MACs2). This allows policy-based comparison with locally perceived
network properties on either side, as well as logging for debugging network properties on either side, as well as logging for debugging
purposes. The peer MAY include in PeerInfo any data items that it purposes. The peer MAY include in PeerInfo any data items that it
wants to bind to the EAP-NOOB association and to the exported keys. wants to bind to the EAP-NOOB association and to the exported keys.
These can be properties of the authenticator or the access link, such These can be properties of the authenticator or the access link, such
as the SSID and BSSID of the wireless network (see Table 6). As as the SSID and BSSID of the wireless network (see Table 6). As
noted in Section 4.3 of [RFC6677], the scope of the channel binding noted in Section 4.3 of [RFC6677], the scope of the channel binding
varies between deployments. For example, the server may have less varies between deployments. For example, the server may have less
link-layer information available from roaming networks than from a link-layer information available from roaming networks than from a
local enterprise network, and it may be unable to verify all the local enterprise network, and it may be unable to verify all the
network properties received in PeerInfo. There are also privacy network properties received in PeerInfo. There are also privacy
considerations related to exchanging the ServerInfo and PeerInfo considerations related to exchanging the ServerInfo and PeerInfo
while roaming (see Section 7.10). while roaming (see Section 6.10).
Channel binding to secure channels, defined in [RFC5056], binds Channel binding to secure channels, defined in [RFC5056], binds
authentication at a higher protocol layer to a secure channel at a authentication at a higher protocol layer to a secure channel at a
lower layer. Like most EAP methods, EAP-NOOB exports the session lower layer. Like most EAP methods, EAP-NOOB exports the session
keys MSK and EMSK, and an outer tunnel or a higher-layer protocol can keys MSK and EMSK, and an outer tunnel or a higher-layer protocol can
bind its authentication to these keys. Additionally, EAP-NOOB bind its authentication to these keys. Additionally, EAP-NOOB
exports the key AMSK, which may be used to bind application-layer exports the key AMSK, which may be used to bind application-layer
authentication to the secure channel created by EAP-NOOB and to the authentication to the secure channel created by EAP-NOOB and to the
session keys MSK and EMSK. session keys MSK and EMSK.
7.8. Denial of Service 6.8. Denial of Service
While denial-of-service (DoS) attacks by on-link attackers cannot be While denial-of-service (DoS) attacks by on-link attackers cannot be
fully prevented, the design goal in EAP-NOOB is to void long-lasting fully prevented, the design goal in EAP-NOOB is to void long-lasting
failure caused by an attacker who is present only temporarily or failure caused by an attacker who is present only temporarily or
intermittently. The main defense mechanism is the persistent EAP- intermittently. The main defense mechanism is the persistent EAP-
NOOB association, which is never deleted automatically due to in-band NOOB association, which is never deleted automatically due to in-band
messages or error indications. Thus, the endpoints can always use messages or error indications. Thus, the endpoints can always use
the persistent association for reconnecting after the DoS attacker the persistent association for reconnecting after the DoS attacker
leaves the network. In this sense, the persistent association serves leaves the network. In this sense, the persistent association serves
the same function in EAP-NOOB as a permanent master key or the same function in EAP-NOOB as a permanent primary key or
certificate in other authentication protocols. We discuss logical certificate in other authentication protocols. We discuss logical
attacks against the updates of the persistent association in attacks against the updates of the persistent association in
Section 7.9. Section 6.9.
In addition to logical DoS attacks, it is necessary to consider In addition to logical DoS attacks, it is necessary to consider
resource exhaustion attacks against the EAP server. The number of resource exhaustion attacks against the EAP server. The number of
persistent EAP-NOOB associations created in the server is limited by persistent EAP-NOOB associations created in the server is limited by
the need for a user to assist in delivering the OOB message. The the need for a user to assist in delivering the OOB message. The
users can be authenticated for the input or output of the OOB message users can be authenticated for the input or output of the OOB message
at the EAP server, and any users who create excessive numbers of at the EAP server, and any users who create excessive numbers of
persistent associations can be held accountable and their persistent associations can be held accountable and their
associations can be deleted by the server administrator. What the associations can be deleted by the server administrator. What the
attacker can do without user authentication is to perform the Initial attacker can do without user authentication is to perform the Initial
Exchange repeatedly and create a large number of ephemeral Exchange repeatedly and create a large number of ephemeral
associations (server in state 1, Waiting for OOB) without ever associations (server in Waiting for OOB (1) state) without ever
delivering the OOB message. Above in Section 7.4, it was suggested delivering the OOB message. In Section 6.4, it was suggested that
that the server should store the ephemeral states for at least a day. the server should store the ephemeral states for at least a day.
This may require off-loading the state storage from memory to disk This may require off-loading the state storage from memory to disk
during a DoS attack. However, if the server implementation is unable during a DoS attack. However, if the server implementation is unable
to keep up with a rate of Initial Exchanges performed by a DoS to keep up with a rate of Initial Exchanges performed by a DoS
attacker and needs to drop some ephemeral states, no damage is caused attacker and needs to drop some ephemeral states, no damage is caused
to already created persistent associations, and the honest users can to already-created persistent associations, and the honest users can
resume registering new peers when the DoS attacker leaves the resume registering new peers when the DoS attacker leaves the
network. network.
There are some trade-offs in the protocol design between polite back- There are some trade-offs in the protocol design between politely
off and giving way to DoS attackers. An on-link DoS attacker could backing off and giving way to DoS attackers. An on-link DoS attacker
spoof the SleepTime value in the Initial Exchange or Waiting Exchange could spoof the SleepTime value in the Initial Exchange or Waiting
to cause denial of service against a specific peer device. There is Exchange to cause denial of service against a specific peer device.
an upper limit on the SleepTime (3600 seconds) to mitigate the There is an upper limit on the SleepTime (3600 seconds) to mitigate
spoofing threat. This means that, in the presence of an on-link DoS the spoofing threat. This means that, in the presence of an on-link
attacker who spoofs the SleepTime, it could take up to one hour after DoS attacker who spoofs the SleepTime, it could take up to one hour
the delivery of the OOB message before the device performs the after the delivery of the OOB message before the device performs the
Completion Exchange and becomes functional. Similarly, the Unwanted Completion Exchange and becomes functional. Similarly, the Unwanted
peer error (error code 2001) could cause the peer to stop connecting peer error (error code 2001) could cause the peer to stop connecting
to the network. If the peer device is able to alert the user about to the network. If the peer device is able to alert the user about
the error condition, it can safely stop connecting to the server and the error condition, it can safely stop connecting to the server and
wait for the user to trigger a reconnection attempt, e.g., by wait for the user to trigger a reconnection attempt, e.g., by
resetting the device. As mentioned in Section 3.6.2, peer devices resetting the device. As mentioned in Section 3.6.2, peer devices
that are unable to alert the user should continue to retry the that are unable to alert the user should continue to retry the
Initial Exchange infrequently to avoid a permanent DoS condition. We Initial Exchange infrequently to avoid a permanent DoS condition. We
believe a maximum backoff time of 3600 seconds is reasonable for a believe a maximum backoff time of 3600 seconds is reasonable for a
new protocol because malfunctioning or misconfigured peer new protocol because malfunctioning or misconfigured peer
implementations are at least as great a concern as DoS attacks, and implementations are at least as great a concern as DoS attacks, and
politely backing off within some reasonable limits will increase the politely backing off within some reasonable limits will increase the
acceptance of the protocol. The maximum backoff times could be acceptance of the protocol. The maximum backoff times could be
updated to be shorter as the protocol implementations mature. updated to be shorter as the protocol implementations mature.
7.9. Recovery from loss of last message 6.9. Recovery from Loss of Last Message
The EAP-NOOB Completion Exchange, as well as the Reconnect Exchange The EAP-NOOB Completion Exchange, as well as the Reconnect Exchange
with cryptosuite update, result in a persistent state change that with cryptosuite update, results in a persistent state change that
should take place either on both endpoints or on neither; otherwise, should take place either on both endpoints or on neither; otherwise,
the result is a state mismatch that requires user action to resolve. the result is a state mismatch that requires user action to resolve.
The state mismatch can occur if the final EAP response of the The state mismatch can occur if the final EAP response of the
exchanges is lost. In the Completion Exchange, the loss of the final exchanges is lost. In the Completion Exchange, the loss of the final
response (Type=6) results in the peer moving to Registered (4) state response (Type=6) results in the peer moving to the Registered (4)
and creating a persistent EAP-NOOB association while the server stays state and creating a persistent EAP-NOOB association while the server
in an ephemeral state (1 or 2). In the Reconnect Exchange, the loss stays in an ephemeral state (1 or 2). In the Reconnect Exchange, the
of the final response (Type=9) results in the peer moving to the loss of the final response (Type=9) results in the peer moving to the
Registered (4) state and updating its persistent key material Kz Registered (4) state and updating its persistent key material Kz
while the server stays in the Reconnecting (3) state and keeps the while the server stays in the Reconnecting (3) state and keeps the
old key material. old key material.
The state mismatch is an example of an unavoidable problem in The state mismatch is an example of an unavoidable problem in
distributed systems: it is theoretically impossible to guarantee distributed systems: it is theoretically impossible to guarantee
synchronous state changes in endpoints that communicate synchronous state changes in endpoints that communicate
asynchronously. The protocol will always have one critical message asynchronously. The protocol will always have one critical message
that may get lost, so that one side commits to the state change and that may get lost, so that one side commits to the state change and
the other side does not. In EAP, the critical message is the final the other side does not. In EAP, the critical message is the final
response from the peer to the server. While the final response is response from the peer to the server. While the final response is
normally followed by EAP-Success, [RFC3748] section 4.2 states that normally followed by EAP-Success, [RFC3748], Section 4.2 states that
the peer MAY assume that the EAP-Success was lost and the the peer MAY assume that the EAP-Success was lost and the
authentication was successful. Furthermore, EAP method authentication was successful. Furthermore, EAP method
implementations in the peer do not receive notification of the EAP- implementations in the peer do not receive notification of the EAP-
Success message from the parent EAP state machine [RFC4137]. For Success message from the parent EAP state machine [RFC4137]. For
these reasons, EAP-NOOB on the peer side commits to a state change these reasons, EAP-NOOB on the peer side commits to a state change
already when it sends the final response. already when it sends the final response.
The best available solution to the loss of the critical message is to The best available solution to the loss of the critical message is to
keep trying. EAP retransmission behavior defined in Section 4.3 of keep trying. EAP retransmission behavior defined in Section 4.3 of
[RFC3748] suggests 3-5 retransmissions. In the absence of an [RFC3748] suggests 3-5 retransmissions. In the absence of an
attacker, this would be sufficient to reduce the probability of attacker, this would be sufficient to reduce the probability of
failure to an acceptable level. However, a determined attacker on failure to an acceptable level. However, a determined attacker on
the in-band channel can drop the final EAP-Response message and all the in-band channel can drop the final EAP-Response message and all
subsequent retransmissions. In the Completion Exchange subsequent retransmissions. In the Completion Exchange
(KeyingMode=0) and in the Reconnect Exchange with cryptosuite upgrade (KeyingMode=0) and Reconnect Exchange with cryptosuite upgrade
(KeyingMode=3), this could result in a state mismatch and persistent (KeyingMode=3), this could result in a state mismatch and persistent
denial of service until the user resets the peer state. denial of service until the user resets the peer state.
EAP-NOOB implements its own recovery mechanism that allows unlimited EAP-NOOB implements its own recovery mechanism that allows unlimited
retries of the Reconnect Exchange. When the DoS attacker eventually retries of the Reconnect Exchange. When the DoS attacker eventually
stops dropping packets on the in-band channel, the protocol will stops dropping packets on the in-band channel, the protocol will
recover. The logic for this recovery mechanism is specified in recover. The logic for this recovery mechanism is specified in
Section 3.4.2. Section 3.4.2.
EAP-NOOB does not implement the same kind of retry mechanism in the EAP-NOOB does not implement the same kind of retry mechanism in the
Completion Exchange. The reason is that there is always a user Completion Exchange. The reason is that there is always a user
involved in the initial association process, and the user can repeat involved in the initial association process, and the user can repeat
the OOB Step to complete the association after the DoS attacker has the OOB Step to complete the association after the DoS attacker has
left. On the other hand, Reconnect Exchange needs to work without left. On the other hand, Reconnect Exchange needs to work without
user involvement. user involvement.
7.10. Privacy considerations 6.10. Privacy Considerations
There are privacy considerations related to performing the Reconnect There are privacy considerations related to performing the Reconnect
Exchange while roaming. The peer and server may send updated Exchange while roaming. The peer and server may send updated
PeerInfo and ServerInfo fields in the Reconnect Exchange. This data PeerInfo and ServerInfo fields in the Reconnect Exchange. This data
is sent unencrypted between the peer and the EAP authenticator, such is sent unencrypted between the peer and the EAP authenticator, such
as a wireless access point. Thus, it can be observed by both as a wireless access point. Thus, it can be observed by both
outsiders and the access network. The PeerInfo field contains outsiders and the access network. The PeerInfo field contains
identifiers and other information about the peer device (see identifiers and other information about the peer device (see
Table 6). While the information refers to the peer device and not Table 6). While the information refers to the peer device and not
directly to the user, it can leak information about the user to the directly to the user, it can leak information about the user to the
access network and to outside observers. The ServerInfo, on the access network and to outside observers. The ServerInfo, on the
other hand, can leak information about the peer's affiliation with other hand, can leak information about the peer's affiliation with
the home network. For this reason, the optional PeerInfo and the home network. For this reason, the optional PeerInfo and
ServerInfo in the Reconnect Exchange SHOULD be omitted unless some ServerInfo in the Reconnect Exchange SHOULD be omitted unless some
critical data has changed and it cannot be updated on the application critical data has changed and it cannot be updated on the application
layer. layer.
Peer devices that randomize their layer-2 address to prevent tracking Peer devices that randomize their Layer 2 address to prevent tracking
can do this whenever the user resets the EAP-NOOB association. can do this whenever the user resets the EAP-NOOB association.
During the lifetime of the association, the PeerId is a unique During the lifetime of the association, the PeerId is a unique
identifier that can be used to track the peer in the access network. identifier that can be used to track the peer in the access network.
Later versions of this specification may consider updating the PeerId Later versions of this specification may consider updating the PeerId
at each Reconnect Exchange. In that case, it is necessary to at each Reconnect Exchange. In that case, it is necessary to
consider how the authenticator and access-network administrators can consider how the authenticator and access-network administrators can
recognize and add misbehaving peer devices to a deny list, as well recognize and add misbehaving peer devices to a deny list, as well as
as, how to avoid loss of synchronization between the server and the how to avoid loss of synchronization between the server and the peer
peer if messages are lost during the identifier update. if messages are lost during the identifier update.
To enable stronger identity protection in later versions of EAP-NOOB, To enable stronger identity protection in later versions of EAP-NOOB,
the optional server-assigned NAI (NewNAI) SHOULD have a constant the optional server-assigned NAI (NewNAI) SHOULD have a constant
username part. The RECOMMENDED username is "noob". The server MAY, username part. The RECOMMENDED username is "noob". The server MAY,
however, send a different username in NewNAI to avoid username however, send a different username in NewNAI to avoid username
collisions within its realm or to conform to a local policy on collisions within its realm or to conform to a local policy on
usernames. usernames.
7.11. EAP security claims 6.11. EAP Security Claims
EAP security claims are defined in section 7.2.1 of [RFC3748]. The EAP security claims are defined in Section 7.2.1 of [RFC3748]. The
security claims for EAP-NOOB are listed in Table 13. security claims for EAP-NOOB are listed in Table 13.
+-----------------+-------------------------------------------------+ +=================+=================================================+
| Security | EAP-NOOB claim | | Security | EAP-NOOB Claim |
| property | | | Property | |
+-----------------+-------------------------------------------------+ +=================+=================================================+
| Authentication | ECDHE key exchange with out-of-band | | Authentication | ECDHE key exchange with out-of-band |
| mechanism | authentication | | mechanism | authentication |
| | | +-----------------+-------------------------------------------------+
| Protected | yes | | Protected | yes |
| cryptosuite | | | cryptosuite | |
| negotiation | | | negotiation | |
| | | +-----------------+-------------------------------------------------+
| Mutual | yes | | Mutual | yes |
| authentication | | | authentication | |
| | | +-----------------+-------------------------------------------------+
| Integrity | yes | | Integrity | yes |
| protection | | | protection | |
| | | +-----------------+-------------------------------------------------+
| Replay | yes | | Replay | yes |
| protection | | | protection | |
| | | +-----------------+-------------------------------------------------+
| Confidentiality | no | | Confidentiality | no |
| | | +-----------------+-------------------------------------------------+
| Key derivation | yes | | Key derivation | yes |
| | | +-----------------+-------------------------------------------------+
| Key strength | The specified cryptosuites provide key strength | | Key strength | The specified cryptosuites provide |
| | of at least 128 bits. | | | key strength of at least 128 bits. |
| | | +-----------------+-------------------------------------------------+
| Dictionary | yes | | Dictionary | yes |
| attack | | | attack | |
| protection | | | protection | |
| | | +-----------------+-------------------------------------------------+
| Fast reconnect | yes | | Fast reconnect | yes |
| | | +-----------------+-------------------------------------------------+
| Cryptographic | not applicable | | Cryptographic | not applicable |
| binding | | | binding | |
| | | +-----------------+-------------------------------------------------+
| Session | yes | | Session | yes |
| independence | | | independence | |
| | | +-----------------+-------------------------------------------------+
| Fragmentation | no | | Fragmentation | no |
| | | +-----------------+-------------------------------------------------+
| Channel binding | yes (The ServerInfo and PeerInfo can be used to | | Channel binding | yes (The ServerInfo and PeerInfo can |
| | convey integrity-protected channel properties | | | be used to convey integrity-protected |
| | such as network SSID or peer MAC address.) | | | channel properties, such as network |
| | SSID or peer MAC address.) |
+-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+
Table 13: EAP security claims Table 13: EAP Security Claims
8. References 7. References
8.1. Normative references 7.1. Normative References
[EUI-48] Institute of Electrical and Electronics Engineers, [EUI-48] IEEE, "IEEE Standard for Local and Metropolitan Area
"802-2014 IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture",
Networks: Overview and Architecture.", IEEE Standard DOI 10.1109/IEEESTD.2014.6847097, IEEE Standard 802-2014,
802-2014. , June 2014. June 2014, <https://doi.org/10.1109/IEEESTD.2014.6847097>.
[FIPS186-4] [FIPS186-4]
National Institute of Standards and Technology, "Digital National Institute of Standards and Technology (NIST),
Signature Standard (DSS)", FIPS 186-4 , July 2013. "Digital Signature Standard (DSS)",
DOI 10.6028/NIST.FIPS.186-4, FIPS 186-4, July 2013,
<https://doi.org/10.6028/NIST.FIPS.186-4>.
[NIST-DH] Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R. [NIST-DH] Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R.
Davis, "Recommendation for Pair-Wise Key Establishment Davis, "Recommendation for Pair-Wise Key-Establishment
Schemes Using Discrete Logarithm Cryptography", NIST Schemes Using Discrete Logarithm Cryptography",
Special Publication 800-56A Revision 3 , April 2018, DOI 10.6028/NIST.SP.800-56Ar3, NIST Special
Publication 800-56A Revision 3, April 2018,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-56Ar3.pdf>. NIST.SP.800-56Ar3.pdf>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>. <https://www.rfc-editor.org/info/rfc2104>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
skipping to change at page 57, line 40 skipping to change at line 2569
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259, Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017, DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>. <https://www.rfc-editor.org/info/rfc8259>.
8.2. Informative references 7.2. Informative References
[BluetoothPairing]
Bluetooth, SIG, "Simple pairing whitepaper", Technical
report , 2007.
[I-D.ietf-rats-eat]
Mandyam, G., Lundblade, L., Ballesteros, M., and J.
O'Donoghue, "The Entity Attestation Token (EAT)", draft-
ietf-rats-eat-10 (work in progress), June 2021.
[I-D.tschofenig-tls-cwt] [Bluetooth]
Tschofenig, H. and M. Brossard, "Using CBOR Web Tokens Bluetooth Special Interest Group, "Bluetooth Core
(CWTs) in Transport Layer Security (TLS) and Datagram Specification Version 5.3", July 2021,
Transport Layer Security (DTLS)", draft-tschofenig-tls- <https://www.bluetooth.com/specifications/bluetooth-core-
cwt-02 (work in progress), July 2020. specification>.
[IEEE-802.1X] [IEEE-802.1X]
Institute of Electrical and Electronics Engineers, "Local IEEE, "IEEE Standard for Local and Metropolitan Area
and Metropolitan Area Networks: Port-Based Network Access Networks--Port-Based Network Access Control", IEEE
Control", IEEE Standard 802.1X-2004. , December 2004. Standard 802.1X-2020, February 2020.
[mcrl2] Groote, J. and M. Mousavi, "Modeling and analysis of
communicating systems", The MIT press , 2014,
<https://mitpress.mit.edu/books/modeling-and-analysis-
communicating-systems>.
[noob-mcrl2]
Peltonen, A., "mCRL2 model of EAP-NOOB", 2021,
<https://github.com/tuomaura/eap-
noob/tree/master/protocolmodel/mcrl2>.
[noob-proverif]
Peltonen, A., "ProVerif model of EAP-NOOB", 2021,
<https://github.com/tuomaura/eap-
noob/tree/master/protocolmodel/proverif >.
[proverif] [RATS-EAT] Lundblade, L., Mandyam, G., and J. O'Donoghue, "The Entity
Blanchet, B., Smyth, B., Cheval, V., and M. Sylvestre, Attestation Token (EAT)", Work in Progress, Internet-
"ProVerif 2.00: Automatic Cryptographic Protocol Verifier, Draft, draft-ietf-rats-eat-11, 24 October 2021,
User Manual and Tutorial", The MIT press , 2018, <https://datatracker.ietf.org/doc/html/draft-ietf-rats-
<http://prosecco.gforge.inria.fr/personal/bblanche/ eat-11>.
proverif/>.
[RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., [RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L.,
Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and
D. Spence, "AAA Authorization Framework", RFC 2904, D. Spence, "AAA Authorization Framework", RFC 2904,
DOI 10.17487/RFC2904, August 2000, DOI 10.17487/RFC2904, August 2000,
<https://www.rfc-editor.org/info/rfc2904>. <https://www.rfc-editor.org/info/rfc2904>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
skipping to change at page 59, line 24 skipping to change at line 2618
[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216,
March 2008, <https://www.rfc-editor.org/info/rfc5216>. March 2008, <https://www.rfc-editor.org/info/rfc5216>.
[RFC6677] Hartman, S., Ed., Clancy, T., and K. Hoeper, "Channel- [RFC6677] Hartman, S., Ed., Clancy, T., and K. Hoeper, "Channel-
Binding Support for Extensible Authentication Protocol Binding Support for Extensible Authentication Protocol
(EAP) Methods", RFC 6677, DOI 10.17487/RFC6677, July 2012, (EAP) Methods", RFC 6677, DOI 10.17487/RFC6677, July 2012,
<https://www.rfc-editor.org/info/rfc6677>. <https://www.rfc-editor.org/info/rfc6677>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[Sethi14] Sethi, M., Oat, E., Di Francesco, M., and T. Aura, "Secure [Sethi14] Sethi, M., Oat, E., Di Francesco, M., and T. Aura, "Secure
Bootstrapping of Cloud-Managed Ubiquitous Displays", bootstrapping of cloud-managed ubiquitous displays",
Proceedings of ACM International Joint Conference on Proceedings of ACM International Joint Conference on
Pervasive and Ubiquitous Computing (UbiComp 2014), pp. Pervasive and Ubiquitous Computing (UbiComp 2014), pp.
739-750, Seattle, USA , September 2014, 739-750, Seattle, USA, DOI 10.1145/2632048.2632049,
September 2014,
<http://dx.doi.org/10.1145/2632048.2632049>. <http://dx.doi.org/10.1145/2632048.2632049>.
[Sethi19] Sethi, M., Peltonen, A., and T. Aura, "Misbinding Attacks [Sethi19] Sethi, M., Peltonen, A., and T. Aura, "Misbinding Attacks
on Secure Device Pairing", 2019, on Secure Device Pairing and Bootstrapping",
DOI 10.1145/3321705.3329813, February 2019,
<https://arxiv.org/abs/1902.07550>. <https://arxiv.org/abs/1902.07550>.
Appendix A. Exchanges and events per state [TLS-CWT] Tschofenig, H. and M. Brossard, "Using CBOR Web Tokens
(CWTs) in Transport Layer Security (TLS) and Datagram
Transport Layer Security (DTLS)", Work in Progress,
Internet-Draft, draft-tschofenig-tls-cwt-02, 13 July 2020,
<https://datatracker.ietf.org/doc/html/draft-tschofenig-
tls-cwt-02>.
Figure 11 shows how the EAP server chooses the exchange type Appendix A. Exchanges and Events per State
depending on the server and peer states. In the state combinations
marked with hyphen "-", there is no possible exchange and user action
is required to make progress. Note that peer state 4 is omitted from
the table because the peer never connects to the server when the peer
is in that state. The table also shows the handling of errors in
each exchange. A notable detail is that the recipient of error code
2003 moves to state 1.
+--------+---------------------------+------------------------------+ Table 14 shows how the EAP server chooses the exchange type depending
| peer | exchange chosen by | next peer and | on the server and peer states. In the state combinations marked with
| states | server | server states | hyphen "-", there is no possible exchange and user action is required
+========+===========================+==============================+ to make progress. Note that peer state 4 is omitted from the table
| server state: Unregistered (0) | 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
| 0..2 | Initial Exchange | both 1 (0 on error) | exchange. A notable detail is that the recipient of error code 2003
| 3 | - | no change, notify user | moves to state 1.
+--------+---------------------------+------------------------------+
| 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
Figure 11: How server chooses the exchange type +=============+===============================+==================+
| Peer States | Exchange Chosen by the Server | Next Peer and |
| | | 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) |
+-------------+-------------------------------+------------------+
Figure 12 lists the local events that can take place in the server or Table 14: How the Server Chooses the Exchange Type
(A) peer to 1 on error 2003; no other changes on error
(B) server to 1 on error 2003; no other changes on error
Table 15 lists the local events that can take place in the server or
peer. Both the server and peer output and accept OOB messages in peer. Both the server and peer output and accept OOB messages in
association state 1, leading the receiver to state 2. Communication association state 1, leading the receiver to state 2. Communication
errors and timeouts in states 0..2 lead back to state 0, while errors and timeouts in states 0..2 lead back to state 0, while
similar errors in states 3..4 lead to state 3. Application request similar errors in states 3..4 lead to state 3. An application
for rekeying (e.g., to refresh session keys or to upgrade request for rekeying (e.g., to refresh session keys or to upgrade
cryptosuite) also takes the association from state 3..4 to state 3. cryptosuite) also takes the association from state 3..4 to state 3.
User can always reset the association state to 0. Recovering The user can always reset the association state to 0. Recovering
association data, e.g., from a backup, leads to state 3. association data, e.g., from a backup, leads to state 3.
+--------+----------------------------------+--------------------+ +===================+========================+=========+
| server/| possible local events | next state | | Server/Peer State | Possible Local Events | Next |
| peer | on server and peer | | | | in the Server and Peer | State |
| state | | | +===================+========================+=========+
+========+==================================+====================+ | 1 | OOB Output | 1 |
| 1 | OOB Output | 1 | +-------------------+------------------------+---------+
| 1 | OOB Input | 2 (1 on error) | | 1 | OOB Input | 2 (1 on |
| 0..2 | Mobility/timeout/network failure | 0 | | | | error) |
| 3..4 | Mobility/timeout/network failure | 3 | +-------------------+------------------------+---------+
| 3..4 | Rekeying request | 3 | | 0..2 | Mobility/timeout/ | 0 |
| 0..4 | User resets association | 0 | | | network failure | |
| 0..4 | Association state recovery | 3 | +-------------------+------------------------+---------+
+--------+----------------------------------+--------------------+ | 3..4 | Mobility/timeout/ | 3 |
| | network failure | |
+-------------------+------------------------+---------+
| 3..4 | Rekeying request | 3 |
+-------------------+------------------------+---------+
| 0..4 | User resets | 0 |
| | association | |
+-------------------+------------------------+---------+
| 0..4 | Association state | 3 |
| | recovery | |
+-------------------+------------------------+---------+
Figure 12: Local events on server and peer Table 15: Local Events in the Server and Peer
Appendix B. Application-specific parameters Appendix B. Application-Specific Parameters
Table 14 lists OOB channel parameters that need to be specified in Table 16 lists OOB channel parameters that need to be specified in
each application that makes use of EAP-NOOB. The list is not each application that makes use of EAP-NOOB. The list is not
exhaustive and is included for the convenience of implementers only. exhaustive and is included for the convenience of implementers only.
+--------------------+----------------------------------------------+ +====================+=========================================+
| Parameter | Description | | Parameter | Description |
+--------------------+----------------------------------------------+ +====================+=========================================+
| OobDirs | Allowed directions of the OOB channel | | OobDirs | Allowed directions of the OOB channel. |
| | | +--------------------+-----------------------------------------+
| OobMessageEncoding | How the OOB message data fields are encoded | | OobMessageEncoding | How the OOB message data fields are |
| | for the OOB channel | | | encoded for the OOB channel. |
| | | +--------------------+-----------------------------------------+
| SleepTimeDefault | Default minimum time in seconds that the | | SleepTimeDefault | Default minimum time in seconds that |
| | peer should sleep before the next Waiting | | | the peer should sleep before the next |
| | Exchange | | | Waiting Exchange. |
| | | +--------------------+-----------------------------------------+
| OobRetries | Number of received OOB messages with invalid | | OobRetries | Number of received OOB messages with |
| | Hoob after which the receiver moves to | | | invalid Hoob, after which the receiver |
| | Unregistered (0) state. When the OOB channel | | | moves to Unregistered (0) state. When |
| | has error detection or correction, the | | | the OOB channel has error detection or |
| | RECOMMENDED value is 5. | | | correction, the RECOMMENDED value is 5. |
| | | +--------------------+-----------------------------------------+
| NoobTimeout | How many seconds the sender of the OOB | | NoobTimeout | How many seconds the sender of the OOB |
| | message remembers the sent Noob value. The | | | message remembers the sent Noob value. |
| | RECOMMENDED value is 3600 seconds. | | | The RECOMMENDED value is 3600 seconds. |
| | | +--------------------+-----------------------------------------+
| ServerInfoType | The value of the Type field and the other | | ServerInfoType | The value of the Type field and the |
| | required fields in ServerInfo | | | other required fields in ServerInfo. |
| | | +--------------------+-----------------------------------------+
| PeerInfoType | The value of the Type field and the other | | PeerInfoType | The value of the Type field and the |
| | required fields in PeerInfo | | | other required fields in PeerInfo. |
+--------------------+----------------------------------------------+ +--------------------+-----------------------------------------+
Table 14: OOB channel characteristics Table 16: OOB Channel Characteristics
Appendix C. EAP-NOOB roaming Appendix C. EAP-NOOB Roaming
AAA architectures [RFC2904] allow for roaming of network-connected AAA architectures [RFC2904] allow for roaming of network-connected
appliances that are authenticated over EAP. While the peer is appliances that are authenticated over EAP. While the peer is
roaming in a visited network, authentication still takes place roaming in a visited network, authentication still takes place
between the peer and an authentication server at its home network. between the peer and an authentication server at its home network.
EAP-NOOB supports such roaming by allowing the server to assign a NAI EAP-NOOB supports such roaming by allowing the server to assign a NAI
to the peer. After the NAI has been assigned, it enables the visited 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 server. network to route the EAP session to the peer's home AAA server.
A peer device that is new or has gone through a hard reset should be A peer device that is new or has gone through a hard reset should be
connected first to the home network and establish an EAP-NOOB connected first to the home network and establish an EAP-NOOB
association with its home AAA server before it is able to roam. association with its home AAA server before it is able to roam.
After that, it can perform the Reconnect Exchange from the visited After that, it can perform the Reconnect Exchange from the visited
network. network.
Alternatively, the device may provide some method for the user to Alternatively, the device may provide some method for the user to
configure the NAI of the home network. This is the user or configure the NAI of the home network. This is the user or
application configured NAI mentioned in Section 3.3.1. In that case, application-configured NAI mentioned in Section 3.3.1. In that case,
the EAP-NOOB association can be created while roaming. The the EAP-NOOB association can be created while roaming. The
configured NAI enables the EAP messages to be routed correctly to the configured NAI enables the EAP messages to be routed correctly to the
home AAA server. home AAA server.
While roaming, the device needs to identify the networks where the While roaming, the device needs to identify the networks where the
EAP-NOOB association can be used to gain network access. For 802.11 EAP-NOOB association can be used to gain network access. For 802.11
access networks, the server MAY send a list of SSID strings in the access networks, the server MAY send a list of SSID strings in the
ServerInfo field called either SSIDList or Base64SSIDList. The list ServerInfo field, called either SSIDList or Base64SSIDList. The list
is formatted as explained in Table 6. If present, the peer MAY use is formatted as explained in Table 6. If present, the peer MAY use
this list as a hint to determine the networks where the EAP-NOOB this list as a hint to determine the networks where the EAP-NOOB
association can be used for access authorization, in addition to the association can be used for access authorization, in addition to the
access network where the Initial Exchange took place. access network where the Initial Exchange took place.
Appendix D. OOB message as URL Appendix D. OOB Message as a URL
While EAP-NOOB does not mandate any particular OOB communication While EAP-NOOB does not mandate any particular OOB communication
channel, typical OOB channels include graphical displays and emulated channel, typical OOB channels include graphical displays and emulated
NFC tags. In the peer-to-server direction, it may be convenient to NFC tags. In the peer-to-server direction, it may be convenient to
encode the OOB message as a URL, which is then encoded as a QR code encode the OOB message as a URL, which is then encoded as a QR code
for displays and printers or as an NDEF record for dynamic NFC tags. for displays and printers or as an NFC Data Exchange Format (NDEF)
A user can then simply scan the QR code or NFC tag and open the URL, record for dynamic NFC tags. A user can then simply scan the QR code
which causes the OOB message to be delivered to the authentication or NFC tag and open the URL, which causes the OOB message to be
server. The URL MUST specify https or another server-authenticated delivered to the authentication server. The URL MUST specify https
scheme, so that there is a secure connection to the server and the or another server-authenticated scheme so that there is a secure
on-path attacker cannot read or modify the OOB message. connection to the server and the on-path attacker cannot read or
modify the OOB message.
The ServerInfo in this case includes a field called ServerURL of the The ServerInfo in this case includes a field called ServerURL of the
following format with RECOMMENDED length of at most 60 characters: following format with a RECOMMENDED length of at most 60 characters:
https://<host>[:<port>]/[<path>] https://<host>[:<port>]/[<path>]
To this, the peer appends the OOB message fields (PeerId, Noob, Hoob) To this, the peer appends the OOB message fields (PeerId, Noob, and
as a query string. PeerId is provided to the peer by the server and Hoob) as a query string. PeerId is provided to the peer by the
might be a 22-character ASCII string. The peer base64url encodes, server and might be a 22-character ASCII string. The peer base64url
without padding, the 16-byte values Noob and Hoob into 22-character encodes, without padding, the 16-byte values Noob and Hoob into
ASCII strings. The query parameters MAY be in any order. The 22-character ASCII strings. The query parameters MAY be in any
resulting URL is of the following format: order. The resulting URL is of the following format:
https://<host>[:<port>]/[<path>]?P=<PeerId>&N=<Noob>&H=<Hoob> https://<host>[:<port>]/[<path>]?P=<PeerId>&N=<Noob>&H=<Hoob>
The following is an example of a well-formed URL encoding the OOB The following is an example of a well-formed URL encoding the OOB
message (without line breaks): message (without line breaks):
https://aaa.example.com/eapnoob?P=mcm5BSCDZ45cYPlAr1ghNw&N=rMinS0-F4E https://aaa.example.com/eapnoob?P=mcm5BSCDZ45cYPlAr1ghNw&N=rMinS0-F4E
fCU8D9ljxX_A&H=QvnMp4UGxuQVFaXPW_14UW fCU8D9ljxX_A&H=QvnMp4UGxuQVFaXPW_14UW
Appendix E. Version history Acknowledgments
o Version 01:
* Fixed Reconnection Exchange.
* URL examples.
* Message examples.
* Improved state transition (event) tables.
o Version 02:
* Reworked the rekeying and key derivation.
* Increased internal key lengths and in-band nonce and HMAC
lengths to 32 bytes.
* Less data in the persistent EAP-NOOB association.
* Updated reference [NIST-DH] to Revision 2 (2013).
* Shorter suggested PeerId format.
* Optimized the example of encoding OOB message as URL.
* NoobId in Completion Exchange to differentiate between multiple
valid Noob values.
* List of application-specific parameters in appendix.
* Clarified the equivalence of Unregistered state and no state.
* Peer SHOULD probe the server regardless of the OOB channel
direction.
* Added new error messages.
* Realm is part of the persistent association and can be updated.
* Clarified error handling.
* Updated message examples.
* Explained roaming in appendix.
* More accurate definition of timeout for the Noob nonce.
* Additions to security considerations.
o Version 03:
* Clarified reasons for going to Reconnecting state.
* Included Verp in persistent state.
* Added appendix on suggested ServerInfo and PeerInfo fields.
* Exporting PeerId and SessionId.
* Explicitly specified next state after OOB Step.
* Clarified the processing of an expired OOB message and
unrecognized NoobId.
* Enabled protocol version upgrade in Reconnect Exchange.
* Explained handling of redundant received OOB messages.
* Clarified where raw and base64url encoded values are used.
* Cryptosuite must specify the detailed format of the JWK object.
* Base64url encoding in JSON strings is done without padding.
* Simplified explanation of PeerId, Realm and NAI.
* Added error codes for private and experimental use.
* Updated the security considerations.
o Version 04:
* Recovery from synchronization failure due to lost last
response.
o Version 05:
* Kz identifier added to help recovery from lost last messages.
* Error message codes changed for better structure.
* Improved security considerations section.
o Version 06:
* Kz identifier removed to enable PeerId anonymization in the
future.
* Clarified text on when to use server-assigned realm.
* Send PeerId and PeerState in a separate request-response pair,
not in NAI.
* New subsection for the common handshake in all exchanges to
avoid repetition.
o Version 07:
* Updated example messages.
* Added pointers to new implementation in Contiki.
o Version 08:
* Editorial improvements and corrections.
o WG Version 00:
* Editorial improvements and corrections.
* Updated reference [NIST-DH] to Revision 3 (2018).
o WG Version 01:
* Add NIST P-256 as Cryptosuite 2.
* Renumber message types.
* Very minor editorial fixes.
o WG Version 02:
* Updated message examples with all KeyingModes.
* Many editorial fixes and other updates based on the IoT
directorate review of Dave Thaler.
* Text on cloning attacks based on review by Hannes Tschofenig.
o WG Version 03:
* Changed server-assigned Realm to server-assigned NAI to avoid
username collisions. This issue was identified in a review by
Alan Dekok.
* Minor editorial improvements.
o WG Version 04:
* Use of more inclusive language.
* Minor changes to IANA registration policies.
* Explain how relative strength of cryptosuites is determined.
* Improvements based on AD review from Roman Danyliw and shepherd
review from Joseph Salowey.
o WG Version 05:
* Many text clarifications based on IESG evaluation.
* Security considerations subsections on success indications,
channel binding, and denial of service.
* Privacy considerations gathered to a separate section.
o WG Version 06:
* Remove leftover text in section on identifying correct
endpoints.
* Example messages removed.
Appendix F. Acknowledgments
Max Crone, Shiva Prasad TP, and Raghavendra MS implemented parts of Max Crone, Shiva Prasad TP, and Raghavendra MS implemented parts of
this protocol with wpa_supplicant and hostapd. Eduardo Ingles (RFC this protocol with wpa_supplicant and hostapd. Eduardo Inglés and
editor: please add an accented e in Ingles) and Dan Garcia-Carrillo Dan Garcia-Carrillo were involved in the implementation of this
were involved in the implementation of this protocol on Contiki. protocol on Contiki. Their inputs helped us in improving the
Their inputs helped us in improving the specification. specification.
The authors would like to thank Rhys Smith and Josh Howlett for The authors would like to thank Rhys Smith and Josh Howlett for
providing valuable feedback as well as new use cases and requirements providing valuable feedback, as well as new use cases and
for the protocol. Thanks to Eric Rescorla, Alan Dekok, Darshak requirements for the protocol. Thanks to Eric Rescorla, Alan Dekok,
Thakore, Stefan Winter, Hannes Tschofenig, Daniel Migault, Roman Darshak Thakore, Stefan Winter, Hannes Tschofenig, Daniel Migault,
Danyliw, Benjamin Kaduk, Francesca Palombini, Steve Hanna, Lars Roman Danyliw, Benjamin Kaduk, Francesca Palombini, Steve Hanna, Lars
Eggert, and Eric Vyncke for their comments and reviews. Eggert, and Éric Vyncke for their comments and reviews.
We would also like to express our sincere gratitude to Dave Thaler We would also like to express our sincere gratitude to Dave Thaler
for his thorough review of the document. for his thorough review of the document.
Authors' Addresses Authors' Addresses
Tuomas Aura Tuomas Aura
Aalto University Aalto University
Aalto 00076 FI-00076 Aalto
Finland Finland
EMail: tuomas.aura@aalto.fi Email: tuomas.aura@aalto.fi
Mohit Sethi Mohit Sethi
Ericsson Ericsson
Jorvas 02420 FI-02420 Jorvas
Finland Finland
EMail: mohit@piuha.net Email: mohit@iki.fi
Aleksi Peltonen Aleksi Peltonen
Aalto University Aalto University
Aalto 00076 FI-00076 Aalto
Finland Finland
EMail: aleksi.peltonen@aalto.fi Email: aleksi.peltonen@aalto.fi
 End of changes. 285 change blocks. 
1385 lines changed or deleted 1181 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/