idnits 2.17.1 draft-rieckers-emu-eap-ute-00.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (7 March 2022) is 782 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: 'OOB-Id' is mentioned on line 639, but not defined -- Obsolete informational reference (is this intentional?): RFC 8152 (Obsoleted by RFC 9052, RFC 9053) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J.-F. Rieckers 3 Internet-Draft DFN 4 Intended status: Standards Track 7 March 2022 5 Expires: 8 September 2022 7 User-assisted Trust Establishment (EAP-UTE) 8 draft-rieckers-emu-eap-ute-00 10 Abstract 12 The Extensible Authentication Protocol (EAP) provides support for 13 multiple authentication methods. This document defines the EAP-UTE 14 authentication method for a User-assisted Trust Establishment between 15 the peer and the server. The EAP method is intended for 16 bootstrapping Internet-of-Things (IoT) devices without preconfigured 17 authentication credentials. The trust establishment is achieved by 18 transmitting a one-directional out-of-band (OOB) message between the 19 peer and the server to authenticate the in-band exchange. The peer 20 must have a secondary input or output interface, such as a display, 21 camera, microphone, speaker, blinking light, or light sensor, so that 22 dynamically generated messages with tens of bytes in length can be 23 transmitted or received. 25 About This Document 27 This note is to be removed before publishing as an RFC. 29 Status information for this document may be found at 30 https://datatracker.ietf.org/doc/draft-rieckers-emu-eap-ute/. 32 Discussion of this document takes place on the EAP Method Update 33 (emu) Working Group mailing list (mailto:emu@ietf.org), which is 34 archived at https://mailarchive.ietf.org/arch/browse/emu/. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on 8 September 2022. 53 Copyright Notice 55 Copyright (c) 2022 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 60 license-info) in effect on the date of publication of this document. 61 Please review these documents carefully, as they describe your rights 62 and restrictions with respect to this document. Code Components 63 extracted from this document must include Revised BSD License text as 64 described in Section 4.e of the Trust Legal Provisions and are 65 provided without warranty as described in the Revised BSD License. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 70 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 71 3. EAP-UTE protocol . . . . . . . . . . . . . . . . . . . . . . 4 72 3.1. Protocol Overview . . . . . . . . . . . . . . . . . . . . 4 73 3.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . 5 74 3.2.1. General Message format . . . . . . . . . . . . . . . 5 75 3.2.2. Server greeting . . . . . . . . . . . . . . . . . . . 8 76 3.2.3. Client greeting . . . . . . . . . . . . . . . . . . . 8 77 3.2.4. Server Keyshare . . . . . . . . . . . . . . . . . . . 9 78 3.2.5. Client Finished . . . . . . . . . . . . . . . . . . . 9 79 3.2.6. Client Completion Request . . . . . . . . . . . . . . 10 80 3.2.7. Server Completion Response . . . . . . . . . . . . . 10 81 3.2.8. Client Keyshare . . . . . . . . . . . . . . . . . . . 10 82 3.3. Protocol Sequence . . . . . . . . . . . . . . . . . . . . 10 83 3.3.1. Initial Exchange . . . . . . . . . . . . . . . . . . 11 84 3.3.2. User-assisted out-of-band step . . . . . . . . . . . 12 85 3.3.3. Waiting Exchange . . . . . . . . . . . . . . . . . . 12 86 3.3.4. Completion Exchange . . . . . . . . . . . . . . . . . 13 87 3.3.5. Reconnect Exchange . . . . . . . . . . . . . . . . . 14 88 3.4. MAC and OOB calculation and Key derivation . . . . . . . 16 89 3.5. Error handling . . . . . . . . . . . . . . . . . . . . . 17 90 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 91 4.1. EAP Security Claims . . . . . . . . . . . . . . . . . . . 17 92 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 93 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 94 7. Differences to RFC 9140 (EAP-NOOB) . . . . . . . . . . . . . 18 95 7.1. Different encoding . . . . . . . . . . . . . . . . . . . 18 96 7.2. Implicit transmission of peer state . . . . . . . . . . . 18 97 7.3. Extensibility . . . . . . . . . . . . . . . . . . . . . . 18 98 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 99 8.1. Normative References . . . . . . . . . . . . . . . . . . 18 100 8.2. Informative References . . . . . . . . . . . . . . . . . 19 101 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19 102 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 104 1. Introduction 106 This document describes a method for registration, authentication, 107 and key derivation for network-connected devices, especially with low 108 computational power and small or no interaction interfaces, such as 109 devices that are part of the Internet of Things (IoT). These devices 110 may come without preconfigured trust anchors or have no possibility 111 to receive a network configuration that enables them to connect 112 securely to a network. 114 This document uses the basic design principle behind the EAP-NOOB 115 method described in [RFC9140] and aims to improve some key elements 116 of the protocol to better address the needs for IoT devices. This is 117 mainly achieved by using CBOR with numeric keys instead of JSON to 118 encode the exchanged messages. 120 TODO: The EAP-UTE protocol also allows extensions, they are still 121 TBD. Basically, the messages can just include additional fields with 122 newly defined meanings. 124 The possible problems of EAP-NOOB are discussed in 125 [I-D.draft-rieckers-emu-eap-noob-observations]. This document 126 provides a specification which aims to address these concerns. 128 2. Conventions and Definitions 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 132 "OPTIONAL" in this document are to be interpreted as described in 133 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 134 capitals, as shown here. 136 TODO frequently used terms 138 authenticator 140 peer 141 server 143 3. EAP-UTE protocol 145 This section defines the EAP-UTE method. 147 3.1. Protocol Overview 149 TODO: The introduction text is basically copied from RFC9140. Should 150 be reworded. 152 The EAP-UTE method execution spans two or more EAP conversations, 153 called Exchanges in this specification. Each Exchange consists of 154 several EAP request-response pairs. In order to give the user time 155 to deliver the OOB message between the peer and the server, at least 156 two separate EAP conversations are needed. 158 The overall protocol starts with a version and cryptosuite 159 negotiation and peer detection. Depending of the current state of 160 the peer and server, different exchanges are selected. 162 If the server or the peer are in the unregistered state, peer and 163 server exchange nonces and keys for the Ephemeral Elliptic Curve 164 Diffie-Hellman. This is called the Initial Exchange. The Initial 165 Exchange results in an EAP-Failure, since neither the server nor the 166 peer are authenticated. 168 After the Initial Exchange, the user-assisted step of trust 169 establishment takes place. The user delivers one OOB message either 170 from the peer to the server or from the server to the peer. 172 While peer and server are waiting for completion of the OOB Step, the 173 peer MAY probe the server by reconnecting, to check for successful 174 transmission of the OOB message. This probe request will result in a 175 Waiting Exchange and EAP-Failure, if the server has not yet received 176 the OOB message. 178 If either the server or the peer have received the OOB message, the 179 probe request will result in a Completion Exchange. In the 180 Completion Exchange, peer and server exchange message authentication 181 codes over the previous in-band messages and the OOB message. The 182 Completion Exchange may result in EAP-Success. Once the peer and 183 server have performed a successful Completion Exchange, both 184 endpoints store the created association in persistent storage. 186 After a successful Completion Exchange, the peer and server can use 187 the Reconnect Exchange, to create a new association with new 188 cryptographic bindings. The user-assisted OOB step is not necessary, 189 since the peer and server can infer the mutual authentication by 190 using the persistent data stored after the Completion Exchange. 192 Waiting 193 .------. 194 | V 195 +------------------+ +---------------------+ 196 .->| Unregistered (0) | Initial | Waiting for OOB (1) | 197 | | (ephemeral) |-------->| (ephemeral) | 198 | +------------------+ +---------------------+ 199 | | | 200 | User Reset .-----------------' | OOB Input 201 | | Completion | 202 | | | 203 | V V 204 | +----------------+ +------------------+ 205 '-| Registered (3) | Completion | OOB Received (2) | 206 | (persistent) |<-----------| | 207 +----------------+ +------------------+ 209 Figure 1: EAP-UTE Server-Peer Association State Machine 211 3.2. Messages 213 3.2.1. General Message format 215 All EAP-UTE messages consist of the following parts: 217 type: one octet to indicate the type of the message 219 length: two octets indicating the length of the following message 220 payload, not including the optional MAC value 222 payload: the CBOR encoded message 224 MAC: (optional) the message authentication code 226 Remark from the author: 227 This format is just a first draft. It allows a very simple MAC 228 calculation, since the MACs can just consist of the concatenated 229 previous messages. This also allows an easy addition of extensions, 230 since the extension payloads are automatically included in the MAC 231 calculation, if they are part of the CBOR payload. 233 The message payloads are encoded in CBOR [RFC8949] as maps. 235 In Table 1 the different message fields, their assigned mapkey and 236 the type are listed. 238 +========+==========+======================+========================+ 239 | Mapkey | Type | Label |Description | 240 +========+==========+======================+========================+ 241 | 1 | Array of | Versions |The versions supported | 242 | | Integers | |by the server. For this| 243 | | | |document the version is | 244 | | | |1 | 245 +--------+----------+----------------------+------------------------+ 246 | 2 | Integer | Version |The version selected by | 247 | | | |the peer | 248 +--------+----------+----------------------+------------------------+ 249 | 3 | Array? | Ciphers |The ciphers supported by| 250 | | | |the server. TODO: Not | 251 | | | |yet sure how to define | 252 | | | |them. | 253 +--------+----------+----------------------+------------------------+ 254 | 4 | Integer? | Cipher |The cipher selected by | 255 | | | |the peer | 256 +--------+----------+----------------------+------------------------+ 257 | 5 | Integer | Directions |The OOB-Directions | 258 | | | |supported by the server.| 259 | | | |0x01 for peer-to-server,| 260 | | | |0x02 for server-to-peer,| 261 | | | |0x03 for both | 262 +--------+----------+----------------------+------------------------+ 263 | 6 | Integer | Direction |The OOB-Direction | 264 | | | |selected by the peer. | 265 | | | |SHOULD be either 0x01 or| 266 | | | |0x02, but MAY be 0x03 | 267 | | | |for both directions | 268 +--------+----------+----------------------+------------------------+ 269 | 7 | Map | ServerInfo |Information about the | 270 | | | |server, e.g. a URL for | 271 | | | |OOB-message-submission | 272 +--------+----------+----------------------+------------------------+ 273 | 8 | Map | PeerInfo |Information about the | 274 | | | |peer, e.g. manufacturer/| 275 | | | |serial number | 276 +--------+----------+----------------------+------------------------+ 277 | 9 | bytes | Nonce_P |Peer Nonce | 278 +--------+----------+----------------------+------------------------+ 279 | 10 | bytes | Nonce_S |Server Nonce | 280 +--------+----------+----------------------+------------------------+ 281 | 11 | ? | Key_P |Peer's ECDHE key | 282 | | | |according to the chosen | 283 | | | |cipher | 284 +--------+----------+----------------------+------------------------+ 285 | 12 | ? | Key_S |Server's ECDHE key | 286 +--------+----------+----------------------+------------------------+ 287 | 13 | null | MAC_S |Indication that Server | 288 | | | |MAC is included | 289 +--------+----------+----------------------+------------------------+ 290 | 14 | null | MAC_P |Indication that Peer MAC| 291 | | | |is included | 292 +--------+----------+----------------------+------------------------+ 293 | 15 | text | PeerId |Peer Identifier | 294 +--------+----------+----------------------+------------------------+ 295 | 16 | bytes | OOB-Id |Identifier of the OOB | 296 | | | |message | 297 +--------+----------+----------------------+------------------------+ 298 | 17 | int | RetryInterval |Number of seconds to | 299 | | | |wait after a failed | 300 | | | |Completion Exchange | 301 +--------+----------+----------------------+------------------------+ 302 | 18 | Map | AdditionalServerInfo |Additional information | 303 | | | |about the server. TODO:| 304 | | | |not sure about this yet.| 305 +--------+----------+----------------------+------------------------+ 307 Table 1: Mapkeys for CBOR encoding 309 The inclusion of MAC_S or MAC_P indicate that the MAC value is 310 appended to the message. The length of the MAC field is determined 311 by the used cryptosuite. A message MUST NOT contain both MAC_S and 312 MAC_P, only one of these values can be present in a message. 314 TODO: Depending on the definition of the Cipher Suites, the format 315 for Ciphers and Cipher might change, as well as Key_P and Key_S. The 316 most immediate choice would be COSE [RFC8152]. But maybe there are 317 better choices out there. 319 3.2.1.1. Thoughts about the message format 321 EAP-NOOB [RFC9140] uses JSON as encoding. Problems of using JSON are 322 discussed in section 2.1 of 323 [I-D.draft-rieckers-emu-eap-noob-observations]. 325 For this specification, the following encodings have been considered: 327 * Static encoding 328 This allows a minimal number of bytes and requires a minimal 329 amount of parsing, since the format and order of the message 330 fields is specified exactly. However, this encoding severely 331 affects the extensibility, unless a specific extension format is 332 used. The specification of this protocol also has optional fields 333 in some message types, so this would also have to be addressed. 335 * CBOR with static fields (e.g. Array) 336 This approach has a slightly higher number of bytes than the 337 static encoding, but allows an easier extensibility. The required 338 fields can be specified, so the order of the protocol field is 339 static and a parser has minimal effort to parse the protocol 340 fields. However, this might be problematic in future protocol 341 versions, when new fields are introduced. Like with static 342 encoding, this also requires a mechanism for optional fields in 343 the different message types. 345 * CBOR map with numeric keys 346 To mitigate the problems of optional fields while keeping the 347 parsing effort low, CBOR maps with numeric keys can be used. All 348 protocol fields are identified by a unique identifier, specified 349 in this document. A parser can simply loop through the CBOR map. 350 Since CBOR maps have a canonical order, minimal implementations 351 may rely on this fact to parse the information needed. 353 On the basis of this discussion, this draft will use a CBOR map as 354 message encoding. However, this is just a first draft and 355 suggestions for other message formats are highly welcome. 357 3.2.2. Server greeting 359 * Message Type: 1 361 * Required Attributes: 363 - Versions 365 - Ciphers 367 - ServerInfo 369 - Directions 371 * Optional Attributes: 373 - RetryInterval? 375 3.2.3. Client greeting 377 * Message Type: 2 378 * Required Attributes: 380 - Version 382 - Cipher 384 - PeerInfo 386 - Direction 388 - Nonce_P 390 - Key_P 392 * Optional Attributes: 394 - PeerId 396 3.2.4. Server Keyshare 398 * Message Type: 3 400 * Required Attributes: 402 - Key_S 404 - Nonce_S 406 - MAC_S 408 * Optional Attributes: 410 - PeerId 412 - AdditionalServerInfo? 414 - RetryInterval? 416 TODO: Maybe make MAC_S optional, if used in Initial Exchange 418 3.2.5. Client Finished 420 * Message Type: 4 422 * Required Attributes: 424 - MAC_P 426 TODO: Maybe make MAC_P optional, if used in Initial Exchange 428 3.2.6. Client Completion Request 430 * Message Type: 5 432 * Required Attributes: 434 - Nonce_P 436 - PeerId 438 * Optional Attributes: 440 - OOB-Id 442 3.2.7. Server Completion Response 444 * Message Type: 6 446 * Required Attributes: 448 - Nonce_S 450 - MAC_S 452 * Optional Attributes: 454 - OOB-Id 456 3.2.8. Client Keyshare 458 * Message Type: 7 460 * Required Attributes: 462 - PeerId 464 - Nonce_P 466 - Key_P 468 3.3. Protocol Sequence 470 After reception of the EAP-Response/Identity packet, the server 471 always answers with a Server Greeting packet (Type 1). This Server 472 Greeting contains the supported protocol versions, ciphers and OOB 473 directions along with the ServerInfo. 475 Depending on the peer state, the peer chooses the next packet. If 476 the peer is in the unregistered state and does not yet have an 477 ephemeral or persistent state, it chooses the Client Greeting, which 478 starts the Initial Handshake. 480 If the peer is in the Waiting for OOB or OOB Received state, the 481 Initial Exchange has completed and the OOB step needs to take place. 482 If the negotiated direction is from server to peer, the peer SHOULD 483 NOT try to reconnect until the peer received an OOB message. If the 484 negotiated direction is from peer to server, the peer can probe the 485 server at regular intervals to check if the OOB message to the server 486 has been delivered. The peer will send a Client Completion Request 487 to initiate the Waiting/Completion Exchange. 489 If the peer is in the Registered state, it may choose between three 490 different Reconnect Exchanges. If the peer wants a reconnect without 491 new key exchanges, it will send a Client Completion Request, starting 492 the Reconnect Exchange without ECDHE. If the peer wants to reconnect 493 with new key exchanges, it will send a Client Key Share packet, which 494 starts the Reconnect Exchange with new ECDHE exchange. The third 495 option is a reconnect with a new version or cipher, this is TBD. 497 3.3.1. Initial Exchange 499 The Initial Exchange comprises of the following packets: 501 After the Server Greeting common to all exchanges, the peer sends a 502 Client Greeting packet. The Client Greeting contains the peer's 503 chosen protocol version, cipher and direction of the OOB message. 504 The peer MUST only choose values for these fields offered by the 505 server in it's Server Greeting. For Direction the peer SHOULD choose 506 either 0x01 or 0x02 if the server offered 0x03. Additionally, the 507 Client Greeting contains PeerInfo, a nonce and the peer's ECDHE 508 public key. 510 The server will then answer with a Server Keyshare packet. The 511 packet contains a newly allocated PeerId, the server's nonce and 512 ECDHE public key and the message authentication code MAC_S. 514 The peer then answers with a Client Finished packet, containing the 515 peer's message authentication code MAC_P. 517 Since no authentication has yet been achieved, the server then 518 answers with an EAP-Failure. 520 EAP Peer Authenticator EAP Server 521 | | | 522 |<- EAP-Request/Identity -| | 523 | | 524 |-- EAP-Response/Identity ------------->| 525 | (NAI=new@eap-ute.arpa) | 526 | | 527 |<- EAP-Request/EAP-UTE ----------------| 528 | SERVER GREETING (1) | 529 | Versions, Ciphers, ServerInfo, | 530 | Directions | 531 | | 532 |-- EAP-Response/EAP-UTE -------------->| 533 | CLIENT GREETING (2) | 534 | Version, Cipher, PeerInfo, | 535 | Direction, Nonce_P, Key_P | 536 | | 537 |<- EAP-Request/EAP-UTE ----------------| 538 | SERVER KEYSHARE (3) | 539 | PeerId, Key_S, Nonce_S, MAC_S | 540 | | 541 |-- EAP-Response/EAP-UTE -------------->| 542 | CLIENT FINISHED (4) | 543 | MAC_P | 544 | | 545 |<- EAP-Failure ------------------------| 546 | | 548 Figure 2: Initial Exchange 550 TODO: Do I need MACs here? What are they really for? (see 551 Section 3.4 for more thoughts on this) 553 3.3.2. User-assisted out-of-band step 555 After the completed Initial Exchange, the peer or the server, 556 depending on the negotiated direction, will generate an OOB message. 558 Details still TBD. 560 3.3.3. Waiting Exchange 562 The Waiting Exchange is performed if neither the server nor the peer 563 have received an OOB message yet. 565 The peer probes the server with a Client Completion Request. In this 566 packet the peer omits the optional OOB-Id field. If the OOB message 567 is delivered from the peer to the server, the server may have 568 received an OOB message already. To allow the server to complete the 569 association, the peer includes a nonce, along with the allocated 570 PeerId. The nonce MAY be repeated for all Client Completion Requests 571 while waiting for the completion. 573 If the server did not receive an OOB message, it answers with an EAP- 574 Failure. 576 EAP Peer Authenticator EAP Server 577 | | | 578 |<- EAP-Request/Identity -| | 579 | | 580 |-- EAP-Response/Identity ------------->| 581 | (NAI=waiting@eap-ute.arpa) | 582 | | 583 |<- EAP-Request/EAP-UTE ----------------| 584 | SERVER GREETING (1) | 585 | Versions, Ciphers, Server Info, | 586 | Directions | 587 | | 588 |-- EAP-Response/EAP-UTE -------------->| 589 | CLIENT COMPLETION REQUEST (5) | 590 | PeerId, Nonce_P | 591 | | 592 |<- EAP-Failure ------------------------| 593 | | 595 Figure 3: Waiting Exchange 597 3.3.4. Completion Exchange 599 The Completion Exchange is performed to finish the mutual trust 600 establishment. 602 As in the Waiting Exchange, the peer probes the server with a Client 603 Completion Request. The nonce of the previous Client Completion 604 Requests which did not lead to a completion MAY be repeated. If the 605 peer has received an OOB message, the peer will include the OOB-Id in 606 the Completion Request. If the peer did not include an OOB-Id, the 607 server will include the OOB-Id of its received OOB message. In the 608 unlikely case that both directions are negotiated and an OOB message 609 is delivered from the peer to the server and from the server to the 610 peer at the same time, as a tiebreaker, the OOB message from the 611 server to the peer is chosen. 613 The server generates a new nonce, calculates MAC_S according to 614 Section 3.4 and sends a Server Completion Response to the peer. 616 The peer will then calculate the MAC_P value and send a Client 617 Finished message to the server. 619 The server then answers with an EAP-Success. 621 EAP Peer Authenticator EAP Server 622 | | | 623 |<- EAP-Request/Identity -| | 624 | | 625 |-- EAP-Response/Identity ------------->| 626 | (NAI=waiting@eap-ute.arpa) | 627 | | 628 |<- EAP-Request/EAP-UTE ----------------| 629 | SERVER GREETING (1) | 630 | Versions, Ciphers, Server Info, | 631 | Directions | 632 | | 633 |-- EAP-Response/EAP-UTE -------------->| 634 | CLIENT COMPLETION REQUEST (5) | 635 | PeerId, Nonce_P, [OOB-Id] | 636 | | 637 |<- EAP-Request/EAP-UTE ----------------| 638 | SERVER COMPLETION RESPONSE (6) | 639 | [OOB-Id], Nonce_S, MAC_S | 640 | | 641 |-- EAP-Response/EAP-UTE -------------->| 642 | CLIENT FINISHED (4) | 643 | MAC_P | 644 | | 645 |<- EAP-Success ------------------------| 646 | | 648 Figure 4: Completion Exchange 650 3.3.5. Reconnect Exchange 652 The Reconnect Exchange is performed if both the peer and the server 653 are in the registered state. 655 For a reconnect without new exchanging of ECDHE keys, the peer will 656 answer to the Server Greeting with a Client Completion Request, 657 including the PeerId and a nonce. 659 To distinguish a Reconnect Exchange from a Waiting/Completion 660 Exchange, the server will look up the saved states for the 661 transmitted PeerId. If the server has a persistent state saved, it 662 will choose the Reconnect Exchange, otherwise it will choose the 663 Waiting Exchange. 665 The server will then generate a nonce and the MAC_S value according 666 to Section 3.4 and send a Server Completion Response with the nonce 667 and MAC_S value. 669 The peer then sends a Client Finished message, containing the 670 computed MAC_P value. 672 The server then answers with an EAP-Success. 674 EAP Peer Authenticator EAP Server 675 | | | 676 |<- EAP-Request/Identity -| | 677 | | 678 |-- EAP-Response/Identity ------------->| 679 | | 680 |<- EAP-Request/EAP-UTE ----------------| 681 | SERVER GREETING (1) | 682 | Versions, Ciphers, Server Info, | 683 | Directions | 684 | | 685 |-- EAP-Response/EAP-UTE -------------->| 686 | CLIENT COMPLETION REQUEST (5) | 687 | PeerId, Nonce_P | 688 | | 689 |<- EAP-Request/EAP-UTE ----------------| 690 | SERVER COMPLETION RESPONSE (6) | 691 | Nonce_S, MAC_S | 692 | | 693 |-- EAP-Response/EAP-UTE -------------->| 694 | CLIENT FINISHED (4) | 695 | MAC_P | 696 | | 697 |<- EAP-Success ------------------------| 698 | | 700 Figure 5: Reconnect Exchange without new ECDHE exchange 702 For a Reconnect Exchange with new ECDHE exchange, the peer will send 703 a Client Keyshare in response to the Server Greeting. The Client 704 Keyshare will include the PeerId, a nonce and a new ECDHE key. 706 The server will also generate a new ECDHE key, a nonce and compute 707 MAC_S according to Section 3.4. 709 The peer will then calculate the MAC_P value and send a Client 710 Finished message to the server. 712 The server then answers with an EAP-Success. 714 EAP Peer Authenticator EAP Server 715 | | | 716 |<- EAP-Request/Identity -| | 717 | | 718 |-- EAP-Response/Identity ------------->| 719 | | 720 |<- EAP-Request/EAP-UTE ----------------| 721 | SERVER GREETING (1) | 722 | Versions, Ciphers, Server Info, | 723 | Directions | 724 | | 725 |-- EAP-Response/EAP-UTE -------------->| 726 | CLIENT KEYSHARE (7) | 727 | PeerId, Nonce_P, Key_P | 728 | | 729 |<- EAP-Request/EAP-UTE ----------------| 730 | SERVER KEYSHARE (3) | 731 | Nonce_S, Key_S, MAC_S | 732 | | 733 |-- EAP-Response/EAP-UTE -------------->| 734 | CLIENT FINISHED (4) | 735 | MAC_P | 736 | | 737 |<- EAP-Success ------------------------| 738 | | 740 Figure 6: Reconnect Exchange with new ECDHE exchange 742 TODO: Reconnect exchange with updated version or cipher suite 744 3.4. MAC and OOB calculation and Key derivation 746 For the MAC calculation, the exchanged messages up to the current 747 message are concatenated into the "Messages" field. This field 748 consists for each message of the one octet message type, the two 749 octet encoding of the length and the CBOR encoded message payload. 750 The optional MAC value at the end of the message is omitted for the 751 MAC calculation. For the calculation of the MAC_S value, the 752 Messages field also includes the Server Keyshare/Server Completion 753 Response message. For MAC_P the Client Finished message is omitted, 754 so both MAC_P and MAC_S have the same input. 756 For the following definition || denotes a concatenation. 758 Messages = Type_1 || Length_1 || Payload_1 || ... || Type_n || 759 Length_n || Payload_n 761 OOB-Id = H(OOB-Nonce || Messages) 762 TODO: Calculation of MAC_S/MAC_P 764 Idea: For initial exchange MAC_S/MAC_P = HMAC(key, Messages), and for 765 completion exchange MAC_S/MAC_P = HMAC(key, prev_MAC_S || 766 prev_MAC_P || Messages) 768 TODO: Key derivation. Here I have a problem. If I want to send MACs 769 in the initial exchange, I somehow have to make a key derivation 770 already. Maybe this is too costly. Maybe it would only be necessary 771 to save a Hash of the previous messages during the InitialExchange 772 and include it in the KDF to cryptographically bind the Server/ 773 PeerInfo to the connection. This way, the Initial Exchange wont have 774 MACs, the integrity check is done completely by exchanging of MACs 775 during the Completion Exchange. This will probably be more clear in 776 the -01 draft version. 778 3.5. Error handling 780 TBD 782 4. Security Considerations 784 This document has a lot of security considerations, however they 785 remain TBD 787 4.1. EAP Security Claims 789 TODO. See [RFC3748], section 7.2.1 791 5. IANA Considerations 793 This document has IANA actions, if approved. What they are exactly 794 needs to be defined in detail. 796 The EAP Method Type number for EAP-UTE needs to be assigned. The 797 reference implementation will use 255 (Experimental) for now. 799 Like EAP-NOOB, this draft will probably use a .arpa domain, in this 800 case probably eap-ute.arpa, as default NAI realm. 802 Additionally, the IANA should create registries for the message types 803 and the message field mapkeys. 805 6. Implementation Status 807 Note to RFC Editor: Please remove this entire section before 808 publication. 810 There are no implementations yet. 812 7. Differences to RFC 9140 (EAP-NOOB) 814 In this section the main differences between EAP-NOOB and EAP-UTE are 815 discussed. Some problems of [RFC9140] are discussed in 816 [I-D.draft-rieckers-emu-eap-noob-observations]. 818 7.1. Different encoding 820 EAP-UTE uses CBOR instead of JSON. More text TBD. 822 7.2. Implicit transmission of peer state 824 In EAP-NOOB all EAP exchanges start with the same common handshake, 825 which mainly serves the purpose of detecting the current peer state. 827 The server initiates the EAP conversation by sending a Type 1 message 828 without any further content, to which the peer responds by sending 829 its PeerId, if it was assigned, and its PeerState. 831 In EAP-UTE, this peer state transmission is done implicitly by the 832 peer's choice of response to the Server Greeting. 834 This adds probably unnecessary bytes in the first packet from the 835 server to the peer, since the peer already knows the server's 836 supported versions, ciphers and the ServerInfo in the later 837 exchanges, especially in the Waiting/Completion Exchange. However, 838 this increased number of bytes is negligible in comparison to the 839 elevated expense of an additional roundtrip, since this would 840 significantly increase the authentication time, especially if the EAP 841 packets are routed through a number of proxies. 843 7.3. Extensibility 845 The EAP-NOOB standard does not specify how to deal with unexpected 846 labels in the message, which could be used to extend the protocol. 847 This specification will explicitly allow extensions. They are still 848 TBD. 850 8. References 852 8.1. Normative References 854 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 855 Requirement Levels", BCP 14, RFC 2119, 856 DOI 10.17487/RFC2119, March 1997, 857 . 859 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 860 Levkowetz, Ed., "Extensible Authentication Protocol 861 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 862 . 864 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 865 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 866 May 2017, . 868 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 869 Representation (CBOR)", STD 94, RFC 8949, 870 DOI 10.17487/RFC8949, December 2020, 871 . 873 8.2. Informative References 875 [I-D.draft-rieckers-emu-eap-noob-observations] 876 Rieckers, J., "Observations about EAP-NOOB (RFC 9140)", 877 Work in Progress, Internet-Draft, draft-rieckers-emu-eap- 878 noob-observations-00, 7 March 2022, 879 . 882 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 883 RFC 8152, DOI 10.17487/RFC8152, July 2017, 884 . 886 [RFC9140] Aura, T., Sethi, M., and A. Peltonen, "Nimble Out-of-Band 887 Authentication for EAP (EAP-NOOB)", RFC 9140, 888 DOI 10.17487/RFC9140, December 2021, 889 . 891 Acknowledgements 893 TBD 895 Author's Address 897 Jan-Frederik Rieckers 898 Deutsches Forschungsnetz | German National Research and Education Network 899 Alexanderplatz 1 900 10178 Berlin 901 Germany 902 Email: rieckers@dfn.de 903 URI: www.dfn.de