Assignment of new error codes MUST be done through IANA with "Specification Required" and "IESG Approval" as defined in [RFC5226].

4.3. Domain name reservation considerations

"eap-noob.net" should be registered as a special-use domain. The considerations required by [RFC6761] for registering this special use domain name are as follows:

• Users: Non-admin users are not expected to encounter this name or recognize it as special. AAA administrators may need to recognize the name.
• Application Software: Application software is not expected to recognize this domain name as special.
• Name Resolution APIs and Libraries: Name resolution APIs and libraries are not expected to recognize this domain name as special.
• Caching DNS Servers: Caching servers are not expected to recognize this domain name as special.
• Authoritative DNS Servers: Authoritative DNS servers MUST respond to queries for eap-noob.net with NXDOMAIN.
• DNS Server Operators: Except for the authoritative DNS server, there are no special requirements for the operators.
• DNS Registries/Registrars: There are no special requirements for DNS registrars.

5. Security considerations

EAP-NOOB is an authentication and key derivation protocol and, thus, security considerations can be found in most sections of this specification. In the following, we explain the protocol design and highlight some other special considerations.

5.1. Authentication principle

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 ECDH. The message authentication codes computed with the secret nonce Noob are alone sufficient for authenticating the key exchange. The OOB channel might, however, be vulnerable to eavesdropping of the OOB channel, which could lead to compromise of the secret nonce, which will then enable a man-in-the-middle attack on the in-band channel. This is why we include, as a second authentication feature, the integrity-protecting fingerprint Hoob in the OOB message. It is typically more difficult to spoof or alter messages on the human-assisted OOB channel, such as bar code, sound burst or user-transferred URL, than it is to spy on them.

The security provided by the cryptographic fingerprint is somewhat intricate to understand. The party that receives the OOB message uses Hoob to verify the integrity of the ECDH exchange. Thus, that party can detect man-in-the-middle attacks on the in-band channel. The other party, 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. Indeed, other device-pairing protocols have solved a similar situation by requiring the user to confirm to the OOB sender that the association was accepted by the OOB-receiver, e.g. by pressing an "accept" button on the sender. Since EAP-NOOB was designed to work strictly with one-directional OOB communication, it does not rely on such input 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 it from the OOB channel. If an attacker is able to eavesdrop the secret nonce and performs a man-in-the-middle attack on the in-band channel, the mismatching fingerprint will alert the OOB receiver, which will reject the OOB message. In this case, the association will appear to be complete only on the OOB sender side. The user in many applications will detect this apparently one-sided association because the peer device does not appear registered on the server or network.

The expected use cases for EAP-NOOB are ones where it replaces a user-entered access credentials. In wireless network access for IoT devices, the user-entered credential is often a passphrase, which is shared by all the network stations. Like any other EAP-based solution, EAP-NOOB establishes a different master secret for each peer device, which is obviously more resilient to device compromise than a common master secret. Additionally, it is possible to revoke the security association for an individual device on the server side.

Forward secrecy in EAP-NOOB is optional. The Reconnect Exchange in EAP-NOOB provides forward secrecy only if both the server and peer send their fresh ECDH keys. This allows both the server and the peer to limit the frequency of the costly computation that is required for forward secrecy. The server should make its decision primarily based on what it knows about the peer's computational capabilities.

5.2. Identifying and naming peer devices

EAP-NOOB relies on physical possession or identification of the peer device and secure communication between the user and the server. The main remaining threat against EAP-NOOB is that the attacker performs a man-in-the-middle attack on the in-band channel and, during the protocol execution, tricks the user to deliver the OOB message to or from the wrong peer. The server will now be associated with that wrong peer. Similarly, the attacker could try to trick the user to accessing the wrong server in the OOB Step. This reliance on user in identifying the correct parties is an inherent property of out-of-band authentication.

One mechanism that can be used to mitigate user mistakes is certification of trusted servers and peer devices. For example, if used together with EAP-NOOB, vendor certificates could prevent accidental association with a rogue peer device. Compared to a fully certificate-based authentication, EAP-NOOB does not depend on trusted third parties and does not require the user to know the identifier of the peer device; physical access is sufficient.

