RFC 9140: Nimble Out-of-Band Authentication for EAP (EAP-NOOB)

3.1. Protocol Overview

One EAP-NOOB method execution spans two or more EAP conversations, called Exchanges in this specification. Each Exchange consists of several EAP request-response pairs. At least two separate EAP conversations are needed to give the human user time to deliver the OOB message between them.¶

The overall protocol starts with the Initial Exchange, which comprises four EAP request-response pairs. In the Initial Exchange, the server allocates an identifier to the peer, and the server and peer negotiate the protocol version and cryptosuite (i.e., cryptographic algorithm suite), exchange nonces, and perform an Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key exchange. The user-assisted OOB Step then takes place. This step requires only one out-of-band message, either from the peer to the server or from the server to the peer. While waiting for the OOB Step action, the peer MAY probe the server by reconnecting to it with EAP-NOOB. If the OOB Step has already taken place, the probe leads to the Completion Exchange, which completes the mutual authentication and key confirmation. On the other hand, if the OOB Step has not yet taken place, the probe leads to the Waiting Exchange, and the peer will perform another probe after a server-defined minimum waiting time. The Initial Exchange and Waiting Exchange always end in EAP-Failure, while 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, and the OOB Step is not repeated. Thereafter, creation of new temporal keys, ECDHE rekeying, and updates of cryptographic algorithms can be achieved with the Reconnect Exchange.¶

                                    OOB Output/Initial Exchange/
                                               Waiting Exchange
                                                 .-----.
                                                 |     v
     .------------------.   Initial       .------------------.
     |                  |   Exchange      |                  |
  .->| Unregistered (0) |---------------->|Waiting for OOB(1)|
  |  |   (ephemeral)    |                 |   (ephemeral)    |
  |  |                  |                 |                  |
  |  '------------------'                 '------------------'
  |                                         |      |      ^
 User Reset                 Completion      |      |      |
  |                         Exchange        |     OOB   OOB
  |<-------.      .-------------------------'    Input  Reject/
  |        |      |                                |    Initial
  |        |      |                                |    Exchange
  |        |      v                                v      |
  |  .------------------.   Completion    .------------------.
  |  |                  |   Exchange      |                  |
  |  |  Registered (4)  |<----------------| OOB Received (2) |
  |  |   (persistent)   |                 |   (ephemeral)    |
  |  |                  |                 |                  |
  |  '------------------'                 '------------------'
  |        |      ^
  |  Mobility/    |
  |  Timeout/   Reconnect
  |  Failure    Exchange
  |        |      |
  |        v      |
  |  .------------------.
  |  |                  |
  '--| Reconnecting (3) |
     |   (persistent)   |
     |                  |
     '------------------'

Figure 1 shows the association state machine, which is the same for the server and for the peer. (For readability, only the main state transitions are shown. The complete table of transitions can be found in Appendix A.) When the peer initiates the EAP-NOOB method, the server chooses the ensuing message exchange based on the combination of the server and peer states. The EAP server and peer are initially in the Unregistered (0) state, in which no state information needs to be stored. Before a successful Completion Exchange, the server-peer association state is ephemeral in both the server and peer (ephemeral states 0..2), and a timeout or error may cause one or both endpoints to go back to the Unregistered (0) state so that the Initial Exchange is repeated. After the Completion Exchange has resulted in EAP-Success, the association state becomes persistent (persistent states 3..4). Only user reset or memory failure can cause the return of the server or the peer from the persistent states to the ephemeral states and to the Initial Exchange.¶

The server MUST NOT repeat a successful OOB Step with the same peer except if the association with the peer is explicitly reset by the user or lost due to failure of the persistent storage in the server. More specifically, once the association has entered the Registered (4) state, the server MUST NOT delete the association or go back to the ephemeral states 0..2 without explicit user approval. Similarly, the peer MUST NOT repeat the OOB Step unless the user explicitly deletes the association with the server from the peer or resets the peer to the Unregistered (0) state. The server and peer MAY implement user reset of the association by deleting the state data from that endpoint. If an endpoint continues to store data about the association after the user reset, its behavior MUST be equivalent to having deleted the association data.¶

It can happen that the peer accidentally (or through user reset) loses its persistent state and reconnects to the server without a previously allocated peer identifier. In that case, the server MUST treat the peer as a new peer. The server MAY use auxiliary information, such as the PeerInfo field received in the Initial Exchange, to detect multiple associations with the same peer. However, it MUST NOT delete or merge redundant associations without user or application approval because EAP-NOOB internally has no secure way of verifying that the two peers are the same physical device. Similarly, the server might lose the association state because of a memory failure or user reset. In that case, the only way to recover is that the user also resets the peer.¶

A special feature of the EAP-NOOB method is that the server is not assumed to have any a priori knowledge of the peer. Therefore, the peer initially uses the generic identity string "noob@eap-noob.arpa" as its Network Access Identifier (NAI). The server then allocates a server-specific identifier to the peer. The generic NAI serves two purposes: firstly, it tells the server that the peer supports and expects the EAP-NOOB method; secondly, it allows routing of the EAP-NOOB sessions to a specific authentication server in an Authentication, Authorization, and Accounting (AAA) architecture.¶

