Subject: [Emu] draft-aura-eap-noob-07 review

From: Daniel Migault <[email-masked]>
Date: Thu, 16 Jan 2020 11:13:53 -0500

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=[email-masked])                     |
          |                                                  |
          |                                                  |
          |<----------- 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>
[...]