This section defines the EAP-NOOB method. The protocol is a generalized version of the original idea presented by [
Sethi14].
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.
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.
All EAP-NOOB exchanges start with common handshake messages. The handshake begins with the identity request and response that are common to all EAP methods. Their purpose is to enable the AAA architecture to route the EAP conversation to the EAP server and to enable the EAP server to select the EAP method. The handshake then continues with one EAP-NOOB request-response pair in which the server discovers the peer identifier used in EAP-NOOB and the peer state.
In more detail, each EAP-NOOB exchange begins with the authenticator sending an EAP-Request/Identity packet to the peer. From this point on, the EAP conversation occurs between the server and the peer, and the authenticator acts as a pass-through device. The peer responds to the authenticator with an EAP-Response/Identity packet, which contains the Network Access Identifier (NAI). The authenticator, acting as a pass-through device, forwards this response and the following EAP conversation between the peer and the AAA architecture. The AAA architecture routes the conversation to a specific AAA server (called "EAP server" or simply "server" in this specification) based on the realm part of the NAI. The server selects the EAP-NOOB method based on the user part of the NAI, as defined in
Section 3.3.1.
After receiving the EAP-Response/Identity message, the server sends the first EAP-NOOB request (Type=1) to the peer, which responds with the peer identifier (PeerId) and state (PeerState) in the range 0..3. However, the peer
SHOULD omit the PeerId from the response (Type=1) when PeerState=0. The server then chooses the EAP-NOOB exchange, i.e., the ensuing message sequence, as explained below. The peer recognizes the exchange based on the message type field (Type) of the next EAP-NOOB request received from the server.
The server
MUST determine the exchange type based on the combination of the peer and server states as follows (also summarized in
Table 14). If either the peer or server is in the Unregistered (0) state and the other is in one of the ephemeral states (0..2), the server chooses the Initial Exchange. If either the peer or server is in the OOB Received (2) state and the other is either in the Waiting for OOB (1) or OOB Received (2) state, the OOB Step has taken place and the server chooses the Completion Exchange. If both the server and peer are in the Waiting for OOB (1) state, the server chooses the Waiting Exchange. If the peer is in the Reconnecting (3) state and the server is in the Registered (4) or Reconnecting (3) state, the server chooses the Reconnect Exchange. All other state combinations are error situations where user action is required, and the server
SHOULD indicate such errors to the peer with the error code 2002 (see
Section 3.6.3). Note also that the peer
MUST NOT initiate EAP-NOOB when the peer is in the Registered (4) state.
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... |
The Initial Exchange comprises the common handshake and two further EAP-NOOB request-response pairs: one for version, cryptosuite, and parameter negotiation and the other for the ECDHE key exchange. The first EAP-NOOB request (Type=2) from the server contains a newly allocated PeerId for the peer and an optional NewNAI for assigning a new NAI to the peer. The server allocates a new PeerId in the Initial Exchange regardless of any old PeerId received in the previous response (Type=1). The server also sends in the request a list of the protocol versions (Vers) and cryptosuites (Cryptosuites) it supports, an indicator of the OOB channel directions it supports (Dirs), and a ServerInfo object. The peer chooses one of the versions and cryptosuites. The peer sends a response (Type=2) with the selected protocol version (Verp), the received PeerId, the selected cryptosuite (Cryptosuitep), an indicator of the OOB channel direction(s) selected by the peer (Dirp), and a PeerInfo object. In the second EAP-NOOB request and response (Type=3), the server and peer exchange the public components of their ECDHE keys and nonces (PKs, Ns, PKp, and Np). The ECDHE keys
MUST be based on the negotiated cryptosuite, i.e., Cryptosuitep. The Initial Exchange always ends with EAP-Failure from the server because the authentication cannot yet be completed.
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 -------------------------|
| |
At the conclusion of the Initial Exchange, both the server and the peer move to the Waiting for OOB (1) state.
The OOB Step, labeled as OOB Output and OOB Input in
Figure 1, takes place after the Initial Exchange. Depending on the negotiated OOB channel direction, the peer or the server outputs the OOB message as shown in Figures [
4] or [
5], respectively. The data fields are the PeerId, the secret nonce Noob, and the cryptographic fingerprint Hoob. The contents of the data fields are defined in
Section 3.3.2. The OOB message is delivered to the other endpoint via a user-assisted OOB channel.
For brevity, we will use the terms OOB sender and OOB receiver in addition to the already familiar EAP server and EAP peer. If the OOB message is sent in the server-to-peer direction, the OOB sender is the server and the OOB receiver is the peer. On the other hand, if the OOB message is sent in the peer-to-server direction, the OOB sender is the peer and the OOB receiver is the server.
EAP Peer EAP Server
| |
|=================OOB=============================>|
| (PeerId,Noob,Hoob) |
| |
EAP Peer EAP Server
| |
|<================OOB==============================|
| (PeerId,Noob,Hoob) |
| |
The OOB receiver
MUST compare the received value of the fingerprint Hoob (see
Section 3.3.2) with a value that it computed locally for the PeerID received. This integrity check ensures that the endpoints agree on contents of the Initial Exchange. If the values are equal, the receiver moves to the OOB Received (2) state. Otherwise, the receiver
MUST reject the OOB message. For usability reasons, the OOB receiver
SHOULD indicate the acceptance or rejection of the OOB message to the user. The receiver
SHOULD reject invalid OOB messages without changing its state in the association state machine until an application-specific number of invalid messages (OobRetries) has been reached; after which, the receiver
SHOULD consider it an error and go back to the Unregistered (0) state.
The server or peer
MAY send multiple OOB messages with different Noob values while in the Waiting for OOB (1) state. The OOB sender
SHOULD remember the Noob values until they expire and accept any one of them in the following Completion Exchange. The Noob values sent by the server expire after an application-dependent timeout (NoobTimeout), and the server
MUST NOT accept Noob values older than that in the Completion Exchange. The
RECOMMENDED value for NoobTimeout is 3600 seconds if there are no application-specific reasons for making it shorter or longer. The Noob values sent by the peer expire, as defined in
Section 3.2.5.
The OOB receiver does not accept further OOB messages after it has accepted one and moved to the OOB Received (2) state. However, the receiver
MAY buffer redundant OOB messages in case an OOB message expiry or similar error detected in the Completion Exchange causes it to return to the Waiting for OOB (1) state. It is
RECOMMENDED that the OOB receiver notifies the user about redundant OOB messages, but it
MAY instead discard them silently.
The sender will typically generate a new Noob, and therefore a new OOB message, at constant time intervals (NoobInterval). The
RECOMMENDED interval is
NoobInterval = NoobTimeout / 2
in which case, the receiver of the OOB will at any given time accept either of the two latest Noob values. However, the timing of the Noob generation may also be based on user interaction or on implementation considerations.
Even though not recommended (see
Section 3.3), this specification allows both directions to be negotiated (Dirp=3) for the OOB channel. In that case, both sides
SHOULD output the OOB message, and it is up to the user to deliver at least one of them.
The details of the OOB channel implementation including the message encoding are defined by the application.
Appendix D gives an example of how the OOB message can be encoded as a URL that may be embedded in a dynamic QR code or NFC (Near Field Communication) tag.
After the Initial Exchange, if the OOB channel directions selected by the peer include the peer-to-server direction, the peer
SHOULD initiate the EAP-NOOB method again after an applications-specific waiting time in order to probe for completion of the OOB Step. If the OOB channel directions selected by the peer include the server-to-peer direction and the peer receives the OOB message, it
SHOULD initiate the EAP-NOOB method immediately. Depending on the combination of the peer and server states, the server continues with the Completion Exchange or Waiting Exchange (see
Section 3.2.1 on how the server makes this decision).
The Completion Exchange comprises the common handshake and one or two further EAP-NOOB request-response pairs. If the peer is in the Waiting for OOB (1) state, the OOB message has been sent in the peer-to-server direction. In that case, only one request-response pair (Type=6) takes place. In the request, the server sends the NoobId value (see
Section 3.3.2), which the peer uses to identify the exact OOB message received by the server. On the other hand, if the peer is in the OOB Received (2) state, the direction of the OOB message is from server to peer. In this case, two request-response pairs (Type=5 and Type=6) are needed. The purpose of the first request-response pair (Type=5) is that it enables the server to discover NoobId, which identifies the exact OOB message received by the peer. The server returns the same NoobId to the peer in the latter request.
In the last request-response pair (Type=6) of the Completion Exchange, the server and peer exchange message authentication codes. Both sides
MUST compute the keys Kms and Kmp, as defined in
Section 3.5, and the message authentication codes MACs and MACp, as defined in
Section 3.3.2. Both sides
MUST compare the received message authentication code with a locally computed value. If the peer finds that it has received the correct value of MACs and the server finds that it has received the correct value of MACp, the Completion Exchange ends in EAP-Success. Otherwise, the endpoint where the comparison fails indicates this with an error message (error code 4001, see
Section 3.6.5), and the Completion Exchange ends in EAP-Failure.
After the successful Completion Exchange, both the server and the peer move to the Registered (4) state. They also derive the output keying material and store the persistent EAP-NOOB association state, as defined in Sections [
3.4] and [
3.5].
It is possible that the OOB message expires before it is received. In that case, the sender of the OOB message no longer recognizes the NoobId that it receives in the Completion Exchange. Another reason why the OOB sender might not recognize the NoobId is if the received OOB message was spoofed and contained an attacker-generated Noob value. The recipient of an unrecognized NoobId indicates this with an error message (error code 2003, see
Section 3.6.1), and the Completion Exchange ends in EAP-Failure. The recipient of the error message 2003 moves back to the Waiting for OOB (1) state. This state transition is called OOB Reject in
Figure 1 (even though it really is a specific type of failed Completion Exchange). On the other hand, the sender of the error message stays in its previous state.
Although it is not expected to occur in practice, poor user interface design could lead to two OOB messages delivered simultaneously, one from the peer to the server and the other from the server to the peer. The server detects this event in the beginning of the Completion Exchange by observing that both the server and peer are in the OOB Received (2) state. In that case, as a tiebreaker, the server
MUST behave as if only the server-to-peer message had been delivered.
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 -------------------------|
| |
As explained in
Section 3.2.4, the peer
SHOULD probe the server for completion of the OOB Step. When the combination of the peer and server states indicates that the OOB message has not yet been delivered, the server chooses the Waiting Exchange (see
Section 3.2.1 on how the server makes this decision). The Waiting Exchange comprises the common handshake and one further request-response pair, and it always ends in EAP-Failure.
In order to limit the rate at which peers probe the server, the server
MAY send to the peer either in the Initial Exchange or in the Waiting Exchange a minimum time to wait before probing the server again. A peer that has not received an OOB message
SHOULD wait at least the server-specified minimum waiting time in seconds (SleepTime) before initiating EAP again with the same server. The peer uses the latest SleepTime value that it has received in or after the Initial Exchange. If the server has not sent any SleepTime value, the peer
MUST wait for an application-specified minimum time (SleepTimeDefault).
After the Waiting Exchange, the peer
MUST discard (from its local ephemeral storage) Noob values that it has sent to the server in OOB messages that are older than the application-defined timeout NoobTimeout (see
Section 3.2.3). The peer
SHOULD discard such expired Noob values even if the probing failed because of, e.g., failure to connect to the EAP server or an incorrect message authentication code. The timeout of peer-generated Noob values is defined like this in order to allow the peer to probe the server once after it has waited for the server-specified SleepTime.
If the server and peer have negotiated to use only the server-to-peer direction for the OOB channel (Dirp=2), the peer
SHOULD nevertheless probe the server. The purpose of this is to keep the server informed about the peers that are still waiting for OOB messages. The server
MAY set SleepTime to a high number (e.g., 3600) to prevent the peer from probing the server frequently.
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 -------------------------|
| |
This section defines the various identifiers and data fields used in the EAP-NOOB method.
The server allocates a new peer identifier (PeerId) for the peer in the Initial Exchange. The peer identifier
MUST follow the syntax of the utf8-username specified in [
RFC 7542]. The server
MUST generate the identifiers in such a way that they do not repeat and cannot be guessed by the peer or third parties before the server sends them to the peer in the Initial Exchange. One way to generate the identifiers is to choose a random 16-byte identifier and to base64url encode it without padding [
RFC 4648] into a 22-character ASCII string. Another way to generate the identifiers is to choose a random 22-character alphanumeric ASCII string. It is
RECOMMENDED to not use identifiers longer than this because they result in longer OOB messages.
The peer uses the allocated PeerId to identify itself to the server in the subsequent exchanges. The peer
MUST copy the PeerId byte by byte from the message where it was allocated, and the server
MUST perform a byte-by-byte comparison between the received and the previously allocated PeerID. The peer sets the PeerId value in response type 1 as follows. As stated in
Section 3.2.1, when the peer is in the Unregistered (0) state, it
SHOULD omit the PeerId from response type 1. When the peer is in one of the states 1..2, it
MUST use the PeerId that the server assigned to it in the latest Initial Exchange. When the peer is in one of the persistent states 3..4, it
MUST use the PeerId from its persistent EAP-NOOB association. (The PeerId is written to the association when the peer moves to the Registered (4) state after a Completion Exchange.)
The default NAI for the peer is "noob@eap-noob.arpa". The peer implementation
MAY allow the user or application to configure a different NAI, which overrides the default NAI. Furthermore, the server
MAY assign a new NAI to the peer in the Initial Exchange or Reconnect Exchange in the NewNAI field of request types 2 and 7 to override any previous NAI value. When the peer is in the Unregistered (0) state, or when the peer is in one of the states 1..2 and the server did not send a NewNAI in the latest Initial Exchange, the peer
MUST use the configured NAI or, if it does not exist, the default NAI. When the peer is in one of the states 1..2 and the server sent a NewNAI in the latest Initial Exchange, the peer
MUST use this server-assigned NAI. When the peer moves to the Registered (4) state after the Completion Exchange, it writes to the persistent EAP-NOOB association the same NAI value that it used in the Completion Exchange. When the peer is in the Reconnecting (3) or Registered (4) state, it
MUST use the NAI from its persistent EAP-NOOB association. When the server sends NewNAI in the Reconnect Exchange, the peer writes its value to the persistent EAP-NOOB association when it moves from the Reconnecting (3) state to the Registered (4) state. All the NAI values
MUST follow the syntax specified in [
RFC 7542].
The purpose of the server-assigned NAI is to enable more flexible routing of the EAP sessions over the AAA infrastructure, including roaming scenarios (see
Appendix C). Moreover, some authenticators or AAA servers use the realm part of the assigned NAI to determine peer-specific connection parameters, such as isolating the peer to a specific VLAN. On the other hand, the user- or application-configured NAI enables registration of new devices while roaming. It also enables manufacturers to set up their own AAA servers for bootstrapping of new peer devices.
The peer's PeerId and server-assigned NAI are ephemeral until a successful Completion Exchange takes place. Thereafter, the values become parts of the persistent EAP-NOOB association until the user resets the peer and server or until a new NAI is assigned in the Reconnect Exchange.
Table 1 defines the data fields in the protocol messages. The in-band messages are formatted as JSON objects [
RFC 8259] in UTF-8 encoding. The JSON member names are in the left-hand column of the table.
Data Field |
Description |
Vers, Verp |
EAP-NOOB protocol versions supported by the EAP server and the protocol version chosen by the peer. Vers is a JSON array of unsigned integers, and Verp is an unsigned integer. Example values are "[1]" and "1", respectively.
|
PeerId |
Peer identifier, as defined in Section 3.3.1. |
NAI, NewNAI |
Peer NAI and server-assigned new peer NAI, as defined in Section 3.3.1.
|
Type |
EAP-NOOB message type. The type is an integer in the range 0..9. EAP-NOOB requests and the corresponding responses share the same type value.
|
PeerState |
Peer state is an integer in the range 0..4 (see Figure 1). However, only values 0..3 are ever sent in the protocol messages.
|
PKs, PKp |
The public components of the ECDHE keys of the server and peer. PKs and PKp are sent in the JSON Web Key (JWK) format [RFC 7517]. The detailed format of the JWK object is defined by the cryptosuite.
|
Cryptosuites, Cryptosuitep |
The identifiers of cryptosuites supported by the server and of the cryptosuite selected by the peer. The server-supported cryptosuites in Cryptosuites are formatted as a JSON array of the identifier integers. The server MUST send a nonempty array with no repeating elements, ordered by decreasing priority. The peer MUST respond with exactly one suite in the Cryptosuitep value, formatted as an identifier integer. Mandatory-to-implement cryptosuites and the registration procedure for new cryptosuites are specified in Section 5.1. Example values are "[1]" and "1", respectively.
|
Dirs, Dirp |
An integer indicating the OOB channel directions supported by the server and the directions selected by the peer. The possible values are 1=peer-to-server, 2=server-to-peer, and 3=both directions.
|
Dir |
The actual direction of the OOB message (1=peer-to-server, 2=server-to-peer). This value is not sent over any communication channel, but it is included in the computation of the cryptographic fingerprint Hoob.
|
Ns, Np |
32-byte nonces for the Initial Exchange. |
ServerInfo |
This field contains information about the server to be passed from the EAP method to the application layer in the peer. The information is specific to the application or to the OOB channel, and it is encoded as a JSON object of at most 500 bytes. It could include, for example, the access-network name and server name, a Uniform Resource Locator (URL) [RFC 3986], or some other information that helps the user deliver the OOB message to the server through the out-of-band channel.
|
PeerInfo |
This field contains information about the peer to be passed from the EAP method to the application layer in the server. The information is specific to the application or to the OOB channel, and it is encoded as a JSON object of at most 500 bytes. It could include, for example, the peer brand, model, and serial number, which help the user distinguish between devices and deliver the OOB message to the correct peer through the out-of-band channel.
|
SleepTime |
The number of seconds for which the peer MUST NOT start a new execution of the EAP-NOOB method with the authenticator, unless the peer receives the OOB message or the sending is triggered by an application-specific user action. The server can use this field to limit the rate at which peers probe it. SleepTime is an unsigned integer in the range 0..3600.
|
Noob |
16-byte secret nonce sent through the OOB channel and used for the session key derivation. The endpoint that received the OOB message uses this secret in the Completion Exchange to authenticate the exchanged key to the endpoint that sent the OOB message.
|
Hoob |
16-byte cryptographic fingerprint (i.e., hash value) computed from all the parameters exchanged in the Initial Exchange and in the OOB message. Receiving this fingerprint over the OOB channel guarantees the integrity of the key exchange and parameter negotiation. Hence, it authenticates the exchanged key to the endpoint that receives the OOB message.
|
NoobId |
16-byte identifier for the OOB message, computed with a one-way function from the nonce Noob in the message.
|
MACs, MACp |
Message authentication codes (HMAC) for mutual authentication, key confirmation, and integrity check on the exchanged information. The input to the HMAC is defined below, and the key for the HMAC is defined in Section 3.5.
|
Ns2, Np2 |
32-byte nonces for the Reconnect Exchange. |
KeyingMode |
Integer indicating the key derivation method. 0 in the Completion Exchange, and 1..3 in the Reconnect Exchange.
|
PKs2, PKp2 |
The public components of the ECDHE keys of the server and peer for the Reconnect Exchange. PKp2 and PKs2 are sent in the JSON Web Key (JWK) format [RFC 7517]. The detailed format of the JWK object is defined by the cryptosuite.
|
MACs2, MACp2 |
Message authentication codes (HMAC) for mutual authentication, key confirmation, and integrity check on the Reconnect Exchange. The input to the HMAC is defined below, and the key for the HMAC is defined in Section 3.5.
|
ErrorCode |
Integer indicating an error condition. Defined in Section 5.3. |
ErrorInfo |
Textual error message for logging and debugging purposes. A UTF-8 string of at most 500 bytes.
|
Table 1: Message Data Fields
It is
RECOMMENDED for servers to support both OOB channel directions (Dirs=3) unless the type of the OOB channel limits them to one direction (Dirs=1 or Dirs=2). On the other hand, it is
RECOMMENDED that the peer selects only one direction (Dirp=1 or Dirp=2) even when both directions (Dirp=3) would be technically possible. The reason is that, if value 3 is negotiated, the user may be presented with two OOB messages, one for each direction, even though only one of them needs to be delivered. This can be confusing to the user. Nevertheless, the EAP-NOOB protocol is designed to also cope with the value 3; in which case, it uses the first delivered OOB message. In the unlikely case of simultaneously delivered OOB messages, the protocol prioritizes the server-to-peer direction.
The nonces in the in-band messages (Ns, Np, Ns2, Np2) are 32-byte fresh random byte strings, and the secret nonce Noob is a 16-byte fresh random byte string. All the nonces are generated by the endpoint that sends the message.
The fingerprint Hoob and the identifier NoobId are computed with the cryptographic hash function H, which is specified in the negotiated cryptosuite and truncated to the 16 leftmost bytes of the output. The message authentication codes (MACs, MACp, MACs2, MACp2) are computed with the function HMAC, which is the hashed message authentication code [
RFC 2104] based on the cryptographic hash function H and truncated to the 32 leftmost bytes of the output.
The inputs to the hash function for computing the fingerprint Hoob and to the HMAC for computing MACs, MACp, MACs2, and MACp2 are JSON arrays containing a fixed number (17) of elements. The array elements
MUST be copied to the array verbatim from the sent and received in-band messages. When the element is a JSON object, its members
MUST NOT be reordered or reencoded. White space
MUST NOT be added anywhere in the JSON structure. Implementers should check that their JSON library copies the elements as UTF-8 strings, does not modify them in any way, and does not add white space to the HMAC input.
The inputs for computing the fingerprint and message authentication codes are the following:
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,"")
The inputs denoted with "" above are not present, and the values in brackets [] are optional. Both kinds of missing input values are represented by empty strings "" in the HMAC input (JSON array). The NAI included in the inputs is the NAI value that will be in the persistent EAP-NOOB association if the Completion Exchange or Reconnect Exchange succeeds. In the Completion Exchange, the NAI is the NewNAI value assigned by the server in the preceding Initial Exchange or, if no NewNAI was sent, the NAI used by the client in the Initial Exchange. In the Reconnect Exchange, the NAI is the NewNAI value assigned by the server in the same Reconnect Exchange or, if no NewNAI was sent, the unchanged NAI from the persistent EAP-NOOB association. Each of the values in brackets for the computation of Macs2 and Macp2
MUST be included if it was sent or received in the same Reconnect Exchange; otherwise, the value is replaced by an empty string "".
The parameter Dir indicates the direction in which the OOB message containing the Noob value is being sent (1=peer-to-server, 2=server-to-peer). This field is included in the Hoob input to prevent the user from accidentally delivering the OOB message back to its originator in the rare cases where both OOB directions have been negotiated. The keys (Kms, Kmp, Kms2, and Kmp2) for the HMACs are defined in
Section 3.5.
The nonces (Ns, Np, Ns2, Np2, and Noob) and the hash value (NoobId)
MUST be base64url encoded [
RFC 4648] when they are used as input to the cryptographic functions H or HMAC. These values and the message authentication codes (MACs, MACp, MACs2, and MACp2)
MUST also be base64url encoded when they are sent as JSON strings in the in-band messages. The values Noob and Hoob in the OOB channel
MAY be base64url encoded if that is appropriate for the application and the OOB channel. All base64url encoding is done without padding. The base64url-encoded values will naturally consume more space than the number of bytes specified above (e.g., a 22-character string for a 16-byte nonce and a 43-character string for a 32-byte nonce or message authentication code). In the key derivation in
Section 3.5, on the other hand, the unencoded nonces (raw bytes) are used as input to the key derivation function.
The ServerInfo and PeerInfo are JSON objects with UTF-8 encoding. The length of either encoded object as a byte array
MUST NOT exceed 500 bytes. The format and semantics of these objects
MUST be defined by the application that uses the EAP-NOOB method.
EAP-NOOB implements fast reconnect (
RFC 3748,
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.
To enable rekeying, the EAP server and peer store the session state in persistent memory after a successful Completion Exchange. This state data, called "persistent EAP-NOOB association",
MUST include at least the data fields shown in
Table 2. They are used for identifying and authenticating the peer in the Reconnect Exchange. When a persistent EAP-NOOB association exists, the EAP server and peer are in the Registered (4) state or Reconnecting (3) state, as shown in
Figure 1.
Data Field |
Value |
Type |
PeerId |
Peer identifier allocated by server |
UTF-8 string (typically 22 ASCII characters) |
Verp |
Negotiated protocol version |
integer |
Cryptosuitep |
Negotiated cryptosuite |
integer |
CryptosuitepPrev (at peer only) |
Previous cryptosuite |
integer |
NAI |
NAI assigned by the server or configured by the user or the default NAI "noob@eap-noob.arpa"
|
UTF-8 string |
Kz |
Persistent key material |
32 bytes |
KzPrev (at peer only) |
Previous Kz value |
32 bytes |
Table 2: Persistent EAP-NOOB Association
The server chooses the Reconnect Exchange when both the peer and the server are in a persistent state and fast reconnection is needed (see
Section 3.2.1 for details).
The Reconnect Exchange comprises the common handshake and three further EAP-NOOB request-response pairs: one for cryptosuite and parameter negotiation, another for the nonce and ECDHE key exchange, and the last one for exchanging message authentication codes. In the first request and response (Type=7), the server and peer negotiate a protocol version and cryptosuite in the same way as in the Initial Exchange. The server
SHOULD NOT offer and the peer
MUST NOT accept protocol versions or cryptosuites that it knows to be weaker than the one currently in the Cryptosuitep field of the persistent EAP-NOOB association. The server
SHOULD NOT needlessly change the cryptosuites it offers to the same peer because peer devices may have limited ability to update their persistent storage. However, if the peer has different values in the Cryptosuitep and CryptosuitepPrev fields, it
SHOULD also accept offers that are not weaker than CryptosuitepPrev. Note that Cryptosuitep and CryptosuitePrev from the persistent EAP-NOOB association are only used to support the negotiation as described above; all actual cryptographic operations use the newly negotiated cryptosuite. The request and response (Type=7)
MAY additionally contain PeerInfo and ServerInfo objects.
The server then determines the KeyingMode (defined in
Section 3.5) based on changes in the negotiated cryptosuite and whether it desires to achieve forward secrecy or not. The server
SHOULD only select KeyingMode 3 when the negotiated cryptosuite differs from the Cryptosuitep in the server's persistent EAP-NOOB association, although it is technically possible to select this value without changing the cryptosuite. In the second request and response (Type=8), the server informs the peer about the KeyingMode and the server and peer exchange nonces (Ns2, Np2). When KeyingMode is 2 or 3 (rekeying with ECDHE), they also exchange public components of ECDHE keys (PKs2, PKp2). The server ECDHE key
MUST be fresh, i.e., not previously used with the same peer, and the peer ECDHE key
SHOULD be fresh, i.e., not previously used.
In the third and final request and response (Type=9), the server and peer exchange message authentication codes. Both sides
MUST compute the keys Kms2 and Kmp2, as defined in
Section 3.5, and the message authentication codes MACs2 and MACp2, as defined in
Section 3.3.2. Both sides
MUST compare the received message authentication code with a locally computed value.
The rules by which the peer compares the received MACs2 are nontrivial because, in addition to authenticating the current exchange, MACs2 may confirm the success or failure of a recent cryptosuite upgrade. The peer processes the final request (Type=9) as follows:
-
The peer first compares the received MACs2 value with one it computed using the Kz stored in the persistent EAP-NOOB association. If the received and computed values match, the peer deletes any data stored in the CryptosuitepPrev and KzPrev fields of the persistent EAP-NOOB association. It does this because the received MACs2 confirms that the peer and server share the same Cryptosuitep and Kz, and any previous values must no longer be accepted.
-
On the other hand, if the peer finds that the received MACs2 value does not match the one it computed locally with Kz, the peer checks whether the KzPrev field in the persistent EAP-NOOB association stores a key. If it does, the peer repeats the key derivation (Section 3.5) and local MACs2 computation (Section 3.3.2) using KzPrev in place of Kz. If this second computed MACs2 matches the received value, the match indicates synchronization failure caused by the loss of the last response (Type=9) in a previously attempted cryptosuite upgrade. In this case, the peer rolls back that upgrade by overwriting Cryptosuitep with CryptosuitepPrev and Kz with KzPrev in the persistent EAP-NOOB association. It also clears the CryptosuitepPrev and KzPrev fields.
-
If the received MACs2 matched one of the locally computed values, the peer proceeds to send the final response (Type=9). The peer also moves to the Registered (4) state. When KeyingMode is 1 or 2, the peer stops here. When KeyingMode is 3, the peer also updates the persistent EAP-NOOB association with the negotiated Cryptosuitep and the newly derived Kz value. To prepare for possible synchronization failure caused by the loss of the final response (Type=9) during cryptosuite upgrade, the peer copies the old Cryptosuitep and Kz values in the persistent EAP-NOOB association to the CryptosuitepPrev and KzPrev fields.
-
Finally, if the peer finds that the received MACs2 does not match either of the two values that it computed locally (or one value if no KzPrev was stored), the peer sends an error message (error code 4001, see Section 3.6.5), which causes the Reconnect Exchange to end in EAP-Failure.
The server rules for processing the final message are simpler than the peer rules because the server does not store previous keys and it never rolls back a cryptosuite upgrade. Upon receiving the final response (Type=9), the server compares the received value of MACp2 with one it computes locally. If the values match, the Reconnect Exchange ends in EAP-Success. When KeyingMode is 3, the server also updates Cryptosuitep and Kz in the persistent EAP-NOOB association. On the other hand, if the server finds that the values do not match, it sends an error message (error code 4001), and the Reconnect Exchange ends in EAP-Failure.
The endpoints
MAY send updated NewNAI, ServerInfo, and PeerInfo objects in the Reconnect Exchange. When there is no update to the values, they
SHOULD omit this information from the messages. If the NewNAI was sent, each side updates NAI in the persistent EAP-NOOB association when moving to the Registered (4) state.
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 -------------------------|
| |
As shown in the association state machine in
Figure 1, the only specified way for the association to return from the Registered (4) state to the Unregistered (0) state is through user-initiated reset. After the reset, a new OOB message will be needed to establish a new association between the EAP server and peer. Typical situations in which the user reset is required are when the other side has accidentally lost the persistent EAP-NOOB association data or when the peer device is decommissioned.
The server could detect that the peer is in the Registered or Reconnecting state, but the server itself is in one of the ephemeral states 0..2 (including situations where the server does not recognize the PeerId). In this case, effort should be made to recover the persistent server state, for example, from a backup storage -- especially if many peer devices are similarly affected. If that is not possible, the EAP server
SHOULD log the error or notify an administrator. The only way to continue from such a situation is by having the user reset the peer device.
On the other hand, if the peer is in any of the ephemeral states 0..2, including the Unregistered state, the server will treat the peer as a new peer device and allocate a new PeerId to it. The PeerInfo can be used by the user as a clue to which physical device has lost its state. However, there is no secure way of matching the "new" peer with the old PeerId without repeating the OOB Step. This situation will be resolved when the user performs the OOB Step and thus identifies the physical peer device. The server user interface
MAY support situations where the "new" peer is actually a previously registered peer that has been reset by a user or otherwise lost its persistent data. In those cases, the user could choose to merge the new peer identity with the old one in the server. The alternative is to treat the device just like a new peer.
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.
KeyingMode |
Description |
0 |
Completion Exchange (always with ECDHE) |
1 |
Reconnect Exchange, rekeying without ECDHE |
2 |
Reconnect Exchange, rekeying with ECHDE, no change in cryptosuite
|
3 |
Reconnect Exchange, rekeying with ECDHE, new cryptosuite negotiated
|
Table 3: Keying Modes
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.
KeyingMode |
KDF input field |
Value |
Length (bytes) |
0 Completion |
Z |
ECDHE shared secret from PKs and PKp |
variable |
AlgorithmId |
"EAP-NOOB" |
8 |
PartyUInfo |
Np |
32 |
PartyVInfo |
Ns |
32 |
SuppPubInfo |
(not allowed) |
|
SuppPrivInfo |
Noob |
16 |
1 Reconnect, rekeying without ECDHE |
Z |
Kz |
32 |
AlgorithmId |
"EAP-NOOB" |
8 |
PartyUInfo |
Np2 |
32 |
PartyVInfo |
Ns2 |
32 |
SuppPubInfo |
(not allowed) |
|
SuppPrivInfo |
(null) |
0 |
2 or 3 Reconnect, rekeying, with ECDHE, same or new cryptosuite |
Z |
ECDHE shared secret from PKs2 and PKp2 |
variable |
AlgorithmId |
"EAP-NOOB" |
8 |
PartyUInfo |
Np2 |
32 |
PartyVInfo |
Ns2 |
32 |
SuppPubInfo |
(not allowed) |
|
SuppPrivInfo |
Kz |
32 |
Table 4: Key Derivation Input
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.
KeyingMode |
KDF output bytes |
Used as |
Length (bytes) |
0 Completion |
0..63 |
MSK |
64 |
64..127 |
EMSK |
64 |
128..191 |
AMSK |
64 |
192..223 |
MethodId |
32 |
224..255 |
Kms |
32 |
256..287 |
Kmp |
32 |
288..319 |
Kz |
32 |
1 or 2 Reconnect, rekeying without ECDHE, or with ECDHE and unchanged cryptosuite |
0..63 |
MSK |
64 |
64..127 |
EMSK |
64 |
128..191 |
AMSK |
64 |
192..223 |
MethodId |
32 |
224..255 |
Kms2 |
32 |
256..287 |
Kmp2 |
32 |
3 Reconnect, rekeying with ECDHE, new cryptosuite |
0..63 |
MSK |
64 |
64..127 |
EMSK |
64 |
128..191 |
AMSK |
64 |
192..223 |
MethodId |
32 |
224..255 |
Kms2 |
32 |
256..287 |
Kmp2 |
32 |
288..319 |
Kz |
32 |
Table 5: Key Derivation Output
Finally, every EAP method must export a Server-Id, Peer-Id, and Session-Id [
RFC 5247]. 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.
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
RFC 3748,
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.
If the NAI structure is invalid, the server
SHOULD send the error code 1001 to the peer. The recipient of an EAP-NOOB request or response
SHOULD send the following error codes back to the sender: 1002 if it cannot parse the message as a JSON object or the top-level JSON object has missing or unrecognized members; 1003 if a data field has an invalid value, such as an integer out of range, and there is no more specific error code available; 1004 if the received message type was unexpected in the current state; 2004 if the PeerId has an unexpected value; 2003 if the NoobId is not recognized; and 1005 if the ECDHE key is invalid.
The preferred way for the EAP server to rate limit EAP-NOOB connections from a peer is to use the SleepTime parameter in the Waiting Exchange. However, if the EAP server receives repeated EAP-NOOB connections from a peer that apparently should not connect to this server, the server
MAY indicate that the connections are unwanted by sending the error code 2001. After receiving this error message, the peer
MAY refrain from reconnecting to the same EAP server, and, if possible, both the EAP server and peer
SHOULD indicate this error condition to the user or server administrator. However, in order to avoid persistent denial of service, peer devices that are unable to alert a user
SHOULD continue to try to reconnect infrequently (e.g., approximately every 3600 seconds).
In the states indicated by "-" in
Table 14 in
Appendix A, user action is required to reset the association state or to recover it, for example, from backup storage. In those cases, the server sends the error code 2002 to the peer. If possible, both the EAP server and peer
SHOULD indicate this error condition to the user or server administrator.
If there is no matching protocol version, the peer sends the error code 3001 to the server. If there is no matching cryptosuite, the peer sends the error code 3002 to the server. If there is no matching OOB direction, the peer sends the error code 3003 to the server.
In practice, there is no way of recovering from these errors without software or hardware changes. If possible, both the EAP server and peer
SHOULD indicate these error conditions to the user.
If the receiver of the OOB message detects an unrecognized PeerId or incorrect fingerprint (Hoob) in the OOB message, the receiver
MUST remain in the Waiting for OOB (1) state as if no OOB message was received. The receiver
SHOULD indicate the failure to accept the OOB message to the user. No in-band error message is sent.
Note that if the OOB message was delivered from the server to the peer and the peer does not recognize the PeerId, the likely cause is that the user has unintentionally delivered the OOB message to the wrong peer device. If possible, the peer
SHOULD indicate this to the user; however, the peer device may not have the capability for many different error indications to the user, and it
MAY use the same indication as in the case of an incorrect fingerprint.
The rationale for the above is that the invalid OOB message could have been presented to the receiver by mistake or intentionally by a malicious party; thus, it should be ignored in the hope that the honest user will soon deliver a correct OOB message.
If the EAP server or peer detects an incorrect message authentication code (MACs, MACp, MACs2, or MACp2), it sends the error code 4001 to the other side. As specified in the beginning of
Section 3.6, the failed Completion Exchange will not result in server or peer state changes, while an error in the Reconnect Exchange will put both sides to the Reconnecting (3) state and thus lead to another reconnect attempt.
The rationale for this is that the invalid cryptographic message may have been spoofed by a malicious party; thus, it should be ignored. In particular, a spoofed message on the in-band channel should not force the honest user to perform the OOB Step again. In practice, however, the error may be caused by other failures, such as a software bug. For this reason, the EAP server
MAY limit the rate of peer connections with SleepTime after the above error. Also, there
SHOULD be a way for the user to reset the peer to the Unregistered (0) state so that the OOB Step can be repeated as the last resort.
Applications
MAY define new error messages for failures that are specific to the application or to one type of OOB channel. They
MAY also use the generic application-specific error code 5001 or the error codes 5002 and 5004, which have been reserved for indicating invalid data in the ServerInfo and PeerInfo fields, respectively. Additionally, anticipating OOB channels that make use of a URL, the error code 5003 has been reserved for indicating an invalid server URL.