idnits 2.17.1 draft-ietf-emu-eap-noob-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 12, 2020) is 1377 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Realm' is mentioned on line 1194, but not defined == Missing Reference: 'ServerInfo' is mentioned on line 1194, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS186-4' -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST-DH' ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Downref: Normative reference to an Informational RFC: RFC 6234 ** Downref: Normative reference to an Informational RFC: RFC 7748 == Outdated reference: A later version (-25) exists of draft-ietf-rats-eat-03 == Outdated reference: A later version (-02) exists of draft-tschofenig-tls-cwt-01 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Aura 3 Internet-Draft Aalto University 4 Intended status: Standards Track M. Sethi 5 Expires: January 13, 2021 Ericsson 6 July 12, 2020 8 Nimble out-of-band authentication for EAP (EAP-NOOB) 9 draft-ietf-emu-eap-noob-02 11 Abstract 13 The Extensible Authentication Protocol (EAP) provides support for 14 multiple authentication methods. This document defines the EAP-NOOB 15 authentication method for nimble out-of-band (OOB) authentication and 16 key derivation. The EAP method is intended for bootstrapping all 17 kinds of Internet-of-Things (IoT) devices that have no pre-configured 18 authentication credentials. The method makes use of a user-assisted 19 one-directional OOB message between the peer device and 20 authentication server to authenticate the in-band key exchange. The 21 device must have an input or output interface, such as a display, 22 microphone, speakers or blinking light, which can send or receive 23 dynamically generated messages of tens of bytes in length. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 13, 2021. 42 Copyright Notice 44 Copyright (c) 2020 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. EAP-NOOB protocol . . . . . . . . . . . . . . . . . . . . . . 5 62 3.1. Protocol overview . . . . . . . . . . . . . . . . . . . . 5 63 3.2. Protocol messages and sequences . . . . . . . . . . . . . 8 64 3.2.1. Common handshake in all EAP-NOOB exchanges . . . . . 8 65 3.2.2. Initial Exchange . . . . . . . . . . . . . . . . . . 10 66 3.2.3. OOB Step . . . . . . . . . . . . . . . . . . . . . . 11 67 3.2.4. Completion Exchange . . . . . . . . . . . . . . . . . 13 68 3.2.5. Waiting Exchange . . . . . . . . . . . . . . . . . . 15 69 3.3. Protocol data fields . . . . . . . . . . . . . . . . . . 16 70 3.3.1. Peer identifier, realm and NAI . . . . . . . . . . . 16 71 3.3.2. Message data fields . . . . . . . . . . . . . . . . . 18 72 3.4. Fast reconnect and rekeying . . . . . . . . . . . . . . . 23 73 3.4.1. Persistent EAP-NOOB association . . . . . . . . . . . 23 74 3.4.2. Reconnect Exchange . . . . . . . . . . . . . . . . . 24 75 3.4.3. User reset . . . . . . . . . . . . . . . . . . . . . 27 76 3.5. Key derivation . . . . . . . . . . . . . . . . . . . . . 28 77 3.6. Error handling . . . . . . . . . . . . . . . . . . . . . 31 78 3.6.1. Invalid messages . . . . . . . . . . . . . . . . . . 33 79 3.6.2. Unwanted peer . . . . . . . . . . . . . . . . . . . . 33 80 3.6.3. State mismatch . . . . . . . . . . . . . . . . . . . 33 81 3.6.4. Negotiation failure . . . . . . . . . . . . . . . . . 33 82 3.6.5. Cryptographic verification failure . . . . . . . . . 34 83 3.6.6. Application-specific failure . . . . . . . . . . . . 34 84 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 85 4.1. Cryptosuites . . . . . . . . . . . . . . . . . . . . . . 35 86 4.2. Message Types . . . . . . . . . . . . . . . . . . . . . . 36 87 4.3. Error codes . . . . . . . . . . . . . . . . . . . . . . . 36 88 4.4. Domain name reservation considerations . . . . . . . . . 37 89 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 38 90 5.1. Implementation with wpa_supplicant and hostapd . . . . . 38 91 5.2. Implementation on Contiki . . . . . . . . . . . . . . . . 39 92 5.3. Protocol modeling . . . . . . . . . . . . . . . . . . . . 39 93 6. Security considerations . . . . . . . . . . . . . . . . . . . 39 94 6.1. Authentication principle . . . . . . . . . . . . . . . . 39 95 6.2. Cloning of Devices . . . . . . . . . . . . . . . . . . . 41 96 6.3. Identifying correct endpoints . . . . . . . . . . . . . . 41 97 6.4. Trusted path issues and misbinding attacks . . . . . . . 42 98 6.5. Peer identifiers and attributes . . . . . . . . . . . . . 43 99 6.6. Identity protection . . . . . . . . . . . . . . . . . . . 44 100 6.7. Downgrading threats . . . . . . . . . . . . . . . . . . . 44 101 6.8. Recovery from loss of last message . . . . . . . . . . . 45 102 6.9. EAP security claims . . . . . . . . . . . . . . . . . . . 46 103 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 104 7.1. Normative references . . . . . . . . . . . . . . . . . . 48 105 7.2. Informative references . . . . . . . . . . . . . . . . . 49 106 Appendix A. Exchanges and events per state . . . . . . . . . . . 52 107 Appendix B. Application-specific parameters . . . . . . . . . . 53 108 Appendix C. ServerInfo and PeerInfo contents . . . . . . . . . . 54 109 Appendix D. EAP-NOOB roaming . . . . . . . . . . . . . . . . . . 56 110 Appendix E. OOB message as URL . . . . . . . . . . . . . . . . . 57 111 Appendix F. Example messages . . . . . . . . . . . . . . . . . . 58 112 Appendix G. TODO list . . . . . . . . . . . . . . . . . . . . . 62 113 Appendix H. Version history . . . . . . . . . . . . . . . . . . 62 114 Appendix I. Acknowledgments . . . . . . . . . . . . . . . . . . 65 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 66 117 1. Introduction 119 This document describes a method for registration, authentication and 120 key derivation for network-connected ubiquitous computing devices, 121 such as consumer and enterprise appliances that are part of the 122 Internet of Things (IoT). These devices may be off-the-shelf 123 hardware that is sold and distributed without any prior registration 124 or credential-provisioning process, or they may be recycled devices 125 after a hard reset. Thus, the device registration in a server 126 database, ownership of the device, and the authentication credentials 127 for both network access and application-level security must all be 128 established at the time of the device deployment. Furthermore, many 129 such devices have only limited user interfaces that could be used for 130 their configuration. Often, the interfaces are limited to either 131 only input (e.g., camera) or output (e.g., display screen). The 132 device configuration is made more challenging by the fact that the 133 devices may exist in large numbers and may have to be deployed or re- 134 configured nimbly based on user needs. 136 To summarize, devices may have the following characteristics: 138 o no pre-established relation with the intended server or user, 140 o no pre-provisioned device identifier or authentication 141 credentials, 143 o input or output interface that may be capable of only one- 144 directional communication. 146 Many proprietary OOB configuration methods exist for specific IoT 147 devices. The goal of this specification is to provide an open 148 standard and a generic protocol for bootstrapping the security of 149 network-connected appliances, such as displays, printers, speakers, 150 and cameras. The security bootstrapping in this specification makes 151 use of a user-assisted out-of-band (OOB) channel. The device 152 authentication relies on a user having physical access to the device, 153 and the key exchange security is based on the assumption that 154 attackers are not able to observe or modify the messages conveyed 155 through the OOB channel. We follow the common approach taken in 156 pairing protocols: performing a Diffie-Hellman key exchange over the 157 insecure network and authenticating the established key with the help 158 of the OOB channel in order to prevent impersonation and man-in-the- 159 middle (MitM) attacks. 161 The solution presented here is intended for devices that have either 162 an input or output interface, such as a camera, microphone, display 163 screen, speakers or blinking LED light, which is able to send or 164 receive dynamically generated messages of tens of bytes in length. 165 Naturally, this solution may not be appropriate for very small 166 sensors or actuators that have no user interface at all or for 167 devices that are inaccessible to the user. We also assume that the 168 OOB channel is at least partly automated (e.g., camera scanning a bar 169 code) and, thus, there is no need to absolutely minimize the length 170 of the data transferred through the OOB channel. This differs, for 171 example, from Bluetooth simple pairing [BluetoothPairing], where it 172 is critical to minimize the length of the manually transferred or 173 compared codes. The OOB messages in this specification are 174 dynamically generated. We thus do not support static printed 175 registration codes. One reason for requiring dynamic OOB messages is 176 that the receipt of the OOB message authorizes the server to take 177 ownership of the device. This is more secure than a static printed 178 code, which could be leaked and later misused. 180 2. Terminology 182 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 183 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 184 document are to be interpreted as described in [RFC2119]. 186 In addition, this document frequently uses the following terms as 187 they have been defined in [RFC5216]: 189 authenticator The entity initiating EAP authentication. 191 peer The entity that responds to the authenticator. In 192 [IEEE-802.1X], this entity is known as the supplicant. (We use 193 the terms peer, device, and peer device interchangeably.) 195 server The entity that terminates the EAP authentication method with 196 the peer. In the case where no backend authentication server 197 is used, the EAP server is part of the authenticator. In the 198 case where the authenticator operates in pass-through mode, the 199 EAP server is located on the backend authentication server. 201 3. EAP-NOOB protocol 203 This section defines the EAP-NOOB protocol. The protocol is a 204 generalized version of the original idea presented by Sethi et al. 205 [Sethi14]. 207 3.1. Protocol overview 209 One EAP-NOOB protocol execution spans two or more EAP conversations, 210 called Exchanges in this specification. Each Exchange consists of 211 several EAP request-response pairs. At least two separate EAP 212 conversations are needed to give the human user time to deliver the 213 OOB message between them. 215 The overall protocol starts with the Initial Exchange, which 216 comprises four EAP request-response pairs. In the Initial Exchange, 217 the server allocates an identifier to the peer, and the server and 218 peer negotiate the protocol version and cryptosuite (i.e., 219 cryptographic algorithm suite), exchange nonces and perform an 220 Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key exchange. The 221 user-assisted OOB Step then takes place. This step requires only one 222 out-of-band message either from the peer to the server or from the 223 server to the peer. While waiting for the OOB Step action, the peer 224 MAY probe the server by reconnecting to it with EAP-NOOB. If the OOB 225 Step has already taken place, the probe leads to the Completion 226 Exchange, which completes the mutual authentication and key 227 confirmation. On the other hand, if the OOB Step has not yet taken 228 place, the probe leads to the Waiting Exchange, and the peer will 229 perform another probe after a server-defined minimum waiting time. 230 The Initial Exchange and Waiting Exchange always end in EAP-Failure, 231 while the Completion Exchange may result in EAP-Success. Once the 232 peer and server have performed a successful Completion Exchange, both 233 endpoints store the created association in persistent storage, and 234 the OOB Step is not repeated. Thereafter, creation of new temporal 235 keys, ECDHE rekeying, and updates of cryptographic algorithms can be 236 achieved with the Reconnect Exchange. 238 OOB Output/Initial Exchange/ 239 Waiting Exchange 240 .-----. 241 | v 242 .------------------. Initial .------------------. 243 | | Exchange | | 244 .->| Unregistered (0) |---------------->|Waiting for OOB(1)| 245 | | (ephemeral) | | (ephemeral) | 246 | | | | | 247 | '------------------' '------------------' 248 | | | ^ 249 User Reset Completion | | | 250 | Exchange | OOB OOB 251 |<-------. .-------------------------' Input Reject/ 252 | | | | Initial 253 | | | | Exchange 254 | | v v | 255 | .------------------. Completion .------------------. 256 | | | Exchange | | 257 | | Registered (4) |<----------------| OOB Received (2) | 258 | | (persistent) | | (ephemeral) | 259 | | | | | 260 | '------------------' '------------------' 261 | | ^ 262 | Mobility/ | 263 | Timeout/ Reconnect 264 | Failure Exchange 265 | | | 266 | v | 267 | .------------------. 268 | | | 269 '--| Reconnecting (3) | 270 | (persistent) | 271 | | 272 '------------------' 274 Figure 1: EAP-NOOB server-peer association state machine 276 Figure 1 shows the association state machine, which is the same for 277 the server and for the peer. (For readability, only the main state 278 transitions are shown. The complete table of transitions can be 279 found in Appendix A.) When the peer initiates the EAP-NOOB method, 280 the server chooses the ensuing message exchange based on the 281 combination of the server and peer states. The EAP server and peer 282 are initially in the Unregistered state, in which no state 283 information needs to be stored. Before a successful Completion 284 Exchange, the server-peer association state is ephemeral in both the 285 server and peer (ephemeral states 0..2), and a timeout or error may 286 cause one or both endpoints to go back to the Unregistered state so 287 that the Initial Exchange is repeated. After the Completion Exchange 288 has resulted in EAP-Success, the association state becomes persistent 289 (persistent states 3..4). Only user reset or memory failure can 290 cause the return of the server or the peer from the persistent states 291 to the ephemeral states and to the Initial Exchange. 293 The server MUST NOT repeat a successful OOB Step with the same peer 294 except if the association with the peer is explicitly reset by the 295 user or lost due to failure of the persistent storage in the server. 296 More specifically, once the association has entered the Registered 297 state, the server MUST NOT delete the association or go back to the 298 ephemeral states 0..2 without explicit user approval. Similarly, the 299 peer MUST NOT repeat the OOB Step unless the user explicitly deletes 300 from the peer the association with the server or resets the peer to 301 the Unregistered state. The server and peer MAY implement user reset 302 of the association by deleting the state data from that endpoint. If 303 an endpoint continues to store data about the association after the 304 user reset, its behavior MUST be equivalent to having deleted the 305 association data. 307 It can happen that the peer accidentally or through user reset loses 308 its persistent state and reconnects to the server without a 309 previously allocated peer identifier. In that case, the server MUST 310 treat the peer as a new peer. The server MAY use auxiliary 311 information, such as the PeerInfo field received in the Initial 312 Exchange, to detect multiple associations with the same peer. 313 However, it MUST NOT delete or merge redundant associations without 314 user or application approval because EAP-NOOB internally has no 315 secure way of verifying that the two peers are the same physical 316 device. Similarly, the server might lose the association state 317 because of a memory failure or user reset. In that case, the only 318 way to recover is that the user also resets the peer. 320 A special feature of the EAP-NOOB method is that the server is not 321 assumed to have any a-priori knowledge of the peer. Therefore, the 322 peer initially uses the generic identity string "noob@eap-noob.arpa" 323 as its network access identifier (NAI). The server then allocates a 324 server-specific identifier to the peer. The generic NAI serves two 325 purposes: firstly, it tells the server that the peer supports and 326 expects the EAP-NOOB method and, secondly, it allows routing of the 327 EAP-NOOB sessions to a specific authentication server in an 328 Authentication, Authorization, Accounting (AAA) architecture. 330 EAP-NOOB is an unusual EAP method in that the peer has to have 331 multiple EAP conversations with the server before it can receive EAP- 332 Success. The reason is that, while EAP allows delays between the 333 request-response pairs, e.g. for repeated password entry, the user 334 delays in OOB authentication can be much longer than in password 335 trials. Moreover, EAP-NOOB supports peers with no input capability 336 in the user interface (e.g., LED light bulbs). Since users cannot 337 initiate the protocol in these devices, they have to perform the 338 Initial Exchange opportunistically and hope for the OOB Step to take 339 place within a timeout period (NoobTimeout), which is why the timeout 340 needs to be several minutes rather than seconds. To support such 341 high-latency OOB channels, the peer and server perform the Initial 342 Exchange in one EAP conversation, then allow time for the OOB message 343 to be delivered, and later perform the Waiting and Completion 344 Exchanges in different EAP conversations. 346 3.2. Protocol messages and sequences 348 This section defines the EAP-NOOB exchanges, which correspond to EAP 349 conversations. The exchanges start with a common handshake, which 350 determines the type of the following exchange. The common handshake 351 messages and the subsequent messages for each exchange type are 352 listed in the diagrams below. The diagrams also specify the data 353 fields present in each message. Each exchange comprises multiple EAP 354 request-response pairs and ends in either EAP-Failure, indicating 355 that authentication is not (yet) successful, or in EAP-Success. 357 3.2.1. Common handshake in all EAP-NOOB exchanges 359 All EAP-NOOB exchanges start with common handshake messages. The 360 handshake starts with the identity request and response that are 361 common to all EAP methods. Their purpose is to enable the AAA 362 architecture to route the EAP conversation to the EAP server and to 363 enable the EAP server to select the EAP method. The handshake then 364 continues with one EAP-NOOB request-response pair in which the server 365 discovers the peer identifier used in EAP-NOOB and the peer state. 367 In more detail, each EAP-NOOB exchange begins with the authenticator 368 sending an EAP-Request/Identity packet to the peer. From this point 369 on, the EAP conversation occurs between the server and the peer, and 370 the authenticator acts as a pass-through device. The peer responds 371 to the authenticator with an EAP-Response/Identity packet, which 372 contains the network access identifier (NAI). The authenticator, 373 acting as a pass-through device, forwards this response and the 374 following EAP conversation between the peer and the AAA architecture. 375 The AAA architecture routes the conversation to a specific AAA server 376 (called "EAP server" or simply "server" in this specification) based 377 on the realm part of the NAI. The server selects the EAP-NOOB method 378 based on the user part of the NAI, as defined in Section 3.3.1. 380 After receiving the EAP-Response/Identity message, the server sends 381 the first EAP-NOOB request (Type=1) to the peer, which responds with 382 the peer identifier (PeerId) and state (PeerState) in the range 0..3. 383 However, the peer SHOULD omit the PeerId from the response (Type=1) 384 when PeerState=0. The server then chooses the EAP-NOOB exchange, 385 i.e. the ensuing message sequence, as explained below. The peer 386 recognizes the exchange based on the message type field (Type) of the 387 next EAP-NOOB request received from the server. 389 The server MUST determine the exchange type based on the combination 390 of the peer and server states as follows (also summarized in 391 Figure 11). If either the peer or server is in the Unregistered (0) 392 state and the other is in one of the ephemeral states (0..2), the 393 server chooses the Initial Exchange. If one of the peer or server is 394 in the OOB Received (2) state and the other is either in the Waiting 395 for OOB (1) or OOB Received (2) state, the OOB Step has taken place 396 and the server chooses the Completion Exchange. If both the server 397 and peer are in the Waiting for OOB (1) state, the server chooses the 398 Waiting Exchange. If the peer is in the Reconnecting (3) state and 399 the server is in the Registered (4) or Reconnecting (3) state, the 400 server chooses the Reconnect Exchange. All other state combinations 401 are error situations where user action is required, and the server 402 SHOULD indicate such errors to the peer with the error code 2002 (see 403 Section 3.6.3). Note also that the peer MUST NOT initiate EAP-NOOB 404 when the peer is in the Registered (4) state. 406 EAP Peer Authenticator EAP Server 407 | | | 408 |<----------- EAP-Request/Identity -| | 409 | | 410 | | 411 |------------ EAP-Response/Identity -------------->| 412 | (NAI=noob@eap-noob.net) | 413 | | 414 | | 415 |<----------- EAP-Request/EAP-NOOB ----------------| 416 | (Type=1) | 417 | | 418 | | 419 |------------ EAP-Response/EAP-NOOB -------------->| 420 | (Type=1,[PeerId],PeerState=1) | 421 | | 422 | continuing with exchange-specific messages... | 424 Figure 2: Common handshake in all EAP-NOOB exchanges 426 3.2.2. Initial Exchange 428 The Initial Exchange comprises the common handshake and two further 429 EAP-NOOB request-response pairs, one for version, cryptosuite and 430 parameter negotiation and the other for the ECDHE key exchange. The 431 first EAP-NOOB request (Type=2) from the server contains a newly 432 allocated PeerId for the peer and an optional Realm. The server 433 allocates a new PeerId in the Initial Exchange regardless of any old 434 PeerId in the username part of the received NAI. The server also 435 sends in the request a list of the protocol versions (Vers) and 436 cryptosuites (Cryptosuites) it supports, an indicator of the OOB 437 channel directions it supports (Dirs), and a ServerInfo object. The 438 peer chooses one of the versions and cryptosuites. The peer sends a 439 response (Type=2) with the selected protocol version (Verp), the 440 received PeerId, the selected cryptosuite (Cryptosuitep), an 441 indicator of the OOB channel directions selected by the peer (Dirp), 442 and a PeerInfo object. In the second EAP-NOOB request and response 443 (Type=3), the server and peer exchange the public components of their 444 ECDHE keys and nonces (PKs,Ns,PKp,Np). The ECDHE keys MUST be based 445 on the negotiated cryptosuite, i.e., Cryptosuitep. The Initial 446 Exchange always ends with EAP-Failure from the server because the 447 authentication cannot yet be completed. 449 EAP Peer EAP Server 450 | ...continuing from common handshake | 451 | | 452 |<----------- EAP-Request/EAP-NOOB ----------------| 453 | (Type=2,Vers,PeerId,[Realm], | 454 | Cryptosuites,Dirs,ServerInfo) | 455 | | 456 | | 457 |------------ EAP-Response/EAP-NOOB -------------->| 458 | (Type=2,Verp,PeerId,Cryptosuitep, | 459 | Dirp,PeerInfo) | 460 | | 461 | | 462 |<----------- EAP-Request/EAP-NOOB ----------------| 463 | (Type=3,PeerId,PKs,Ns,[SleepTime]) | 464 | | 465 | | 466 |------------ EAP-Response/EAP-NOOB -------------->| 467 | (Type=3,PeerId,PKp,Np) | 468 | | 469 | | 470 |<----------- EAP-Failure -------------------------| 471 | | 473 Figure 3: Initial Exchange 475 At the conclusion of the Initial Exchange, both the server and the 476 peer move to the Waiting for OOB (1) state. 478 3.2.3. OOB Step 480 The OOB Step, labeled as OOB Output and OOB Input in Figure 1, takes 481 place after the Initial Exchange. Depending on the negotiated OOB 482 channel direction, the peer or the server outputs the OOB message 483 shown in Figure 4 or Figure 5, respectively. The data fields are the 484 PeerId, the secret nonce Noob, and the cryptographic fingerprint 485 Hoob. The contents of the data fields are defined in Section 3.3.2. 486 The OOB message is delivered to the other endpoint via a user- 487 assisted OOB channel. 489 For brevity, we will use the terms OOB sender and OOB receiver in 490 addition to the already familiar EAP server and EAP peer. If the OOB 491 message is sent in the server-to-peer direction, the OOB sender is 492 the server and the OOB receiver is the peer. On the other hand, if 493 the OOB message is sent in the peer-to-server direction, the OOB 494 sender is the peer and the OOB receiver is the server. 496 EAP Peer EAP Server 497 | | 498 |=================OOB=============================>| 499 | (PeerId,Noob,Hoob) | 500 | | 502 Figure 4: OOB Step, from peer to EAP server 504 EAP Peer EAP Server 505 | | 506 |<================OOB==============================| 507 | (PeerId,Noob,Hoob) | 508 | | 510 Figure 5: OOB Step, from EAP server to peer 512 The OOB receiver MUST compare the received value of the fingerprint 513 Hoob (see Section 3.3.2) with a value that it computes locally. This 514 integrity check ensures that the endpoints agree on contents of the 515 Initial Exchange. If the values are equal, the receiver moves to the 516 OOB Received (2) state. Otherwise, the receiver MUST reject the OOB 517 message. For usability reasons, the OOB receiver SHOULD indicate the 518 acceptance or rejection of the OOB message to the user. The receiver 519 SHOULD reject invalid OOB messages without changing its state, until 520 an application-specific number of invalid messages (OobRetries) has 521 been reached, after which the receiver SHOULD consider it an error 522 and go back to the Unregistered (0) state. 524 The server or peer MAY send multiple OOB messages with different Noob 525 values while in the Waiting for OOB (1) state. The OOB sender SHOULD 526 remember the Noob values until they expire and accept any one of them 527 in the following Completion Exchange. The Noob values sent by the 528 server expire after an application-dependent timeout (NoobTimeout), 529 and the server MUST NOT accept Noob values older than that in the 530 Completion Exchange. The RECOMMENDED value for NoobTimeout is 3600 531 seconds if there are no application-specific reasons for making it 532 shorter or longer. The Noob values sent by the peer expire as 533 defined in Section 3.2.5. 535 The OOB receiver does not accept further OOB messages after it has 536 accepted one and moved to the OOB Received (2) state. However, the 537 receiver MAY buffer redundant OOB messages in case an OOB message 538 expiry or similar error detected in the Completion Exchange causes it 539 to return to the Waiting for OOB (1) state. It is RECOMMENDED that 540 the OOB receiver notifies the user about redundant OOB messages, but 541 it MAY instead discard them silently. 543 The sender will typically generate a new Noob, and therefore a new 544 OOB message, at constant time intervals (NoobInterval). The 545 RECOMMENDED interval is NoobInterval = NoobTimeout / 2, in which case 546 the receiver of the OOB will at any given time accept either of the 547 two latest Noob values. However, the timing of the Noob generation 548 may also be based on user interaction or on implementation 549 considerations. 551 Even though not recommended (see Section 3.3), this specification 552 allows both directions to be negotiated (Dirp=3) for the OOB channel. 553 In that case, both sides SHOULD output the OOB message, and it is up 554 to the user to deliver at least one of them. 556 The details of the OOB channel implementation including the message 557 encoding are defined by the application. Appendix E gives an example 558 of how the OOB message can be encoded as a URL that may be embedded 559 in a QR code or NFC tag. 561 3.2.4. Completion Exchange 563 After the Initial Exchange, if both the server and the peer support 564 the peer-to-server direction for the OOB channel, the peer SHOULD 565 initiate the EAP-NOOB method again after an applications-specific 566 waiting time in order to probe for completion of the OOB Step. Also, 567 if both sides support the server-to-peer direction of the OOB 568 exchange and the peer receives the OOB message, it SHOULD initiate 569 the EAP-NOOB method immediately. Depending on the combination of the 570 peer and server states, the server continues with the Completion 571 Exchange or Waiting Exchange (see Section 3.2.1 on how the server 572 makes this decision). 574 The Completion Exchange comprises the common handshake and one or two 575 further EAP-NOOB request-response pairs. If the peer is in the 576 Waiting for OOB (1) state, the OOB message has been sent in the peer- 577 to-server direction. In that case, only one request-response pair 578 (Type=6) takes place. In the request, the server sends the NoobId 579 value, which the peer uses to identify the exact OOB message received 580 by the server. On the other hand, if the peer is in the OOB Received 581 (2) state, the direction of the OOB message is from server to peer. 582 In this case, two request-response pairs (Type=5 and Type=6) are 583 needed. The purpose of the first request-response pair (Type=5) is 584 that it enables the server to discover NoobId, which identifies the 585 exact OOB message received by the peer. The server returns the same 586 NoobId to the peer in the latter request. 588 In the last request-response pair (Type=6) of the Completion 589 Exchange, the server and peer exchange message authentication codes. 590 Both sides MUST compute the keys Kms and Kmp as defined in 591 Section 3.5 and the message authentication codes MACs and MACp as 592 defined in Section 3.3.2. Both sides MUST compare the received 593 message authentication code with a locally computed value. If the 594 peer finds that it has received the correct value of MACs and the 595 server finds that it has received the correct value of MACp, the 596 Completion Exchange ends in EAP-Success. Otherwise, the endpoint 597 where the comparison fails indicates this with an error message 598 (error code 4001, see Section 3.6.1) and the Completion Exchange ends 599 in EAP-Failure. 601 After successful Completion Exchange, both the server and the peer 602 move to the Registered (4) state. They also derive the output keying 603 material and store the persistent EAP-NOOB association state as 604 defined in Section 3.4 and Section 3.5. 606 It is possible that the OOB message expires before it is received. 607 In that case, the sender of the OOB message no longer recognizes the 608 NoobId that it receives in the Completion Exchange. Another reason 609 why the OOB sender might not recognize the NoobId is if the received 610 OOB message was spoofed and contained an attacker-generated Noob 611 value. The recipient of an unrecognized NoobId indicates this with 612 an error message (error code 2003, see Section 3.6.1) and the 613 Completion Exchange ends in EAP-Failure. The recipient of the error 614 message 2003 moves back to the Waiting for OOB (1) state. This state 615 transition is shown as OOB Reject in Figure 1 (even though it really 616 is a specific type of failed Completion Exchange). The sender of the 617 error message, on the other hand, stays in its previous state. 619 Although it is not expected to occur in practice, poor user interface 620 design could lead to two OOB messages delivered simultaneously, one 621 from the peer to the server and the other from the server to the 622 peer. The server detects this event in the beginning of the 623 Completion Exchange by observing that both the server and peer are in 624 the OOB Received state (2). In that case, as a tiebreaker, the 625 server MUST behave as if only the server-to-peer message had been 626 delivered. 628 EAP Peer EAP Server 629 | ...continuing from common handshake | 630 | | 631 |<----------- [ EAP-Request/EAP-NOOB ] ------------| 632 | (Type=5,PeerId) | 633 | | 634 | | 635 |------------ [ EAP-Response/EAP-NOOB ] ---------->| 636 | (Type=5,PeerId,NoobId) | 637 | | 638 | | 639 |<----------- EAP-Request/EAP-NOOB ----------------| 640 | (Type=6,PeerId,NoobId,MACs) | 641 | | 642 | | 643 |------------ EAP-Response/EAP-NOOB -------------->| 644 | (Type=6,PeerId,MACp) | 645 | | 646 | | 647 |<----------- EAP-Success -------------------------| 648 | | 650 Figure 6: Completion Exchange 652 3.2.5. Waiting Exchange 654 As explained in Section 3.2.4, the peer SHOULD probe the server for 655 completion of the OOB Step. When the combination of the peer and 656 server states indicates that the OOB message has not yet been 657 delivered, the server chooses the Waiting Exchange (see Section 3.2.1 658 on how the server makes this decision). The Waiting Exchange 659 comprises the common handshake and one further request-response pair, 660 and it ends always in EAP-Failure. 662 In order to limit the rate at which peers probe the server, the 663 server MAY send to the peer either in the Initial Exchange or in the 664 Waiting Exchange a minimum time to wait before probing the server 665 again. A peer that has not received an OOB message SHOULD wait at 666 least the server-specified minimum waiting time in seconds 667 (SleepTime) before initiating EAP again with the same server. The 668 peer uses the latest SleepTime value that it has received in or after 669 the Initial Exchange. If the server has not sent any SleepTime 670 value, the peer MUST wait for an application-specified minimum time 671 (SleepTimeDefault). 673 After the Waiting Exchange, the peer MUST discard (from its local 674 ephemeral storage) Noob values that it has sent to the server in OOB 675 messages that are older than the application-defined timeout 676 NoobTimeout (see Section 3.2.3). The peer SHOULD discard such 677 expired Noob values even if the probing failed, e.g., because of 678 failure to connect to the EAP server or incorrect message 679 authentication code. The timeout of peer-generated Noob values is 680 defined like this in order to allow the peer to probe the server once 681 after it has waited for the server-specified SleepTime. 683 If the server and peer have negotiated to use only the server-to-peer 684 direction for the OOB channel (Dirp=2), the peer SHOULD nevertheless 685 probe the server. The purpose of this is to keep the server informed 686 about the peers that are still waiting for OOB messages. The server 687 MAY set SleepTime to a high number (3600) to prevent the peer from 688 probing the server frequently. 690 EAP Peer EAP Server 691 | ...continuing from common handshake | 692 | | 693 |<----------- EAP-Request/EAP-NOOB ----------------| 694 | (Type=4,PeerId,[SleepTime]) | 695 | | 696 | | 697 |------------ EAP-Response/EAP-NOOB -------------->| 698 | (Type=4,PeerId) | 699 | | 700 | | 701 |<----------- EAP-Failure -------------------------| 702 | | 704 Figure 7: Waiting Exchange 706 3.3. Protocol data fields 708 This section defines the various identifiers and data fields used in 709 the EAP-NOOB protocol. 711 3.3.1. Peer identifier, realm and NAI 713 The server allocates a new peer identifier (PeerId) for the peer in 714 the Initial Exchange. The peer identifier MUST follow the syntax of 715 the utf8-username specified in [RFC7542]. The server MUST generate 716 the identifiers in such a way that they do not repeat and cannot be 717 guessed by the peer or third parties before the server sends them to 718 the peer in the Initial Exchange. One way to generate the 719 identifiers is to choose a random 16-byte identifier and to base64url 720 encode it without padding [RFC4648] into a 22-character ASCII string. 722 Another way to generate the identifiers is to choose a random 723 22-character alphanumeric ASCII string. It is RECOMMENDED to not use 724 identifiers longer than this because they result in longer OOB 725 messages. 727 The peer uses the allocated PeerId to identify itself to the server 728 in the subsequent exchanges. The peer MUST copy the PeerId byte-by- 729 byte from the message where it was allocated, and the server MUST 730 perform a byte-by-byte comparison between the received and the 731 previously allocated PeerID. The peer sets the PeerId value in 732 response type 1 as follows. When the peer is in the Unregistered (0) 733 state, it SHOULD omit the PeerId from response type 1. When the peer 734 is in one of the states 1..2, it MUST use the PeerId that the server 735 assigned to it in the latest Initial Exchange. When the peer is in 736 one of the persistent states 3..4, it MUST use the PeerId from its 737 persistent EAP-NOOB association. (The PeerId is written to the 738 association when the peer moves to the Registered (4) state after a 739 Completion Exchange.) 741 The default realm for the peer is "eap-noob.arpa". However, the peer 742 MAY allow the user or application to provide a different default 743 realm. Furthermore, the server MAY assign a new realm to the peer in 744 the Initial Exchange or Reconnect Exchange, in the Realm field of 745 response types 2 and 7. The Realm value MUST follow the syntax of 746 the utf8-realm specified in [RFC7542]. When the peer is in the 747 Unregistered (0) state, or when the peer is in one of the states 1..2 748 and the server did not send a Realm in the latest Initial Exchange, 749 the peer MUST use the default realm. When the peer is in one of the 750 states 1..2 and the server sent a Realm in the latest Initial 751 Exchange, the peer MUST use that realm. Finally, when the peer is in 752 one of the persistent states 3..4, it MUST use the Realm from its 753 persistent EAP-NOOB association. (The Realm is written to the 754 association when the peer moves to the Registered (4) state after a 755 Completion Exchange or Reconnect Exchange.) 757 To compose its NAI [RFC7542], the peer concatenates the string 758 "noob@" and the server-assigned realm. When no server-assigned realm 759 is available, the default value is used instead. 761 The purpose of the server-assigned realm is to enable more flexible 762 routing of the EAP sessions over the AAA infrastructure, including 763 roaming scenarios (see Appendix D). Moreover, some Authenticators or 764 AAA servers use the assigned Realm to determine peer-specific 765 connection parameters, such as isolating the peer to a specific VLAN. 766 The possibility to configure a different default realm enables 767 registration of new devices while roaming. It also enables 768 manufacturers to set up their own AAA servers for bootstrapping of 769 new peer devices. 771 The peer's PeerId and Realm are ephemeral until a successful 772 Completion Exchange takes place. Thereafter, the values become parts 773 of the persistent EAP-NOOB association, until the user resets the 774 peer and the server or until a new Realm is assigned in the Reconnect 775 Exchange. 777 3.3.2. Message data fields 779 Table 1 defines the data fields in the protocol messages. The in- 780 band messages are formatted as JSON objects [RFC8259] in UTF-8 781 encoding. The JSON member names are in the left-hand column of the 782 table. 784 +------------------+------------------------------------------------+ 785 | Data field | Description | 786 +------------------+------------------------------------------------+ 787 | Vers, Verp | EAP-NOOB protocol versions supported by the | 788 | | EAP server, and the protocol version chosen by | 789 | | the peer. Vers is a JSON array of unsigned | 790 | | integers, and Verp is an unsigned integer. | 791 | | Example values are "[1]" and "1", | 792 | | respectively. | 793 | | | 794 | PeerId | Peer identifier as defined in Section 3.3.1. | 795 | | | 796 | Realm | Peer realm as defined in Section 3.3.1. | 797 | | | 798 | PeerState | Peer state is an integer in the range 0..4 | 799 | | (see Figure 1). However, only values 0..3 are | 800 | | ever sent in the protocol messages. | 801 | | | 802 | Type | EAP-NOOB message type. The type is an integer | 803 | | in the range 0..9. EAP-NOOB requests and the | 804 | | corresponding responses share the same type | 805 | | value. | 806 | | | 807 | PKs, PKp | The public components of the ECDHE keys of the | 808 | | server and peer. PKs and PKp are sent in the | 809 | | JSON Web Key (JWK) format [RFC7517]. The | 810 | | detailed format of the JWK object is defined | 811 | | by the cryptosuite. | 812 | | | 813 | Cryptosuites, | The identifiers of cryptosuites supported by | 814 | Cryptosuitep | the server and of the cryptosuite selected by | 815 | | the peer. The server-supported cryptosuites in | 816 | | Cryptosuites are formatted as a JSON array of | 817 | | the identifier integers. The server MUST send | 818 | | a nonempty array with no repeating elements, | 819 | | ordered by decreasing priority. The peer MUST | 820 | | respond with exactly one suite in the | 821 | | Cryptosuitep value, formatted as an identifier | 822 | | integer. The registration of cryptosuites is | 823 | | specified in Section 4.1. Example values are | 824 | | "[1]" and "1", respectively. | 825 | | | 826 | Dirs, Dirp | The OOB channel directions supported by the | 827 | | server and the directions selected by the | 828 | | peer. The possible values are 1=peer-to- | 829 | | server, 2=server-to-peer, 3=both directions. | 830 | | | 831 | Dir | The actual direction of the OOB message | 832 | | (1=peer-to-server, 2=server-to-peer). This | 833 | | value is not sent over any communication | 834 | | channel but it is included in the computation | 835 | | of the cryptographic fingerprint Hoob. | 836 | | | 837 | Ns, Np | 32-byte nonces for the Initial Exchange. | 838 | | | 839 | ServerInfo | This field contains information about the | 840 | | server to be passed from the EAP method to the | 841 | | application layer in the peer. The information | 842 | | is specific to the application or to the OOB | 843 | | channel and it is encoded as a JSON object of | 844 | | at most 500 bytes. It could include, for | 845 | | example, the access-network name and server | 846 | | name or a Uniform Resource Locator (URL) | 847 | | [RFC4266] or some other information that helps | 848 | | the user to deliver the OOB message to the | 849 | | server through the out-of-band channel. | 850 | | | 851 | PeerInfo | This field contains information about the peer | 852 | | to be passed from the EAP method to the | 853 | | application layer in the server. The | 854 | | information is specific to the application or | 855 | | to the OOB channel and it is encoded as a JSON | 856 | | object of at most 500 bytes. It could include, | 857 | | for example, the peer brand, model and serial | 858 | | number, which help the user to distinguish | 859 | | between devices and to deliver the OOB message | 860 | | to the correct peer through the out-of-band | 861 | | channel. | 862 | | | 863 | SleepTime | The number of seconds for which the peer MUST | 864 | | NOT start a new execution of the EAP-NOOB | 865 | | method with the authenticator, unless the peer | 866 | | receives the OOB message or the peer is reset | 867 | | by the user. The server can use this field to | 868 | | limit the rate at which peers probe it. | 869 | | SleepTime is an unsigned integer in the range | 870 | | 0..3600. | 871 | | | 872 | Noob | 16-byte secret nonce sent through the OOB | 873 | | channel and used for the session key | 874 | | derivation. The endpoint that received the OOB | 875 | | message uses this secret in the Completion | 876 | | Exchange to authenticate the exchanged key to | 877 | | the endpoint that sent the OOB message. | 878 | | | 879 | Hoob | 16-byte cryptographic fingerprint (i.e., hash | 880 | | value) computed from all the parameters | 881 | | exchanged in the Initial Exchange and in the | 882 | | OOB message. Receiving this fingerprint over | 883 | | the OOB channel guarantees the integrity of | 884 | | the key exchange and parameter negotiation. | 885 | | Hence, it authenticates the exchanged key to | 886 | | the endpoint that receives the OOB message. | 887 | | | 888 | NoobId | 16-byte identifier for the OOB message, | 889 | | computed with a one-way function from the | 890 | | nonce Noob in the message. | 891 | | | 892 | MACs, MACp | Message authentication codes (HMAC) for mutual | 893 | | authentication, key confirmation, and | 894 | | integrity check on the exchanged information. | 895 | | The input to the HMAC is defined below, and | 896 | | the key for the HMAC is defined in | 897 | | Section 3.5. | 898 | | | 899 | Ns2, Np2 | 32-byte Nonces for the Reconnect Exchange. | 900 | | | 901 | KeyingMode | Integer indicating the key derivation method. | 902 | | 0 in the Completion Exchange, and 1..3 in the | 903 | | Reconnect Exchange. | 904 | | | 905 | PKs2, PKp2 | The public components of the ECDHE keys of the | 906 | | server and peer for the Reconnect Exchange. | 907 | | PKp2 and PKs2 are sent in the JSON Web Key | 908 | | (JWK) format [RFC7517]. The detailed format of | 909 | | the JWK object is defined by the cryptosuite. | 910 | | | 911 | MACs2, MACp2 | Message authentication codes (HMAC) for mutual | 912 | | authentication, key confirmation, and | 913 | | integrity check on the Reconnect Exchange. The | 914 | | input to the HMAC is defined below, and the | 915 | | key for the HMAC is defined in Section 3.5. | 916 | | | 917 | ErrorCode | Integer indicating an error condition. Defined | 918 | | in Section 4.3. | 919 | | | 920 | ErrorInfo | Textual error message for logging and | 921 | | debugging purposes. A UTF-8 string of at most | 922 | | 500 bytes. | 923 | | | 924 +------------------+------------------------------------------------+ 926 Table 1: Message data fields 928 It is RECOMMENDED for servers to support both OOB channel directions 929 (Dirs=3), unless the type of the OOB channel limits them to one 930 direction (Dirs=1 or Dirs=2). On the other hand, it is RECOMMENDED 931 that the peer selects only one direction (Dirp=1 or Dirp=2) even when 932 both directions (Dirp=3) would be technically possible. The reason 933 is that, if value 3 is negotiated, the user may be presented with two 934 OOB messages, one for each direction, even though only one of them 935 needs to be delivered. This can be confusing to the user. 936 Nevertheless, the EAP-NOOB protocol is designed to cope also with 937 selected value 3, in which case it uses the first delivered OOB 938 message. In the unlikely case of simultaneously delivered OOB 939 messages, the protocol prioritizes the server-to-peer direction. 941 The nonces in the in-band messages (Ns, Np, Ns2, Np2) are 32-byte 942 fresh random byte strings, and the secret nonce Noob is a 16-byte 943 fresh random byte string. All the nonces are generated by the 944 endpoint that sends the message. 946 The fingerprint Hoob and the identifier NoobId are computed with the 947 cryptographic hash function specified in the negotiated cryptosuite 948 and truncated to the 16 leftmost bytes of the output. The message 949 authentication codes (MACs, MACp, MACs2, MACp2) are computed with the 950 HMAC function [RFC2104] based on the same cryptographic hash function 951 and truncated to the 32 leftmost bytes of the output. 953 The inputs to the hash function for computing the fingerprint Hoob 954 and to the HMAC for computing MACs, MACp, MACs2 and MACp2 are JSON 955 arrays containing a fixed number (17) of elements. The array 956 elements MUST be copied to the array verbatim from the sent and 957 received in-band messages. When the element is a JSON object, its 958 members MUST NOT be reordered or re-encoded. Whitespace MUST NOT be 959 added anywhere in the JSON structure. Implementers should check that 960 their JSON library copies the elements as UTF-8 strings and does not 961 modify them in any way, and that it does not add whitespace to the 962 HMAC input. 964 The inputs for computing the fingerprint and message authentication 965 codes are the following: 967 Hoob = H(Dir,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,Cryptos 968 uitep,Dirp,[Realm],PeerInfo,0,PKs,Ns,PKp,Np,Noob). 970 NoobId = H("NoobId",Noob). 972 MACs = HMAC(Kms; 2,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,C 973 ryptosuitep,Dirp,[Realm],PeerInfo,0,PKs,Ns,PKp,Np,Noob). 975 MACp = HMAC(Kmp; 1,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,C 976 ryptosuitep,Dirp,[Realm],PeerInfo,0,PKs,Ns,PKp,Np,Noob). 978 MACs2 = HMAC(Kms2; 2,Vers,Verp,PeerId,Cryptosuites,"",[ServerInfo] 979 ,Cryptosuitep,"",[Realm],[PeerInfo],KeyingMode,[PKs2],Ns2,[PKp2],N 980 p2,"") 982 MACp2 = HMAC(Kmp2; 1,Vers,Verp,PeerId,Cryptosuites,"",[ServerInfo] 983 ,Cryptosuitep,"",[Realm],[PeerInfo],KeyingMode,[PKs2],Ns2,[PKp2],N 984 p2,"") 986 The inputs denoted with "" above are not present, and the values in 987 brackets [] are optional. Both kinds of missing input values are 988 represented by empty strings "" in the HMAC input (JSON array). 989 Realm is included in the computation of MACs and MACp if it was sent 990 or received in the preceding Initial Exchange. Each of the values in 991 brackets for the computation of Macs2 and Macp2 MUST be included if 992 it was sent or received in the same Reconnect Exchange; otherwise the 993 value is replaced by an empty string "". 995 The parameter Dir indicates the direction in which the OOB message 996 containing the Noob value is being sent (1=peer-to-server, 2=server- 997 to-peer). This field is included in the Hoob input to prevent the 998 user from accidentally delivering the OOB message back to its 999 originator in the rare cases where both OOB directions have been 1000 negotiated. The keys (Kms, Kmp, Kms2, Kmp2) for the HMACs are 1001 defined in Section 3.5. 1003 The nonces (Ns, Np, Ns2, Np2, Noob) and the hash value (NoobId) MUST 1004 be base64url encoded [RFC4648] when they are used as input to the 1005 cryptographic functions H or HMAC. These values and the message 1006 authentication codes (MACs, MACp, MACs2, MACp2) MUST also be 1007 base64url encoded when they are sent in the in-band messages. The 1008 values Noob and Hoob in the OOB channel MAY be base64url encoded if 1009 that is appropriate for the application and the OOB channel. All 1010 base64url encoding is done without padding. The base64url encoded 1011 values will naturally consume more space than the number of bytes 1012 specified above (22-character string for a 16-byte nonce and 1013 43-character string for a 32-byte nonce or message authentication 1014 code). In the key derivation in Section 3.5, on the other hand, the 1015 unencoded nonces (raw bytes) are used as input to the key derivation 1016 function. 1018 The ServerInfo and PeerInfo are JSON objects with UTF-8 encoding. 1019 The length of either encoded object as a byte array MUST NOT exceed 1020 500 bytes. The format and semantics of these objects MUST be defined 1021 by the application that uses the EAP-NOOB method. 1023 3.4. Fast reconnect and rekeying 1025 EAP-NOOB implements Fast Reconnect ([RFC3748], section 7.2.1) that 1026 avoids repeated use of the user-assisted OOB channel. 1028 The rekeying and the Reconnect Exchange may be needed for several 1029 reasons. New EAP output values MSK and EMSK may be needed because of 1030 mobility or timeout of session keys. Software or hardware failure or 1031 user action may also cause the authenticator, EAP server or peer to 1032 lose its non-persistent state data. The failure would typically be 1033 detected by the peer or authenticator when session keys are no longer 1034 accepted by the other endpoint. Changes in the supported 1035 cryptosuites in the EAP server or peer may also cause the need for a 1036 new key exchange. When the EAP server or peer detects any one of 1037 these events, it MUST change from the Registered to Reconnecting 1038 state. These state transitions are labeled Mobility/Timeout/Failure 1039 in Figure 1. The EAP-NOOB method will then perform the Reconnect 1040 Exchange the next time that EAP is triggered. 1042 3.4.1. Persistent EAP-NOOB association 1044 To enable rekeying, the EAP server and peer store the session state 1045 in persistent memory after a successful Completion Exchange. This 1046 state data, called "persistent EAP-NOOB association", MUST include at 1047 least the data fields shown in Table 2. They are used for 1048 identifying and authenticating the peer in the Reconnect Exchange. 1049 When a persistent EAP-NOOB association exists, the EAP server and 1050 peer are in the Registered state (4) or Reconnecting state (3), as 1051 shown in Figure 1. 1053 +------------------+---------------------------+--------------------+ 1054 | Data field | Value | Type | 1055 +------------------+---------------------------+--------------------+ 1056 | PeerId | Peer identifier allocated | UTF-8 string | 1057 | | by server | (typically 22 | 1058 | | | ASCII characters) | 1059 | | | | 1060 | Verp | Negotiated protocol | integer | 1061 | | version | | 1062 | | | | 1063 | Cryptosuitep | Negotiated cryptosuite | integer | 1064 | | | | 1065 | CryptosuitepPrev | Previous cryptosuite | integer | 1066 | (at peer only) | | | 1067 | | | | 1068 | Realm | Optional realm assigned | UTF-8 string | 1069 | | by server (default value | | 1070 | | is "eap-noob.arpa") | | 1071 | | | | 1072 | Kz | Persistent key material | 32 bytes | 1073 | | | | 1074 | KzPrev (at | Previous Kz value | 32 bytes | 1075 | peer only) | | | 1076 +------------------+---------------------------+--------------------+ 1078 Table 2: Persistent EAP-NOOB association 1080 3.4.2. Reconnect Exchange 1082 The server chooses the Reconnect Exchange when both the peer and the 1083 server are in a persistent state and fast reconnection is needed (see 1084 Section 3.2.1 for details). 1086 The Reconnect Exchange comprises the common handshake and three 1087 further EAP-NOOB request-response pairs, one for cryptosuite and 1088 parameter negotiation, another for the nonce and ECDHE key exchange, 1089 and the last one for exchanging message authentication codes. In the 1090 first request and response (Type=7) the server and peer negotiate a 1091 protocol version and cryptosuite in the same way as in the Initial 1092 Exchange. The server SHOULD NOT offer and the peer MUST NOT accept 1093 protocol versions or cryptosuites that it knows to be weaker than the 1094 one currently in the Cryptosuitep field of the persistent EAP-NOOB 1095 association. The server SHOULD NOT needlessly change the 1096 cryptosuites it offers to the same peer because peer devices may have 1097 limited ability to update their persistent storage. However, if the 1098 peer has different values in the Cryptosuitep and CryptosuitepPrev 1099 fields, it SHOULD also accept offers that are not weaker than 1100 CryptosuitepPrev. Note that Cryptosuitep and CryptosuitePrev from 1101 the persistent EAP-NOOB association are only used to support the 1102 negotiation as described above; all actual cryptographic operations 1103 use the negotiated cryptosuite. The request and response (Type=7) 1104 MAY additionally contain PeerInfo and ServerInfo objects. 1106 The server then determines the KeyingMode (defined in Section 3.5) 1107 based on changes in the negotiated cryptosuite and whether it desires 1108 to achieve forward secrecy or not. The server SHOULD only select 1109 KeyingMode 3 when the negotiated cryptosuite differs from the 1110 Cryptosuitep in the server's persistent EAP-NOOB association, 1111 although it is technically possible to select this values without 1112 changing the cryptosuite. In the second request and response 1113 (Type=8), the server informs the peer about the KeyingMode, and the 1114 server and peer exchange nonces (Ns2, Np2). When KeyingMode is 2 or 1115 3 (rekeying with ECDHE), they also exchange public components of 1116 ECDHE keys (PKs2, PKp2). The server ECDHE key MUST be fresh, i.e., 1117 not previously used with the same peer, and the peer ECDHE key SHOULD 1118 be fresh, i.e., not previously used. 1120 In the third and final request and response (Type=9), the server and 1121 peer exchange message authentication codes. Both sides MUST compute 1122 the keys Kms2 and Kmp2 as defined in Section 3.5 and the message 1123 authentication codes MACs2 and MACp2 as defined in Section 3.3.2. 1124 Both sides MUST compare the received message authentication code with 1125 a locally computed value. 1127 The rules by which the peer compares the received MACs2 are non- 1128 trivial because, in addition to authenticating the current exchange, 1129 MACs2 may confirm the success or failure of a recent cryptosuite 1130 upgrade. The peer processes the final request (Type=9) as follows: 1132 1. The peer first compares the received MACs2 value with one it 1133 computed using the Kz stored in the persistent EAP-NOOB 1134 association. If the received and computed values match, the peer 1135 deletes any data stored in the CryptosuitepPrev and KzPrev fields 1136 of the persistent EAP-NOOB association. It does this because the 1137 received MACs2 confirms that the peer and server share the same 1138 Cryptosuitep and Kz, and any previous values must no longer be 1139 accepted. 1141 2. If, on the other hand, the peer finds that the received MACs2 1142 value does not match the one it computed locally with Kz, the 1143 peer checks whether the KzPrev field in the persistent EAP-NOOB 1144 association stores a key. If it does, the peer repeats the key 1145 derivation (Section 3.5) and local MACs2 computation 1146 (Section 3.3.2) using KzPrev in place of Kz. If this second 1147 computed MACs2 matches the received value, the match indicates 1148 synchronization failure caused by the loss of the last response 1149 (Type=9) in a previously attempted cryptosuite upgrade. In this 1150 case, the peer rolls back that upgrade by overwriting 1151 Cryptosuitep with CryptosuitepPrev and Kz with KzPrev in the 1152 persistent EAP-NOOB association. It also clears the 1153 CryptosuitepPrev and KzPrev fields. 1155 3. If the received MACs2 matched one of the locally computed values, 1156 the peer proceeds to send the final response (Type=9). The peer 1157 also moves to the Registered (4) state. When KeyingMode is 1 or 1158 2, the peer stops here. When KeyingMode is 3, the peer also 1159 updates the persistent EAP-NOOB association with the negotiated 1160 Cryptosuitep and the newly-derived Kz value. To prepare for 1161 possible synchronization failure caused by the loss of the final 1162 response (Type=9) during cryptosuite upgrade, the peer copies the 1163 old Cryptosuitep and Kz values in the persistent EAP-NOOB 1164 association to the CryptosuitepPrev and KzPrev fields. 1166 4. Finally, if the peer finds that the received MACs2 does not match 1167 either of the two values that it computed locally (or one value 1168 if no KzPrev was stored), the peer sends an error message (error 1169 code 4001, see Section 3.6.1), which causes the Reconnect 1170 Exchange to end in EAP-Failure. 1172 The server rules for processing the final message are simpler than 1173 the peer rules because the server does not store previous keys and it 1174 never rolls back a cryptosuite upgrade. Upon receiving the final 1175 response (Type=9), the server compares the received value of MACp2 1176 with one it computes locally. If the values match, the Reconnect 1177 Exchange ends in EAP-Success. When KeyingMode is 3, the server also 1178 updates Cryptosuitep and Kz in the persistent EAP-NOOB association. 1179 On the other hand, if the server finds that the values do not match, 1180 it sends an error message (error code 4001), and the Reconnect 1181 Exchange ends in EAP-Failure. 1183 The endpoints MAY send updated Realm, ServerInfo and PeerInfo objects 1184 in the Reconnect Exchange. When there is no update to the values, 1185 they SHOULD omit this information from the messages. If the Realm 1186 was sent, each side updates Realm in the persistent EAP-NOOB 1187 association when moving to the Registered (4) state. 1189 EAP Peer EAP Server 1190 | ...continuing from common handshake | 1191 | | 1192 |<----------- EAP-Request/EAP-NOOB ----------------| 1193 | (Type=7,Vers,PeerId,Cryptosuites, | 1194 | [Realm],[ServerInfo]) | 1195 | | 1196 | | 1197 |------------ EAP-Response/EAP-NOOB -------------->| 1198 | (Type=7,Verp,PeerId,Cryptosuitep,[PeerInfo])| 1199 | | 1200 | | 1201 |<----------- EAP-Request/EAP-NOOB ----------------| 1202 | (Type=8,PeerId,KeyingMode,[PKs2],Ns2) | 1203 | | 1204 | | 1205 |------------ EAP-Response/EAP-NOOB -------------->| 1206 | (Type=8,PeerId,[PKp2],Np2) | 1207 | | 1208 | | 1209 |<----------- EAP-Request/EAP-NOOB ----------------| 1210 | (Type=9,PeerId,MACs2) | 1211 | | 1212 | | 1213 |------------ EAP-Response/EAP-NOOB -------------->| 1214 | (Type=9,PeerId,MACp2) | 1215 | | 1216 | | 1217 |<----------- EAP-Success -------------------------| 1218 | | 1220 Figure 8: Reconnect Exchange 1222 3.4.3. User reset 1224 As shown in the association state machine in Figure 1, the only 1225 specified way for the association to return from the Registered state 1226 (4) to the Unregistered state (0) is through user-initiated reset. 1227 After the reset, a new OOB message will be needed to establish a new 1228 association between the EAP server and peer. Typical situations in 1229 which the user reset is required are when the other side has 1230 accidentally lost the persistent EAP-NOOB association data, or when 1231 the peer device is decommissioned. 1233 The server could detect that the peer is in the Registered or 1234 Reconnecting state but the server itself is in one of the ephemeral 1235 states 0..2 (including situations where the server does not recognize 1236 the PeerId). In this case, effort should be made to recover the 1237 persistent server state, for example, from a backup storage - 1238 especially if many peer devices are similarly affected. If that is 1239 not possible, the EAP server SHOULD log the error or notify an 1240 administrator. The only way to continue from such a situation is by 1241 having the user reset the peer device. 1243 On the other hand, if the peer is in any of the ephemeral states 1244 0..2, including the Unregistered state, the server will treat the 1245 peer as a new peer device and allocate a new PeerId to it. The 1246 PeerInfo can be used by the user as a clue to which physical device 1247 has lost its state. However, there is no secure way of matching the 1248 "new" peer with the old PeerId without repeating the OOB Step. This 1249 situation will be resolved when the user performs the OOB Step and, 1250 thus, identifies the physical peer device. The server user interface 1251 MAY support situations where the "new" peer is actually a previously 1252 registered peer that has been reset by a user or otherwise lost its 1253 persistent data. In those cases, the user could choose to merge the 1254 new peer identity with the old one in the server. The alternative is 1255 to treat the device just like a new peer. 1257 3.5. Key derivation 1259 EAP-NOOB derives the EAP output values MSK and EMSK and other secret 1260 keying material from the output of an Ephemeral Elliptic Curve 1261 Diffie-Hellman (ECDHE) algorithm following the NIST specification 1262 [NIST-DH]. In NIST terminology, we use a C(2e, 0s, ECC CDH) scheme, 1263 i.e., two ephemeral keys and no static keys. In the Initial and 1264 Reconnect Exchanges, the server and peer compute the ECDHE shared 1265 secret Z as defined in section 6.1.2.2 of the NIST specification 1266 [NIST-DH]. In the Completion and Reconnect Exchanges, the server and 1267 peer compute the secret keying material from Z with the single-step 1268 key derivation function (KDF) defined in section 5.8.1 of the NIST 1269 specification. The hash function H for KDF is taken from the 1270 negotiated cryptosuite. 1272 +------------+------------------------------------------------------+ 1273 | KeyingMode | Description | 1274 +------------+------------------------------------------------------+ 1275 | 0 | Completion Exchange (always with ECDHE) | 1276 | | | 1277 | 1 | Reconnect Exchange, rekeying without ECDHE | 1278 | | | 1279 | 2 | Reconnect Exchange, rekeying with ECHDE, no change | 1280 | | in cryptosuite | 1281 | | | 1282 | 3 | Reconnect Exchange, rekeying with ECDHE, new | 1283 | | cryptosuite negotiated | 1284 +------------+------------------------------------------------------+ 1286 Table 3: Keying modes 1288 The key derivation has four different modes (KeyingMode), which are 1289 specified in Table 3. Table 4 defines the inputs to KDF in each 1290 KeyingMode. 1292 In the Completion Exchange (KeyingMode=0), the input Z comes from the 1293 preceding Initial exchange. KDF takes some additional inputs 1294 (OtherInfo), for which we use the concatenation format defined in 1295 section 5.8.1.2.1 of the NIST specification [NIST-DH]. OtherInfo 1296 consists of the AlgorithmId, PartyUInfo, PartyVInfo, and SuppPrivInfo 1297 fields. The first three fields are fixed-length bit strings, and 1298 SuppPrivInfo is a variable-length string with a one-byte Datalength 1299 counter. AlgorithmId is the fixed-length 8-byte ASCII string "EAP- 1300 NOOB". The other input values are the server and peer nonces. In 1301 the Completion Exchange, the inputs also include the secret nonce 1302 Noob from the OOB message. 1304 In the simplest form of the Reconnect Exchange (KeyingMode=1), fresh 1305 nonces are exchanged but no ECDHE keys are sent. In this case, input 1306 Z to the KDF is replaced with the shared key Kz from the persistent 1307 EAP-NOOB association. The result is rekeying without the 1308 computational cost of the ECDHE exchange, but also without forward 1309 secrecy. 1311 When forward secrecy is desired in the Reconnect Exchange 1312 (KeyingMode=2 or KeyingMode=3), both nonces and ECDHE keys are 1313 exchanged. Input Z is the fresh shared secret from the ECDHE 1314 exchange with PKs2 and PKp2. The inputs also include the shared 1315 secret Kz from the persistent EAP-NOOB association. This binds the 1316 rekeying output to the previously authenticated keys. 1318 +--------------+--------------+------------------------+------------+ 1319 | KeyingMode | KDF input | Value | Length | 1320 | | field | | (bytes) | 1321 +--------------+--------------+------------------------+------------+ 1322 | 0 | Z | ECDHE shared secret | variable | 1323 | Completion | | from PKs and PKp | | 1324 | | AlgorithmId | "EAP-NOOB" | 8 | 1325 | | PartyUInfo | Np | 32 | 1326 | | PartyVInfo | Ns | 32 | 1327 | | SuppPubInfo | (not allowed) | | 1328 | | SuppPrivInfo | Noob | 16 | 1329 | | | | | 1330 | 1 | Z | Kz | 32 | 1331 | Reconnect, | AlgorithmId | "EAP-NOOB" | 8 | 1332 | rekeying | PartyUInfo | Np2 | 32 | 1333 | without | PartyVInfo | Ns2 | 32 | 1334 | ECDHE | SuppPubInfo | (not allowed) | | 1335 | | SuppPrivInfo | (null) | 0 | 1336 | | | | | 1337 | 2 or 3 | Z | ECDHE shared secret | variable | 1338 | Reconnect, | | from PKs2 and PKp2 | | 1339 | rekeying, | AlgorithmId | "EAP-NOOB" | 8 | 1340 | with ECDHE, | PartyUInfo | Np2 | 32 | 1341 | same or new | PartyVInfo | Ns2 | 32 | 1342 | cryptosuite | SuppPubInfo | (not allowed) | | 1343 | | SuppPrivInfo | Kz | 32 | 1344 +--------------+--------------+------------------------+------------+ 1346 Table 4: Key derivation input 1348 Table 5 defines how the output bytes of KDF are used. In addition to 1349 the EAP output values MSK and EMSK, the server and peer derive 1350 another shared secret key AMSK, which MAY be used for application- 1351 layer security. Further output bytes are used internally by EAP-NOOB 1352 for the message authentication keys (Kms, Kmp, Kms2, Kmp2). 1354 The Completion Exchange (KeyingMode=0) produces the shared secret Kz, 1355 which the server and peer store in the persistent EAP-NOOB 1356 association. When a new cryptosuite is negotiated in the Reconnect 1357 Exchange (KeyingMode=3), it similarly produces a new Kz. In that 1358 case, the server and peer update both the cryptosuite and Kz in the 1359 persistent EAP-NOOB association. Additionally, the peer stores the 1360 previous Cryptosuitep and Kz values in the CryptosuitepPrev and 1361 KzPrev fields of the persistent EAP-NOOB association. 1363 +-----------------+------------------+----------+----------------+ 1364 | KeyingMode | KDF output bytes | Used as | Length (bytes) | 1365 +-----------------+------------------+----------+----------------+ 1366 | 0 | 0..63 | MSK | 64 | 1367 | Completion | 64..127 | EMSK | 64 | 1368 | | 128..191 | AMSK | 64 | 1369 | | 192..223 | MethodId | 32 | 1370 | | 224..255 | Kms | 32 | 1371 | | 256..287 | Kmp | 32 | 1372 | | 288..319 | Kz | 32 | 1373 | | | | | 1374 | 1 or 2 | 0..63 | MSK | 64 | 1375 | Reconnect, | 64..127 | EMSK | 64 | 1376 | rekeying | 128..191 | AMSK | 64 | 1377 | without ECDHE, | 192..223 | MethodId | 32 | 1378 | or with ECDHE | 224..255 | Kms2 | 32 | 1379 | and unchanged | 256..287 | Kmp2 | 32 | 1380 | cryptosuite | | | | 1381 | | | | | 1382 | | | | | 1383 | 3 Reconnect, | 0..63 | MSK | 64 | 1384 | rekeying | 64..127 | EMSK | 64 | 1385 | with ECDHE, | 128..191 | AMSK | 64 | 1386 | new cryptosuite | 192..223 | MethodId | 32 | 1387 | | 224..255 | Kms2 | 32 | 1388 | | 256..287 | Kmp2 | 32 | 1389 | | 288..319 | Kz | 32 | 1390 +-----------------+------------------+----------+----------------+ 1392 Table 5: Key derivation output 1394 Finally, every EAP method must export a Server-Id, Peer-Id and 1395 Session-Id [RFC5247]. In EAP-NOOB, the exported Peer-Id is the 1396 PeerId which the server has assigned to the peer. The exported 1397 Server-Id is a zero-length string (i.e., null string) because EAP- 1398 NOOB neither knows nor assigns any server identifier. The exported 1399 Session-Id is created by concatenating the Type-Code xxx (TBA) with 1400 the MethodId, which is obtained from the KDF output as shown in 1401 Table 5. 1403 3.6. Error handling 1405 Various error conditions in EAP-NOOB are handled by sending an error 1406 notification message (Type=0) instead of the expected next EAP 1407 request or response message. Both the EAP server and the peer may 1408 send the error notification, as shown in Figure 9 and Figure 10. 1409 After sending or receiving an error notification, the server MUST 1410 send an EAP-Failure (as required by [RFC3748] section 4.2). The 1411 notification MAY contain an ErrorInfo field, which is a UTF-8 encoded 1412 text string with a maximum length of 500 bytes. It is used for 1413 sending descriptive information about the error for logging and 1414 debugging purposes. 1416 EAP Peer EAP Server 1417 ... ... 1418 | | 1419 |<----------- EAP-Request/EAP-NOOB ----------------| 1420 | (Type=0,[PeerId],ErrorCode,[ErrorInfo]) | 1421 | | 1422 | | 1423 |<----------- EAP-Failure -------------------------| 1424 | | 1426 Figure 9: Error notification from server to peer 1428 EAP Peer EAP Server 1429 ... ... 1430 | | 1431 |------------ EAP-Response/EAP-NOOB -------------->| 1432 | (Type=0,[PeerId],ErrorCode,[ErrorInfo]) | 1433 | | 1434 | | 1435 |<----------- EAP-Failure -------------------------| 1436 | | 1438 Figure 10: Error notification from peer to server 1440 After the exchange fails due to an error notification, the server and 1441 peer set the association state as follows. In the Initial Exchange, 1442 both the sender and recipient of the error notification MUST set the 1443 association state to the Unregistered (0) state. In the Waiting and 1444 Completion Exchanges, each side MUST remain in its old state as if 1445 the failed exchange had not taken place, with the exception that the 1446 recipient of error code 2003 processes it as specified in 1447 Section 3.2.4. In the Reconnect Exchange, both sides MUST set the 1448 association state to the Reconnecting (3) state. 1450 Errors that occur in the OOB channel are not explicitly notified in- 1451 band. 1453 3.6.1. Invalid messages 1455 If the NAI structure is invalid, the server SHOULD send the error 1456 code 1001 to the peer. The recipient of an EAP-NOOB request or 1457 response SHOULD send the following error codes back to the sender: 1458 1002 if it cannot parse the message as a JSON object or the top-level 1459 JSON object has missing or unrecognized members; 1003 if a data field 1460 has an invalid value, such as an integer out of range, and there is 1461 no more specific error code available; 1004 if the received message 1462 type was unexpected in the current state; 2004 if the PeerId has an 1463 unexpected value; 2003 if the NoobId is not recognized; and 1007 if 1464 the ECDHE key is invalid. 1466 3.6.2. Unwanted peer 1468 The preferred way for the EAP server to rate limit EAP-NOOB 1469 connections from a peer is to use the SleepTime parameter in the 1470 Waiting Exchange. However, if the EAP server receives repeated EAP- 1471 NOOB connections from a peer which apparently should not connect to 1472 this server, the server MAY indicate that the connections are 1473 unwanted by sending the error code 2001. After receiving this error 1474 message, the peer MAY refrain from reconnecting to the same EAP 1475 server and, if possible, both the EAP server and peer SHOULD indicate 1476 this error condition to the user or server administrator. However, 1477 in order to avoid persistent denial of service, the peer is not 1478 required to stop entirely from reconnecting to the server. 1480 3.6.3. State mismatch 1482 In the states indicated by "-" in Figure 11 in Appendix A, user 1483 action is required to reset the association state or to recover it, 1484 for example, from backup storage. In those cases, the server sends 1485 the error code 2002 to the peer. If possible, both the EAP server 1486 and peer SHOULD indicate this error condition to the user or server 1487 administrator. 1489 3.6.4. Negotiation failure 1491 If there is no matching protocol version, the peer sends the error 1492 code 3001 to the server. If there is no matching cryptosuite, the 1493 peer sends the error code 3002 to the server. If there is no 1494 matching OOB direction, the peer sends the error code 3003 to the 1495 server. 1497 In practice, there is no way of recovering from these errors without 1498 software or hardware changes. If possible, both the EAP server and 1499 peer SHOULD indicate these error conditions to the user. 1501 3.6.5. Cryptographic verification failure 1503 If the receiver of the OOB message detects an unrecognized PeerId or 1504 incorrect fingerprint (Hoob) in the OOB message, the receiver MUST 1505 remain in the Waiting for OOB state (1) as if no OOB message was 1506 received. The receiver SHOULD indicate the failure to accept the OOB 1507 message to the user. No in-band error message is sent. 1509 Note that if the OOB message was delivered from the server to the 1510 peer and the peer does not recognize the PeerId, the likely cause is 1511 that the user has unintentionally delivered the OOB message to the 1512 wrong peer device. If possible, the peer SHOULD indicate this to the 1513 user; however, the peer device may not have the capability for many 1514 different error indications to the user and it MAY use the same 1515 indication as in the case of an incorrect fingerprint. 1517 The rationale for the above is that the invalid OOB message could 1518 have been presented to the receiver by mistake or intentionally by a 1519 malicious party and, thus, it should be ignored in the hope that the 1520 honest user will soon deliver a correct OOB message. 1522 If the EAP server or peer detects an incorrect message authentication 1523 code (MACs, MACp, MACs2, MACp2), it sends the error code 4001 to the 1524 other side. As specified in the beginning of Section 3.6, the failed 1525 Completion Exchange will not result in server or peer state changes 1526 while an error in the Reconnect Exchange will put both sides to the 1527 Reconnecting (3) state and thus lead to another reconnect attempt. 1529 The rationale for this is that the invalid cryptographic message may 1530 have been spoofed by a malicious party and, thus, it should be 1531 ignored. In particular, a spoofed message on the in-band channel 1532 should not force the honest user to perform the OOB Step again. In 1533 practice, however, the error may be caused by other failures, such as 1534 a software bug. For this reason, the EAP server MAY limit the rate 1535 of peer connections with SleepTime after the above error. Also, 1536 there SHOULD be a way for the user to reset the peer to the 1537 Unregistered state (0), so that the OOB Step can be repeated as the 1538 last resort. 1540 3.6.6. Application-specific failure 1542 Applications MAY define new error messages for failures that are 1543 specific to the application or to one type of OOB channel. They MAY 1544 also use the generic application-specific error code 5001, or the 1545 error codes 5002 and 5004, which have been reserved for indicating 1546 invalid data in the ServerInfo and PeerInfo fields, respectively. 1547 Additionally, anticipating OOB channels that make use of a URL, the 1548 error code 5003 has been reserved for indicating invalid server URL. 1550 4. IANA Considerations 1552 This section provides guidance to the Internet Assigned Numbers 1553 Authority (IANA) regarding registration of values related to the EAP- 1554 NOOB protocol, in accordance with [RFC8126]. 1556 The EAP Method Type number for EAP-NOOB needs to be assigned. 1558 This memo also requires IANA to create new registries as defined in 1559 the following subsections. 1561 4.1. Cryptosuites 1563 Cryptosuites are identified by an integer. Each cryptosuite MUST 1564 specify an ECDHE curve for the key exchange, encoding of the ECDHE 1565 public key as a JWK object, and a cryptographic hash function for the 1566 fingerprint and HMAC computation and key derivation. The hash value 1567 output by the cryptographic hash function MUST be at least 32 bytes 1568 in length. The following suites are defined by EAP-NOOB: 1570 +-------------+-----------------------------------------------------+ 1571 | Cryptosuite | Algorithms | 1572 +-------------+-----------------------------------------------------+ 1573 | 1 | ECDHE curve Curve25519 [RFC7748], public-key format | 1574 | | [RFC7517] Section 6.2.1, hash function SHA-256 | 1575 | | [RFC6234] | 1576 | 2 | ECDHE curve NIST P-256 [FIPS186-4], public-key | 1577 | | format [RFC7517] Section 6.2.1, hash function | 1578 | | SHA-256 [RFC6234] | 1579 +-------------+-----------------------------------------------------+ 1581 Table 6: EAP-NOOB cryptosuites 1583 EAP-NOOB implementations MUST support Cryptosuite 1. Support for 1584 Cryptosuite 2 is RECOMMENDED. An example of Cryptosuite 1 public-key 1585 encoded as a JWK object is given below (line breaks are for 1586 readability only). 1588 "jwk":{"kty":"EC","crv":"Curve25519","x":"3p7bfXt9wbTTW2HC7OQ1Nz- 1589 DQ8hbeGdNrfx-FG-IK08"} 1591 Assignment of new values for new cryptosuites MUST be done through 1592 IANA with "Specification Required" and "IESG Approval" as defined in 1593 [RFC8126]. 1595 4.2. Message Types 1597 EAP-NOOB request and response pairs are identified by an integer 1598 Message Type. The following Message Types are defined by EAP-NOOB: 1600 +----------+------------+-------------------------------------------+ 1601 | Message | Used in | Purpose | 1602 | Type | Exchange | | 1603 +----------+------------+-------------------------------------------+ 1604 | 1 | All | PeerId and PeerState discovery | 1605 | | exchanges | | 1606 | | | | 1607 | 2 | Initial | Version, cryptosuite and parameter | 1608 | | | negotiation | 1609 | | | | 1610 | 3 | Initial | Exchange of ECDHE keys and nonces | 1611 | | | | 1612 | 4 | Waiting | Indication to peer that the server has | 1613 | | | not yet received an OOB message | 1614 | | | | 1615 | 5 | Completion | NoobId discovery | 1616 | | | | 1617 | 6 | Completion | Authentication and key confirmation with | 1618 | | | HMAC | 1619 | | | | 1620 | 7 | Reconnect | Version, cryptosuite, and parameter | 1621 | | | negotiation | 1622 | | | | 1623 | 8 | Reconnect | Exchange of ECDHE keys and nonces | 1624 | | | | 1625 | 9 | Reconnect | Authentication and key confirmation with | 1626 | | | HMAC | 1627 | | | | 1628 | 0 | Error | Error notification | 1629 | | | | 1630 +----------+------------+-------------------------------------------+ 1632 Table 7: EAP-NOOB Message Types 1634 Assignment of new values for new Message Types MUST be done through 1635 IANA with "Expert Review" as defined in [RFC8126]. 1637 4.3. Error codes 1639 The error codes defined by EAP-NOOB are listed in Table 8. 1641 +------------+----------------------------------------+ 1642 | Error code | Purpose | 1643 +------------+----------------------------------------+ 1644 | 1001 | Invalid NAI | 1645 | 1002 | Invalid message structure | 1646 | 1003 | Invalid data | 1647 | 1004 | Unexpected message type | 1648 | 1007 | Invalid ECDHE key | 1649 | 2001 | Unwanted peer | 1650 | 2002 | State mismatch, user action required | 1651 | 2003 | Unrecognized OOB message identifier | 1652 | 2004 | Unexpected peer identifier | 1653 | 3001 | No mutually supported protocol version | 1654 | 3002 | No mutually supported cryptosuite | 1655 | 3003 | No mutually supported OOB direction | 1656 | 4001 | HMAC verification failure | 1657 | 5001 | Application-specific error | 1658 | 5002 | Invalid server info | 1659 | 5003 | Invalid server URL | 1660 | 5004 | Invalid peer info | 1661 | 6001-6999 | Private and experimental use | 1662 +------------+----------------------------------------+ 1664 Table 8: EAP-NOOB error codes 1666 Assignment of new error codes MUST be done through IANA with 1667 "Specification Required" and "IESG Approval" as defined in [RFC8126], 1668 with the exception of the range 6001-6999. This range is reserved 1669 for "Private Use" and "Experimental Use", both locally and on the 1670 open Internet. 1672 4.4. Domain name reservation considerations 1674 The special-use domain "eap-noob.arpa" should be registered in the 1675 .arpa registry (). The 1676 considerations required by [RFC6761] for registering this special-use 1677 domain name are the following: 1679 o Users: Non-admin users are not expected to encounter this name or 1680 recognize it as special. AAA administrators may need to recognize 1681 the name. 1683 o Application Software: Application software is not expected to 1684 recognize this domain name as special. 1686 o Name Resolution APIs and Libraries: Name resolution APIs and 1687 libraries are not expected to recognize this domain name as 1688 special. 1690 o Caching DNS Servers: Caching servers are not expected to recognize 1691 this domain name as special. 1693 o Authoritative DNS Servers: Authoritative DNS servers MUST respond 1694 to queries for "eap-noob.arpa" with NXDOMAIN. 1696 o DNS Server Operators: Except for the authoritative DNS server, 1697 there are no special requirements for the operators. 1699 o DNS Registries/Registrars: There are no special requirements for 1700 DNS registrars. 1702 5. Implementation Status 1704 This section records the status of known implementations of the 1705 protocol defined by this specification at the time of posting of this 1706 Internet-Draft, and is based on a proposal described in [RFC7942]. 1707 The description of implementations in this section is intended to 1708 assist the IETF in its decision processes in progressing drafts to 1709 RFCs. Please note that the listing of any individual implementation 1710 here does not imply endorsement by the IETF. Furthermore, no effort 1711 has been spent to verify the information presented here that was 1712 supplied by IETF contributors. This is not intended as, and must not 1713 be construed to be, a catalog of available implementations or their 1714 features. Readers are advised to note that other implementations may 1715 exist. 1717 5.1. Implementation with wpa_supplicant and hostapd 1719 o Responsible Organization: Aalto University 1721 o Location: 1723 o Coverage: This implementation includes all of the features 1724 described in the current specification. The implementation 1725 supports two dimensional QR codes and NFC as example out-of-band 1726 (OOB) channels. 1728 o Level of Maturity: Alpha 1730 o Version compatibility: Version 06 of the draft implemented 1732 o Licensing: BSD 1734 o Contact Information: Tuomas Aura, tuomas.aura@aalto.fi 1736 5.2. Implementation on Contiki 1738 o Responsible Organization: University of Murcia and Aalto 1739 University 1741 o Location: 1743 o Coverage: This implementation includes all of the features 1744 described in the current specification. The implementation uses a 1745 blinking LED light as the out-of-band (OOB) channel. 1747 o Level of Maturity: Alpha 1749 o Version compatibility: Version 05 of the draft implemented 1751 o Licensing: BSD 1753 o Contact Information: Eduardo Ingles, eduardo.ingles@um.es 1755 5.3. Protocol modeling 1757 The current EAP-NOOB specification has been modeled with the mCRL2 1758 formal specification language [mcrl2]. The model 1759 was used mainly for simulating the protocol behavior and for 1761 verifying basic safety and liveness properties as part of the 1762 specification process. For example, we verified the correctness of 1763 the tiebreaking mechanism when two OOB messages are received 1764 simultaneously, one in each direction. We also verified that a man- 1765 in-the-middle attacker cannot cause persistent failure by spoofing a 1766 finite number of messages in the Reconnect Exchange. Additionally, 1767 the protocol has been modeled with the ProVerif [proverif] tool. 1768 This model was used to verify security 1770 properties such as mutual authentication. 1772 6. Security considerations 1774 EAP-NOOB is an authentication and key derivation protocol and, thus, 1775 security considerations can be found in most sections of this 1776 specification. In the following, we explain the protocol design and 1777 highlight some other special considerations. 1779 6.1. Authentication principle 1781 EAP-NOOB establishes a shared secret with an authenticated ECDHE key 1782 exchange. The mutual authentication in EAP-NOOB is based on two 1783 separate features, both conveyed in the OOB message. The first 1784 authentication feature is the secret nonce Noob. The peer and server 1785 use this secret in the Completion Exchange to mutually authenticate 1786 the session key previously created with ECDHE. The message 1787 authentication codes computed with the secret nonce Noob are alone 1788 sufficient for authenticating the key exchange. The second 1789 authentication feature is the integrity-protecting fingerprint Hoob. 1790 Its purpose is to prevent impersonation and man-in-the-middle attacks 1791 even in situations where the attacker is able to eavesdrop on the OOB 1792 channel and the nonce Noob is compromised. In some human-assisted 1793 OOB channels, such as human-perceptible audio or a user-typed URL, it 1794 may be easier to detect tampering than disclosure of the OOB message, 1795 and such applications benefit from the second authentication feature. 1797 The additional security provided by the cryptographic fingerprint 1798 Hoob is somewhat intricate to understand. The endpoint that receives 1799 the OOB message uses Hoob to verify the integrity of the ECDHE 1800 exchange. Thus, the OOB receiver can detect impersonation and man- 1801 in-the-middle attacks that may have happened on the in-band channel. 1802 The other endpoint, however, is not equally protected because the OOB 1803 message and fingerprint are sent only in one direction. Some 1804 protection to the OOB sender is afforded by the fact that the user 1805 may notice the failure of the association at the OOB receiver and 1806 therefore reset the OOB sender. Other device-pairing protocols have 1807 solved similar situations by requiring the user to confirm to the OOB 1808 sender that the association was accepted by the OOB receiver, e.g., 1809 with a button press on the sender side. Applications MAY implement 1810 EAP-NOOB in this way. Nevertheless, since EAP-NOOB was designed to 1811 work with strictly one-directional OOB communication and the 1812 fingerprint is only the second authentication feature, the EAP-NOOB 1813 specification does not mandate such explicit confirmation to the OOB 1814 sender. 1816 To summarize, EAP-NOOB uses the combined protection of the secret 1817 nonce Noob and the cryptographic fingerprint Hoob, both conveyed in 1818 the OOB message. The secret nonce Noob alone is sufficient for 1819 mutual authentication, unless the attacker can eavesdrop on it from 1820 the OOB channel. Even if an attacker is able to eavesdrop on the 1821 secret nonce Noob, it nevertheless cannot perform a full man-in-the- 1822 middle attack on the in-band channel because a mismatching 1823 fingerprint would alert the OOB receiver, which would reject the OOB 1824 message. The attacker that eavesdropped on the secret nonce can 1825 impersonate the OOB receiver to the OOB sender. If it does, the 1826 association will appear to be complete only on the OOB sender side, 1827 and such situations have to be resolved by the user by resetting the 1828 OOB sender to the initial state. 1830 The expected use cases for EAP-NOOB are ones where it replaces a 1831 user-entered access credential in IoT appliances. In wireless 1832 network access without EAP, the user-entered credential is often a 1833 passphrase that is shared by all the network stations. The advantage 1834 of an EAP-based solution, including EAP-NOOB, is that it establishes 1835 a different master secret for each peer device, which makes the 1836 system more resilient against device compromise. Another advantage 1837 is that it is possible to revoke the security association for an 1838 individual device on the server side. 1840 Forward secrecy in EAP-NOOB is optional. The Reconnect Exchange in 1841 EAP-NOOB provides forward secrecy only if both the server and peer 1842 send their fresh ECDHE keys. This allows both the server and the 1843 peer to limit the frequency of the costly computation that is 1844 required for forward secrecy. The server MAY adjust the frequency of 1845 its attempts at ECDHE rekeying based on what it knows about the 1846 peer's computational capabilities. 1848 The users delivering the OOB messages will often authenticate 1849 themselves to the EAP server, e.g., by logging into a secure web page 1850 or API. In this case, the server can reliably associate the peer 1851 device with the user account. Applications that make use of EAP-NOOB 1852 can use this information for configuring the initial owner of the 1853 freshly-registered device. 1855 6.2. Cloning of Devices 1857 6.3. Identifying correct endpoints 1859 Potential weaknesses in EAP-NOOB arise from the fact that the user 1860 must identify physically the correct peer device. If the attacker is 1861 able to trick the user into delivering the OOB message to or from the 1862 wrong peer device, the server may create an association with the 1863 wrong peer. This reliance on the user in identifying the correct 1864 endpoints is an inherent property of user-assisted out-of-band 1865 authentication. 1867 It is, however, not possible to exploit accidental delivery of the 1868 OOB message to the wrong device when the user makes an unexpected 1869 mistake. This is because the wrong peer device would not have 1870 prepared for the attack by performing the Initial Exchange with the 1871 server. In comparison, simpler security bootstrapping solutions 1872 where the master key is transferred to the device via the OOB channel 1873 are vulnerable to opportunistic attacks if the user mistakenly 1874 delivers the master key to the wrong device or to more than one 1875 device. 1877 One mechanism that can mitigate user mistakes is certification of 1878 peer devices. A certificate or an attestation token 1879 (e.g.,[I-D.tschofenig-tls-cwt] and [I-D.ietf-rats-eat]) can convey to 1880 the server authentic identifiers and attributes, such as model and 1881 serial number, of the peer device. Compared to a fully certificate- 1882 based authentication, however, EAP-NOOB can be used without trusted 1883 third parties and does not require the user to know any identifier of 1884 the peer device; physical access to the device is sufficient for 1885 bootstrapping with EAP-NOOB. 1887 Similarly, the attacker can try to trick the user into delivering the 1888 OOB message to the wrong server, so that the peer device becomes 1889 associated with the wrong server. If the EAP server is accessed 1890 through a web user interface, the attack is akin to phishing attacks 1891 where the user is tricked into accessing the wrong URL and wrong web 1892 page. OOB implementation with a dedicated app on a mobile device, 1893 which communicates with a server API at a pre-configured URL, can 1894 protect against such attacks. 1896 After the device registration, an attacker could clone the device 1897 identity by copying the keys from the persistent EAP-NOOB association 1898 into another device. The attacker can be an outsider who gains 1899 access to the keys or the device owner who wants to have two devices 1900 matching the same registration. The cloning threats can be mitigated 1901 by creating the cryptographic keys and storing the persistent EAP- 1902 NOOB association on the peer device in a secure hardware component 1903 such as a trusted execution environment (TEE). Furthermore, remote 1904 attestation on the application level could provide assurance to the 1905 server that the device has not been cloned. 1907 6.4. Trusted path issues and misbinding attacks 1909 Another potential threat is spoofed user input or output on the peer 1910 device. When the user is delivering the OOB message to or from the 1911 correct peer device, a trusted path between the user and the peer 1912 device is needed. That is, the user must communicate directly with 1913 an authentic operating system and EAP-NOOB implementation in the peer 1914 device and not with a spoofed user interface. Otherwise, a 1915 registered device that is under the control of the attacker could 1916 emulate the behavior of an unregistered device. The secure path can 1917 be implemented, for example, by having the user press a reset button 1918 to return the device to the Unregistered state and to invoke a 1919 trusted UI. The problem with such trusted paths is that they are not 1920 standardized across devices. 1922 Another potential consequence of a spoofed UI is the misbinding 1923 attack where the user tries to register a correct but compromised 1924 device, which tricks the user into registering another 1925 (uncompromised) device instead. For example, the compromised device 1926 might have a malicious full-screen app running, which presents to the 1927 user QR codes copied, in real time, from another device's screen. If 1928 the unwitting user scans the QR code and delivers the OOB message in 1929 it to the server, the wrong device may become registered in the 1930 server. Such misbinding vulnerabilities arise because the user does 1931 not have any secure way of verifying that the in-band cryptographic 1932 handshake and the out-of-band physical access are terminated at the 1933 same physical device. Sethi et al. [Sethi19] analyze the misbinding 1934 threat against device-pairing protocols and also EAP-NOOB. 1935 Essentially, all protocols where the authentication relies on the 1936 user's physical access to the device are vulnerable to misbinding, 1937 including EAP-NOOB. 1939 A standardized trusted path for communicating directly with the 1940 trusted computing base in a physical device would mitigate the 1941 misbinding threat, but such paths rarely exist in practice. Careful 1942 asset tracking on the server side can also prevent most misbinding 1943 attacks if the peer device sends its identifiers or attributes in the 1944 PeerInfo field and the server compares them with the expected values. 1945 The wrong but uncompromised device's PeerInfo will not match the 1946 expected values. Device certification by the manufacturer can 1947 further strengthen the asset tracking. 1949 6.5. Peer identifiers and attributes 1951 The PeerId value in the protocol is a server-allocated identifier for 1952 its association with the peer and SHOULD NOT be shown to the user 1953 because its value is initially ephemeral. Since the PeerId is 1954 allocated by the server and the scope of the identifier is the single 1955 server, the so-called identifier squatting attacks, where a malicious 1956 peer could reserve another peer's identifier, are not possible in 1957 EAP-NOOB. The server SHOULD assign a random or pseudo-random PeerId 1958 to each new peer. It SHOULD NOT select the PeerId based on any peer 1959 characteristics that it may know, such as the peer's link-layer 1960 network address. 1962 User reset or failure in the OOB Step can cause the peer to perform 1963 many Initial Exchanges with the server, to allocate many PeerId 1964 values, and to store the ephemeral protocol state for them. The peer 1965 will typically only remember the latest one. EAP-NOOB leaves it to 1966 the implementation to decide when to delete these ephemeral 1967 associations. There is no security reason to delete them early, and 1968 the server does not have any way to verify that the peers are 1969 actually the same one. Thus, it is safest to store the ephemeral 1970 states for at least one day. If the OOB messages are sent only in 1971 the server-to-peer direction, the server SHOULD NOT delete the 1972 ephemeral state before all the related Noob values have expired. 1974 After completion of EAP-NOOB, the server may store the PeerInfo data, 1975 and the user may use it to identify the peer and its attributes, such 1976 as the make and model or serial number. A compromised peer could lie 1977 in the PeerInfo that it sends to the server. If the server stores 1978 any information about the peer, it is important that this information 1979 is approved by the user during or after the OOB Step. Without 1980 verification by the user or authentication on the application level, 1981 the PeerInfo is not authenticated information and should not be 1982 relied on. 1984 One possible use for the PeerInfo field is EAP channel binding 1985 ([RFC3748] Section 7.15). That is, the peer MAY include in PeerInfo 1986 any data items that it wants to bind to the EAP-NOOB association and 1987 to the exported keys. These can be properties of the authenticator 1988 or the access link, such as the SSID and BSSID of the wireless 1989 network (see Appendix C). 1991 6.6. Identity protection 1993 The PeerInfo field contains identifiers and other information about 1994 the peer device (see Appendix C), and the peer sends this information 1995 in plaintext to the EAP server before the server authentication in 1996 EAP-NOOB has been completed. While the information refers to the 1997 peer device and not directly to the user, it may be better for user 1998 privacy to avoid sending unnecessary information. In the Reconnect 1999 Exchange, the optional PeerInfo SHOULD be omitted unless some 2000 critical data has changed. 2002 Peer devices that randomize their layer-2 address to prevent tracking 2003 can do this whenever the user resets the EAP-NOOB association. 2004 During the lifetime of the association, the PeerId is a unique 2005 identifier that can be used to track the peer in the access network. 2006 Later versions of this specification may consider updating the PeerId 2007 at each Reconnect Exchange. In that case, it is necessary to 2008 consider how the authenticator and access-network administrators can 2009 recognize and blacklist misbehaving peer devices and how to avoid 2010 loss of synchronization between the server and the peer if messages 2011 are lost during the identifier update. 2013 6.7. Downgrading threats 2015 The fingerprint Hoob protects all the information exchanged in the 2016 Initial Exchange, including the cryptosuite negotiation. The message 2017 authentication codes MACs and MACp also protect the same information. 2018 The message authentication codes MACs2 and MACp2 protect information 2019 exchanged during key renegotiation in the Reconnect Exchange. This 2020 prevents downgrading attacks to weaker cryptosuites as long as the 2021 possible attacks take more time than the maximum time allowed for the 2022 EAP-NOOB completion. This is typically the case for recently 2023 discovered cryptanalytic attacks. 2025 As an additional precaution, the EAP server and peer MUST check for 2026 downgrading attacks in the Reconnect Exchange as follows. As long as 2027 the server or peer saves any information about the other endpoint, it 2028 MUST also remember the previously negotiated cryptosuite and MUST NOT 2029 accept renegotiation of any cryptosuite that is known to be weaker 2030 than the previous one, such as a deprecated cryptosuite. 2032 Integrity of the direction negotiation cannot be verified in the same 2033 way as the integrity of the cryptosuite negotiation. That is, if the 2034 OOB channel used in an application is critically insecure in one 2035 direction, a man-in-the-middle attacker could modify the negotiation 2036 messages and thereby cause that direction to be used. Applications 2037 that support OOB messages in both directions SHOULD therefore ensure 2038 that the OOB channel has sufficiently strong security in both 2039 directions. While this is a theoretical vulnerability, it could 2040 arise in practice if EAP-NOOB is deployed in new applications. 2041 Currently, we expect most peer devices to support only one OOB 2042 direction, in which case interfering with the direction negotiation 2043 can only prevent the completion of the protocol. 2045 The long-term shared key material Kz in the persistent EAP-NOOB 2046 association is established with an ECDHE key exchange when the peer 2047 and server are first associated. It is a weaker secret than a 2048 manually configured random shared key because advances in 2049 cryptanalysis against the used ECDHE curve could eventually enable 2050 the attacker to recover Kz. EAP-NOOB protects against such attacks 2051 by allowing cryptosuite upgrades in the Reconnect Exchange and by 2052 updating the shared key material Kz whenever the cryptosuite is 2053 upgraded. We do not expect the cryptosuite upgrades to be frequent, 2054 but if an upgrade becomes necessary, it can be done without manual 2055 reset and reassociation of the peer devices. 2057 6.8. Recovery from loss of last message 2059 The EAP-NOOB Completion Exchange, as well as the Reconnect Exchange 2060 with cryptosuite update, result in a persistent state change that 2061 should take place either on both endpoints or on neither; otherwise, 2062 the result is a state mismatch that requires user action to resolve. 2063 The state mismatch can occur if the final EAP response of the 2064 exchanges is lost. In the Completion Exchange, the loss of the final 2065 response (Type=6) results in the peer moving to Registered (4) state 2066 and creating a persistent EAP-NOOB association while the server stays 2067 in an ephemeral state (1 or 2). In the Reconnect Exchange, the loss 2068 of the final response (Type=9) results in the peer moving to the 2069 Registered (4) state and updating its persistent key material Kz 2070 while the server stays in the Reconnecting (3) state and keeps the 2071 old key material. 2073 The state mismatch is an example of an unavoidable problem in 2074 distributed systems: it is theoretically impossible to guarantee 2075 synchronous state changes in endpoints that communicate 2076 asynchronously. The protocol will always have one critical message 2077 that may get lost, so that one side commits to the state change and 2078 the other side does not. In EAP, the critical message is the final 2079 response from the peer to the server. While the final response is 2080 normally followed by EAP-Success, [RFC3748] section 4.2 states that 2081 the peer MAY assume that the EAP-Success was lost and the 2082 authentication was successful. Furthermore, EAP method 2083 implementations in the peer do not receive notification of the EAP- 2084 Success message from the parent EAP state machine [RFC4137]. For 2085 these reasons, EAP-NOOB on the peer side commits to a state change 2086 already when it sends the final response. 2088 The best available solution to the loss of the critical message is to 2089 keep trying. EAP retransmission behavior defined in Section 4.3 of 2090 [RFC3748] suggests 3-5 retransmissions. In the absence of an 2091 attacker, this would be sufficient to reduce the probability of 2092 failure to an acceptable level. However, a determined attacker on 2093 the in-band channel can drop the final EAP-Response message and all 2094 subsequent retransmissions. In the Completion Exchange 2095 (KeyingMode=0) and in the Reconnect Exchange with cryptosuite upgrade 2096 (KeyingMode=3), this could result in a state mismatch and persistent 2097 denial of service until user resets the peer state. 2099 EAP-NOOB implements its own recovery mechanism that allows unlimited 2100 retries of the Reconnect Exchange. When the DoS attacker eventually 2101 stops dropping packets on the in-band channel, the protocol will 2102 recover. The logic for this recovery mechanism is specified in 2103 Section 3.4.2. 2105 EAP-NOOB does not implement the same kind of retry mechanism in the 2106 Completion Exchange. The reason is that there is always a user 2107 involved in the initial association process, and the user can repeat 2108 the OOB Step to complete the association after the DoS attacker has 2109 left. On the other hand, Reconnect Exchange needs to work without 2110 user involvement. 2112 6.9. EAP security claims 2114 EAP security claims are defined in section 7.2.1 of [RFC3748]. The 2115 security claims for EAP-NOOB are listed in Table 9. 2117 +----------------+--------------------------------------------------+ 2118 | Security | EAP-NOOB claim | 2119 | property | | 2120 +----------------+--------------------------------------------------+ 2121 | Authentication | ECDHE key exchange with out-of-band | 2122 | mechanism | authentication | 2123 | | | 2124 | Protected | yes | 2125 | cryptosuite | | 2126 | negotiation | | 2127 | | | 2128 | Mutual | yes | 2129 | authentication | | 2130 | | | 2131 | Integrity | yes | 2132 | protection | | 2133 | | | 2134 | Replay | yes | 2135 | protection | | 2136 | | | 2137 | Key derivation | yes | 2138 | | | 2139 | Key strength | The specified cryptosuites provide key strength | 2140 | | of at least 128 bits. | 2141 | | | 2142 | Dictionary | yes | 2143 | attack | | 2144 | protection | | 2145 | | | 2146 | Fast reconnect | yes | 2147 | | | 2148 | Cryptographic | not applicable | 2149 | binding | | 2150 | | | 2151 | Session | yes | 2152 | independence | | 2153 | | | 2154 | Fragmentation | no | 2155 | | | 2156 | Channel | yes (The ServerInfo and PeerInfo can be used to | 2157 | binding | convey integrity-protected channel properties | 2158 | | such as network SSID or peer MAC address.) | 2159 +----------------+--------------------------------------------------+ 2161 Table 9: EAP security claims 2163 7. References 2165 7.1. Normative references 2167 [FIPS186-4] 2168 National Institute of Standards and Technology, "Digital 2169 Signature Standard (DSS)", FIPS 186-4 , July 2013. 2171 [NIST-DH] Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R. 2172 Davis, "Recommendation for Pair-Wise Key Establishment 2173 Schemes Using Discrete Logarithm Cryptography", NIST 2174 Special Publication 800-56A Revision 3 , April 2018, 2175 . 2178 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 2179 Hashing for Message Authentication", RFC 2104, 2180 DOI 10.17487/RFC2104, February 1997, 2181 . 2183 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2184 Requirement Levels", BCP 14, RFC 2119, 2185 DOI 10.17487/RFC2119, March 1997, 2186 . 2188 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 2189 Levkowetz, Ed., "Extensible Authentication Protocol 2190 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 2191 . 2193 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 2194 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 2195 . 2197 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 2198 Authentication Protocol (EAP) Key Management Framework", 2199 RFC 5247, DOI 10.17487/RFC5247, August 2008, 2200 . 2202 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 2203 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 2204 DOI 10.17487/RFC6234, May 2011, 2205 . 2207 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 2208 RFC 6761, DOI 10.17487/RFC6761, February 2013, 2209 . 2211 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 2212 DOI 10.17487/RFC7517, May 2015, 2213 . 2215 [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, 2216 DOI 10.17487/RFC7542, May 2015, 2217 . 2219 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 2220 for Security", RFC 7748, DOI 10.17487/RFC7748, January 2221 2016, . 2223 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2224 Writing an IANA Considerations Section in RFCs", BCP 26, 2225 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2226 . 2228 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 2229 Interchange Format", STD 90, RFC 8259, 2230 DOI 10.17487/RFC8259, December 2017, 2231 . 2233 7.2. Informative references 2235 [BluetoothPairing] 2236 Bluetooth, SIG, "Simple pairing whitepaper", Technical 2237 report , 2007. 2239 [EUI-48] Institute of Electrical and Electronics Engineers, 2240 "802-2014 IEEE Standard for Local and Metropolitan Area 2241 Networks: Overview and Architecture.", IEEE Standard 2242 802-2014. , June 2014. 2244 [I-D.ietf-rats-eat] 2245 Mandyam, G., Lundblade, L., Ballesteros, M., and J. 2246 O'Donoghue, "The Entity Attestation Token (EAT)", draft- 2247 ietf-rats-eat-03 (work in progress), February 2020. 2249 [I-D.tschofenig-tls-cwt] 2250 Tschofenig, H. and M. Brossard, "Using CBOR Web Tokens 2251 (CWTs) in Transport Layer Security (TLS) and Datagram 2252 Transport Layer Security (DTLS)", draft-tschofenig-tls- 2253 cwt-01 (work in progress), November 2019. 2255 [IEEE-802.1X] 2256 Institute of Electrical and Electronics Engineers, "Local 2257 and Metropolitan Area Networks: Port-Based Network Access 2258 Control", IEEE Standard 802.1X-2004. , December 2004. 2260 [mcrl2] Groote, J. and M. Mousavi, "Modeling and analysis of 2261 communicating systems", The MIT press , 2014, 2262 . 2265 [proverif] 2266 Blanchet, B., Smyth, B., Cheval, V., and M. Sylvestre, 2267 "ProVerif 2.00: Automatic Cryptographic Protocol Verifier, 2268 User Manual and Tutorial", The MIT press , 2018, 2269 . 2272 [RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., 2273 Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and 2274 D. Spence, "AAA Authorization Framework", RFC 2904, 2275 DOI 10.17487/RFC2904, August 2000, 2276 . 2278 [RFC4137] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba, 2279 "State Machines for Extensible Authentication Protocol 2280 (EAP) Peer and Authenticator", RFC 4137, 2281 DOI 10.17487/RFC4137, August 2005, 2282 . 2284 [RFC4266] Hoffman, P., "The gopher URI Scheme", RFC 4266, 2285 DOI 10.17487/RFC4266, November 2005, 2286 . 2288 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 2289 Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, 2290 March 2008, . 2292 [RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a 2293 Prime (ECP Groups) for IKE and IKEv2", RFC 5903, 2294 DOI 10.17487/RFC5903, June 2010, 2295 . 2297 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 2298 Code: The Implementation Status Section", BCP 205, 2299 RFC 7942, DOI 10.17487/RFC7942, July 2016, 2300 . 2302 [Sethi14] Sethi, M., Oat, E., Di Francesco, M., and T. Aura, "Secure 2303 Bootstrapping of Cloud-Managed Ubiquitous Displays", 2304 Proceedings of ACM International Joint Conference on 2305 Pervasive and Ubiquitous Computing (UbiComp 2014), pp. 2306 739-750, Seattle, USA , September 2014, 2307 . 2309 [Sethi19] Sethi, M., Peltonen, A., and T. Aura, "Misbinding Attacks 2310 on Secure Device Pairing", 2019, 2311 . 2313 Appendix A. Exchanges and events per state 2315 Figure 11 shows how the EAP server chooses the exchange type 2316 depending on the server and peer states. In the state combinations 2317 marked with hyphen "-", there is no possible exchange and user action 2318 is required to make progress. Note that peer state 4 is omitted from 2319 the table because the peer never connects to the server when the peer 2320 is in that state. The table also shows the handling of errors in 2321 each exchange. A notable detail is that the recipient of error code 2322 2003 moves to state 1. 2324 +--------+---------------------------+------------------------------+ 2325 | peer | exchange chosen by | next peer and | 2326 | states | server | server states | 2327 +========+===========================+==============================+ 2328 | server state: Unregistered (0) | 2329 +--------+---------------------------+------------------------------+ 2330 | 0..2 | Initial Exchange | both 1 (0 on error) | 2331 | 3 | - | no change, notify user | 2332 +--------+---------------------------+------------------------------+ 2333 | server state: Waiting for OOB (1) | 2334 +--------+---------------------------+------------------------------+ 2335 | 0 | Initial Exchange | both 1 (0 on error) | 2336 | 1 | Waiting Exchange | both 1 (no change on error) | 2337 | 2 | Completion Exchange | both 4 (A) | 2338 | 3 | - | no change, notify user | 2339 +--------+---------------------------+------------------------------+ 2340 | server state: OOB Received (2) | 2341 +--------+---------------------------+------------------------------+ 2342 | 0 | Initial Exchange | both 1 (0 on error) | 2343 | 1 | Completion Exchange | both 4 (B) | 2344 | 2 | Completion Exchange | both 4 (A) | 2345 | 3 | - | no change, notify user | 2346 +--------+---------------------------+------------------------------+ 2347 | server state: Reconnecting (3) or Registered (4) | 2348 +--------+---------------------------+------------------------------+ 2349 | 0..2 | - | no change, notify user | 2350 | 3 | Reconnect Exchange | both 4 (3 on error) | 2351 +--------+---------------------------+------------------------------+ 2352 (A) peer to 1 on error 2003, no other changes on error 2353 (B) server to 1 on error 2003, no other changes on error 2355 Figure 11: How server chooses the exchange type 2357 Figure 12 lists the local events that can take place in the server or 2358 peer. Both the server and peer output and accept OOB messages in 2359 association state 1, leading the receiver to state 2. Communication 2360 errors and timeouts in states 0..2 lead back to state 0, while 2361 similar errors in states 3..4 lead to state 3. Application request 2362 for rekeying (e.g., to refresh session keys or to upgrade 2363 cryptosuite) also takes the association from state 3..4 to state 3. 2364 User can always reset the association state to 0. Recovering 2365 association data, e.g. from a backup, leads to state 3. 2367 +--------+---------------------------+------------------------------+ 2368 | server/| possible local events | next state | 2369 | peer | on server and peer | | 2370 | state | | | 2371 +========+===========================+==============================+ 2372 | 1 | OOB Output* | 1 | 2373 | 1 | OOB Input* | 2 (1 on error) | 2374 | 0..2 | Timeout/network failure | 0 | 2375 | 3..4 | Timeout/network failure | 3 | 2376 | 3..4 | Rekeying request | 3 | 2377 | 0..4 | User resets peer state | 0 | 2378 | 0..4 | Association state recovery| 3 | 2379 +--------+---------------------------+------------------------------+ 2381 Figure 12: Local events on server and peer 2383 Appendix B. Application-specific parameters 2385 Table 10 lists OOB channel parameters that need to be specified in 2386 each application that makes use of EAP-NOOB. The list is not 2387 exhaustive and is included for the convenience of implementers only. 2389 +--------------------+----------------------------------------------+ 2390 | Parameter | Description | 2391 +--------------------+----------------------------------------------+ 2392 | OobDirs | Allowed directions of the OOB channel | 2393 | | | 2394 | OobMessageEncoding | How the OOB message data fields are encoded | 2395 | | for the OOB channel | 2396 | | | 2397 | SleepTimeDefault | Default minimum time in seconds that the | 2398 | | peer should sleep before the next Waiting | 2399 | | Exchange | 2400 | | | 2401 | OobRetries | Number of received OOB messages with invalid | 2402 | | Hoob after which the receiver moves to | 2403 | | Unregistered (0) state | 2404 | | | 2405 | NoobTimeout | How many seconds the sender of the OOB | 2406 | | message remembers the sent Noob value. The | 2407 | | RECOMMENDED value is 3600 seconds. | 2408 | | | 2409 | ServerInfoType | The value of the Type field and the other | 2410 | | required fields in ServerInfo | 2411 | | | 2412 | PeerInfoType | The value of the Type field and the other | 2413 | | required fields in PeerInfo | 2414 +--------------------+----------------------------------------------+ 2416 Table 10: OOB channel characteristics 2418 Appendix C. ServerInfo and PeerInfo contents 2420 The ServerInfo and PeerInfo fields in the Initial Exchange and 2421 Reconnect Exchange enable the server and peer, respectively, to send 2422 information about themselves to the other endpoint. They contain 2423 JSON objects whose structure may be specified separately for each 2424 application and each type of OOB channel. ServerInfo and PeerInfo 2425 MAY contain auxiliary data needed for the OOB channel messaging and 2426 for EAP channel binding. Table 11 lists some suggested data fields 2427 for ServerInfo. Further specifications may specify domain-specific 2428 ServerInfo and PeerInfo contents. 2430 +----------------+--------------------------------------------------+ 2431 | Data field | Description | 2432 +----------------+--------------------------------------------------+ 2433 | Type | Type-tag string that can be used by the peer as | 2434 | | a hint for how to interpret the ServerInfo | 2435 | | contents. | 2436 | | | 2437 | ServerName | String that may be used to aid human | 2438 | | identification of the server. | 2439 | | | 2440 | ServerURL | Prefix string when the OOB message is formatted | 2441 | | as a URL, as suggested in Appendix E. | 2442 | | | 2443 | SSIDList | List of IEEE 802.11 wireless network identifier | 2444 | | (SSID) strings used for roaming support, as | 2445 | | suggested in Appendix D. JSON array of ASCII | 2446 | | encoded SSID strings. | 2447 | | | 2448 | Base64SSIDList | List of IEEE 802.11 wireless network identifier | 2449 | | (SSID) strings used for roaming support, as | 2450 | | suggested in Appendix D. JSON array of SSIDs, | 2451 | | each of which is base64url encoded without | 2452 | | padding. Peers SHOULD send at most one of the | 2453 | | fields SSIDList and Base64SSIDList in PeerInfo, | 2454 | | and the server SHOULD ignore SSIDList if | 2455 | | Base64SSIDList is included. | 2456 +----------------+--------------------------------------------------+ 2458 Table 11: Suggested ServerInfo data fields 2460 PeerInfo typically contains auxiliary information for identifying and 2461 managing peers on the application level at the server end. Table 12 2462 lists some suggested data fields for PeerInfo. 2464 +--------------+----------------------------------------------------+ 2465 | Data field | Description | 2466 +--------------+----------------------------------------------------+ 2467 | Type | Type-tag string that can be used by the server as | 2468 | | a hint for how to interpret the PeerInfo contents. | 2469 | | | 2470 | PeerName | String that may be used to aid human | 2471 | | identification of the peer. | 2472 | | | 2473 | Manufacturer | Manufacturer or brand string. | 2474 | | | 2475 | Model | Manufacturer-specified model string. | 2476 | | | 2477 | SerialNumber | Manufacturer-assigned serial number. | 2478 | | | 2479 | MACAddress | Peer link-layer identifier (EUI-48) in the | 2480 | | 12-digit base-16 form [EUI-48]. The string MAY be | 2481 | | in upper or lower case and MAY include additional | 2482 | | colon ':' or dash '-' characters that MUST be | 2483 | | ignored by the server. | 2484 | | | 2485 | SSID | IEEE 802.11 network SSID for channel binding. The | 2486 | | SSID is a ASCII string. | 2487 | | | 2488 | Base64SSID | IEEE 802.11 network SSID for channel binding. The | 2489 | | SSID is base64url encoded. Peer SHOULD send at | 2490 | | most one of the fields SSID and Base64SSID in | 2491 | | PeerInfo, and the server SHOULD ignore SSID if | 2492 | | Base64SSID is included. | 2493 | | | 2494 | BSSID | Wireless network BSSID (EUI-48) in the 12-digit | 2495 | | base-16 form [EUI-48]. The string MAY be in upper | 2496 | | or lower case and MAY include additional colon ':' | 2497 | | or dash '-' characters that MUST be ignored by the | 2498 | | server. | 2499 | | | 2500 +--------------+----------------------------------------------------+ 2502 Table 12: Suggested PeerInfo data fields 2504 Appendix D. EAP-NOOB roaming 2506 AAA architectures [RFC2904] allow for roaming of network-connected 2507 appliances that are authenticated over EAP. While the peer is 2508 roaming in a visited network, authentication still takes place 2509 between the peer and an authentication server at its home network. 2510 EAP-NOOB supports such roaming by assigning a Realm to the peer. 2512 After the Realm has been assigned, the peer's NAI enables the visited 2513 network to route the EAP session to the peer's home AAA server. 2515 A peer device that is new or has gone through a hard reset should be 2516 connected first to the home network and establish an EAP-NOOB 2517 association with its home AAA server before it is able to roam. 2518 After that, it can perform the Reconnect Exchange from the visited 2519 network. 2521 Alternatively, the device may provide some method for the user to 2522 configure the Realm of the home network. In that case, the EAP-NOOB 2523 association can be created while roaming. The device will use the 2524 user-assigned Realm in the Initial Exchange, which enables the EAP 2525 messages to be routed correctly to the home AAA server. 2527 While roaming, the device needs to identify the networks where the 2528 EAP-NOOB association can be used to gain network access. For 802.11 2529 access networks, the server MAY send a list of SSID strings in the 2530 ServerInfo field called either SSIDList or Base64SSIDList. The list 2531 is formatted as explained in Table 11. If present, the peer MAY use 2532 this list as a hint to determine the networks where the EAP-NOOB 2533 association can be used for access authorization, in addition to the 2534 access network where the Initial Exchange took place. 2536 Appendix E. OOB message as URL 2538 While EAP-NOOB does not mandate any particular OOB communication 2539 channel, typical OOB channels include graphical displays and emulated 2540 NFC tags. In the peer-to-server direction, it may be convenient to 2541 encode the OOB message as a URL, which is then encoded as a QR code 2542 for displays and printers or as an NDEF record for NFC tags. A user 2543 can then simply scan the QR code or NFC tag and open the URL, which 2544 causes the OOB message to be delivered to the authentication server. 2545 The URL MUST specify the https protocol, so that there is a secure 2546 connection to the server and the man-in-the-middle attacker cannot 2547 read or modify the OOB message. 2549 The ServerInfo in this case includes a field called ServerUrl of the 2550 following format with RECOMMENDED length of 60 characters or less: 2552 https://[:]/[] 2554 To this, the peer appends the OOB message fields (PeerId, Noob, Hoob) 2555 as a query string. PeerId is provided to the peer by the server and 2556 might be a 22-character ASCII string. The peer base64url encodes, 2557 without padding, the 16-byte values Noob and Hoob into 22-character 2558 ASCII strings. The query parameters MAY be in any order. The 2559 resulting URL is of the following format: 2561 https://[:]/[]?P=&N=&H= 2563 The following is an example of a well-formed URL encoding the OOB 2564 message (without line breaks): 2566 https://example.com/Noob?P=ZrD7qkczNoHGbGcN2bN0&N=rMinS0-F4EfCU8D9ljx 2567 X_A&H=QvnMp4UGxuQVFaXPW_14UW 2569 Appendix F. Example messages 2571 The message examples in this section are generated with Curve25519 2572 ECDHE test vectors specified in section 6.1 of [RFC7748] 2573 (server=Alice, peer=Bob). The direction of the OOB channel 2574 negotiated is 2 (server-to-peer). The JSON messages are as follows 2575 (line breaks are for readability only). 2577 ====== Initial Exchange ====== 2579 Identity response: 2580 noob@eap-noob.arpa 2582 EAP request (type 1): 2583 {"Type":1} 2585 EAP response (type 1): 2586 {"Type":1,"PeerState":0} 2588 EAP request (type 2): 2589 {"Type":2,"Vers":[1],"PeerId":"07KRU6OgqX0HIeRFldnbSW","Realm":"no 2590 ob.example.com","Cryptosuites":[1,2],"Dirs":3,"ServerInfo":{"Type" 2591 :"url_wifi","Name":"Example","Url":"https://noob.example.com/ 2592 sendOOB"}} 2594 EAP response (type 2): 2595 {"Type":2,"Verp":1,"PeerId":"07KRU6OgqX0HIeRFldnbSW","Cryptosuitep 2596 ":1,"Dirp":2,"PeerInfo":{"Type":"wifi","Make":"Acme","Serial":"DU- 2597 9999","SSID":"Noob1","BSSID":"6c:19:8f:83:c2:80"}} 2599 EAP request (type 3): 2600 {"Type":3,"PeerId":"07KRU6OgqX0HIeRFldnbSW","PKs":{"kty":"EC","crv 2601 ":"X25519","x":"hSDwCYkwp1R0i33ctD73Wg2_Og0mOBr066SpjqqbTmo"},"Ns" 2602 :"PYO7NVd9Af3BxEri1MI6hL8Ck49YxwCjSRPqlC1SPbw","SleepTime":60} 2604 EAP response (type 3): 2605 {"Type":3,"PeerId":"07KRU6OgqX0HIeRFldnbSW","PKp":{"kty":"EC","crv 2606 ":"X25519","x":"3p7bfXt9wbTTW2HC7OQ1Nz-DQ8hbeGdNrfx-FG- 2607 IK08"},"Np":"HIvB6g0n2btpxEcU7YXnWB-451ED6L6veQQd6ugiPFU"} 2609 ====== Waiting Exchange ====== 2611 Identity response: 2612 noob@noob.example.com 2614 EAP request (type 1): 2615 {"Type":1} 2617 EAP response (type 1): 2618 {"Type":1,"PeerId":"07KRU6OgqX0HIeRFldnbSW","PeerState":1} 2620 EAP request (type 4): 2621 {"Type":4,"PeerId":"07KRU6OgqX0HIeRFldnbSW","SleepTime":60} 2623 EAP response (type 4): 2624 {"Type":4,"PeerId":"07KRU6OgqX0HIeRFldnbSW"} 2626 ====== OOB Step ====== 2628 OOB message: 2629 P=07KRU6OgqX0HIeRFldnbSW&N=x3JlolaPciK4Wa6XlMJxtQ&H=W3-icQoP19bJzJ 2630 zI3kvpTA 2632 ====== Completion Exchange ====== 2634 Identity response: 2635 noob@noob.example.com 2637 EAP request (type 1): 2638 {"Type":1} 2640 EAP response (type 1): 2641 {"Type":1,"PeerId":"07KRU6OgqX0HIeRFldnbSW","PeerState":2} 2643 EAP request (type 5): 2644 {"Type":5,"PeerId":"07KRU6OgqX0HIeRFldnbSW"} 2646 EAP response (type 5): 2647 {"Type":5,"PeerId":"07KRU6OgqX0HIeRFldnbSW","NoobId":"U0OHwYGCS4nE 2648 kzk2TPIE6g"} 2650 EAP request (type 6): 2651 {"Type":6,"PeerId":"07KRU6OgqX0HIeRFldnbSW","NoobId":"U0OHwYGCS4nE 2652 kzk2TPIE6g","MACs":"yQTuMzkEBblsjCTUCTqHTbOR5Z2fs7s1tqMeCFqQT0k"} 2654 EAP response (type 6): 2655 {"Type":6,"PeerId":"07KRU6OgqX0HIeRFldnbSW","MACp":"MZOEIma1mHZUL2 2656 _kJX8KMhGDBNkvwqamiv8cCjxIZgM"} 2658 ====== Reconnect Exchange (KeyingMode = 1) ====== 2660 Identity response: 2661 noob@noob.example.com 2663 EAP request (type 1): 2664 {"Type":1} 2666 EAP response (type 1): 2667 {"Type":1,"PeerId":"07KRU6OgqX0HIeRFldnbSW","PeerState":3} 2669 EAP request (type 7): 2670 {"Type":7,"Vers":[1],"PeerId":"07KRU6OgqX0HIeRFldnbSW","Cryptosuit 2671 es":[1,2],"Realm":"noob.example.com","ServerInfo":{"Type":"url_wif 2672 i","Name":"Example","Url":"https://noob.example.com/sendOOB"}} 2674 EAP response (type 7): 2675 {"Type":7,"Verp":1,"PeerId":"07KRU6OgqX0HIeRFldnbSW","Cryptosuitep 2676 ":1,"PeerInfo":{"Type":"wifi","Make":"Acme","Serial":"DU- 2677 9999","SSID":"Noob1","BSSID":"6c:19:8f:83:c2:80"}} 2679 EAP request (type 8): 2680 {"Type":8,"PeerId":"07KRU6OgqX0HIeRFldnbSW","KeyingMode":1,"Ns2":" 2681 RDLahHBlIgnmL_F_xcynrHurLPkCsrp3G3B_S82WUF4"} 2683 EAP response (type 8): 2684 {"Type":8,"PeerId":"07KRU6OgqX0HIeRFldnbSW","Np2":"jN0_V4P0JoTqwI9 2685 VHHQKd9ozUh7tQdc9ABd-j6oTy_4"} 2687 EAP request (type 9): 2688 {"Type":9,"PeerId":"07KRU6OgqX0HIeRFldnbSW","MACs2":"WsZU_JZNhE1ju 2689 dcVeEbIhiDEo1OXXOAxqxxgEP2FckI"} 2691 EAP response (type 9): 2692 {"Type":9,"PeerId":"07KRU6OgqX0HIeRFldnbSW","MACp2":"sopB5xkLBjZBC 2693 81GE3YXdBDDadqRFh1vQTGIBXnr_Dk"} 2695 ====== Reconnect Exchange (KeyingMode = 2) ====== 2697 Identity response: 2698 noob@noob.example.com 2700 EAP request (type 1): 2701 {"Type":1} 2703 EAP response (type 1): 2704 {"Type":1,"PeerId":"07KRU6OgqX0HIeRFldnbSW","PeerState":3} 2706 EAP request (type 7): 2707 {"Type":7,"Vers":[1],"PeerId":"07KRU6OgqX0HIeRFldnbSW","Cryptosuit 2708 es":[1,2],"Realm":"noob.example.com","ServerInfo":{"Type":"url_wif 2709 i","Name":"Example","Url":"https://noob.example.com/sendOOB"}} 2711 EAP response (type 7): 2712 {"Type":7,"Verp":1,"PeerId":"07KRU6OgqX0HIeRFldnbSW","Cryptosuitep 2713 ":1,"PeerInfo":{"Type":"wifi","Make":"Acme","Serial":"DU- 2714 9999","SSID":"Noob1","BSSID":"6c:19:8f:83:c2:80"}} 2716 EAP request (type 8): 2717 {"Type":8,"PeerId":"07KRU6OgqX0HIeRFldnbSW","KeyingMode":2,"PKs2": 2718 {"kty":"EC","crv":"X25519","x":"hSDwCYkwp1R0i33ctD73Wg2_Og0mOBr066 2719 SpjqqbTmo"},"Ns2":"RDLahHBlIgnmL_F_xcynrHurLPkCsrp3G3B_S82WUF4"} 2721 EAP response (type 8): 2722 {"Type":8,"PeerId":"07KRU6OgqX0HIeRFldnbSW","PKp2":{"kty":"EC","cr 2723 v":"X25519","x":"3p7bfXt9wbTTW2HC7OQ1Nz-DQ8hbeGdNrfx-FG- 2724 IK08"},"Np2":"jN0_V4P0JoTqwI9VHHQKd9ozUh7tQdc9ABd-j6oTy_4"} 2726 EAP request (type 9): 2727 {"Type":9,"PeerId":"07KRU6OgqX0HIeRFldnbSW","MACs2":"CJ6bIYcSMvWD6 2728 NIq1zikdnmwVlvOJBJ3TODkg7QCl40"} 2730 EAP response (type 9): 2731 {"Type":9,"PeerId":"07KRU6OgqX0HIeRFldnbSW","MACp2":"TUP9IqEK78y4Q 2732 fmsjDIijlLHHq3EgcQ_mYhXT0LSpmk"} 2734 ====== Reconnect Exchange (KeyingMode = 3) ====== 2736 These message examples show the case where the peer upgrades to 2737 Cryptosuite 2 during the Reconnect Exchange. The messages are 2738 generated with NIST P-256 ECDHE test vectors specified in section 8.1 2739 of [RFC5903] (server=responder, peer=initiator). 2741 Identity response: 2742 noob@noob.example.com 2744 EAP request (type 1): 2745 {"Type":1} 2747 EAP response (type 1): 2748 {"Type":1,"PeerId":"07KRU6OgqX0HIeRFldnbSW","PeerState":3} 2750 EAP request (type 7): 2751 {"Type":7,"Vers":[1],"PeerId":"07KRU6OgqX0HIeRFldnbSW","Cryptosuit 2752 es":[1,2],"Realm":"noob.example.com","ServerInfo":{"Type":"url_wif 2753 i","Name":"Example","Url":"https://noob.example.com/sendOOB"}} 2755 EAP response (type 7): 2756 {"Type":7,"Verp":1,"PeerId":"07KRU6OgqX0HIeRFldnbSW","Cryptosuitep 2757 ":2,"PeerInfo":{"Type":"wifi","Make":"Acme","Serial":"DU- 2758 9999","SSID":"Noob1","BSSID":"6c:19:8f:83:c2:80"}} 2760 EAP request (type 8): 2761 {"Type":8,"PeerId":"07KRU6OgqX0HIeRFldnbSW","KeyingMode":3,"PKs2": 2762 {"kty":"EC","crv":"P-256","x":"2tC2U5QiHPmwUeH-yleH0Jjf5jf8kLnvlF0 2763 MN3JYEYA","y":"UnGgRhzbglLWHxxFb6PlmrH0WzOsz19YOJ4Fd7iZC7M"},"Ns2" 2764 :"RDLahHBlIgnmL_F_xcynrHurLPkCsrp3G3B_S82WUF4"} 2766 EAP response (type 8): 2767 {"Type":8,"PeerId":"07KRU6OgqX0HIeRFldnbSW","PKp2":{"kty":"EC","cr 2768 v":"P-256","x":"0S37UonI1PgSCLcCcDmMNCKWlwoLzLdMc2_HVUSUv2M","y":" 2769 VvvzyjZswj6BV4VME8WNaqwj8Eatow-DU- 2770 dPMwOYcqs"},"Np2":"jN0_V4P0JoTqwI9VHHQKd9ozUh7tQdc9ABd-j6oTy_4"} 2772 EAP request (type 9): 2773 {"Type":9,"PeerId":"07KRU6OgqX0HIeRFldnbSW","MACs2":"Baj0VovNadExD 2774 WhuY-ehTy92AgV236Xilx-hcjuePOs"} 2776 EAP response (type 9): 2777 {"Type":9,"PeerId":"07KRU6OgqX0HIeRFldnbSW","MACp2":"8NZNZJqaptSsB 2778 A8CdCrfTfx1gBgdsdqW28oAAG27LpM"} 2780 Appendix G. TODO list 2782 o Update EAP Method Type number assigned by IANA 2784 o Update reserved domain name. 2786 Appendix H. Version history 2788 o Version 01: 2790 * Fixed Reconnection Exchange. 2792 * URL examples. 2794 * Message examples. 2796 * Improved state transition (event) tables. 2798 o Version 02: 2800 * Reworked the rekeying and key derivation. 2802 * Increased internal key lengths and in-band nonce and HMAC 2803 lengths to 32 bytes. 2805 * Less data in the persistent EAP-NOOB association. 2807 * Updated reference [NIST-DH] to Revision 2 (2013). 2809 * Shorter suggested PeerId format. 2811 * Optimized the example of encoding OOB message as URL. 2813 * NoobId in Completion Exchange to differentiate between multiple 2814 valid Noob values. 2816 * List of application-specific parameters in appendix. 2818 * Clarified the equivalence of Unregistered state and no state. 2820 * Peer SHOULD probe the server regardless of the OOB channel 2821 direction. 2823 * Added new error messages. 2825 * Realm is part of the persistent association and can be updated. 2827 * Clarified error handling. 2829 * Updated message examples. 2831 * Explained roaming in appendix. 2833 * More accurate definition of timeout for the Noob nonce. 2835 * Additions to security considerations. 2837 o Version 03: 2839 * Clarified reasons for going to Reconnecting state. 2841 * Included Verp in persistent state. 2843 * Added appendix on suggested ServerInfo and PeerInfo fields. 2845 * Exporting PeerId and SessionId. 2847 * Explicitly specified next state after OOB Step. 2849 * Clarified the processing of an expired OOB message and 2850 unrecognized NoobId. 2852 * Enabled protocol version upgrade in Reconnect Exchange. 2854 * Explained handling of redundant received OOB messages. 2856 * Clarified where raw and base64url encoded values are used. 2858 * Cryptosuite must specify the detailed format of the JWK object. 2860 * Base64url encoding in JSON strings is done without padding. 2862 * Simplified explanation of PeerId, Realm and NAI. 2864 * Added error codes for private and experimental use. 2866 * Updated the security considerations. 2868 o Version 04: 2870 * Recovery from synchronization failure due to lost last 2871 response. 2873 o Version 05: 2875 * Kz identifier added to help recovery from lost last messages. 2877 * Error message codes changed for better structure. 2879 * Improved security considerations section. 2881 o Version 06: 2883 * Kz identifier removed to enable PeerId anonymization in the 2884 future. 2886 * Clarified text on when to use server-assigned realm. 2888 * Send PeerId and PeerState in a separate request-reponse pair, 2889 not in NAI. 2891 * New subsection for the common handshake in all exchanges to 2892 avoid repetition. 2894 o Version 07: 2896 * Updated example messages. 2898 * Added pointers to new implementation in Contiki. 2900 o Version 08: 2902 * Editorial improvements and corrections. 2904 o WG Version 00: 2906 * Editorial improvements and corrections. 2908 * Updated reference [NIST-DH] to Revision 3 (2018). 2910 o WG Version 01: 2912 * Add NIST P-256 as Cryptosuite 2. 2914 * Renumber message types. 2916 * Very minor editorial fixes. 2918 o WG Version 02: 2920 * Updated message examples with all KeyingModes. 2922 * Many editorial fixes and other updates based on the IoT 2923 directorate review of Dave Thaler. 2925 * Text on cloning attacks based on review by Hannes Tschofenig. 2927 Appendix I. Acknowledgments 2929 Aleksi Peltonen modeled the protocol specification with the mCRL2 2930 formal specification language. Max Crone, Shiva Prasad TP, and 2931 Raghavendra MS implemented parts of the protocol with wpa_supplicant 2932 and hostapd. Their inputs helped us in improving the specification. 2934 The authors would like to thank Rhys Smith and Josh Howlett for 2935 providing valuable feedback as well as new use cases and requirements 2936 for the protocol. Thanks to Eric Rescorla, Darshak Thakore, Stefan 2937 Winter, Hannes Tschofenig, and Daniel Migault for interesting 2938 discussions in this problem space. 2940 We would also like to express our sincere gratitude to Dave Thaler 2941 for his thorough review of the document. 2943 Authors' Addresses 2945 Tuomas Aura 2946 Aalto University 2947 Aalto 00076 2948 Finland 2950 EMail: tuomas.aura@aalto.fi 2952 Mohit Sethi 2953 Ericsson 2954 Jorvas 02420 2955 Finland 2957 EMail: mohit@piuha.net