The user could also accidentally deliver the OOB message to more than one peer device. This could, for example, occur if the OOB message is a bar code and the peer is a camera: the user could by mistake show the bar code first to the wrong camera. Such accidents in EAP-NOOB will not enable the wrong camera to compute the master key or to opportunistically eavesdrop the communication. This is because the wrong peer device would need to have performed a man-in-the middle attack on the in-band channel before the accident. In comparison, simpler solutions where the master key is transferred to the device via the OOB channel would be vulnerable to opportunistic attacks if the user mistakenly delivers the master key to more than one device.

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 pseudo-random 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 and to allocate many PeerIds and to store the ephemeral protocol state for them. The peer will typically only remember the latest one. 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 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 properties, such as make and model or serial number. A compromised peer could lie about this information 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 rigorous user checking, the PeerInfo is not authenticated information and should not be relied on. Therefore, it is better to include only minimal information about the peer in PeerInfo and to ask the user to name the peer devices. In many applications, such as OOB authentication for ad-hoc wireless network access, it may be unnecessary to store any names for the peer device. Since the user delivering the OOB message will often communicate with the server over an authenticated channel, e.g. by logging into a secure web page, the user identity and user-given name can in those cases be reliably stored for the peer device. It is these user identities and user-given names that should be later used for access control and revocation.

Another reason to include only minimal information in the PeerInfo is potential privacy issues. The PeerInfo field is typically transmitted in plaintext between the peer and the authenticator. Although the PeerInfo sent by a new, unregistered device will not leak any information specifically about the user, it could reveal device identifiers and information about other device properties, which the user may want to avoid leaking at this point.

5.3. 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 downgrade 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 SHOULD check for downgrading attacks in the Reconnect Exchange. As long as the server or peer saves any information about the other party, it SHOULD also remember the previously negotiated cryptosuite and not accept renegotiation of any cryptosuite that is known to be weaker than the previous one (e.g. a deprecated cryptosuite or the same ECDH field with a shorter key).

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, a man-in-the-middle 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 unexpected applications. However, most devices acting as the peer are likely to support only one direction of exchange, 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 ECDH 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 ECDH curve could eventually enable the attacker to recover Kz. EAP-NOOB protect against such attacks by allowing cryptosuite upgrade in the Reconnect Exchange. We do not expect the upgrades to be frequent, but if one becomes necessary, the upgrade can be made without manual resetting and reassociation of the peer devices. During the algorithm upgrade, the shared key material Kz is also updated.

5.4. 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 7.

          
+--------+---------------------------+------------------------------+
| peer   | exchange chosen by        | next peer and                |
| states | server                    | server states                |
+========+===========================+==============================+
| server state: Unregistered (0)                                    |
+--------+---------------------------+------------------------------+
| 0..2   | Initial Exchange          | both 1 (0 on error)          |
| 3      | -                         | no change, notify user       |
+--------+---------------------------+------------------------------+
| server state: Waiting for OOB (1)                                 |
+--------+---------------------------+------------------------------+
| 0      | Initial Exchange          | both 1 (0 on error)          |
| 1      | Waiting Exchange          | both 1 (no change on error)  |
| 2      | Completion Exchange       | both 4 (no change on error)  |
| 3      | -                         | no change, notify user       |
+--------+---------------------------+------------------------------+
| server state: OOB Received (2)                                    |
+--------+---------------------------+------------------------------+
| 0      | Initial Exchange          | both 1 (0 on error)          |
| 1      | Completion Exchange       | both 4 (no change on error)  |
| 2      | Completion Exchange       | both 4 (no change on error)  |
| 3      | -                         | no change, notify user       |
+--------+---------------------------+------------------------------+
| server state: Reconnecting (3) or Registered (4)                  |
+--------+---------------------------+------------------------------+
| 0..2   | -                         | no change, notify user       |
| 3      | Reconnect Exchange        | both 4 (3 on error)          |
+--------+---------------------------+------------------------------+
        
          

          
+--------+---------------------------+------------------------------+
| server/| possible local events     | next state                   |
| peer   | on server and peer        |                              |
| state  |                           |                              |
+========+===========================+==============================+
| 1      | OOB Output*               | 1                            |
| 1      | OOB Input*                | 2 (1 on error)               |
| 0..2   | Timeout/network failure   | 0                            |
| 3..4   | Timeout/network failure   | 3                            |
| 3..4   | Rekeying request          | 3                            |
| 0..4   | User resets peer state    | 0                            |
| 0..4   | Association state recovery| 3                            |
+--------+---------------------------+------------------------------+