< draft-aura-eap-noob-05.txt   draft-aura-eap-noob-06.txt >
Network Working Group T. Aura Network Working Group T. Aura
Internet-Draft Aalto University Internet-Draft Aalto University
Intended status: Standards Track M. Sethi Intended status: Standards Track M. Sethi
Expires: September 12, 2019 Ericsson Expires: January 4, 2020 Ericsson
March 11, 2019 July 3, 2019
Nimble out-of-band authentication for EAP (EAP-NOOB) Nimble out-of-band authentication for EAP (EAP-NOOB)
draft-aura-eap-noob-05 draft-aura-eap-noob-06
Abstract Abstract
Extensible Authentication Protocol (EAP) provides support for Extensible Authentication Protocol (EAP) provides support for
multiple authentication methods. This document defines the EAP-NOOB multiple authentication methods. This document defines the EAP-NOOB
authentication method for nimble out-of-band (OOB) authentication and authentication method for nimble out-of-band (OOB) authentication and
key derivation. This EAP method is intended for bootstrapping all key derivation. This EAP method is intended for bootstrapping all
kinds of Internet-of-Things (IoT) devices that have a minimal user kinds of Internet-of-Things (IoT) devices that have a minimal user
interface and no pre-configured authentication credentials. The interface and no pre-configured authentication credentials. The
method makes use of a user-assisted one-directional OOB channel method makes use of a user-assisted one-directional OOB channel
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 12, 2019. This Internet-Draft will expire on January 4, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 16 skipping to change at page 2, line 16
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. EAP-NOOB protocol . . . . . . . . . . . . . . . . . . . . . . 5 3. EAP-NOOB protocol . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Protocol overview . . . . . . . . . . . . . . . . . . . . 5 3.1. Protocol overview . . . . . . . . . . . . . . . . . . . . 5
3.2. Protocol messages and sequences . . . . . . . . . . . . . 8 3.2. Protocol messages and sequences . . . . . . . . . . . . . 8
3.2.1. Initial Exchange . . . . . . . . . . . . . . . . . . 8 3.2.1. Common handshake in all EAP exchanges . . . . . . . . 8
3.2.2. OOB Step . . . . . . . . . . . . . . . . . . . . . . 10 3.2.2. Initial Exchange . . . . . . . . . . . . . . . . . . 10
3.2.3. Completion Exchange . . . . . . . . . . . . . . . . . 11 3.2.3. OOB Step . . . . . . . . . . . . . . . . . . . . . . 11
3.2.4. Waiting Exchange . . . . . . . . . . . . . . . . . . 13 3.2.4. Completion Exchange . . . . . . . . . . . . . . . . . 13
3.3. Protocol data fields . . . . . . . . . . . . . . . . . . 15 3.2.5. Waiting Exchange . . . . . . . . . . . . . . . . . . 15
3.3.1. Peer identifier, realm and NAI . . . . . . . . . . . 15 3.3. Protocol data fields . . . . . . . . . . . . . . . . . . 16
3.3.2. Message data fields . . . . . . . . . . . . . . . . . 17 3.3.1. Peer identifier, realm and NAI . . . . . . . . . . . 16
3.4. Fast reconnect and rekeying . . . . . . . . . . . . . . . 22 3.3.2. Message data fields . . . . . . . . . . . . . . . . . 18
3.4.1. Persistent EAP-NOOB association . . . . . . . . . . . 22 3.4. Fast reconnect and rekeying . . . . . . . . . . . . . . . 23
3.4.2. Reconnect Exchange . . . . . . . . . . . . . . . . . 23 3.4.1. Persistent EAP-NOOB association . . . . . . . . . . . 23
3.4.3. User reset . . . . . . . . . . . . . . . . . . . . . 26 3.4.2. Reconnect Exchange . . . . . . . . . . . . . . . . . 24
3.5. Key derivation . . . . . . . . . . . . . . . . . . . . . 27 3.4.3. User reset . . . . . . . . . . . . . . . . . . . . . 27
3.6. Error handling . . . . . . . . . . . . . . . . . . . . . 30 3.5. Key derivation . . . . . . . . . . . . . . . . . . . . . 28
3.6.1. Invalid messages . . . . . . . . . . . . . . . . . . 32 3.6. Error handling . . . . . . . . . . . . . . . . . . . . . 31
3.6.2. Unwanted peer . . . . . . . . . . . . . . . . . . . . 32 3.6.1. Invalid messages . . . . . . . . . . . . . . . . . . 33
3.6.3. State mismatch . . . . . . . . . . . . . . . . . . . 32 3.6.2. Unwanted peer . . . . . . . . . . . . . . . . . . . . 33
3.6.4. Negotiation failure . . . . . . . . . . . . . . . . . 32 3.6.3. State mismatch . . . . . . . . . . . . . . . . . . . 33
3.6.5. Cryptographic verification failure . . . . . . . . . 33 3.6.4. Negotiation failure . . . . . . . . . . . . . . . . . 33
3.6.6. Application-specific failure . . . . . . . . . . . . 33 3.6.5. Cryptographic verification failure . . . . . . . . . 34
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 3.6.6. Application-specific failure . . . . . . . . . . . . 34
4.1. Cryptosuites . . . . . . . . . . . . . . . . . . . . . . 34 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
4.2. Message Types . . . . . . . . . . . . . . . . . . . . . . 34 4.1. Cryptosuites . . . . . . . . . . . . . . . . . . . . . . 35
4.3. Error codes . . . . . . . . . . . . . . . . . . . . . . . 35 4.2. Message Types . . . . . . . . . . . . . . . . . . . . . . 35
4.4. Domain name reservation considerations . . . . . . . . . 36 4.3. Error codes . . . . . . . . . . . . . . . . . . . . . . . 36
5. Implementation Status . . . . . . . . . . . . . . . . . . . . 37 4.4. Domain name reservation considerations . . . . . . . . . 37
5.1. Implementation with wpa_supplicant and hostapd . . . . . 37 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 38
5.2. Protocol modeling . . . . . . . . . . . . . . . . . . . . 38 5.1. Implementation with wpa_supplicant and hostapd . . . . . 38
6. Security considerations . . . . . . . . . . . . . . . . . . . 38 5.2. Protocol modeling . . . . . . . . . . . . . . . . . . . . 39
6.1. Authentication principle . . . . . . . . . . . . . . . . 38 6. Security considerations . . . . . . . . . . . . . . . . . . . 39
6.2. Identifying correct endpoints . . . . . . . . . . . . . . 40 6.1. Authentication principle . . . . . . . . . . . . . . . . 39
6.3. Trusted path issues and misbinding attacks . . . . . . . 40 6.2. Identifying correct endpoints . . . . . . . . . . . . . . 41
6.4. Peer identifiers and attributes . . . . . . . . . . . . . 41 6.3. Trusted path issues and misbinding attacks . . . . . . . 41
6.5. Identity protection . . . . . . . . . . . . . . . . . . . 42 6.4. Peer identifiers and attributes . . . . . . . . . . . . . 42
6.6. Downgrading threats . . . . . . . . . . . . . . . . . . . 43 6.5. Identity protection . . . . . . . . . . . . . . . . . . . 43
6.7. Recovery from loss of last message . . . . . . . . . . . 44 6.6. Downgrading threats . . . . . . . . . . . . . . . . . . . 44
6.8. EAP security claims . . . . . . . . . . . . . . . . . . . 45 6.7. Recovery from loss of last message . . . . . . . . . . . 45
6.8. EAP security claims . . . . . . . . . . . . . . . . . . . 46
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 48
7.1. Normative references . . . . . . . . . . . . . . . . . . 47 7.1. Normative references . . . . . . . . . . . . . . . . . . 48
7.2. Informative references . . . . . . . . . . . . . . . . . 48 7.2. Informative references . . . . . . . . . . . . . . . . . 49
Appendix A. Exchanges and events per state . . . . . . . . . . . 50 Appendix A. Exchanges and events per state . . . . . . . . . . . 51
Appendix B. Application-specific parameters . . . . . . . . . . 51 Appendix B. Application-specific parameters . . . . . . . . . . 52
Appendix C. ServerInfo and PeerInfo contents . . . . . . . . . . 52 Appendix C. ServerInfo and PeerInfo contents . . . . . . . . . . 53
Appendix D. EAP-NOOB roaming . . . . . . . . . . . . . . . . . . 54 Appendix D. EAP-NOOB roaming . . . . . . . . . . . . . . . . . . 55
Appendix E. OOB message as URL . . . . . . . . . . . . . . . . . 55 Appendix E. OOB message as URL . . . . . . . . . . . . . . . . . 56
Appendix F. Example messages . . . . . . . . . . . . . . . . . . 56 Appendix F. Example messages . . . . . . . . . . . . . . . . . . 57
Appendix G. TODO list . . . . . . . . . . . . . . . . . . . . . 58 Appendix G. TODO list . . . . . . . . . . . . . . . . . . . . . 59
Appendix H. Version history . . . . . . . . . . . . . . . . . . 58 Appendix H. Version history . . . . . . . . . . . . . . . . . . 59
Appendix I. Acknowledgments . . . . . . . . . . . . . . . . . . 60 Appendix I. Acknowledgments . . . . . . . . . . . . . . . . . . 61
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61
1. Introduction 1. Introduction
This document describes a method for registration, authentication and This document describes a method for registration, authentication and
key derivation for network-connected ubiquitous computing devices, key derivation for network-connected ubiquitous computing devices,
such as consumer and enterprise appliances that are part of the such as consumer and enterprise appliances that are part of the
Internet of Things (IoT). These devices may be off-the-shelf Internet of Things (IoT). These devices may be off-the-shelf
hardware that is sold and distributed without any prior registration hardware that is sold and distributed without any prior registration
or credential-provisioning process. Thus, the device registration in or credential-provisioning process. Thus, the device registration in
a server database, ownership of the device, and the authentication a server database, ownership of the device, and the authentication
skipping to change at page 8, line 18 skipping to change at page 8, line 18
several minutes rather than seconds. For example, consider a printer several minutes rather than seconds. For example, consider a printer
(peer) that outputs the OOB message on paper, which is then scanned (peer) that outputs the OOB message on paper, which is then scanned
for the server. To support such high-latency OOB channels, the peer for the server. To support such high-latency OOB channels, the peer
and server perform the Initial Exchange in one EAP conversation, then and server perform the Initial Exchange in one EAP conversation, then
allow time for the OOB message to be delivered, and later perform the allow time for the OOB message to be delivered, and later perform the
Waiting and Completion Exchanges in different EAP conversations. Waiting and Completion Exchanges in different EAP conversations.
3.2. Protocol messages and sequences 3.2. Protocol messages and sequences
This section defines the EAP-NOOB exchanges, which correspond to EAP This section defines the EAP-NOOB exchanges, which correspond to EAP
conversations. The protocol messages in each exchange and the data conversations. The exchanges start with a common handshake, which
members in each message are listed in the diagrams below. determines the type of the following exchange. The common handshake
messages and the subsequent messages for each exchange type are
listed in the diagrams below. The diagrams also specify the data
members present in each message. Each exchange comprises multiple
EAP requests-response pairs and ends in either EAP-Failure,
indicating that authentication is not (yet) successful, or in EAP-
Success.
Each EAP-NOOB exchange begins with the authenticator sending an EAP- 3.2.1. Common handshake in all EAP exchanges
Request/Identity packet to the peer. From this point on, the EAP
conversation occurs between the server and the peer, and the
authenticator acts as a pass-through device. The peer responds to
the authenticator with an EAP-Response/Identity packet, containing
the network access identifier (NAI), which conveys both the peer
identity and the current peer state as defined in Section 3.3.1.
After receiving the NAI, the server chooses the EAP-NOOB exchange, All EAP-NOOB exchanges start with common handshake messages. The
i.e. the ensuing message sequence, based on the combination of the handshake starts with the identity request and response that are
peer and server states. The peer recognizes the exchange based on common to all EAP methods. Their purpose is to enable the AAA
the message type field (Type) of the EAP-NOOB request received from architecture to route the EAP conversation to the EAP server and to
the server. The available exchanges are defined in the following enable the EAP server to select the EAP method. The handshake then
subsections. Each exchange comprises one or more EAP requests- continues with one EAP-NOOB request-response pair in which the server
response pairs and ends in either EAP-Failure, indicating that discovers the peer identifier used in EAP-NOOB and the peer state.
authentication is not (yet) successful, or in EAP-Success.
3.2.1. Initial Exchange In more detail, each EAP-NOOB exchanges begin with the authenticator
sending an EAP-Request/Identity packet to the peer. From this point
on, the EAP conversation occurs between the server and the peer, and
the authenticator acts as a pass-through device. The peer responds
to the authenticator with an EAP-Response/Identity packet, which
contains the network access identifier (NAI). The authenticator,
acting as a pass-through device, forwards this response and the
following EAP conversation between the peer and the AAA architecture.
The AAA architecture routes the conversation to a specific AAA server
(called "EAP server" or simply "server" in this specification) based
on the realm part of the NAI. The server selects the EAP-NOOB method
based on the user part of the NAI, as defined in Section 3.3.1.
Upon receiving the EAP-Response/Identity from the peer, if either the After receiving the EAP-Response/Identity message, the server sends
peer or the server is in the Unregistered (0) state and the other is the first EAP-NOOB request (Type=9) to the peer, which responds with
in one of the ephemeral states (0..2), the server chooses the Initial the peer identifier (PeerId) and state (PeerState) in the range 0..3.
Exchange. However, the peer SHOULD omit the PeerId from the response (Type=9)
when PeerState=0. The server then chooses the EAP-NOOB exchange,
i.e. the ensuing message sequence, as explained below. The peer
recognizes the exchange based on the message type field (Type) of the
next EAP-NOOB request received from the server.
The Initial Exchange comprises two EAP-NOOB request-response pairs, The server determines the exchange type based on the combination of
one for version, cryptosuite and parameter negotiation and the other the peer and server states as follows (also summarized in Figure 11).
for the ECDHE key exchange. The first EAP-NOOB request (Type=1) from If one of the peer and server is in the Unregistered (0) state and
the server contains a newly allocated PeerId for the peer and an the other is in one of the ephemeral states (0..2), the server
optional Realm. The server allocates a new PeerId in the Initial chooses the Initial Exchange. If one of the peer or server is in the
Exchange regardless of any old PeerId in the username part of the OOB Received (2) state and the other is either in the Waiting for OOB
received NAI. The server also sends in the request a list of the (1) or OOB Received (2) state, the OOB Step has taken place and the
protocol versions (Vers) and cryptosuites (Cryptosuites) it supports, server chooses the Completion Exchange. If both the server and peer
an indicator of the OOB channel directions it supports (Dirs), and a are in the Waiting for OOB (1) state, the server chooses the Waiting
ServerInfo object. The peer chooses one of the versions and Exchange. If the peer is in the Reconnecting (3) state and the
cryptosuites. The peer sends a response (Type=1) with the selected server is in the Registered (4) or Reconnecting (3) state, the server
protocol version (Verp), the received PeerId, the selected chooses the Reconnect Exchange. All other state combinations are
cryptosuite (Cryptosuitep), an indicator of the OOB channel error situations where user action is required, and the server
directions selected by the peer (Dirp), and a PeerInfo object. In indicates such errors to the peer with the error code 2002 (see
the second EAP-NOOB request and response (Type=2), the server and Section 3.6.3). Note also that the peer MUST NOT initiate EAP-NOOB
peer exchange the public components of their ECDHE keys and nonces when the peer is in Registered (4) state.
(PKs,Ns,PKp,Np). The ECDHE keys MUST be based on the negotiated
cryptosuite i.e. Cryptosuitep. The Initial Exchange ends always with
EAP-Failure from the server because the authentication cannot yet be
completed.
EAP Peer EAP Server EAP Peer EAP Server
| | | |
|<----------- EAP-Request/Identity -| | |<----------- EAP-Request/Identity -| |
| | | |
| | | |
|------------ EAP-Response/Identity -------------->| |------------ EAP-Response/Identity -------------->|
| (NAI=noob|PeerId+sX@eap-noob.net) | | (NAI=noob@eap-noob.net) |
| | | |
| | | |
|<----------- EAP-Request/EAP-NOOB ----------------| |<----------- EAP-Request/EAP-NOOB ----------------|
| (Type=9) |
| |
| |
|------------ EAP-Response/EAP-NOOB -------------->|
| (Type=9,[PeerId],PeerState=1) |
| |
| continuing with exchange-specific messages... |
Figure 2: Common handshake in all EAP-NOOB exchanges
3.2.2. Initial Exchange
The Initial Exchange comprises the common handshake and two further
EAP-NOOB request-response pairs, one for version, cryptosuite and
parameter negotiation and the other for the ECDHE key exchange. The
first EAP-NOOB request (Type=1) from the server contains a newly
allocated PeerId for the peer and an optional Realm. The server
allocates a new PeerId in the Initial Exchange regardless of any old
PeerId in the username part of the received NAI. The server also
sends in the request a list of the protocol versions (Vers) and
cryptosuites (Cryptosuites) it supports, an indicator of the OOB
channel directions it supports (Dirs), and a ServerInfo object. The
peer chooses one of the versions and cryptosuites. The peer sends a
response (Type=1) with the selected protocol version (Verp), the
received PeerId, the selected cryptosuite (Cryptosuitep), an
indicator of the OOB channel directions selected by the peer (Dirp),
and a PeerInfo object. In the second EAP-NOOB request and response
(Type=2), the server and peer exchange the public components of their
ECDHE keys and nonces (PKs,Ns,PKp,Np). The ECDHE keys MUST be based
on the negotiated cryptosuite i.e. Cryptosuitep. The Initial
Exchange always ends with EAP-Failure from the server because the
authentication cannot yet be completed.
EAP Peer EAP Server
| ...continuing from common handshake |
| |
|<----------- EAP-Request/EAP-NOOB ----------------|
| (Type=1,Vers,PeerId,[Realm], | | (Type=1,Vers,PeerId,[Realm], |
| Cryptosuites,Dirs,ServerInfo) | | Cryptosuites,Dirs,ServerInfo) |
| | | |
| | | |
|------------ EAP-Response/EAP-NOOB -------------->| |------------ EAP-Response/EAP-NOOB -------------->|
| (Type=1,Verp,PeerId,Cryptosuitep, | | (Type=1,Verp,PeerId,Cryptosuitep, |
| Dirp,PeerInfo) | | Dirp,PeerInfo) |
| | | |
| | | |
|<----------- EAP-Request/EAP-NOOB ----------------| |<----------- EAP-Request/EAP-NOOB ----------------|
| (Type=2,PeerId,PKs,Ns,[SleepTime]) | | (Type=2,PeerId,PKs,Ns,[SleepTime]) |
| | | |
| | | |
|------------ EAP-Response/EAP-NOOB -------------->| |------------ EAP-Response/EAP-NOOB -------------->|
| (Type=2,PeerId,PKp,Np) | | (Type=2,PeerId,PKp,Np) |
| | | |
| | | |
|<----------- EAP-Failure -------------------------| |<----------- EAP-Failure -------------------------|
| | | |
Figure 2: 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.2. 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 direction place after the Initial Exchange. Depending on the negotiated OOB
negotiated, the peer or the server outputs the OOB message shown in channel direction, the peer or the server outputs the OOB message
Figure 3 or Figure 4, respectively. The data fields are the PeerId, shown in Figure 4 or Figure 5, respectively. The data fields are the
the secret nonce Noob, and the cryptographic fingerprint Hoob. The PeerId, the secret nonce Noob, and the cryptographic fingerprint
contents of the data fields are defined in Section 3.3.2. The OOB Hoob. The contents of the data fields are defined in Section 3.3.2.
message is delivered to the other endpoint via a user-assisted OOB The OOB message is delivered to the other endpoint via a user-
channel. assisted OOB channel.
For brevity, we will use the terms OOB sender and OOB receiver in
addition to the already familiar EAP server and EAP peer. If the OOB
message is sent in in the server-to-peer direction, the OOB sender is
the server and the OOB receiver is the peer. On the other hand, if
the OOB message is sent in the peer-to-server direction, the OOB
sender is the peer and the OOB receiver is the server.
EAP Peer EAP Server EAP Peer EAP Server
| | | |
|=================OOB=============================>| |=================OOB=============================>|
| (PeerId,Noob,Hoob) | | (PeerId,Noob,Hoob) |
| | | |
Figure 3: 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 4: OOB Step, from EAP server to peer Figure 5: OOB Step, from EAP server to peer
The receiver of the OOB message MUST compare the received value of The OOB receiver MUST compare the received value of the fingerprint
the fingerprint Hoob with a value that it computes locally. If the Hoob with a value that it computes locally. If the values are equal,
values are equal, the receiver moves to the OOB Received (2) state. the receiver moves to the OOB Received (2) state. Otherwise, the
Otherwise, the receiver MUST reject the OOB message. For usability receiver MUST reject the OOB message. For usability reasons, the OOB
reasons, the receiver SHOULD indicate the acceptance or rejection of receiver SHOULD indicate the acceptance or rejection of the OOB
the OOB message to the user. The receiver SHOULD reject invalid OOB message to the user. The receiver SHOULD reject invalid OOB messages
messages without changing its state, until an application-specific without changing its state, until an application-specific number of
number of invalid messages (OobRetries) has been reached, after which invalid messages (OobRetries) has been reached, after which the
the receiver SHOULD consider it an error and go back to the receiver SHOULD consider it an error and go back to the Unregistered
Unregistered (0) state. (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.4. 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 OOB message expiry receiver MAY buffer redundant OOB messages in case OOB message expiry
or similar error detected in the Completion Exchange causes it to or similar error detected in the Completion Exchange causes it to
return to the Waiting for OOB (1) state. It is RECOMMENED that the return to the Waiting for OOB (1) state. It is RECOMMENED that the
OOB receiver notifies the user about redundant OOB messages, but it OOB receiver notifies the user about redundant OOB messages, but it
MAY also discard them silently. MAY also 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
skipping to change at page 11, line 37 skipping to change at page 13, line 22
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 one of them. to the user to deliver one of them.
The details of the OOB channel implementation including the message The details of the OOB channel implementation including the message
encoding are defined by the application. Appendix E gives an example encoding are defined by the application. Appendix E gives an example
of how the OOB message can be encoded as a URL that may be embedded of how the OOB message can be encoded as a URL that may be embedded
in a QR code and NFC tag. in a QR code and NFC tag.
3.2.3. Completion Exchange 3.2.4. Completion Exchange
After the Initial Exchange, if both the server and the peer support After the Initial Exchange, if both the server and the peer support
the peer-to-server direction for the OOB channel, the peer SHOULD the peer-to-server direction for the OOB channel, the peer SHOULD
initiate the EAP-NOOB method again after an applications-specific initiate the EAP-NOOB method again after an applications-specific
waiting time in order to probe for completion of the OOB Step. Also, waiting time in order to probe for completion of the OOB Step. Also,
if both sides support the server-to-peer direction of the OOB if both sides support the server-to-peer direction of the OOB
exchange and the peer receives the OOB message, it SHOULD initiate exchange and the peer receives the OOB message, it SHOULD initiate
the EAP-NOOB method immediately. Once the server receives the EAP- the EAP-NOOB method immediately. Depending on the combination of the
Response/Identity, if one of the server and peer is in the OOB peer and server states, the server continues with with the Completion
Received (2) state and the other is either in the Waiting for OOB (1) Exchange or Waiting Exchange (see Section 3.2.1 on how the server
or OOB Received (2) state, the OOB Step has taken place and the makes this decision).
server SHOULD continue with the Completion Exchange.
The Completion Exchange comprises one or two EAP-NOOB request- The Completion Exchange comprises the common handshake and one or two
response pairs. If the peer is in the Waiting for OOB (1) state, the further EAP-NOOB request-response pairs. If the peer is in the
OOB message has been sent in the peer-to-server direction. In that Waiting for OOB (1) state, the OOB message has been sent in the peer-
case, only one request-response pair (Type=4) takes place. In the to-server direction. In that case, only one request-response pair
request, the server sends the NoobId value, which the peer uses to (Type=4) takes place. In the request, the server sends the NoobId
identify the exact OOB message received by the server. On the other value, which the peer uses to identify the exact OOB message received
hand, if the peer is in the OOB Received (2) state, the direction of by the server. On the other hand, if the peer is in the OOB Received
the OOB message is from server to peer. In that case, two request- (2) state, the direction of the OOB message is from server to peer.
response pairs (Type=8 and Type=4) are needed. The purpose of the In that case, two request-response pairs (Type=8 and Type=4) are
first request-response pair (Type=8) is that it enables the server to needed. The purpose of the first request-response pair (Type=8) is
discover NoobId, which identifies the exact OOB message received by that it enables the server to discover NoobId, which identifies the
the peer. The server returns the same NoobId to the peer in the exact OOB message received by the peer. The server returns the same
latter request. NoobId to the peer in the latter request.
In the last and sometimes only request-response pair (Type=4) of the In the last and sometimes only request-response pair (Type=4) of the
Completion Exchange, the server and peer exchange message Completion Exchange, the server and peer exchange message
authentication codes. Both sides MUST compute the keys Kms and Kmp authentication codes. Both sides MUST compute the keys Kms and Kmp
as defined in Section 3.5 and the message authentication codes MACs as defined in Section 3.5 and the message authentication codes MACs
and MACp as defined in Section 3.3.2. Both sides MUST compare the and MACp as defined in Section 3.3.2. Both sides MUST compare the
received message authentication code with a locally computed value. received message authentication code with a locally computed value.
If the peer finds that it has received the correct value of MACs and If the peer finds that it has received the correct value of MACs and
the server finds that it has received the correct value of MACp, the 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
skipping to change at page 13, line 11 skipping to change at page 15, line 6
Although it is not expected to occur in practice, poor user interface Although it is not expected to occur in practice, poor user interface
design could lead to two OOB messages delivered simultaneously, one design could lead to two OOB messages delivered simultaneously, one
from the peer to the server and the other from the server to the from the peer to the server and the other from the server to the
peer. The server detects this event in the beginning of the peer. The server detects this event in the beginning of the
Completion Exchange by observing that both the server and peer are in Completion Exchange by observing that both the server and peer are in
the OOB Received state (2). In that case, as a tiebreaker, the the OOB Received state (2). In that case, as a tiebreaker, the
server MUST behave as if only the server-to-peer message had been server MUST behave as if only the server-to-peer message had been
delivered. delivered.
EAP Peer EAP Server EAP Peer EAP Server
| | | ...continuing from common handshake |
|<----------- EAP-Request/Identity -| |
| |
| |
|------------ EAP-Response/Identity -------------->|
| (NAI=PeerId+sX@eap-noob.net) |
| |
| | | |
|<----------- [ EAP-Request/EAP-NOOB ] ------------| |<----------- [ EAP-Request/EAP-NOOB ] ------------|
| (Type=8,PeerId) | | (Type=8,PeerId) |
| | | |
| | | |
|------------ [ EAP-Response/EAP-NOOB ] ---------->| |------------ [ EAP-Response/EAP-NOOB ] ---------->|
| (Type=8,PeerId,NoobId) | | (Type=8,PeerId,NoobId) |
| | | |
| | | |
|<----------- EAP-Request/EAP-NOOB ----------------| |<----------- EAP-Request/EAP-NOOB ----------------|
| (Type=4,PeerId,NoobId,MACs) | | (Type=4,PeerId,NoobId,MACs) |
| | | |
| | | |
|------------ EAP-Response/EAP-NOOB -------------->| |------------ EAP-Response/EAP-NOOB -------------->|
| (Type=4,PeerId,MACp) | | (Type=4,PeerId,MACp) |
| | | |
| | | |
|<----------- EAP-Success -------------------------| |<----------- EAP-Success -------------------------|
| | | |
Figure 5: Completion Exchange Figure 6: Completion Exchange
3.2.4. Waiting Exchange 3.2.5. Waiting Exchange
As explained in Section 3.2.3, the peer SHOULD probe the server for As explained in Section 3.2.4, the peer SHOULD probe the server for
completion of the OOB Step. Once the server receives the EAP- completion of the OOB Step. When the combination of the peer and
Response/Identity, if both the server and peer states are in the server states indicates that the OOB message has not yet been
Waiting for OOB (1) state, the server will continue with the Waiting delivered, the server chooses the Waiting Exchange (see Section 3.2.1
Exchange (Type=3). The main purpose of this exchange is to inform on how the server makes this decision). The Waiting Exchange
the peer that the server has not yet received a peer-to-server OOB comprises the common handshake and one further request-response pair,
message. and it ends always in EAP-Failure.
In order to limit the rate at which peers probe the server, the In order to limit the rate at which peers probe the server, the
server MAY send to the peer either in the Initial Exchange or in the server MAY send to the peer either in the Initial Exchange or in the
Waiting Exchange a minimum time to wait before probing the server Waiting Exchange a minimum time to wait before probing the server
again. A peer that has not received an OOB message MUST wait at again. A peer that has not received an OOB message MUST wait at
least the server-specified minimum waiting time in seconds least the server-specified minimum waiting time in seconds
(SleepTime) before initiating EAP again with the same server. The (SleepTime) before initiating EAP again with the same server. The
peer uses the latest SleepTime value that it has received in or after peer uses the latest SleepTime value that it has received in or after
the Initial Exchange. If the server has not sent any SleepTime the Initial Exchange. If the server has not sent any SleepTime
value, the peer SHOULD wait for an application-specified minimum time value, the peer SHOULD 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.2). 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, e.g. because of
failure to connect to the EAP server or incorrect HMAC. The timeout failure to connect to the EAP server or incorrect HMAC. The timeout
of peer-generated Noob values is defined like this in order to allow of peer-generated Noob values is defined like this in order to allow
the peer to probe the server once after it has waited for the server- the peer to probe the server once after it has waited for the server-
specified SleepTime. 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 (3600) to prevent the peer from
probing the server frequently. probing the server frequently.
EAP Peer EAP Server EAP Peer EAP Server
| | | ...continuing from common handshake |
|<----------- EAP-Request/Identity -| |
| |
| |
|------------ EAP-Response/Identity -------------->|
| (NAI=PeerId+s1@eap-noob.net) |
| |
| | | |
|<----------- EAP-Request/EAP-NOOB ----------------| |<----------- EAP-Request/EAP-NOOB ----------------|
| (Type=3,PeerId,[SleepTime]) | | (Type=3,PeerId,[SleepTime]) |
| | | |
| | | |
|------------ EAP-Response/EAP-NOOB -------------->| |------------ EAP-Response/EAP-NOOB -------------->|
| (Type=3,PeerId) | | (Type=3,PeerId) |
| | | |
| | | |
|<----------- EAP-Failure -------------------------| |<----------- EAP-Failure -------------------------|
| | | |
Figure 6: Waiting Exchange Figure 7: Waiting Exchange
3.3. Protocol data fields 3.3. Protocol data fields
This section defines the various identifiers and data fields used in This section defines the various identifiers and data fields used in
the EAP-NOOB protocol. the EAP-NOOB protocol.
3.3.1. Peer identifier, realm and NAI 3.3.1. Peer identifier, realm 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]; however, it MUST NOT exceed the utf8-username specified in [RFC7542]. The server MUST generate
60 bytes in length and MUST NOT contain the character '+'. The the identifiers in such a way that they do not repeat and cannot be
server MUST generate the identifiers in such a way that they do not guessed by the peer or third parties before the server sends them to
repeat and cannot be guessed by the peer or third parties before the the peer in the Initial Exchange. One way to generate the
server sends them to the peer in the Initial Exchange. One way to identifiers is to choose a random 16-byte identifier and to base64url
generate the identifiers is to choose a random 16-byte identifier and encode it without padding [RFC4648] into a 22-character string.
to base64url encode it without padding [RFC4648] into a 22-character
string. Another way to generate the identifiers is to choose a Another way to generate the identifiers is to choose a random
random 22-character alphanumeric string. It is not advisable to use 22-character alphanumeric 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.
When the peer is in one of the states 1..2, the peer MUST use the The peer uses the allocated PeerId to identify itself to the server
PeerId that the server assigned to it in the latest Initial Exchange. in the subsequent exchanges. It sets the PeerId value in response
When the peer is in one of the persistent states 3..4, it MUST use type 9 as follows. When the peer is in the Unregistered (0) state,
the PeerId from its persistent EAP-NOOB association. When the peer it SHOULD omit the PeerId from response type 9. When the peer is in
is in the Unregistered (0) state, it MUST use the default value one of the states 1..2, it MUST use the PeerId that the server
"noob" as its PeerId. assigned to it in the latest Initial Exchange. When the peer is in
one of the persistent states 3..4, it MUST use the PeerId from its
The server MAY also assign a realm (Realm) to the peer by in the persistent EAP-NOOB association. (The PeerId is written to the
Initial Exchange or Reconnect Exchange. The realm value MUST follow association when the peer moves to the Registered (4) state after a
the syntax of the utf8-realm specified in [RFC7542]. When the peer Completion Exchange.)
is in one of the states 1..2, the peer MUST use the Realm that the
server assigned to it the latest Initial Exchange, if one was
assigned. When the peer is in one of the persistent states 3..4, it
MUST use the Realm from its persistent EAP-NOOB association, if one
is stored in the association. When the peer is in the Unregistered
(0) state, or when the peer is in one of the other states 1..4 and
the server has not assigned it a realm, the peer SHOULD use the
default realm "eap-noob.net". However, the user or application MAY
provide a different default realm to the peer.
To compose its NAI [RFC7542], the peer uses the PeerId in the user The default realm for the peer is "eap-noob.net". However, the user
part and the Realm as the realm part. When no server-assigned PeerId or application MAY provide a different default realm to the peer.
or Realm is available, the default value is used instead. In the Furthermore, the server MAY assign a new realm to the peer in the
Unregistered (0) state, the peer must create the NAI as the Initial Exchange or Reconnect Exchange, in the Realm field of
concatenation of the PeerId, the symbol "@", and the Realm. In the response types 1 and 5. The Realm value MUST follow the syntax of
other states 1..4, the peer MUST create the NAI as the concatenation the utf8-realm specified in [RFC7542]. When the peer is in the
of the PeerId, the string "+s", a single numeric character indicating Unregistered (0) state, or when the peer is in one of the states 1..2
the state of the peer, and the Realm. and the server did not send a Realm in the latest Initial Exchange,
the peer MUST use the default realm. When the peer is in one of the
states 1..2 and the server sent a Realm in the latest Initial
Exchange, the peer MUST use that realm. Finally, when the peer is in
one of the persistent states 3..4, it MUST use the Realm from its
persistent EAP-NOOB association. (The Realm is written to the
association when the peer moves to the Registered (4) state after a
Completion Exchange or Reconnect Exchange.)
Note that a new peer typically sends the NAI "noob@eap-noob.net" in To compose its NAI [RFC7542], the peer concatenates the string
its first EAP-Response/Identity message, and it is always acceptable "noob@" and the server-assigned realm. When no server-assigned realm
for a peer that is in the Unregistered (0) state to use this default is available, the default value is used instead.
NAI. The purpose of the state indicator "+sX" is to inform the
server about the peer state without the cost of an additional round
trip. The server uses this information together with the server
state to decide on the type of the exchange and, thus, the type of
the next EAP-Request. The lack of a state indicator in the NAI means
that that peer is in state 0.
The purpose of the server-assigned realm is to enable more flexible The purpose of the server-assigned realm is to enable more flexible
routing of the EAP sessions over the AAA infrastructure, including routing of the EAP sessions over the AAA infrastructure, including
roaming scenarios (see Appendix D). Moreover, some Authenticators or roaming scenarios (see Appendix D). Moreover, some Authenticators or
AAA servers use the assigned Realm to determine peer-specific AAA servers use the assigned Realm to determine peer-specific
connection parameters, such as isolating the peer to a specific VLAN. connection parameters, such as isolating the peer to a specific VLAN.
The possibility to configure a different default realm enables The possibility to configure a different default realm enables
registration of new devices while roaming. It also enables registration of new devices while roaming. It also enables
manufacturers to set up their own AAA servers for bootstrapping of manufacturers to set up their own AAA servers for bootstrapping of
new peer devices. new peer devices.
skipping to change at page 17, line 28 skipping to change at page 18, line 29
| | EAP server, and the protocol version chosen by | | | EAP server, and the protocol version chosen by |
| | the peer. Vers is a JSON array of unsigned | | | the peer. Vers is a JSON array of unsigned |
| | integers, and Verp is an unsigned integer. | | | integers, and Verp is an unsigned integer. |
| | Example values are "[1]" and "1", | | | Example values are "[1]" and "1", |
| | respectively. | | | respectively. |
| | | | | |
| PeerId | Peer identifier as defined in Section 3.3.1. | | PeerId | Peer identifier as defined in Section 3.3.1. |
| | | | | |
| Realm | Peer realm as defined in Section 3.3.1. | | Realm | Peer realm as defined in Section 3.3.1. |
| | | | | |
| Peer State "+sX" | Peer state indicator as defined in Section | | PeerState | Peer state is an integer in the range 0..4 |
| | 3.3.1. | | | (see Figure 1). However, only values 0..3 are |
| | ever sent in the protocol messages. |
| | | | | |
| Type | EAP-NOOB message type. The type is an integer | | Type | EAP-NOOB message type. The type is an integer |
| | in the range 0..8. 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. |
| | | | | |
| 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]. Detailed | | | JSON Web Key (JWK) format [RFC7517]. Detailed |
| | format of the JWK object is defined by the | | | format of the JWK object is defined by the |
| | cryptosuite. | | | cryptosuite. |
| | | | | |
| Cryptosuites, | The identifiers of cryptosuites supported by | | Cryptosuites, | The identifiers of cryptosuites supported by |
skipping to change at page 21, line 10 skipping to change at page 22, line 13
HMAC input. HMAC input.
The inputs for computing the fingerprint and message authentication The inputs for computing the fingerprint and message authentication
codes are the following: codes are the following:
Hoob = H(Dir,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,Cryptos Hoob = H(Dir,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,Cryptos
uitep,Dirp,[Realm],PeerInfo,0,PKs,Ns,PKp,Np,Noob). uitep,Dirp,[Realm],PeerInfo,0,PKs,Ns,PKp,Np,Noob).
NoobId = H("NoobId",Noob). NoobId = H("NoobId",Noob).
KzId = H("KzId",Kz,Cryptosuitep).
MACs = HMAC(Kms; 2,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,C MACs = HMAC(Kms; 2,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,C
ryptosuitep,Dirp,[Realm],PeerInfo,0,PKs,Ns,PKp,Np,Noob). ryptosuitep,Dirp,[Realm],PeerInfo,0,PKs,Ns,PKp,Np,Noob).
MACp = HMAC(Kmp; 1,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,C MACp = HMAC(Kmp; 1,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,C
ryptosuitep,Dirp,[Realm],PeerInfo,0,PKs,Ns,PKp,Np,Noob). ryptosuitep,Dirp,[Realm],PeerInfo,0,PKs,Ns,PKp,Np,Noob).
MACs2 = HMAC(Kms2; 2,Vers,Verp,PeerId,Cryptosuites,"",[ServerInfo] MACs2 = HMAC(Kms2; 2,Vers,Verp,PeerId,Cryptosuites,"",[ServerInfo]
,Cryptosuitep,"",[Realm],[PeerInfo],KeyingMode,[PKs2],Ns2,[PKp2],N ,Cryptosuitep,"",[Realm],[PeerInfo],KeyingMode,[PKs2],Ns2,[PKp2],N
p2,KzId) p2,"")
MACp2 = HMAC(Kmp2; 1,Vers,Verp,PeerId,Cryptosuites,"",[ServerInfo] MACp2 = HMAC(Kmp2; 1,Vers,Verp,PeerId,Cryptosuites,"",[ServerInfo]
,Cryptosuitep,"",[Realm],[PeerInfo],KeyingMode,[PKs2],Ns2,[PKp2],N ,Cryptosuitep,"",[Realm],[PeerInfo],KeyingMode,[PKs2],Ns2,[PKp2],N
p2,KzId) p2,"")
Missing input values are represented by empty strings "" in the Missing input values are represented by empty strings "" in the
array. The values indicated with "" above are always empty strings. array. The values indicated with "" above are always empty strings.
Realm is included in the computation of MACs and MACp if it was sent Realm is included in the computation of MACs and MACp if it was sent
or received in the preceding Initial Exchange. Each of the values in or received in the preceding Initial Exchange. Each of the values in
brackets for the computation of Macs2 and Macp2 MUST be included if brackets for the computation of Macs2 and Macp2 MUST be included if
it was sent or received in the same Reconnect Exchange; otherwise the it was sent or received in the same Reconnect Exchange; otherwise the
value is replaced by an empty string "". value is replaced by an empty string "".
The parameter Dir indicates the direction in which the OOB message The parameter Dir indicates the direction in which the OOB message
skipping to change at page 23, line 27 skipping to change at page 24, line 27
| (at peer only) | | | | (at peer only) | | |
| | | | | | | |
| Realm | Optional realm assigned by | UTF-8 string | | Realm | Optional realm assigned by | UTF-8 string |
| | server (default value is | | | | server (default value is | |
| | "eap-noob.net") | | | | "eap-noob.net") | |
| | | | | | | |
| Kz | Persistent key material | 32 bytes | | Kz | Persistent key material | 32 bytes |
| | | | | | | |
| KzPrev (at | Previous Kz value | 32 bytes | | KzPrev (at | Previous Kz value | 32 bytes |
| peer only) | | | | peer only) | | |
| | | |
| KzId | Kz identifier | 16 bytes |
| | | |
| KzIdPrev (at | Previous Kz identifier | 16 bytes |
| peer only) | | |
+------------------+------------------------------+-----------------+ +------------------+------------------------------+-----------------+
Table 2: Persistent EAP-NOOB association Table 2: Persistent EAP-NOOB association
3.4.2. Reconnect Exchange 3.4.2. Reconnect Exchange
When the server receives the EAP-Response/Identity, the server The server chooses the Reconnect Exchange when both the peer and the
chooses the Reconnect Exchange if the peer is in the Reconnecting (3) server are in a persistent state and fast reconnection is needed (see
state and the server itself is in the Registered (4) or Reconnecting Section 3.2.1 for details).
(3) state. The peer MUST NOT initiate EAP-NOOB when the peer is in
Registered state.
The Reconnect Exchange comprises three EAP-NOOB request-response The Reconnect Exchange comprises the common handshake and three
pairs, one for cryptosuite and parameter negotiation, another for the further EAP-NOOB request-response pairs, one for cryptosuite and
nonce and ECDHE key exchange, and the last one for exchanging message parameter negotiation, another for the nonce and ECDHE key exchange,
authentication codes. In the first request and response (Type=5) the and the last one for exchanging message authentication codes. In the
server and peer negotiate a protocol version and cryptosuite in the first request and response (Type=5) the server and peer negotiate a
same way as in the Initial Exchange. The server SHOULD NOT offer and protocol version and cryptosuite in the same way as in the Initial
the peer MUST NOT accept protocol versions or cryptosuites that it Exchange. The server SHOULD NOT offer and the peer MUST NOT accept
knows to be weaker than the one currently in the Cryptosuitep field protocol versions or cryptosuites that it knows to be weaker than the
of the persistent EAP-NOOB association. The server SHOULD NOT one currently in the Cryptosuitep field of the persistent EAP-NOOB
needlessly change the cryptosuites it offers to the same peer because association. The server SHOULD NOT needlessly change the
peer devices may have limited ability to update their persistent cryptosuites it offers to the same peer because peer devices may have
storage. However, if the peer has different values in the limited ability to update their persistent storage. However, if the
Cryptosuitep and CryptosuitepPrev fields, it SHOULD also accept peer has different values in the Cryptosuitep and CryptosuitepPrev
offers that are not weaker than CryptosuitepPrev. Note that fields, it SHOULD also accept offers that are not weaker than
Cryptosuitep and CryptosuitePrev from the persistent EAP-NOOB CryptosuitepPrev. Note that Cryptosuitep and CryptosuitePrev from
association are only used to support the negotiation as described the persistent EAP-NOOB association are only used to support the
above; all actual cryptographic operations use the negotiated negotiation as described above; all actual cryptographic operations
cryptosuite. The request and response (Type=5) MAY additionally use the negotiated cryptosuite. The request and response (Type=5)
contain PeerInfo and ServerInfo objects. MAY additionally contain PeerInfo and ServerInfo objects.
The server then determines the KeyingMode (defined in Section 3.5) The server then determines the KeyingMode (defined in Section 3.5)
based on changes in the negotiated cryptosuite and whether it desires based on changes in the negotiated cryptosuite and whether it desires
to achieve forward secrecy or not. The server SHOULD only select to achieve forward secrecy or not. The server SHOULD only select
KeyingMode 3 when the negotiated cryptosuite differs from the KeyingMode 3 when the negotiated cryptosuite differs from the
Cryptosuitep in the server's persistent EAP-NOOB association, Cryptosuitep in the server's persistent EAP-NOOB association,
although it is technically possible to select this values without although it is technically possible to select this values without
changing the cryptosuite. In the second request and response changing the cryptosuite. In the second request and response
(Type=6), the server informs the peer about the KeyingMode, and the (Type=6), 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
skipping to change at page 26, line 6 skipping to change at page 27, line 6
it sends an error message (error code 4001), and the Reconnect it sends an error message (error code 4001), and the Reconnect
Exchange ends in EAP-Failure. Exchange ends in EAP-Failure.
The endpoints MAY send updated Realm, ServerInfo and PeerInfo objects The endpoints MAY send updated Realm, ServerInfo and PeerInfo objects
in the Reconnect Exchange. When there is no update to the values, in the Reconnect Exchange. When there is no update to the values,
they SHOULD omit this information from the messages. If the Realm they SHOULD omit this information from the messages. If the Realm
was sent, each side updates Realm in the persistent EAP-NOOB was sent, each side updates Realm 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 |
|<----------- EAP-Request/Identity -| |
| |
| |
|------------ EAP-Response/Identity -------------->|
| (NAI=PeerId+s3@eap-noob.net) |
| |
| | | |
|<----------- EAP-Request/EAP-NOOB ----------------| |<----------- EAP-Request/EAP-NOOB ----------------|
| (Type=5,Vers,PeerId,Cryptosuites, | | (Type=5,Vers,PeerId,Cryptosuites, |
| [Realm],[ServerInfo]) | | [Realm],[ServerInfo]) |
| | | |
| | | |
|------------ EAP-Response/EAP-NOOB -------------->| |------------ EAP-Response/EAP-NOOB -------------->|
| (Type=5,Verp,PeerId,Cryptosuitep,[PeerInfo])| | (Type=5,Verp,PeerId,Cryptosuitep,[PeerInfo])|
| | | |
| | | |
|<----------- EAP-Request/EAP-NOOB ----------------| |<----------- EAP-Request/EAP-NOOB ----------------|
| (Type=6,PeerId,KeyingMode,KzId,[PKs2],Ns2) | | (Type=6,PeerId,KeyingMode,[PKs2],Ns2) |
| | | |
| | | |
|------------ EAP-Response/EAP-NOOB -------------->| |------------ EAP-Response/EAP-NOOB -------------->|
| (Type=6,PeerId,[PKp2],Np2) | | (Type=6,PeerId,[PKp2],Np2) |
| | | |
| | | |
|<----------- EAP-Request/EAP-NOOB ----------------| |<----------- EAP-Request/EAP-NOOB ----------------|
| (Type=7,PeerId,MACs2) | | (Type=7,PeerId,MACs2) |
| | | |
| | | |
|------------ EAP-Response/EAP-NOOB -------------->| |------------ EAP-Response/EAP-NOOB -------------->|
| (Type=7,PeerId,MACp2) | | (Type=7,PeerId,MACp2) |
| | | |
| | | |
|<----------- EAP-Success -------------------------| |<----------- EAP-Success -------------------------|
| | | |
Figure 7: 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 state
(4) to the Unregistered state (0) is through user-initiated reset. (4) to the Unregistered state (0) is through user-initiated reset.
After the reset, a new OOB message will be needed to establish a new 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
skipping to change at page 28, line 48 skipping to change at page 29, line 48
nonces are exchanged but no ECDHE keys are sent. In this case, input nonces are exchanged but no ECDHE keys are sent. In this case, input
Z to the KDF is replaced with the shared key Kz from the persistent Z to the KDF is replaced with the shared key Kz from the persistent
EAP-NOOB association. The result is rekeying without the 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 associatiob. 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 | Z | ECDHE shared secret | variable |
| Completion | | from PKs and PKp | | | Completion | | from PKs and PKp | |
| | AlgorithmId | "EAP-NOOB" | 8 | | | AlgorithmId | "EAP-NOOB" | 8 |
| | PartyUInfo | Np | 32 | | | PartyUInfo | Np | 32 |
skipping to change at page 30, line 50 skipping to change at page 31, line 50
neither knows nor assigns any server identifier. The exported neither knows nor assigns any server identifier. The exported
Session-Id is created by concatenating the Type-Code xxx (TBA) with Session-Id is created by concatenating the Type-Code xxx (TBA) with
the MethodId, which is obtained from the KDF output as shown in the MethodId, which is obtained from the KDF output as shown in
Table 5. Table 5.
3.6. Error handling 3.6. Error handling
Various error conditions in EAP-NOOB are handled by sending an error Various error conditions in EAP-NOOB are handled by sending an error
notification message (Type=0) instead of the expected next EAP notification message (Type=0) instead of the expected next EAP
request or response message. Both the EAP server and the peer may request or response message. Both the EAP server and the peer may
send the error notification, as shown in Figure 8 and Figure 9. send the error notification, as shown in Figure 9 and Figure 10.
After sending or receiving an error notification, the server MUST After sending or receiving an error notification, the server MUST
send an EAP-Failure (as required by [RFC3748] section 4.2). The send an EAP-Failure (as required by [RFC3748] section 4.2). The
notification MAY contain an ErrorInfo field, which is a UTF-8 encoded notification MAY contain an ErrorInfo field, which is a UTF-8 encoded
text string with a maximum length of 500 bytes. It is used for text string with a maximum length of 500 bytes. It is used for
sending descriptive information about the error for logging and sending descriptive information about the error for logging and
debugging purposes. debugging 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 8: 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 9: 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 and
Completion Exchanges, each side MUST remain in its old state as if Completion Exchanges, each side MUST remain in its old state as if
the failed exchange had not taken place, with the exception that the the failed exchange had not taken place, with the exception that the
recipient of error code 2003 processes it as specified in recipient of error code 2003 processes it as specified in
Section 3.2.3. In the Reconnect Exchange, both sides MUST set the Section 3.2.4. In the Reconnect Exchange, both sides MUST set the
association state to the Reconnecting (3) state. 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; 2005 if the unexpected value; 2003 if the NoobId is not recognized; and 1007 if
KzId is not recognized; and 1007 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 which 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 indicate
this error condition to the user or server administrator. However, this error condition to the user or server administrator. However,
in order to avoid persistent denial of service, the peer is not in order to avoid persistent denial of service, the peer is not
required to stop entirely from reconnecting to the server. required to stop entirely from reconnecting to the server.
3.6.3. State mismatch 3.6.3. State mismatch
In the states indicated by "-" in Figure 10 in Appendix A, user In the states indicated by "-" in Figure 11 in Appendix A, user
action is required to reset the association state or to recover it, action is required to reset the association state or to recover it,
for example, from backup storage. In those cases, the server sends for example, from backup storage. In those cases, the server sends
the error code 2002 to the peer. If possible, both the EAP server the error code 2002 to the peer. If possible, both the EAP server
and peer SHOULD indicate this error condition to the user or server and 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
skipping to change at page 35, line 30 skipping to change at page 36, line 30
| 5 | Reconnect | Version, cryptosuite, and parameter | | 5 | Reconnect | Version, cryptosuite, and parameter |
| | | negotiation | | | | negotiation |
| | | | | | | |
| 6 | Reconnect | Exchange of ECDHE keys and nonces | | 6 | Reconnect | Exchange of ECDHE keys and nonces |
| | | | | | | |
| 7 | Reconnect | Authentication and key confirmation with | | 7 | Reconnect | Authentication and key confirmation with |
| | | HMAC | | | | HMAC |
| | | | | | | |
| 8 | Completion | NoobId discovery | | 8 | Completion | NoobId discovery |
| | | | | | | |
| 9 | All | PeerId and PeerState discovery |
| | exchanges | |
| | | |
| 0 | Error | Error notification | | 0 | Error | Error notification |
| | | | | | | |
+----------+------------+-------------------------------------------+ +----------+------------+-------------------------------------------+
Table 7: EAP-NOOB Table 7: EAP-NOOB
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 "Expert Review" as defined in [RFC8126]. IANA with "Expert Review" as defined in [RFC8126].
4.3. Error codes 4.3. Error codes
skipping to change at page 36, line 17 skipping to change at page 37, line 17
+------------+----------------------------------------+ +------------+----------------------------------------+
| 1001 | Invalid NAI | | 1001 | Invalid NAI |
| 1002 | Invalid message structure | | 1002 | Invalid message structure |
| 1003 | Invalid data | | 1003 | Invalid data |
| 1004 | Unexpected message type | | 1004 | Unexpected message type |
| 1007 | Invalid ECDHE key | | 1007 | Invalid ECDHE key |
| 2001 | Unwanted peer | | 2001 | Unwanted peer |
| 2002 | State mismatch, user action required | | 2002 | State mismatch, user action required |
| 2003 | Unrecognized OOB message identifier | | 2003 | Unrecognized OOB message identifier |
| 2004 | Unexpected peer identifier | | 2004 | Unexpected peer identifier |
| 2005 | Unrecognized Kz identifier |
| 3001 | No mutually supported protocol version | | 3001 | No mutually supported protocol version |
| 3002 | No mutually supported cryptosuite | | 3002 | No mutually supported cryptosuite |
| 3003 | No mutually supported OOB direction | | 3003 | No mutually supported OOB direction |
| 4001 | HMAC verification failure | | 4001 | HMAC verification failure |
| 5001 | Application-specific error | | 5001 | Application-specific error |
| 5002 | Invalid server info | | 5002 | Invalid server info |
| 5003 | Invalid server URL | | 5003 | Invalid server URL |
| 5004 | Invalid peer info | | 5004 | Invalid peer info |
| 6001-6999 | Private and experimental use | | 6001-6999 | Private and experimental use |
+------------+----------------------------------------+ +------------+----------------------------------------+
skipping to change at page 50, line 7 skipping to change at page 51, line 7
Pervasive and Ubiquitous Computing (UbiComp 2014), pp. Pervasive and Ubiquitous Computing (UbiComp 2014), pp.
739-750, Seattle, USA , September 2014, 739-750, Seattle, USA , 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", 2019,
<https://arxiv.org/abs/1902.07550>. <https://arxiv.org/abs/1902.07550>.
Appendix A. Exchanges and events per state Appendix A. Exchanges and events per state
Figure 10 shows how the EAP server chooses the exchange type Figure 11 shows how the EAP server chooses the exchange type
depending on the server and peer states. In the state combinations depending on the server and peer states. In the state combinations
marked with hyphen "-", there is no possible exchange and user action marked with hyphen "-", there is no possible exchange and user action
is required to make progress. Note that peer state 4 is omitted from 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 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 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 each exchange. A notable detail is that the recipient of error code
2003 moves to state 1. 2003 moves to state 1.
+--------+---------------------------+------------------------------+ +--------+---------------------------+------------------------------+
| peer | exchange chosen by | next peer and | | peer | exchange chosen by | next peer and |
skipping to change at page 50, line 47 skipping to change at page 51, line 47
| 3 | - | no change, notify user | | 3 | - | no change, notify user |
+--------+---------------------------+------------------------------+ +--------+---------------------------+------------------------------+
| server state: Reconnecting (3) or Registered (4) | | server state: Reconnecting (3) or Registered (4) |
+--------+---------------------------+------------------------------+ +--------+---------------------------+------------------------------+
| 0..2 | - | no change, notify user | | 0..2 | - | no change, notify user |
| 3 | Reconnect Exchange | both 4 (3 on error) | | 3 | Reconnect Exchange | both 4 (3 on error) |
+--------+---------------------------+------------------------------+ +--------+---------------------------+------------------------------+
(A) peer to 1 on error 2003, no other changes 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 (B) server to 1 on error 2003, no other changes on error
Figure 10: How server chooses the exchange type Figure 11: How server chooses the exchange type
Figure 11 lists the local events that can take place in the server or Figure 12 lists the local events that can take place in the server or
peer. Both the server and peer output and accept OOB messages in peer. Both the server and peer output and accept OOB messages in
association state 1, leading the receiver to state 2. Communication association state 1, leading the receiver to state 2. Communication
errors and timeouts in states 0..2 lead back to state 0, while errors and timeouts in states 0..2 lead back to state 0, while
similar errors in states 3..4 lead to state 3. Application request similar errors in states 3..4 lead to state 3. Application request
for rekeying (e.g. to refresh session keys or to upgrade cryptosuite) for rekeying (e.g. to refresh session keys or to upgrade cryptosuite)
also takes the association from state 3..4 to state 3. User can also takes the association from state 3..4 to state 3. User can
always reset the association state to 0. Recovering association always reset the association state to 0. Recovering association
data, e.g. from a backup, leads to state 3. data, e.g. from a backup, leads to state 3.
+--------+---------------------------+------------------------------+ +--------+---------------------------+------------------------------+
skipping to change at page 51, line 26 skipping to change at page 52, line 26
+========+===========================+==============================+ +========+===========================+==============================+
| 1 | OOB Output* | 1 | | 1 | OOB Output* | 1 |
| 1 | OOB Input* | 2 (1 on error) | | 1 | OOB Input* | 2 (1 on error) |
| 0..2 | Timeout/network failure | 0 | | 0..2 | Timeout/network failure | 0 |
| 3..4 | Timeout/network failure | 3 | | 3..4 | Timeout/network failure | 3 |
| 3..4 | Rekeying request | 3 | | 3..4 | Rekeying request | 3 |
| 0..4 | User resets peer state | 0 | | 0..4 | User resets peer state | 0 |
| 0..4 | Association state recovery| 3 | | 0..4 | Association state recovery| 3 |
+--------+---------------------------+------------------------------+ +--------+---------------------------+------------------------------+
Figure 11: Local events on server and peer Figure 12: Local events on server and peer
Appendix B. Application-specific parameters Appendix B. Application-specific parameters
Table 10 lists OOB channel parameters that need to be specified in Table 10 lists OOB channel parameters that need to be specified in
each application that makes use of EAP-NOOB. The list is not each application that makes use of EAP-NOOB. The list is not
exhaustive and is included for the convenience of implementors only. exhaustive and is included for the convenience of implementors only.
+--------------------+----------------------------------------------+ +--------------------+----------------------------------------------+
| Parameter | Description | | Parameter | Description |
+--------------------+----------------------------------------------+ +--------------------+----------------------------------------------+
skipping to change at page 58, line 15 skipping to change at page 59, line 15
EAP request (type 7): EAP request (type 7):
{"Type":7,"PeerId":"07KRU6OgqX0HIeRFldnbSW","MACs2":"_pXDF4- {"Type":7,"PeerId":"07KRU6OgqX0HIeRFldnbSW","MACs2":"_pXDF4-
7uBKXKqVKKB6U-GP9EDnGCNOMdkyfEQp_iwA"} 7uBKXKqVKKB6U-GP9EDnGCNOMdkyfEQp_iwA"}
EAP response (type 7): EAP response (type 7):
{"Type":7,"PeerId":"07KRU6OgqX0HIeRFldnbSW","MACp2":"qSUH4zA0VzMqU {"Type":7,"PeerId":"07KRU6OgqX0HIeRFldnbSW","MACp2":"qSUH4zA0VzMqU
2O1U-JJTqwGRXGB8i3bggasYL6o1uU"} 2O1U-JJTqwGRXGB8i3bggasYL6o1uU"}
Appendix G. TODO list Appendix G. TODO list
o Change the way KzId is generated and document its use in Reconnect o Update example messages with request-reponse type 9.
Exchange.
Appendix H. Version history Appendix H. Version history
o Version 01: o Version 01:
* Fixed Reconnection Exchange. * Fixed Reconnection Exchange.
* URL examples. * URL examples.
* Message examples. * Message examples.
skipping to change at page 60, line 18 skipping to change at page 61, line 16
response. response.
o Version 05: o Version 05:
* Kz identifier added to help recovery from lost last messages. * Kz identifier added to help recovery from lost last messages.
* Error message codes changed for better structure. * Error message codes changed for better structure.
* Improved security considerations section. * 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-reponse pair,
not in NAI.
* New subsection for the common handshake in all exchanges to
avoid repetition.
Appendix I. Acknowledgments Appendix I. Acknowledgments
Aleksi Peltonen modeled the protocol specification with the mCRL2 Aleksi Peltonen modeled the protocol specification with the mCRL2
formal specification language. Shiva Prasad TP and Raghavendra MS formal specification language. Shiva Prasad TP and Raghavendra MS
implemented parts of the protocol with wpa_supplicant and hostapd. implemented parts of the protocol with wpa_supplicant and hostapd.
Their inputs helped us in improving the specification. Their inputs helped us in improving the specification.
The authors would also like to thank Rhys Smith and Josh Howlett for The authors would also like to thank Rhys Smith and Josh Howlett for
providing valuable feedback as well as new use cases and requirements providing valuable feedback as well as new use cases and requirements
for the protocol. Thanks to Eric Rescorla, Darshak Thakore, Stefan for the protocol. Thanks to Eric Rescorla, Darshak Thakore, Stefan
 End of changes. 59 change blocks. 
268 lines changed or deleted 301 lines changed or added

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