idnits 2.17.1 draft-aura-eap-noob-05.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 (March 11, 2019) is 1873 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Realm' is mentioned on line 1154, but not defined == Missing Reference: 'ServerInfo' is mentioned on line 1154, but not defined -- 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 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 2 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: September 12, 2019 Ericsson 6 March 11, 2019 8 Nimble out-of-band authentication for EAP (EAP-NOOB) 9 draft-aura-eap-noob-05 11 Abstract 13 Extensible Authentication Protocol (EAP) provides support for 14 multiple authentication methods. This document defines the EAP-NOOB 15 authentication method for nimble out-of-band (OOB) authentication and 16 key derivation. This EAP method is intended for bootstrapping all 17 kinds of Internet-of-Things (IoT) devices that have a minimal user 18 interface and no pre-configured authentication credentials. The 19 method makes use of a user-assisted one-directional OOB channel 20 between the peer device and authentication server. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 12, 2019. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. EAP-NOOB protocol . . . . . . . . . . . . . . . . . . . . . . 5 59 3.1. Protocol overview . . . . . . . . . . . . . . . . . . . . 5 60 3.2. Protocol messages and sequences . . . . . . . . . . . . . 8 61 3.2.1. Initial Exchange . . . . . . . . . . . . . . . . . . 8 62 3.2.2. OOB Step . . . . . . . . . . . . . . . . . . . . . . 10 63 3.2.3. Completion Exchange . . . . . . . . . . . . . . . . . 11 64 3.2.4. Waiting Exchange . . . . . . . . . . . . . . . . . . 13 65 3.3. Protocol data fields . . . . . . . . . . . . . . . . . . 15 66 3.3.1. Peer identifier, realm and NAI . . . . . . . . . . . 15 67 3.3.2. Message data fields . . . . . . . . . . . . . . . . . 17 68 3.4. Fast reconnect and rekeying . . . . . . . . . . . . . . . 22 69 3.4.1. Persistent EAP-NOOB association . . . . . . . . . . . 22 70 3.4.2. Reconnect Exchange . . . . . . . . . . . . . . . . . 23 71 3.4.3. User reset . . . . . . . . . . . . . . . . . . . . . 26 72 3.5. Key derivation . . . . . . . . . . . . . . . . . . . . . 27 73 3.6. Error handling . . . . . . . . . . . . . . . . . . . . . 30 74 3.6.1. Invalid messages . . . . . . . . . . . . . . . . . . 32 75 3.6.2. Unwanted peer . . . . . . . . . . . . . . . . . . . . 32 76 3.6.3. State mismatch . . . . . . . . . . . . . . . . . . . 32 77 3.6.4. Negotiation failure . . . . . . . . . . . . . . . . . 32 78 3.6.5. Cryptographic verification failure . . . . . . . . . 33 79 3.6.6. Application-specific failure . . . . . . . . . . . . 33 80 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 81 4.1. Cryptosuites . . . . . . . . . . . . . . . . . . . . . . 34 82 4.2. Message Types . . . . . . . . . . . . . . . . . . . . . . 34 83 4.3. Error codes . . . . . . . . . . . . . . . . . . . . . . . 35 84 4.4. Domain name reservation considerations . . . . . . . . . 36 85 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 37 86 5.1. Implementation with wpa_supplicant and hostapd . . . . . 37 87 5.2. Protocol modeling . . . . . . . . . . . . . . . . . . . . 38 88 6. Security considerations . . . . . . . . . . . . . . . . . . . 38 89 6.1. Authentication principle . . . . . . . . . . . . . . . . 38 90 6.2. Identifying correct endpoints . . . . . . . . . . . . . . 40 91 6.3. Trusted path issues and misbinding attacks . . . . . . . 40 92 6.4. Peer identifiers and attributes . . . . . . . . . . . . . 41 93 6.5. Identity protection . . . . . . . . . . . . . . . . . . . 42 94 6.6. Downgrading threats . . . . . . . . . . . . . . . . . . . 43 95 6.7. Recovery from loss of last message . . . . . . . . . . . 44 96 6.8. EAP security claims . . . . . . . . . . . . . . . . . . . 45 98 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 99 7.1. Normative references . . . . . . . . . . . . . . . . . . 47 100 7.2. Informative references . . . . . . . . . . . . . . . . . 48 101 Appendix A. Exchanges and events per state . . . . . . . . . . . 50 102 Appendix B. Application-specific parameters . . . . . . . . . . 51 103 Appendix C. ServerInfo and PeerInfo contents . . . . . . . . . . 52 104 Appendix D. EAP-NOOB roaming . . . . . . . . . . . . . . . . . . 54 105 Appendix E. OOB message as URL . . . . . . . . . . . . . . . . . 55 106 Appendix F. Example messages . . . . . . . . . . . . . . . . . . 56 107 Appendix G. TODO list . . . . . . . . . . . . . . . . . . . . . 58 108 Appendix H. Version history . . . . . . . . . . . . . . . . . . 58 109 Appendix I. Acknowledgments . . . . . . . . . . . . . . . . . . 60 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60 112 1. Introduction 114 This document describes a method for registration, authentication and 115 key derivation for network-connected ubiquitous computing devices, 116 such as consumer and enterprise appliances that are part of the 117 Internet of Things (IoT). These devices may be off-the-shelf 118 hardware that is sold and distributed without any prior registration 119 or credential-provisioning process. Thus, the device registration in 120 a server database, ownership of the device, and the authentication 121 credentials for both network access and application-level security 122 must all be established at the time of the device deployment. 123 Furthermore, many such devices have only limited user interfaces that 124 could be used for their configuration. Often, the interfaces are 125 limited to either only input (e.g. camera) or output (e.g. display 126 screen). The device configuration is made more challenging by the 127 fact that the devices may exist in large numbers and may have to be 128 deployed or re-configured nimbly based on user needs. 130 More specifically, the devices may have the following 131 characteristics: 133 o no pre-established relation with a specific server or user, 135 o no pre-provisioned device identifier or authentication 136 credentials, 138 o limited user interface and configuration capabilities. 140 Many proprietary OOB configuration methods exits for specific IoT 141 devices. The goal of this specification is to provide an open 142 standard and a generic protocol for bootstrapping the security of 143 network-connected appliances, such as displays, printers, speakers, 144 and cameras. The security bootstrapping in this specification makes 145 use of a user-assisted out-of-band (OOB) channel. The device 146 authentication relies on user having physical access to the device, 147 and the of the key exchange security is based on the assumption that 148 attackers are not able to observe or modify the messages conveyed 149 through the OOB channel. We follow the common approach taken in 150 pairing protocols: performing a Diffie-Hellman key exchange over the 151 insecure network and authenticating the established key with the help 152 of the OOB channel in order to prevent impersonation and man-in-the- 153 middle (MitM) attacks. 155 The solution presented here is intended for devices that have either 156 an input or output interface, such as a camera, microphone, display 157 screen, speakers or blinking LED light, which is able to send or 158 receive dynamically generated messages of tens of bytes in length. 159 Naturally, this solution may not be appropriate for very small 160 sensors or actuators that have no user interface at all or for 161 devices that are inaccessible to the user. We also assume that the 162 OOB channel is at least partly automated (e.g. camera scanning a bar 163 code) and, thus, there is no need to absolutely minimize the length 164 of the data transferred through the OOB channel. This differs, for 165 example, from Bluetooth simple pairing [BluetoothPairing], where it 166 is critical to minimize the length of the manually transferred or 167 compared codes. Since the OOB messages are dynamically generated, we 168 do not support static printed registration codes. This also prevents 169 attacks where a static secret code would be leaked. 171 2. Terminology 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 175 document are to be interpreted as described in [RFC2119]. 177 In addition, this document frequently uses the following terms as 178 they have been defined in [RFC5216]: 180 authenticator The entity initiating EAP authentication. 182 peer The entity that responds to the authenticator. In 183 [IEEE-802.1X], this entity is known as the supplicant. 185 server The entity that terminates the EAP authentication method with 186 the peer. In the case where no backend authentication server 187 is used, the EAP server is part of the authenticator. In the 188 case where the authenticator operates in pass-through mode, the 189 EAP server is located on the backend authentication server. 191 3. EAP-NOOB protocol 193 This section defines the EAP-NOOB protocol. The protocol is a 194 generalized version of the original idea presented by Sethi et al. 195 [Sethi14]. 197 3.1. Protocol overview 199 One EAP-NOOB protocol execution spans multiple EAP conversations, 200 called Exchanges. This is necessary to leave time for the OOB 201 message to be delivered, as will be explained below. 203 The overall protocol starts with the Initial Exchange, in which the 204 server allocates an identifier to the peer, and the server and peer 205 negotiate the protocol version and cryptosuite (i.e. cryptographic 206 algorithm suite), exchange nonces and perform an Ephemeral Elliptic 207 Curve Diffie-Hellman (ECDHE) key exchange. The user-assisted OOB 208 Step then takes place. This step requires only one out-of-band 209 message either from the peer to the server or from the server to the 210 peer. While waiting for the OOB Step action, the peer MAY probe the 211 server by reconnecting to it with EAP-NOOB. If the OOB Step has 212 already taken place, the probe leads to the Completion Exchange, 213 which completes the mutual authentication and key confirmation. On 214 the other hand, if the OOB Step has not yet taken place, the probe 215 leads to the Waiting Exchange, and the peer will perform another 216 probe after a server-defined minimum waiting time. The Initial 217 Exchange and Waiting Exchange always end in EAP-Failure, while the 218 Completion Exchange may result in EAP-Success. Once the peer and 219 server have performed a successful Completion Exchange, both 220 endpoints store the created association in persistent storage, and 221 the OOB Step is not repeated. Thereafter, creation of new temporal 222 keys, ECDHE rekeying, and updates of cryptographic algorithms can be 223 achieved with the Reconnect Exchange. 225 OOB Output/Initial Exchange/ 226 Waiting Exchange 227 .-----. 228 | v 229 .------------------. Initial .------------------. 230 | | Exchange | | 231 .->| 0. Unregistered |---------------->|1. Waiting for OOB| 232 | | | | | 233 | '------------------' '------------------' 234 | | | ^ 235 User Reset Completion | | | 236 | Exchange | OOB OOB 237 |<-------. .-------------------------' Input Reject/ 238 | | | | Initial 239 | | | | Exchange 240 | | v v | 241 | .------------------. Completion .------------------. 242 | | | Exchange | | 243 | | 4. Registered |<----------------| 2. OOB Received | 244 | | | | | 245 | '------------------' '------------------' 246 | | ^ 247 | Mobility/ | 248 | Timeout/ Reconnect 249 | Failure Exchange 250 | | | 251 | v | 252 | .-----------------. 253 | | | 254 '--| 3. Reconnecting | 255 | | 256 '-----------------' 258 Figure 1: EAP-NOOB server-peer association state machine 260 Figure 1 shows the association state machine, which is the same for 261 the server and for the peer. (For readability, only the main state 262 transitions are shown. The complete table of transitions can be 263 found in Appendix A.) When the peer initiates the EAP-NOOB method, 264 the server chooses the ensuing message exchange based on the 265 combination of the server and peer states. The EAP server and peer 266 are initially in the Unregistered state, in which no state 267 information needs to be stored. Before a successful Completion 268 Exchange, the server-peer association state is ephemeral in both the 269 server and peer (ephemeral states 0..2), and either endpoint may 270 cause the protocol to fall back to the Initial Exchange. After the 271 Completion Exchange has resulted in EAP-Success, the association 272 state becomes persistent (persistent states 3..4). Only user reset 273 or memory failure can cause the return of the server or the peer from 274 the persistent states to the ephemeral states and to the Initial 275 Exchange. 277 The server MUST NOT repeat a successful OOB Step with the same peer 278 except if the association with the peer is explicitly reset by the 279 user or lost due to failure of the persistent storage in the server. 280 More specifically, once the association has entered the Registered 281 state, the server MUST NOT delete the association or go back to 282 states 0..2 without explicit user approval. Similarly, the peer MUST 283 NOT repeat the OOB Step unless the user explicitly deletes from the 284 peer the association with the server or resets the peer to the 285 Unregistered state. The server and peer MAY implement user reset of 286 the association by deleting the state data from that endpoint. If an 287 endpoint continues to store data about the association after the user 288 reset, its behavior SHOULD be equivalent to having deleted the 289 association data. 291 It can happen that the peer accidentally or through user reset loses 292 its persistent state and reconnects to the server without a 293 previously allocated peer identifier. In that case, the server MUST 294 treat the peer as a new peer. The server MAY use auxiliary 295 information, such as the PeerInfo field received in the Initial 296 Exchange, to detect multiple associations with the same peer. 297 However, it MUST NOT delete or merge redundant associations without 298 user or application approval because EAP-NOOB internally has no 299 secure way of verifying that the two peers are the same physical 300 device. Similarly, the server might lose the association state 301 because of a memory failure or user reset. In that case, the only 302 way to recover is that the user resets also the peer. 304 A special feature of the EAP-NOOB method is that the server is not 305 assumed to have any a-priori knowledge of the peer. Therefore, the 306 peer initially uses the generic identity string "noob@eap-noob.net" 307 as its network access identifier (NAI). The server then allocates a 308 server-specific identifier to the peer. The generic NAI serves two 309 purposes: firstly, it tells the server that the peer supports and 310 expects the EAP-NOOB method and, secondly, it allows routing of the 311 EAP-NOOB sessions to a specific authentication server in the AAA 312 architecture. 314 EAP-NOOB is an unusual EAP method in that the peer has to have 315 multiple EAP conversations with the server before it can receive EAP- 316 Success. The reason is that, while EAP allows delays between the 317 request-response pairs, e.g. for repeated password entry, the user 318 delays in OOB authentication can be much longer than in password 319 trials. In particular, EAP-NOOB supports also peers with no input 320 capability in the user interface. Since user cannot initiate the 321 protocol in these devices, they have to perform the Initial Exchange 322 opportunistically and hope for the OOB Step to take place within a 323 timeout period (NoobTimeout), which is why the timeout needs to be 324 several minutes rather than seconds. For example, consider a printer 325 (peer) that outputs the OOB message on paper, which is then scanned 326 for the server. To support such high-latency OOB channels, the peer 327 and server perform the Initial Exchange in one EAP conversation, then 328 allow time for the OOB message to be delivered, and later perform the 329 Waiting and Completion Exchanges in different EAP conversations. 331 3.2. Protocol messages and sequences 333 This section defines the EAP-NOOB exchanges, which correspond to EAP 334 conversations. The protocol messages in each exchange and the data 335 members in each message are listed in the diagrams below. 337 Each EAP-NOOB exchange begins with the authenticator sending an EAP- 338 Request/Identity packet to the peer. From this point on, the EAP 339 conversation occurs between the server and the peer, and the 340 authenticator acts as a pass-through device. The peer responds to 341 the authenticator with an EAP-Response/Identity packet, containing 342 the network access identifier (NAI), which conveys both the peer 343 identity and the current peer state as defined in Section 3.3.1. 345 After receiving the NAI, the server chooses the EAP-NOOB exchange, 346 i.e. the ensuing message sequence, based on the combination of the 347 peer and server states. The peer recognizes the exchange based on 348 the message type field (Type) of the EAP-NOOB request received from 349 the server. The available exchanges are defined in the following 350 subsections. Each exchange comprises one or more EAP requests- 351 response pairs and ends in either EAP-Failure, indicating that 352 authentication is not (yet) successful, or in EAP-Success. 354 3.2.1. Initial Exchange 356 Upon receiving the EAP-Response/Identity from the peer, if either the 357 peer or the server is in the Unregistered (0) state and the other is 358 in one of the ephemeral states (0..2), the server chooses the Initial 359 Exchange. 361 The Initial Exchange comprises two EAP-NOOB request-response pairs, 362 one for version, cryptosuite and parameter negotiation and the other 363 for the ECDHE key exchange. The first EAP-NOOB request (Type=1) from 364 the server contains a newly allocated PeerId for the peer and an 365 optional Realm. The server allocates a new PeerId in the Initial 366 Exchange regardless of any old PeerId in the username part of the 367 received NAI. The server also sends in the request a list of the 368 protocol versions (Vers) and cryptosuites (Cryptosuites) it supports, 369 an indicator of the OOB channel directions it supports (Dirs), and a 370 ServerInfo object. The peer chooses one of the versions and 371 cryptosuites. The peer sends a response (Type=1) with the selected 372 protocol version (Verp), the received PeerId, the selected 373 cryptosuite (Cryptosuitep), an indicator of the OOB channel 374 directions selected by the peer (Dirp), and a PeerInfo object. In 375 the second EAP-NOOB request and response (Type=2), the server and 376 peer exchange the public components of their ECDHE keys and nonces 377 (PKs,Ns,PKp,Np). The ECDHE keys MUST be based on the negotiated 378 cryptosuite i.e. Cryptosuitep. The Initial Exchange ends always with 379 EAP-Failure from the server because the authentication cannot yet be 380 completed. 382 EAP Peer EAP Server 383 | | 384 |<----------- EAP-Request/Identity -| | 385 | | 386 | | 387 |------------ EAP-Response/Identity -------------->| 388 | (NAI=noob|PeerId+sX@eap-noob.net) | 389 | | 390 | | 391 |<----------- EAP-Request/EAP-NOOB ----------------| 392 | (Type=1,Vers,PeerId,[Realm], | 393 | Cryptosuites,Dirs,ServerInfo) | 394 | | 395 | | 396 |------------ EAP-Response/EAP-NOOB -------------->| 397 | (Type=1,Verp,PeerId,Cryptosuitep, | 398 | Dirp,PeerInfo) | 399 | | 400 | | 401 |<----------- EAP-Request/EAP-NOOB ----------------| 402 | (Type=2,PeerId,PKs,Ns,[SleepTime]) | 403 | | 404 | | 405 |------------ EAP-Response/EAP-NOOB -------------->| 406 | (Type=2,PeerId,PKp,Np) | 407 | | 408 | | 409 |<----------- EAP-Failure -------------------------| 410 | | 412 Figure 2: Initial Exchange 414 At the conclusion of the Initial Exchange, both the server and the 415 peer move to the Waiting for OOB (1) state. 417 3.2.2. OOB Step 419 The OOB Step, labeled as OOB Output and OOB Input in Figure 1, takes 420 place after the Initial Exchange. Depending on the direction 421 negotiated, the peer or the server outputs the OOB message shown in 422 Figure 3 or Figure 4, respectively. The data fields are the PeerId, 423 the secret nonce Noob, and the cryptographic fingerprint Hoob. The 424 contents of the data fields are defined in Section 3.3.2. The OOB 425 message is delivered to the other endpoint via a user-assisted OOB 426 channel. 428 EAP Peer EAP Server 429 | | 430 |=================OOB=============================>| 431 | (PeerId,Noob,Hoob) | 432 | | 434 Figure 3: OOB Step, from peer to EAP server 436 EAP Peer EAP Server 437 | | 438 |<================OOB==============================| 439 | (PeerId,Noob,Hoob) | 440 | | 442 Figure 4: OOB Step, from EAP server to peer 444 The receiver of the OOB message MUST compare the received value of 445 the fingerprint Hoob with a value that it computes locally. If the 446 values are equal, the receiver moves to the OOB Received (2) state. 447 Otherwise, the receiver MUST reject the OOB message. For usability 448 reasons, the receiver SHOULD indicate the acceptance or rejection of 449 the OOB message to the user. The receiver SHOULD reject invalid OOB 450 messages without changing its state, until an application-specific 451 number of invalid messages (OobRetries) has been reached, after which 452 the receiver SHOULD consider it an error and go back to the 453 Unregistered (0) state. 455 The server or peer MAY send multiple OOB messages with different Noob 456 values while in the Waiting for OOB (1) state. The OOB sender SHOULD 457 remember the Noob values until they expire and accept any one of them 458 in the following Completion Exchange. The Noob values sent by the 459 server expire after an application-dependent timeout (NoobTimeout), 460 and the server MUST NOT accept Noob values older than that in the 461 Completion Exchange. The RECOMMENDED value for NoobTimeout is 3600 462 seconds if there are no application-specific reasons for making it 463 shorter or longer. The Noob values sent by the peer expire as 464 defined in Section 3.2.4. 466 The OOB receiver does not accept further OOB messages after it has 467 accepted one and moved to the OOB Received (2) state. However, the 468 receiver MAY buffer redundant OOB messages in case OOB message expiry 469 or similar error detected in the Completion Exchange causes it to 470 return to the Waiting for OOB (1) state. It is RECOMMENED that the 471 OOB receiver notifies the user about redundant OOB messages, but it 472 MAY also discard them silently. 474 The sender will typically generate a new Noob, and therefore a new 475 OOB message, at constant time intervals (NoobInterval). The 476 RECOMMENDED interval is NoobInterval = NoobTimeout / 2, so that the 477 two latest values are always accepted. However, the timing of the 478 Noob generation may also be based on user interaction or on 479 implementation considerations. 481 Even though not recommended (see Section 3.3), this specification 482 allows both directions to be negotiated (Dirp=3) for the OOB channel. 483 In that case, both sides SHOULD output the OOB message, and it is up 484 to the user to deliver one of them. 486 The details of the OOB channel implementation including the message 487 encoding are defined by the application. Appendix E gives an example 488 of how the OOB message can be encoded as a URL that may be embedded 489 in a QR code and NFC tag. 491 3.2.3. Completion Exchange 493 After the Initial Exchange, if both the server and the peer support 494 the peer-to-server direction for the OOB channel, the peer SHOULD 495 initiate the EAP-NOOB method again after an applications-specific 496 waiting time in order to probe for completion of the OOB Step. Also, 497 if both sides support the server-to-peer direction of the OOB 498 exchange and the peer receives the OOB message, it SHOULD initiate 499 the EAP-NOOB method immediately. Once the server receives the EAP- 500 Response/Identity, if one of the server and peer is in the OOB 501 Received (2) state and the other is either in the Waiting for OOB (1) 502 or OOB Received (2) state, the OOB Step has taken place and the 503 server SHOULD continue with the Completion Exchange. 505 The Completion Exchange comprises one or two EAP-NOOB request- 506 response pairs. If the peer is in the Waiting for OOB (1) state, the 507 OOB message has been sent in the peer-to-server direction. In that 508 case, only one request-response pair (Type=4) takes place. In the 509 request, the server sends the NoobId value, which the peer uses to 510 identify the exact OOB message received by the server. On the other 511 hand, if the peer is in the OOB Received (2) state, the direction of 512 the OOB message is from server to peer. In that case, two request- 513 response pairs (Type=8 and Type=4) are needed. The purpose of the 514 first request-response pair (Type=8) is that it enables the server to 515 discover NoobId, which identifies the exact OOB message received by 516 the peer. The server returns the same NoobId to the peer in the 517 latter request. 519 In the last and sometimes only request-response pair (Type=4) of the 520 Completion Exchange, the server and peer exchange message 521 authentication codes. Both sides MUST compute the keys Kms and Kmp 522 as defined in Section 3.5 and the message authentication codes MACs 523 and MACp as defined in Section 3.3.2. Both sides MUST compare the 524 received message authentication code with a locally computed value. 525 If the peer finds that it has received the correct value of MACs and 526 the server finds that it has received the correct value of MACp, the 527 Completion Exchange ends in EAP-Success. Otherwise, the endpoint 528 where the comparison fails indicates this with an error message 529 (error code 4001, see Section 3.6.1) and the Completion Exchange ends 530 in EAP-Failure. 532 After successful Completion Exchange, both the server and the peer 533 move to the Registered (4) state. They also derive the output keying 534 material and store the persistent EAP-NOOB association state as 535 defined in Section 3.4 and Section 3.5. 537 It is possible that the OOB message expires before it is received. 538 In that case, the sender of the OOB message no longer recognizes the 539 NoobId that it receives in the Completion Exchange. Another reason 540 why the OOB sender might not recognize the NoobId is if the received 541 OOB message was spoofed and contained an attacker-generated Noob 542 value. The recipient of an unrecognized NoobId indicates this with 543 an error message (error code 2003, see Section 3.6.1) and the 544 Completion Exchange ends in EAP-Failure. The recipient of the error 545 message 2003 moves back to the Waiting for OOB (1) state. This state 546 transition is shown as OOB Reject in Figure 1 (even though it really 547 is a specific type of failed Completion Exchange). The sender of the 548 error message, on the other hand, stays in its previous state. 550 Although it is not expected to occur in practice, poor user interface 551 design could lead to two OOB messages delivered simultaneously, one 552 from the peer to the server and the other from the server to the 553 peer. The server detects this event in the beginning of the 554 Completion Exchange by observing that both the server and peer are in 555 the OOB Received state (2). In that case, as a tiebreaker, the 556 server MUST behave as if only the server-to-peer message had been 557 delivered. 559 EAP Peer EAP Server 560 | | 561 |<----------- EAP-Request/Identity -| | 562 | | 563 | | 564 |------------ EAP-Response/Identity -------------->| 565 | (NAI=PeerId+sX@eap-noob.net) | 566 | | 567 | | 568 |<----------- [ EAP-Request/EAP-NOOB ] ------------| 569 | (Type=8,PeerId) | 570 | | 571 | | 572 |------------ [ EAP-Response/EAP-NOOB ] ---------->| 573 | (Type=8,PeerId,NoobId) | 574 | | 575 | | 576 |<----------- EAP-Request/EAP-NOOB ----------------| 577 | (Type=4,PeerId,NoobId,MACs) | 578 | | 579 | | 580 |------------ EAP-Response/EAP-NOOB -------------->| 581 | (Type=4,PeerId,MACp) | 582 | | 583 | | 584 |<----------- EAP-Success -------------------------| 585 | | 587 Figure 5: Completion Exchange 589 3.2.4. Waiting Exchange 591 As explained in Section 3.2.3, the peer SHOULD probe the server for 592 completion of the OOB Step. Once the server receives the EAP- 593 Response/Identity, if both the server and peer states are in the 594 Waiting for OOB (1) state, the server will continue with the Waiting 595 Exchange (Type=3). The main purpose of this exchange is to inform 596 the peer that the server has not yet received a peer-to-server OOB 597 message. 599 In order to limit the rate at which peers probe the server, the 600 server MAY send to the peer either in the Initial Exchange or in the 601 Waiting Exchange a minimum time to wait before probing the server 602 again. A peer that has not received an OOB message MUST wait at 603 least the server-specified minimum waiting time in seconds 604 (SleepTime) before initiating EAP again with the same server. The 605 peer uses the latest SleepTime value that it has received in or after 606 the Initial Exchange. If the server has not sent any SleepTime 607 value, the peer SHOULD wait for an application-specified minimum time 608 (SleepTimeDefault). 610 After the Waiting Exchange, the peer MUST discard (from its local 611 ephemeral storage) Noob values that it has sent to the server in OOB 612 messages that are older than the application-defined timeout 613 NoobTimeout (see Section 3.2.2). The peer SHOULD discard such 614 expired Noob values even if the probing failed, e.g. because of 615 failure to connect to the EAP server or incorrect HMAC. The timeout 616 of peer-generated Noob values is defined like this in order to allow 617 the peer to probe the server once after it has waited for the server- 618 specified SleepTime. 620 If the server and peer have negotiated to use only the server-to-peer 621 direction for the OOB channel (Dirp=2), the peer SHOULD nevertheless 622 probe the server. The purpose of this is to keep the server informed 623 about the peers that are still waiting for OOB messages. The server 624 MAY set SleepTime to a high number (3600) to prevent the peer from 625 probing the server frequently. 627 EAP Peer EAP Server 628 | | 629 |<----------- EAP-Request/Identity -| | 630 | | 631 | | 632 |------------ EAP-Response/Identity -------------->| 633 | (NAI=PeerId+s1@eap-noob.net) | 634 | | 635 | | 636 |<----------- EAP-Request/EAP-NOOB ----------------| 637 | (Type=3,PeerId,[SleepTime]) | 638 | | 639 | | 640 |------------ EAP-Response/EAP-NOOB -------------->| 641 | (Type=3,PeerId) | 642 | | 643 | | 644 |<----------- EAP-Failure -------------------------| 645 | | 647 Figure 6: Waiting Exchange 649 3.3. Protocol data fields 651 This section defines the various identifiers and data fields used in 652 the EAP-NOOB protocol. 654 3.3.1. Peer identifier, realm and NAI 656 The server allocates a new peer identifier (PeerId) for the peer in 657 the Initial Exchange. The peer identifier MUST follow the syntax of 658 the utf8-username specified in [RFC7542]; however, it MUST NOT exceed 659 60 bytes in length and MUST NOT contain the character '+'. The 660 server MUST generate the identifiers in such a way that they do not 661 repeat and cannot be guessed by the peer or third parties before the 662 server sends them to the peer in the Initial Exchange. One way to 663 generate the identifiers is to choose a random 16-byte identifier and 664 to base64url encode it without padding [RFC4648] into a 22-character 665 string. Another way to generate the identifiers is to choose a 666 random 22-character alphanumeric string. It is not advisable to use 667 identifiers longer than this because they result in longer OOB 668 messages. 670 When the peer is in one of the states 1..2, the peer MUST use the 671 PeerId that the server assigned to it in the latest Initial Exchange. 672 When the peer is in one of the persistent states 3..4, it MUST use 673 the PeerId from its persistent EAP-NOOB association. When the peer 674 is in the Unregistered (0) state, it MUST use the default value 675 "noob" as its PeerId. 677 The server MAY also assign a realm (Realm) to the peer by in the 678 Initial Exchange or Reconnect Exchange. The realm value MUST follow 679 the syntax of the utf8-realm specified in [RFC7542]. When the peer 680 is in one of the states 1..2, the peer MUST use the Realm that the 681 server assigned to it the latest Initial Exchange, if one was 682 assigned. When the peer is in one of the persistent states 3..4, it 683 MUST use the Realm from its persistent EAP-NOOB association, if one 684 is stored in the association. When the peer is in the Unregistered 685 (0) state, or when the peer is in one of the other states 1..4 and 686 the server has not assigned it a realm, the peer SHOULD use the 687 default realm "eap-noob.net". However, the user or application MAY 688 provide a different default realm to the peer. 690 To compose its NAI [RFC7542], the peer uses the PeerId in the user 691 part and the Realm as the realm part. When no server-assigned PeerId 692 or Realm is available, the default value is used instead. In the 693 Unregistered (0) state, the peer must create the NAI as the 694 concatenation of the PeerId, the symbol "@", and the Realm. In the 695 other states 1..4, the peer MUST create the NAI as the concatenation 696 of the PeerId, the string "+s", a single numeric character indicating 697 the state of the peer, and the Realm. 699 Note that a new peer typically sends the NAI "noob@eap-noob.net" in 700 its first EAP-Response/Identity message, and it is always acceptable 701 for a peer that is in the Unregistered (0) state to use this default 702 NAI. The purpose of the state indicator "+sX" is to inform the 703 server about the peer state without the cost of an additional round 704 trip. The server uses this information together with the server 705 state to decide on the type of the exchange and, thus, the type of 706 the next EAP-Request. The lack of a state indicator in the NAI means 707 that that peer is in state 0. 709 The purpose of the server-assigned realm is to enable more flexible 710 routing of the EAP sessions over the AAA infrastructure, including 711 roaming scenarios (see Appendix D). Moreover, some Authenticators or 712 AAA servers use the assigned Realm to determine peer-specific 713 connection parameters, such as isolating the peer to a specific VLAN. 714 The possibility to configure a different default realm enables 715 registration of new devices while roaming. It also enables 716 manufacturers to set up their own AAA servers for bootstrapping of 717 new peer devices. 719 The peer's PeerId and Realm are ephemeral until a successful 720 Completion Exchange takes place. Thereafter, the values become parts 721 of the persistent EAP-NOOB association, until the user resets the 722 peer and the server or until a new Realm is assigned in the Reconnect 723 Exchange. 725 3.3.2. Message data fields 727 Table 1 defines the data fields in the protocol messages. The in- 728 band messages are formatted as JSON objects [RFC8259] in UTF-8 729 encoding. The JSON member names are in the left-hand column of the 730 table. 732 +------------------+------------------------------------------------+ 733 | Data field | Description | 734 +------------------+------------------------------------------------+ 735 | Vers, Verp | EAP-NOOB protocol versions supported by the | 736 | | EAP server, and the protocol version chosen by | 737 | | the peer. Vers is a JSON array of unsigned | 738 | | integers, and Verp is an unsigned integer. | 739 | | Example values are "[1]" and "1", | 740 | | respectively. | 741 | | | 742 | PeerId | Peer identifier as defined in Section 3.3.1. | 743 | | | 744 | Realm | Peer realm as defined in Section 3.3.1. | 745 | | | 746 | Peer State "+sX" | Peer state indicator as defined in Section | 747 | | 3.3.1. | 748 | | | 749 | Type | EAP-NOOB message type. The type is an integer | 750 | | in the range 0..8. EAP-NOOB requests and the | 751 | | corresponding responses share the same type | 752 | | value. | 753 | | | 754 | PKs, PKp | The public components of the ECDHE keys of the | 755 | | server and peer. PKs and PKp are sent in the | 756 | | JSON Web Key (JWK) format [RFC7517]. Detailed | 757 | | format of the JWK object is defined by the | 758 | | cryptosuite. | 759 | | | 760 | Cryptosuites, | The identifiers of cryptosuites supported by | 761 | Cryptosuitep | the server and of the cryptosuite selected by | 762 | | the peer. The server-supported cryptosuites in | 763 | | Cryptosuites are formatted as a JSON array of | 764 | | the identifier integers. The server MUST send | 765 | | a nonempty array with no repeating elements, | 766 | | ordered by decreasing priority. The peer MUST | 767 | | respond with exactly one suite in the | 768 | | Cryptosuitep value, formatted as an identifier | 769 | | integer. The registration of cryptosuites is | 770 | | specified in Section 4.1. Example values are | 771 | | "[1]" and "1", respectively. | 772 | | | 773 | Dirs, Dirp | The OOB channel directions supported by the | 774 | | server and the directions selected by the | 775 | | peer. The possible values are 1=peer-to- | 776 | | server, 2=server-to-peer, 3=both directions. | 777 | | | 778 | Dir | The actual direction of the OOB message (1 | 779 | | =peer-to-server, 2=server-to-peer). This value | 780 | | is not sent over any communication channel but | 781 | | it is included in the computation of the | 782 | | cryptographic fingerprint Hoob. | 783 | | | 784 | Ns, Np | 32-byte nonces for the Initial Exchange. | 785 | | | 786 | ServerInfo | This field contains information about the | 787 | | server to be passed from the EAP method to the | 788 | | application layer in the peer. The information | 789 | | is specific to the application or to the OOB | 790 | | channel and it is encoded as a JSON object of | 791 | | at most 500 bytes. It could include, for | 792 | | example, the access-network name and server | 793 | | name or a Uniform Resource Locator (URL) | 794 | | [RFC4266] or some other information that helps | 795 | | the user to deliver the OOB message to the | 796 | | server through the out-of-band channel. | 797 | | | 798 | PeerInfo | This field contains information about the peer | 799 | | to be passed from the EAP method to the | 800 | | application layer in the server. The | 801 | | information is specific to the application or | 802 | | to the OOB channel and it is encoded as a JSON | 803 | | object of at most 500 bytes. It could include, | 804 | | for example, the peer brand, model and serial | 805 | | number, which help the user to distinguish | 806 | | between devices and to deliver the OOB message | 807 | | to the correct peer through the out-of-band | 808 | | channel. | 809 | | | 810 | SleepTime | The number of seconds for which peer MUST NOT | 811 | | start a new execution of the EAP-NOOB method | 812 | | with the authenticator, unless the peer | 813 | | receives the OOB message or the peer is reset | 814 | | by the user. The server can use this field to | 815 | | limit the rate at which peers probe it. | 816 | | SleepTime is an unsigned integer in the range | 817 | | 0..3600. | 818 | | | 819 | Noob | 16-byte secret nonce sent through the OOB | 820 | | channel and used for the session key | 821 | | derivation. The endpoint that received the OOB | 822 | | message uses this secret in the Completion | 823 | | Exchange to authenticate the exchanged key to | 824 | | the endpoint that sent the OOB message. | 825 | | | 826 | Hoob | 16-byte cryptographic fingerprint (i.e. hash | 827 | | value) computed from all the parameters | 828 | | exchanged in the Initial Exchange and in the | 829 | | OOB message. Receiving this fingerprint over | 830 | | the OOB channel guarantees the integrity of | 831 | | the key exchange and parameter negotiation. | 832 | | Hence, it authenticates the exchanged key to | 833 | | the endpoint that receives the OOB message. | 834 | | | 835 | NoobId | 16-byte identifier for the OOB message, | 836 | | computed with a one-way function from the | 837 | | nonce Noob in the message. | 838 | | | 839 | MACs, MACp | Message authentication codes (HMAC) for mutual | 840 | | authentication, key confirmation, and | 841 | | integrity check on the exchanged information. | 842 | | The input to the HMAC is defined below, and | 843 | | the key for the HMAC is defined in Section | 844 | | 3.5. | 845 | | | 846 | Ns2, Np2 | 32-byte Nonces for the Reconnect Exchange. | 847 | | | 848 | KeyingMode | Integer indicating the key derivation method. | 849 | | 0 in the Completion Exchange, and 1..3 in the | 850 | | Reconnect Exchange. | 851 | | | 852 | PKs2, PKp2 | The public components of the ECDHE keys of the | 853 | | server and peer for the Reconnect Exchange. | 854 | | PKp2 and PKs2 are sent in the JSON Web Key | 855 | | (JWK) format [RFC7517]. Detailed format of the | 856 | | JWK object is defined by the cryptosuite. | 857 | | | 858 | MACs2, MACp2 | Message authentication codes (HMAC) for mutual | 859 | | authentication, key confirmation, and | 860 | | integrity check on the Reconnect Exchange. The | 861 | | input to the HMAC is defined below, and the | 862 | | key for the HMAC is defined in Section 3.5. | 863 | | | 864 | ErrorCode | Integer indicating an error condition. Defined | 865 | | in Section 4.3. | 866 | | | 867 | ErrorInfo | Textual error message for logging and | 868 | | debugging purposes. UTF-8 string of at most | 869 | | 500 bytes. | 870 | | | 871 +------------------+------------------------------------------------+ 873 Table 1: Message data fields 875 It is RECOMMENDED for servers to support both OOB channel directions 876 (Dirs=3), unless the type of the OOB channel limits them to one 877 direction (Dirs=1 or Dirs=2). On the other hand, it is RECOMMENDED 878 that the peer selects only one direction (Dirp=1 or Dirp=2) even when 879 both directions (Dirp=3) would be technically possible. The reason 880 is that, if value 3 is negotiated, the user may be presented with two 881 OOB messages, one for each direction, even though only one of them 882 needs to be delivered. This can be confusing to the user. 883 Nevertheless, the EAP-NOOB protocol is designed to cope also with 884 selected value 3, in which case it uses the first delivered OOB 885 message. In the unlikely case of simultaneously delivered OOB 886 messages, the protocol prioritizes the server-to-peer direction. 888 The nonces in the in-band messages (Ns, Np, Ns2, Np2) are 32-byte 889 fresh random byte strings, and the secret nonce Noob is a 16-byte 890 fresh random byte string. All the nonces are generated by the 891 endpoint that sends the message. 893 The fingerprint Hoob and the identifier NoobId are computed with the 894 cryptographic hash function specified in the negotiated cryptosuite 895 and truncated to the 16 leftmost bytes of the output. The message 896 authentication codes (MACs, MACp, MACs2, MACp2) are computed with the 897 HMAC function [RFC2104] based on the same cryptographic hash function 898 and truncated to the 32 leftmost bytes of the output. 900 The inputs to the hash function for computing the fingerprint Hoob 901 and to the HMAC for computing MACs, MACp, MACs2 and MACp2 are JSON 902 arrays containing a fixed number (17) of elements. The array 903 elements MUST be copied to the array verbatim from the sent and 904 received in-band messages. When the element is a JSON object, its 905 members MUST NOT be reordered or re-encoded. Whitespace MUST NOT be 906 added anywhere in the JSON structure. Implementers should check that 907 their JSON library copies the elements as UTF-8 strings and does not 908 modify then in any way, and that it does not add whitespace to the 909 HMAC input. 911 The inputs for computing the fingerprint and message authentication 912 codes are the following: 914 Hoob = H(Dir,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,Cryptos 915 uitep,Dirp,[Realm],PeerInfo,0,PKs,Ns,PKp,Np,Noob). 917 NoobId = H("NoobId",Noob). 919 KzId = H("KzId",Kz,Cryptosuitep). 921 MACs = HMAC(Kms; 2,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,C 922 ryptosuitep,Dirp,[Realm],PeerInfo,0,PKs,Ns,PKp,Np,Noob). 924 MACp = HMAC(Kmp; 1,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,C 925 ryptosuitep,Dirp,[Realm],PeerInfo,0,PKs,Ns,PKp,Np,Noob). 927 MACs2 = HMAC(Kms2; 2,Vers,Verp,PeerId,Cryptosuites,"",[ServerInfo] 928 ,Cryptosuitep,"",[Realm],[PeerInfo],KeyingMode,[PKs2],Ns2,[PKp2],N 929 p2,KzId) 931 MACp2 = HMAC(Kmp2; 1,Vers,Verp,PeerId,Cryptosuites,"",[ServerInfo] 932 ,Cryptosuitep,"",[Realm],[PeerInfo],KeyingMode,[PKs2],Ns2,[PKp2],N 933 p2,KzId) 935 Missing input values are represented by empty strings "" in the 936 array. The values indicated with "" above are always empty strings. 937 Realm is included in the computation of MACs and MACp if it was sent 938 or received in the preceding Initial Exchange. Each of the values in 939 brackets for the computation of Macs2 and Macp2 MUST be included if 940 it was sent or received in the same Reconnect Exchange; otherwise the 941 value is replaced by an empty string "". 943 The parameter Dir indicates the direction in which the OOB message 944 containing the Noob value is being sent (1=peer-to-server, 2=server- 945 to-peer). This field is included in the Hoob input to prevent the 946 user from accidentally delivering the OOB message back to its 947 originator in the rare cases where both OOB directions have been 948 negotiated. The keys (Kms, Kmp, Kms2, Kmp2) for the HMACs are 949 defined in Section 3.5. 951 The nonces (Ns, Np, Ns2, Np2, Noob) and the hash value (NoobId) MUST 952 be base64url encoded [RFC4648] when they are used as input to the 953 cryptograhic functions H or HMAC. These values and the message 954 authentication codes (MACs, MACp, MACs2, MACp2) MUST also be 955 base64url encoded when they are sent in the in-band messages. The 956 values Noob and Hoob in the OOB channel MAY be base64url encoded if 957 that is appropriate for the application and the OOB channel. All 958 base64url encoding is done without padding. The base64url encoded 959 values will naturally consume more space than the number of bytes 960 specified above (22-character string for a 16-byte nonce and 961 43-character string for a 32-byte nonce or message authentication 962 code). In the key derivation in Section 3.5, on the other hand, the 963 unencoded nonces (raw bytes) are used as input to the key derivation 964 function. 966 The ServerInfo and PeerInfo are JSON objects with UTF-8 encoding. 967 The length of either encoded object as a byte array MUST NOT exceed 968 500 bytes. The format and semantics of these objects MUST be defined 969 by the application that uses the EAP-NOOB method. 971 3.4. Fast reconnect and rekeying 973 EAP-NOOB implements Fast Reconnect ([RFC3748], section 7.2.1) that 974 avoids repeated use of the user-assisted OOB channel. 976 The rekeying and the Reconnect Exchange may be needed for several 977 reasons. New EAP output values MSK and EMSK may be needed because of 978 mobility or timeout of session keys. Software or hardware failure or 979 user action may also cause the authenticator, EAP server or peer to 980 lose its non-persistent state data. The failure would typically be 981 detected by the peer or authenticator when session keys no longer are 982 accepted by the other endpoint. Change in the supported cryptosuites 983 in the EAP server or peer may also cause the need for a new key 984 exchange. When the EAP server or peer detects any one of these 985 events, it MUST change from the Registered to Reconnecting state. 986 These state transitions are labeled Mobility/Timeout/Failure in 987 Figure 1. The EAP-NOOB method will then perform the Reconnect 988 Exchange next time when EAP is triggered. 990 3.4.1. Persistent EAP-NOOB association 992 To enable rekeying, the EAP server and peer store the session state 993 in persistent memory after a successful Completion Exchange. This 994 state data, called "persistent EAP-NOOB association", MUST include at 995 least the data fields shown in Table 2. They are used for 996 identifying and authenticating the peer in the Reconnect Exchange. 997 When a persistent EAP-NOOB association exists, the EAP server and 998 peer are in the Registered state (4) or Reconnecting state (3), as 999 shown in Figure 1. 1001 +------------------+------------------------------+-----------------+ 1002 | Data field | Value | Type | 1003 +------------------+------------------------------+-----------------+ 1004 | PeerId | Peer identifier allocated by | UTF-8 string | 1005 | | server | (typically 22 | 1006 | | | bytes) | 1007 | | | | 1008 | Verp | Negotiated protocol version | integer | 1009 | | | | 1010 | Cryptosuitep | Negotiated cryptosuite | integer | 1011 | | | | 1012 | CryptosuitepPrev | Previous cryptosuite | integer | 1013 | (at peer only) | | | 1014 | | | | 1015 | Realm | Optional realm assigned by | UTF-8 string | 1016 | | server (default value is | | 1017 | | "eap-noob.net") | | 1018 | | | | 1019 | Kz | Persistent key material | 32 bytes | 1020 | | | | 1021 | KzPrev (at | Previous Kz value | 32 bytes | 1022 | peer only) | | | 1023 | | | | 1024 | KzId | Kz identifier | 16 bytes | 1025 | | | | 1026 | KzIdPrev (at | Previous Kz identifier | 16 bytes | 1027 | peer only) | | | 1028 +------------------+------------------------------+-----------------+ 1030 Table 2: Persistent EAP-NOOB association 1032 3.4.2. Reconnect Exchange 1034 When the server receives the EAP-Response/Identity, the server 1035 chooses the Reconnect Exchange if the peer is in the Reconnecting (3) 1036 state and the server itself is in the Registered (4) or Reconnecting 1037 (3) state. The peer MUST NOT initiate EAP-NOOB when the peer is in 1038 Registered state. 1040 The Reconnect Exchange comprises three EAP-NOOB request-response 1041 pairs, one for cryptosuite and parameter negotiation, another for the 1042 nonce and ECDHE key exchange, and the last one for exchanging message 1043 authentication codes. In the first request and response (Type=5) the 1044 server and peer negotiate a protocol version and cryptosuite in the 1045 same way as in the Initial Exchange. The server SHOULD NOT offer and 1046 the peer MUST NOT accept protocol versions or cryptosuites that it 1047 knows to be weaker than the one currently in the Cryptosuitep field 1048 of the persistent EAP-NOOB association. The server SHOULD NOT 1049 needlessly change the cryptosuites it offers to the same peer because 1050 peer devices may have limited ability to update their persistent 1051 storage. However, if the peer has different values in the 1052 Cryptosuitep and CryptosuitepPrev fields, it SHOULD also accept 1053 offers that are not weaker than CryptosuitepPrev. Note that 1054 Cryptosuitep and CryptosuitePrev from the persistent EAP-NOOB 1055 association are only used to support the negotiation as described 1056 above; all actual cryptographic operations use the negotiated 1057 cryptosuite. The request and response (Type=5) MAY additionally 1058 contain PeerInfo and ServerInfo objects. 1060 The server then determines the KeyingMode (defined in Section 3.5) 1061 based on changes in the negotiated cryptosuite and whether it desires 1062 to achieve forward secrecy or not. The server SHOULD only select 1063 KeyingMode 3 when the negotiated cryptosuite differs from the 1064 Cryptosuitep in the server's persistent EAP-NOOB association, 1065 although it is technically possible to select this values without 1066 changing the cryptosuite. In the second request and response 1067 (Type=6), the server informs the peer about the KeyingMode, and the 1068 server and peer exchange nonces (Ns2, Np2). When KeyingMode is 2 or 1069 3 (rekeying with ECDHE), they also exchange public components of 1070 ECDHE keys (PKs2, PKp2). The server ECDHE key MUST be fresh, i.e. 1071 not previously used with the same peer, and the peer ECDHE key SHOULD 1072 be fresh, i.e. not previously used. 1074 In the third and final request and response (Type=7), the server and 1075 peer exchange message authentication codes. Both sides MUST compute 1076 the keys Kms2 and Kmp2 as defined in Section 3.5 and the message 1077 authentication codes MACs2 and MACp2 as defined in Section 3.3.2. 1078 Both sides MUST compare the received message authentication code with 1079 a locally computed value. 1081 The rules by which the peer compares the received MACs2 are non- 1082 trivial because, in addition to authenticating the current exchange, 1083 MACs2 may confirm the success or failure of a recent cryptosuite 1084 upgrade. The peer processes the final request (Type=7) as follows: 1086 1. The peer first compares the received MACs2 value with one it 1087 computed using the Kz stored in the persistent EAP-NOOB 1088 association. If the received and computed values match, the peer 1089 deletes any data stored in the CryptosuitepPrev and KzPrev fields 1090 of the persistent EAP-NOOB association. It does this because the 1091 received MACs2 confirms that the peer and server share the same 1092 Cryptosuitep and Kz, and any previous values must no longer be 1093 accepted. 1095 2. If, on the other hand, the peer finds that the received MACs2 1096 value does not match the one it computed locally with Kz, the 1097 peer checks whether the KzPrev field in the persistent EAP-NOOB 1098 association stores a key. If it does, the peer repeats the key 1099 derivation (Section 3.5) and local MACs2 computation 1100 (Section 3.3.2) using KzPrev in place of Kz. If this second 1101 computed MACs2 matches the received value, the match indicates 1102 synchronization failure caused by the loss of the last response 1103 (Type=7) in a previously attempted cryptosuite upgrade. In this 1104 case, the peer rolls back that upgrade by overwriting 1105 Cryptosuitep with CryptosuitepPrev and Kz with KzPrev in the 1106 persistent EAP-NOOB association. It also clears the 1107 CryptosuitepPrev and KzPrev fields. 1109 3. If the received MACs2 matched one of the locally computed values, 1110 the peer proceeds to send the final response (Type=7). The peer 1111 also moves to the Registered (4) state. When KeyingMode is 1 or 1112 2, the peer stops here. When KeyingMode is 3, the peer also 1113 updates the persistent EAP-NOOB association with the negotiated 1114 Cryptosuitep and the newly-derived Kz value. To prepare for 1115 possible synchronization failure caused by the loss of the final 1116 response (Type=7) during cryptosuite upgrade, the peer copies the 1117 old Cryptosuitep and Kz values in the persistent EAP-NOOB 1118 association to the CryptosuitepPrev and KzPrev fields. 1120 4. Finally, if the peer finds that the received MACs2 does not match 1121 either of the two values that it computed locally (or one value 1122 if no KzPrev was stored), the peer sends an error message (error 1123 code 4001, see Section 3.6.1), which causes the the Reconnect 1124 Exchange to end in EAP-Failure. 1126 The server rules for processing the final message are simpler than 1127 the peer rules because the server does not store previous keys and it 1128 never rolls back a cryptosuite upgrade. Upon receiving the final 1129 response (Type=7), the server compares the received value of MACp2 1130 with one it computes locally. If the values match, the Reconnect 1131 Exchange ends in EAP-Success. When KeyingMode is 3, the server also 1132 updates Cryptosuitep and Kz in the persistent EAP-NOOB association. 1133 On the other hand, if the server finds that the values do not match, 1134 it sends an error message (error code 4001), and the Reconnect 1135 Exchange ends in EAP-Failure. 1137 The endpoints MAY send updated Realm, ServerInfo and PeerInfo objects 1138 in the Reconnect Exchange. When there is no update to the values, 1139 they SHOULD omit this information from the messages. If the Realm 1140 was sent, each side updates Realm in the persistent EAP-NOOB 1141 association when moving to the Registered (4) state. 1143 EAP Peer EAP Server 1144 | | 1145 |<----------- EAP-Request/Identity -| | 1146 | | 1147 | | 1148 |------------ EAP-Response/Identity -------------->| 1149 | (NAI=PeerId+s3@eap-noob.net) | 1150 | | 1151 | | 1152 |<----------- EAP-Request/EAP-NOOB ----------------| 1153 | (Type=5,Vers,PeerId,Cryptosuites, | 1154 | [Realm],[ServerInfo]) | 1155 | | 1156 | | 1157 |------------ EAP-Response/EAP-NOOB -------------->| 1158 | (Type=5,Verp,PeerId,Cryptosuitep,[PeerInfo])| 1159 | | 1160 | | 1161 |<----------- EAP-Request/EAP-NOOB ----------------| 1162 | (Type=6,PeerId,KeyingMode,KzId,[PKs2],Ns2) | 1163 | | 1164 | | 1165 |------------ EAP-Response/EAP-NOOB -------------->| 1166 | (Type=6,PeerId,[PKp2],Np2) | 1167 | | 1168 | | 1169 |<----------- EAP-Request/EAP-NOOB ----------------| 1170 | (Type=7,PeerId,MACs2) | 1171 | | 1172 | | 1173 |------------ EAP-Response/EAP-NOOB -------------->| 1174 | (Type=7,PeerId,MACp2) | 1175 | | 1176 | | 1177 |<----------- EAP-Success -------------------------| 1178 | | 1180 Figure 7: Reconnect Exchange 1182 3.4.3. User reset 1184 As shown in the association state machine in Figure 1, the only 1185 specified way for the association to return from the Registered state 1186 (4) to the Unregistered state (0) is through user-initiated reset. 1187 After the reset, a new OOB message will be needed to establish a new 1188 association between the EAP server and peer. Typical situations in 1189 which the user reset is required are when the other side has 1190 accidentally lost the persistent EAP-NOOB association data, or when 1191 the peer device is decommissioned. 1193 The server could detect that the peer is in the Registered or 1194 Reconnecting state but the server itself is in one of the ephemeral 1195 states 0..2 (including situations where the server does not recognize 1196 the PeerId). In this case, effort should be made to recover the 1197 persistent server state, for example, from a backup storage - 1198 especially if many peer devices are similarly affected. If that is 1199 not possible, the EAP server SHOULD log the error or notify an 1200 administrator. The only way to continue from such a situation is by 1201 having the user reset the peer device. 1203 On the other hand, if the peer is in any of the ephemeral states 1204 0..2, including the Unregistered state, the server will treat the 1205 peer as a new peer device and allocate a new PeerId to it. The 1206 PeerInfo can be used by the user as a clue to which physical device 1207 has lost its state. However, there is no secure way of matching the 1208 "new" peer with the old PeerId without repeating the OOB Step. This 1209 situation will be resolved when the user performs the OOB Step and, 1210 thus, identifies the physical peer device. The server user interface 1211 MAY support situations where the "new" peer is actually a previously 1212 registered peer that has been reset by a user or otherwise lost its 1213 persistent data. In those cases, the user could choose to merge new 1214 peer identity with the old one in the server. The alternative is to 1215 treat the device just like a new peer. 1217 3.5. Key derivation 1219 EAP-NOOB derives the EAP output values MSK and EMSK and other secret 1220 keying material from the output of an Ephemeral Elliptic Curve 1221 Diffie-Hellman (ECDHE) algorithm following the NIST specification 1222 [NIST-DH]. In NIST terminology, we use a C(2, 0, ECC CDH) scheme, 1223 i.e. two ephemeral keys and no static keys. In the Initial and 1224 Reconnect Exchanges, the server and peer compute the ECDHE shared 1225 secret Z as defined in section 6.1.2.2 of the NIST specification 1226 [NIST-DH]. In the Completion and Reconnect Exchanges, the server and 1227 peer compute the secret keying material from Z with the single-step 1228 key derivation function (KDF) defined in section 5.8.1 of the NIST 1229 specification. The hash function H for KDF is taken from the 1230 negotiated cryptosuite. 1232 +------------+------------------------------------------------------+ 1233 | KeyingMode | Description | 1234 +------------+------------------------------------------------------+ 1235 | 0 | Completion Exchange (always with ECDHE) | 1236 | | | 1237 | 1 | Reconnect Exchange, rekeying without ECDHE | 1238 | | | 1239 | 2 | Reconnect Exchange, rekeying with ECHDE, no change | 1240 | | in cryptosuite | 1241 | | | 1242 | 3 | Reconnect Exchange, rekeying with ECDHE, new | 1243 | | cryptosuite negotiated | 1244 +------------+------------------------------------------------------+ 1246 Table 3: Keying modes 1248 The key derivation has three different modes (KeyingMode), which are 1249 specified in Table 3. Table 4 defines the inputs to KDF in each 1250 KeyingMode. 1252 In the Completion Exchange (KeyingMode=0), the input Z comes from the 1253 preceding Initial exchange. KDF takes some additional inputs 1254 (OtherInfo), for which we use the concatenation format defined in 1255 section 5.8.1.2.1 of the NIST specification [NIST-DH]. OtherInfo 1256 consists of the AlgorithmId, PartyUInfo, PartyVInfo, and SuppPrivInfo 1257 fields. The first three fields are fixed-length bit strings, and 1258 SuppPrivInfo is a variable-length string with a one-byte Datalength 1259 counter. AlgorithmId is the fixed-length 8-byte ASCII string "EAP- 1260 NOOB". The other input values are the server and peer nonces. In 1261 the Completion Exchange, the inputs also include the secret nonce 1262 Noob from the OOB message. 1264 In the simplest form of the Reconnect Exchange (KeyingMode=1), fresh 1265 nonces are exchanged but no ECDHE keys are sent. In this case, input 1266 Z to the KDF is replaced with the shared key Kz from the persistent 1267 EAP-NOOB association. The result is rekeying without the 1268 computational cost of the ECDHE exchange, but also without forward 1269 secrecy. 1271 When forward secrecy is desired in the Reconnect Exchange 1272 (KeyingMode=2 or KeyingMode=3), both nonces and ECDHE keys are 1273 exchanged. Input Z is the fresh shared secret from the ECDHE 1274 exchange with PKs2 and PKp2. The inputs also include the shared 1275 secret Kz from the persistent EAP-NOOB associatiob. This binds the 1276 rekeying output to the previously authenticated keys. 1278 +--------------+--------------+------------------------+------------+ 1279 | KeyingMode | KDF input | Value | Length | 1280 | | field | | (bytes) | 1281 +--------------+--------------+------------------------+------------+ 1282 | 0 | Z | ECDHE shared secret | variable | 1283 | Completion | | from PKs and PKp | | 1284 | | AlgorithmId | "EAP-NOOB" | 8 | 1285 | | PartyUInfo | Np | 32 | 1286 | | PartyVInfo | Ns | 32 | 1287 | | SuppPubInfo | (not allowed) | | 1288 | | SuppPrivInfo | Noob | 16 | 1289 | | | | | 1290 | 1 | Z | Kz | 32 | 1291 | Reconnect, | AlgorithmId | "EAP-NOOB" | 8 | 1292 | rekeying | PartyUInfo | Np2 | 32 | 1293 | without | PartyVInfo | Ns2 | 32 | 1294 | ECDHE | SuppPubInfo | (not allowed) | | 1295 | | SuppPrivInfo | (null) | 0 | 1296 | | | | | 1297 | 2 or 3 | Z | ECDHE shared secret | variable | 1298 | Reconnect, | | from PKs2 and PKp2 | | 1299 | rekeying, | AlgorithmId | "EAP-NOOB" | 8 | 1300 | with ECDHE, | PartyUInfo | Np2 | 32 | 1301 | same or new | PartyVInfo | Ns2 | 32 | 1302 | cryptosuite | SuppPubInfo | (not allowed) | | 1303 | | SuppPrivInfo | Kz | 32 | 1304 +--------------+--------------+------------------------+------------+ 1306 Table 4: Key derivation input 1308 Table 5 defines how the output bytes of KDF are used. In addition to 1309 the EAP output values MSK and EMSK, the server and peer derive 1310 another shared secret key AMSK, which MAY be used for application- 1311 layer security. Further output bytes are used internally by EAP-NOOB 1312 for the message authentication keys (Kms, Kmp, Kms2, Kmp2). 1314 The Completion Exchange (KeyingMode=0) produces the shared secret Kz, 1315 which the server and peer store in the persistent EAP-NOOB 1316 association. When a new cryptosuite is negotiated in the Reconnect 1317 Exchange (KeyingMode=3), it similarly produces a new Kz. In that 1318 case, the server and peer update both the cryptosuite and Kz in the 1319 persistent EAP-NOOB association. Additionally, the peer stores the 1320 previous Cryptosuitep and Kz values in the CryptosuitepPrev and 1321 KzPrev fields of the persistent EAP-NOOB association. 1323 +-----------------+------------------+----------+----------------+ 1324 | KeyingMode | KDF output bytes | Used as | Length (bytes) | 1325 +-----------------+------------------+----------+----------------+ 1326 | 0 | 0..63 | MSK | 64 | 1327 | Completion | 64..127 | EMSK | 64 | 1328 | | 128..191 | AMSK | 64 | 1329 | | 192..223 | MethodId | 32 | 1330 | | 224..255 | Kms | 32 | 1331 | | 256..287 | Kmp | 32 | 1332 | | 288..319 | Kz | 32 | 1333 | | | | | 1334 | 1 or 2 | 0..63 | MSK | 64 | 1335 | Reconnect, | 64..127 | EMSK | 64 | 1336 | rekeying | 128..191 | AMSK | 64 | 1337 | without ECDHE, | 192..223 | MethodId | 32 | 1338 | or with ECDHE | 224..255 | Kms2 | 32 | 1339 | and unchanged | 256..287 | Kmp2 | 32 | 1340 | cryptosuite | | | | 1341 | | | | | 1342 | | | | | 1343 | 3 Reconnect, | 0..63 | MSK | 64 | 1344 | rekeying | 64..127 | EMSK | 64 | 1345 | with ECDHE, | 128..191 | AMSK | 64 | 1346 | new cryptosuite | 192..223 | MethodId | 32 | 1347 | | 224..255 | Kms2 | 32 | 1348 | | 256..287 | Kmp2 | 32 | 1349 | | 288..319 | Kz | 32 | 1350 +-----------------+------------------+----------+----------------+ 1352 Table 5: Key derivation output 1354 Finally, every EAP method must export a Server-Id, Peer-Id and 1355 Session-Id [RFC5247]. In EAP-NOOB, the exported Peer-Id is the 1356 PeerId which the server has assigned to the peer. The exported 1357 Server-Id is a zero-length string (i.e. null string) because EAP-NOOB 1358 neither knows nor assigns any server identifier. The exported 1359 Session-Id is created by concatenating the Type-Code xxx (TBA) with 1360 the MethodId, which is obtained from the KDF output as shown in 1361 Table 5. 1363 3.6. Error handling 1365 Various error conditions in EAP-NOOB are handled by sending an error 1366 notification message (Type=0) instead of the expected next EAP 1367 request or response message. Both the EAP server and the peer may 1368 send the error notification, as shown in Figure 8 and Figure 9. 1369 After sending or receiving an error notification, the server MUST 1370 send an EAP-Failure (as required by [RFC3748] section 4.2). The 1371 notification MAY contain an ErrorInfo field, which is a UTF-8 encoded 1372 text string with a maximum length of 500 bytes. It is used for 1373 sending descriptive information about the error for logging and 1374 debugging purposes. 1376 EAP Peer EAP Server 1377 ... ... 1378 | | 1379 |<----------- EAP-Request/EAP-NOOB ----------------| 1380 | (Type=0,[PeerId],ErrorCode,[ErrorInfo]) | 1381 | | 1382 | | 1383 |<----------- EAP-Failure -------------------------| 1384 | | 1386 Figure 8: Error notification from server to peer 1388 EAP Peer EAP Server 1389 ... ... 1390 | | 1391 |------------ EAP-Response/EAP-NOOB -------------->| 1392 | (Type=0,[PeerId],ErrorCode,[ErrorInfo]) | 1393 | | 1394 | | 1395 |<----------- EAP-Failure -------------------------| 1396 | | 1398 Figure 9: Error notification from peer to server 1400 After the exchange fails due to an error notification, the server and 1401 peer set the association state as follows. In the Initial Exchange, 1402 both the sender and recipient of the error notification MUST set the 1403 association state to the Unregistered (0) state. In the Waiting and 1404 Completion Exchanges, each side MUST remain in its old state as if 1405 the failed exchange had not taken place, with the exception that the 1406 recipient of error code 2003 processes it as specified in 1407 Section 3.2.3. In the Reconnect Exchange, both sides MUST set the 1408 association state to the Reconnecting (3) state. 1410 Errors that occur in the OOB channel are not explicitly notified in- 1411 band. 1413 3.6.1. Invalid messages 1415 If the NAI structure is invalid, the server SHOULD send the error 1416 code 1001 to the peer. The recipient of an EAP-NOOB request or 1417 response SHOULD send the following error codes back to the sender: 1418 1002 if it cannot parse the message as a JSON object or the top-level 1419 JSON object has missing or unrecognized members; 1003 if a data field 1420 has an invalid value, such as an integer out of range, and there is 1421 no more specific error code available; 1004 if the received message 1422 type was unexpected in the current state; 2004 if the PeerId has an 1423 unexpected value; 2003 if the NoobId is not recognized; 2005 if the 1424 KzId is not recognized; and 1007 if the ECDHE key is invalid. 1426 3.6.2. Unwanted peer 1428 The preferred way for the EAP server to rate limit EAP-NOOB 1429 connections from a peer is to use the SleepTime parameter in the 1430 Waiting Exchange. However, if the EAP server receives repeated EAP- 1431 NOOB connections from a peer which apparently should not connect to 1432 this server, the server MAY indicate that the connections are 1433 unwanted by sending the error code 2001. After receiving this error 1434 message, the peer MAY refrain from reconnecting to the same EAP 1435 server and, if possible, both the EAP server and peer SHOULD indicate 1436 this error condition to the user or server administrator. However, 1437 in order to avoid persistent denial of service, the peer is not 1438 required to stop entirely from reconnecting to the server. 1440 3.6.3. State mismatch 1442 In the states indicated by "-" in Figure 10 in Appendix A, user 1443 action is required to reset the association state or to recover it, 1444 for example, from backup storage. In those cases, the server sends 1445 the error code 2002 to the peer. If possible, both the EAP server 1446 and peer SHOULD indicate this error condition to the user or server 1447 administrator. 1449 3.6.4. Negotiation failure 1451 If there is no matching protocol version, the peer sends the error 1452 code 3001 to the server. If there is no matching cryptosuite, the 1453 peer sends the error code 3002 to the server. If there is no 1454 matching OOB direction, the peer sends the error code 3003 to the 1455 server. 1457 In practice, there is no way of recovering from these errors without 1458 software or hardware changes. If possible, both the EAP server and 1459 peer SHOULD indicate these error conditions to the user. 1461 3.6.5. Cryptographic verification failure 1463 If the receiver of the OOB message detects an unrecognized PeerId or 1464 incorrect fingerprint (Hoob) in the OOB message, the receiver MUST 1465 remain in the Waiting for OOB state (1) as if no OOB message was 1466 received. The receiver SHOULD indicate the failure to accept the OOB 1467 message to the user. No in-band error message is sent. 1469 Note that if the OOB message was delivered from the server to the 1470 peer and the peer does not recognize the PeerId, the likely cause is 1471 that the user has unintentionally delivered the OOB message to the 1472 wrong peer device. If possible, the peer SHOULD indicate this to the 1473 user; however, the peer device may not have the capability for many 1474 different error indications to the user and it MAY use the same 1475 indication as in the case of an incorrect fingerprint. 1477 The rationale for the above is that the invalid OOB message could 1478 have been presented to the receiver by mistake or intentionally by a 1479 malicious party and, thus, it should be ignored in the hope that the 1480 honest user will soon deliver a correct OOB message. 1482 If the EAP server or peer detects an incorrect message authentication 1483 code (MACs, MACp, MACs2, MACp2), it sends the error code 4001 to the 1484 other side. As specified in the beginning of Section 3.6, the failed 1485 Completion Exchange will not result in server or peer state changes 1486 while error in the Reconnect Exchange will put both sides to the 1487 Reconnecting (3) state and thus lead to another reconnect attempt. 1489 The rationale for this is that the invalid cryptographic message may 1490 have been spoofed by a malicious party and, thus, it should be 1491 ignored. In particular, a spoofed message on the in-band channel 1492 should not force the honest user to perform the OOB Step again. In 1493 practice, however, the error may be caused by other failures, such as 1494 a software bug. For this reason, the EAP server MAY limit the rate 1495 of peer connections with SleepTime after the above error. Also, 1496 there SHOULD be a way for the user to reset the peer to the 1497 Unregistered state (0), so that the OOB Step can be repeated at the 1498 last resort. 1500 3.6.6. Application-specific failure 1502 Applications MAY define new error messages for failures that are 1503 specific to the application or to one type of OOB channel. They MAY 1504 also use the generic application-specific error code 5001, or the 1505 error codes 5002 and 5004, which have been reserved for indicating 1506 invalid data in the ServerInfo and PeerInfo fields, respectively. 1507 Additionally, anticipating OOB channels that make use of a URL, the 1508 error code 5003 has been reserved for indicating invalid server URL. 1510 4. IANA Considerations 1512 This section provides guidance to the Internet Assigned Numbers 1513 Authority (IANA) regarding registration of values related to the EAP- 1514 NOOB protocol, in accordance with [RFC8126]. 1516 The EAP Method Type number for EAP-NOOB needs to be assigned. 1518 This memo also requires IANA to create new registries as defined in 1519 the following subsections. 1521 4.1. Cryptosuites 1523 Cryptosuites are identified by an integer. Each cryptosuite MUST 1524 specify an ECDHE curve for the key exchange, encoding of the ECDHE 1525 public key as a JWK object, and a cryptographic hash function for the 1526 fingerprint and HMAC computation and key derivation. The hash value 1527 output by the cryptographic hash function MUST be at least 32 bytes 1528 in length. The following suites are defined by EAP-NOOB: 1530 +-------------+-----------------------------------------------------+ 1531 | Cryptosuite | Algorithms | 1532 +-------------+-----------------------------------------------------+ 1533 | 1 | ECDHE curve Curve25519 [RFC7748], public-key format | 1534 | | [RFC7518] Section 6.2.1, hash function SHA-256 | 1535 | | [RFC6234] | 1536 +-------------+-----------------------------------------------------+ 1538 Table 6: EAP-NOOB cryptosuites 1540 An example of Cryptosuite 1 public-key encoded as a JWK object is 1541 given below (line breaks are for readability only). 1543 "jwk":{"kty":"EC","crv":"Curve25519","x":"3p7bfXt9wbTTW2HC7OQ1Nz- 1544 DQ8hbeGdNrfx-FG-IK08"} 1546 Assignment of new values for new cryptosuites MUST be done through 1547 IANA with "Specification Required" and "IESG Approval" as defined in 1548 [RFC8126]. 1550 4.2. Message Types 1552 EAP-NOOB request and response pairs are identified by an integer 1553 Message Type. The following Message Types are defined by EAP-NOOB: 1555 +----------+------------+-------------------------------------------+ 1556 | Message | Used in | Purpose | 1557 | Type | Exchange | | 1558 +----------+------------+-------------------------------------------+ 1559 | 1 | Initial | Version, cryptosuite and parameter | 1560 | | | negotiation | 1561 | | | | 1562 | 2 | Initial | Exchange of ECDHE keys and nonces | 1563 | | | | 1564 | 3 | Waiting | Indication to peer that the server has | 1565 | | | not yet received an OOB message | 1566 | | | | 1567 | 4 | Completion | Authentication and key confirmation with | 1568 | | | HMAC | 1569 | | | | 1570 | 5 | Reconnect | Version, cryptosuite, and parameter | 1571 | | | negotiation | 1572 | | | | 1573 | 6 | Reconnect | Exchange of ECDHE keys and nonces | 1574 | | | | 1575 | 7 | Reconnect | Authentication and key confirmation with | 1576 | | | HMAC | 1577 | | | | 1578 | 8 | Completion | NoobId discovery | 1579 | | | | 1580 | 0 | Error | Error notification | 1581 | | | | 1582 +----------+------------+-------------------------------------------+ 1584 Table 7: EAP-NOOB 1586 Assignment of new values for new Message Types MUST be done through 1587 IANA with "Expert Review" as defined in [RFC8126]. 1589 4.3. Error codes 1591 The error codes defined by EAP-NOOB are listed in Table 8. 1593 +------------+----------------------------------------+ 1594 | Error code | Purpose | 1595 +------------+----------------------------------------+ 1596 | 1001 | Invalid NAI | 1597 | 1002 | Invalid message structure | 1598 | 1003 | Invalid data | 1599 | 1004 | Unexpected message type | 1600 | 1007 | Invalid ECDHE key | 1601 | 2001 | Unwanted peer | 1602 | 2002 | State mismatch, user action required | 1603 | 2003 | Unrecognized OOB message identifier | 1604 | 2004 | Unexpected peer identifier | 1605 | 2005 | Unrecognized Kz identifier | 1606 | 3001 | No mutually supported protocol version | 1607 | 3002 | No mutually supported cryptosuite | 1608 | 3003 | No mutually supported OOB direction | 1609 | 4001 | HMAC verification failure | 1610 | 5001 | Application-specific error | 1611 | 5002 | Invalid server info | 1612 | 5003 | Invalid server URL | 1613 | 5004 | Invalid peer info | 1614 | 6001-6999 | Private and experimental use | 1615 +------------+----------------------------------------+ 1617 Table 8: EAP-NOOB error codes 1619 Assignment of new error codes MUST be done through IANA with 1620 "Specification Required" and "IESG Approval" as defined in [RFC8126], 1621 with the exception of the range 6001-6999, which is reserved for 1622 "Private Use" and "Experimental Use". 1624 4.4. Domain name reservation considerations 1626 "eap-noob.net" should be registered as a special-use domain. The 1627 considerations required by [RFC6761] for registering this special-use 1628 domain name are the following: 1630 o Users: Non-admin users are not expected to encounter this name or 1631 recognize it as special. AAA administrators may need to recognize 1632 the name. 1634 o Application Software: Application software is not expected to 1635 recognize this domain name as special. 1637 o Name Resolution APIs and Libraries: Name resolution APIs and 1638 libraries are not expected to recognize this domain name as 1639 special. 1641 o Caching DNS Servers: Caching servers are not expected to recognize 1642 this domain name as special. 1644 o Authoritative DNS Servers: Authoritative DNS servers MUST respond 1645 to queries for eap-noob.net with NXDOMAIN. 1647 o DNS Server Operators: Except for the authoritative DNS server, 1648 there are no special requirements for the operators. 1650 o DNS Registries/Registrars: There are no special requirements for 1651 DNS registrars. 1653 5. Implementation Status 1655 This section records the status of known implementations of the 1656 protocol defined by this specification at the time of posting of this 1657 Internet-Draft, and is based on a proposal described in [RFC7942]. 1658 The description of implementations in this section is intended to 1659 assist the IETF in its decision processes in progressing drafts to 1660 RFCs. Please note that the listing of any individual implementation 1661 here does not imply endorsement by the IETF. Furthermore, no effort 1662 has been spent to verify the information presented here that was 1663 supplied by IETF contributors. This is not intended as, and must not 1664 be construed to be, a catalog of available implementations or their 1665 features. Readers are advised to note that other implementations may 1666 exist. 1668 5.1. Implementation with wpa_supplicant and hostapd 1670 o Responsible Organization: Aalto University 1672 o Location: 1674 o Coverage: This implementation includes all of the features 1675 described in the current specification. The implementation 1676 supports two dimensional QR codes and NFC as example out-of-band 1677 (OOB) channels 1679 o Level of Maturity: Alpha 1681 o Version compatibility: Version 03 of the draft implemented 1683 o Licensing: BSD 1685 o Contact Information: Tuomas Aura, tuomas.aura@aalto.fi 1687 5.2. Protocol modeling 1689 The current EAP-NOOB specification has been modeled with the mCRL2 1690 formal specification language [mcrl2]. The model 1691 was used mainly for simulating the protocol behavior and for 1693 verifying basic safety and liveness properties as part of the 1694 specification process. For example, we verified the correctness of 1695 the tiebreaking mechanism when two OOB messages are received 1696 simultaneously, one in each direction. We also verified that a man- 1697 in-the-middle attacker cannot cause persistent failure by spoofing a 1698 finite number of messages in the Reconnect Exchange. Additionally, 1699 the protocol has been modeled with the ProVerif [proverif] tool. 1700 This model was used to verify security 1702 properties such as mutual authentication. 1704 6. Security considerations 1706 EAP-NOOB is an authentication and key derivation protocol and, thus, 1707 security considerations can be found in most sections of this 1708 specification. In the following, we explain the protocol design and 1709 highlight some other special considerations. 1711 6.1. Authentication principle 1713 EAP-NOOB establishes a shared secret with an authenticated ECDHE key 1714 exchange. The mutual authentication in EAP-NOOB is based on two 1715 separate features, both conveyed in the OOB message. The first 1716 authentication feature is the secret nonce Noob. The peer and server 1717 use this secret in the Completion Exchange to mutually authenticate 1718 the session key previously created with ECDHE. The message 1719 authentication codes computed with the secret nonce Noob are alone 1720 sufficient for authenticating the key exchange. The second 1721 authentication feature is the integrity-protecting fingerprint Hoob. 1722 Its purpose is to prevent impersonation and man-in-the-middle attacks 1723 even in situations where the attacker is able to eavesdrop the OOB 1724 channel and the nonce Noob is compromised. In some human-assisted 1725 OOB channels, such as sound burst or user-transferred URL, it may be 1726 easier to detect tampering than spying of the OOB message, and such 1727 applications benefit from the second authentication feature. 1729 The additional security provided by the cryptographic fingerprint 1730 Hoob is somewhat intricate to understand. The endpoint that receives 1731 the OOB message uses Hoob to verify the integrity of the ECDHE 1732 exchange. Thus, the OOB receiver can detect impersonation and man- 1733 in-the-middle attacks on the in-band channel. The other endpoint, 1734 however, is not equally protected because the OOB message and 1735 fingerprint are sent only in one direction. Some protection to the 1736 OOB sender is afforded by the fact that the user may notice the 1737 failure of the association at the OOB receiver and therefore reset 1738 the OOB sender. Other device-pairing protocols have solved similar 1739 situations by requiring the user to confirm to the OOB sender that 1740 the association was accepted by the OOB receiver, e.g. by pressing an 1741 "confirm" button on the sender side. Applications MAY implement EAP- 1742 NOOB in this way. Nevertheless, since EAP-NOOB was designed to work 1743 with strictly one-directional OOB communication and the fingerprint 1744 is only the second authentication feature, the EAP-NOOB specification 1745 does not mandate such explicit confirmation to the OOB sender. 1747 To summarize, EAP-NOOB uses the combined protection of the secret 1748 nonce Noob and the cryptographic fingerprint Hoob, both conveyed in 1749 the OOB message. The secret nonce Noob alone is sufficient for 1750 mutual authentication, unless the attacker can eavesdrop it from the 1751 OOB channel. Even if an attacker is able to eavesdrop the secret 1752 nonce Noob, it nevertheless cannot perform a full man-in-the-middle 1753 attack on the in-band channel because the mismatching fingerprint 1754 would alert the OOB receiver, which would reject the OOB message. 1755 The attacker that eavesdropped the secret nonce can impersonate the 1756 OOB receiver to the OOB sender. In this case, the association will 1757 appear to be complete only on the OOB sender side, and such 1758 situations have to be resolved by the user by resetting the OOB 1759 sender to the initial state. 1761 The expected use cases for EAP-NOOB are ones where it replaces a 1762 user-entered access credentials in IoT appliances. In wireless 1763 network access without EAP, the user-entered credential is often a 1764 passphrase that is shared by all the network stations. The advantage 1765 of an EAP-based solution, including EAP-NOOB, is that it establishes 1766 a different master secret for each peer device, which makes the 1767 system more resilient against device compromise than if there were a 1768 common master secret. Additionally, it is possible to revoke the 1769 security association for an individual device on the server side. 1771 Forward secrecy in EAP-NOOB is optional. The Reconnect Exchange in 1772 EAP-NOOB provides forward secrecy only if both the server and peer 1773 send their fresh ECDHE keys. This allows both the server and the 1774 peer to limit the frequency of the costly computation that is 1775 required for forward secrecy. The server MAY adjust the frequency of 1776 its attempts at ECDHE rekeying based on what it knows about the 1777 peer's computational capabilities. 1779 The users delivering the OOB messages will often authenticate 1780 themselves to the EAP server, e.g. by logging into a secure web page. 1781 In this case, the server can reliably associate the peer device with 1782 the user account. Applications that make use of EAP-NOOB can use 1783 this information for configuring the initial owner of the freshly- 1784 registered device. 1786 6.2. Identifying correct endpoints 1788 Potential weaknesses in EAP-NOOB arise from the fact that the user 1789 must identify physically the correct peer device. If the attacker is 1790 able to trick the user into delivering the OOB message to or from the 1791 wrong peer device, the server may create an association with the 1792 wrong peer. This reliance on user in identifying the correct 1793 endpoints is an inherent property of user-assisted out-of-band 1794 authentication. 1796 It is, however, not possible to exploit accidental delivery of the 1797 OOB message to the wrong device when the user makes a mistake. This 1798 is because the wrong peer device would not have prepared for the 1799 attack by performing the Initial Exchange with the server. In 1800 comparison, simpler solutions where the master key is transferred to 1801 the device via the OOB channel are vulnerable to opportunistic 1802 attacks if the user mistakenly delivers the master key to more than 1803 one device. 1805 One mechanism that can mitigate user mistakes is certification of 1806 peer devices. The certificate can convey to the server authentic 1807 identifiers and attributes of the peer device. Compared to a fully 1808 certificate-based authentication, however, EAP-NOOB can be used 1809 without trusted third parties and does not require the user to know 1810 any identifier of the peer device; physical access to the device is 1811 sufficient. 1813 Similarly, the attacker can try to trick the user to deliver the OOB 1814 message to the wrong server, so that the peer device becomes 1815 associated with the wrong server. Since the EAP server is typically 1816 online and accessed through a web user interface, the attack would be 1817 akin to phishing attacks where the user is tricked to accessing the 1818 wrong URL and wrong web page. 1820 6.3. Trusted path issues and misbinding attacks 1822 Another potential threat is spoofed user input or output on the peer 1823 device. When the user is delivering the OOB message to or from the 1824 correct peer device, a trusted path between the user and the peer 1825 device is needed. That is, the user must communicate directly with 1826 an authentic operating system and EAP-NOOB implementation in the peer 1827 device and not with a spoofed user interface. Otherwise, a 1828 Registered device that is under the control of the attacker could 1829 emulate the behavior of an unregistered device. The secure path can 1830 be implemented, for example, by having the user pressing a reset 1831 button to return the device to the Unregistered state and a trusted 1832 UI. The problem with such trusted paths is that they are not 1833 standardized across devices. 1835 Another potential consequence of spoofed UI is the misbinding attack 1836 where the user tries to register the correct but compromised device, 1837 and that device tricks the user into registering another device 1838 instead. For example, a compromised device might have a malicious 1839 full-screen app running, which presents to the user QR codes copied, 1840 in real time, from another device's screen. If the unwitting user 1841 scans the QR code and delivers the OOB message in it to the server, 1842 the wrong device may become registered in the server. Such 1843 misbinding vulnerabilities arise because the user does not have any 1844 secure way of verifying that the in-band cryptographic handshake and 1845 the out-of-band physical access are terminated at the same physical 1846 device. Sethi et al. [Sethi19] analyze the binding threat against 1847 device-pairing protocols and also EAP-NOOB. Essentially, all 1848 protocols where the authentication relies on the user's physical 1849 access to the device are vulnerable to misbinding, including EAP- 1850 NOOB. 1852 A standardized trusted path for communicating directly with the 1853 trusted computing base in a physical device would mitigate the 1854 misbinding threat, but such paths rarely exist in practice. Careful 1855 asset tracking can also prevent most misbinding attacks because the 1856 PeerInfo sent in-band by the wrong device will not match expected 1857 values. Device certification by the manufacturer can further 1858 strengthen the asset tracking. 1860 6.4. Peer identifiers and attributes 1862 The PeerId value in the protocol is a server-allocated identifier for 1863 its association with the peer and SHOULD NOT be shown to the user 1864 because its value is initially ephemeral. Since the PeerId is 1865 allocated by the server and the scope of the identifier is the single 1866 server, the so-called identifier squatting attacks, where a malicious 1867 peer could reserve another peer's identifier, are not possible in 1868 EAP-NOOB. The server SHOULD assign a random or pseudo-random PeerId 1869 to each new peer. It SHOULD NOT select the PeerId based on any peer 1870 characteristics that it may know, such as the peer's link-layer 1871 network address. 1873 User reset or failure in the OOB Step can cause the peer to perform 1874 many Initial Exchanges with the server and to allocate many PeerIds 1875 and to store the ephemeral protocol state for them. The peer will 1876 typically only remember the latest one. EAP-NOOB leaves it to the 1877 implementation to decide when to delete these ephemeral associations. 1878 There is no security reason to delete them early, and the server does 1879 not have any way to verify that the peers are actually the same one. 1880 Thus, it is safest to store the ephemeral states for at least one 1881 day. If the OOB messages are sent only in the server-to-peer 1882 direction, the server SHOULD NOT delete the ephemeral state before 1883 all the related Noob values have expired. 1885 After completion of EAP-NOOB, the server may store the PeerInfo data, 1886 and the user may use it to identify the peer and its properties, such 1887 as the make and model or serial number. A compromised peer could lie 1888 in the PeerInfo that it sends to the server. If the server stores 1889 any information about the peer, it is important that this information 1890 is approved by the user during or after the OOB Step. Without 1891 verification by the user or authentication with vendor certificates 1892 on the application level, the PeerInfo is not authenticated 1893 information and should not be relied on. 1895 One possible use for the PeerInfo field is EAP channel binding 1896 ([RFC3748] Section 7.15). That is, the PeerInfo may include data 1897 items that bind the EAP-NOOB association and exported keys to 1898 properties of the authenticator or the access link, such as the SSID 1899 and BSSID of the wireless network (see Appendix C). 1901 6.5. Identity protection 1903 The PeerInfo field contains identifiers and other information about 1904 the peer device (see Appendix C), and the peer sends this information 1905 in plaintext to the EAP server before the server authentication in 1906 EAP-NOOB has been completed. While the information refers to the 1907 peer device and not directly to the user, it may be better for user 1908 privacy to avoid sending unnecessary information. In the Reconnect 1909 Exchange, the optional PeerInfo SHOULD be omitted unless some 1910 critical data has changed. 1912 Peer devices that randomize their layer-2 address to prevent tracking 1913 can do this whenever the user resets the EAP-NOOB association. 1914 During the lifetime of the association, the PeerId is a unique 1915 identifier that can be used to track the peer in the access network. 1916 Later versions of this specification may consider updating the PeerId 1917 at each Reconnect Exchange. In that case, it is necessary to 1918 consider how the authenticator and access-network administrators can 1919 recognize and blacklist misbehaving peer devices and how to avoid 1920 loss of synchronization between the server and the peer if messages 1921 are lost during the identifier update. 1923 6.6. Downgrading threats 1925 The fingerprint Hoob protects all the information exchanged in the 1926 Initial Exchange, including the cryptosuite negotiation. The message 1927 authentication codes MACs and MACp also protect the same information. 1928 The message authentication codes MACs2 and MACp2 protect information 1929 exchanged during key renegotiation in the Reconnect Exchange. This 1930 prevents downgrading attacks to weaker cryptosuites as long as the 1931 possible attacks take more time than the maximum time allowed for the 1932 EAP-NOOB completion. This is typically the case for recently 1933 discovered cryptanalytic attacks. 1935 As an additional precaution, the EAP server and peer SHOULD check for 1936 downgrading attacks in the Reconnect Exchange. As long as the server 1937 or peer saves any information about the other endpoint, it MUST also 1938 remember the previously negotiated cryptosuite and MUST NOT accept 1939 renegotiation of any cryptosuite that is known to be weaker than the 1940 previous one, such as a deprecated cryptosuite. 1942 Integrity of the direction negotiation cannot be verified in the same 1943 way as the integrity of the cryptosuite negotiation. That is, if the 1944 OOB channel used in an application is critically insecure in one 1945 direction, a man-in-the-middle attacker could modify the negotiation 1946 messages and thereby cause that direction to be used. Applications 1947 that support OOB messages in both directions SHOULD therefore ensure 1948 that the OOB channel has sufficiently strong security in both 1949 directions. While this is a theoretical vulnerability, it could 1950 arise in practice if EAP-NOOB is deployed in unexpected applications. 1951 However, most devices acting as the peer are likely to support only 1952 one direction of exchange, in which case interfering with the 1953 direction negotiation can only prevent the completion of the 1954 protocol. 1956 The long-term shared key material Kz in the persistent EAP-NOOB 1957 association is established with an ECDHE key exchange when the peer 1958 and server are first associated. It is a weaker secret than a 1959 manually configured random shared key because advances in 1960 cryptanalysis against the used ECDHE curve could eventually enable 1961 the attacker to recover Kz. EAP-NOOB protects against such attacks 1962 by allowing cryptosuite upgrades in the Reconnect Exchange and by 1963 updating shared key material Kz whenever the cryptosuite is upgraded. 1964 We do not expect the cryptosuite upgrades to be frequent, but if one 1965 becomes necessary, the upgrade can be made without manual resetting 1966 and reassociation of the peer devices. 1968 6.7. Recovery from loss of last message 1970 The EAP-NOOB Completion Exchange, as well as the Reconnect Exchange 1971 with cryptosuite update, result in a persistent state change that 1972 should take place either on both endpoints or on neither; otherwise, 1973 the result is a state mismatch that requires user action to resolve. 1974 The state mismatch can occur if the final EAP response of the 1975 exchanges is lost. In the Completion Exchange, the loss of the final 1976 response (Type=4) results in the peer moving to Registered (4) state 1977 and creating a persistent EAP-NOOB association while the server stays 1978 in an ephemeral state (1 or 2). In the Reconnect Exchange, the loss 1979 of the final response (Type=7) results in the peer moving to the 1980 Registered (4) state and updating its persistent key material Kz 1981 while the server stays in the Reconnecting (3) state and keeps the 1982 old key material. 1984 The state mismatch is an example of a unavoidable problem in 1985 distributed systems: it is theoretically impossible to guarantee 1986 synchronous state changes in endpoints that communicate 1987 asynchronously. The protocol will always have one critical message 1988 that may get lost, so that one side commits to the state change and 1989 the other side does not. In EAP, the critical message is the final 1990 response from the peer to the server. While the final response is 1991 normally followed by EAP-Success, [RFC3748] section 4.2 states that 1992 the peer MAY assume that the EAP-Success was lost and the 1993 authentication was successful. Furthermore, EAP methods in the peer 1994 do not receive notification of the EAP-Success message from the 1995 parent EAP state machine [RFC4137]. For these reasons, EAP-NOOB on 1996 the peer side commits to a state change already when it sends the 1997 final response. 1999 The best available solution to the loss of the critical message is to 2000 keep trying. EAP retransmission behavior defined in Section 4.3 of 2001 [RFC3748] suggests 3-5 retransmissions. In the absence of an 2002 attacker, this would be sufficient to reduce the probability of 2003 failure to an acceptable level. However, a determined attacker on 2004 the in-band channel can drop the final EAP-Response message and all 2005 subsequent retransmissions. In the Completion Exchange 2006 (KeyingMode=0) and in the Reconnect Exchange with cryptosuite upgrade 2007 (KeyingMode=3), this could result in state mismatch and persistent 2008 denial of service until user resets the peer state. 2010 EAP-NOOB implements its own recovery mechanism that allows unlimited 2011 retries of the Reconnect Exchange. When the DoS attacker eventually 2012 stops dropping packets on the in-band channel, the protocol will 2013 recover. The logic for this recovery mechanism is specified in 2014 Section 3.4.2. 2016 EAP-NOOB does not implement the same kind of retry mechanism in the 2017 Completion Exchange. The reason is that there is always a user 2018 involved in the initial association process, and the user can repeat 2019 the OOB Step to complete the association after the DoS attacker has 2020 left. On the other hand, Reconnect Exchange needs to work without 2021 user involvement. 2023 6.8. EAP security claims 2025 EAP security claims are defined in section 7.2.1 of [RFC3748]. The 2026 security claims for EAP-NOOB are listed in Table 9. 2028 +----------------+--------------------------------------------------+ 2029 | Security | EAP-NOOB claim | 2030 | property | | 2031 +----------------+--------------------------------------------------+ 2032 | Authentication | ECDHE key exchange with out-of-band | 2033 | mechanism | authentication | 2034 | | | 2035 | Protected | yes | 2036 | cryptosuite | | 2037 | negotiation | | 2038 | | | 2039 | Mutual | yes | 2040 | authentication | | 2041 | | | 2042 | Integrity | yes | 2043 | protection | | 2044 | | | 2045 | Replay | yes | 2046 | protection | | 2047 | | | 2048 | Key derivation | yes | 2049 | | | 2050 | Key strength | The specified cryptosuites provide key strength | 2051 | | of at least 128 bits. | 2052 | | | 2053 | Dictionary | yes | 2054 | attack | | 2055 | protection | | 2056 | | | 2057 | Fast reconnect | yes | 2058 | | | 2059 | Cryptographic | not applicable | 2060 | binding | | 2061 | | | 2062 | Session | yes | 2063 | independence | | 2064 | | | 2065 | Fragmentation | no | 2066 | | | 2067 | Channel | yes (The ServerInfo and PeerInfo can be used to | 2068 | binding | convey integrity-protected channel properties | 2069 | | such as network SSID or peer MAC address.) | 2070 +----------------+--------------------------------------------------+ 2072 Table 9: EAP security claims 2074 7. References 2076 7.1. Normative references 2078 [NIST-DH] Barker, E., Chen, L., Roginsky, A., and M. Smid, 2079 "Recommendation for Pair-Wise Key Establishment Schemes 2080 Using Discrete Logarithm Cryptography", NIST Special 2081 Publication 800-56A Revision 2 , May 2013, 2082 . 2085 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 2086 Hashing for Message Authentication", RFC 2104, 2087 DOI 10.17487/RFC2104, February 1997, 2088 . 2090 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2091 Requirement Levels", BCP 14, RFC 2119, 2092 DOI 10.17487/RFC2119, March 1997, 2093 . 2095 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 2096 Levkowetz, Ed., "Extensible Authentication Protocol 2097 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 2098 . 2100 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 2101 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 2102 . 2104 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 2105 Authentication Protocol (EAP) Key Management Framework", 2106 RFC 5247, DOI 10.17487/RFC5247, August 2008, 2107 . 2109 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 2110 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 2111 DOI 10.17487/RFC6234, May 2011, 2112 . 2114 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 2115 RFC 6761, DOI 10.17487/RFC6761, February 2013, 2116 . 2118 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 2119 DOI 10.17487/RFC7517, May 2015, 2120 . 2122 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 2123 DOI 10.17487/RFC7518, May 2015, 2124 . 2126 [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, 2127 DOI 10.17487/RFC7542, May 2015, 2128 . 2130 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 2131 for Security", RFC 7748, DOI 10.17487/RFC7748, January 2132 2016, . 2134 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2135 Writing an IANA Considerations Section in RFCs", BCP 26, 2136 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2137 . 2139 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 2140 Interchange Format", STD 90, RFC 8259, 2141 DOI 10.17487/RFC8259, December 2017, 2142 . 2144 7.2. Informative references 2146 [BluetoothPairing] 2147 Bluetooth, SIG, "Simple pairing whitepaper", Technical 2148 report , 2007. 2150 [EUI-48] Institute of Electrical and Electronics Engineers, 2151 "802-2014 IEEE Standard for Local and Metropolitan Area 2152 Networks: Overview and Architecture.", IEEE Standard 2153 802-2014. , June 2014. 2155 [IEEE-802.1X] 2156 Institute of Electrical and Electronics Engineers, "Local 2157 and Metropolitan Area Networks: Port-Based Network Access 2158 Control", IEEE Standard 802.1X-2004. , December 2004. 2160 [mcrl2] Groote, J. and M. Mousavi, "Modeling and analysis of 2161 communicating systems", The MIT press , 2014, 2162 . 2165 [proverif] 2166 Blanchet, B., Smyth, B., Cheval, V., and M. Sylvestre, 2167 "ProVerif 2.00: Automatic Cryptographic Protocol Verifier, 2168 User Manual and Tutorial", The MIT press , 2018, 2169 . 2172 [RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., 2173 Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and 2174 D. Spence, "AAA Authorization Framework", RFC 2904, 2175 DOI 10.17487/RFC2904, August 2000, 2176 . 2178 [RFC4137] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba, 2179 "State Machines for Extensible Authentication Protocol 2180 (EAP) Peer and Authenticator", RFC 4137, 2181 DOI 10.17487/RFC4137, August 2005, 2182 . 2184 [RFC4266] Hoffman, P., "The gopher URI Scheme", RFC 4266, 2185 DOI 10.17487/RFC4266, November 2005, 2186 . 2188 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 2189 Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, 2190 March 2008, . 2192 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 2193 Code: The Implementation Status Section", BCP 205, 2194 RFC 7942, DOI 10.17487/RFC7942, July 2016, 2195 . 2197 [Sethi14] Sethi, M., Oat, E., Di Francesco, M., and T. Aura, "Secure 2198 Bootstrapping of Cloud-Managed Ubiquitous Displays", 2199 Proceedings of ACM International Joint Conference on 2200 Pervasive and Ubiquitous Computing (UbiComp 2014), pp. 2201 739-750, Seattle, USA , September 2014, 2202 . 2204 [Sethi19] Sethi, M., Peltonen, A., and T. Aura, "Misbinding Attacks 2205 on Secure Device Pairing", 2019, 2206 . 2208 Appendix A. Exchanges and events per state 2210 Figure 10 shows how the EAP server chooses the exchange type 2211 depending on the server and peer states. In the state combinations 2212 marked with hyphen "-", there is no possible exchange and user action 2213 is required to make progress. Note that peer state 4 is omitted from 2214 the table because the peer never connects to the server when the peer 2215 is in that state. The table also shows the handling of errors in 2216 each exchange. A notable detail is that the recipient of error code 2217 2003 moves to state 1. 2219 +--------+---------------------------+------------------------------+ 2220 | peer | exchange chosen by | next peer and | 2221 | states | server | server states | 2222 +========+===========================+==============================+ 2223 | server state: Unregistered (0) | 2224 +--------+---------------------------+------------------------------+ 2225 | 0..2 | Initial Exchange | both 1 (0 on error) | 2226 | 3 | - | no change, notify user | 2227 +--------+---------------------------+------------------------------+ 2228 | server state: Waiting for OOB (1) | 2229 +--------+---------------------------+------------------------------+ 2230 | 0 | Initial Exchange | both 1 (0 on error) | 2231 | 1 | Waiting Exchange | both 1 (no change on error) | 2232 | 2 | Completion Exchange | both 4 (A) | 2233 | 3 | - | no change, notify user | 2234 +--------+---------------------------+------------------------------+ 2235 | server state: OOB Received (2) | 2236 +--------+---------------------------+------------------------------+ 2237 | 0 | Initial Exchange | both 1 (0 on error) | 2238 | 1 | Completion Exchange | both 4 (B) | 2239 | 2 | Completion Exchange | both 4 (A) | 2240 | 3 | - | no change, notify user | 2241 +--------+---------------------------+------------------------------+ 2242 | server state: Reconnecting (3) or Registered (4) | 2243 +--------+---------------------------+------------------------------+ 2244 | 0..2 | - | no change, notify user | 2245 | 3 | Reconnect Exchange | both 4 (3 on error) | 2246 +--------+---------------------------+------------------------------+ 2247 (A) peer to 1 on error 2003, no other changes on error 2248 (B) server to 1 on error 2003, no other changes on error 2250 Figure 10: How server chooses the exchange type 2252 Figure 11 lists the local events that can take place in the server or 2253 peer. Both the server and peer output and accept OOB messages in 2254 association state 1, leading the receiver to state 2. Communication 2255 errors and timeouts in states 0..2 lead back to state 0, while 2256 similar errors in states 3..4 lead to state 3. Application request 2257 for rekeying (e.g. to refresh session keys or to upgrade cryptosuite) 2258 also takes the association from state 3..4 to state 3. User can 2259 always reset the association state to 0. Recovering association 2260 data, e.g. from a backup, leads to state 3. 2262 +--------+---------------------------+------------------------------+ 2263 | server/| possible local events | next state | 2264 | peer | on server and peer | | 2265 | state | | | 2266 +========+===========================+==============================+ 2267 | 1 | OOB Output* | 1 | 2268 | 1 | OOB Input* | 2 (1 on error) | 2269 | 0..2 | Timeout/network failure | 0 | 2270 | 3..4 | Timeout/network failure | 3 | 2271 | 3..4 | Rekeying request | 3 | 2272 | 0..4 | User resets peer state | 0 | 2273 | 0..4 | Association state recovery| 3 | 2274 +--------+---------------------------+------------------------------+ 2276 Figure 11: Local events on server and peer 2278 Appendix B. Application-specific parameters 2280 Table 10 lists OOB channel parameters that need to be specified in 2281 each application that makes use of EAP-NOOB. The list is not 2282 exhaustive and is included for the convenience of implementors only. 2284 +--------------------+----------------------------------------------+ 2285 | Parameter | Description | 2286 +--------------------+----------------------------------------------+ 2287 | OobDirs | Allowed directions of the OOB channel | 2288 | | | 2289 | OobMessageEncoding | How the OOB message data fields are encoded | 2290 | | for the OOB channel | 2291 | | | 2292 | SleepTimeDefault | Default minimum time in seconds that the | 2293 | | peer should sleep before the next Waiting | 2294 | | Exchange | 2295 | | | 2296 | OobRetries | Number of received OOB messages with invalid | 2297 | | Hoob after which the receiver moves to | 2298 | | Unregistered (0) state | 2299 | | | 2300 | NoobTimeout | How many seconds the sender of the OOB | 2301 | | message remembers the sent Noob value. The | 2302 | | RECOMMENDED value is 3600 seconds. | 2303 | | | 2304 | ServerInfoMembers | Required members in ServerInfo | 2305 | | | 2306 | PeerInfoMembers | Required members in PeerInfo | 2307 +--------------------+----------------------------------------------+ 2309 Table 10: OOB channel characteristics 2311 Appendix C. ServerInfo and PeerInfo contents 2313 The ServerInfo and PeerInfo fields in the Initial Exchange and 2314 Reconnect Exchange enable the server and peer, respectively, send 2315 information about themselves to the other endpoint. They contain 2316 JSON objects whose structure may be specified separately for each 2317 application and each type of OOB channel. ServerInfo and PeerInfo 2318 MAY contain auxiliary data needed for the OOB channel messaging and 2319 for EAP channel binding. Table 11 lists some suggested data fields 2320 for ServerInfo. 2322 +----------------+--------------------------------------------------+ 2323 | Data field | Description | 2324 +----------------+--------------------------------------------------+ 2325 | ServerName | String that may be used to aid human | 2326 | | identification of the server. | 2327 | | | 2328 | ServerURL | Prefix string when the OOB message is formatted | 2329 | | as URL, as suggested in Appendix E. | 2330 | | | 2331 | SSIDList | List of wireless network identifier (SSID) | 2332 | | strings used for roaming support, as suggested | 2333 | | in Appendix D. JSON array of UTF-8 encoded SSID | 2334 | | strings. | 2335 | | | 2336 | Base64SSIDList | List of wireless network identifier (SSID) | 2337 | | strings used for roaming support, as suggested | 2338 | | in Appendix D. JSON array of SSIDs, each of | 2339 | | which is base64url encoded without padding. Peer | 2340 | | SHOULD send at most one of the fields SSIDList | 2341 | | and Base64SSIDList in PeerInfo, and the server | 2342 | | SHOULD ignore SSIDList if Base64SSIDList is | 2343 | | included. | 2344 +----------------+--------------------------------------------------+ 2346 Table 11: Suggested ServerInfo data fields 2348 PeerInfo typically contains auxiliary information for identifying and 2349 managing peers on the application level at the server end. Table 12 2350 lists some suggested data fields for PeerInfo. 2352 +--------------+----------------------------------------------------+ 2353 | Data field | Description | 2354 +--------------+----------------------------------------------------+ 2355 | PeerName | String that may be used to aid human | 2356 | | identification of the peer. | 2357 | | | 2358 | Manufacturer | Manufacturer or brand string. | 2359 | | | 2360 | Model | Manufacturer-specified model string. | 2361 | | | 2362 | SerialNumber | Manufacturer-assigned serial number. | 2363 | | | 2364 | MACAddress | Peer link-layer identifier (EUI-48) in the | 2365 | | 12-digit base-16 form [EUI-48]. The string MAY | 2366 | | include additional colon ':' or dash '-' | 2367 | | characters that MUST be ignored by the server. | 2368 | | | 2369 | SSID | Wireless network SSID for channel binding. The | 2370 | | SSID is a UTF-8 string. | 2371 | | | 2372 | Base64SSID | Wireless network SSID for channel binding. The | 2373 | | SSID is base64url encoded. Peer SHOULD send at | 2374 | | most one of the fields SSID and Base64SSID in | 2375 | | PeerInfo, and the server SHOULD ignore SSID if | 2376 | | Base64SSID is included. | 2377 | | | 2378 | BSSID | Wireless network BSSID (EUI-48) in the 12-digit | 2379 | | base-16 form [EUI-48]. The string MAY include | 2380 | | additional colon ':' or dash '-' characters that | 2381 | | MUST be ignored by the server. | 2382 | | | 2383 +--------------+----------------------------------------------------+ 2385 Table 12: Suggested PeerInfo data fields 2387 Appendix D. EAP-NOOB roaming 2389 AAA architectures [RFC2904] allow for roaming of network-connected 2390 appliances that are authenticated over EAP. While the peer is 2391 roaming in a visited network, authentication still takes place 2392 between the peer and an authentication server at its home network. 2393 EAP-NOOB supports such roaming by assigning a Realm to the peer. 2394 After the Realm has been assigned, the peer's NAI enables the visited 2395 network to route the EAP session to the peer's home AAA server. 2397 A peer device that is new or has gone through a hard reset should be 2398 connected first to the home network and establish an EAP-NOOB 2399 association with its home AAA server before it is able to roam. 2401 After that, it can perform the Reconnect Exchange from the visited 2402 network. 2404 Alternatively, the device may provide some method for the user to 2405 configure the Realm of the home network. In that case, the EAP-NOOB 2406 association can be created while roaming. The device will use the 2407 user-assigned Realm in the Initial Exchange, which enables the EAP 2408 messages to be routed correctly to the home AAA server. 2410 While roaming, the device needs to identify the networks where the 2411 EAP-NOOB association can be used to gain network access. For 802.11 2412 access networks, the server MAY send a list of SSID strings in the 2413 ServerInfo JSON object in a member called either SSIDList or 2414 Base64SSIDList. The list is formated as explained in Table 11. If 2415 present, the peer MAY use this list as a hint to determine the 2416 networks where the EAP-NOOB association can be used for access 2417 authorization, in addition to the access network where the Initial 2418 Exchange took place. 2420 Appendix E. OOB message as URL 2422 While EAP-NOOB does not mandate any particular OOB communication 2423 channel, typical OOB channels include graphical displays and emulated 2424 NFC tags. In the peer-to-server direction, it may be convenient to 2425 encode the OOB message as a URL, which is then encoded as a QR code 2426 for displays and printers or as an NDEF record for NFC tags. A user 2427 can then simply scan the QR code or NFC tag and open the URL, which 2428 causes the OOB message to be delivered to the authentication server. 2429 The URL MUST specify the https protocol i.e. secure connection to the 2430 server, so that the man-in-the-middle attacker cannot read or modify 2431 the OOB message. 2433 The ServerInfo in this case includes a JSON member called ServerUrl 2434 of the following format with maximum length of 60 characters: 2436 https://[:]/[] 2438 To this, the peer appends the OOB message fields (PeerId, Noob, Hoob) 2439 as a query string. PeerId is provided to the peer by the server and 2440 might be a 22-character string. The peer base64url encodes, without 2441 padding, the 16-byte values Noob and Hoob into 22-character strings. 2442 The query parameters MAY be in any order. The resulting URL is of 2443 the following format: 2445 https://[:]/[]?P=&N=&H= 2447 The following is an example of a well-formed URL encoding the OOB 2448 message (without line breaks): 2450 https://example.com/Noob?P=ZrD7qkczNoHGbGcN2bN0&N=rMinS0-F4EfCU8D9ljx 2451 X_A&H=QvnMp4UGxuQVFaXPW_14UW 2453 Appendix F. Example messages 2455 The message examples in this section are generated with Curve25519 2456 ECDHE test vectors specified in section 6.1 of [RFC7748] 2457 (server=Alice, peer=Bob). The direction of the OOB channel 2458 negotiated is 1 (peer-to-server). The JSON messages are as follows 2459 (line breaks are for readability only). 2461 ====== Initial Exchange ====== 2463 Identity response: 2464 noob@eap-noob.net 2466 EAP request (type 1): 2467 {"Type":1,"Vers":[1],"PeerId":"07KRU6OgqX0HIeRFldnbSW","Realm":"no 2468 ob.example.com","Cryptosuites":[1],"Dirs":3,"ServerInfo":{"Name":" 2469 Example","Url":"https://noob.example.com/sendOOB"}} 2471 EAP response (type 1): 2472 {"Type":1,"Verp":1,"PeerId":"07KRU6OgqX0HIeRFldnbSW","Cryptosuitep 2473 ":1,"Dirp":1,"PeerInfo":{"Make":"Acme","Type":"None","Serial":"DU- 2474 9999","SSID":"Noob1","BSSID":"6c:19:8f:83:c2:80"}} 2476 EAP request (type 2): 2477 {"Type":2,"PeerId":"07KRU6OgqX0HIeRFldnbSW","PKs":{"kty":"EC","crv 2478 ":"Curve25519","x":"hSDwCYkwp1R0i33ctD73Wg2_Og0mOBr066SpjqqbTmo"}, 2479 "Ns":"PYO7NVd9Af3BxEri1MI6hL8Ck49YxwCjSRPqlC1SPbw","SleepTime":60} 2481 EAP response (type 2): 2482 {"Type":2,"PeerId":"07KRU6OgqX0HIeRFldnbSW","PKp":{"kty":"EC","crv 2483 ":"Curve25519","x":"3p7bfXt9wbTTW2HC7OQ1Nz-DQ8hbeGdNrfx-FG- 2484 IK08"},"Np":"HIvB6g0n2btpxEcU7YXnWB-451ED6L6veQQd6ugiPFU"} 2486 ====== Waiting Exchange ====== 2488 Identity response: 2489 07KRU6OgqX0HIeRFldnbSW+s1@noob.example.com 2491 EAP request (type 3): 2492 {"Type":3,"PeerId":"07KRU6OgqX0HIeRFldnbSW","SleepTime":60} 2494 EAP response (type 3): 2495 {"Type":3,"PeerId":"07KRU6OgqX0HIeRFldnbSW"} 2497 ====== OOB Step ====== 2498 Identity response: 2499 P=07KRU6OgqX0HIeRFldnbSW&N=x3JlolaPciK4Wa6XlMJxtQ&H=faqWz68trUrBTK 2500 AnioZMQA 2502 ====== Completion Exchange ====== 2504 Identity response: 2505 07KRU6OgqX0HIeRFldnbSW+s2@noob.example.com 2507 EAP request (type 8): 2508 {"Type":8,"PeerId":"07KRU6OgqX0HIeRFldnbSW"} 2510 EAP response (type 8): 2511 {"Type":8,"PeerId":"07KRU6OgqX0HIeRFldnbSW","NoobId":"U0OHwYGCS4nE 2512 kzk2TPIE6g"} 2514 EAP request (type 4): 2515 {"Type":4,"PeerId":"07KRU6OgqX0HIeRFldnbSW","NoobId":"U0OHwYGCS4nE 2516 kzk2TPIE6g","MACs":"Y5NfKQkZTbRW3sEFhWy0Bv0ic2wsMnaA6xGqtUmQqmc"} 2518 EAP response (type 4): 2519 {"Type":4,"PeerId":"07KRU6OgqX0HIeRFldnbSW","MACp":"ddY225rN3lYzo7 2520 qZNPStbVO1HRdNnTx0Rit6_8xEh7A"} 2522 ====== Reconnect Exchange ====== 2524 Identity response: 2525 07KRU6OgqX0HIeRFldnbSW+s3@noob.example.com 2527 EAP request (type 5): 2528 {"Type":5,"Vers":[1],"PeerId":"07KRU6OgqX0HIeRFldnbSW","Cryptosuit 2529 es":[1],"Realm":"noob.example.com","ServerInfo":{"Name":"Example", 2530 "Url":"https://noob.example.com/sendOOB"}} 2532 EAP response (type 5): 2533 {"Type":5,"Verp":1,"PeerId":"07KRU6OgqX0HIeRFldnbSW","Cryptosuitep 2534 ":1,"PeerInfo":{"Make":"Acme","Type":"None","Serial":"DU- 2535 9999","SSID":"Noob1","BSSID":"6c:19:8f:83:c2:80"}} 2537 EAP request (type 6): 2538 {"Type":6,"PeerId":"07KRU6OgqX0HIeRFldnbSW","PKs2":{"kty":"EC","cr 2539 v":"Curve25519","x":"hSDwCYkwp1R0i33ctD73Wg2_Og0mOBr066SpjqqbTmo"} 2540 ,"Ns2":"RDLahHBlIgnmL_F_xcynrHurLPkCsrp3G3B_S82WUF4"} 2542 EAP response (type 6): 2543 {"Type":6,"PeerId":"07KRU6OgqX0HIeRFldnbSW","PKp2":{"kty":"EC","cr 2544 v":"Curve25519","x":"3p7bfXt9wbTTW2HC7OQ1Nz-DQ8hbeGdNrfx-FG- 2545 IK08"},"Np2":"jN0_V4P0JoTqwI9VHHQKd9ozUh7tQdc9ABd-j6oTy_4"} 2547 EAP request (type 7): 2548 {"Type":7,"PeerId":"07KRU6OgqX0HIeRFldnbSW","MACs2":"_pXDF4- 2549 7uBKXKqVKKB6U-GP9EDnGCNOMdkyfEQp_iwA"} 2551 EAP response (type 7): 2552 {"Type":7,"PeerId":"07KRU6OgqX0HIeRFldnbSW","MACp2":"qSUH4zA0VzMqU 2553 2O1U-JJTqwGRXGB8i3bggasYL6o1uU"} 2555 Appendix G. TODO list 2557 o Change the way KzId is generated and document its use in Reconnect 2558 Exchange. 2560 Appendix H. Version history 2562 o Version 01: 2564 * Fixed Reconnection Exchange. 2566 * URL examples. 2568 * Message examples. 2570 * Improved state transition (event) tables. 2572 o Version 02: 2574 * Reworked the rekeying and key derivation. 2576 * Increased internal key lengths and in-band nonce and HMAC 2577 lengths to 32 bytes. 2579 * Less data in the persistent EAP-NOOB association. 2581 * Updated reference [NIST-DH] to Revision 2 (2013). 2583 * Shorter suggested PeerId format. 2585 * Optimized the example of encoding OOB message as URL. 2587 * NoobId in Completion Exchange to differentiate between multiple 2588 valid Noob values. 2590 * List of application-specific parameters in appendix. 2592 * Clarified the equivalence of Unregistered state and no state. 2594 * Peer SHOULD probe the server regardless of the OOB channel 2595 direction. 2597 * Added new error messages. 2599 * Realm is part of the persistent association and can be updated. 2601 * Clarified error handling. 2603 * Updated message examples. 2605 * Explained roaming in appendix. 2607 * More accurate definition of timeout for the Noob nonce. 2609 * Additions to security considerations. 2611 o Version 03: 2613 * Clarified reasons for going to Reconnecting state. 2615 * Included Verp in persistent state. 2617 * Added appendix on suggested ServerInfo and PeerInfo fields. 2619 * Exporting PeerId and SessionId. 2621 * Explicitly specified next state after OOB Step. 2623 * Clarified the processing of an expired OOB message and 2624 unrecognized NoobId. 2626 * Enabled protocol version upgrade in Reconnect Exchange. 2628 * Explained handling of redundant received OOB messages. 2630 * Clarified where raw and base64url encoded values are used. 2632 * Cryptosuite must specify the detailed format of the JWK object. 2634 * Base64url encoding in JSON strings is done without padding. 2636 * Simplified explanation of PeerId, Realm and NAI. 2638 * Added error codes for private and experimental use. 2640 * Updated the security considerations. 2642 o Version 04: 2644 * Recovery from synchronization failure due to lost last 2645 response. 2647 o Version 05: 2649 * Kz identifier added to help recovery from lost last messages. 2651 * Error message codes changed for better structure. 2653 * Improved security considerations section. 2655 Appendix I. Acknowledgments 2657 Aleksi Peltonen modeled the protocol specification with the mCRL2 2658 formal specification language. Shiva Prasad TP and Raghavendra MS 2659 implemented parts of the protocol with wpa_supplicant and hostapd. 2660 Their inputs helped us in improving the specification. 2662 The authors would also like to thank Rhys Smith and Josh Howlett for 2663 providing valuable feedback as well as new use cases and requirements 2664 for the protocol. Thanks to Eric Rescorla, Darshak Thakore, Stefan 2665 Winter and Hannes Tschofenig for interesting discussions in this 2666 problem space. 2668 Authors' Addresses 2670 Tuomas Aura 2671 Aalto University 2672 Aalto 00076 2673 Finland 2675 EMail: tuomas.aura@aalto.fi 2677 Mohit Sethi 2678 Ericsson 2679 Jorvas 02420 2680 Finland 2682 EMail: mohit@piuha.net