EAP-NOOB is an unusual EAP method in that the peer has to have multiple EAP conversations with the server before it can receive EAP-Success. The reason is that, while EAP allows delays between the request-response pairs, e.g., for repeated password entry, the user delays in OOB authentication can be much longer than in password trials. Moreover, EAP-NOOB supports peers with no input capability in the user interface (e.g., LED light bulbs). Since users cannot initiate the protocol in these devices, the devices have to perform the Initial Exchange opportunistically and hope for the OOB Step to take place within a timeout period (NoobTimeout), which is why the timeout needs to be several minutes rather than seconds. To support such high-latency OOB channels, the peer and server perform the Initial Exchange in one EAP conversation, then allow time for the OOB message to be delivered, and later perform the Waiting Exchange and Completion Exchange in different EAP conversations.¶

3.2. Protocol Messages and Sequences

This section defines the EAP-NOOB exchanges, which correspond to EAP conversations. The exchanges start with a common handshake, which determines the type of the following exchange. The common handshake messages and the subsequent messages for each exchange type are listed in the diagrams below. The diagrams also specify the data fields present in each message. Each exchange comprises multiple EAP request-response pairs and ends in either EAP-Failure, indicating that authentication is not (yet) successful, or in EAP-Success.¶

EAP Peer                      Authenticator    EAP Server
  |                                   |              |
  |<----------- EAP-Request/Identity -|              |
  |                                                  |
  |                                                  |
  |------------ EAP-Response/Identity -------------->|
  |      (NAI=noob@eap-noob.arpa)                    |
  |                                                  |
  |                                                  |
  |<----------- EAP-Request/EAP-NOOB ----------------|
  |      (Type=1)                                    |
  |                                                  |
  |                                                  |
  |------------ EAP-Response/EAP-NOOB -------------->|
  |      (Type=1,[PeerId],PeerState=1)               |
  |                                                  |
  |  continuing with exchange-specific messages...   |

EAP Peer                                        EAP Server
  |       ...continuing from common handshake        |
  |                                                  |
  |<----------- EAP-Request/EAP-NOOB ----------------|
  |      (Type=2,Vers,PeerId,[NewNAI],               |
  |       Cryptosuites,Dirs,ServerInfo)              |
  |                                                  |
  |                                                  |
  |------------ EAP-Response/EAP-NOOB -------------->|
  |      (Type=2,Verp,PeerId,Cryptosuitep,           |
  |        Dirp,PeerInfo)                            |
  |                                                  |
  |                                                  |
  |<----------- EAP-Request/EAP-NOOB ----------------|
  |      (Type=3,PeerId,PKs,Ns,[SleepTime])          |
  |                                                  |
  |                                                  |
  |------------ EAP-Response/EAP-NOOB -------------->|
  |      (Type=3,PeerId,PKp,Np)                      |
  |                                                  |
  |                                                  |
  |<----------- EAP-Failure -------------------------|
  |                                                  |

EAP Peer                                        EAP Server
  |                                                  |
  |=================OOB=============================>|
  |             (PeerId,Noob,Hoob)                   |
  |                                                  |

EAP Peer                                        EAP Server
  |                                                  |
  |<================OOB==============================|
  |             (PeerId,Noob,Hoob)                   |
  |                                                  |

EAP Peer                                        EAP Server
  |       ...continuing from common handshake        |
  |                                                  |
  |<----------- [ EAP-Request/EAP-NOOB ] ------------|
  |      (Type=5,PeerId)                             |
  |                                                  |
  |                                                  |
  |------------ [ EAP-Response/EAP-NOOB ] ---------->|
  |      (Type=5,PeerId,NoobId)                      |
  |                                                  |
  |                                                  |
  |<----------- EAP-Request/EAP-NOOB ----------------|
  |      (Type=6,PeerId,NoobId,MACs)                 |
  |                                                  |
  |                                                  |
  |------------ EAP-Response/EAP-NOOB -------------->|
  |      (Type=6,PeerId,MACp)                        |
  |                                                  |
  |                                                  |
  |<----------- EAP-Success -------------------------|
  |                                                  |

EAP Peer                                        EAP Server
  |       ...continuing from common handshake        |
  |                                                  |
  |<----------- EAP-Request/EAP-NOOB ----------------|
  |      (Type=4,PeerId,[SleepTime])                 |
  |                                                  |
  |                                                  |
  |------------ EAP-Response/EAP-NOOB -------------->|
  |      (Type=4,PeerId)                             |
  |                                                  |
  |                                                  |
  |<----------- EAP-Failure -------------------------|
  |                                                  |

3.3. Protocol Data Fields

This section defines the various identifiers and data fields used in the EAP-NOOB method.¶

Hoob = H(Dir,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,
Cryptosuitep,Dirp,NAI,PeerInfo,0,PKs,Ns,PKp,Np,Noob).

NoobId = H("NoobId",Noob).

MACs = HMAC(Kms; 2,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,
Cryptosuitep,Dirp,NAI,PeerInfo,0,PKs,Ns,PKp,Np,Noob).

MACp = HMAC(Kmp; 1,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,
Cryptosuitep,Dirp,NAI,PeerInfo,0,PKs,Ns,PKp,Np,Noob).

MACs2 = HMAC(Kms2; 2,Vers,Verp,PeerId,Cryptosuites,"",[ServerInfo],
Cryptosuitep,"",NAI,[PeerInfo],KeyingMode,[PKs2],Ns2,[PKp2],Np2,"")

MACp2 = HMAC(Kmp2; 1,Vers,Verp,PeerId,Cryptosuites,"",[ServerInfo],
Cryptosuitep,"",NAI,[PeerInfo],KeyingMode,[PKs2],Ns2,[PKp2],Np2,"")

3.4. Fast Reconnect and Rekeying

EAP-NOOB implements fast reconnect ([RFC3748], Section 7.2.1), which avoids repeated use of the user-assisted OOB channel.¶

