Internet Engineering Task Force J.-F. Rieckers Internet-Draft DFN Intended status: Standards Track 7 March 2022 Expires: 8 September 2022 User-assisted Trust Establishment (EAP-UTE) draft-rieckers-emu-eap-ute-00 Abstract The Extensible Authentication Protocol (EAP) provides support for multiple authentication methods. This document defines the EAP-UTE authentication method for a User-assisted Trust Establishment between the peer and the server. The EAP method is intended for bootstrapping Internet-of-Things (IoT) devices without preconfigured authentication credentials. The trust establishment is achieved by transmitting a one-directional out-of-band (OOB) message between the peer and the server to authenticate the in-band exchange. The peer must have a secondary input or output interface, such as a display, camera, microphone, speaker, blinking light, or light sensor, so that dynamically generated messages with tens of bytes in length can be transmitted or received. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-rieckers-emu-eap-ute/. Discussion of this document takes place on the EAP Method Update (emu) Working Group mailing list (mailto:emu@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/emu/. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Rieckers Expires 8 September 2022 [Page 1] Internet-Draft EAP-UTE March 2022 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 8 September 2022. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. EAP-UTE protocol . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Protocol Overview . . . . . . . . . . . . . . . . . . . . 4 3.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2.1. General Message format . . . . . . . . . . . . . . . 5 3.2.2. Server greeting . . . . . . . . . . . . . . . . . . . 8 3.2.3. Client greeting . . . . . . . . . . . . . . . . . . . 8 3.2.4. Server Keyshare . . . . . . . . . . . . . . . . . . . 9 3.2.5. Client Finished . . . . . . . . . . . . . . . . . . . 9 3.2.6. Client Completion Request . . . . . . . . . . . . . . 10 3.2.7. Server Completion Response . . . . . . . . . . . . . 10 3.2.8. Client Keyshare . . . . . . . . . . . . . . . . . . . 10 3.3. Protocol Sequence . . . . . . . . . . . . . . . . . . . . 10 3.3.1. Initial Exchange . . . . . . . . . . . . . . . . . . 11 3.3.2. User-assisted out-of-band step . . . . . . . . . . . 12 3.3.3. Waiting Exchange . . . . . . . . . . . . . . . . . . 12 3.3.4. Completion Exchange . . . . . . . . . . . . . . . . . 13 3.3.5. Reconnect Exchange . . . . . . . . . . . . . . . . . 14 3.4. MAC and OOB calculation and Key derivation . . . . . . . 16 3.5. Error handling . . . . . . . . . . . . . . . . . . . . . 17 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 4.1. EAP Security Claims . . . . . . . . . . . . . . . . . . . 17 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 Rieckers Expires 8 September 2022 [Page 2] Internet-Draft EAP-UTE March 2022 7. Differences to RFC 9140 (EAP-NOOB) . . . . . . . . . . . . . 18 7.1. Different encoding . . . . . . . . . . . . . . . . . . . 18 7.2. Implicit transmission of peer state . . . . . . . . . . . 18 7.3. Extensibility . . . . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . 18 8.2. Informative References . . . . . . . . . . . . . . . . . 19 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction This document describes a method for registration, authentication, and key derivation for network-connected devices, especially with low computational power and small or no interaction interfaces, such as devices that are part of the Internet of Things (IoT). These devices may come without preconfigured trust anchors or have no possibility to receive a network configuration that enables them to connect securely to a network. This document uses the basic design principle behind the EAP-NOOB method described in [RFC9140] and aims to improve some key elements of the protocol to better address the needs for IoT devices. This is mainly achieved by using CBOR with numeric keys instead of JSON to encode the exchanged messages. TODO: The EAP-UTE protocol also allows extensions, they are still TBD. Basically, the messages can just include additional fields with newly defined meanings. The possible problems of EAP-NOOB are discussed in [I-D.draft-rieckers-emu-eap-noob-observations]. This document provides a specification which aims to address these concerns. 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. TODO frequently used terms authenticator peer Rieckers Expires 8 September 2022 [Page 3] Internet-Draft EAP-UTE March 2022 server 3. EAP-UTE protocol This section defines the EAP-UTE method. 3.1. Protocol Overview TODO: The introduction text is basically copied from RFC9140. Should be reworded. The EAP-UTE method execution spans two or more EAP conversations, called Exchanges in this specification. Each Exchange consists of several EAP request-response pairs. In order to give the user time to deliver the OOB message between the peer and the server, at least two separate EAP conversations are needed. The overall protocol starts with a version and cryptosuite negotiation and peer detection. Depending of the current state of the peer and server, different exchanges are selected. If the server or the peer are in the unregistered state, peer and server exchange nonces and keys for the Ephemeral Elliptic Curve Diffie-Hellman. This is called the Initial Exchange. The Initial Exchange results in an EAP-Failure, since neither the server nor the peer are authenticated. After the Initial Exchange, the user-assisted step of trust establishment takes place. The user delivers one OOB message either from the peer to the server or from the server to the peer. While peer and server are waiting for completion of the OOB Step, the peer MAY probe the server by reconnecting, to check for successful transmission of the OOB message. This probe request will result in a Waiting Exchange and EAP-Failure, if the server has not yet received the OOB message. If either the server or the peer have received the OOB message, the probe request will result in a Completion Exchange. In the Completion Exchange, peer and server exchange message authentication codes over the previous in-band messages and the OOB message. The Completion Exchange may result in EAP-Success. Once the peer and server have performed a successful Completion Exchange, both endpoints store the created association in persistent storage. Rieckers Expires 8 September 2022 [Page 4] Internet-Draft EAP-UTE March 2022 After a successful Completion Exchange, the peer and server can use the Reconnect Exchange, to create a new association with new cryptographic bindings. The user-assisted OOB step is not necessary, since the peer and server can infer the mutual authentication by using the persistent data stored after the Completion Exchange. Waiting .------. | V +------------------+ +---------------------+ .->| Unregistered (0) | Initial | Waiting for OOB (1) | | | (ephemeral) |-------->| (ephemeral) | | +------------------+ +---------------------+ | | | | User Reset .-----------------' | OOB Input | | Completion | | | | | V V | +----------------+ +------------------+ '-| Registered (3) | Completion | OOB Received (2) | | (persistent) |<-----------| | +----------------+ +------------------+ Figure 1: EAP-UTE Server-Peer Association State Machine 3.2. Messages 3.2.1. General Message format All EAP-UTE messages consist of the following parts: type: one octet to indicate the type of the message length: two octets indicating the length of the following message payload, not including the optional MAC value payload: the CBOR encoded message MAC: (optional) the message authentication code Remark from the author: This format is just a first draft. It allows a very simple MAC calculation, since the MACs can just consist of the concatenated previous messages. This also allows an easy addition of extensions, since the extension payloads are automatically included in the MAC calculation, if they are part of the CBOR payload. The message payloads are encoded in CBOR [RFC8949] as maps. Rieckers Expires 8 September 2022 [Page 5] Internet-Draft EAP-UTE March 2022 In Table 1 the different message fields, their assigned mapkey and the type are listed. +========+==========+======================+========================+ | Mapkey | Type | Label |Description | +========+==========+======================+========================+ | 1 | Array of | Versions |The versions supported | | | Integers | |by the server. For this| | | | |document the version is | | | | |1 | +--------+----------+----------------------+------------------------+ | 2 | Integer | Version |The version selected by | | | | |the peer | +--------+----------+----------------------+------------------------+ | 3 | Array? | Ciphers |The ciphers supported by| | | | |the server. TODO: Not | | | | |yet sure how to define | | | | |them. | +--------+----------+----------------------+------------------------+ | 4 | Integer? | Cipher |The cipher selected by | | | | |the peer | +--------+----------+----------------------+------------------------+ | 5 | Integer | Directions |The OOB-Directions | | | | |supported by the server.| | | | |0x01 for peer-to-server,| | | | |0x02 for server-to-peer,| | | | |0x03 for both | +--------+----------+----------------------+------------------------+ | 6 | Integer | Direction |The OOB-Direction | | | | |selected by the peer. | | | | |SHOULD be either 0x01 or| | | | |0x02, but MAY be 0x03 | | | | |for both directions | +--------+----------+----------------------+------------------------+ | 7 | Map | ServerInfo |Information about the | | | | |server, e.g. a URL for | | | | |OOB-message-submission | +--------+----------+----------------------+------------------------+ | 8 | Map | PeerInfo |Information about the | | | | |peer, e.g. manufacturer/| | | | |serial number | +--------+----------+----------------------+------------------------+ | 9 | bytes | Nonce_P |Peer Nonce | +--------+----------+----------------------+------------------------+ | 10 | bytes | Nonce_S |Server Nonce | +--------+----------+----------------------+------------------------+ | 11 | ? | Key_P |Peer's ECDHE key | | | | |according to the chosen | Rieckers Expires 8 September 2022 [Page 6] Internet-Draft EAP-UTE March 2022 | | | |cipher | +--------+----------+----------------------+------------------------+ | 12 | ? | Key_S |Server's ECDHE key | +--------+----------+----------------------+------------------------+ | 13 | null | MAC_S |Indication that Server | | | | |MAC is included | +--------+----------+----------------------+------------------------+ | 14 | null | MAC_P |Indication that Peer MAC| | | | |is included | +--------+----------+----------------------+------------------------+ | 15 | text | PeerId |Peer Identifier | +--------+----------+----------------------+------------------------+ | 16 | bytes | OOB-Id |Identifier of the OOB | | | | |message | +--------+----------+----------------------+------------------------+ | 17 | int | RetryInterval |Number of seconds to | | | | |wait after a failed | | | | |Completion Exchange | +--------+----------+----------------------+------------------------+ | 18 | Map | AdditionalServerInfo |Additional information | | | | |about the server. TODO:| | | | |not sure about this yet.| +--------+----------+----------------------+------------------------+ Table 1: Mapkeys for CBOR encoding The inclusion of MAC_S or MAC_P indicate that the MAC value is appended to the message. The length of the MAC field is determined by the used cryptosuite. A message MUST NOT contain both MAC_S and MAC_P, only one of these values can be present in a message. TODO: Depending on the definition of the Cipher Suites, the format for Ciphers and Cipher might change, as well as Key_P and Key_S. The most immediate choice would be COSE [RFC8152]. But maybe there are better choices out there. 3.2.1.1. Thoughts about the message format EAP-NOOB [RFC9140] uses JSON as encoding. Problems of using JSON are discussed in section 2.1 of [I-D.draft-rieckers-emu-eap-noob-observations]. For this specification, the following encodings have been considered: * Static encoding This allows a minimal number of bytes and requires a minimal amount of parsing, since the format and order of the message fields is specified exactly. However, this encoding severely Rieckers Expires 8 September 2022 [Page 7] Internet-Draft EAP-UTE March 2022 affects the extensibility, unless a specific extension format is used. The specification of this protocol also has optional fields in some message types, so this would also have to be addressed. * CBOR with static fields (e.g. Array) This approach has a slightly higher number of bytes than the static encoding, but allows an easier extensibility. The required fields can be specified, so the order of the protocol field is static and a parser has minimal effort to parse the protocol fields. However, this might be problematic in future protocol versions, when new fields are introduced. Like with static encoding, this also requires a mechanism for optional fields in the different message types. * CBOR map with numeric keys To mitigate the problems of optional fields while keeping the parsing effort low, CBOR maps with numeric keys can be used. All protocol fields are identified by a unique identifier, specified in this document. A parser can simply loop through the CBOR map. Since CBOR maps have a canonical order, minimal implementations may rely on this fact to parse the information needed. On the basis of this discussion, this draft will use a CBOR map as message encoding. However, this is just a first draft and suggestions for other message formats are highly welcome. 3.2.2. Server greeting * Message Type: 1 * Required Attributes: - Versions - Ciphers - ServerInfo - Directions * Optional Attributes: - RetryInterval? 3.2.3. Client greeting * Message Type: 2 Rieckers Expires 8 September 2022 [Page 8] Internet-Draft EAP-UTE March 2022 * Required Attributes: - Version - Cipher - PeerInfo - Direction - Nonce_P - Key_P * Optional Attributes: - PeerId 3.2.4. Server Keyshare * Message Type: 3 * Required Attributes: - Key_S - Nonce_S - MAC_S * Optional Attributes: - PeerId - AdditionalServerInfo? - RetryInterval? TODO: Maybe make MAC_S optional, if used in Initial Exchange 3.2.5. Client Finished * Message Type: 4 * Required Attributes: - MAC_P Rieckers Expires 8 September 2022 [Page 9] Internet-Draft EAP-UTE March 2022 TODO: Maybe make MAC_P optional, if used in Initial Exchange 3.2.6. Client Completion Request * Message Type: 5 * Required Attributes: - Nonce_P - PeerId * Optional Attributes: - OOB-Id 3.2.7. Server Completion Response * Message Type: 6 * Required Attributes: - Nonce_S - MAC_S * Optional Attributes: - OOB-Id 3.2.8. Client Keyshare * Message Type: 7 * Required Attributes: - PeerId - Nonce_P - Key_P 3.3. Protocol Sequence After reception of the EAP-Response/Identity packet, the server always answers with a Server Greeting packet (Type 1). This Server Greeting contains the supported protocol versions, ciphers and OOB directions along with the ServerInfo. Rieckers Expires 8 September 2022 [Page 10] Internet-Draft EAP-UTE March 2022 Depending on the peer state, the peer chooses the next packet. If the peer is in the unregistered state and does not yet have an ephemeral or persistent state, it chooses the Client Greeting, which starts the Initial Handshake. If the peer is in the Waiting for OOB or OOB Received state, the Initial Exchange has completed and the OOB step needs to take place. If the negotiated direction is from server to peer, the peer SHOULD NOT try to reconnect until the peer received an OOB message. If the negotiated direction is from peer to server, the peer can probe the server at regular intervals to check if the OOB message to the server has been delivered. The peer will send a Client Completion Request to initiate the Waiting/Completion Exchange. If the peer is in the Registered state, it may choose between three different Reconnect Exchanges. If the peer wants a reconnect without new key exchanges, it will send a Client Completion Request, starting the Reconnect Exchange without ECDHE. If the peer wants to reconnect with new key exchanges, it will send a Client Key Share packet, which starts the Reconnect Exchange with new ECDHE exchange. The third option is a reconnect with a new version or cipher, this is TBD. 3.3.1. Initial Exchange The Initial Exchange comprises of the following packets: After the Server Greeting common to all exchanges, the peer sends a Client Greeting packet. The Client Greeting contains the peer's chosen protocol version, cipher and direction of the OOB message. The peer MUST only choose values for these fields offered by the server in it's Server Greeting. For Direction the peer SHOULD choose either 0x01 or 0x02 if the server offered 0x03. Additionally, the Client Greeting contains PeerInfo, a nonce and the peer's ECDHE public key. The server will then answer with a Server Keyshare packet. The packet contains a newly allocated PeerId, the server's nonce and ECDHE public key and the message authentication code MAC_S. The peer then answers with a Client Finished packet, containing the peer's message authentication code MAC_P. Since no authentication has yet been achieved, the server then answers with an EAP-Failure. Rieckers Expires 8 September 2022 [Page 11] Internet-Draft EAP-UTE March 2022 EAP Peer Authenticator EAP Server | | | |<- EAP-Request/Identity -| | | | |-- EAP-Response/Identity ------------->| | (NAI=new@eap-ute.arpa) | | | |<- EAP-Request/EAP-UTE ----------------| | SERVER GREETING (1) | | Versions, Ciphers, ServerInfo, | | Directions | | | |-- EAP-Response/EAP-UTE -------------->| | CLIENT GREETING (2) | | Version, Cipher, PeerInfo, | | Direction, Nonce_P, Key_P | | | |<- EAP-Request/EAP-UTE ----------------| | SERVER KEYSHARE (3) | | PeerId, Key_S, Nonce_S, MAC_S | | | |-- EAP-Response/EAP-UTE -------------->| | CLIENT FINISHED (4) | | MAC_P | | | |<- EAP-Failure ------------------------| | | Figure 2: Initial Exchange TODO: Do I need MACs here? What are they really for? (see Section 3.4 for more thoughts on this) 3.3.2. User-assisted out-of-band step After the completed Initial Exchange, the peer or the server, depending on the negotiated direction, will generate an OOB message. Details still TBD. 3.3.3. Waiting Exchange The Waiting Exchange is performed if neither the server nor the peer have received an OOB message yet. The peer probes the server with a Client Completion Request. In this packet the peer omits the optional OOB-Id field. If the OOB message is delivered from the peer to the server, the server may have Rieckers Expires 8 September 2022 [Page 12] Internet-Draft EAP-UTE March 2022 received an OOB message already. To allow the server to complete the association, the peer includes a nonce, along with the allocated PeerId. The nonce MAY be repeated for all Client Completion Requests while waiting for the completion. If the server did not receive an OOB message, it answers with an EAP- Failure. EAP Peer Authenticator EAP Server | | | |<- EAP-Request/Identity -| | | | |-- EAP-Response/Identity ------------->| | (NAI=waiting@eap-ute.arpa) | | | |<- EAP-Request/EAP-UTE ----------------| | SERVER GREETING (1) | | Versions, Ciphers, Server Info, | | Directions | | | |-- EAP-Response/EAP-UTE -------------->| | CLIENT COMPLETION REQUEST (5) | | PeerId, Nonce_P | | | |<- EAP-Failure ------------------------| | | Figure 3: Waiting Exchange 3.3.4. Completion Exchange The Completion Exchange is performed to finish the mutual trust establishment. As in the Waiting Exchange, the peer probes the server with a Client Completion Request. The nonce of the previous Client Completion Requests which did not lead to a completion MAY be repeated. If the peer has received an OOB message, the peer will include the OOB-Id in the Completion Request. If the peer did not include an OOB-Id, the server will include the OOB-Id of its received OOB message. In the unlikely case that both directions are negotiated and an OOB message is delivered from the peer to the server and from the server to the peer at the same time, as a tiebreaker, the OOB message from the server to the peer is chosen. The server generates a new nonce, calculates MAC_S according to Section 3.4 and sends a Server Completion Response to the peer. Rieckers Expires 8 September 2022 [Page 13] Internet-Draft EAP-UTE March 2022 The peer will then calculate the MAC_P value and send a Client Finished message to the server. The server then answers with an EAP-Success. EAP Peer Authenticator EAP Server | | | |<- EAP-Request/Identity -| | | | |-- EAP-Response/Identity ------------->| | (NAI=waiting@eap-ute.arpa) | | | |<- EAP-Request/EAP-UTE ----------------| | SERVER GREETING (1) | | Versions, Ciphers, Server Info, | | Directions | | | |-- EAP-Response/EAP-UTE -------------->| | CLIENT COMPLETION REQUEST (5) | | PeerId, Nonce_P, [OOB-Id] | | | |<- EAP-Request/EAP-UTE ----------------| | SERVER COMPLETION RESPONSE (6) | | [OOB-Id], Nonce_S, MAC_S | | | |-- EAP-Response/EAP-UTE -------------->| | CLIENT FINISHED (4) | | MAC_P | | | |<- EAP-Success ------------------------| | | Figure 4: Completion Exchange 3.3.5. Reconnect Exchange The Reconnect Exchange is performed if both the peer and the server are in the registered state. For a reconnect without new exchanging of ECDHE keys, the peer will answer to the Server Greeting with a Client Completion Request, including the PeerId and a nonce. To distinguish a Reconnect Exchange from a Waiting/Completion Exchange, the server will look up the saved states for the transmitted PeerId. If the server has a persistent state saved, it will choose the Reconnect Exchange, otherwise it will choose the Waiting Exchange. Rieckers Expires 8 September 2022 [Page 14] Internet-Draft EAP-UTE March 2022 The server will then generate a nonce and the MAC_S value according to Section 3.4 and send a Server Completion Response with the nonce and MAC_S value. The peer then sends a Client Finished message, containing the computed MAC_P value. The server then answers with an EAP-Success. EAP Peer Authenticator EAP Server | | | |<- EAP-Request/Identity -| | | | |-- EAP-Response/Identity ------------->| | | |<- EAP-Request/EAP-UTE ----------------| | SERVER GREETING (1) | | Versions, Ciphers, Server Info, | | Directions | | | |-- EAP-Response/EAP-UTE -------------->| | CLIENT COMPLETION REQUEST (5) | | PeerId, Nonce_P | | | |<- EAP-Request/EAP-UTE ----------------| | SERVER COMPLETION RESPONSE (6) | | Nonce_S, MAC_S | | | |-- EAP-Response/EAP-UTE -------------->| | CLIENT FINISHED (4) | | MAC_P | | | |<- EAP-Success ------------------------| | | Figure 5: Reconnect Exchange without new ECDHE exchange For a Reconnect Exchange with new ECDHE exchange, the peer will send a Client Keyshare in response to the Server Greeting. The Client Keyshare will include the PeerId, a nonce and a new ECDHE key. The server will also generate a new ECDHE key, a nonce and compute MAC_S according to Section 3.4. The peer will then calculate the MAC_P value and send a Client Finished message to the server. The server then answers with an EAP-Success. Rieckers Expires 8 September 2022 [Page 15] Internet-Draft EAP-UTE March 2022 EAP Peer Authenticator EAP Server | | | |<- EAP-Request/Identity -| | | | |-- EAP-Response/Identity ------------->| | | |<- EAP-Request/EAP-UTE ----------------| | SERVER GREETING (1) | | Versions, Ciphers, Server Info, | | Directions | | | |-- EAP-Response/EAP-UTE -------------->| | CLIENT KEYSHARE (7) | | PeerId, Nonce_P, Key_P | | | |<- EAP-Request/EAP-UTE ----------------| | SERVER KEYSHARE (3) | | Nonce_S, Key_S, MAC_S | | | |-- EAP-Response/EAP-UTE -------------->| | CLIENT FINISHED (4) | | MAC_P | | | |<- EAP-Success ------------------------| | | Figure 6: Reconnect Exchange with new ECDHE exchange TODO: Reconnect exchange with updated version or cipher suite 3.4. MAC and OOB calculation and Key derivation For the MAC calculation, the exchanged messages up to the current message are concatenated into the "Messages" field. This field consists for each message of the one octet message type, the two octet encoding of the length and the CBOR encoded message payload. The optional MAC value at the end of the message is omitted for the MAC calculation. For the calculation of the MAC_S value, the Messages field also includes the Server Keyshare/Server Completion Response message. For MAC_P the Client Finished message is omitted, so both MAC_P and MAC_S have the same input. For the following definition || denotes a concatenation. Messages = Type_1 || Length_1 || Payload_1 || ... || Type_n || Length_n || Payload_n OOB-Id = H(OOB-Nonce || Messages) Rieckers Expires 8 September 2022 [Page 16] Internet-Draft EAP-UTE March 2022 TODO: Calculation of MAC_S/MAC_P Idea: For initial exchange MAC_S/MAC_P = HMAC(key, Messages), and for completion exchange MAC_S/MAC_P = HMAC(key, prev_MAC_S || prev_MAC_P || Messages) TODO: Key derivation. Here I have a problem. If I want to send MACs in the initial exchange, I somehow have to make a key derivation already. Maybe this is too costly. Maybe it would only be necessary to save a Hash of the previous messages during the InitialExchange and include it in the KDF to cryptographically bind the Server/ PeerInfo to the connection. This way, the Initial Exchange wont have MACs, the integrity check is done completely by exchanging of MACs during the Completion Exchange. This will probably be more clear in the -01 draft version. 3.5. Error handling TBD 4. Security Considerations This document has a lot of security considerations, however they remain TBD 4.1. EAP Security Claims TODO. See [RFC3748], section 7.2.1 5. IANA Considerations This document has IANA actions, if approved. What they are exactly needs to be defined in detail. The EAP Method Type number for EAP-UTE needs to be assigned. The reference implementation will use 255 (Experimental) for now. Like EAP-NOOB, this draft will probably use a .arpa domain, in this case probably eap-ute.arpa, as default NAI realm. Additionally, the IANA should create registries for the message types and the message field mapkeys. 6. Implementation Status Note to RFC Editor: Please remove this entire section before publication. Rieckers Expires 8 September 2022 [Page 17] Internet-Draft EAP-UTE March 2022 There are no implementations yet. 7. Differences to RFC 9140 (EAP-NOOB) In this section the main differences between EAP-NOOB and EAP-UTE are discussed. Some problems of [RFC9140] are discussed in [I-D.draft-rieckers-emu-eap-noob-observations]. 7.1. Different encoding EAP-UTE uses CBOR instead of JSON. More text TBD. 7.2. Implicit transmission of peer state In EAP-NOOB all EAP exchanges start with the same common handshake, which mainly serves the purpose of detecting the current peer state. The server initiates the EAP conversation by sending a Type 1 message without any further content, to which the peer responds by sending its PeerId, if it was assigned, and its PeerState. In EAP-UTE, this peer state transmission is done implicitly by the peer's choice of response to the Server Greeting. This adds probably unnecessary bytes in the first packet from the server to the peer, since the peer already knows the server's supported versions, ciphers and the ServerInfo in the later exchanges, especially in the Waiting/Completion Exchange. However, this increased number of bytes is negligible in comparison to the elevated expense of an additional roundtrip, since this would significantly increase the authentication time, especially if the EAP packets are routed through a number of proxies. 7.3. Extensibility The EAP-NOOB standard does not specify how to deal with unexpected labels in the message, which could be used to extend the protocol. This specification will explicitly allow extensions. They are still TBD. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Rieckers Expires 8 September 2022 [Page 18] Internet-Draft EAP-UTE March 2022 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . 8.2. Informative References [I-D.draft-rieckers-emu-eap-noob-observations] Rieckers, J., "Observations about EAP-NOOB (RFC 9140)", Work in Progress, Internet-Draft, draft-rieckers-emu-eap- noob-observations-00, 7 March 2022, . [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", RFC 8152, DOI 10.17487/RFC8152, July 2017, . [RFC9140] Aura, T., Sethi, M., and A. Peltonen, "Nimble Out-of-Band Authentication for EAP (EAP-NOOB)", RFC 9140, DOI 10.17487/RFC9140, December 2021, . Acknowledgements TBD Author's Address Jan-Frederik Rieckers Deutsches Forschungsnetz | German National Research and Education Network Alexanderplatz 1 10178 Berlin Germany Email: rieckers@dfn.de URI: www.dfn.de Rieckers Expires 8 September 2022 [Page 19]