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