The rekeying and the Reconnect Exchange may be needed for several reasons. New EAP output values Main Session Key (MSK) and Extended Main Session Key (EMSK) may be needed because of mobility or timeout of session keys. Software or hardware failure or user action may also cause the authenticator, EAP server, or peer to lose its nonpersistent state data. The failure would typically be detected by the peer or authenticator when session keys are no longer accepted by the other endpoint. Changes in the supported cryptosuites in the EAP server or peer may also cause the need for a new key exchange. When the EAP server or peer detects any one of these events, it MUST change from the Registered (4) state to the Reconnecting (3) state. These state transitions are labeled Mobility/Timeout/Failure in Figure 1. The EAP-NOOB method will then perform the Reconnect Exchange the next time when EAP is triggered.¶

EAP Peer                                        EAP Server
  |       ...continuing from common handshake        |
  |                                                  |
  |<----------- EAP-Request/EAP-NOOB ----------------|
  |      (Type=7,Vers,PeerId,Cryptosuites,           |
  |       [NewNAI],[ServerInfo])                     |
  |                                                  |
  |                                                  |
  |------------ EAP-Response/EAP-NOOB -------------->|
  |      (Type=7,Verp,PeerId,Cryptosuitep,[PeerInfo])|
  |                                                  |
  |                                                  |
  |<----------- EAP-Request/EAP-NOOB ----------------|
  |      (Type=8,PeerId,KeyingMode,[PKs2],Ns2)       |
  |                                                  |
  |                                                  |
  |------------ EAP-Response/EAP-NOOB -------------->|
  |      (Type=8,PeerId,[PKp2],Np2)                  |
  |                                                  |
  |                                                  |
  |<----------- EAP-Request/EAP-NOOB ----------------|
  |      (Type=9,PeerId,MACs2)                       |
  |                                                  |
  |                                                  |
  |------------ EAP-Response/EAP-NOOB -------------->|
  |      (Type=9,PeerId,MACp2)                       |
  |                                                  |
  |                                                  |
  |<----------- EAP-Success -------------------------|
  |                                                  |

3.5. Key Derivation

EAP-NOOB derives the EAP output values MSK and EMSK and other secret keying material from the output of an Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) algorithm following the NIST specification [NIST-DH]. In NIST terminology, we use a C(2e, 0s, ECC CDH) scheme, i.e., two ephemeral keys and no static keys. In the Initial Exchange and Reconnect Exchange, the server and peer compute the ECDHE shared secret Z, as defined in Section 6.1.2 of the NIST specification [NIST-DH]. In the Completion Exchange and Reconnect Exchange, the server and peer compute the secret keying material from Z with the one-step key derivation function (KDF) defined in Section 5.8.2.1 of the NIST specification. The auxiliary function H is a hash function, and it is taken from the negotiated cryptosuite.¶

The key derivation has four different modes (KeyingMode), which are specified in Table 3. Table 4 defines the inputs to KDF in each KeyingMode.¶

In the Completion Exchange (KeyingMode=0), the input Z comes from the preceding Initial exchange. The KDF takes some additional inputs (FixedInfo), for which we use the concatenation format defined in Section 5.8.2.1.1 of the NIST specification [NIST-DH]. FixedInfo consists of the AlgorithmId, PartyUInfo, PartyVInfo, and SuppPrivInfo fields. The first three fields are fixed-length bit strings, and SuppPrivInfo is a variable-length string with a one-byte Datalength counter. AlgorithmId is the fixed-length, 8-byte ASCII string "EAP-NOOB". The other input values are the server and peer nonces. In the Completion Exchange, the inputs also include the secret nonce Noob from the OOB message.¶

In the simplest form of the Reconnect Exchange (KeyingMode=1), fresh nonces are exchanged, but no ECDHE keys are sent. In this case, input Z to the KDF is replaced with the shared key Kz from the persistent EAP-NOOB association. The result is rekeying without the computational cost of the ECDHE exchange but also without forward secrecy.¶

When forward secrecy is desired in the Reconnect Exchange (KeyingMode=2 or KeyingMode=3), both nonces and ECDHE keys are exchanged. Input Z is the fresh shared secret from the ECDHE exchange with PKs2 and PKp2. The inputs also include the shared secret Kz from the persistent EAP-NOOB association. This binds the rekeying output to the previously authenticated keys.¶

Table 5 defines how the output bytes of the KDF are used. In addition to the EAP output values MSK and EMSK, the server and peer derive another shared secret key AMSK (Application Main Session Key), which MAY be used for application-layer security. Further output bytes are used internally by EAP-NOOB for the message authentication keys (Kms, Kmp, Kms2, and Kmp2).¶

The Completion Exchange (KeyingMode=0) produces the shared secret Kz, which the server and peer store in the persistent EAP-NOOB association. When a new cryptosuite is negotiated in the Reconnect Exchange (KeyingMode=3), it similarly produces a new Kz. In that case, the server and peer update both the cryptosuite and Kz in the persistent EAP-NOOB association. Additionally, the peer stores the previous Cryptosuitep and Kz values in the CryptosuitepPrev and KzPrev fields of the persistent EAP-NOOB association.¶

Finally, every EAP method must export a Server-Id, Peer-Id, and Session-Id [RFC5247]. In EAP-NOOB, the exported Peer-Id is the PeerId that the server has assigned to the peer. The exported Server-Id is a zero-length string (i.e., null string) because EAP-NOOB neither knows nor assigns any server identifier. The exported Session-Id is created by concatenating the one-byte Type-Code 0x38 (decimal value 56) with the MethodId, which is obtained from the KDF output, as shown in Table 5.¶

