idnits 2.17.1 draft-ietf-emu-eap-noob-06.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (September 3, 2021) is 959 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'NewNAI' is mentioned on line 1219, but not defined == Missing Reference: 'ServerInfo' is mentioned on line 1219, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'EUI-48' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS186-4' -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST-DH' ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Downref: Normative reference to an Informational RFC: RFC 6234 ** Downref: Normative reference to an Informational RFC: RFC 7748 == Outdated reference: A later version (-25) exists of draft-ietf-rats-eat-10 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 4 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: March 7, 2022 Ericsson 6 A. Peltonen 7 Aalto University 8 September 3, 2021 10 Nimble out-of-band authentication for EAP (EAP-NOOB) 11 draft-ietf-emu-eap-noob-06 13 Abstract 15 The Extensible Authentication Protocol (EAP) provides support for 16 multiple authentication methods. This document defines the EAP-NOOB 17 authentication method for nimble out-of-band (OOB) authentication, 18 and key derivation. The EAP method is intended for bootstrapping all 19 kinds of Internet-of-Things (IoT) devices that have no pre-configured 20 authentication credentials. The method makes use of a user-assisted 21 one-directional OOB message between the peer device and 22 authentication server to authenticate the in-band key exchange. The 23 device must have a non-network input or output interface, such as a 24 display, microphone, speaker, or blinking light, which can send or 25 receive dynamically generated messages of tens of bytes in length. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on March 7, 2022. 44 Copyright Notice 46 Copyright (c) 2021 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. EAP-NOOB protocol . . . . . . . . . . . . . . . . . . . . . . 5 64 3.1. Protocol overview . . . . . . . . . . . . . . . . . . . . 5 65 3.2. Protocol messages and sequences . . . . . . . . . . . . . 8 66 3.2.1. Common handshake in all EAP-NOOB exchanges . . . . . 8 67 3.2.2. Initial Exchange . . . . . . . . . . . . . . . . . . 10 68 3.2.3. OOB Step . . . . . . . . . . . . . . . . . . . . . . 11 69 3.2.4. Completion Exchange . . . . . . . . . . . . . . . . . 13 70 3.2.5. Waiting Exchange . . . . . . . . . . . . . . . . . . 15 71 3.3. Protocol data fields . . . . . . . . . . . . . . . . . . 16 72 3.3.1. Peer identifier and NAI . . . . . . . . . . . . . . . 16 73 3.3.2. Message data fields . . . . . . . . . . . . . . . . . 18 74 3.4. Fast reconnect and rekeying . . . . . . . . . . . . . . . 23 75 3.4.1. Persistent EAP-NOOB association . . . . . . . . . . . 24 76 3.4.2. Reconnect Exchange . . . . . . . . . . . . . . . . . 24 77 3.4.3. User reset . . . . . . . . . . . . . . . . . . . . . 27 78 3.5. Key derivation . . . . . . . . . . . . . . . . . . . . . 28 79 3.6. Error handling . . . . . . . . . . . . . . . . . . . . . 31 80 3.6.1. Invalid messages . . . . . . . . . . . . . . . . . . 33 81 3.6.2. Unwanted peer . . . . . . . . . . . . . . . . . . . . 33 82 3.6.3. State mismatch . . . . . . . . . . . . . . . . . . . 33 83 3.6.4. Negotiation failure . . . . . . . . . . . . . . . . . 33 84 3.6.5. Cryptographic verification failure . . . . . . . . . 34 85 3.6.6. Application-specific failure . . . . . . . . . . . . 34 86 4. ServerInfo and PeerInfo contents . . . . . . . . . . . . . . 35 87 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 88 5.1. Cryptosuites . . . . . . . . . . . . . . . . . . . . . . 37 89 5.2. Message Types . . . . . . . . . . . . . . . . . . . . . . 38 90 5.3. Error codes . . . . . . . . . . . . . . . . . . . . . . . 39 91 5.4. ServerInfo data fields . . . . . . . . . . . . . . . . . 39 92 5.5. PeerInfo data fields . . . . . . . . . . . . . . . . . . 40 93 5.6. Domain name reservation . . . . . . . . . . . . . . . . . 41 94 5.7. Guidance for Designated Experts . . . . . . . . . . . . . 41 95 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 42 96 6.1. Implementation with wpa_supplicant and hostapd . . . . . 42 97 6.2. Implementation on Contiki . . . . . . . . . . . . . . . . 43 98 6.3. Implementation with wpa_supplicant and hostapd . . . . . 43 99 6.4. Protocol modeling . . . . . . . . . . . . . . . . . . . . 43 100 7. Security considerations . . . . . . . . . . . . . . . . . . . 44 101 7.1. Authentication principle . . . . . . . . . . . . . . . . 44 102 7.2. Identifying correct endpoints . . . . . . . . . . . . . . 46 103 7.3. Trusted path issues and misbinding attacks . . . . . . . 47 104 7.4. Peer identifiers and attributes . . . . . . . . . . . . . 48 105 7.5. Downgrading threats . . . . . . . . . . . . . . . . . . . 49 106 7.6. Protected success and failure indications . . . . . . . . 50 107 7.7. Channel Binding . . . . . . . . . . . . . . . . . . . . . 50 108 7.8. Denial of Service . . . . . . . . . . . . . . . . . . . . 51 109 7.9. Recovery from loss of last message . . . . . . . . . . . 52 110 7.10. Privacy considerations . . . . . . . . . . . . . . . . . 53 111 7.11. EAP security claims . . . . . . . . . . . . . . . . . . . 54 112 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 56 113 8.1. Normative references . . . . . . . . . . . . . . . . . . 56 114 8.2. Informative references . . . . . . . . . . . . . . . . . 57 115 Appendix A. Exchanges and events per state . . . . . . . . . . . 60 116 Appendix B. Application-specific parameters . . . . . . . . . . 61 117 Appendix C. EAP-NOOB roaming . . . . . . . . . . . . . . . . . . 62 118 Appendix D. OOB message as URL . . . . . . . . . . . . . . . . . 63 119 Appendix E. Version history . . . . . . . . . . . . . . . . . . 64 120 Appendix F. Acknowledgments . . . . . . . . . . . . . . . . . . 67 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 68 123 1. Introduction 125 This document describes a method for registration, authentication and 126 key derivation for network-connected smart devices, such as consumer 127 and enterprise appliances that are part of the Internet of Things 128 (IoT). These devices may be off-the-shelf hardware that is sold and 129 distributed without any prior registration or credential-provisioning 130 process, or they may be recycled devices after a hard reset. Thus, 131 the device registration in a server database, ownership of the 132 device, and the authentication credentials for both network access 133 and application-level security must all be established at the time of 134 the device deployment. Furthermore, many such devices have only 135 limited user interfaces that could be used for their configuration. 136 Often, the user interfaces are limited to either only input (e.g., 137 camera) or output (e.g., display screen). The device configuration 138 is made more challenging by the fact that the devices may exist in 139 large numbers and may have to be deployed or re-configured nimbly 140 based on user needs. 142 To summarize, devices may have the following characteristics: 144 o no pre-established relation with the intended server or user, 145 o no pre-provisioned device identifier or authentication 146 credentials, 148 o input or output interface that may be capable of only one- 149 directional out-of-band communication. 151 Many proprietary out-of-band (OOB) configuration methods exist for 152 specific IoT devices. The goal of this specification is to provide 153 an open standard and a generic protocol for bootstrapping the 154 security of network-connected appliances, such as displays, printers, 155 speakers, and cameras. The security bootstrapping in this 156 specification makes use of a user-assisted OOB channel. The device 157 authentication relies on a user having physical access to the device, 158 and the key exchange security is based on the assumption that 159 attackers are not able to observe or modify the messages conveyed 160 through the OOB channel. We follow the common approach taken in 161 pairing protocols: performing a Diffie-Hellman key exchange over the 162 insecure network and authenticating the established key with the help 163 of the OOB channel in order to prevent impersonation attacks. 165 The solution presented here is intended for devices that have either 166 a non-network input or output interface, such as a camera, 167 microphone, display screen, speakers or blinking LED light, which is 168 able to send or receive dynamically generated messages of tens of 169 bytes in length. Naturally, this solution may not be appropriate for 170 very small sensors or actuators that have no user interface at all or 171 for devices that are inaccessible to the user. We also assume that 172 the OOB channel is at least partly automated (e.g., camera scanning a 173 bar code) and, thus, there is no need to absolutely minimize the 174 length of the data transferred through the OOB channel. This 175 differs, for example, from Bluetooth pairing [BluetoothPairing], 176 where it is essential to minimize the length of the manually 177 transferred or compared codes. The OOB messages in this 178 specification are dynamically generated. We thus do not support 179 static printed registration codes. One reason for requiring dynamic 180 OOB messages is that the receipt of the OOB message authorizes the 181 server to take ownership of the device. Dynamic OOB messages are 182 more secure than static printed codes, which could be leaked and 183 later misused. 185 2. Terminology 187 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 188 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 189 document are to be interpreted as described in BCP 14 [RFC2119] 190 [RFC8174] when, and only when, they appear in all capitals, as shown 191 here. 193 In addition, this document frequently uses the following terms as 194 they have been defined in [RFC5216]: 196 authenticator The entity initiating EAP authentication. 198 peer The entity that responds to the authenticator. In 199 [IEEE-802.1X], this entity is known as the supplicant. (We use 200 the terms peer, device, and peer device interchangeably.) 202 server The entity that terminates the EAP authentication method with 203 the peer. In the case where no backend authentication server 204 is used, the EAP server is part of the authenticator. In the 205 case where the authenticator operates in pass-through mode, the 206 EAP server is located on the backend authentication server. 208 3. EAP-NOOB protocol 210 This section defines the EAP-NOOB protocol. The protocol is a 211 generalized version of the original idea presented by Sethi et al. 212 [Sethi14]. 214 3.1. Protocol overview 216 One EAP-NOOB protocol execution spans two or more EAP conversations, 217 called Exchanges in this specification. Each Exchange consists of 218 several EAP request-response pairs. At least two separate EAP 219 conversations are needed to give the human user time to deliver the 220 OOB message between them. 222 The overall protocol starts with the Initial Exchange, which 223 comprises four EAP request-response pairs. In the Initial Exchange, 224 the server allocates an identifier to the peer, and the server and 225 peer negotiate the protocol version and cryptosuite (i.e., 226 cryptographic algorithm suite), exchange nonces and perform an 227 Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key exchange. The 228 user-assisted OOB Step then takes place. This step requires only one 229 out-of-band message either from the peer to the server or from the 230 server to the peer. While waiting for the OOB Step action, the peer 231 MAY probe the server by reconnecting to it with EAP-NOOB. If the OOB 232 Step has already taken place, the probe leads to the Completion 233 Exchange, which completes the mutual authentication and key 234 confirmation. On the other hand, if the OOB Step has not yet taken 235 place, the probe leads to the Waiting Exchange, and the peer will 236 perform another probe after a server-defined minimum waiting time. 237 The Initial Exchange and Waiting Exchange always end in EAP-Failure, 238 while the Completion Exchange may result in EAP-Success. Once the 239 peer and server have performed a successful Completion Exchange, both 240 endpoints store the created association in persistent storage, and 241 the OOB Step is not repeated. Thereafter, creation of new temporal 242 keys, ECDHE rekeying, and updates of cryptographic algorithms can be 243 achieved with the Reconnect Exchange. 245 OOB Output/Initial Exchange/ 246 Waiting Exchange 247 .-----. 248 | v 249 .------------------. Initial .------------------. 250 | | Exchange | | 251 .->| Unregistered (0) |---------------->|Waiting for OOB(1)| 252 | | (ephemeral) | | (ephemeral) | 253 | | | | | 254 | '------------------' '------------------' 255 | | | ^ 256 User Reset Completion | | | 257 | Exchange | OOB OOB 258 |<-------. .-------------------------' Input Reject/ 259 | | | | Initial 260 | | | | Exchange 261 | | v v | 262 | .------------------. Completion .------------------. 263 | | | Exchange | | 264 | | Registered (4) |<----------------| OOB Received (2) | 265 | | (persistent) | | (ephemeral) | 266 | | | | | 267 | '------------------' '------------------' 268 | | ^ 269 | Mobility/ | 270 | Timeout/ Reconnect 271 | Failure Exchange 272 | | | 273 | v | 274 | .------------------. 275 | | | 276 '--| Reconnecting (3) | 277 | (persistent) | 278 | | 279 '------------------' 281 Figure 1: EAP-NOOB server-peer association state machine 283 Figure 1 shows the association state machine, which is the same for 284 the server and for the peer. (For readability, only the main state 285 transitions are shown. The complete table of transitions can be 286 found in Appendix A.) When the peer initiates the EAP-NOOB method, 287 the server chooses the ensuing message exchange based on the 288 combination of the server and peer states. The EAP server and peer 289 are initially in the Unregistered state, in which no state 290 information needs to be stored. Before a successful Completion 291 Exchange, the server-peer association state is ephemeral in both the 292 server and peer (ephemeral states 0..2), and a timeout or error may 293 cause one or both endpoints to go back to the Unregistered state so 294 that the Initial Exchange is repeated. After the Completion Exchange 295 has resulted in EAP-Success, the association state becomes persistent 296 (persistent states 3..4). Only user reset or memory failure can 297 cause the return of the server or the peer from the persistent states 298 to the ephemeral states and to the Initial Exchange. 300 The server MUST NOT repeat a successful OOB Step with the same peer 301 except if the association with the peer is explicitly reset by the 302 user or lost due to failure of the persistent storage in the server. 303 More specifically, once the association has entered the Registered 304 state, the server MUST NOT delete the association or go back to the 305 ephemeral states 0..2 without explicit user approval. Similarly, the 306 peer MUST NOT repeat the OOB Step unless the user explicitly deletes 307 from the peer the association with the server or resets the peer to 308 the Unregistered state. The server and peer MAY implement user reset 309 of the association by deleting the state data from that endpoint. If 310 an endpoint continues to store data about the association after the 311 user reset, its behavior MUST be equivalent to having deleted the 312 association data. 314 It can happen that the peer accidentally or through user reset loses 315 its persistent state and reconnects to the server without a 316 previously allocated peer identifier. In that case, the server MUST 317 treat the peer as a new peer. The server MAY use auxiliary 318 information, such as the PeerInfo field received in the Initial 319 Exchange, to detect multiple associations with the same peer. 320 However, it MUST NOT delete or merge redundant associations without 321 user or application approval because EAP-NOOB internally has no 322 secure way of verifying that the two peers are the same physical 323 device. Similarly, the server might lose the association state 324 because of a memory failure or user reset. In that case, the only 325 way to recover is that the user also resets the peer. 327 A special feature of the EAP-NOOB method is that the server is not 328 assumed to have any a-priori knowledge of the peer. Therefore, the 329 peer initially uses the generic identity string "noob@eap-noob.arpa" 330 as its network access identifier (NAI). The server then allocates a 331 server-specific identifier to the peer. The generic NAI serves two 332 purposes: firstly, it tells the server that the peer supports and 333 expects the EAP-NOOB method and, secondly, it allows routing of the 334 EAP-NOOB sessions to a specific authentication server in an 335 Authentication, Authorization and Accounting (AAA) architecture. 337 EAP-NOOB is an unusual EAP method in that the peer has to have 338 multiple EAP conversations with the server before it can receive EAP- 339 Success. The reason is that, while EAP allows delays between the 340 request-response pairs, e.g., for repeated password entry, the user 341 delays in OOB authentication can be much longer than in password 342 trials. Moreover, EAP-NOOB supports peers with no input capability 343 in the user interface (e.g., LED light bulbs). Since users cannot 344 initiate the protocol in these devices, the devices have to perform 345 the Initial Exchange opportunistically and hope for the OOB Step to 346 take place within a timeout period (NoobTimeout), which is why the 347 timeout needs to be several minutes rather than seconds. To support 348 such high-latency OOB channels, the peer and server perform the 349 Initial Exchange in one EAP conversation, then allow time for the OOB 350 message to be delivered, and later perform the Waiting and Completion 351 Exchanges in different EAP conversations. 353 3.2. Protocol messages and sequences 355 This section defines the EAP-NOOB exchanges, which correspond to EAP 356 conversations. The exchanges start with a common handshake, which 357 determines the type of the following exchange. The common handshake 358 messages and the subsequent messages for each exchange type are 359 listed in the diagrams below. The diagrams also specify the data 360 fields present in each message. Each exchange comprises multiple EAP 361 request-response pairs and ends in either EAP-Failure, indicating 362 that authentication is not (yet) successful, or in EAP-Success. 364 3.2.1. Common handshake in all EAP-NOOB exchanges 366 All EAP-NOOB exchanges start with common handshake messages. The 367 handshake begins with the identity request and response that are 368 common to all EAP methods. Their purpose is to enable the AAA 369 architecture to route the EAP conversation to the EAP server and to 370 enable the EAP server to select the EAP method. The handshake then 371 continues with one EAP-NOOB request-response pair in which the server 372 discovers the peer identifier used in EAP-NOOB and the peer state. 374 In more detail, each EAP-NOOB exchange begins with the authenticator 375 sending an EAP-Request/Identity packet to the peer. From this point 376 on, the EAP conversation occurs between the server and the peer, and 377 the authenticator acts as a pass-through device. The peer responds 378 to the authenticator with an EAP-Response/Identity packet, which 379 contains the network access identifier (NAI). The authenticator, 380 acting as a pass-through device, forwards this response and the 381 following EAP conversation between the peer and the AAA architecture. 383 The AAA architecture routes the conversation to a specific AAA server 384 (called "EAP server" or simply "server" in this specification) based 385 on the realm part of the NAI. The server selects the EAP-NOOB method 386 based on the user part of the NAI, as defined in Section 3.3.1. 388 After receiving the EAP-Response/Identity message, the server sends 389 the first EAP-NOOB request (Type=1) to the peer, which responds with 390 the peer identifier (PeerId) and state (PeerState) in the range 0..3. 391 However, the peer SHOULD omit the PeerId from the response (Type=1) 392 when PeerState=0. The server then chooses the EAP-NOOB exchange, 393 i.e., the ensuing message sequence, as explained below. The peer 394 recognizes the exchange based on the message type field (Type) of the 395 next EAP-NOOB request received from the server. 397 The server MUST determine the exchange type based on the combination 398 of the peer and server states as follows (also summarized in 399 Figure 11). If either the peer or server is in the Unregistered (0) 400 state and the other is in one of the ephemeral states (0..2), the 401 server chooses the Initial Exchange. If one of the peer or server is 402 in the OOB Received (2) state and the other is either in the Waiting 403 for OOB (1) or OOB Received (2) state, the OOB Step has taken place 404 and the server chooses the Completion Exchange. If both the server 405 and peer are in the Waiting for OOB (1) state, the server chooses the 406 Waiting Exchange. If the peer is in the Reconnecting (3) state and 407 the server is in the Registered (4) or Reconnecting (3) state, the 408 server chooses the Reconnect Exchange. All other state combinations 409 are error situations where user action is required, and the server 410 SHOULD indicate such errors to the peer with the error code 2002 (see 411 Section 3.6.3). Note also that the peer MUST NOT initiate EAP-NOOB 412 when the peer is in the Registered (4) state. 414 EAP Peer Authenticator EAP Server 415 | | | 416 |<----------- EAP-Request/Identity -| | 417 | | 418 | | 419 |------------ EAP-Response/Identity -------------->| 420 | (NAI=noob@eap-noob.arpa) | 421 | | 422 | | 423 |<----------- EAP-Request/EAP-NOOB ----------------| 424 | (Type=1) | 425 | | 426 | | 427 |------------ EAP-Response/EAP-NOOB -------------->| 428 | (Type=1,[PeerId],PeerState=1) | 429 | | 430 | continuing with exchange-specific messages... | 432 Figure 2: Common handshake in all EAP-NOOB exchanges 434 3.2.2. Initial Exchange 436 The Initial Exchange comprises the common handshake and two further 437 EAP-NOOB request-response pairs, one for version, cryptosuite and 438 parameter negotiation and the other for the ECDHE key exchange. The 439 first EAP-NOOB request (Type=2) from the server contains a newly 440 allocated PeerId for the peer and an optional NewNAI for assigning a 441 new NAI to the peer. The server allocates a new PeerId in the 442 Initial Exchange regardless of any old PeerId received in the 443 previous response (Type=1). The server also sends in the request a 444 list of the protocol versions (Vers) and cryptosuites (Cryptosuites) 445 it supports, an indicator of the OOB channel directions it supports 446 (Dirs), and a ServerInfo object. The peer chooses one of the 447 versions and cryptosuites. The peer sends a response (Type=2) with 448 the selected protocol version (Verp), the received PeerId, the 449 selected cryptosuite (Cryptosuitep), an indicator of the OOB channel 450 direction(s) selected by the peer (Dirp), and a PeerInfo object. In 451 the second EAP-NOOB request and response (Type=3), the server and 452 peer exchange the public components of their ECDHE keys and nonces 453 (PKs,Ns,PKp,Np). The ECDHE keys MUST be based on the negotiated 454 cryptosuite, i.e., Cryptosuitep. The Initial Exchange always ends 455 with EAP-Failure from the server because the authentication cannot 456 yet be completed. 458 EAP Peer EAP Server 459 | ...continuing from common handshake | 460 | | 461 |<----------- EAP-Request/EAP-NOOB ----------------| 462 | (Type=2,Vers,PeerId,[NewNAI], | 463 | Cryptosuites,Dirs,ServerInfo) | 464 | | 465 | | 466 |------------ EAP-Response/EAP-NOOB -------------->| 467 | (Type=2,Verp,PeerId,Cryptosuitep, | 468 | Dirp,PeerInfo) | 469 | | 470 | | 471 |<----------- EAP-Request/EAP-NOOB ----------------| 472 | (Type=3,PeerId,PKs,Ns,[SleepTime]) | 473 | | 474 | | 475 |------------ EAP-Response/EAP-NOOB -------------->| 476 | (Type=3,PeerId,PKp,Np) | 477 | | 478 | | 479 |<----------- EAP-Failure -------------------------| 480 | | 482 Figure 3: Initial Exchange 484 At the conclusion of the Initial Exchange, both the server and the 485 peer move to the Waiting for OOB (1) state. 487 3.2.3. OOB Step 489 The OOB Step, labeled as OOB Output and OOB Input in Figure 1, takes 490 place after the Initial Exchange. Depending on the negotiated OOB 491 channel direction, the peer or the server outputs the OOB message as 492 shown in Figure 4 or Figure 5, respectively. The data fields are the 493 PeerId, the secret nonce Noob, and the cryptographic fingerprint 494 Hoob. The contents of the data fields are defined in Section 3.3.2. 495 The OOB message is delivered to the other endpoint via a user- 496 assisted OOB channel. 498 For brevity, we will use the terms OOB sender and OOB receiver in 499 addition to the already familiar EAP server and EAP peer. If the OOB 500 message is sent in the server-to-peer direction, the OOB sender is 501 the server and the OOB receiver is the peer. On the other hand, if 502 the OOB message is sent in the peer-to-server direction, the OOB 503 sender is the peer and the OOB receiver is the server. 505 EAP Peer EAP Server 506 | | 507 |=================OOB=============================>| 508 | (PeerId,Noob,Hoob) | 509 | | 511 Figure 4: OOB Step, from peer to EAP server 513 EAP Peer EAP Server 514 | | 515 |<================OOB==============================| 516 | (PeerId,Noob,Hoob) | 517 | | 519 Figure 5: OOB Step, from EAP server to peer 521 The OOB receiver MUST compare the received value of the fingerprint 522 Hoob (see Section 3.3.2) with a value that it computed locally for 523 the PeerID received. This integrity check ensures that the endpoints 524 agree on contents of the Initial Exchange. If the values are equal, 525 the receiver moves to the OOB Received (2) state. Otherwise, the 526 receiver MUST reject the OOB message. For usability reasons, the OOB 527 receiver SHOULD indicate the acceptance or rejection of the OOB 528 message to the user. The receiver SHOULD reject invalid OOB messages 529 without changing its state in the association state machine, until an 530 application-specific number of invalid messages (OobRetries) has been 531 reached, after which the receiver SHOULD consider it an error and go 532 back to the Unregistered (0) state. 534 The server or peer MAY send multiple OOB messages with different Noob 535 values while in the Waiting for OOB (1) state. The OOB sender SHOULD 536 remember the Noob values until they expire and accept any one of them 537 in the following Completion Exchange. The Noob values sent by the 538 server expire after an application-dependent timeout (NoobTimeout), 539 and the server MUST NOT accept Noob values older than that in the 540 Completion Exchange. The RECOMMENDED value for NoobTimeout is 3600 541 seconds if there are no application-specific reasons for making it 542 shorter or longer. The Noob values sent by the peer expire as 543 defined in Section 3.2.5. 545 The OOB receiver does not accept further OOB messages after it has 546 accepted one and moved to the OOB Received (2) state. However, the 547 receiver MAY buffer redundant OOB messages in case an OOB message 548 expiry or similar error detected in the Completion Exchange causes it 549 to return to the Waiting for OOB (1) state. It is RECOMMENDED that 550 the OOB receiver notifies the user about redundant OOB messages, but 551 it MAY instead discard them silently. 553 The sender will typically generate a new Noob, and therefore a new 554 OOB message, at constant time intervals (NoobInterval). The 555 RECOMMENDED interval is NoobInterval = NoobTimeout / 2, in which case 556 the receiver of the OOB will at any given time accept either of the 557 two latest Noob values. However, the timing of the Noob generation 558 may also be based on user interaction or on implementation 559 considerations. 561 Even though not recommended (see Section 3.3), this specification 562 allows both directions to be negotiated (Dirp=3) for the OOB channel. 563 In that case, both sides SHOULD output the OOB message, and it is up 564 to the user to deliver at least one of them. 566 The details of the OOB channel implementation including the message 567 encoding are defined by the application. Appendix D gives an example 568 of how the OOB message can be encoded as a URL that may be embedded 569 in a dynamic QR code or NFC tag. 571 3.2.4. Completion Exchange 573 After the Initial Exchange, if the OOB channel directions selected by 574 the peer include the peer-to-server direction, the peer SHOULD 575 initiate the EAP-NOOB method again after an applications-specific 576 waiting time in order to probe for completion of the OOB Step. If 577 the OOB channel directions selected by the peer include the server- 578 to-peer direction and the peer receives the OOB message, it SHOULD 579 initiate the EAP-NOOB method immediately. Depending on the 580 combination of the peer and server states, the server continues with 581 the Completion Exchange or Waiting Exchange (see Section 3.2.1 on how 582 the server makes this decision). 584 The Completion Exchange comprises the common handshake and one or two 585 further EAP-NOOB request-response pairs. If the peer is in the 586 Waiting for OOB (1) state, the OOB message has been sent in the peer- 587 to-server direction. In that case, only one request-response pair 588 (Type=6) takes place. In the request, the server sends the NoobId 589 value (see Section 3.3.2), which the peer uses to identify the exact 590 OOB message received by the server. On the other hand, if the peer 591 is in the OOB Received (2) state, the direction of the OOB message is 592 from server to peer. In this case, two request-response pairs 593 (Type=5 and Type=6) are needed. The purpose of the first request- 594 response pair (Type=5) is that it enables the server to discover 595 NoobId, which identifies the exact OOB message received by the peer. 596 The server returns the same NoobId to the peer in the latter request. 598 In the last request-response pair (Type=6) of the Completion 599 Exchange, the server and peer exchange message authentication codes. 600 Both sides MUST compute the keys Kms and Kmp as defined in 601 Section 3.5 and the message authentication codes MACs and MACp as 602 defined in Section 3.3.2. Both sides MUST compare the received 603 message authentication code with a locally computed value. If the 604 peer finds that it has received the correct value of MACs and the 605 server finds that it has received the correct value of MACp, the 606 Completion Exchange ends in EAP-Success. Otherwise, the endpoint 607 where the comparison fails indicates this with an error message 608 (error code 4001, see Section 3.6.1) and the Completion Exchange ends 609 in EAP-Failure. 611 After successful Completion Exchange, both the server and the peer 612 move to the Registered (4) state. They also derive the output keying 613 material and store the persistent EAP-NOOB association state as 614 defined in Section 3.4 and Section 3.5. 616 It is possible that the OOB message expires before it is received. 617 In that case, the sender of the OOB message no longer recognizes the 618 NoobId that it receives in the Completion Exchange. Another reason 619 why the OOB sender might not recognize the NoobId is if the received 620 OOB message was spoofed and contained an attacker-generated Noob 621 value. The recipient of an unrecognized NoobId indicates this with 622 an error message (error code 2003, see Section 3.6.1), and the 623 Completion Exchange ends in EAP-Failure. The recipient of the error 624 message 2003 moves back to the Waiting for OOB (1) state. This state 625 transition is called OOB Reject in Figure 1 (even though it really is 626 a specific type of failed Completion Exchange). The sender of the 627 error message, on the other hand, stays in its previous state. 629 Although it is not expected to occur in practice, poor user interface 630 design could lead to two OOB messages delivered simultaneously, one 631 from the peer to the server and the other from the server to the 632 peer. The server detects this event in the beginning of the 633 Completion Exchange by observing that both the server and peer are in 634 the OOB Received state (2). In that case, as a tiebreaker, the 635 server MUST behave as if only the server-to-peer message had been 636 delivered. 638 EAP Peer EAP Server 639 | ...continuing from common handshake | 640 | | 641 |<----------- [ EAP-Request/EAP-NOOB ] ------------| 642 | (Type=5,PeerId) | 643 | | 644 | | 645 |------------ [ EAP-Response/EAP-NOOB ] ---------->| 646 | (Type=5,PeerId,NoobId) | 647 | | 648 | | 649 |<----------- EAP-Request/EAP-NOOB ----------------| 650 | (Type=6,PeerId,NoobId,MACs) | 651 | | 652 | | 653 |------------ EAP-Response/EAP-NOOB -------------->| 654 | (Type=6,PeerId,MACp) | 655 | | 656 | | 657 |<----------- EAP-Success -------------------------| 658 | | 660 Figure 6: Completion Exchange 662 3.2.5. Waiting Exchange 664 As explained in Section 3.2.4, the peer SHOULD probe the server for 665 completion of the OOB Step. When the combination of the peer and 666 server states indicates that the OOB message has not yet been 667 delivered, the server chooses the Waiting Exchange (see Section 3.2.1 668 on how the server makes this decision). The Waiting Exchange 669 comprises the common handshake and one further request-response pair, 670 and it always ends in EAP-Failure. 672 In order to limit the rate at which peers probe the server, the 673 server MAY send to the peer either in the Initial Exchange or in the 674 Waiting Exchange a minimum time to wait before probing the server 675 again. A peer that has not received an OOB message SHOULD wait at 676 least the server-specified minimum waiting time in seconds 677 (SleepTime) before initiating EAP again with the same server. The 678 peer uses the latest SleepTime value that it has received in or after 679 the Initial Exchange. If the server has not sent any SleepTime 680 value, the peer MUST wait for an application-specified minimum time 681 (SleepTimeDefault). 683 After the Waiting Exchange, the peer MUST discard (from its local 684 ephemeral storage) Noob values that it has sent to the server in OOB 685 messages that are older than the application-defined timeout 686 NoobTimeout (see Section 3.2.3). The peer SHOULD discard such 687 expired Noob values even if the probing failed, e.g., because of 688 failure to connect to the EAP server or incorrect message 689 authentication code. The timeout of peer-generated Noob values is 690 defined like this in order to allow the peer to probe the server once 691 after it has waited for the server-specified SleepTime. 693 If the server and peer have negotiated to use only the server-to-peer 694 direction for the OOB channel (Dirp=2), the peer SHOULD nevertheless 695 probe the server. The purpose of this is to keep the server informed 696 about the peers that are still waiting for OOB messages. The server 697 MAY set SleepTime to a high number (3600) to prevent the peer from 698 probing the server frequently. 700 EAP Peer EAP Server 701 | ...continuing from common handshake | 702 | | 703 |<----------- EAP-Request/EAP-NOOB ----------------| 704 | (Type=4,PeerId,[SleepTime]) | 705 | | 706 | | 707 |------------ EAP-Response/EAP-NOOB -------------->| 708 | (Type=4,PeerId) | 709 | | 710 | | 711 |<----------- EAP-Failure -------------------------| 712 | | 714 Figure 7: Waiting Exchange 716 3.3. Protocol data fields 718 This section defines the various identifiers and data fields used in 719 the EAP-NOOB protocol. 721 3.3.1. Peer identifier and NAI 723 The server allocates a new peer identifier (PeerId) for the peer in 724 the Initial Exchange. The peer identifier MUST follow the syntax of 725 the utf8-username specified in [RFC7542]. The server MUST generate 726 the identifiers in such a way that they do not repeat and cannot be 727 guessed by the peer or third parties before the server sends them to 728 the peer in the Initial Exchange. One way to generate the 729 identifiers is to choose a random 16-byte identifier and to base64url 730 encode it without padding [RFC4648] into a 22-character ASCII string. 732 Another way to generate the identifiers is to choose a random 733 22-character alphanumeric ASCII string. It is RECOMMENDED to not use 734 identifiers longer than this because they result in longer OOB 735 messages. 737 The peer uses the allocated PeerId to identify itself to the server 738 in the subsequent exchanges. The peer MUST copy the PeerId byte-by- 739 byte from the message where it was allocated, and the server MUST 740 perform a byte-by-byte comparison between the received and the 741 previously allocated PeerID. The peer sets the PeerId value in 742 response type 1 as follows. As stated in Section 3.2.1, when the 743 peer is in the Unregistered (0) state, it SHOULD omit the PeerId from 744 response type 1. When the peer is in one of the states 1..2, it MUST 745 use the PeerId that the server assigned to it in the latest Initial 746 Exchange. When the peer is in one of the persistent states 3..4, it 747 MUST use the PeerId from its persistent EAP-NOOB association. (The 748 PeerId is written to the association when the peer moves to the 749 Registered (4) state after a Completion Exchange.) 751 The default NAI for the peer is "noob@eap-noob.arpa". The peer 752 implementation MAY allow the user or application to configure a 753 different NAI, which overrides the default NAI. Furthermore, the 754 server MAY assign a new NAI to the peer in the Initial Exchange or 755 Reconnect Exchange, in the NewNAI field of request types 2 and 7, to 756 override any previous NAI value. When the peer is in the 757 Unregistered (0) state, or when the peer is in one of the states 1..2 758 and the server did not send a NewNAI in the latest Initial Exchange, 759 the peer MUST use the configured NAI, or if it does not exist, the 760 default NAI. When the peer is in one of the states 1..2 and the 761 server sent a NewNAI in the latest Initial Exchange, the peer MUST 762 use this server-assigned NAI. When the peer moves to the Registered 763 (4) state after the Completion Exchange, it writes to the persistent 764 EAP-NOOB association the same NAI value that it used in the 765 Completion Exchange. When the peer is in the Reconnecting (3) or 766 Registered (4) state, it MUST use the NAI from its persistent EAP- 767 NOOB association. When the server sends NewNAI in the Reconnect 768 Exchange, the peer writes its value to the persistent EAP-NOOB 769 association when it moves from the Reconnecting (3) state to the 770 Registered (4) state. All the NAI values MUST follow the syntax 771 specified in [RFC7542]. 773 The purpose of the server-assigned NAI is to enable more flexible 774 routing of the EAP sessions over the AAA infrastructure, including 775 roaming scenarios (see Appendix C). Moreover, some Authenticators or 776 AAA servers use the realm part of the assigned NAI to determine peer- 777 specific connection parameters, such as isolating the peer to a 778 specific VLAN. The user or application configured NAI, on the other 779 hand, enables registration of new devices while roaming. It also 780 enables manufacturers to set up their own AAA servers for 781 bootstrapping of new peer devices. 783 The peer's PeerId and server-assigned NAI are ephemeral until a 784 successful Completion Exchange takes place. Thereafter, the values 785 become parts of the persistent EAP-NOOB association, until the user 786 resets the peer and the server or until a new NAI is assigned in the 787 Reconnect Exchange. 789 3.3.2. Message data fields 791 Table 1 defines the data fields in the protocol messages. The in- 792 band messages are formatted as JSON objects [RFC8259] in UTF-8 793 encoding. The JSON member names are in the left-hand column of the 794 table. 796 +------------------+------------------------------------------------+ 797 | Data field | Description | 798 +------------------+------------------------------------------------+ 799 | Vers, Verp | EAP-NOOB protocol versions supported by the | 800 | | EAP server, and the protocol version chosen by | 801 | | the peer. Vers is a JSON array of unsigned | 802 | | integers, and Verp is an unsigned integer. | 803 | | Example values are "[1]" and "1", | 804 | | respectively. | 805 | | | 806 | PeerId | Peer identifier as defined in Section 3.3.1. | 807 | | | 808 | NAI, NewNAI | Peer NAI and server-assigned new peer NAI as | 809 | | defined in Section 3.3.1. | 810 | | | 811 | Type | EAP-NOOB message type. The type is an integer | 812 | | in the range 0..9. EAP-NOOB requests and the | 813 | | corresponding responses share the same type | 814 | | value. | 815 | | | 816 | PeerState | Peer state is an integer in the range 0..4 | 817 | | (see Figure 1). However, only values 0..3 are | 818 | | ever sent in the protocol messages. | 819 | | | 820 | PKs, PKp | The public components of the ECDHE keys of the | 821 | | server and peer. PKs and PKp are sent in the | 822 | | JSON Web Key (JWK) format [RFC7517]. The | 823 | | detailed format of the JWK object is defined | 824 | | by the cryptosuite. | 825 | | | 826 | Cryptosuites, | The identifiers of cryptosuites supported by | 827 | Cryptosuitep | the server and of the cryptosuite selected by | 828 | | the peer. The server-supported cryptosuites in | 829 | | Cryptosuites are formatted as a JSON array of | 830 | | the identifier integers. The server MUST send | 831 | | a nonempty array with no repeating elements, | 832 | | ordered by decreasing priority. The peer MUST | 833 | | respond with exactly one suite in the | 834 | | Cryptosuitep value, formatted as an identifier | 835 | | integer. Mandatory to implement cryptosuites | 836 | | and the registration procedure for new | 837 | | cryptosuites is specified in Section 5.1. | 838 | | Example values are "[1]" and "1", | 839 | | respectively. | 840 | | | 841 | Dirs, Dirp | An integer indicating the OOB channel | 842 | | directions supported by the server and the | 843 | | directions selected by the peer. The possible | 844 | | values are 1=peer-to-server, 2=server-to-peer, | 845 | | 3=both directions. | 846 | | | 847 | Dir | The actual direction of the OOB message | 848 | | (1=peer-to-server, 2=server-to-peer). This | 849 | | value is not sent over any communication | 850 | | channel, but it is included in the computation | 851 | | of the cryptographic fingerprint Hoob. | 852 | | | 853 | Ns, Np | 32-byte nonces for the Initial Exchange. | 854 | | | 855 | ServerInfo | This field contains information about the | 856 | | server to be passed from the EAP method to the | 857 | | application layer in the peer. The information | 858 | | is specific to the application or to the OOB | 859 | | channel, and it is encoded as a JSON object of | 860 | | at most 500 bytes. It could include, for | 861 | | example, the access-network name and server | 862 | | name or a Uniform Resource Locator (URL) | 863 | | [RFC3986] or some other information that helps | 864 | | the user to deliver the OOB message to the | 865 | | server through the out-of-band channel. | 866 | | | 867 | PeerInfo | This field contains information about the peer | 868 | | to be passed from the EAP method to the | 869 | | application layer in the server. The | 870 | | information is specific to the application or | 871 | | to the OOB channel, and it is encoded as a | 872 | | JSON object of at most 500 bytes. It could | 873 | | include, for example, the peer brand, model, | 874 | | and serial number, which help the user to | 875 | | distinguish between devices and to deliver the | 876 | | OOB message to the correct peer through the | 877 | | out-of-band channel. | 878 | | | 879 | SleepTime | The number of seconds for which the peer MUST | 880 | | NOT start a new execution of the EAP-NOOB | 881 | | method with the authenticator, unless the peer | 882 | | receives the OOB message or the sending is | 883 | | triggered by an application-specific user | 884 | | action. The server can use this field to limit | 885 | | the rate at which peers probe it. SleepTime is | 886 | | an unsigned integer in the range 0..3600. | 887 | | | 888 | Noob | 16-byte secret nonce sent through the OOB | 889 | | channel and used for the session key | 890 | | derivation. The endpoint that received the OOB | 891 | | message uses this secret in the Completion | 892 | | Exchange to authenticate the exchanged key to | 893 | | the endpoint that sent the OOB message. | 894 | | | 895 | Hoob | 16-byte cryptographic fingerprint (i.e., hash | 896 | | value) computed from all the parameters | 897 | | exchanged in the Initial Exchange and in the | 898 | | OOB message. Receiving this fingerprint over | 899 | | the OOB channel guarantees the integrity of | 900 | | the key exchange and parameter negotiation. | 901 | | Hence, it authenticates the exchanged key to | 902 | | the endpoint that receives the OOB message. | 903 | | | 904 | NoobId | 16-byte identifier for the OOB message, | 905 | | computed with a one-way function from the | 906 | | nonce Noob in the message. | 907 | | | 908 | MACs, MACp | Message authentication codes (HMAC) for mutual | 909 | | authentication, key confirmation, and | 910 | | integrity check on the exchanged information. | 911 | | The input to the HMAC is defined below, and | 912 | | the key for the HMAC is defined in | 913 | | Section 3.5. | 914 | | | 915 | Ns2, Np2 | 32-byte nonces for the Reconnect Exchange. | 916 | | | 917 | KeyingMode | Integer indicating the key derivation method. | 918 | | 0 in the Completion Exchange, and 1..3 in the | 919 | | Reconnect Exchange. | 920 | | | 921 | PKs2, PKp2 | The public components of the ECDHE keys of the | 922 | | server and peer for the Reconnect Exchange. | 923 | | PKp2 and PKs2 are sent in the JSON Web Key | 924 | | (JWK) format [RFC7517]. The detailed format of | 925 | | the JWK object is defined by the cryptosuite. | 926 | | | 927 | MACs2, MACp2 | Message authentication codes (HMAC) for mutual | 928 | | authentication, key confirmation, and | 929 | | integrity check on the Reconnect Exchange. The | 930 | | input to the HMAC is defined below, and the | 931 | | key for the HMAC is defined in Section 3.5. | 932 | | | 933 | ErrorCode | Integer indicating an error condition. Defined | 934 | | in Section 5.3. | 935 | | | 936 | ErrorInfo | Textual error message for logging and | 937 | | debugging purposes. A UTF-8 string of at most | 938 | | 500 bytes. | 939 | | | 940 +------------------+------------------------------------------------+ 942 Table 1: Message data fields 944 It is RECOMMENDED for servers to support both OOB channel directions 945 (Dirs=3) unless the type of the OOB channel limits them to one 946 direction (Dirs=1 or Dirs=2). On the other hand, it is RECOMMENDED 947 that the peer selects only one direction (Dirp=1 or Dirp=2) even when 948 both directions (Dirp=3) would be technically possible. The reason 949 is that, if value 3 is negotiated, the user may be presented with two 950 OOB messages, one for each direction, even though only one of them 951 needs to be delivered. This can be confusing to the user. 952 Nevertheless, the EAP-NOOB protocol is designed to cope also with the 953 value 3, in which case it uses the first delivered OOB message. In 954 the unlikely case of simultaneously delivered OOB messages, the 955 protocol prioritizes the server-to-peer direction. 957 The nonces in the in-band messages (Ns, Np, Ns2, Np2) are 32-byte 958 fresh random byte strings, and the secret nonce Noob is a 16-byte 959 fresh random byte string. All the nonces are generated by the 960 endpoint that sends the message. 962 The fingerprint Hoob and the identifier NoobId are computed with the 963 cryptographic hash function H, which is specified in the negotiated 964 cryptosuite and truncated to the 16 leftmost bytes of the output. 965 The message authentication codes (MACs, MACp, MACs2, MACp2) are 966 computed with the function HMAC, which is the HMAC message 967 authentication code [RFC2104] based on the cryptographic hash 968 function H and truncated to the 32 leftmost bytes of the output. 970 The inputs to the hash function for computing the fingerprint Hoob 971 and to the HMAC for computing MACs, MACp, MACs2 and MACp2 are JSON 972 arrays containing a fixed number (17) of elements. The array 973 elements MUST be copied to the array verbatim from the sent and 974 received in-band messages. When the element is a JSON object, its 975 members MUST NOT be reordered or re-encoded. Whitespace MUST NOT be 976 added anywhere in the JSON structure. Implementers should check that 977 their JSON library copies the elements as UTF-8 strings and does not 978 modify them in any way, and that it does not add whitespace to the 979 HMAC input. 981 The inputs for computing the fingerprint and message authentication 982 codes are the following: 984 Hoob = H(Dir,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,Cryptos 985 uitep,Dirp,NAI,PeerInfo,0,PKs,Ns,PKp,Np,Noob). 987 NoobId = H("NoobId",Noob). 989 MACs = HMAC(Kms; 2,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,C 990 ryptosuitep,Dirp,NAI,PeerInfo,0,PKs,Ns,PKp,Np,Noob). 992 MACp = HMAC(Kmp; 1,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,C 993 ryptosuitep,Dirp,NAI,PeerInfo,0,PKs,Ns,PKp,Np,Noob). 995 MACs2 = HMAC(Kms2; 2,Vers,Verp,PeerId,Cryptosuites,"",[ServerInfo] 996 ,Cryptosuitep,"",NAI,[PeerInfo],KeyingMode,[PKs2],Ns2,[PKp2],Np2," 997 ") 999 MACp2 = HMAC(Kmp2; 1,Vers,Verp,PeerId,Cryptosuites,"",[ServerInfo] 1000 ,Cryptosuitep,"",NAI,[PeerInfo],KeyingMode,[PKs2],Ns2,[PKp2],Np2," 1001 ") 1003 The inputs denoted with "" above are not present, and the values in 1004 brackets [] are optional. Both kinds of missing input values are 1005 represented by empty strings "" in the HMAC input (JSON array). The 1006 NAI included in the inputs is the NAI value that will be in the 1007 persistent EAP-NOOB association if the Completion Exchange or 1008 Reconnect Exchange succeeds. In the Completion Exchange, the NAI is 1009 the NewNAI value assigned by the server in the preceding Initial 1010 Exchange, or if no NewNAI was sent, the NAI used by the client in the 1011 Initial Exchange. In the Reconnect Exchange, the NAI is the NewNAI 1012 value assigned by the server in the same Reconnect Exchange, or if no 1013 NewNAI was sent, the unchanged NAI from the persistent EAP-NOOB 1014 association. Each of the values in brackets for the computation of 1015 Macs2 and Macp2 MUST be included if it was sent or received in the 1016 same Reconnect Exchange; otherwise, the value is replaced by an empty 1017 string "". 1019 The parameter Dir indicates the direction in which the OOB message 1020 containing the Noob value is being sent (1=peer-to-server, 2=server- 1021 to-peer). This field is included in the Hoob input to prevent the 1022 user from accidentally delivering the OOB message back to its 1023 originator in the rare cases where both OOB directions have been 1024 negotiated. The keys (Kms, Kmp, Kms2, Kmp2) for the HMACs are 1025 defined in Section 3.5. 1027 The nonces (Ns, Np, Ns2, Np2, Noob) and the hash value (NoobId) MUST 1028 be base64url encoded [RFC4648] when they are used as input to the 1029 cryptographic functions H or HMAC. These values and the message 1030 authentication codes (MACs, MACp, MACs2, MACp2) MUST also be 1031 base64url encoded when they are sent as JSON strings in the in-band 1032 messages. The values Noob and Hoob in the OOB channel MAY be 1033 base64url encoded if that is appropriate for the application and the 1034 OOB channel. All base64url encoding is done without padding. The 1035 base64url encoded values will naturally consume more space than the 1036 number of bytes specified above (22-character string for a 16-byte 1037 nonce and 43-character string for a 32-byte nonce or message 1038 authentication code). In the key derivation in Section 3.5, on the 1039 other hand, the unencoded nonces (raw bytes) are used as input to the 1040 key derivation function. 1042 The ServerInfo and PeerInfo are JSON objects with UTF-8 encoding. 1043 The length of either encoded object as a byte array MUST NOT exceed 1044 500 bytes. The format and semantics of these objects MUST be defined 1045 by the application that uses the EAP-NOOB method. 1047 3.4. Fast reconnect and rekeying 1049 EAP-NOOB implements Fast Reconnect ([RFC3748], section 7.2.1) that 1050 avoids repeated use of the user-assisted OOB channel. 1052 The rekeying and the Reconnect Exchange may be needed for several 1053 reasons. New EAP output values Main Session Key (MSK) and Extended 1054 Main Session Key (EMSK) may be needed because of mobility or timeout 1055 of session keys. Software or hardware failure or user action may 1056 also cause the authenticator, EAP server or peer to lose its non- 1057 persistent state data. The failure would typically be detected by 1058 the peer or authenticator when session keys are no longer accepted by 1059 the other endpoint. Changes in the supported cryptosuites in the EAP 1060 server or peer may also cause the need for a new key exchange. When 1061 the EAP server or peer detects any one of these events, it MUST 1062 change from the Registered to Reconnecting state. These state 1063 transitions are labeled Mobility/Timeout/Failure in Figure 1. The 1064 EAP-NOOB method will then perform the Reconnect Exchange the next 1065 time when EAP is triggered. 1067 3.4.1. Persistent EAP-NOOB association 1069 To enable rekeying, the EAP server and peer store the session state 1070 in persistent memory after a successful Completion Exchange. This 1071 state data, called "persistent EAP-NOOB association", MUST include at 1072 least the data fields shown in Table 2. They are used for 1073 identifying and authenticating the peer in the Reconnect Exchange. 1074 When a persistent EAP-NOOB association exists, the EAP server and 1075 peer are in the Registered state (4) or Reconnecting state (3), as 1076 shown in Figure 1. 1078 +------------------+----------------------------+-------------------+ 1079 | Data Field | Value | Type | 1080 +------------------+----------------------------+-------------------+ 1081 | PeerId | Peer identifier allocated | UTF-8 string | 1082 | | by server | (typically 22 | 1083 | | | ASCII characters) | 1084 | | | | 1085 | Verp | Negotiated protocol | integer | 1086 | | version | | 1087 | | | | 1088 | Cryptosuitep | Negotiated cryptosuite | integer | 1089 | | | | 1090 | CryptosuitepPrev | Previous cryptosuite | integer | 1091 | (at peer only) | | | 1092 | | | | 1093 | NAI | NAI assigned by server, | UTF-8 string | 1094 | | configured by user, or the | | 1095 | | default NAI "noob@eap- | | 1096 | | noob.arpa" | | 1097 | Kz | Persistent key material | 32 bytes | 1098 | | | | 1099 | KzPrev (at peer | Previous Kz value | 32 bytes | 1100 | only) | | | 1101 +------------------+----------------------------+-------------------+ 1103 Table 2: Persistent EAP-NOOB association 1105 3.4.2. Reconnect Exchange 1107 The server chooses the Reconnect Exchange when both the peer and the 1108 server are in a persistent state and fast reconnection is needed (see 1109 Section 3.2.1 for details). 1111 The Reconnect Exchange comprises the common handshake and three 1112 further EAP-NOOB request-response pairs, one for cryptosuite and 1113 parameter negotiation, another for the nonce and ECDHE key exchange, 1114 and the last one for exchanging message authentication codes. In the 1115 first request and response (Type=7) the server and peer negotiate a 1116 protocol version and cryptosuite in the same way as in the Initial 1117 Exchange. The server SHOULD NOT offer and the peer MUST NOT accept 1118 protocol versions or cryptosuites that it knows to be weaker than the 1119 one currently in the Cryptosuitep field of the persistent EAP-NOOB 1120 association. The server SHOULD NOT needlessly change the 1121 cryptosuites it offers to the same peer because peer devices may have 1122 limited ability to update their persistent storage. However, if the 1123 peer has different values in the Cryptosuitep and CryptosuitepPrev 1124 fields, it SHOULD also accept offers that are not weaker than 1125 CryptosuitepPrev. Note that Cryptosuitep and CryptosuitePrev from 1126 the persistent EAP-NOOB association are only used to support the 1127 negotiation as described above; all actual cryptographic operations 1128 use the newly negotiated cryptosuite. The request and response 1129 (Type=7) MAY additionally contain PeerInfo and ServerInfo objects. 1131 The server then determines the KeyingMode (defined in Section 3.5) 1132 based on changes in the negotiated cryptosuite and whether it desires 1133 to achieve forward secrecy or not. The server SHOULD only select 1134 KeyingMode 3 when the negotiated cryptosuite differs from the 1135 Cryptosuitep in the server's persistent EAP-NOOB association, 1136 although it is technically possible to select this value without 1137 changing the cryptosuite. In the second request and response 1138 (Type=8), the server informs the peer about the KeyingMode, and the 1139 server and peer exchange nonces (Ns2, Np2). When KeyingMode is 2 or 1140 3 (rekeying with ECDHE), they also exchange public components of 1141 ECDHE keys (PKs2, PKp2). The server ECDHE key MUST be fresh, i.e., 1142 not previously used with the same peer, and the peer ECDHE key SHOULD 1143 be fresh, i.e., not previously used. 1145 In the third and final request and response (Type=9), the server and 1146 peer exchange message authentication codes. Both sides MUST compute 1147 the keys Kms2 and Kmp2 as defined in Section 3.5 and the message 1148 authentication codes MACs2 and MACp2 as defined in Section 3.3.2. 1149 Both sides MUST compare the received message authentication code with 1150 a locally computed value. 1152 The rules by which the peer compares the received MACs2 are non- 1153 trivial because, in addition to authenticating the current exchange, 1154 MACs2 may confirm the success or failure of a recent cryptosuite 1155 upgrade. The peer processes the final request (Type=9) as follows: 1157 1. The peer first compares the received MACs2 value with one it 1158 computed using the Kz stored in the persistent EAP-NOOB 1159 association. If the received and computed values match, the peer 1160 deletes any data stored in the CryptosuitepPrev and KzPrev fields 1161 of the persistent EAP-NOOB association. It does this because the 1162 received MACs2 confirms that the peer and server share the same 1163 Cryptosuitep and Kz, and any previous values must no longer be 1164 accepted. 1166 2. If, on the other hand, the peer finds that the received MACs2 1167 value does not match the one it computed locally with Kz, the 1168 peer checks whether the KzPrev field in the persistent EAP-NOOB 1169 association stores a key. If it does, the peer repeats the key 1170 derivation (Section 3.5) and local MACs2 computation 1171 (Section 3.3.2) using KzPrev in place of Kz. If this second 1172 computed MACs2 matches the received value, the match indicates 1173 synchronization failure caused by the loss of the last response 1174 (Type=9) in a previously attempted cryptosuite upgrade. In this 1175 case, the peer rolls back that upgrade by overwriting 1176 Cryptosuitep with CryptosuitepPrev and Kz with KzPrev in the 1177 persistent EAP-NOOB association. It also clears the 1178 CryptosuitepPrev and KzPrev fields. 1180 3. If the received MACs2 matched one of the locally computed values, 1181 the peer proceeds to send the final response (Type=9). The peer 1182 also moves to the Registered (4) state. When KeyingMode is 1 or 1183 2, the peer stops here. When KeyingMode is 3, the peer also 1184 updates the persistent EAP-NOOB association with the negotiated 1185 Cryptosuitep and the newly-derived Kz value. To prepare for 1186 possible synchronization failure caused by the loss of the final 1187 response (Type=9) during cryptosuite upgrade, the peer copies the 1188 old Cryptosuitep and Kz values in the persistent EAP-NOOB 1189 association to the CryptosuitepPrev and KzPrev fields. 1191 4. Finally, if the peer finds that the received MACs2 does not match 1192 either of the two values that it computed locally (or one value 1193 if no KzPrev was stored), the peer sends an error message (error 1194 code 4001, see Section 3.6.1), which causes the Reconnect 1195 Exchange to end in EAP-Failure. 1197 The server rules for processing the final message are simpler than 1198 the peer rules because the server does not store previous keys, and 1199 it never rolls back a cryptosuite upgrade. Upon receiving the final 1200 response (Type=9), the server compares the received value of MACp2 1201 with one it computes locally. If the values match, the Reconnect 1202 Exchange ends in EAP-Success. When KeyingMode is 3, the server also 1203 updates Cryptosuitep and Kz in the persistent EAP-NOOB association. 1204 On the other hand, if the server finds that the values do not match, 1205 it sends an error message (error code 4001), and the Reconnect 1206 Exchange ends in EAP-Failure. 1208 The endpoints MAY send updated NewNAI, ServerInfo and PeerInfo 1209 objects in the Reconnect Exchange. When there is no update to the 1210 values, they SHOULD omit this information from the messages. If the 1211 NewNAI was sent, each side updates NAI in the persistent EAP-NOOB 1212 association when moving to the Registered (4) state. 1214 EAP Peer EAP Server 1215 | ...continuing from common handshake | 1216 | | 1217 |<----------- EAP-Request/EAP-NOOB ----------------| 1218 | (Type=7,Vers,PeerId,Cryptosuites, | 1219 | [NewNAI],[ServerInfo]) | 1220 | | 1221 | | 1222 |------------ EAP-Response/EAP-NOOB -------------->| 1223 | (Type=7,Verp,PeerId,Cryptosuitep,[PeerInfo])| 1224 | | 1225 | | 1226 |<----------- EAP-Request/EAP-NOOB ----------------| 1227 | (Type=8,PeerId,KeyingMode,[PKs2],Ns2) | 1228 | | 1229 | | 1230 |------------ EAP-Response/EAP-NOOB -------------->| 1231 | (Type=8,PeerId,[PKp2],Np2) | 1232 | | 1233 | | 1234 |<----------- EAP-Request/EAP-NOOB ----------------| 1235 | (Type=9,PeerId,MACs2) | 1236 | | 1237 | | 1238 |------------ EAP-Response/EAP-NOOB -------------->| 1239 | (Type=9,PeerId,MACp2) | 1240 | | 1241 | | 1242 |<----------- EAP-Success -------------------------| 1243 | | 1245 Figure 8: Reconnect Exchange 1247 3.4.3. User reset 1249 As shown in the association state machine in Figure 1, the only 1250 specified way for the association to return from the Registered state 1251 (4) to the Unregistered state (0) is through user-initiated reset. 1252 After the reset, a new OOB message will be needed to establish a new 1253 association between the EAP server and peer. Typical situations in 1254 which the user reset is required are when the other side has 1255 accidentally lost the persistent EAP-NOOB association data, or when 1256 the peer device is decommissioned. 1258 The server could detect that the peer is in the Registered or 1259 Reconnecting state but the server itself is in one of the ephemeral 1260 states 0..2 (including situations where the server does not recognize 1261 the PeerId). In this case, effort should be made to recover the 1262 persistent server state, for example, from a backup storage - 1263 especially if many peer devices are similarly affected. If that is 1264 not possible, the EAP server SHOULD log the error or notify an 1265 administrator. The only way to continue from such a situation is by 1266 having the user reset the peer device. 1268 On the other hand, if the peer is in any of the ephemeral states 1269 0..2, including the Unregistered state, the server will treat the 1270 peer as a new peer device and allocate a new PeerId to it. The 1271 PeerInfo can be used by the user as a clue to which physical device 1272 has lost its state. However, there is no secure way of matching the 1273 "new" peer with the old PeerId without repeating the OOB Step. This 1274 situation will be resolved when the user performs the OOB Step and, 1275 thus, identifies the physical peer device. The server user interface 1276 MAY support situations where the "new" peer is actually a previously 1277 registered peer that has been reset by a user or otherwise lost its 1278 persistent data. In those cases, the user could choose to merge the 1279 new peer identity with the old one in the server. The alternative is 1280 to treat the device just like a new peer. 1282 3.5. Key derivation 1284 EAP-NOOB derives the EAP output values MSK and EMSK and other secret 1285 keying material from the output of an Ephemeral Elliptic Curve 1286 Diffie-Hellman (ECDHE) algorithm following the NIST specification 1287 [NIST-DH]. In NIST terminology, we use a C(2e, 0s, ECC CDH) scheme, 1288 i.e., two ephemeral keys and no static keys. In the Initial and 1289 Reconnect Exchanges, the server and peer compute the ECDHE shared 1290 secret Z as defined in section 6.1.2 of the NIST specification 1291 [NIST-DH]. In the Completion and Reconnect Exchanges, the server and 1292 peer compute the secret keying material from Z with the one-step key 1293 derivation function (KDF) defined in section 5.8.2.1 of the NIST 1294 specification. The auxiliary function H is a hash function, and it 1295 is taken from the negotiated cryptosuite. 1297 +------------+------------------------------------------------------+ 1298 | KeyingMode | Description | 1299 +------------+------------------------------------------------------+ 1300 | 0 | Completion Exchange (always with ECDHE) | 1301 | | | 1302 | 1 | Reconnect Exchange, rekeying without ECDHE | 1303 | | | 1304 | 2 | Reconnect Exchange, rekeying with ECHDE, no change | 1305 | | in cryptosuite | 1306 | | | 1307 | 3 | Reconnect Exchange, rekeying with ECDHE, new | 1308 | | cryptosuite negotiated | 1309 +------------+------------------------------------------------------+ 1311 Table 3: Keying modes 1313 The key derivation has four different modes (KeyingMode), which are 1314 specified in Table 3. Table 4 defines the inputs to KDF in each 1315 KeyingMode. 1317 In the Completion Exchange (KeyingMode=0), the input Z comes from the 1318 preceding Initial exchange. KDF takes some additional inputs 1319 (FixedInfo), for which we use the concatenation format defined in 1320 section 5.8.2.1.1 of the NIST specification [NIST-DH]. FixedInfo 1321 consists of the AlgorithmId, PartyUInfo, PartyVInfo, and SuppPrivInfo 1322 fields. The first three fields are fixed-length bit strings, and 1323 SuppPrivInfo is a variable-length string with a one-byte Datalength 1324 counter. AlgorithmId is the fixed-length 8-byte ASCII string "EAP- 1325 NOOB". The other input values are the server and peer nonces. In 1326 the Completion Exchange, the inputs also include the secret nonce 1327 Noob from the OOB message. 1329 In the simplest form of the Reconnect Exchange (KeyingMode=1), fresh 1330 nonces are exchanged but no ECDHE keys are sent. In this case, input 1331 Z to the KDF is replaced with the shared key Kz from the persistent 1332 EAP-NOOB association. The result is rekeying without the 1333 computational cost of the ECDHE exchange, but also without forward 1334 secrecy. 1336 When forward secrecy is desired in the Reconnect Exchange 1337 (KeyingMode=2 or KeyingMode=3), both nonces and ECDHE keys are 1338 exchanged. Input Z is the fresh shared secret from the ECDHE 1339 exchange with PKs2 and PKp2. The inputs also include the shared 1340 secret Kz from the persistent EAP-NOOB association. This binds the 1341 rekeying output to the previously authenticated keys. 1343 +--------------+--------------+------------------------+------------+ 1344 | KeyingMode | KDF input | Value | Length | 1345 | | field | | (bytes) | 1346 +--------------+--------------+------------------------+------------+ 1347 | 0 | Z | ECDHE shared secret | variable | 1348 | Completion | | from PKs and PKp | | 1349 | | AlgorithmId | "EAP-NOOB" | 8 | 1350 | | PartyUInfo | Np | 32 | 1351 | | PartyVInfo | Ns | 32 | 1352 | | SuppPubInfo | (not allowed) | | 1353 | | SuppPrivInfo | Noob | 16 | 1354 | | | | | 1355 | 1 | Z | Kz | 32 | 1356 | Reconnect, | AlgorithmId | "EAP-NOOB" | 8 | 1357 | rekeying | PartyUInfo | Np2 | 32 | 1358 | without | PartyVInfo | Ns2 | 32 | 1359 | ECDHE | SuppPubInfo | (not allowed) | | 1360 | | SuppPrivInfo | (null) | 0 | 1361 | | | | | 1362 | 2 or 3 | Z | ECDHE shared secret | variable | 1363 | Reconnect, | | from PKs2 and PKp2 | | 1364 | rekeying, | AlgorithmId | "EAP-NOOB" | 8 | 1365 | with ECDHE, | PartyUInfo | Np2 | 32 | 1366 | same or new | PartyVInfo | Ns2 | 32 | 1367 | cryptosuite | SuppPubInfo | (not allowed) | | 1368 | | SuppPrivInfo | Kz | 32 | 1369 +--------------+--------------+------------------------+------------+ 1371 Table 4: Key derivation input 1373 Table 5 defines how the output bytes of KDF are used. In addition to 1374 the EAP output values MSK and EMSK, the server and peer derive 1375 another shared secret key AMSK, which MAY be used for application- 1376 layer security. Further output bytes are used internally by EAP-NOOB 1377 for the message authentication keys (Kms, Kmp, Kms2, Kmp2). 1379 The Completion Exchange (KeyingMode=0) produces the shared secret Kz, 1380 which the server and peer store in the persistent EAP-NOOB 1381 association. When a new cryptosuite is negotiated in the Reconnect 1382 Exchange (KeyingMode=3), it similarly produces a new Kz. In that 1383 case, the server and peer update both the cryptosuite and Kz in the 1384 persistent EAP-NOOB association. Additionally, the peer stores the 1385 previous Cryptosuitep and Kz values in the CryptosuitepPrev and 1386 KzPrev fields of the persistent EAP-NOOB association. 1388 +-----------------+------------------+----------+----------------+ 1389 | KeyingMode | KDF output bytes | Used as | Length (bytes) | 1390 +-----------------+------------------+----------+----------------+ 1391 | 0 | 0..63 | MSK | 64 | 1392 | Completion | 64..127 | EMSK | 64 | 1393 | | 128..191 | AMSK | 64 | 1394 | | 192..223 | MethodId | 32 | 1395 | | 224..255 | Kms | 32 | 1396 | | 256..287 | Kmp | 32 | 1397 | | 288..319 | Kz | 32 | 1398 | | | | | 1399 | 1 or 2 | 0..63 | MSK | 64 | 1400 | Reconnect, | 64..127 | EMSK | 64 | 1401 | rekeying | 128..191 | AMSK | 64 | 1402 | without ECDHE, | 192..223 | MethodId | 32 | 1403 | or with ECDHE | 224..255 | Kms2 | 32 | 1404 | and unchanged | 256..287 | Kmp2 | 32 | 1405 | cryptosuite | | | | 1406 | | | | | 1407 | | | | | 1408 | 3 Reconnect, | 0..63 | MSK | 64 | 1409 | rekeying | 64..127 | EMSK | 64 | 1410 | with ECDHE, | 128..191 | AMSK | 64 | 1411 | new cryptosuite | 192..223 | MethodId | 32 | 1412 | | 224..255 | Kms2 | 32 | 1413 | | 256..287 | Kmp2 | 32 | 1414 | | 288..319 | Kz | 32 | 1415 +-----------------+------------------+----------+----------------+ 1417 Table 5: Key derivation output 1419 Finally, every EAP method must export a Server-Id, Peer-Id, and 1420 Session-Id [RFC5247]. In EAP-NOOB, the exported Peer-Id is the 1421 PeerId which the server has assigned to the peer. The exported 1422 Server-Id is a zero-length string (i.e., null string) because EAP- 1423 NOOB neither knows nor assigns any server identifier. The exported 1424 Session-Id is created by concatenating the Type-Code xxx (TBA) with 1425 the MethodId, which is obtained from the KDF output as shown in 1426 Table 5. 1428 3.6. Error handling 1430 Various error conditions in EAP-NOOB are handled by sending an error 1431 notification message (Type=0) instead of a next EAP request or 1432 response message. Both the EAP server and the peer may send the 1433 error notification, as shown in Figure 9 and Figure 10. After 1434 sending or receiving an error notification, the server MUST send an 1435 EAP-Failure (as required by [RFC3748] section 4.2). The notification 1436 MAY contain an ErrorInfo field, which is a UTF-8 encoded text string 1437 with a maximum length of 500 bytes. It is used for sending 1438 descriptive information about the error for logging and debugging 1439 purposes. 1441 EAP Peer EAP Server 1442 ... ... 1443 | | 1444 |<----------- EAP-Request/EAP-NOOB ----------------| 1445 | (Type=0,[PeerId],ErrorCode,[ErrorInfo]) | 1446 | | 1447 | | 1448 |<----------- EAP-Failure -------------------------| 1449 | | 1451 Figure 9: Error notification from server to peer 1453 EAP Peer EAP Server 1454 ... ... 1455 | | 1456 |------------ EAP-Response/EAP-NOOB -------------->| 1457 | (Type=0,[PeerId],ErrorCode,[ErrorInfo]) | 1458 | | 1459 | | 1460 |<----------- EAP-Failure -------------------------| 1461 | | 1463 Figure 10: Error notification from peer to server 1465 After the exchange fails due to an error notification, the server and 1466 peer set the association state as follows. In the Initial Exchange, 1467 both the sender and recipient of the error notification MUST set the 1468 association state to the Unregistered (0) state. In the Waiting and 1469 Completion Exchanges, each side MUST remain in its old state as if 1470 the failed exchange had not taken place, with the exception that the 1471 recipient of error code 2003 processes it as specified in 1472 Section 3.2.4. In the Reconnect Exchange, both sides MUST set the 1473 association state to the Reconnecting (3) state. 1475 Errors that occur in the OOB channel are not explicitly notified in- 1476 band. 1478 3.6.1. Invalid messages 1480 If the NAI structure is invalid, the server SHOULD send the error 1481 code 1001 to the peer. The recipient of an EAP-NOOB request or 1482 response SHOULD send the following error codes back to the sender: 1483 1002 if it cannot parse the message as a JSON object or the top-level 1484 JSON object has missing or unrecognized members; 1003 if a data field 1485 has an invalid value, such as an integer out of range, and there is 1486 no more specific error code available; 1004 if the received message 1487 type was unexpected in the current state; 2004 if the PeerId has an 1488 unexpected value; 2003 if the NoobId is not recognized; and 1005 if 1489 the ECDHE key is invalid. 1491 3.6.2. Unwanted peer 1493 The preferred way for the EAP server to rate limit EAP-NOOB 1494 connections from a peer is to use the SleepTime parameter in the 1495 Waiting Exchange. However, if the EAP server receives repeated EAP- 1496 NOOB connections from a peer which apparently should not connect to 1497 this server, the server MAY indicate that the connections are 1498 unwanted by sending the error code 2001. After receiving this error 1499 message, the peer MAY refrain from reconnecting to the same EAP 1500 server and, if possible, both the EAP server and peer SHOULD indicate 1501 this error condition to the user or server administrator. However, 1502 in order to avoid persistent denial of service, peer devices that are 1503 unable to alert a user SHOULD continue to try to reconnect 1504 infrequently (e.g., approximately every 3600 seconds). 1506 3.6.3. State mismatch 1508 In the states indicated by "-" in Figure 11 in Appendix A, user 1509 action is required to reset the association state or to recover it, 1510 for example, from backup storage. In those cases, the server sends 1511 the error code 2002 to the peer. If possible, both the EAP server 1512 and peer SHOULD indicate this error condition to the user or server 1513 administrator. 1515 3.6.4. Negotiation failure 1517 If there is no matching protocol version, the peer sends the error 1518 code 3001 to the server. If there is no matching cryptosuite, the 1519 peer sends the error code 3002 to the server. If there is no 1520 matching OOB direction, the peer sends the error code 3003 to the 1521 server. 1523 In practice, there is no way of recovering from these errors without 1524 software or hardware changes. If possible, both the EAP server and 1525 peer SHOULD indicate these error conditions to the user. 1527 3.6.5. Cryptographic verification failure 1529 If the receiver of the OOB message detects an unrecognized PeerId or 1530 incorrect fingerprint (Hoob) in the OOB message, the receiver MUST 1531 remain in the Waiting for OOB state (1) as if no OOB message was 1532 received. The receiver SHOULD indicate the failure to accept the OOB 1533 message to the user. No in-band error message is sent. 1535 Note that if the OOB message was delivered from the server to the 1536 peer and the peer does not recognize the PeerId, the likely cause is 1537 that the user has unintentionally delivered the OOB message to the 1538 wrong peer device. If possible, the peer SHOULD indicate this to the 1539 user; however, the peer device may not have the capability for many 1540 different error indications to the user, and it MAY use the same 1541 indication as in the case of an incorrect fingerprint. 1543 The rationale for the above is that the invalid OOB message could 1544 have been presented to the receiver by mistake or intentionally by a 1545 malicious party and, thus, it should be ignored in the hope that the 1546 honest user will soon deliver a correct OOB message. 1548 If the EAP server or peer detects an incorrect message authentication 1549 code (MACs, MACp, MACs2, MACp2), it sends the error code 4001 to the 1550 other side. As specified in the beginning of Section 3.6, the failed 1551 Completion Exchange will not result in server or peer state changes 1552 while an error in the Reconnect Exchange will put both sides to the 1553 Reconnecting (3) state and thus lead to another reconnect attempt. 1555 The rationale for this is that the invalid cryptographic message may 1556 have been spoofed by a malicious party and, thus, it should be 1557 ignored. In particular, a spoofed message on the in-band channel 1558 should not force the honest user to perform the OOB Step again. In 1559 practice, however, the error may be caused by other failures, such as 1560 a software bug. For this reason, the EAP server MAY limit the rate 1561 of peer connections with SleepTime after the above error. Also, 1562 there SHOULD be a way for the user to reset the peer to the 1563 Unregistered state (0), so that the OOB Step can be repeated as the 1564 last resort. 1566 3.6.6. Application-specific failure 1568 Applications MAY define new error messages for failures that are 1569 specific to the application or to one type of OOB channel. They MAY 1570 also use the generic application-specific error code 5001, or the 1571 error codes 5002 and 5004, which have been reserved for indicating 1572 invalid data in the ServerInfo and PeerInfo fields, respectively. 1573 Additionally, anticipating OOB channels that make use of a URL, the 1574 error code 5003 has been reserved for indicating an invalid server 1575 URL. 1577 4. ServerInfo and PeerInfo contents 1579 The ServerInfo and PeerInfo fields in the Initial Exchange and 1580 Reconnect Exchange enable the server and peer, respectively, to send 1581 information about themselves to the other endpoint. They contain 1582 JSON objects whose structure may be specified separately for each 1583 application and each type of OOB channel. ServerInfo and PeerInfo 1584 MAY contain auxiliary data needed for the OOB channel messaging and 1585 for EAP channel binding (see Section 7.7). This section describes 1586 the optional initial data fields for ServerInfo and PeerInfo 1587 registered by this specification. Further specifications may request 1588 new application-specific ServerInfo and PeerInfo data fields from 1589 IANA (see Section 5.4 and Section 5.5). 1591 +----------------+--------------------------------------------------+ 1592 | Data Field | Description | 1593 +----------------+--------------------------------------------------+ 1594 | Type | Type-tag string that can be used by the peer as | 1595 | | a hint for how to interpret the ServerInfo | 1596 | | contents. | 1597 | | | 1598 | ServerName | String that may be used to aid human | 1599 | | identification of the server. | 1600 | | | 1601 | ServerURL | Prefix string when the OOB message is formatted | 1602 | | as a URL, as suggested in Appendix D. | 1603 | | | 1604 | SSIDList | List of IEEE 802.11 wireless network identifier | 1605 | | (SSID) strings used for roaming support, as | 1606 | | suggested in Appendix C. JSON array of ASCII | 1607 | | encoded SSID strings. | 1608 | | | 1609 | Base64SSIDList | List of IEEE 802.11 wireless network identifier | 1610 | | (SSID) strings used for roaming support, as | 1611 | | suggested in Appendix C. JSON array of SSIDs, | 1612 | | each of which is base64url encoded without | 1613 | | padding. Peers SHOULD send at most one of the | 1614 | | fields SSIDList and Base64SSIDList in PeerInfo, | 1615 | | and the server SHOULD ignore SSIDList if | 1616 | | Base64SSIDList is included. | 1617 +----------------+--------------------------------------------------+ 1619 Table 6: ServerInfo data fields 1621 +--------------+----------------------------------------------------+ 1622 | Data Field | Description | 1623 +--------------+----------------------------------------------------+ 1624 | Type | Type-tag string that can be used by the server as | 1625 | | a hint for how to interpret the PeerInfo contents. | 1626 | | | 1627 | PeerName | String that may be used to aid human | 1628 | | identification of the peer. | 1629 | | | 1630 | Manufacturer | Manufacturer or brand string. | 1631 | | | 1632 | Model | Manufacturer-specified model string. | 1633 | | | 1634 | SerialNumber | Manufacturer-assigned serial number. | 1635 | | | 1636 | MACAddress | Peer link-layer identifier (EUI-48) in the | 1637 | | 12-digit base-16 form [EUI-48]. The string MAY be | 1638 | | in upper or lower case and MAY include additional | 1639 | | colon ':' or dash '-' characters that MUST be | 1640 | | ignored by the server. | 1641 | | | 1642 | SSID | IEEE 802.11 network SSID for channel binding. The | 1643 | | SSID is an ASCII string. | 1644 | | | 1645 | Base64SSID | IEEE 802.11 network SSID for channel binding. The | 1646 | | SSID is base64url encoded. Peer SHOULD send at | 1647 | | most one of the fields SSID and Base64SSID in | 1648 | | PeerInfo, and the server SHOULD ignore SSID if | 1649 | | Base64SSID is included. | 1650 | | | 1651 | BSSID | Wireless network BSSID (EUI-48) in the 12-digit | 1652 | | base-16 form [EUI-48] for channel binding. The | 1653 | | string MAY be in upper or lower case and MAY | 1654 | | include additional colon ':' or dash '-' | 1655 | | characters that MUST be ignored by the server. | 1656 | | | 1657 +--------------+----------------------------------------------------+ 1659 Table 7: PeerInfo data fields 1661 5. IANA Considerations 1663 This section provides guidance to the Internet Assigned Numbers 1664 Authority (IANA) regarding registration of values related to the EAP- 1665 NOOB protocol, in accordance with [RFC8126]. 1667 The EAP Method Type number for EAP-NOOB needs to be assigned in the 1668 Method Types sub-registry of the Extensible Authentication Protocol 1669 (EAP) registry (requested value = 56). 1671 This memo also requires IANA to create and maintain a new registry 1672 entitled "Nimble out-of-band authentication for EAP Parameters" in 1673 the Extensible Authentication Protocol (EAP) registry. IANA is also 1674 requested to create and maintain sub-registries defined in the 1675 following subsections. 1677 5.1. Cryptosuites 1679 IANA is requested to create and maintain a new sub-registry entitled 1680 "EAP-NOOB Cryptosuites" in the "Nimble out-of-band authentication for 1681 EAP Parameters" registry. Cryptosuites are identified by an integer. 1682 Each cryptosuite MUST specify an ECDHE curve for the key exchange, 1683 encoding of the ECDHE public key as a JWK object, and a cryptographic 1684 hash function for the fingerprint and HMAC computation and key 1685 derivation. The hash value output by the cryptographic hash function 1686 MUST be at least 32 bytes in length. The initial values for this 1687 registry are: 1689 +-------------+-----------------------------------------------------+ 1690 | Cryptosuite | Algorithms | 1691 +-------------+-----------------------------------------------------+ 1692 | 1 | ECDHE curve Curve25519 [RFC7748], public-key format | 1693 | | [RFC7517], hash function SHA-256 [RFC6234]. The JWK | 1694 | | encoding of Curve25519 public key is defined in | 1695 | | [RFC8037]. For clarity: the "crv" parameter is | 1696 | | "X25519", the "kty" parameter is "OKP", and the | 1697 | | public-key encoding contains only an x-coordinate. | 1698 | 2 | ECDHE curve NIST P-256 [FIPS186-4], public-key | 1699 | | format [RFC7517], hash function SHA-256 [RFC6234]. | 1700 | | The JWK encoding of NIST P-256 public key is | 1701 | | defined in [RFC7518]. For clarity: the "crv" | 1702 | | parameter is "P-256", the "kty" parameter is "EC", | 1703 | | and the public-key encoding has both an x and y | 1704 | | coordinates as defined in Section 6.2.1 of | 1705 | | [RFC7518]. | 1706 +-------------+-----------------------------------------------------+ 1708 Table 8: EAP-NOOB cryptosuites 1710 EAP-NOOB implementations MUST support Cryptosuite 1. Support for 1711 Cryptosuite 2 is RECOMMENDED. An example of Cryptosuite 1 public-key 1712 encoded as a JWK object is given below (line breaks are for 1713 readability only). 1715 "jwk":{"kty":"OKP","crv":"X25519","x":"3p7bfXt9wbTTW2HC7OQ1Nz- 1716 DQ8hbeGdNrfx-FG-IK08"} 1718 Assignment of new values for new cryptosuites MUST be done through 1719 IANA with "Specification Required" as defined in [RFC8126]. 1721 5.2. Message Types 1723 IANA is requested to create and maintain a new sub-registry entitled 1724 "EAP-NOOB Message Types" in the "Nimble out-of-band authentication 1725 for EAP Parameters" registry. EAP-NOOB request and response pairs 1726 are identified by an integer Message Type. The initial values for 1727 this registry are: 1729 +----------+------------+-------------------------------------------+ 1730 | Message | Used in | Purpose | 1731 | Type | Exchange | | 1732 +----------+------------+-------------------------------------------+ 1733 | 1 | All | PeerId and PeerState discovery | 1734 | | exchanges | | 1735 | | | | 1736 | 2 | Initial | Version, cryptosuite and parameter | 1737 | | | negotiation | 1738 | | | | 1739 | 3 | Initial | Exchange of ECDHE keys and nonces | 1740 | | | | 1741 | 4 | Waiting | Indication to peer that the server has | 1742 | | | not yet received an OOB message | 1743 | | | | 1744 | 5 | Completion | NoobId discovery | 1745 | | | | 1746 | 6 | Completion | Authentication and key confirmation with | 1747 | | | HMAC | 1748 | | | | 1749 | 7 | Reconnect | Version, cryptosuite, and parameter | 1750 | | | negotiation | 1751 | | | | 1752 | 8 | Reconnect | Exchange of ECDHE keys and nonces | 1753 | | | | 1754 | 9 | Reconnect | Authentication and key confirmation with | 1755 | | | HMAC | 1756 | | | | 1757 | 0 | Error | Error notification | 1758 | | | | 1759 +----------+------------+-------------------------------------------+ 1761 Table 9: EAP-NOOB Message Types 1763 Assignment of new values for new Message Types MUST be done through 1764 IANA with "Specification Required" as defined in [RFC8126]. 1766 5.3. Error codes 1768 IANA is requested to create and maintain a new sub-registry entitled 1769 "EAP-NOOB Error codes" in the "Nimble out-of-band authentication for 1770 EAP Parameters" registry. Cryptosuites are identified by an integer. 1771 The initial values for this registry are: 1773 +------------+----------------------------------------+ 1774 | Error code | Purpose | 1775 +------------+----------------------------------------+ 1776 | 1001 | Invalid NAI | 1777 | 1002 | Invalid message structure | 1778 | 1003 | Invalid data | 1779 | 1004 | Unexpected message type | 1780 | 1005 | Invalid ECDHE key | 1781 | 2001 | Unwanted peer | 1782 | 2002 | State mismatch, user action required | 1783 | 2003 | Unrecognized OOB message identifier | 1784 | 2004 | Unexpected peer identifier | 1785 | 3001 | No mutually supported protocol version | 1786 | 3002 | No mutually supported cryptosuite | 1787 | 3003 | No mutually supported OOB direction | 1788 | 4001 | HMAC verification failure | 1789 | 5001 | Application-specific error | 1790 | 5002 | Invalid server info | 1791 | 5003 | Invalid server URL | 1792 | 5004 | Invalid peer info | 1793 | 6001-6999 | Private and experimental use | 1794 +------------+----------------------------------------+ 1796 Table 10: EAP-NOOB error codes 1798 Assignment of new error codes MUST be done through IANA with 1799 "Specification Required" as defined in [RFC8126], except for the 1800 range 6001-6999. This range is reserved for "Private Use" and 1801 "Experimental Use", both locally and on the open Internet. 1803 5.4. ServerInfo data fields 1805 IANA is requested to create and maintain a new sub-registry entitled 1806 "EAP-NOOB ServerInfo data fields" in the "Nimble out-of-band 1807 authentication for EAP Parameters" registry. The initial values for 1808 this registry are: 1810 +----------------+--------------------+ 1811 | Data Field | Specification | 1812 +----------------+--------------------+ 1813 | Type | This RFC Section 4 | 1814 | | | 1815 | ServerName | This RFC Section 4 | 1816 | | | 1817 | ServerURL | This RFC Section 4 | 1818 | | | 1819 | SSIDList | This RFC Section 4 | 1820 | | | 1821 | Base64SSIDList | This RFC Section 4 | 1822 +----------------+--------------------+ 1824 Table 11: ServerInfo data fields 1826 Assignment of new values for new ServerInfo data fields MUST be done 1827 through IANA with "Specification Required" as defined in [RFC8126]. 1829 5.5. PeerInfo data fields 1831 IANA is requested to create and maintain a new sub-registry entitled 1832 "EAP-NOOB PeerInfo data fields" in the "Nimble out-of-band 1833 authentication for EAP Parameters" registry. The initial values for 1834 this registry are: 1836 +--------------+--------------------+ 1837 | Data Field | Specification | 1838 +--------------+--------------------+ 1839 | Type | This RFC Section 4 | 1840 | | | 1841 | PeerName | This RFC Section 4 | 1842 | | | 1843 | Manufacturer | This RFC Section 4 | 1844 | | | 1845 | Model | This RFC Section 4 | 1846 | | | 1847 | SerialNumber | This RFC Section 4 | 1848 | | | 1849 | MACAddress | This RFC Section 4 | 1850 | | | 1851 | SSID | This RFC Section 4 | 1852 | | | 1853 | Base64SSID | This RFC Section 4 | 1854 | | | 1855 | BSSID | This RFC Section 4 | 1856 | | | 1857 +--------------+--------------------+ 1859 Table 12: PeerInfo data fields 1861 Assignment of new values for new PeerInfo data fields MUST be done 1862 through IANA with "Specification Required" as defined in [RFC8126]. 1864 5.6. Domain name reservation 1866 The special-use domain "eap-noob.arpa" should be registered in the 1867 .arpa registry (). No A, AAAA, or 1868 PTR records are requested. 1870 5.7. Guidance for Designated Experts 1872 Experts SHOULD be conservative in the allocation of new Cryptosuites. 1873 Experts MUST ascertain that the requested values match the current 1874 Crypto Forum Research Group (CFRG) guidance on cryptographic 1875 algorithm security. Experts MUST ensure that any new Cryptosuites 1876 fully specify the encoding of the ECDHE public key and should include 1877 details such as the value of "kty" (key type) parameter when JWK 1878 [RFC7517] encoding is used. 1880 Experts SHOULD be conservative in the allocation of new Message 1881 Types. Experts SHOULD ascertain that a well-defined specification 1882 for the new Message Type is permanently and publicly available. 1884 Experts SHOULD be conservative in the allocation of new Error codes 1885 since the 6001-6999 range is already allocated for private and 1886 experimental use. 1888 Experts MAY be liberal in the allocation of new ServerInfo and 1889 PeerInfo data fields. Experts MUST ensure that the Data Field 1890 requested has a unique name that is not easily confused with existing 1891 registrations. For example, requests for a new PeerInfo data field 1892 "ssid" should be rejected even though it is unique because it can be 1893 confused with the existing registration of "SSID". Experts MUST 1894 ensure that a suitable Description for the data field is available. 1896 6. Implementation Status 1898 Note to RFC Editor: Please remove this entire section and the 1899 reference to RFC7942 before publication. 1901 This section records the status of known implementations of the 1902 protocol defined by this specification at the time of posting of this 1903 Internet-Draft and is based on a proposal described in [RFC7942]. 1904 The description of implementations in this section is intended to 1905 assist the IETF in its decision processes in progressing drafts to 1906 RFCs. Please note that the listing of any individual implementation 1907 here does not imply endorsement by the IETF. Furthermore, no effort 1908 has been spent to verify the information presented here that was 1909 supplied by IETF contributors. This is not intended as, and must not 1910 be construed to be, a catalog of available implementations or their 1911 features. Readers are advised to note that other implementations may 1912 exist. 1914 6.1. Implementation with wpa_supplicant and hostapd 1916 o Responsible Organization: Aalto University 1918 o Location: 1920 o Coverage: This implementation includes all the features described 1921 in the current specification. The implementation supports two- 1922 dimensional QR codes and NFC as example out-of-band (OOB) 1923 channels. 1925 o Level of Maturity: Alpha 1927 o Version compatibility: Version 08 of the individual draft 1928 implemented 1930 o Licensing: BSD 1931 o Contact Information: Tuomas Aura, tuomas.aura@aalto.fi 1933 6.2. Implementation on Contiki 1935 o Responsible Organization: University of Murcia and Aalto 1936 University 1938 o Location: 1940 o Coverage: This implementation includes all the features described 1941 in the current specification. The implementation uses a blinking 1942 LED light as the out-of-band (OOB) channel. 1944 o Level of Maturity: Alpha 1946 o Version compatibility: Version 06 of the draft implemented 1948 o Licensing: BSD 1950 o Contact Information: Eduardo Ingles, eduardo.ingles@um.es 1952 6.3. Implementation with wpa_supplicant and hostapd 1954 o Responsible Organization: Ericsson 1956 o Location: 1958 o Coverage: This implementation is the most up-to-date one. The 1959 implementation only provides a minimal API interface for 1960 transferring OOB messages. 1962 o Level of Maturity: Alpha 1964 o Version compatibility: Version 02 of the working group adopted 1965 draft is implemented 1967 o Licensing: BSD 1969 6.4. Protocol modeling 1971 The current EAP-NOOB specification has been modeled with the mCRL2 1972 formal specification language [mcrl2]. The model [noob-mcrl2] was 1973 used mainly for simulating the protocol behavior and for verifying 1974 basic safety and liveness properties as part of the specification 1975 process. For example, we verified the correctness of the tiebreaking 1976 mechanism when two OOB messages are received simultaneously, one in 1977 each direction. We also verified that an on-path attacker cannot 1978 cause persistent failure by spoofing a finite number of messages in 1979 the Reconnect Exchange. Additionally, the protocol has been modeled 1980 with the ProVerif [proverif] tool. This model [noob-proverif] was 1981 used to verify security properties such as mutual authentication. 1983 7. Security considerations 1985 EAP-NOOB is an authentication and key derivation protocol and, thus, 1986 security considerations can be found in most sections of this 1987 specification. In the following, we explain the protocol design and 1988 highlight some other special considerations. 1990 7.1. Authentication principle 1992 EAP-NOOB establishes a shared secret with an authenticated ECDHE key 1993 exchange. The mutual authentication in EAP-NOOB is based on two 1994 separate features, both conveyed in the OOB message. The first 1995 authentication feature is the secret nonce Noob. The peer and server 1996 use this secret in the Completion Exchange to mutually authenticate 1997 the session key previously created with ECDHE. The message 1998 authentication codes computed with the secret nonce Noob are alone 1999 sufficient for authenticating the key exchange. The second 2000 authentication feature is the integrity-protecting fingerprint Hoob. 2001 Its purpose is to prevent impersonation attacks even in situations 2002 where the attacker is able to eavesdrop on the OOB channel and the 2003 nonce Noob is compromised. In some human-assisted OOB channels, such 2004 as human-perceptible audio or a user-typed URL, it may be easier to 2005 detect tampering than disclosure of the OOB message, and such 2006 applications benefit from the second authentication feature. 2008 The additional security provided by the cryptographic fingerprint 2009 Hoob is somewhat intricate to understand. The endpoint that receives 2010 the OOB message uses Hoob to verify the integrity of the ECDHE 2011 exchange. Thus, the OOB receiver can detect impersonation attacks 2012 that may have happened on the in-band channel. The other endpoint, 2013 however, is not equally protected because the OOB message and 2014 fingerprint are sent only in one direction. Some protection to the 2015 OOB sender is afforded by the fact that the user may notice the 2016 failure of the association at the OOB receiver and therefore reset 2017 the OOB sender. Other device-pairing protocols have solved similar 2018 situations by requiring the user to confirm to the OOB sender that 2019 the association was accepted by the OOB receiver, e.g., with a button 2020 press on the sender side. Applications MAY implement EAP-NOOB in 2021 this way. Nevertheless, since EAP-NOOB was designed to work with 2022 strictly one-directional OOB communication and the fingerprint is 2023 only the second authentication feature, the EAP-NOOB specification 2024 does not mandate such explicit confirmation to the OOB sender. 2026 To summarize, EAP-NOOB uses the combined protection of the secret 2027 nonce Noob and the cryptographic fingerprint Hoob, both conveyed in 2028 the OOB message. The secret nonce Noob alone is sufficient for 2029 mutual authentication unless the attacker can eavesdrop on it from 2030 the OOB channel. Even if an attacker is able to eavesdrop on the 2031 secret nonce Noob, it nevertheless cannot perform a full 2032 impersonation attack on the in-band channel because a mismatching 2033 fingerprint would alert the OOB receiver, which would reject the OOB 2034 message. The attacker that eavesdropped on the secret nonce can 2035 impersonate the OOB receiver to the OOB sender. If it does, the 2036 association will appear to be complete only on the OOB sender side, 2037 and such situations have to be resolved by the user by resetting the 2038 OOB sender to the initial state. 2040 The expected use cases for EAP-NOOB are ones where it replaces a 2041 user-entered access credential in IoT appliances. In wireless 2042 network access without EAP, the user-entered credential is often a 2043 passphrase that is shared by all the network stations. The advantage 2044 of an EAP-based solution, including EAP-NOOB, is that it establishes 2045 a different shared secret for each peer device, which makes the 2046 system more resilient against device compromise. Another advantage 2047 is that it is possible to revoke the security association for an 2048 individual device on the server side. 2050 Forward secrecy during fast reconnect in EAP-NOOB is optional. The 2051 Reconnect Exchange in EAP-NOOB provides forward secrecy only if both 2052 the server and peer send their fresh ECDHE keys. This allows both 2053 the server and the peer to limit the frequency of the costly 2054 computation that is required for forward secrecy. The server MAY 2055 adjust the frequency of its attempts at ECDHE rekeying based on what 2056 it knows about the peer's computational capabilities. 2058 Another way in which some servers may control their computational 2059 load is to reuse the same ECDHE key for all peers over a short 2060 server-specific time window. In that case, forward secrecy will be 2061 achieved only after the server updates its ECDHE key, which may be a 2062 reasonable trade-off between security and performance. However, the 2063 server MUST NOT reuse the same ECDHE key with the same peer when 2064 rekeying with ECDHE (KeyingMode=2 or KeyingMode=3). Instead, it can 2065 simply not send an ECDHE key (KeyingMode=1). 2067 The users delivering the OOB messages will often authenticate 2068 themselves to the EAP server, e.g., by logging into a secure web page 2069 or API. In this case, the server can associate the peer device with 2070 the user account. Applications that make use of EAP-NOOB can use 2071 this information for configuring the initial owner of the freshly- 2072 registered device. 2074 7.2. Identifying correct endpoints 2076 Potential weaknesses in EAP-NOOB arise from the fact that the user 2077 must identify physically the correct peer device. If the user 2078 mistakenly delivers the OOB message from the wrong peer device to the 2079 server, the server may create an association with the wrong peer. 2080 The reliance on the user in identifying the correct endpoints is an 2081 inherent property of user-assisted out-of-band authentication. To 2082 understand the potential consequences of the user mistake, we need to 2083 consider a few different scenarios. In the first scenario, there is 2084 no malicious party, and the user makes an accidental mistake between 2085 two out-of-the-box devices that are both ready to be registered to a 2086 server. If the user delivers the OOB message from the wrong device 2087 to the server, confusion may arise but usually no security issues. 2088 In the second scenario, an attacker intentionally tricks the user, 2089 for example, by substituting the original peer device with a 2090 compromised one. This is essentially a supply chain attack where the 2091 user accepts a compromised physical device. 2093 There is also a third scenario, in which an opportunistic attacker 2094 tries to take advantage of the user's accidental mistake. For 2095 example, the user could play an audio or a blinking LED message to a 2096 device that is not expecting to receive it. In simple security 2097 bootstrapping solutions that transfer a master key to the device via 2098 the OOB channel, the device could misuse or leak the accidentally 2099 received master key. EAP-NOOB is not vulnerable to such 2100 opportunistic attackers because the OOB message has no value to 2101 anyone who did not take part in the corresponding Initial Exchange. 2103 One mechanism that can mitigate user mistakes is certification of 2104 peer devices. A certificate or an attestation token 2105 (e.g.,[I-D.tschofenig-tls-cwt] and [I-D.ietf-rats-eat]) can convey to 2106 the server authentic identifiers and attributes, such as model and 2107 serial number, of the peer device. Compared to a fully certificate- 2108 based authentication, however, EAP-NOOB can be used without trusted 2109 third parties and does not require the user to know any identifier of 2110 the peer device; physical access to the device is sufficient for 2111 bootstrapping with EAP-NOOB. 2113 Similarly, the attacker can try to trick the user into delivering the 2114 OOB message to the wrong server, so that the peer device becomes 2115 associated with the wrong server. If the EAP server is accessed 2116 through a web user interface, the attack is akin to phishing attacks 2117 where the user is tricked into accessing the wrong URL and wrong web 2118 page. OOB implementation with a dedicated app on a mobile device, 2119 which communicates with a server API at a pre-configured URL, can 2120 protect against such attacks. 2122 After the device registration, an attacker could clone the device 2123 identity by copying the keys from the persistent EAP-NOOB association 2124 into another device. The attacker can be an outsider who gains 2125 access to the keys or the device owner who wants to have two devices 2126 matching the same registration. The cloning threats can be mitigated 2127 by creating the cryptographic keys and storing the persistent EAP- 2128 NOOB association on the peer device in a secure hardware component 2129 such as a trusted execution environment (TEE). Furthermore, remote 2130 attestation on the application level could provide assurance to the 2131 server that the device has not been cloned. Reconnect Exchange with 2132 a new cryptosuite (KeyingMode=3) will also disconnect all but the 2133 first clone that performs the update. 2135 7.3. Trusted path issues and misbinding attacks 2137 Another potential threat is spoofed user input or output on the peer 2138 device. When the user is delivering the OOB message to or from the 2139 correct peer device, a trusted path between the user and the peer 2140 device is needed. That is, the user must communicate directly with 2141 an authentic operating system and EAP-NOOB implementation in the peer 2142 device and not with a spoofed user interface. Otherwise, a 2143 registered device that is under the control of the attacker could 2144 emulate the behavior of an unregistered device. The secure path can 2145 be implemented, for example, by having the user press a reset button 2146 to return the device to the Unregistered state and to invoke a 2147 trusted UI. The problem with such trusted paths is that they are not 2148 standardized across devices. 2150 Another potential consequence of a spoofed UI is the misbinding 2151 attack where the user tries to register a correct but compromised 2152 device, which tricks the user into registering another 2153 (uncompromised) device instead. For example, the compromised device 2154 might have a malicious full-screen app running, which presents to the 2155 user QR codes copied, in real time, from another device's screen. If 2156 the unwitting user scans the QR code and delivers the OOB message in 2157 it to the server, the wrong device may become registered in the 2158 server. Such misbinding vulnerabilities arise because the user does 2159 not have any secure way of verifying that the in-band cryptographic 2160 handshake and the out-of-band physical access are terminated at the 2161 same physical device. Sethi et al. [Sethi19] analyze the misbinding 2162 threat against device-pairing protocols and also EAP-NOOB. 2163 Essentially, all protocols where the authentication relies on the 2164 user's physical access to the device are vulnerable to misbinding, 2165 including EAP-NOOB. 2167 A standardized trusted path for communicating directly with the 2168 trusted computing base in a physical device would mitigate the 2169 misbinding threat, but such paths rarely exist in practice. Careful 2170 asset tracking on the server side can also prevent most misbinding 2171 attacks if the peer device sends its identifiers or attributes in the 2172 PeerInfo field and the server compares them with the expected values. 2173 The wrong but uncompromised device's PeerInfo will not match the 2174 expected values. Device certification by the manufacturer can 2175 further strengthen the asset tracking. 2177 7.4. Peer identifiers and attributes 2179 The PeerId value in the protocol is a server-allocated identifier for 2180 its association with the peer and SHOULD NOT be shown to the user 2181 because its value is initially ephemeral. Since the PeerId is 2182 allocated by the server and the scope of the identifier is the single 2183 server, the so-called identifier squatting attacks, where a malicious 2184 peer could reserve another peer's identifier, are not possible in 2185 EAP-NOOB. The server SHOULD assign a random or pseudo-random PeerId 2186 to each new peer. It SHOULD NOT select the PeerId based on any peer 2187 characteristics that it may know, such as the peer's link-layer 2188 network address. 2190 User reset or failure in the OOB Step can cause the peer to perform 2191 many Initial Exchanges with the server, which allocates many PeerId 2192 values and stores the ephemeral protocol state for them. The peer 2193 will typically only remember the latest ones. EAP-NOOB leaves it to 2194 the implementation to decide when to delete these ephemeral 2195 associations. There is no security reason to delete them early, and 2196 the server does not have any way to verify that the peers are 2197 actually the same one. Thus, it is safest to store the ephemeral 2198 states on the server for at least one day. If the OOB messages are 2199 sent only in the server-to-peer direction, the server SHOULD NOT 2200 delete the ephemeral state before all the related Noob values have 2201 expired. 2203 After completion of EAP-NOOB, the server may store the PeerInfo data, 2204 and the user may use it to identify the peer and its attributes, such 2205 as the make and model or serial number. A compromised peer could lie 2206 in the PeerInfo which it sends to the server. If the server stores 2207 any information about the peer, it is important that this information 2208 is approved by the user during or after the OOB Step. Without 2209 verification by the user or authentication on the application level, 2210 the PeerInfo is not authenticated information and should not be 2211 relied on. One possible use for the PeerInfo field is EAP channel 2212 binding (see Section 7.7). 2214 7.5. Downgrading threats 2216 The fingerprint Hoob protects all the information exchanged in the 2217 Initial Exchange, including the cryptosuite negotiation. The message 2218 authentication codes MACs and MACp also protect the same information. 2219 The message authentication codes MACs2 and MACp2 protect information 2220 exchanged during key renegotiation in the Reconnect Exchange. This 2221 prevents downgrading attacks to weaker cryptosuites as long as the 2222 possible attacks take more time than the maximum time allowed for the 2223 EAP-NOOB completion. This is typically the case for recently 2224 discovered cryptanalytic attacks. 2226 As an additional precaution, the EAP server and peer MUST check for 2227 downgrading attacks in the Reconnect Exchange as follows. As long as 2228 the server or peer saves any information about the other endpoint, it 2229 MUST also remember the previously negotiated cryptosuite and MUST NOT 2230 accept renegotiation of any cryptosuite that is known to be weaker 2231 than the previous one, such as a deprecated cryptosuite. Determining 2232 the relative strength of the cryptosuites is out of scope of this 2233 specification and may be managed by implementations or by local 2234 policies at the peer and server. 2236 Integrity of the direction negotiation cannot be verified in the same 2237 way as the integrity of the cryptosuite negotiation. That is, if the 2238 OOB channel used in an application is critically insecure in one 2239 direction, an on-path attacker could modify the negotiation messages 2240 and thereby cause that direction to be used. Applications that 2241 support OOB messages in both directions SHOULD therefore ensure that 2242 the OOB channel has sufficiently strong security in both directions. 2243 While this is a theoretical vulnerability, it could arise in practice 2244 if EAP-NOOB is deployed in new applications. Currently, we expect 2245 most peer devices to support only one OOB direction, in which case 2246 interfering with the direction negotiation can only prevent the 2247 completion of the protocol. 2249 The long-term shared key material Kz in the persistent EAP-NOOB 2250 association is established with an ECDHE key exchange when the peer 2251 and server are first associated. It is a weaker secret than a 2252 manually configured random shared key because advances in 2253 cryptanalysis against the used ECDHE curve could eventually enable 2254 the attacker to recover Kz. EAP-NOOB protects against such attacks 2255 by allowing cryptosuite upgrades in the Reconnect Exchange and by 2256 updating the shared key material Kz whenever the cryptosuite is 2257 upgraded. We do not expect the cryptosuite upgrades to be frequent, 2258 but if an upgrade becomes necessary, it can be done without manual 2259 reset and reassociation of the peer devices. 2261 7.6. Protected success and failure indications 2263 Section 7.16 of [RFC3748] allows EAP methods to specify protected 2264 result indications because EAP-Success and EAP-Failure packets are 2265 neither acknowledged nor integrity protected. [RFC3748] notes that 2266 these indications may be explicit or implicit. 2268 EAP-NOOB relies on implicit protected success indicators in the 2269 Completion and Reconnect exchange. Successful verification of MACs 2270 and MACs2 in the EAP-Request message from the server (message type 6 2271 and message type 9, respectively) acts as an implicit protected 2272 success indication to the peer. Similarly, successful verification 2273 of MACp and MACp2 in the EAP-Response message from the peer (message 2274 type 6 and message type 9, respectively) act as an implicit protected 2275 success indication to the server. 2277 EAP-NOOB failure messages are not protected. Protected failure 2278 result indications would not significantly improve availability since 2279 EAP-NOOB reacts to most malformed data by ending the current EAP 2280 conversation in EAP-Failure. However, since EAP-NOOB spans multiple 2281 conversations, failure in one conversation usually means no state 2282 change on the level of the EAP-NOOB state machine. 2284 7.7. Channel Binding 2286 EAP channel binding, defined in [RFC6677], means that the endpoints 2287 compare their perceptions of network properties, such as lower-layer 2288 identifiers, over the secure channel established by EAP 2289 authentication. Section 4.1 of [RFC6677] defines two approaches to 2290 channel binding. EAP-NOOB follows the first approach, in which the 2291 peer and server exchange plaintext information about the network over 2292 a channel that is integrity protected with keys derived during the 2293 EAP execution. More specifically, channel information is exchanged 2294 in the plaintext PeerInfo and ServerInfo objects and is later 2295 verified with message authentication codes (MACp, MACs, MACp2, 2296 MACs2). This allows policy-based comparison with locally perceived 2297 network properties on either side, as well as logging for debugging 2298 purposes. The peer MAY include in PeerInfo any data items that it 2299 wants to bind to the EAP-NOOB association and to the exported keys. 2300 These can be properties of the authenticator or the access link, such 2301 as the SSID and BSSID of the wireless network (see Table 6). As 2302 noted in Section 4.3 of [RFC6677], the scope of the channel binding 2303 varies between deployments. For example, the server may have less 2304 link-layer information available from roaming networks than from a 2305 local enterprise network, and it may be unable to verify all the 2306 network properties received in PeerInfo. There are also privacy 2307 considerations related to exchanging the ServerInfo and PeerInfo 2308 while roaming (see Section 7.10). 2310 Channel binding to secure channels, defined in [RFC5056], binds 2311 authentication at a higher protocol layer to a secure channel at a 2312 lower layer. Like most EAP methods, EAP-NOOB exports the session 2313 keys MSK and EMSK, and an outer tunnel or a higher-layer protocol can 2314 bind its authentication to these keys. Additionally, EAP-NOOB 2315 exports the key AMSK, which may be used to bind application-layer 2316 authentication to the secure channel created by EAP-NOOB and to the 2317 session keys MSK and EMSK. 2319 7.8. Denial of Service 2321 While denial-of-service (DoS) attacks by on-link attackers cannot be 2322 fully prevented, the design goal in EAP-NOOB is to void long-lasting 2323 failure caused by an attacker who is present only temporarily or 2324 intermittently. The main defense mechanism is the persistent EAP- 2325 NOOB association, which is never deleted automatically due to in-band 2326 messages or error indications. Thus, the endpoints can always use 2327 the persistent association for reconnecting after the DoS attacker 2328 leaves the network. In this sense, the persistent association serves 2329 the same function in EAP-NOOB as a permanent master key or 2330 certificate in other authentication protocols. We discuss logical 2331 attacks against the updates of the persistent association in 2332 Section 7.9. 2334 In addition to logical DoS attacks, it is necessary to consider 2335 resource exhaustion attacks against the EAP server. The number of 2336 persistent EAP-NOOB associations created in the server is limited by 2337 the need for a user to assist in delivering the OOB message. The 2338 users can be authenticated for the input or output of the OOB message 2339 at the EAP server, and any users who create excessive numbers of 2340 persistent associations can be held accountable and their 2341 associations can be deleted by the server administrator. What the 2342 attacker can do without user authentication is to perform the Initial 2343 Exchange repeatedly and create a large number of ephemeral 2344 associations (server in state 1, Waiting for OOB) without ever 2345 delivering the OOB message. Above in Section 7.4, it was suggested 2346 that the server should store the ephemeral states for at least a day. 2347 This may require off-loading the state storage from memory to disk 2348 during a DoS attack. However, if the server implementation is unable 2349 to keep up with a rate of Initial Exchanges performed by a DoS 2350 attacker and needs to drop some ephemeral states, no damage is caused 2351 to already created persistent associations, and the honest users can 2352 resume registering new peers when the DoS attacker leaves the 2353 network. 2355 There are some trade-offs in the protocol design between polite back- 2356 off and giving way to DoS attackers. An on-link DoS attacker could 2357 spoof the SleepTime value in the Initial Exchange or Waiting Exchange 2358 to cause denial of service against a specific peer device. There is 2359 an upper limit on the SleepTime (3600 seconds) to mitigate the 2360 spoofing threat. This means that, in the presence of an on-link DoS 2361 attacker who spoofs the SleepTime, it could take up to one hour after 2362 the delivery of the OOB message before the device performs the 2363 Completion Exchange and becomes functional. Similarly, the Unwanted 2364 peer error (error code 2001) could cause the peer to stop connecting 2365 to the network. If the peer device is able to alert the user about 2366 the error condition, it can safely stop connecting to the server and 2367 wait for the user to trigger a reconnection attempt, e.g., by 2368 resetting the device. As mentioned in Section 3.6.2, peer devices 2369 that are unable to alert the user should continue to retry the 2370 Initial Exchange infrequently to avoid a permanent DoS condition. We 2371 believe a maximum backoff time of 3600 seconds is reasonable for a 2372 new protocol because malfunctioning or misconfigured peer 2373 implementations are at least as great a concern as DoS attacks, and 2374 politely backing off within some reasonable limits will increase the 2375 acceptance of the protocol. The maximum backoff times could be 2376 updated to be shorter as the protocol implementations mature. 2378 7.9. Recovery from loss of last message 2380 The EAP-NOOB Completion Exchange, as well as the Reconnect Exchange 2381 with cryptosuite update, result in a persistent state change that 2382 should take place either on both endpoints or on neither; otherwise, 2383 the result is a state mismatch that requires user action to resolve. 2384 The state mismatch can occur if the final EAP response of the 2385 exchanges is lost. In the Completion Exchange, the loss of the final 2386 response (Type=6) results in the peer moving to Registered (4) state 2387 and creating a persistent EAP-NOOB association while the server stays 2388 in an ephemeral state (1 or 2). In the Reconnect Exchange, the loss 2389 of the final response (Type=9) results in the peer moving to the 2390 Registered (4) state and updating its persistent key material Kz 2391 while the server stays in the Reconnecting (3) state and keeps the 2392 old key material. 2394 The state mismatch is an example of an unavoidable problem in 2395 distributed systems: it is theoretically impossible to guarantee 2396 synchronous state changes in endpoints that communicate 2397 asynchronously. The protocol will always have one critical message 2398 that may get lost, so that one side commits to the state change and 2399 the other side does not. In EAP, the critical message is the final 2400 response from the peer to the server. While the final response is 2401 normally followed by EAP-Success, [RFC3748] section 4.2 states that 2402 the peer MAY assume that the EAP-Success was lost and the 2403 authentication was successful. Furthermore, EAP method 2404 implementations in the peer do not receive notification of the EAP- 2405 Success message from the parent EAP state machine [RFC4137]. For 2406 these reasons, EAP-NOOB on the peer side commits to a state change 2407 already when it sends the final response. 2409 The best available solution to the loss of the critical message is to 2410 keep trying. EAP retransmission behavior defined in Section 4.3 of 2411 [RFC3748] suggests 3-5 retransmissions. In the absence of an 2412 attacker, this would be sufficient to reduce the probability of 2413 failure to an acceptable level. However, a determined attacker on 2414 the in-band channel can drop the final EAP-Response message and all 2415 subsequent retransmissions. In the Completion Exchange 2416 (KeyingMode=0) and in the Reconnect Exchange with cryptosuite upgrade 2417 (KeyingMode=3), this could result in a state mismatch and persistent 2418 denial of service until the user resets the peer state. 2420 EAP-NOOB implements its own recovery mechanism that allows unlimited 2421 retries of the Reconnect Exchange. When the DoS attacker eventually 2422 stops dropping packets on the in-band channel, the protocol will 2423 recover. The logic for this recovery mechanism is specified in 2424 Section 3.4.2. 2426 EAP-NOOB does not implement the same kind of retry mechanism in the 2427 Completion Exchange. The reason is that there is always a user 2428 involved in the initial association process, and the user can repeat 2429 the OOB Step to complete the association after the DoS attacker has 2430 left. On the other hand, Reconnect Exchange needs to work without 2431 user involvement. 2433 7.10. Privacy considerations 2435 There are privacy considerations related to performing the Reconnect 2436 Exchange while roaming. The peer and server may send updated 2437 PeerInfo and ServerInfo fields in the Reconnect Exchange. This data 2438 is sent unencrypted between the peer and the EAP authenticator, such 2439 as a wireless access point. Thus, it can be observed by both 2440 outsiders and the access network. The PeerInfo field contains 2441 identifiers and other information about the peer device (see 2442 Table 6). While the information refers to the peer device and not 2443 directly to the user, it can leak information about the user to the 2444 access network and to outside observers. The ServerInfo, on the 2445 other hand, can leak information about the peer's affiliation with 2446 the home network. For this reason, the optional PeerInfo and 2447 ServerInfo in the Reconnect Exchange SHOULD be omitted unless some 2448 critical data has changed and it cannot be updated on the application 2449 layer. 2451 Peer devices that randomize their layer-2 address to prevent tracking 2452 can do this whenever the user resets the EAP-NOOB association. 2453 During the lifetime of the association, the PeerId is a unique 2454 identifier that can be used to track the peer in the access network. 2455 Later versions of this specification may consider updating the PeerId 2456 at each Reconnect Exchange. In that case, it is necessary to 2457 consider how the authenticator and access-network administrators can 2458 recognize and add misbehaving peer devices to a deny list, as well 2459 as, how to avoid loss of synchronization between the server and the 2460 peer if messages are lost during the identifier update. 2462 To enable stronger identity protection in later versions of EAP-NOOB, 2463 the optional server-assigned NAI (NewNAI) SHOULD have a constant 2464 username part. The RECOMMENDED username is "noob". The server MAY, 2465 however, send a different username in NewNAI to avoid username 2466 collisions within its realm or to conform to a local policy on 2467 usernames. 2469 7.11. EAP security claims 2471 EAP security claims are defined in section 7.2.1 of [RFC3748]. The 2472 security claims for EAP-NOOB are listed in Table 13. 2474 +-----------------+-------------------------------------------------+ 2475 | Security | EAP-NOOB claim | 2476 | property | | 2477 +-----------------+-------------------------------------------------+ 2478 | Authentication | ECDHE key exchange with out-of-band | 2479 | mechanism | authentication | 2480 | | | 2481 | Protected | yes | 2482 | cryptosuite | | 2483 | negotiation | | 2484 | | | 2485 | Mutual | yes | 2486 | authentication | | 2487 | | | 2488 | Integrity | yes | 2489 | protection | | 2490 | | | 2491 | Replay | yes | 2492 | protection | | 2493 | | | 2494 | Confidentiality | no | 2495 | | | 2496 | Key derivation | yes | 2497 | | | 2498 | Key strength | The specified cryptosuites provide key strength | 2499 | | of at least 128 bits. | 2500 | | | 2501 | Dictionary | yes | 2502 | attack | | 2503 | protection | | 2504 | | | 2505 | Fast reconnect | yes | 2506 | | | 2507 | Cryptographic | not applicable | 2508 | binding | | 2509 | | | 2510 | Session | yes | 2511 | independence | | 2512 | | | 2513 | Fragmentation | no | 2514 | | | 2515 | Channel binding | yes (The ServerInfo and PeerInfo can be used to | 2516 | | convey integrity-protected channel properties | 2517 | | such as network SSID or peer MAC address.) | 2518 +-----------------+-------------------------------------------------+ 2520 Table 13: EAP security claims 2522 8. References 2524 8.1. Normative references 2526 [EUI-48] Institute of Electrical and Electronics Engineers, 2527 "802-2014 IEEE Standard for Local and Metropolitan Area 2528 Networks: Overview and Architecture.", IEEE Standard 2529 802-2014. , June 2014. 2531 [FIPS186-4] 2532 National Institute of Standards and Technology, "Digital 2533 Signature Standard (DSS)", FIPS 186-4 , July 2013. 2535 [NIST-DH] Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R. 2536 Davis, "Recommendation for Pair-Wise Key Establishment 2537 Schemes Using Discrete Logarithm Cryptography", NIST 2538 Special Publication 800-56A Revision 3 , April 2018, 2539 . 2542 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 2543 Hashing for Message Authentication", RFC 2104, 2544 DOI 10.17487/RFC2104, February 1997, 2545 . 2547 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2548 Requirement Levels", BCP 14, RFC 2119, 2549 DOI 10.17487/RFC2119, March 1997, 2550 . 2552 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 2553 Levkowetz, Ed., "Extensible Authentication Protocol 2554 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 2555 . 2557 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 2558 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 2559 . 2561 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 2562 Authentication Protocol (EAP) Key Management Framework", 2563 RFC 5247, DOI 10.17487/RFC5247, August 2008, 2564 . 2566 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 2567 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 2568 DOI 10.17487/RFC6234, May 2011, 2569 . 2571 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 2572 DOI 10.17487/RFC7517, May 2015, 2573 . 2575 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 2576 DOI 10.17487/RFC7518, May 2015, 2577 . 2579 [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, 2580 DOI 10.17487/RFC7542, May 2015, 2581 . 2583 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 2584 for Security", RFC 7748, DOI 10.17487/RFC7748, January 2585 2016, . 2587 [RFC8037] Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman (ECDH) 2588 and Signatures in JSON Object Signing and Encryption 2589 (JOSE)", RFC 8037, DOI 10.17487/RFC8037, January 2017, 2590 . 2592 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2593 Writing an IANA Considerations Section in RFCs", BCP 26, 2594 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2595 . 2597 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2598 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2599 May 2017, . 2601 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 2602 Interchange Format", STD 90, RFC 8259, 2603 DOI 10.17487/RFC8259, December 2017, 2604 . 2606 8.2. Informative references 2608 [BluetoothPairing] 2609 Bluetooth, SIG, "Simple pairing whitepaper", Technical 2610 report , 2007. 2612 [I-D.ietf-rats-eat] 2613 Mandyam, G., Lundblade, L., Ballesteros, M., and J. 2614 O'Donoghue, "The Entity Attestation Token (EAT)", draft- 2615 ietf-rats-eat-10 (work in progress), June 2021. 2617 [I-D.tschofenig-tls-cwt] 2618 Tschofenig, H. and M. Brossard, "Using CBOR Web Tokens 2619 (CWTs) in Transport Layer Security (TLS) and Datagram 2620 Transport Layer Security (DTLS)", draft-tschofenig-tls- 2621 cwt-02 (work in progress), July 2020. 2623 [IEEE-802.1X] 2624 Institute of Electrical and Electronics Engineers, "Local 2625 and Metropolitan Area Networks: Port-Based Network Access 2626 Control", IEEE Standard 802.1X-2004. , December 2004. 2628 [mcrl2] Groote, J. and M. Mousavi, "Modeling and analysis of 2629 communicating systems", The MIT press , 2014, 2630 . 2633 [noob-mcrl2] 2634 Peltonen, A., "mCRL2 model of EAP-NOOB", 2021, 2635 . 2638 [noob-proverif] 2639 Peltonen, A., "ProVerif model of EAP-NOOB", 2021, 2640 . 2643 [proverif] 2644 Blanchet, B., Smyth, B., Cheval, V., and M. Sylvestre, 2645 "ProVerif 2.00: Automatic Cryptographic Protocol Verifier, 2646 User Manual and Tutorial", The MIT press , 2018, 2647 . 2650 [RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., 2651 Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and 2652 D. Spence, "AAA Authorization Framework", RFC 2904, 2653 DOI 10.17487/RFC2904, August 2000, 2654 . 2656 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2657 Resource Identifier (URI): Generic Syntax", STD 66, 2658 RFC 3986, DOI 10.17487/RFC3986, January 2005, 2659 . 2661 [RFC4137] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba, 2662 "State Machines for Extensible Authentication Protocol 2663 (EAP) Peer and Authenticator", RFC 4137, 2664 DOI 10.17487/RFC4137, August 2005, 2665 . 2667 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 2668 Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, 2669 . 2671 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 2672 Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, 2673 March 2008, . 2675 [RFC6677] Hartman, S., Ed., Clancy, T., and K. Hoeper, "Channel- 2676 Binding Support for Extensible Authentication Protocol 2677 (EAP) Methods", RFC 6677, DOI 10.17487/RFC6677, July 2012, 2678 . 2680 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 2681 Code: The Implementation Status Section", BCP 205, 2682 RFC 7942, DOI 10.17487/RFC7942, July 2016, 2683 . 2685 [Sethi14] Sethi, M., Oat, E., Di Francesco, M., and T. Aura, "Secure 2686 Bootstrapping of Cloud-Managed Ubiquitous Displays", 2687 Proceedings of ACM International Joint Conference on 2688 Pervasive and Ubiquitous Computing (UbiComp 2014), pp. 2689 739-750, Seattle, USA , September 2014, 2690 . 2692 [Sethi19] Sethi, M., Peltonen, A., and T. Aura, "Misbinding Attacks 2693 on Secure Device Pairing", 2019, 2694 . 2696 Appendix A. Exchanges and events per state 2698 Figure 11 shows how the EAP server chooses the exchange type 2699 depending on the server and peer states. In the state combinations 2700 marked with hyphen "-", there is no possible exchange and user action 2701 is required to make progress. Note that peer state 4 is omitted from 2702 the table because the peer never connects to the server when the peer 2703 is in that state. The table also shows the handling of errors in 2704 each exchange. A notable detail is that the recipient of error code 2705 2003 moves to state 1. 2707 +--------+---------------------------+------------------------------+ 2708 | peer | exchange chosen by | next peer and | 2709 | states | server | server states | 2710 +========+===========================+==============================+ 2711 | server state: Unregistered (0) | 2712 +--------+---------------------------+------------------------------+ 2713 | 0..2 | Initial Exchange | both 1 (0 on error) | 2714 | 3 | - | no change, notify user | 2715 +--------+---------------------------+------------------------------+ 2716 | server state: Waiting for OOB (1) | 2717 +--------+---------------------------+------------------------------+ 2718 | 0 | Initial Exchange | both 1 (0 on error) | 2719 | 1 | Waiting Exchange | both 1 (no change on error) | 2720 | 2 | Completion Exchange | both 4 (A) | 2721 | 3 | - | no change, notify user | 2722 +--------+---------------------------+------------------------------+ 2723 | server state: OOB Received (2) | 2724 +--------+---------------------------+------------------------------+ 2725 | 0 | Initial Exchange | both 1 (0 on error) | 2726 | 1 | Completion Exchange | both 4 (B) | 2727 | 2 | Completion Exchange | both 4 (A) | 2728 | 3 | - | no change, notify user | 2729 +--------+---------------------------+------------------------------+ 2730 | server state: Reconnecting (3) or Registered (4) | 2731 +--------+---------------------------+------------------------------+ 2732 | 0..2 | - | no change, notify user | 2733 | 3 | Reconnect Exchange | both 4 (3 on error) | 2734 +--------+---------------------------+------------------------------+ 2735 (A) peer to 1 on error 2003, no other changes on error 2736 (B) server to 1 on error 2003, no other changes on error 2738 Figure 11: How server chooses the exchange type 2740 Figure 12 lists the local events that can take place in the server or 2741 peer. Both the server and peer output and accept OOB messages in 2742 association state 1, leading the receiver to state 2. Communication 2743 errors and timeouts in states 0..2 lead back to state 0, while 2744 similar errors in states 3..4 lead to state 3. Application request 2745 for rekeying (e.g., to refresh session keys or to upgrade 2746 cryptosuite) also takes the association from state 3..4 to state 3. 2747 User can always reset the association state to 0. Recovering 2748 association data, e.g., from a backup, leads to state 3. 2750 +--------+----------------------------------+--------------------+ 2751 | server/| possible local events | next state | 2752 | peer | on server and peer | | 2753 | state | | | 2754 +========+==================================+====================+ 2755 | 1 | OOB Output | 1 | 2756 | 1 | OOB Input | 2 (1 on error) | 2757 | 0..2 | Mobility/timeout/network failure | 0 | 2758 | 3..4 | Mobility/timeout/network failure | 3 | 2759 | 3..4 | Rekeying request | 3 | 2760 | 0..4 | User resets association | 0 | 2761 | 0..4 | Association state recovery | 3 | 2762 +--------+----------------------------------+--------------------+ 2764 Figure 12: Local events on server and peer 2766 Appendix B. Application-specific parameters 2768 Table 14 lists OOB channel parameters that need to be specified in 2769 each application that makes use of EAP-NOOB. The list is not 2770 exhaustive and is included for the convenience of implementers only. 2772 +--------------------+----------------------------------------------+ 2773 | Parameter | Description | 2774 +--------------------+----------------------------------------------+ 2775 | OobDirs | Allowed directions of the OOB channel | 2776 | | | 2777 | OobMessageEncoding | How the OOB message data fields are encoded | 2778 | | for the OOB channel | 2779 | | | 2780 | SleepTimeDefault | Default minimum time in seconds that the | 2781 | | peer should sleep before the next Waiting | 2782 | | Exchange | 2783 | | | 2784 | OobRetries | Number of received OOB messages with invalid | 2785 | | Hoob after which the receiver moves to | 2786 | | Unregistered (0) state. When the OOB channel | 2787 | | has error detection or correction, the | 2788 | | RECOMMENDED value is 5. | 2789 | | | 2790 | NoobTimeout | How many seconds the sender of the OOB | 2791 | | message remembers the sent Noob value. The | 2792 | | RECOMMENDED value is 3600 seconds. | 2793 | | | 2794 | ServerInfoType | The value of the Type field and the other | 2795 | | required fields in ServerInfo | 2796 | | | 2797 | PeerInfoType | The value of the Type field and the other | 2798 | | required fields in PeerInfo | 2799 +--------------------+----------------------------------------------+ 2801 Table 14: OOB channel characteristics 2803 Appendix C. EAP-NOOB roaming 2805 AAA architectures [RFC2904] allow for roaming of network-connected 2806 appliances that are authenticated over EAP. While the peer is 2807 roaming in a visited network, authentication still takes place 2808 between the peer and an authentication server at its home network. 2809 EAP-NOOB supports such roaming by allowing the server to assign a NAI 2810 to the peer. After the NAI has been assigned, it enables the visited 2811 network to route the EAP session to the peer's home AAA server. 2813 A peer device that is new or has gone through a hard reset should be 2814 connected first to the home network and establish an EAP-NOOB 2815 association with its home AAA server before it is able to roam. 2816 After that, it can perform the Reconnect Exchange from the visited 2817 network. 2819 Alternatively, the device may provide some method for the user to 2820 configure the NAI of the home network. This is the user or 2821 application configured NAI mentioned in Section 3.3.1. In that case, 2822 the EAP-NOOB association can be created while roaming. The 2823 configured NAI enables the EAP messages to be routed correctly to the 2824 home AAA server. 2826 While roaming, the device needs to identify the networks where the 2827 EAP-NOOB association can be used to gain network access. For 802.11 2828 access networks, the server MAY send a list of SSID strings in the 2829 ServerInfo field called either SSIDList or Base64SSIDList. The list 2830 is formatted as explained in Table 6. If present, the peer MAY use 2831 this list as a hint to determine the networks where the EAP-NOOB 2832 association can be used for access authorization, in addition to the 2833 access network where the Initial Exchange took place. 2835 Appendix D. OOB message as URL 2837 While EAP-NOOB does not mandate any particular OOB communication 2838 channel, typical OOB channels include graphical displays and emulated 2839 NFC tags. In the peer-to-server direction, it may be convenient to 2840 encode the OOB message as a URL, which is then encoded as a QR code 2841 for displays and printers or as an NDEF record for dynamic NFC tags. 2842 A user can then simply scan the QR code or NFC tag and open the URL, 2843 which causes the OOB message to be delivered to the authentication 2844 server. The URL MUST specify https or another server-authenticated 2845 scheme, so that there is a secure connection to the server and the 2846 on-path attacker cannot read or modify the OOB message. 2848 The ServerInfo in this case includes a field called ServerURL of the 2849 following format with RECOMMENDED length of at most 60 characters: 2851 https://[:]/[] 2853 To this, the peer appends the OOB message fields (PeerId, Noob, Hoob) 2854 as a query string. PeerId is provided to the peer by the server and 2855 might be a 22-character ASCII string. The peer base64url encodes, 2856 without padding, the 16-byte values Noob and Hoob into 22-character 2857 ASCII strings. The query parameters MAY be in any order. The 2858 resulting URL is of the following format: 2860 https://[:]/[]?P=&N=&H= 2862 The following is an example of a well-formed URL encoding the OOB 2863 message (without line breaks): 2865 https://aaa.example.com/eapnoob?P=mcm5BSCDZ45cYPlAr1ghNw&N=rMinS0-F4E 2866 fCU8D9ljxX_A&H=QvnMp4UGxuQVFaXPW_14UW 2868 Appendix E. Version history 2870 o Version 01: 2872 * Fixed Reconnection Exchange. 2874 * URL examples. 2876 * Message examples. 2878 * Improved state transition (event) tables. 2880 o Version 02: 2882 * Reworked the rekeying and key derivation. 2884 * Increased internal key lengths and in-band nonce and HMAC 2885 lengths to 32 bytes. 2887 * Less data in the persistent EAP-NOOB association. 2889 * Updated reference [NIST-DH] to Revision 2 (2013). 2891 * Shorter suggested PeerId format. 2893 * Optimized the example of encoding OOB message as URL. 2895 * NoobId in Completion Exchange to differentiate between multiple 2896 valid Noob values. 2898 * List of application-specific parameters in appendix. 2900 * Clarified the equivalence of Unregistered state and no state. 2902 * Peer SHOULD probe the server regardless of the OOB channel 2903 direction. 2905 * Added new error messages. 2907 * Realm is part of the persistent association and can be updated. 2909 * Clarified error handling. 2911 * Updated message examples. 2913 * Explained roaming in appendix. 2915 * More accurate definition of timeout for the Noob nonce. 2917 * Additions to security considerations. 2919 o Version 03: 2921 * Clarified reasons for going to Reconnecting state. 2923 * Included Verp in persistent state. 2925 * Added appendix on suggested ServerInfo and PeerInfo fields. 2927 * Exporting PeerId and SessionId. 2929 * Explicitly specified next state after OOB Step. 2931 * Clarified the processing of an expired OOB message and 2932 unrecognized NoobId. 2934 * Enabled protocol version upgrade in Reconnect Exchange. 2936 * Explained handling of redundant received OOB messages. 2938 * Clarified where raw and base64url encoded values are used. 2940 * Cryptosuite must specify the detailed format of the JWK object. 2942 * Base64url encoding in JSON strings is done without padding. 2944 * Simplified explanation of PeerId, Realm and NAI. 2946 * Added error codes for private and experimental use. 2948 * Updated the security considerations. 2950 o Version 04: 2952 * Recovery from synchronization failure due to lost last 2953 response. 2955 o Version 05: 2957 * Kz identifier added to help recovery from lost last messages. 2959 * Error message codes changed for better structure. 2961 * Improved security considerations section. 2963 o Version 06: 2965 * Kz identifier removed to enable PeerId anonymization in the 2966 future. 2968 * Clarified text on when to use server-assigned realm. 2970 * Send PeerId and PeerState in a separate request-response pair, 2971 not in NAI. 2973 * New subsection for the common handshake in all exchanges to 2974 avoid repetition. 2976 o Version 07: 2978 * Updated example messages. 2980 * Added pointers to new implementation in Contiki. 2982 o Version 08: 2984 * Editorial improvements and corrections. 2986 o WG Version 00: 2988 * Editorial improvements and corrections. 2990 * Updated reference [NIST-DH] to Revision 3 (2018). 2992 o WG Version 01: 2994 * Add NIST P-256 as Cryptosuite 2. 2996 * Renumber message types. 2998 * Very minor editorial fixes. 3000 o WG Version 02: 3002 * Updated message examples with all KeyingModes. 3004 * Many editorial fixes and other updates based on the IoT 3005 directorate review of Dave Thaler. 3007 * Text on cloning attacks based on review by Hannes Tschofenig. 3009 o WG Version 03: 3011 * Changed server-assigned Realm to server-assigned NAI to avoid 3012 username collisions. This issue was identified in a review by 3013 Alan Dekok. 3015 * Minor editorial improvements. 3017 o WG Version 04: 3019 * Use of more inclusive language. 3021 * Minor changes to IANA registration policies. 3023 * Explain how relative strength of cryptosuites is determined. 3025 * Improvements based on AD review from Roman Danyliw and shepherd 3026 review from Joseph Salowey. 3028 o WG Version 05: 3030 * Many text clarifications based on IESG evaluation. 3032 * Security considerations subsections on success indications, 3033 channel binding, and denial of service. 3035 * Privacy considerations gathered to a separate section. 3037 o WG Version 06: 3039 * Remove leftover text in section on identifying correct 3040 endpoints. 3042 * Example messages removed. 3044 Appendix F. Acknowledgments 3046 Max Crone, Shiva Prasad TP, and Raghavendra MS implemented parts of 3047 this protocol with wpa_supplicant and hostapd. Eduardo Ingles (RFC 3048 editor: please add an accented e in Ingles) and Dan Garcia-Carrillo 3049 were involved in the implementation of this protocol on Contiki. 3050 Their inputs helped us in improving the specification. 3052 The authors would like to thank Rhys Smith and Josh Howlett for 3053 providing valuable feedback as well as new use cases and requirements 3054 for the protocol. Thanks to Eric Rescorla, Alan Dekok, Darshak 3055 Thakore, Stefan Winter, Hannes Tschofenig, Daniel Migault, Roman 3056 Danyliw, Benjamin Kaduk, Francesca Palombini, Steve Hanna, Lars 3057 Eggert, and Eric Vyncke for their comments and reviews. 3059 We would also like to express our sincere gratitude to Dave Thaler 3060 for his thorough review of the document. 3062 Authors' Addresses 3064 Tuomas Aura 3065 Aalto University 3066 Aalto 00076 3067 Finland 3069 EMail: tuomas.aura@aalto.fi 3071 Mohit Sethi 3072 Ericsson 3073 Jorvas 02420 3074 Finland 3076 EMail: mohit@piuha.net 3078 Aleksi Peltonen 3079 Aalto University 3080 Aalto 00076 3081 Finland 3083 EMail: aleksi.peltonen@aalto.fi