idnits 2.17.1 draft-aura-eap-noob-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 4, 2016) is 2850 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST-DH' ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Downref: Normative reference to an Informational RFC: RFC 6234 ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) ** Downref: Normative reference to an Informational RFC: RFC 7748 Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Aura 3 Internet-Draft Aalto University 4 Intended status: Standards Track M. Sethi 5 Expires: January 5, 2017 Ericsson 6 July 4, 2016 8 Nimble out-of-band authentication for EAP (EAP-NOOB) 9 draft-aura-eap-noob-01 11 Abstract 13 Extensible Authentication Protocol (EAP) provides support for 14 multiple authentication methods. This document defines the EAP-NOOB 15 authentication method for nimble out-of-band (OOB) authentication and 16 key derivation. This EAP method is intended for bootstrapping all 17 kinds of Internet-of-Things (IoT) devices that have a minimal user 18 interface and no pre-configured authentication credentials. The 19 method makes use of a user-assisted one-directional OOB channel 20 between the peer device and authentication server. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 5, 2017. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. EAP-NOOB protocol . . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. Protocol overview . . . . . . . . . . . . . . . . . . . . 4 60 3.2. Protocol messages and sequences . . . . . . . . . . . . . 7 61 3.2.1. Initial Exchange . . . . . . . . . . . . . . . . . . 7 62 3.2.2. OOB Step . . . . . . . . . . . . . . . . . . . . . . 9 63 3.2.3. Completion Exchange . . . . . . . . . . . . . . . . . 9 64 3.2.4. Waiting Exchange . . . . . . . . . . . . . . . . . . 11 65 3.3. Message data items . . . . . . . . . . . . . . . . . . . 11 66 3.4. Fast reconnect and rekeying . . . . . . . . . . . . . . . 16 67 3.4.1. Reconnect Exchange . . . . . . . . . . . . . . . . . 16 68 3.4.2. User reset . . . . . . . . . . . . . . . . . . . . . 18 69 3.5. Key derivation . . . . . . . . . . . . . . . . . . . . . 19 70 3.6. Error handling . . . . . . . . . . . . . . . . . . . . . 21 71 3.6.1. Invalid messages . . . . . . . . . . . . . . . . . . 21 72 3.6.2. Unwanted peer . . . . . . . . . . . . . . . . . . . . 22 73 3.6.3. State mismatch . . . . . . . . . . . . . . . . . . . 22 74 3.6.4. Negotiation failure . . . . . . . . . . . . . . . . . 22 75 3.6.5. Cryptographic verification failure . . . . . . . . . 22 76 3.7. EAP-NOOB Roaming . . . . . . . . . . . . . . . . . . . . 23 77 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 78 4.1. Cryptosuites . . . . . . . . . . . . . . . . . . . . . . 23 79 4.2. Error codes . . . . . . . . . . . . . . . . . . . . . . . 24 80 4.3. Domain name reservation considerations . . . . . . . . . 24 81 5. Security considerations . . . . . . . . . . . . . . . . . . . 25 82 5.1. Authentication principle . . . . . . . . . . . . . . . . 25 83 5.2. Identifying and naming peer devices . . . . . . . . . . . 27 84 5.3. Downgrading threats . . . . . . . . . . . . . . . . . . . 28 85 5.4. EAP security claims . . . . . . . . . . . . . . . . . . . 29 86 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 87 6.1. Normative references . . . . . . . . . . . . . . . . . . 30 88 6.2. Informative references . . . . . . . . . . . . . . . . . 31 89 Appendix A. Exchanges and events per state . . . . . . . . . . . 32 90 Appendix B. QR code as an OOB . . . . . . . . . . . . . . . . . 33 91 Appendix C. Example messages . . . . . . . . . . . . . . . . . . 34 92 Appendix D. TODO list . . . . . . . . . . . . . . . . . . . . . 35 93 Appendix E. Version tracking . . . . . . . . . . . . . . . . . . 36 95 1. Introduction 96 This document describes a method for registration, authentication and 97 key derivation for network-connected ubiquitous computing devices, 98 such as consumer and enterprise appliances that are part of the 99 Internet of Things (IoT). These devices may be off-the-shelf 100 hardware that is sold and distributed without any prior registration 101 or credential-provisioning process. Thus, the device registration in 102 a server database, ownership of the device, and the authentication 103 credentials for both network access and application-level security 104 must all be established at the time of the device deployment. 105 Furthermore, many such devices have only limited user interfaces that 106 could be used for their configuration. Often, the interfaces are 107 limited to either only input (e.g. camera) or output (e.g. display 108 screen). The device configuration is made more challenging by the 109 fact that the devices may exist in large numbers or may have to be 110 deployed or re-configured nimbly based on user needs. 112 More specifically, the devices may have the following 113 characteristics: 115 o no pre-established relation with a specific server or user, 117 o no pre-provisioned device identifier or authentication 118 credentials, 120 o limited user interface and configuration capabilities. 122 Many proprietary OOB configuration methods exits for specific IoT 123 devices. The goal of this specification is to provide an open 124 standard and a generic protocol for bootstrapping the security of 125 network-connected appliances, such as displays, printers, speaker, 126 and cameras. The security bootstrapping in this specification makes 127 use of a user-assisted out-of-band (OOB) channel. The security is 128 based on the assumption that attackers are not able to observe or 129 modify the messages conveyed through the OOB channel. We follow the 130 common approach of performing a Diffie-Hellman key exchange over the 131 insecure network and authenticating the established key with the help 132 of the OOB channel in order to prevent man-in-the-middle (MitM) 133 attacks. 135 The solution presented here is intended for devices that have either 136 an input or output interface, such as a camera or display screen, 137 which is able to send or receive dynamically generated messages of 138 tens of bytes in length. Naturally, this solution may not be 139 appropriate for very small sensors or actuators that have no user 140 interface at all. We also assume that the OOB channel is at least 141 partly automated (e.g. camera scanning a bar code) and, thus, there 142 is no need to absolutely minimize the length of the data transferred 143 through the OOB channel. This differs, for example, from Bluetooth 144 simple pairing [SimplePairing], where it is critical to minimize the 145 length of the manually transferred or compared codes. Since the OOB 146 messages are dynamically generated, we do not support static printed 147 registration codes. This also prevents attacks where a static secret 148 code would be leaked. 150 2. Terminology 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in [RFC2119]. 156 In addition, this document frequently uses the following terms as 157 they have been defined in [RFC5216]: 159 authenticator The entity initiating EAP authentication. 161 peer The entity that responds to the authenticator. In 162 [IEEE-802.1X], this entity is known as the Supplicant. 164 server The entity that terminates the EAP authentication method with 165 the peer. In the case where no backend authentication server 166 is used, the EAP server is part of the authenticator. In the 167 case where the authenticator operates in pass-through mode, the 168 EAP server is located on the backend authentication server. 170 3. EAP-NOOB protocol 172 This section defines the EAP-NOOB protocol. The protocol is a 173 generalized version of the original idea presented by Sethi et al. 174 [Sethi14]. 176 3.1. Protocol overview 178 One EAP-NOOB protocol execution spans multiple EAP exchanges. This 179 is necessary to leave time for the OOB message to be delivered, as 180 will be explained below. 182 The overall protocol starts with the Initial Exchange, in which the 183 server allocates an identifier to the peer, and the server and peer 184 negotiate the protocol version and cryptosuite (i.e. cryptographic 185 algorithm suite), exchange nonces and perform an Elliptic Curve 186 Diffie-Hellman (ECDH) key exchange. The user-assisted OOB Step then 187 takes place. This step involves only one out-of-band message either 188 from the peer to the server or from the server to the peer. While 189 waiting for the OOB Step action, the peer MAY probe the server by 190 reconnecting to it with EAP-NOOB. If the OOB Step has already taken 191 place, the probe leads to the Completion Exchange, which completes 192 the mutual authentication and key confirmation. On the other hand, 193 if the OOB Step has not yet taken place, the probe leads to the 194 Waiting Exchange, and the peer will perform another probe after a 195 server-defined minimum waiting time. The Initial Exchange and 196 Waiting Exchange always end in EAP-Failure, while the Completion 197 Exchange may result in EAP-Success. Once the peer and server have 198 performed a successful Completion Exchange, both parties store the 199 created association in persistent storage, and the OOB Step is not 200 repeated. Thereafter, creation of new temporal keys, ECDH rekeying, 201 and updates of cryptographic algorithms can be achieved with the 202 Reconnect Exchange. 204 OOB Output, Initial Exchange, 205 or Waiting Exchange 206 .-----. 207 | v 208 .------------------. Initial .------------------. 209 | | Exchange | | 210 .->| 0. Unregistered |---------------->|1. Waiting for OOB| 211 | | | | | 212 | '------------------' '------------------' 213 | | | ^ 214 User Reset Completion | | | 215 | Exchange | OOB Initial 216 |<-------. .<------------------------' Input Exchange 217 | | | | | 218 | | v v | 219 | .------------------. Completion .------------------. 220 | | | Exchange | | 221 | | 4. Registered |<----------------| 2. OOB Received | 222 | | | | | 223 | '------------------' '------------------' 224 | | ^ 225 | | | 226 | Timeout / Reconnect 227 | Failure Exchange 228 | | | 229 | v | 230 | .-----------------. 231 | | | 232 '--| 3. Reconnecting | 233 | | 234 '-----------------' 236 Figure 1: EAP-NOOB server-peer association state machine 238 Figure 1 shows the association state machine, which is the same for 239 the server and for the peer. When the client initiates the EAP-NOOB 240 method, the server chooses the ensuing message exchange based on the 241 combination of the server and peer states. The EAP server and peer 242 are initially in the Unregistered state, in which no state 243 information needs to be stored. Before a successful Completion 244 Exchange, the server-peer association state is ephemeral in both the 245 server and peer (ephemeral states 0..2) , and either party may cause 246 the protocol to fall back to the Initial Exchange. After the 247 Completion Exchange has resulted in EAP-Success, the association 248 state becomes persistent (persistent states 3..4), and only user 249 reset or accidental failure can cause the return of the server or the 250 peer to the ephemeral states and to the Initial Exchange. 252 The server MUST NOT repeat the OOB Step with the same peer except if 253 the association with the peer is explicitly reset by the user or lost 254 due to failure of the persistent storage. In particular, once the 255 association has entered the Registered state, the server MUST NOT 256 delete the association or go back to states 0-2 without explicit user 257 approval. Similarly, the peer MUST NOT repeat the OOB Step unless 258 the user explicitly deletes the association with the server or resets 259 it to the Unregistered state. However, it can happen that the client 260 accidentally loses its persistent state and reconnects to the server 261 without a previously allocated peer identifier. In that case, the 262 server MUST treat the peer as a new peer. The server MAY use 263 auxiliary information, such as the PeerInfo field received in the 264 Initial Exchange, to detect such multiple association of the same 265 peer. However, it MUST NOT automatically delete associations because 266 there is no secure way of verifying that the two peers are the same 267 physical device. 269 A special feature of the EAP-NOOB method is that the server is not 270 assumed to have any a-priori knowledge of the peer. Therefore, the 271 peer initially uses the generic identity string "noob@eap-noob.net" 272 as the NAI. The server then allocates a server-specific identifier 273 to the peer. The network access identifier NAI is a concatenation of 274 the server-allocated peer identifier and the generic suffix "@eap- 275 noob.net". This suffix serves two purposes: firstly, it tells the 276 server that the peer supports and expects the EAP-NOOB method and, 277 secondly, it allows routing of the EAP-NOOB sessions to a specific 278 authentication server in the AAA architecture. 280 EAP-NOOB is an unusual EAP method in that the peer has to connect to 281 the server two or more times before it can receive EAP-Success. The 282 reason is that, while EAP allows delays between the request-response 283 pairs, e.g. for repeated password entry, the user delays in OOB 284 authentication can be much longer than in password trials. In 285 particular, EAP-NOOB supports also peers or servers with no input 286 capability in the user interface. Since these output-only parties 287 cannot be told to perform the protocol at the right moment, they have 288 to perform the initial exchange opportunistically and hope for the 289 OOB Step to take place within a timeout period, which is why the 290 timeout needs to be several minutes rather than seconds. For 291 example, consider a printer (peer) from which the OOB message is 292 printed as a bar code on paper and then scanned with a camera phone 293 and communicated to the server. To support such devices and slow OOB 294 channels, the peer in EAP-NOOB first contacts the server in the 295 Initial Exchange, then disconnects for some time, and later continues 296 with the Waiting and Completion Exchanges. 298 3.2. Protocol messages and sequences 300 This section defines the EAP-NOOB exchanges. The protocol messages 301 communicated and the data members in each message are listed in the 302 diagrams below. 304 Each EAP-NOOB exchange begins with the authenticator sending an EAP- 305 Request/Identity packet to the peer. From this point on, the EAP 306 conversation occurs between the server and the peer, and the 307 authenticator acts as a pass-through device. The peer responds to 308 the authenticator with an EAP-Response/Identity packet, containing 309 the network access identifier (NAI). The peer MUST compose the NAI 310 as defined in Section 3.3. Essentially, if the peer has no previous 311 peer identifier (PeerId), it uses the fixed NAI string "noob@eap- 312 noob.net", and if it has received a PeerId from the server, it 313 creates the NAI by concatenating the PeerId, a state indicator "+sX", 314 and the fixed suffix string "@eap-noob.net". 316 After receiving the NAI, the server chooses the EAP-NOOB exchange, 317 i.e. the ensuing message sequence, based on the combination of the 318 client and server states. The client recognizes the exchange based 319 on the message type field (Type) of the EAP-NOOB request received 320 from the server. The available exchanges are defined in the 321 following subsections. Each exchange comprises one or two EAP 322 requests-response pairs and ends in either EAP-Failure, indicating 323 that authentication is not (yet) successful, or in EAP-Success. 325 3.2.1. Initial Exchange 327 Upon receiving the EAP-Response/Identity from the peer, if either the 328 peer or the server is in the Unregistered (0) state and the other is 329 in one of the ephemeral states (0..2), the server chooses the Initial 330 Exchange. 332 The Initial Exchange comprises two EAP-NOOB request-response pairs, 333 one for version, algorithm and parameter negotiation and the other 334 for the ECDH key exchange. The first EAP-NOOB request (Type=1) from 335 the server contains a newly allocated PeerId for the peer, regardless 336 of the username part of the received NAI. The server also sends in 337 the request a list of protocol versions supported (Vers), 338 cryptosuites (Cryptosuites), an indicator of the OOB channel 339 directions supported by the server (Dirs), and a ServerInfo object. 340 The peer chooses one of the versions and cryptosuites. The peer 341 sends a response (Type=1) with the selected protocol version (Verp), 342 the received PeerId, the selected cryptosuite (Cryptosuitep), an 343 indicator of the OOB channel directions supported by the peer (Dirp), 344 and a PeerInfo object. In the second EAP-NOOB request and response 345 (Type=2), the server and peer exchange the public components of their 346 ECDH keys and nonces (PKs,Ns,PKp,Np). The ECDH keys MUST be based on 347 the negotiated cryptosuite. The Initial Exchange ends with EAP- 348 Failure from the server because the authentication cannot yet be 349 completed. 351 EAP Peer EAP Server 352 | | 353 |<----------- EAP-Request/Identity -| | 354 | | 355 | | 356 |------------ EAP-Response/Identity -------------->| 357 | (NAI=noob|PeerId+sX@eap-noob.net) | 358 | | 359 | | 360 |<----------- EAP-Request/EAP-NOOB ----------------| 361 | (Type=1,Vers,PeerId,Cryptosuites,Dirs,ServerInfo)| 362 | | 363 | | 364 |------------ EAP-Response/EAP-NOOB -------------->| 365 | (Type=1,Verp,PeerId,Cryptosuitep,Dirp,PeerInfo) | 366 | | 367 | | 368 |<----------- EAP-Request/EAP-NOOB ----------------| 369 | (Type=2,PeerId,PKs,Ns) | 370 | | 371 | | 372 |------------ EAP-Response/EAP-NOOB -------------->| 373 | (Type=2,PeerId,PKp,Np) | 374 | | 375 | | 376 |<----------- EAP-Failure -------------------------| 377 | | 379 Figure 2: Initial Exchange 381 At the conclusion of the Initial Exchange, both the server and the 382 peer move to the Waiting for OOB (1) state. 384 3.2.2. OOB Step 386 The OOB Step, shown as OOB Output and OOB Input in Figure 1, takes 387 place after the Initial Exchange. Depending on the direction 388 negotiated, the peer or the server outputs the OOB message containing 389 the PeerId, the secret nonce Noob, and the cryptographic fingerprint 390 Hoob, as defined in Section 3.3. This message is then delivered to 391 the other party via a user-assisted OOB channel. The details of the 392 OOB channel are defined by the application. The receiver of the OOB 393 message MUST compare the received value of the fingerprint Hoob with 394 a value that it computes locally. 396 Even though not recommended (see Section 3.3), this specification 397 allows both directions to be negotiated. In this case, both sides 398 SHOULD output the OOB message, and it is up to the user to deliver 399 one of them. 401 EAP Peer EAP Server 402 | | 403 |=================OOB=============================>| 404 | (PeerId,Noob,Hoob) | 405 | | 407 Figure 3: OOB Step, from peer to EAP server 409 EAP Peer EAP Server 410 | | 411 |<================OOB==============================| 412 | (PeerId,Noob,Hoob) | 413 | | 415 Figure 4: OOB Step, from EAP server to peer 417 3.2.3. Completion Exchange 419 After the Initial Exchange, if both the server the peer support the 420 peer-to-server direction for the OOB channel, the peer SHOULD 421 initiate the EAP-NOOB method again after an applications-specific 422 waiting time in order to probe for completion of the OOB Step. Also, 423 if both sides support the server-to-peer direction of the OOB 424 exchange and the peer receives the OOB message, it SHOULD initiate 425 the EAP-NOOB method immediately. Once server receives the EAP- 426 Response/Identity, if one of the server and peer is in the OOB 427 Received (2) state and the other is in the Waiting for OOB (1) or OOB 428 Received (2) state, the OOB Step has taken place and the server 429 SHOULD continue with the Completion Exchange. 431 The Completion Exchange comprises one EAP-NOOB request-response pair 432 (Type=4). In these messages, the server and peer exchange message 433 authentication codes. Both sides MUST compute the keys Kms and Kmp 434 as defined in Section 3.5 and the message authentication codes MACs 435 and MACp as defined in Section 3.3. Both sides MUST compare the 436 received message authentication code with a locally computed value. 437 If the EAP server finds that it has received the correct value of 438 MACp, the Completion Exchange ends in EAP-Success; otherwise, in EAP- 439 Failure. 441 While it is not expected to occur in practice, poor user interface 442 design could lead to two OOB messages delivered simultaneously, one 443 from the peer to the server and the other from the server to the 444 peer. The server detects this event by observing that both the 445 server and peer are in the OOB Received state (2). In that case, the 446 server MUST behave as if only the server-to-peer message was 447 delivered. 449 After successful Completion Exchange, both the server and the peer 450 move to the Registered (4) state. 452 EAP Peer EAP Server 453 | | 454 |<----------- EAP-Request/Identity -| | 455 | | 456 | | 457 |------------ EAP-Response/Identity -------------->| 458 | (NAI=PeerId+sX@eap-noob.net) | 459 | | 460 | | 461 |<----------- EAP-Request/EAP-NOOB ----------------| 462 | (Type=4,PeerId,MACs) | 463 | | 464 | | 465 |------------ EAP-Response/EAP-NOOB -------------->| 466 | (Type=4,PeerId,MACp) | 467 | | 468 | | 469 |<----------- EAP-Success -------------------------| 470 | | 471 Figure 5: Completion Exchange 473 3.2.4. Waiting Exchange 475 As explained in Section 3.2.3, if both the server and the peer 476 support the peer-to-server direction for the OOB channel, the peer 477 will probe the server for completion of the OOB Step. If both the 478 server and client states are Waiting for OOB (1), the server will 479 continue with the Waiting Exchange (message Type=3). The only 480 purpose of this exchange is to indicate to the peer that the server 481 has not yet received a peer-to-server OOB message. 483 In order to limit the rate at which peers probe the server, the 484 server sends to the peer a minimum time to wait before probing the 485 server again. The peer MUST wait at least the server-specified 486 minimum waiting time in seconds (MinSleep) before initiating EAP 487 again with the same server. If the server omits the MinSleep field 488 from the request, the peer SHOULD wait for an application-specified 489 minimum time. 491 EAP Peer EAP Server 492 | | 493 |<----------- EAP-Request/Identity -| | 494 | | 495 | | 496 |------------ EAP-Response/Identity -------------->| 497 | (NAI=PeerId+s1@eap-noob.net) | 498 | | 499 | | 500 |<----------- EAP-Request/EAP-NOOB ----------------| 501 | (Type=3,PeerId,[MinSleep]) | 502 | | 503 | | 504 |------------ EAP-Response/EAP-NOOB -------------->| 505 | (Type=3,PeerId) | 506 | | 507 | | 508 |<----------- EAP-Failure -------------------------| 509 | | 511 Figure 6: Waiting Exchange 513 3.3. Message data items 514 Table 1 defines the data items in the protocol messages. The in-band 515 messages are formatted as JSON objects [RFC7159] in UTF-8 encoding. 516 The member names are in the left-hand column of table. 518 +---------------+---------------------------------------------------+ 519 | Data field | Description | 520 +---------------+---------------------------------------------------+ 521 | Vers,Verp | EAP-NOOB protocol versions supported by the EAP | 522 | | server, and the protocol version chosen by the | 523 | | peer. Vers is a JSON array of unsigned integers, | 524 | | and Verp is an unsigned integer. Currently, the | 525 | | only defined values are "[1]" and "1", | 526 | | respectively. | 527 | PeerId | Peer identifier. If the peer does not yet have a | 528 | | peer identifier or it does not remember one, it | 529 | | uses the NAI "noob@eap-noob.net" in the Initial | 530 | | Exchange. The server then assigns an identifier | 531 | | to the peer and sends it in the first server-to- | 532 | | peer request of the Initial Exchange. The | 533 | | assigned identifier is ephemeral until a | 534 | | successful Completion Exchange takes place. | 535 | | Thereafter, the peer identifier becomes permanent | 536 | | until the user resets the peer and the server. | 537 | | Resetting the server means deleting the | 538 | | association for the peer from the server | 539 | | database. The peer identifier MUST follow the | 540 | | syntax of the utf8-username specified in | 541 | | [RFC7542]; however, it MUST NOT exceed 60 bytes | 542 | | in length and MUST NOT contain the character '+'. | 543 | | The server MUST generate the identifiers in such | 544 | | a way that they do not repeat and cannot be | 545 | | guessed by the peer or third parties beforehand. | 546 | | One way to generate the identifiers is to choose | 547 | | a random 40-digit lower-case hexadecimal string. | 548 | | | 549 | Peer State | This part of the NAI informs the server about the | 550 | "+sX" | peer state. The server uses this information | 551 | | together with the server state to decide on the | 552 | | type of the exchange and, thus, of the type of | 553 | | the next EAP-Request. The peer appends the peer | 554 | | state to the PeerId to form the username part of | 555 | | the NAI. (Sending it in the EAP-Response/Identity | 556 | | message avoids an additional round trip for | 557 | | querying the peer state.) If the peer is in state | 558 | | 0, it MUST use the NAI "noob@eap-noob.net"; | 559 | | otherwise, the peer MUST create the NAI as the | 560 | | concatenation of the PeerId, the string "+s", a | 561 | | single digit indicating the state of the peer, | 562 | | and the string "@eap-noob.net". | 563 | | | 564 | Type | EAP-NOOB message type. The type is an integer in | 565 | | the range 0..6. EAP-NOOB requests and the | 566 | | corresponding responses share the same type | 567 | | value. | 568 | | | 569 | PKs, PKp | The public components of the ECDH keys of the | 570 | | server and peer. PKs and PKp are sent in the JSON | 571 | | Web Key (JWK) format [RFC7517]. | 572 | | | 573 | Cryptosuites, | The identifiers of cryptosuites supported by the | 574 | Cryptosuitep | server and of the cryptosuite selected by the | 575 | | peer. The format is specified in Section 4.1. | 576 | | | 577 | Dirs, Dirp | OOB channel directions supported by the server | 578 | | and the peer. The possible values are 1=peer-to- | 579 | | server, 2=server-to-peer, 3=both directions. | 580 | | Endpoints that are general-purpose computers or | 581 | | online services SHOULD support both directions. | 582 | | IoT devices with a limited user interface will | 583 | | mostly support only one direction. If the | 584 | | negotiated value is 3, the user may be presented | 585 | | with two OOB messages, one for each direction, | 586 | | even though the user needs to deliver only one of | 587 | | them. Since this can be confusing to the user, it | 588 | | RECOMMENDED that the peer selects value 1 or 2. | 589 | | The EAP-NOOB protocol itself is designed to cope | 590 | | also with selected value 3, in which case it uses | 591 | | the first delivered OOB message. In the unlikely | 592 | | case of simultaneously delivered OOB messages, | 593 | | the protocol prioritizes the server-to-peer | 594 | | direction. | 595 | | | 596 | Ns, Np | Nonces for the Initial Exchange. | 597 | | | 598 | ServerInfo | This field contains information about the server | 599 | | to be passed from the EAP method to the | 600 | | application layer in the peer. The content of | 601 | | this field is specific to the application. It | 602 | | could include, for example, the network name and | 603 | | server name or a Uniform Resource Locator (URL) | 604 | | [RFC4266] or some other information that helps | 605 | | the user to deliver the OOB message to the server | 606 | | through the out-of-band channel. | 607 | | | 608 | PeerInfo | This field contains information about the peer to | 609 | | be passed from the EAP method to the application | 610 | | layer in the server. The content of this field is | 611 | | specific to the application. It could include, | 612 | | for example, the peer make, model and serial | 613 | | number that helps the user to distinguish between | 614 | | devices and to deliver the OOB message to the | 615 | | correct peer through the out-of-band channel. | 616 | | | 617 | MinSleep | The number of seconds for which peer MUST NOT | 618 | | start a new execution of the EAP-NOOB method with | 619 | | the authenticator, unless the peer is reset by | 620 | | the user. The server can use this field to limit | 621 | | the rate at which peers probe it for the | 622 | | completion of the OOB Step. MinSleep is an | 623 | | unsigned integer in the range 0..3600. | 624 | | | 625 | Noob | Secret nonce sent through the OOB channel and | 626 | | used for the session key derivation. The party | 627 | | that received the OOB message uses this secret in | 628 | | the Completion Exchange to authenticate the | 629 | | exchanged key to the party that sent the OOB | 630 | | message. | 631 | | | 632 | Hoob | Cryptographic fingerprint (i.e. hash value) | 633 | | computed from all the parameters exchanged in the | 634 | | Initial Exchange and in the OOB message. | 635 | | Receiving this fingerprint over the OOB channel | 636 | | guarantees the integrity of the key exchange and | 637 | | parameter negotiation. Hence, it authenticates | 638 | | the exchanged key to the party that receives the | 639 | | OOB message. | 640 | | | 641 | Ns2, Np2 | Nonces for the Reconnect Exchange. | 642 | | | 643 | MACs, MACp | Message authentication codes for mutual | 644 | | authentication, key confirmation, and integrity | 645 | | check on the exchanged information. The input to | 646 | | the HMAC is defined below, and the key for the | 647 | | HMAC is defined in Section 3.5. | 648 | | | 649 | PKs2, PKp2 | The public components of the ECDH keys of the | 650 | | server and peer. These MUST be present if a new | 651 | | cryptosuite was negotiated. Otherwise, either | 652 | | party may omit the field. PKs2 and PKp2 are sent | 653 | | in the JSON Web Key (JWK) format [RFC7517]. | 654 | | | 655 | MACs2, MACp2 | Message authentication codes for mutual | 656 | | authentication, key confirmation, and integrity | 657 | | check on the Reconnect Exchange. The input to the | 658 | | HMAC is defined below, and the key for the HMAC | 659 | | is defined in Section 3.5. | 660 | | | 661 +---------------+---------------------------------------------------+ 663 Table 1: Message data items 665 All nonces (Ns, Np, Ns2, Np2, Noob) are 16-byte fresh random byte 666 strings generated by the party that sends the message. 668 The fingerprint Hoob is computed with the hash function specified in 669 the negotiated cryptosuite and truncated to the 16 leftmost bytes of 670 the output. The message authentication codes (MACs, MACp, MACs2, 671 MACp2) are computed with the HMAC function [RFC2104] based on the 672 same cryptographic hash function and truncated to the 16 leftmost 673 bytes of the output. 675 The inputs to the hash function for computing the fingerprint Hoob 676 and to the HMAC for computing MACs, MACp, MACs2 and MACp2 are JSON 677 arrays containing a fixed number (15) of members. The array member 678 values MUST be copied to the array verbatim from the in-band 679 messages, and space characters or whitespace MUST NOT be added 680 anywhere in the JSON structure. 682 The inputs for computing the fingerprint and message authentication 683 codes are the following: 685 Hoob = H(Dir,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,Cryptos 686 uitepp,Dirp,PeerInfo,PKs,Ns,PKp,Np,Noob). 688 MACs = HMAC(Kms; 2,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,C 689 ryptosuitep,Dirp,PeerInfo,PKs,Ns,PKp,Np,Noob). 691 MACp = HMAC(Kmp; 1,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,C 692 ryptosuitep,Dirp,PeerInfo,PKs,Ns,PKp,Np,Noob). 694 MACs2 = HMAC(Kms2; 2,Vers,Verp,PeerId,Cryptosuites,"",[ServerInfo] 695 ,Cryptosuitep,"",[PeerInfo],[PKs2],Ns2,[PKp2],Np2,"") 697 MACp2 = HMAC(Kmp2; 1,Vers,Verp,PeerId,Cryptosuites,"",[ServerInfo] 698 ,Cryptosuitep,"",[PeerInfo],[PKs2],Ns2,[PKp2],Np2,"") 700 Missing input values are represented by empty strings "" in the 701 array. The values indicated with "" are always empty strings. The 702 values in brackets MUST be included if they were exchanged in the 703 same Reconnect Exchange; otherwise these values are replaced by empty 704 strings "". 706 The parameter Dir indicates the direction in which the OOB message 707 containing the Noob value is being sent (1=peer-to-server, 2=server- 708 to-peer). This field in needed to prevent the user from accidentally 709 delivering the OOB message back to its originator in the rare cases 710 where both OOB directions have been negotiated. The keys for the 711 HMACs are defined in the following section. 713 The nonces (Ns, Np, Ns2, Np2) and message authentication codes (MACs, 714 MACp, MACs2, MACp2) in the in-band messages and in the cryptographic 715 function inputs MUST be base64url encoded [RFC4648]. The values Noob 716 and Hoob in the OOB channel MAY also be base64url encoded, if that is 717 appropriate for the application and the used OOB channel. 719 The ServerInfo and PeerInfo are JSON object with UFT-8 encoding. The 720 length of each encoded object as a byte arrays MUST NOT exceed 500 721 bytes. The format and semantics of these objects MUST be defined by 722 the application that uses the EAP-NOOB method. 724 3.4. Fast reconnect and rekeying 726 EAP-NOOB implements Fast Reconnect ([RFC3748], section 7.2.1) that 727 avoids repeated use of the user-assisted OOB channel. For this 728 reason, the EAP server and peer store the session state in persistent 729 memory after a successful Completion Exchange. This persistent data, 730 called "persistent EAP-NOOB association", MUST include at least the 731 following data: PeerId, negotiated cryptosuite, Kms, Kmp, and Kz. 732 The last three are shared keys used internally by EAP-NOOB for 733 rekeying in the Reconnect Exchange. When a persistent EAP-NOOB 734 association exists, the EAP server and peer are in the Registered 735 state (4) or Reconnecting state (3), as shown in Figure 1. 737 The rekeying and Reconnect Exchange may be needed for several 738 reasons. A timeout, software or hardware failure, or user action may 739 cause the EAP server, peer or authenticator to lose its non- 740 persistent state data such as master keys. Change in the supported 741 cryptosuites in the EAP server or peer may also cause the need for a 742 new key exchange. When the EAP server or peer detects such an event, 743 it MUST change from the Registered to Reconnecting state. The EAP- 744 NOOB method will then perform the Reconnect Exchange next time when 745 EAP is triggered. Thus, the difference between the Registered state 746 and Reconnecting state is that, in the Reconnecting state, some of 747 the non-persistent data related to the EAP-NOOB association between 748 the EAP server and peer may be lost or stale, and a new key exchange 749 is needed. 751 3.4.1. Reconnect Exchange 752 The server chooses the Reconnect Exchange when peer is in the 753 Reconnecting (3) state and the server itself is in the Registered (4) 754 or Reconnecting (3) state. The peer MUST NOT initiate EAP-NOOB when 755 the peer is in Registered state. 757 The Reconnect Exchange comprises three EAP-NOOB request-response 758 pairs, one for algorithm and parameter negotiation, another for the 759 nonce and key exchange, and the last one for exchanging message 760 authentication codes. In the first request and response (Type=5) the 761 server and peer negotiate a cryptosuite in the same way as in the 762 Initial Exchange. The messages MAY also contain PeerInfo and 763 ServerInfo objects. In the second request and response (Type=6), the 764 server and peer exchange the public components of ECDH keys and 765 nonces (PKs2,Ns2,PKp2,Np2). The server ECDH key MUST be fresh, i.e. 766 not previously used with the same peer, and the client ECDH key 767 SHOULD be fresh, i.e. not previously used. In the third and final 768 request and respone (Type=7), the server and peer exchange the 769 message authentication codes (MACs2,MACp2). Both sides MUST compute 770 the keys Kms2 and Kmp2 as defined in Section 3.5 and the message 771 authentication codes MACs2 and MACp2 as defined in Section 3.3. Both 772 sides MUST compare the received message authentication code with a 773 locally computed value. If the EAP server finds that it has received 774 the correct value of MACp, the Completion Exchange ends in EAP- 775 Success; otherwise, in EAP-Failure. 777 If the negotiated cryptosuite is the same as previously, the server 778 MAY refuse to perform a new ECDH exchange by omitting PKs2, and the 779 peer MAY refuse by omitting PKp2. If the server omits PKs2, it is 780 RECOMMENDED that the peer also omits PKp2, as it will not be used in 781 any case. When one or both public keys are not present, the new 782 master keys are derived from the fresh nonces and the previously 783 established shared key Kz, as defined in Section 3.5. The security 784 property lost by refusing the ECDH exchange is forward secrecy. 786 The server and client MAY send updated ServerInfo and PeerInfo 787 objects in the Reconnect Exchange. If there is no update to the 788 values, they SHOULD omit this information from the messages. 790 Both sides MUST compare the received message authentication code with 791 a locally computed value. If the EAP server finds that it has 792 received the correct value of MACp2, the Reconnect Exchange ends in 793 EAP-Success; otherwise, in EAP-Failure. 795 After successful Reconnect Exchange, both the server and the peer 796 move to the Registered (4) state. If a new ECHD key exchange was 797 performed, they also update the persistent EAP-NOOB association with 798 the changed values. 800 EAP Peer EAP Server 801 | | 802 |<----------- EAP-Request/Identity -| | 803 | | 804 | | 805 |------------ EAP-Response/Identity -------------->| 806 | (NAI=PeerId+s3@eap-noob.net) | 807 | | 808 | | 809 |<----------- EAP-Request/EAP-NOOB ----------------| 810 | (Type=5,PeerId,Cryptosuites,[ServerInfo]) | 811 | | 812 | | 813 |------------ EAP-Response/EAP-NOOB -------------->| 814 | (Type=5,PeerId,Cryptosuitep,[PeerInfo]) | 815 | | 816 | | 817 |<----------- EAP-Request/EAP-NOOB ----------------| 818 | (Type=6,PeerId,[PKs2,]Ns2) | 819 | | 820 | | 821 |------------ EAP-Response/EAP-NOOB -------------->| 822 | (Type=6,PeerId,[PKp2,]Np2) | 823 | | 824 | | 825 |<----------- EAP-Request/EAP-NOOB ----------------| 826 | (Type=7,PeerId,MACs2) | 827 | | 828 | | 829 |------------ EAP-Response/EAP-NOOB -------------->| 830 | (Type=7,PeerId,MACp2) | 831 | | 832 | | 833 |<----------- EAP-Success -------------------------| 834 | | 836 Figure 7: Reconnect Exchange 838 3.4.2. User reset 839 As shown in the association state machine in Figure 1, the only 840 specified way for the association to return from the Registered state 841 (4) to the Unregistered state (0) is through user-initiated reset. 842 After the reset, a new OOB message will be needed to establish a new 843 association between the EAP server and peer. Typical situations in 844 which the user reset is required are when the other side has 845 accidentally lost the persistent EAP-NOOB association data, or when 846 the peer device is decommissioned. 848 The server could detect that the peer is in the Registered or 849 Reconnecting state but the server itself is in one of the ephemeral 850 states 0..2 (including situations where the server does not recognize 851 the PeerId). In this case, effort should be made to recover the 852 persistent server state, for example, from a backup storage - 853 especially if many peer devices are similarly affected. If that is 854 not possible, the EAP server SHOULD log the error or notify an 855 administrator. The only way to continue from such a situation is by 856 having the user reset the peer device. 858 On the other hand, if the peer is in any of the ephemeral states 859 0..2, including the Unregistered state, the server will treat the 860 peer as a new peer device and allocate a new PeerId to it. The 861 PeerInfo can be used by the administrator as a clue to which physical 862 device has lost its state. However, there is no secure way of 863 matching the "new" peer with the old PeerId without repeating the OOB 864 step. This situation will be resolved when the user performs the OOB 865 step and, thus, identifies the physical peer device. The server user 866 interface SHOULD support situations where the "new" peer is actually 867 a previously registered peer that has been reset by a user or has 868 otherwise lost the persistent EAP-NOOB association data and needs to 869 be merged with the old peer data in the server. 871 3.5. Key derivation 873 The EAP output values MSK and EMSK are derived with the Elliptic 874 Curve Diffie-Hellman (ECDH) algorithm. In the terminology of the 875 NIST specification [NIST-DH], we use a C(2, 0, ECC CDH) scheme, i.e. 876 two ephemeral keys and no static keys. The server and peer compute 877 the ECDH shared secret Z as defined in section 6.1.2.2 and the secret 878 keying material as defined in section 5.8.1 of the NIST 879 specification. The hash function H for the Concatenation Key 880 Derivation Function is taken from the negotiated cryptosuite. 882 The Concatenation Key Derivation Function in the NIST specification 883 requires some additional input: AlgorithmID, PartyUInfo, PartyVInfo, 884 SuppPubInfo, and SuppPrivInfo. In EAP_NOOB, the AlgorithmID is the 885 fixed-length 8-byte ASCII string "EAP-NOOB". When keys are derived 886 in the Completion Exchange, PartyUInfo is the nonce Np as a 16-byte 887 byte string, and PartyVInfo is the nonce Ns as a 16-byte byte string. 888 SuppPubInfo is not allowed in EAP-NOOB; that is, it is not included 889 in the input of the key derivation function. In the Completion 890 Exchange, SuppPrivInfo is the nonce Noob as a 16-byte byte string. 891 When keys are derived in the Reconnect Exchange, the key derivation 892 process is the same except for the following differences: PartyUInfo 893 is the nonce Np2 as a 16-byte byte string, and PartyVInfo is the 894 nonce Ns2 as a 16-byte byte string, and neither SuppPubInfo nor 895 SuppPrivInfo is allowed. 897 After a successful Completion Exchange, the outputs of the EAP method 898 are the following: MSK and EMSK are the bytes 0..63 and 64..127, 899 respectively, of the output of the Concatenation Key Derivation 900 Function. The 16-byte keys Kms and Kmp and the 32-byte key Kz used 901 internally by EAP-NOOB for computing HMAC values are the bytes 902 128..143, 144..159, and 160..191, respectively, of the output of the 903 Concatenation Key Derivation Function. EAP server and peer store the 904 values Kms, Kmp and Kz in the persistent EAP-NOOB association. 906 After a successful Reconnect Exchange, there are two methods for 907 deriving the new master keys. The first method is used when ECDH 908 public keys were exchanged in the Reconnect Exchange. In this 909 method, the outputs of the EAP method are the following: MSK and EMSK 910 are the bytes 0..63 and 64..127, respectively, of the output of the 911 Concatenation Key Derivation Function. The 32-byte key Kms2 is 912 created by concatenating the stored 16-byte Kms value with the bytes 913 128..143 of the output of the Concatenation Key Derivation Function. 914 The 32-byte key Kmp2 is similarly created by concatenating the stored 915 16-byte Kmp value with the bytes 144..159 of the output of the 916 Concatenation Key Derivation Function. A new 32-byte key Kz is 917 obtained by taking bytes 160..191 of the output of the Concatenation 918 Key Derivation Function. EAP server and peer update the value of Kz 919 in the persistent EAP-NOOB association. 921 The second method is used when no ECDH public keys were exchanged in 922 the Reconnect Exchange (or if only one party sent its public key). 923 In this method, input Z to the Concatenation Key Derivation Function 924 is replaced with the 32-byte key Kz from the persistent EAP-NOOB 925 association. This method achieves rekeying without the computational 926 cost of the ECDH exchange, but does not provide forward secrecy. In 927 this second method, no updates are made to the persistent EAP-NOOB 928 association. 930 3.6. Error handling 932 Various error conditions in EAP-NOOB are handled by sending an error 933 notification message (type=0) instead of the expected next EAP 934 request or response message. Both the EAP server and the peer may 935 send the error notification, as shown in Figure 8 and Figure 9. 936 After sending or receiving an error notification, the server MUST 937 send an EAP-Failure message. The notification MAY contain an 938 ErrorInfo field, which is a UTF-8 encoded text string with a maximum 939 length of 500 bytes. It is used for sending descriptive information 940 about the error, which may be useful for logging and debugging. 942 EAP Peer EAP Server 943 ... ... 944 | | 945 |<----------- EAP-Request/EAP-NOOB ----------------| 946 | (Type=0,[PeerId],ErrorCode,[ErrorInfo]) | 947 | | 948 | | 949 |<----------- EAP-Failure -------------------------| 950 | | 952 Figure 8: Error notification from server to peer 954 EAP Peer EAP Server 955 ... ... 956 | | 957 |------------ EAP-Response/EAP-NOOB -------------->| 958 | (Type=0,[PeerId],ErrorCode,[ErrorInfo]) | 959 | | 960 | | 961 |<----------- EAP-Failure -------------------------| 962 | | 964 Figure 9: Error notification from peer to server 966 3.6.1. Invalid messages 968 If the NAI structure is invalid, the server SHOULD send the error 969 code 1001 to the peer. The recipient of an EAP-NOOB request or 970 response SHOULD send the following error codes back to the sender: 971 1002 if it cannot parse the message as a JSON object or there are 972 missing or unrecognized members in the JSON object; 1003 if a data 973 field has an invalid value, such as an integer out of range; 1004 if 974 the received message type was unexpected; 1005 if the PeerId has an 975 unexpected value; and 1006 if the ECDH key is invalid. 977 3.6.2. Unwanted peer 979 The preferred way for the EAP server to rate limit EAP-NOOB 980 connections from a peer is to use the MinSleep parameter in the 981 Waiting Exchange. However, if the EAP server receives repeated EAP- 982 NOOB connections from a peer which apparently should not connect to 983 this server, the server MAY indicate that the connections are 984 unwanted by sending the error code 2001. The peer MAY refrain from 985 reconnecting to the same EAP server and, if possible, both the EAP 986 server and peer SHOULD indicate this error condition to the user. 987 However, in order to avoid persistent denial-of-service, the peer is 988 not required to stop entirely from reconnecting to the server. 990 3.6.3. State mismatch 992 In the states indicated by "-" in Figure 10 in Appendix A, user 993 action is required to reset the association state or to recover it, 994 for example, from backup storage. In those case, the server sends 995 the error code 2002 to the peer. If possible, both the EAP server 996 and peer SHOULD indicate this error condition to the user. 998 3.6.4. Negotiation failure 1000 If there is no matching protocol version, the peer sends the error 1001 code 3001 to the server. If there is no matching cryptosuite, the 1002 peer sends the error code 3002 to the server. If there is no 1003 matching OOB direction, the peer sends the error code 3003 to the 1004 server. In practice, there is no way of recovering from these errors 1005 without software or hardware changes. If possible, both the EAP 1006 server and peer SHOULD indicate these error conditions to the user. 1008 3.6.5. Cryptographic verification failure 1010 If the EAP server or peer detect an unrecognized PeerId or incorrect 1011 fingerprint (Hoob) in the OOB message, the recipient SHOULD indicate 1012 the failure to accept the OOB message to the user. The recipient 1013 MUST remain in the Waiting for OOB state (1) as if no OOB message was 1014 received. 1016 Note that if the OOB message was delivered from the server to the 1017 peer and the peer does not recognize the PeerId, the likely cause is 1018 that the user has unintentionally delivered the OOB message to the 1019 wrong destination. If possible, the peer SHOULD indicate this to the 1020 user; however, the peer device may not have capability for many 1021 different error indications and it MAY use the same method or error 1022 indication as in the case of an incorrect fingerprint. 1024 The rationale for the above is that the invalid OOB message could 1025 have been presented to the recipient by mistake or intentionally by a 1026 malicious party and, thus, it should be ignored in the hope that the 1027 honest user will soon deliver a correct OOB message. 1029 If the EAP server or peer detects an incorrect message authentication 1030 code (MACs, MACp, MACs2, MACp2), it sends the error code 4001 to the 1031 other side. If this error occurred in the Completion Exchange, both 1032 sides must remain in the old state as if the failed Completion 1033 Exchange did not take place. On the other hand, if the error 1034 occurred in the Reconnect Exchange, both sides MUST go to the 1035 Reconnecting state (3). 1037 The rationale for the above is that the invalid cryptographic 1038 messages may have been spoofed by a malicious party and, thus, it 1039 should be ignored. In particular, a spoofed message on the network 1040 should not force the honest user to perform the OOB step again. In 1041 practice, however, the error may be caused by other failures, such as 1042 software errors. For this reason, the EAP server MAY limit the rate 1043 of peer connections after the above error. Also, there MUST be a way 1044 for the user to reset the EAP server and peer to the Unregistered 1045 state (0), so that the OOB step can be repeated. 1047 3.7. EAP-NOOB Roaming 1049 Roaming support to be added. 1051 4. IANA Considerations 1053 This section provides guidance to the Internet Assigned Numbers 1054 Authority (IANA) regarding registration of values related to the EAP- 1055 NOOB protocol, in accordance with [RFC5226]. 1057 The EAP Method Type number for EAP-NOOB needs to be assigned. 1059 This memo also requires IANA to create new registries as defined in 1060 the following subsections. 1062 4.1. Cryptosuites 1063 An EAP server MUST supply one or more suggestions for cryptosuites as 1064 the Cryptosuites value in the Initial Exchange. They are formatted 1065 as a JSON array of the identifier integers. Each suite MUST appear 1066 only once in the array. The cryptosuites MUST be supplied in order 1067 of priority. Peers MUST supply exactly one suite in the Cryptosuitep 1068 value, formatted as an identifier integer. The following suites are 1069 defined by EAP-NOOB: 1071 +-------------+-----------------------------------------+ 1072 | Cryptosuite | Algorithms | 1073 +-------------+-----------------------------------------+ 1074 | 1 | Curve25519 [RFC7748], SHA-256 [RFC6234] | 1075 +-------------+-----------------------------------------+ 1077 Table 2: EAP-NOOB cryptosuites 1079 Assignment of new values for new cryptosuites MUST be done through 1080 IANA with "Specification Required" and "IESG Approval" as defined in 1081 [RFC5226]. 1083 4.2. Error codes 1085 The error codes defined by EAP-NOOB are listed in Table 3. 1087 +------------+----------------------------------------+ 1088 | Error code | Purpose | 1089 +------------+----------------------------------------+ 1090 | 1001 | Invalid NAI or peer state | 1091 | 1002 | Invalid message structure | 1092 | 1003 | Invalid data | 1093 | 1004 | Unexpected message type | 1094 | 1005 | Unexpected peer identifier | 1095 | 1006 | Invalid ECDH key | 1096 | 2001 | Unwanted peer | 1097 | 2002 | State mismatch, user action required | 1098 | 3001 | No mutually supported protocol version | 1099 | 3002 | No mutually supported cryptosuite | 1100 | 3003 | No mutually supported OOB direction | 1101 | 4001 | MAC verification failure | 1102 +------------+----------------------------------------+ 1104 Table 3: EAP-NOOB error codes 1106 Assignment of new error codes MUST be done through IANA with 1107 "Specification Required" and "IESG Approval" as defined in [RFC5226]. 1109 4.3. Domain name reservation considerations 1110 "eap-noob.net" should be registered as a special-use domain. The 1111 considerations required by [RFC6761] for registering this special use 1112 domain name are as follows: 1114 o Users: Non-admin users are not expected to encounter this name or 1115 recognize it as special. AAA administrators may need to recognize 1116 the name. 1118 o Application Software: Application software is not expected to 1119 recognize this domain name as special. 1121 o Name Resolution APIs and Libraries: Name resolution APIs and 1122 libraries are not expected to recognize this domain name as 1123 special. 1125 o Caching DNS Servers: Caching servers are not expected to recognize 1126 this domain name as special. 1128 o Authoritative DNS Servers: Authoritative DNS servers MUST respond 1129 to queries for eap-noob.net with NXDOMAIN. 1131 o DNS Server Operators: Except for the authoritative DNS server, 1132 there are no special requirements for the operators. 1134 o DNS Registries/Registrars: There are no special requirements for 1135 DNS registrars. 1137 5. Security considerations 1139 EAP-NOOB is an authentication and key derivation protocol and, thus, 1140 security considerations can be found in most sections of this 1141 specification. In the following, we explain the protocol design and 1142 highlight some other special considerations. 1144 5.1. Authentication principle 1146 The mutual authentication in EAP-NOOB is based on two separate 1147 features, both conveyed in the OOB message. The first authentication 1148 feature is the secret nonce Noob. The peer and server use this 1149 secret in the Completion Exchange to mutually authenticate the 1150 session key previously created with ECDH. The message authentication 1151 codes computed with the secret nonce Noob are alone sufficient for 1152 authenticating the key exchange. The OOB channel might, however, be 1153 vulnerable to eavesdropping of the OOB channel, which could lead to 1154 compromise of the secret nonce, which will then enable a man-in-the- 1155 middle attack on the in-band channel. This is why we include, as a 1156 second authentication feature, the integrity-protecting fingerprint 1157 Hoob in the OOB message. It is typically more difficult to spoof or 1158 alter messages on the human-assisted OOB channel, such as bar code, 1159 sound burst or user-transferred URL, than it is to spy on them. 1161 The security provided by the cryptographic fingerprint is somewhat 1162 intricate to understand. The party that receives the OOB message 1163 uses Hoob to verify the integrity of the ECDH exchange. Thus, that 1164 party can detect man-in-the-middle attacks on the in-band channel. 1165 The other party, however, is not equally protected because the OOB 1166 message and fingerprint are sent only in one direction. Some 1167 protection to the OOB sender is afforded by the fact that the user 1168 may notice the failure of the association at the OOB receiver and 1169 therefore reset the OOB sender. Indeed, other device-pairing 1170 protocols have solved a similar situation by requiring the user to 1171 confirm to the OOB sender that the association was accepted by the 1172 OOB-receiver, e.g. by pressing an "accept" button on the sender. 1173 Since EAP-NOOB was designed to work strictly with one-directional OOB 1174 communication, it does not rely on such input to the OOB sender. 1176 To summarize, EAP-NOOB uses the combined protection of the secret 1177 nonce Noob and the cryptographic fingerprint Hoob, both conveyed in 1178 the OOB message. The secret nonce Noob alone is sufficient for 1179 mutual authentication, unless the attacker can eavesdrop it from the 1180 OOB channel. If an attacker is able to eavesdrop the secret nonce 1181 and performs a man-in-the-middle attack on in-band channel, the 1182 mismatching fingerprint will alert the OOB receiver, which will 1183 reject the OOB message. In this case, the association will appear to 1184 be complete only on the OOB sender side. The user in many 1185 applications will detect this apparently one-sided association 1186 because the peer device does not appear registered on the server or 1187 network. 1189 The expected use cases for EAP-NOOB are ones where it replaces a 1190 user-entered access credentials. In wireless network access for IoT 1191 devices, the user-entered credential is often a passphrase, which is 1192 shared by all the network stations. Like any other EAP-based 1193 solution, EAP-NOOB establishes a different master secret for each 1194 peer device, which is obviously more resilient to device compromise 1195 than a common master secret. Additionally, it is possible to revoke 1196 the security association for an individual device on the server side. 1198 Forward secrecy in EAP-NOOB is optional. The Reconnect exchange in 1199 EAP-NOOB provides forward secrecy only if both the server and peer 1200 send their fresh ECDH keys. This allows both the server and the peer 1201 to limit the frequency of the costly computation that is required for 1202 forward secrecy. The server should make its decision primarily based 1203 on what it knows about the peer's computational capabilities. 1205 5.2. Identifying and naming peer devices 1207 EAP-NOOB relies on physical possession or identification of the peer 1208 device and secure communication between the user and the server. The 1209 main remaining threat against EAP-NOOB is that the attacker performs 1210 a man-in-the-middle attack on the in-band channel and, during the 1211 protocol execution, tricks the user to deliver the OOB message to or 1212 from the wrong peer. The server will now be associated with that 1213 wrong peer. Similarly, the attacker could try to trick the user to 1214 accessing the wrong server in the OOB step. This reliance on user in 1215 identifying the correct parties is an inherent property of out-of- 1216 band authentication. 1218 One mechanism that can be used to mitigate user mistakes is 1219 certification of trusted servers and peer devices. For example, if 1220 used together with EAP-NOOB, vendor certificates could prevent 1221 accidental association with a rogue peer device. Compared to a fully 1222 certificate-based authentication, EAP-NOOB does not depend on trusted 1223 third parties and does not require the user to know the identifier of 1224 the peer device; physical access is sufficient. 1226 The user could also accidentally deliver the OOB message to more than 1227 one peer device. This could, for example, occur if the OOB message 1228 is a bar code and the peer is a camera: the user could by mistake 1229 show the bar code first to the wrong camera. Such accidents in EAP- 1230 NOOB will not enable the wrong camera to compute the master key or to 1231 opportunistically eavesdrop the communication. This is because the 1232 wrong peer device would need to have performed a man-in-the middle 1233 attack on the in-band channel before the accident. In comparison, 1234 simpler solutions where the master key is transferred to the device 1235 via the OOB channel would be vulnerable to opportunistic attacks if 1236 the user mistakenly delivers the master key to more than one device. 1238 After completion of EAP-NOOB, the server may store the PeerInfo data, 1239 and the user may use it to identify the peer and its properties, such 1240 as make and model or serial number. A compromised peer could lie 1241 about this information in the PeerInfo that it sends to the server. 1242 If the server stores any information about the peer, it is important 1243 that this information is approved by the user during or after the OOB 1244 step. Without rigorous user checking, the PeerInfo is not 1245 authenticated information and should not be relied on. Therefore, it 1246 is better to include only minimal information about the peer in 1247 PeerInfo and to ask the user to name the peer devices. In many 1248 applications, such as OOB authentication for ad-hoc wireless network 1249 access, it may be unnecessary to store any names for the peer device. 1250 Since the user delivering the OOB message will often communicate with 1251 the server over an authenticated channel, e.g. logging into a secure 1252 web page, the user identity and user-given name can in those cases be 1253 reliably stored for the peer device. It is these user identities and 1254 user-given names that should be later used for access control and 1255 revocation. 1257 Another reason to include only minimal information in the PeerInfo is 1258 potential privacy issues. The PeerInfo field is typically 1259 transmitted in plaintext between the peer and the authenticator. 1260 Although the PeerInfo sent by a new, unregistered device will not 1261 leak any information specifically about the user, it could reveal 1262 device identifiers and information about other device properties, 1263 which the user may want to avoid leaking at this point. 1265 The PeerId value in the protocol is a server-allocated identifier for 1266 its association with the peer and SHOULD NOT be shown to the user 1267 because its value is initially ephemeral. Since the PeerId is 1268 allocated by the server and the scope of the identifier is the single 1269 server, the so-called identifier squatting attacks, where a malicious 1270 peer could reserve another peer's identifier, are not possible in 1271 EAP-NOOB. The server SHOULD assign a random or pseudo-random PeerId 1272 to each new peer. It SHOULD NOT select the PeerId based on any peer 1273 characteristics that it may know, such as the peer's lower-layer 1274 address. 1276 5.3. Downgrading threats 1278 The fingerprint Hoob protects all the information exchanged in the 1279 Initial Exchange, including the cryptosuite negotiation. The message 1280 authentication codes MACs and MACp also protect the same information. 1281 The message authentication codes MACs2 and MACp2 protect information 1282 exchanged during key renegotiation in the Reconnect Exchange. This 1283 prevents downgrade attacks to weaker cryptosuites as long as the 1284 possible attacks take more time than the maximum time allowed for the 1285 EAP-NOOB completion. This is typically the case for recently 1286 discovered cryptanalytic attacks. 1288 As an additional precaution, the EAP server and peer SHOULD check for 1289 downgrading attacks in the Reconnect Exchange. As long as the server 1290 or peer saves any information about the other party, it SHOULD also 1291 remember the previously negotiated cryptosuite and not accept 1292 renegotiation of any cryptosuite that is known to be weaker than the 1293 previous one (e.g. a deprecated cryptosuite or the same ECDH field 1294 with a shorter key). 1296 Integrity of the direction negotiation cannot be verified in the same 1297 way as the integrity of the cryptosuite negotiation. That is, if the 1298 OOB channel used in an application is critically insecure in one 1299 direction, a man-in-the-middle attacker could modify the negotiation 1300 messages and thereby cause that direction to be used. Applications 1301 that support OOB messages in both directions SHOULD therefore ensure 1302 that the OOB channel has sufficiently strong security in both 1303 directions. While this is a theoretical vulnerability, it could 1304 arise in practice if EAP-NOOB is deployed in unexpected applications. 1305 However, most devices acting as the peer are likely to support only 1306 one direction of exchange, in which case interfering with the 1307 direction negotiation can only prevent the completion of the 1308 protocol. 1310 5.4. EAP security claims 1312 +-----------------------+-------------------------------------------+ 1313 | Security property | EAP-NOOB claim | 1314 +-----------------------+-------------------------------------------+ 1315 | Authentication | ECDH key exchange with out-of-band | 1316 | mechanism | authentication | 1317 | | | 1318 | Protected cryptosuite | yes | 1319 | negotiation | | 1320 | | | 1321 | Mutual authentication | yes | 1322 | | | 1323 | Integrity protection | yes | 1324 | | | 1325 | Replay protection | yes | 1326 | | | 1327 | Key derivation | yes | 1328 | | | 1329 | Key strength | The specified cryptosuites provide key | 1330 | | strength of at least 128 bits. | 1331 | | | 1332 | Dictionary attack | not applicable | 1333 | protection | | 1334 | | | 1335 | Fast reconnect | yes | 1336 | | | 1337 | Cryptographic binding | not applicable | 1338 | | | 1339 | Session independence | yes | 1340 | | | 1341 | Fragmentation | no (The largest EAP-NOOB packet is at | 1342 | | most TBD bytes long.) | 1343 | | | 1344 | Channel binding | yes (The ServerInfo and PeerInfo can be | 1345 | | used to convey integrity-protected | 1346 | | channel properties such as peer MAC | 1347 | | address.) | 1348 +-----------------------+-------------------------------------------+ 1349 Table 4: Security claims 1351 EAP security claims are defined in section 7.2.1 of [RFC3748]. EAP- 1352 NOOB makes the following security claims: 1354 6. References 1356 6.1. Normative references 1358 [NIST-DH] Barker, E., Johnson, D., and M. Smid, "Recommendation for 1359 Pair-Wise Key Establishment Schemes Using Discrete 1360 Logarithm Cryptography", NIST Special Publication 800-56A 1361 Revision 1 , March 2007, . 1365 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1366 Hashing for Message Authentication", RFC 2104, DOI 1367 10.17487/RFC2104, February 1997, 1368 . 1370 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1371 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1372 RFC2119, March 1997, 1373 . 1375 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1376 Levkowetz, Ed., "Extensible Authentication Protocol 1377 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 1378 . 1380 [RFC4266] Hoffman, P., "The gopher URI Scheme", RFC 4266, DOI 1381 10.17487/RFC4266, November 2005, 1382 . 1384 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1385 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 1386 . 1388 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 1389 Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, 1390 March 2008, . 1392 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1393 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1394 DOI 10.17487/RFC5226, May 2008, 1395 . 1397 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 1398 (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487 1399 /RFC6234, May 2011, 1400 . 1402 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 1403 RFC 6761, DOI 10.17487/RFC6761, February 2013, 1404 . 1406 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1407 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1408 2014, . 1410 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/ 1411 RFC7517, May 2015, 1412 . 1414 [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, DOI 1415 10.17487/RFC7542, May 2015, 1416 . 1418 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 1419 for Security", RFC 7748, DOI 10.17487/RFC7748, January 1420 2016, . 1422 6.2. Informative references 1424 [IEEE-802.1X] 1425 Institute of Electrical and Electronics Engineers, "Local 1426 and Metropolitan Area Networks: Port-Based Network Access 1427 Control", IEEE Standard 802.1X-2004. , December 2004. 1429 [Sethi14] Sethi, M., Oat, E., Di Francesco, M., and T. Aura, "Secure 1430 Bootstrapping of Cloud-Managed Ubiquitous Displays", 1431 Proceedings of ACM International Joint Conference on 1432 Pervasive and Ubiquitous Computing (UbiComp 2014), pp. 1433 739-750, Seattle, USA , September 2014, 1434 . 1436 [SimplePairing] 1437 Bluetooth, SIG, "Simple pairing whitepaper", Technical 1438 report , 2007. 1440 Appendix A. Exchanges and events per state 1442 Figure 10 shows how the EAP server chooses the exchange type 1443 depending on the server and peer states. In the state combinations 1444 marked with hyphen "-", there is no possible exchange, and user 1445 action is required to make progress. Note that peer state 4 is 1446 omitted from the table because the peer never connects to the server 1447 when peer is in that state. 1449 +--------+---------------------------+------------------------------+ 1450 | peer | exchange chosen by | next peer and | 1451 | states | server | server states | 1452 +========+===========================+==============================+ 1453 | server state: Unregistered (0) | 1454 +--------+---------------------------+------------------------------+ 1455 | 0..2 | Initial Exchange | both 1 (0 on error) | 1456 | 3 | - | no change, notify user | 1457 +--------+---------------------------+------------------------------+ 1458 | server state: Waiting for OOB (1) | 1459 +--------+---------------------------+------------------------------+ 1460 | 0 | Initial Exchange | both 1 (0 on error) | 1461 | 1 | Waiting Exchange | both 1 | 1462 | 2 | Completion Exchange | both 4 (no change on error) | 1463 | 3 | - | no change, notify user | 1464 +--------+---------------------------+------------------------------+ 1465 | server state: OOB Received (2) | 1466 +--------+---------------------------+------------------------------+ 1467 | 0 | Initial Exchange | both 1 (0 on error) | 1468 | 1 | Completion Exchange | both 4 (no change on error) | 1469 | 2 | Completion Exchange | both 4 (no change on error) | 1470 | 3 | - | no change, notify user | 1471 +--------+---------------------------+------------------------------+ 1472 | server states: Reconnecting (3) or Registered (4) | 1473 +--------+---------------------------+------------------------------+ 1474 | 0..2 | - | no change, notify user | 1475 | 3 | Reconnect Exchange | both 4 (3 on error) | 1476 +--------+---------------------------+------------------------------+ 1478 Figure 10: How server chooses the exchange type 1480 Figure 11 lists the local events that can take place in the server or 1481 peer. Both the server and peer output and accept OOB messages in 1482 association state 1. The OOB message events have been marked with 1483 asterisk (*) to indicate that events are only possible if allowed by 1484 the negotiated OOB directions (Dirp). Communication errors and 1485 timeouts in states 0..2 lead back to state 0, while similar errors in 1486 states 3..4 lead to state 3. Application request for rekeying (e.g. 1487 to refresh session keys or to upgrade algorithms) also takes the 1488 association from state 3..4 to state 3. User can always reset the 1489 association state to 0. Recovering association data, e.g. from a 1490 backup, leads to state 3. 1492 +--------+---------------------------+------------------------------+ 1493 | server/| possible local events | next state | 1494 | peer | on server and peer | | 1495 | state | | | 1496 +========+===========================+==============================+ 1497 | 1 | OOB Output* | 1 | 1498 | 1 | OOB Input* | 2 (1 on error) | 1499 | 0..2 | Timeout/network failure | 0 | 1500 | 3..4 | Timeout/network failure | 3 | 1501 | 3..4 | Rekeying request | 3 | 1502 | 0..4 | User resets peer state | 0 | 1503 | 0..4 | Association state recovery| 3 | 1504 +--------+---------------------------+------------------------------+ 1506 Figure 11: Local events on server and peer 1508 Appendix B. QR code as an OOB 1510 While EAP-NOOB does not mandate any particular OOB communication 1511 channel, when bootstrapping devices with output interfaces such as 1512 electronic displays and printers, it may be convenient to use a QR 1513 code containing the server address (URL) for transferring the OOB 1514 message. A user would simply scan the QR code containing an https 1515 URL where the OOB message content would be delivered. The ServerInfo 1516 in this case would consist of a JSON member called "ServUrl". The 1517 value of this member would indicate where the the OOB message 1518 contents (PeerId,Noob,Hoob) are delivered. The URL is of the 1519 following format (line breaks are for readability only): 1521 https://[:][/][/ 1522 ]?PeerId=&Noob=&Hoob= 1524 The following are examples of well-formed URL that contain the OOB 1525 message (line breaks are for readability only): 1527 https://example.com/?PeerId=ZrD7qkczNoHGbGcN2bN0Xg2NEhvVfQNchqiFLueyQ 1528 Td0znNByyzuMChoTKi&Noob=rMinS0-F4EfCU8D9ljxX_A&Hoob=QvnMp4UGxuQVFaXPW 1529 _14UWnAvm7H1Hly23sjhzRXMEY 1530 https://example.com:8080/qrcode.jsp?PeerID=FA37jNCchRYdSBZAYY4CbwdXs2 1531 2jJZHmAIrRv41MTZXLyVkwRo72Tk0lk0E&Noob=Iag2Mhb1mXTw1qJlXuFlig&Hoob=Qv 1532 nMp4UGxuQVFaXPW_14UWnAvm7H1Hly23sjhzRXMEY 1534 In the examples above, the PeerID is encoded as a 59 byte hexadecimal 1535 string, the Hoob and Noob are encoded as base64url strings. The 1536 order of the query parameters may change. The URL MUST specify a 1537 host available over https i.e. the secure version of the HTTP 1538 protocol. 1540 Appendix C. Example messages 1542 The following are example JSON messages exchanged between an EAP peer 1543 and server (line breaks are for readability only): 1545 1. First Identity response: 1546 noob@eap-noob.net 1548 2. EAP request (type 1): 1549 {"Cryptosuites":[1],"Vers":[1],"Type":1,"ServerInfo":"{\"ServNam 1550 e\":\"DVS-21x\",\"ServUrl\":\"https://example.com/verify\"}","Pe 1551 erId":"ZrD7qkczNoHGbGcN2bN0Xg2NEhvVfQNchqiFLueyQTd0znNByyzuMChoT 1552 Ki","Dirs":3} 1554 3. EAP response (type 1): 1555 {"Dirp":1,"PeerId":"ZrD7qkczNoHGbGcN2bN0Xg2NEhvVfQNchqiFLueyQTd0 1556 znNByyzuMChoTKi","Type":1,"Verp":1,"Cryptosuitep":1,"PeerInfo":" 1557 {\"PeerName\":\"A display unit.\",\"PeerSNum\":\"XA532678BQ\"}"} 1559 4. EAP request (type 2): 1560 {"Type":2,"PeerId":"ZrD7qkczNoHGbGcN2bN0Xg2NEhvVfQNchqiFLueyQTd0 1561 znNByyzuMChoTKi","Ns":"ZHBOzuW9Qtr9bpDJuke_5w","PKs":"BOgOPRWrti 1562 mpdEYIM_gJkne9PLaP4OJ2wknZGVk_N3bXFS4U6e0OtL2T1fG2u- 1563 jau8FBHvs4UNkLpMwxemsAcwM","jwk":{"kty":"EC","crv":"P-256","x 1564 ":"6A49Fau2Kal0Rggz-AmSd708to_g4nbCSdkZWT83dtc","y 1565 ":"FS4U6e0OtL2T1fG2u-jau8FBHvs4UNkLpMwxemsAcwM"}} 1567 5. EAP response (type 2): 1568 {"Type":2,"PeerId":"ZrD7qkczNoHGbGcN2bN0Xg2NEhvVfQNchqiFLueyQTd0 1569 znNByyzuMChoTKi","Np":"Jvr5QxlfibdjuWF518pAIQ","PKp":"BD8Adwz3n6 1570 lWE6pRmnGboDXHoc15QfoUsXfVnygsil1nI_X2r0d3gWS8bgNrI774AdjgZ77s8a 1571 UMPnjOvi3R8rE","jwk":{"kty":"EC","crv":"P-256","x 1572 ":"PwB3DPefqVYTqlGacZugNcehzXlB-hSxd9WfKCyKXWc","y":"I_X2r0d3gWS 1573 8bgNrI774AdjgZ77s8aUMPnjOvi3R8rE"}} 1575 6. EAP request (type 3): 1576 {"Type":3,"PeerId":"ZrD7qkczNoHGbGcN2bN0Xg2NEhvVfQNchqiFLueyQTd0 1577 znNByyzuMChoTKi","minsleep":150} 1579 7. EAP response (type 3): 1580 {"Type":3,"PeerId":"ZrD7qkczNoHGbGcN2bN0Xg2NEhvVfQNchqiFLueyQTd0 1581 znNByyzuMChoTKi"} 1583 8. EAP request (type 4): 1584 {"Type":4,"PeerId":"ZrD7qkczNoHGbGcN2bN0Xg2NEhvVfQNchqiFLueyQTd0 1585 znNByyzuMChoTKi","MACs":"JeDGWKrlj6L_8EkSv40gGFw5-gYiU7QD3scDWl4 1586 TB3I"} 1588 9. EAP response (type 4): 1589 {"Type":4,"MACp":"HaDcAd4qgqbD4NDmXe2nr6BiQwVFlv1LB3NemCVAaWc"," 1590 PeerID":"ZrD7qkczNoHGbGcN2bN0Xg2NEhvVfQNchqiFLueyQTd0znNByyzuMCh 1591 oTKi"} 1593 10. EAP request (type 5): 1594 {"Cryptosuites":[1],"Type":5,"ServerInfo":"{\"ServName\":\"DVS- 1595 21x\",\"ServUrl\":\"https://example.com/verify\"}","PeerId":"ZrD 1596 7qkczNoHGbGcN2bN0Xg2NEhvVfQNchqiFLueyQTd0znNByyzuMChoTKi"} 1598 11. EAP response (type 5): 1599 {"Type":5,"PeerId":"ZrD7qkczNoHGbGcN2bN0Xg2NEhvVfQNchqiFLueyQTd0 1600 znNByyzuMChoTKi","PeerInfo":"{\"PeerName\":\"A display 1601 unit.\",\"PeerSNum\":\"XA532678BQ\"}","Cryptosuitep":1} 1603 12. EAP request (type 6): 1604 {"Type":6,"Ns":"Px2d1B0oVEgmsdlGgvTnXA","PeerId":"ZrD7qkczNoHGbG 1605 cN2bN0Xg2NEhvVfQNchqiFLueyQTd0znNByyzuMChoTKi"} 1607 13. EAP response (type 6): 1608 {"Type":6,"PeerId":"ZrD7qkczNoHGbGcN2bN0Xg2NEhvVfQNchqiFLueyQTd0 1609 znNByyzuMChoTKi","Np":"IF5NhNDKTUz1h0HvFUfCEw"} 1611 14. EAP request (type 7): 1612 {"Type":7,"PeerId":"ZrD7qkczNoHGbGcN2bN0Xg2NEhvVfQNchqiFLueyQTd0 1613 znNByyzuMChoTKi","MACs":"-BubtcZXbv3p51BGD98XvYW5dAAIPbgjrhAJGwc 1614 0aOc"} 1616 15. EAP response (type 7): 1617 {"Type":7,"PeerId":"ZrD7qkczNoHGbGcN2bN0Xg2NEhvVfQNchqiFLueyQTd0 1618 znNByyzuMChoTKi","MACp":"-Ertyhd3j83p51BGD98XvYW5dAAIPbgjrhAJGwr 1619 taft"} 1621 Appendix D. TODO list 1623 o Add roaming support info. 1625 o Update Kms and Kmp in the persistent EAP_NOOB association after 1626 ECDH rekeying. This will add to security but is somewhat tricky. 1628 o Clarify the relation of Unregistered state and no association 1629 stored. 1631 o Consider less disruptive ways for handling protocol errors in 1632 state 1, compared to the current solution of returning to state 0. 1634 Appendix E. Version tracking 1636 o Version 01: 1638 * Fix Reconnection Exchange 1640 * URL examples 1642 * Message examples 1644 * Improved state transition (event) tables 1646 Authors' Addresses 1648 Tuomas Aura 1649 Aalto University 1650 Aalto 00076 1651 Finland 1653 EMail: tuomas.aura@aalto.fi 1655 Mohit Sethi 1656 Ericsson 1657 Hirsalantie 11 1658 Jorvas 02420 1659 Finland 1661 EMail: mohit@piuha.net