Hi,
I have reviewed the eap-noob document and believe it is ready for adoption.
I have made a series of comments that are mostly editorial and some
clarifying questions. I am happy to review the document further.
Yours,
Daniel
[...]
Abstract
Extensible Authentication Protocol (EAP) provides support for
multiple authentication methods. This document defines the EAP-NOOB
authentication method for nimble out-of-band (OOB) authentication and
key derivation. This EAP method is intended for bootstrapping all
kinds of Internet-of-Things (IoT) devices that have a minimal user
interface and no pre-configured authentication credentials. The
method makes use of a user-assisted one-directional OOB channel
between the peer device and authentication server.
<mglt>
A nit. There are double spaces, so maybe :%s/ / /gc may be needed. I
believe
that *minimal* should be expanded here as it might be an important
characteristic of the object. Typically the ability to communicate an URL to
the end user, is a characteristic that is not generic to all devices at
least
maybe not the bulb or temperature network. I would be good that from the
abstract the reader knows if this methods apply or not.
</mglt>
1. Introduction
This document describes a method for registration, authentication and
key derivation for network-connected ubiquitous computing devices,
such as consumer and enterprise appliances that are part of the
Internet of Things (IoT). These devices may be off-the-shelf
hardware that is sold and distributed without any prior registration
or credential-provisioning process. Thus, the device registration in
a server database, ownership of the device, and the authentication
credentials for both network access and application-level security
must all be established at the time of the device deployment.
Furthermore, many such devices have only limited user interfaces that
could be used for their configuration. Often, the interfaces are
limited to either only input (e.g. camera) or output (e.g. display
screen). The device configuration is made more challenging by the
fact that the devices may exist in large numbers and may have to be
deployed or re-configured nimbly based on user needs.
More specifically, the devices may have the following
characteristics:
o no pre-established relation with a specific server or user,
<mglt>
I understand this characteristic as requiring that devices must be
completely
new. I have the impression that the characteristic concerns more the state
of
the device then the device itself. Does the text means that such
characteristics are not necessary or that these characteristic if existing
will
make the registration impossible. Typically, I imagine the following
scenarios.
I have a registered screen from in a server in my company. I am taking that
screen to the University that organises a workshop. Can the screen work with
two different accounts/registration on different servers ? Do I have to
necessarily factory reset the screen ? Do I have to redo the registration
procedure when I bring the screen back to my company ? Am I going to
possibly
register the screen I bought on second-hand-gatan ? </mglt>
o no pre-provisioned device identifier or authentication
credentials,
<mglt>I do have the same questions as above. </mglt>
o limited user interface and configuration capabilities.
<mglt>I am finding limited too vague to understand if my device is a
candidate
for this registration.</mglt>
Many proprietary OOB configuration methods exits for specific IoT
devices. The goal of this specification is to provide an open
standard and a generic protocol for bootstrapping the security of
network-connected appliances, such as displays, printers, speakers,
Aura & Sethi Expires May 1, 2020 [Page 3]
Internet-Draft EAP-NOOB October 2019
and cameras. The security bootstrapping in this specification makes
use of a user-assisted out-of-band (OOB) channel. The device
authentication relies on user having physical access to the device,
and the of the key exchange security is based on the assumption that
attackers are not able to observe or modify the messages conveyed
through the OOB channel. We follow the common approach taken in
pairing protocols: performing a Diffie-Hellman key exchange over the
insecure network and authenticating the established key with the help
of the OOB channel in order to prevent impersonation and man-in-the-
middle (MitM) attacks.
The solution presented here is intended for devices that have either
an input or output interface, such as a camera, microphone, display
screen, speakers or blinking LED light, which is able to send or
receive dynamically generated messages of tens of bytes in length.
<mglt>
I believe that this characteristics should be mentioned earlier as it
characterizes the devices. The contextual characteristic to perform the
procedure is that the user has physical access to it. The characteristic of
your method is, in my opinion, that you perform the registration without
any
pre-provisioning of the device. Instead only the user needs to have an
account
to the server.
"tens or bytes" tends to characterize the network capacity. I am wondering
if
we could have a more specific idea of the maximum length of the message.
Maybe
that will dpeend on the type of devices.
device resources: it might be good to provide an estimating of the necessary
resources in term of software/RAM necessary to run the protocol. This would
probably remove a bunch of devices.
</mglt>
Naturally, this solution may not be appropriate for very small sensors or
actuators that have no user interface at all or for devices that are
inaccessible to the user. We also assume that the OOB channel is at least
partly automated (e.g. camera scanning a bar code) and, thus, there is no
need
to absolutely minimize the length of the data transferred through the OOB
channel. This differs, for example, from Bluetooth simple pairing
[BluetoothPairing], where it is critical to minimize the length of the
manually
transferred or compared codes. Since the OOB messages are dynamically
generated, we do not support static printed registration codes. This also
prevents attacks where a static secret code would be leaked.
2. Terminology
[...]
peer The entity that responds to the authenticator. In
[IEEE-802.1X], this entity is known as the supplicant.
<mglt>It might be good to explicitly mention the device is now designated as
peer.</mglt>
3. EAP-NOOB protocol
[...]
3.1. Protocol overview
One EAP-NOOB protocol execution spans multiple EAP conversations,
called Exchanges. This is necessary to leave time for the OOB
message to be delivered, as will be explained below.
<mglt>"leave time": This was unclear to me until I read the following
paragraph. My first reading was that multiple messages would take sufficient
time, so the OOB message can be delivered (in paralell ?). Then I thought
that
the implication of the three parties requires multiple exchanges. I think
that
multiple exchange enable multiple parties as well as the necessary
flexibility
that is required by a human interaction with non deterministic delays which
requires probing capabilities. I also have the impression that we could
introduce a better terminology to distinguish session - that includes the
initial Exchange, step a set of exchanges within a session a exchange with
one
round trip. Note this is just a suggestion, and I am not sure what is
commonly
used. </mglt>
The overall protocol starts with the Initial Exchange
<mglt>There is probably a reference to EAP that is needed in the first line
of
the paragraph as well as an indication that the Initial Ex is part of the
EAP
message.</mglt>
[...]
OOB Output/Initial Exchange/
Waiting Exchange
.-----.
| v
.------------------. Initial .------------------.
| | Exchange | |
.->| 0. Unregistered |---------------->|1. Waiting for OOB|
| | | | |
| '------------------' '------------------'
| | | ^
User Reset Completion | | |
| Exchange | OOB OOB
|<-------. .-------------------------' Input Reject/
| | | | Initial
| | | | Exchange
| | v v |
| .------------------. Completion .------------------.
| | | Exchange | |
| | 4. Registered |<----------------| 2. OOB Received |
| | | | |
| '------------------' '------------------'
| | ^
| Mobility/ |
| Timeout/ Reconnect
| Failure Exchange
| | |
| v |
| .-----------------.
| | |
'--| 3. Reconnecting |
| |
'-----------------'
<mglt> maybe that would be good to specify (explicitly) the numbers in the
figure represents state values. I think the first time I went through the
graph I interpreted as chronological indications. It took me also some time
to
figure out that 0..2 means 0-2 or 0, 1, 2. I think (1) would be clearer
than 1.
if the number represents a state value. I am only providing this as an
input,
but I am also fin if I am the only one that got partly confused. </mglt>
Figure 1: EAP-NOOB server-peer association state machine
[...]
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
state, the server MUST NOT delete the association or go back to
states 0..2 without explicit user approval. Similarly, the peer MUST
NOT repeat the OOB Step unless the user explicitly deletes from the
peer the association with the server or resets the peer to the
Unregistered 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 SHOULD be equivalent to having deleted the
association data.
<mglt> I understand as a need to set mechanisms to prevent the peer and the
server to become de-synchronized as well as the peer to be associated
twice. It
is unclear to me why a double association needs to be prevented given that
the
peer is mot limited to one association. Naively, I would expect the peer to
select one of these association. That it ends int the expected association
is a
different thing.
I am questioning the "The server MUST NOT repeat a successful OOB Step". I
have
the impression, the server decides whether OOB is neeeded or not. I have the
impression that depends on the trust model.
If the purpose is to get the device authenticated by the server that
associate
the device to a user. We can have the server requesting an OOB operation for
devices that have not been used for a while. This could be correct if you
believe that an attacker does not have access to the device for example.
Homenetwork may fall in that category. When the devices enters into a OOB
phase
it either removes older associations or add this one. This would at least
ensure that the server and devices are always able to recover from one
another.
The main issue I see is that any server can overwrite the device's
association, but I am not sure this is required in every scenarii. I believe
that the two approach may be described.
If this is not expected, this means that we expect that when the
authentication
failure happens, the device should not set a new association. Potential
reasons
for a failure may be the device not being registered, the procedure to fail
because of a bug.... I am wondering how the user may be able to see that the
device has not been registered AND the server is not the expected server. In
this case we do not want to reset the device, while in other cases, a retry
or
a reset will be sufficient. If the server identity doesn't appear my
feeling is
that, the most common operation will be reset and register again.
While going through the document I see that error message can make the
distinction. I believe that would be worth mentioning it. </mglt>
[...]
3.2. Protocol messages and sequences
[...]
3.2.1. Common handshake in all EAP exchanges
</mglt>The title should be EAP-NOOB I think.</mglt>
All EAP-NOOB exchanges start with common handshake messages. The
handshake starts 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 exchanges begin with the authenticator
<mglt>Though I am not native english speaker, "each exchanges begin" sounds
strange to me. wouldn't "the" more appropriated?</mglt>
[...]
If one of 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
indicates 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 Registered (4) state.
</mglt>I am wondering if some normative language should not be used to
describe
the server's behavior (MUST).</mglt>
EAP Peer EAP Server
| |
|<----------- EAP-Request/Identity -| |
| |
| |
|------------ EAP-Response/Identity -------------->|
| (NAI=n...@eap-noob.net) |
| |
| |
|<----------- EAP-Request/EAP-NOOB ----------------|
| (Type=9) |
| |
| |
|------------ EAP-Response/EAP-NOOB -------------->|
| (Type=9,[PeerId],PeerState=1) |
| |
| continuing with exchange-specific messages... |
Figure 2: Common handshake in all EAP-NOOB exchanges
3.2.2. Initial Exchange
<mglt>As a comment, I am wondering if Initial Step would not be more
appropriated instead of Exchange, each step being accomplished by a number
of
exchanges. </mglt>
[...]
3.2.3. OOB Step
[...]
The OOB receiver MUST compare the received value of the fingerprint
Hoob with a value that it computes locally. 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, 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.
<mglt>I probably have missed them, but it is unclear to me what a Noob or
Hoob
are it would be good to provide a high level definition as well as a
reference
to the section 3.3.2. Message data fields.</mglt>
[...]
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, so that the
two latest values are always accepted.
<mglt> If I understand it correctly, the number of Nood will be 2 in that
case,
and the received will be the first two. </mglt>
[...]
3.2.4. Completion Exchange
After the Initial Exchange, if both the server and the peer support
the peer-to-server direction for the OOB channel, 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. Also,
if both sides support the server-to-peer direction of the OOB
exchange 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 with the Completion
Exchange or Waiting Exchange (see Section 3.2.1 on how the server
makes this decision).
<mglt>I understand that Completion requires the session of a new session
that
is the agreement of a new ecdhe secret and does not leverage from the
established session for the Initial exchange. I understand better why the
authentication procedure is particular. I am wondering if we do not include
a
Hoob associated to the previous Initial Exchange as well as the OOB
exchanges
to make sure there is a strong binding between these exchanges. This could
be
achieved at least partly by specifying the Noob to include Hoob.
Going through the document I have seen Z, which might address my concerns.
</mglt>
[...]
3.2.5. Waiting Exchange
[...]
3.3. Protocol data fields
This section defines the various identifiers and data fields used in
the EAP-NOOB protocol.
3.3.1. Peer identifier, realm and NAI
[...]
Another way to generate the identifiers is to choose a random
22-character alphanumeric string. It is RECOMMENDED to not use
identifiers longer than this because they result in longer OOB
messages.
<mglt> 22 leads to 154 or 176 bits. I am wondering if limiting the number
the
expected number of device could be recommended in order to limit the size of
the message. </mglt>
[...]
The default realm for the peer is "eap-noob.net". However, the user
<mglt> the domain name has been registered. I believe that is a useful
information to mention. I am wondering how this domain will remain reserved
once standardized and if something under .arpa may not be preferred as being
managed by the IANA. </mglt>
[...]
Hoob = H(Dir,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,Cryptos
uitep,Dirp,[Realm],PeerInfo,0,PKs,Ns,PKp,Np,Noob).
NoobId = H("NoobId",Noob).
MACs = HMAC(Kms; 2,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,C
ryptosuitep,Dirp,[Realm],PeerInfo,0,PKs,Ns,PKp,Np,Noob).
MACp = HMAC(Kmp; 1,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,C
ryptosuitep,Dirp,[Realm],PeerInfo,0,PKs,Ns,PKp,Np,Noob).
MACs2 = HMAC(Kms2; 2,Vers,Verp,PeerId,Cryptosuites,"",[ServerInfo]
,Cryptosuitep,"",[Realm],[PeerInfo],KeyingMode,[PKs2],Ns2,[PKp2],N
p2,"")
MACp2 = HMAC(Kmp2; 1,Vers,Verp,PeerId,Cryptosuites,"",[ServerInfo]
,Cryptosuitep,"",[Realm],[PeerInfo],KeyingMode,[PKs2],Ns2,[PKp2],N
p2,"")
Missing input values are represented by empty strings "" in the
array. The values indicated with "" above are always empty strings.
Realm is included in the computation of MACs and MACp if it was sent
or received in the preceding Initial Exchange. 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 "".
<mglt>maybe an explanation for [] is also needed. </mglt>
[...]
3.5. Key derivation
[...]
+------------+------------------------------------------------------+
| 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 three different modes (KeyingMode), which are
specified in Table 3. Table 4 defines the inputs to KDF in each
KeyingMode.
<mglt>I am counting 4 modes. I am also wondering why the Initial Exchange
is
not mentioned ? </mglt>
[...]
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