3.6. Error Handling

Various error conditions in EAP-NOOB are handled by sending an error notification message (Type=0) instead of a next EAP request or response message. Both the EAP server and the peer may send the error notification, as shown in Figures 9 and 10. After sending or receiving an error notification, the server MUST send an EAP-Failure (as required by [RFC3748], Section 4.2). The notification MAY contain an ErrorInfo field, which is a UTF-8-encoded text string with a maximum length of 500 bytes. It is used for sending descriptive information about the error for logging and debugging purposes.¶

EAP Peer                                        EAP Server
  ...                                                ...
  |                                                  |
  |<----------- EAP-Request/EAP-NOOB ----------------|
  |        (Type=0,[PeerId],ErrorCode,[ErrorInfo])   |
  |                                                  |
  |                                                  |
  |<----------- EAP-Failure -------------------------|
  |                                                  |

EAP Peer                                        EAP Server
  ...                                                ...
  |                                                  |
  |------------ EAP-Response/EAP-NOOB -------------->|
  |        (Type=0,[PeerId],ErrorCode,[ErrorInfo])   |
  |                                                  |
  |                                                  |
  |<----------- EAP-Failure -------------------------|
  |                                                  |

After the exchange fails due to an error notification, the server and peer set the association state as follows. In the Initial Exchange, both the sender and recipient of the error notification MUST set the association state to the Unregistered (0) state. In the Waiting Exchange and Completion Exchange, each side MUST remain in its old state as if the failed exchange had not taken place, with the exception that the recipient of error code 2003 processes it as specified in Section 3.2.4. In the Reconnect Exchange, both sides MUST set the association state to the Reconnecting (3) state.¶

Errors that occur in the OOB channel are not explicitly notified in-band.¶

5.1. Cryptosuites

IANA has created and will maintain a new subregistry entitled "EAP-NOOB Cryptosuites" in the "Nimble Out-of-Band Authentication for EAP Parameters (EAP-NOOB)" registry. Cryptosuites are identified by an integer. Each cryptosuite MUST specify an ECDHE curve for the key exchange, encoding of the ECDHE public key as a JWK object, and a cryptographic hash function for the fingerprint and HMAC computation and key derivation. The hash value output by the cryptographic hash function MUST be at least 32 bytes in length. The initial values for this registry are:¶

EAP-NOOB implementations MUST support Cryptosuite 1. Support for Cryptosuite 2 is RECOMMENDED. An example of a Cryptosuite 1 public-key encoded as a JWK object is given below. (Line breaks are for readability only.)¶

"jwk":{"kty":"OKP","crv":"X25519","x":"3p7bfXt9wbTTW2HC7OQ1Nz-
DQ8hbeGdNrfx-FG-IK08"}

Assignment of new values for new cryptosuites MUST be done through IANA with "Specification Required", as defined in [RFC8126].¶

5.2. Message Types

IANA has created and will maintain a new subregistry entitled "EAP-NOOB Message Types" in the "Nimble Out-of-Band Authentication for EAP Parameters (EAP-NOOB)" registry. EAP-NOOB request and response pairs are identified by an integer Message Type. The initial values for this registry are:¶

Assignment of new values for new Message Types MUST be done through IANA with "Specification Required", as defined in [RFC8126].¶

5.3. Error Codes

IANA has created and will maintain a new subregistry entitled "EAP-NOOB Error codes" in the "Nimble Out-of-Band Authentication for EAP Parameters (EAP-NOOB)" registry. Cryptosuites are identified by an integer. The initial values for this registry are:¶

Assignment of new error codes MUST be done through IANA with "Specification Required", as defined in [RFC8126], except for the range 6001-6999. This range is reserved for "Private Use" and "Experimental Use", both locally and on the open Internet.¶

5.4. ServerInfo Data Fields

IANA has created and will maintain a new subregistry entitled "EAP-NOOB ServerInfo Data Fields" in the "Nimble Out-of-Band Authentication for EAP Parameters (EAP-NOOB)" registry. The initial values for this registry are:¶

Assignment of new values for new ServerInfo data fields MUST be done through IANA with "Specification Required", as defined in [RFC8126].¶

5.5. PeerInfo Data Fields

IANA is requested to create and maintain a new subregistry entitled "EAP-NOOB PeerInfo Data Fields" in the "Nimble Out-of-Band Authentication for EAP Parameters (EAP-NOOB)" registry. The initial values for this registry are:¶

Assignment of new values for new PeerInfo data fields MUST be done through IANA with "Specification Required", as defined in [RFC8126].¶

5.6. Domain Name Reservation

The special-use domain "eap-noob.arpa" has been registered in the .arpa registry (https://www.iana.org/domains/arpa) and the "Special-Use Domain Names" registry (https://www.iana.org/assignments/special-use-domain-names).¶

5.7. Guidance for Designated Experts

Experts SHOULD be conservative in the allocation of new Cryptosuites. Experts MUST ascertain that the requested values match the current Crypto Forum Research Group (CFRG) guidance on cryptographic algorithm security. Experts MUST ensure that any new Cryptosuites fully specify the encoding of the ECDHE public key and should include details, such as the value of the "kty" (key type) parameter when JWK [RFC7517] encoding is used.¶

Experts SHOULD be conservative in the allocation of new Message Types. Experts SHOULD ascertain that a well-defined specification for the new Message Type is permanently and publicly available.¶

Experts SHOULD be conservative in the allocation of new Error codes, since the 6001-6999 range is already reserved for private and experimental use.¶

Experts MAY be liberal in the allocation of new ServerInfo and PeerInfo data fields. Experts MUST ensure that the data field requested has a unique name that is not easily confused with existing registrations. For example, requests for a new PeerInfo data field "ssid" should be rejected even though it is unique because it can be confused with the existing registration of "SSID". Experts MUST ensure that a suitable Description for the data field is available.¶

6.1. Authentication Principle

EAP-NOOB establishes a shared secret with an authenticated ECDHE key exchange. The mutual authentication in EAP-NOOB is based on two separate features, both conveyed in the OOB message. The first authentication feature is the secret nonce Noob. The peer and server use this secret in the Completion Exchange to mutually authenticate the session key previously created with ECDHE. The message authentication codes computed with the secret nonce Noob are alone sufficient for authenticating the key exchange. The second authentication feature is the integrity-protecting fingerprint Hoob. Its purpose is to prevent impersonation attacks even in situations where the attacker is able to eavesdrop on the OOB channel and the nonce Noob is compromised. In some human-assisted OOB channels, such as human-perceptible audio or a user-typed URL, it may be easier to detect tampering than disclosure of the OOB message, and such applications benefit from the second authentication feature.¶

The additional security provided by the cryptographic fingerprint Hoob is somewhat intricate to understand. The endpoint that receives the OOB message uses Hoob to verify the integrity of the ECDHE exchange. Thus, the OOB receiver can detect impersonation attacks that may have happened on the in-band channel. The other endpoint, however, is not equally protected because the OOB message and fingerprint are sent only in one direction. Some protection to the OOB sender is afforded by the fact that the user may notice the failure of the association at the OOB receiver and therefore reset the OOB sender. Other device-pairing protocols have solved similar situations by requiring the user to confirm to the OOB sender that the association was accepted by the OOB receiver, e.g., with a button press on the sender side. Applications MAY implement EAP-NOOB in this way. Nevertheless, since EAP-NOOB was designed to work with strictly one-directional OOB communication and the fingerprint is only the second authentication feature, the EAP-NOOB specification does not mandate such explicit confirmation to the OOB sender.¶

To summarize, EAP-NOOB uses the combined protection of the secret nonce Noob and the cryptographic fingerprint Hoob, both conveyed in the OOB message. The secret nonce Noob alone is sufficient for mutual authentication unless the attacker can eavesdrop on it from the OOB channel. Even if an attacker is able to eavesdrop on the secret nonce Noob, it nevertheless cannot perform a full impersonation attack on the in-band channel because a mismatching fingerprint would alert the OOB receiver, which would reject the OOB message. The attacker that eavesdropped on the secret nonce can impersonate the OOB receiver to the OOB sender. If it does, the association will appear to be complete only on the OOB sender side, and such situations have to be resolved by the user by resetting the OOB sender to the initial state.¶

The expected use cases for EAP-NOOB are ones where it replaces a user-entered access credential in IoT appliances. In wireless network access without EAP, the user-entered credential is often a passphrase that is shared by all the network stations. The advantage of an EAP-based solution, including EAP-NOOB, is that it establishes a different shared secret for each peer device, which makes the system more resilient against device compromise. Another advantage is that it is possible to revoke the security association for an individual device on the server side.¶

Forward secrecy during fast reconnect in EAP-NOOB is optional. The Reconnect Exchange in EAP-NOOB provides forward secrecy only if both the server and peer send their fresh ECDHE keys. This allows both the server and peer to limit the frequency of the costly computation that is required for forward secrecy. The server MAY adjust the frequency of its attempts at ECDHE rekeying based on what it knows about the peer's computational capabilities.¶

Another way in which some servers may control their computational load is to reuse the same ECDHE key for all peers over a short server-specific time window. In that case, forward secrecy will be achieved only after the server updates its ECDHE key, which may be a reasonable trade-off between security and performance. However, the server MUST NOT reuse the same ECDHE key with the same peer when rekeying with ECDHE (KeyingMode=2 or KeyingMode=3). Instead, it can simply not send an ECDHE key (KeyingMode=1).¶

The users delivering the OOB messages will often authenticate themselves to the EAP server, e.g., by logging into a secure web page or API. In this case, the server can associate the peer device with the user account. Applications that make use of EAP-NOOB can use this information for configuring the initial owner of the freshly registered device.¶

6.2. Identifying Correct Endpoints

Potential weaknesses in EAP-NOOB arise from the fact that the user must physically identify the correct peer device. If the user mistakenly delivers the OOB message from the wrong peer device to the server, the server may create an association with the wrong peer. The reliance on the user in identifying the correct endpoints is an inherent property of user-assisted, out-of-band authentication. To understand the potential consequences of the user mistake, we need to consider a few different scenarios. In the first scenario, there is no malicious party, and the user makes an accidental mistake between two out-of-the-box devices that are both ready to be registered to a server. If the user delivers the OOB message from the wrong device to the server, confusion may arise but usually no security issues. In the second scenario, an attacker intentionally tricks the user, for example, by substituting the original peer device with a compromised one. This is essentially a supply chain attack where the user accepts a compromised physical device.¶

There is also a third scenario, in which an opportunistic attacker tries to take advantage of the user's accidental mistake. For example, the user could play an audio or a blinking LED message to a device that is not expecting to receive it. In simple security bootstrapping solutions that transfer a primary key to the device via the OOB channel, the device could misuse or leak the accidentally received primary key. EAP-NOOB is not vulnerable to such opportunistic attackers because the OOB message has no value to anyone who did not take part in the corresponding Initial Exchange.¶

One mechanism that can mitigate user mistakes is certification of peer devices. A certificate or an attestation token (e.g., [TLS-CWT] and [RATS-EAT]) can convey to the server authentic identifiers and attributes, such as model and serial number, of the peer device. Compared to a fully certificate-based authentication, however, EAP-NOOB can be used without trusted third parties and does not require the user to know any identifier of the peer device; physical access to the device is sufficient for bootstrapping with EAP-NOOB.¶

Similarly, the attacker can try to trick the user into delivering the OOB message to the wrong server so that the peer device becomes associated with the wrong server. If the EAP server is accessed through a web user interface, the attack is akin to phishing attacks where the user is tricked into accessing the wrong URL and wrong web page. OOB implementation with a dedicated app on a mobile device, which communicates with a server API at a preconfigured URL, can protect against such attacks.¶

After the device registration, an attacker could clone the device identity by copying the keys from the persistent EAP-NOOB association into another device. The attacker can be an outsider who gains access to the keys or the device owner who wants to have two devices matching the same registration. The cloning threats can be mitigated by creating the cryptographic keys and storing the persistent EAP-NOOB association on the peer device in a secure hardware component such as a trusted execution environment (TEE). Furthermore, remote attestation on the application level could provide assurance to the server that the device has not been cloned. Reconnect Exchange with a new cryptosuite (KeyingMode=3) will also disconnect all but the first clone that performs the update.¶

6.3. Trusted Path Issues and Misbinding Attacks

Another potential threat is spoofed user input or output on the peer device. When the user is delivering the OOB message to or from the correct peer device, a trusted path between the user and the peer device is needed. That is, the user must communicate directly with an authentic operating system and EAP-NOOB implementation in the peer device and not with a spoofed user interface. Otherwise, a registered device that is under the control of the attacker could emulate the behavior of an unregistered device. The secure path can be implemented, for example, by having the user press a reset button to return the device to the Unregistered (0) state and to invoke a trusted UI. The problem with such trusted paths is that they are not standardized across devices.¶

Another potential consequence of a spoofed UI is the misbinding attack where the user tries to register a correct but compromised device, which tricks the user into registering another (uncompromised) device instead. For example, the compromised device might have a malicious, full-screen app running, which presents to the user QR codes copied, in real time, from another device's screen. If the unwitting user scans the QR code and delivers the OOB message in it to the server, the wrong device may become registered in the server. Such misbinding vulnerabilities arise because the user does not have any secure way of verifying that the in-band cryptographic handshake and the out-of-band physical access are terminated at the same physical device. Sethi et al. [Sethi19] analyze the misbinding threat against device-pairing protocols and also EAP-NOOB. Essentially, all protocols where the authentication relies on the user's physical access to the device are vulnerable to misbinding, including EAP-NOOB.¶

A standardized trusted path for communicating directly with the trusted computing base in a physical device would mitigate the misbinding threat, but such paths rarely exist in practice. Careful asset tracking on the server side can also prevent most misbinding attacks if the peer device sends its identifiers or attributes in the PeerInfo field and the server compares them with the expected values. The wrong but uncompromised device's PeerInfo will not match the expected values. Device certification by the manufacturer can further strengthen the asset tracking.¶

6.4. Peer Identifiers and Attributes

The PeerId value in the protocol is a server-allocated identifier for its association with the peer and SHOULD NOT be shown to the user because its value is initially ephemeral. Since the PeerId is allocated by the server and the scope of the identifier is the single server, the so-called identifier squatting attacks, where a malicious peer could reserve another peer's identifier, are not possible in EAP-NOOB. The server SHOULD assign a random or pseudorandom PeerId to each new peer. It SHOULD NOT select the PeerId based on any peer characteristics that it may know, such as the peer's link-layer network address.¶

User reset or failure in the OOB Step can cause the peer to perform many Initial Exchanges with the server, which allocates many PeerId values and stores the ephemeral protocol state for them. The peer will typically only remember the latest ones. EAP-NOOB leaves it to the implementation to decide when to delete these ephemeral associations. There is no security reason to delete them early, and the server does not have any way to verify that the peers are actually the same one. Thus, it is safest to store the ephemeral states on the server for at least one day. If the OOB messages are sent only in the server-to-peer direction, the server SHOULD NOT delete the ephemeral state before all the related Noob values have expired.¶

After completion of EAP-NOOB, the server may store the PeerInfo data, and the user may use it to identify the peer and its attributes, such as the make and model or serial number. A compromised peer could lie in the PeerInfo that it sends to the server. If the server stores any information about the peer, it is important that this information is approved by the user during or after the OOB Step. Without verification by the user or authentication on the application level, the PeerInfo is not authenticated information and should not be relied on. One possible use for the PeerInfo field is EAP channel binding (see Section 6.7).¶

6.5. Downgrading Threats

The fingerprint Hoob protects all the information exchanged in the Initial Exchange, including the cryptosuite negotiation. The message authentication codes MACs and MACp also protect the same information. The message authentication codes MACs2 and MACp2 protect information exchanged during key renegotiation in the Reconnect Exchange. This prevents downgrading attacks to weaker cryptosuites, as long as the possible attacks take more time than the maximum time allowed for the EAP-NOOB completion. This is typically the case for recently discovered cryptanalytic attacks.¶

As an additional precaution, the EAP server and peer MUST check for downgrading attacks in the Reconnect Exchange as follows. As long as the server or peer saves any information about the other endpoint, it MUST also remember the previously negotiated cryptosuite and MUST NOT accept renegotiation of any cryptosuite that is known to be weaker than the previous one, such as a deprecated cryptosuite. Determining the relative strength of the cryptosuites is out of scope of this specification and may be managed by implementations or by local policies at the peer and server.¶

Integrity of the direction negotiation cannot be verified in the same way as the integrity of the cryptosuite negotiation. That is, if the OOB channel used in an application is critically insecure in one direction, an on-path attacker could modify the negotiation messages and thereby cause that direction to be used. Applications that support OOB messages in both directions SHOULD, therefore, ensure that the OOB channel has sufficiently strong security in both directions. While this is a theoretical vulnerability, it could arise in practice if EAP-NOOB is deployed in new applications. Currently, we expect most peer devices to support only one OOB direction; in which case, interfering with the direction negotiation can only prevent the completion of the protocol.¶

The long-term shared key material Kz in the persistent EAP-NOOB association is established with an ECDHE key exchange when the peer and server are first associated. It is a weaker secret than a manually configured random shared key because advances in cryptanalysis against the used ECDHE curve could eventually enable the attacker to recover Kz. EAP-NOOB protects against such attacks by allowing cryptosuite upgrades in the Reconnect Exchange and by updating the shared key material Kz whenever the cryptosuite is upgraded. We do not expect the cryptosuite upgrades to be frequent, but, if an upgrade becomes necessary, it can be done without manual reset and reassociation of the peer devices.¶

6.6. Protected Success and Failure Indications

Section 7.16 of [RFC3748] allows EAP methods to specify protected result indications because EAP-Success and EAP-Failure packets are neither acknowledged nor integrity protected. [RFC3748] notes that these indications may be explicit or implicit.¶

EAP-NOOB relies on implicit, protected success indicators in the Completion Exchange and Reconnect Exchange. Successful verification of MACs and MACs2 in the EAP-Request message from the server (message type 6 and message type 9, respectively) acts as an implicit, protected success indication to the peer. Similarly, successful verification of MACp and MACp2 in the EAP-Response message from the peer (message type 6 and message type 9, respectively) act as an implicit, protected success indication to the server.¶

EAP-NOOB failure messages are not protected. Protected failure result indications would not significantly improve availability since EAP-NOOB reacts to most malformed data by ending the current EAP conversation in EAP-Failure. However, since EAP-NOOB spans multiple conversations, failure in one conversation usually means no state change on the level of the EAP-NOOB state machine.¶

6.7. Channel Binding

EAP channel binding, defined in [RFC6677], means that the endpoints compare their perceptions of network properties, such as lower-layer identifiers, over the secure channel established by EAP authentication. Section 4.1 of [RFC6677] defines two approaches to channel binding. EAP-NOOB follows the first approach, in which the peer and server exchange plaintext information about the network over a channel that is integrity protected with keys derived during the EAP execution. More specifically, channel information is exchanged in the plaintext PeerInfo and ServerInfo objects and is later verified with message authentication codes (MACp, MACs, MACp2, and MACs2). This allows policy-based comparison with locally perceived network properties on either side, as well as logging for debugging purposes. The peer MAY include in PeerInfo any data items that it wants to bind to the EAP-NOOB association and to the exported keys. These can be properties of the authenticator or the access link, such as the SSID and BSSID of the wireless network (see Table 6). As noted in Section 4.3 of [RFC6677], the scope of the channel binding varies between deployments. For example, the server may have less link-layer information available from roaming networks than from a local enterprise network, and it may be unable to verify all the network properties received in PeerInfo. There are also privacy considerations related to exchanging the ServerInfo and PeerInfo while roaming (see Section 6.10).¶

Channel binding to secure channels, defined in [RFC5056], binds authentication at a higher protocol layer to a secure channel at a lower layer. Like most EAP methods, EAP-NOOB exports the session keys MSK and EMSK, and an outer tunnel or a higher-layer protocol can bind its authentication to these keys. Additionally, EAP-NOOB exports the key AMSK, which may be used to bind application-layer authentication to the secure channel created by EAP-NOOB and to the session keys MSK and EMSK.¶

6.8. Denial of Service

While denial-of-service (DoS) attacks by on-link attackers cannot be fully prevented, the design goal in EAP-NOOB is to void long-lasting failure caused by an attacker who is present only temporarily or intermittently. The main defense mechanism is the persistent EAP-NOOB association, which is never deleted automatically due to in-band messages or error indications. Thus, the endpoints can always use the persistent association for reconnecting after the DoS attacker leaves the network. In this sense, the persistent association serves the same function in EAP-NOOB as a permanent primary key or certificate in other authentication protocols. We discuss logical attacks against the updates of the persistent association in Section 6.9.¶

In addition to logical DoS attacks, it is necessary to consider resource exhaustion attacks against the EAP server. The number of persistent EAP-NOOB associations created in the server is limited by the need for a user to assist in delivering the OOB message. The users can be authenticated for the input or output of the OOB message at the EAP server, and any users who create excessive numbers of persistent associations can be held accountable and their associations can be deleted by the server administrator. What the attacker can do without user authentication is to perform the Initial Exchange repeatedly and create a large number of ephemeral associations (server in Waiting for OOB (1) state) without ever delivering the OOB message. In Section 6.4, it was suggested that the server should store the ephemeral states for at least a day. This may require off-loading the state storage from memory to disk during a DoS attack. However, if the server implementation is unable to keep up with a rate of Initial Exchanges performed by a DoS attacker and needs to drop some ephemeral states, no damage is caused to already-created persistent associations, and the honest users can resume registering new peers when the DoS attacker leaves the network.¶

There are some trade-offs in the protocol design between politely backing off and giving way to DoS attackers. An on-link DoS attacker could spoof the SleepTime value in the Initial Exchange or Waiting Exchange to cause denial of service against a specific peer device. There is an upper limit on the SleepTime (3600 seconds) to mitigate the spoofing threat. This means that, in the presence of an on-link DoS attacker who spoofs the SleepTime, it could take up to one hour after the delivery of the OOB message before the device performs the Completion Exchange and becomes functional. Similarly, the Unwanted peer error (error code 2001) could cause the peer to stop connecting to the network. If the peer device is able to alert the user about the error condition, it can safely stop connecting to the server and wait for the user to trigger a reconnection attempt, e.g., by resetting the device. As mentioned in Section 3.6.2, peer devices that are unable to alert the user should continue to retry the Initial Exchange infrequently to avoid a permanent DoS condition. We believe a maximum backoff time of 3600 seconds is reasonable for a new protocol because malfunctioning or misconfigured peer implementations are at least as great a concern as DoS attacks, and politely backing off within some reasonable limits will increase the acceptance of the protocol. The maximum backoff times could be updated to be shorter as the protocol implementations mature.¶

6.9. Recovery from Loss of Last Message

The EAP-NOOB Completion Exchange, as well as the Reconnect Exchange with cryptosuite update, results in a persistent state change that should take place either on both endpoints or on neither; otherwise, the result is a state mismatch that requires user action to resolve. The state mismatch can occur if the final EAP response of the exchanges is lost. In the Completion Exchange, the loss of the final response (Type=6) results in the peer moving to the Registered (4) state and creating a persistent EAP-NOOB association while the server stays in an ephemeral state (1 or 2). In the Reconnect Exchange, the loss of the final response (Type=9) results in the peer moving to the Registered (4) state and updating its persistent key material Kz while the server stays in the Reconnecting (3) state and keeps the old key material.¶

The state mismatch is an example of an unavoidable problem in distributed systems: it is theoretically impossible to guarantee synchronous state changes in endpoints that communicate asynchronously. The protocol will always have one critical message that may get lost, so that one side commits to the state change and the other side does not. In EAP, the critical message is the final response from the peer to the server. While the final response is normally followed by EAP-Success, [RFC3748], Section 4.2 states that the peer MAY assume that the EAP-Success was lost and the authentication was successful. Furthermore, EAP method implementations in the peer do not receive notification of the EAP-Success message from the parent EAP state machine [RFC4137]. For these reasons, EAP-NOOB on the peer side commits to a state change already when it sends the final response.¶

The best available solution to the loss of the critical message is to keep trying. EAP retransmission behavior defined in Section 4.3 of [RFC3748] suggests 3-5 retransmissions. In the absence of an attacker, this would be sufficient to reduce the probability of failure to an acceptable level. However, a determined attacker on the in-band channel can drop the final EAP-Response message and all subsequent retransmissions. In the Completion Exchange (KeyingMode=0) and Reconnect Exchange with cryptosuite upgrade (KeyingMode=3), this could result in a state mismatch and persistent denial of service until the user resets the peer state.¶

EAP-NOOB implements its own recovery mechanism that allows unlimited retries of the Reconnect Exchange. When the DoS attacker eventually stops dropping packets on the in-band channel, the protocol will recover. The logic for this recovery mechanism is specified in Section 3.4.2.¶

EAP-NOOB does not implement the same kind of retry mechanism in the Completion Exchange. The reason is that there is always a user involved in the initial association process, and the user can repeat the OOB Step to complete the association after the DoS attacker has left. On the other hand, Reconnect Exchange needs to work without user involvement.¶

6.10. Privacy Considerations

There are privacy considerations related to performing the Reconnect Exchange while roaming. The peer and server may send updated PeerInfo and ServerInfo fields in the Reconnect Exchange. This data is sent unencrypted between the peer and the EAP authenticator, such as a wireless access point. Thus, it can be observed by both outsiders and the access network. The PeerInfo field contains identifiers and other information about the peer device (see Table 6). While the information refers to the peer device and not directly to the user, it can leak information about the user to the access network and to outside observers. The ServerInfo, on the other hand, can leak information about the peer's affiliation with the home network. For this reason, the optional PeerInfo and ServerInfo in the Reconnect Exchange SHOULD be omitted unless some critical data has changed and it cannot be updated on the application layer.¶

Peer devices that randomize their Layer 2 address to prevent tracking can do this whenever the user resets the EAP-NOOB association. During the lifetime of the association, the PeerId is a unique identifier that can be used to track the peer in the access network. Later versions of this specification may consider updating the PeerId at each Reconnect Exchange. In that case, it is necessary to consider how the authenticator and access-network administrators can recognize and add misbehaving peer devices to a deny list, as well as how to avoid loss of synchronization between the server and the peer if messages are lost during the identifier update.¶

To enable stronger identity protection in later versions of EAP-NOOB, the optional server-assigned NAI (NewNAI) SHOULD have a constant username part. The RECOMMENDED username is "noob". The server MAY, however, send a different username in NewNAI to avoid username collisions within its realm or to conform to a local policy on usernames.¶

6.11. EAP Security Claims

EAP security claims are defined in Section 7.2.1 of [RFC3748]. The security claims for EAP-NOOB are listed in Table 13.¶