[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

Network Working Group                                            T. Aura
Internet-Draft                                          Aalto University
Intended status: Standards Track                                M. Sethi
Expires: January 3, 2019                                        Ericsson
                                                            July 2, 2018


          Nimble out-of-band authentication for EAP (EAP-NOOB)
                         draft-aura-eap-noob-03

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.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 3, 2019.

Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect



Aura & Sethi             Expires January 3, 2019                [Page 1]


Internet-Draft                  EAP-NOOB                       July 2018


   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  EAP-NOOB protocol . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Protocol overview . . . . . . . . . . . . . . . . . . . .   5
     3.2.  Protocol messages and sequences . . . . . . . . . . . . .   8
       3.2.1.  Initial Exchange  . . . . . . . . . . . . . . . . . .   8
       3.2.2.  OOB Step  . . . . . . . . . . . . . . . . . . . . . .  10
       3.2.3.  Completion Exchange . . . . . . . . . . . . . . . . .  11
       3.2.4.  Waiting Exchange  . . . . . . . . . . . . . . . . . .  13
     3.3.  Protocol data fields  . . . . . . . . . . . . . . . . . .  15
       3.3.1.  Peer identifier, realm and NAI  . . . . . . . . . . .  15
       3.3.2.  Message data fields . . . . . . . . . . . . . . . . .  16
     3.4.  Fast reconnect and rekeying . . . . . . . . . . . . . . .  21
       3.4.1.  Persistent EAP-NOOB association . . . . . . . . . . .  21
       3.4.2.  Reconnect Exchange  . . . . . . . . . . . . . . . . .  22
       3.4.3.  User reset  . . . . . . . . . . . . . . . . . . . . .  24
     3.5.  Key derivation  . . . . . . . . . . . . . . . . . . . . .  25
     3.6.  Error handling  . . . . . . . . . . . . . . . . . . . . .  28
       3.6.1.  Invalid messages  . . . . . . . . . . . . . . . . . .  29
       3.6.2.  Unwanted peer . . . . . . . . . . . . . . . . . . . .  29
       3.6.3.  State mismatch  . . . . . . . . . . . . . . . . . . .  29
       3.6.4.  Negotiation failure . . . . . . . . . . . . . . . . .  29
       3.6.5.  Cryptographic verification failure  . . . . . . . . .  30
       3.6.6.  Application-specific failure  . . . . . . . . . . . .  31
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  31
     4.1.  Cryptosuites  . . . . . . . . . . . . . . . . . . . . . .  31
     4.2.  Error codes . . . . . . . . . . . . . . . . . . . . . . .  32
     4.3.  Domain name reservation considerations  . . . . . . . . .  32
   5.  Implementation Status . . . . . . . . . . . . . . . . . . . .  33
     5.1.  Implementation with wpa_supplicant and hostapd  . . . . .  33
     5.2.  Protocol modeling . . . . . . . . . . . . . . . . . . . .  34
   6.  Security considerations . . . . . . . . . . . . . . . . . . .  34
     6.1.  Authentication principle  . . . . . . . . . . . . . . . .  34
     6.2.  Identifying correct endpoints . . . . . . . . . . . . . .  36
     6.3.  Trusted path issues . . . . . . . . . . . . . . . . . . .  36
     6.4.  Peer identifiers and attributes . . . . . . . . . . . . .  37
     6.5.  Identify protection . . . . . . . . . . . . . . . . . . .  38
     6.6.  Downgrading threats . . . . . . . . . . . . . . . . . . .  38
     6.7.  Denial-of-service threats . . . . . . . . . . . . . . . .  39
     6.8.  EAP security claims . . . . . . . . . . . . . . . . . . .  39
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  41



Aura & Sethi             Expires January 3, 2019                [Page 2]


Internet-Draft                  EAP-NOOB                       July 2018


     7.1.  Normative references  . . . . . . . . . . . . . . . . . .  41
     7.2.  Informative references  . . . . . . . . . . . . . . . . .  42
   Appendix A.  Exchanges and events per state . . . . . . . . . . .  44
   Appendix B.  Application-specific parameters  . . . . . . . . . .  45
   Appendix C.  ServerInfo and PeerInfo contents . . . . . . . . . .  46
   Appendix D.  EAP-NOOB roaming . . . . . . . . . . . . . . . . . .  48
   Appendix E.  OOB message as URL . . . . . . . . . . . . . . . . .  49
   Appendix F.  Example messages . . . . . . . . . . . . . . . . . .  50
   Appendix G.  TODO list  . . . . . . . . . . . . . . . . . . . . .  52
   Appendix H.  Version history  . . . . . . . . . . . . . . . . . .  52
   Appendix I.  Acknowledgments  . . . . . . . . . . . . . . . . . .  54
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  54

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,

   o  no pre-provisioned device identifier or authentication
      credentials,

   o  limited user interface and configuration capabilities.

   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,
   and cameras.  The security bootstrapping in this specification makes
   use of a user-assisted out-of-band (OOB) channel.  The security is
   based on the assumption that attackers are not able to observe or



Aura & Sethi             Expires January 3, 2019                [Page 3]


Internet-Draft                  EAP-NOOB                       July 2018


   modify the messages conveyed through the OOB channel.  We follow the
   common approach of 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 or display screen,
   which is able to send or receive dynamically generated messages of
   tens of bytes in length.  Naturally, this solution may not be
   appropriate for very small sensors or actuators that have no user
   interface at all.  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

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   In addition, this document frequently uses the following terms as
   they have been defined in [RFC5216]:

   authenticator  The entity initiating EAP authentication.

   peer  The entity that responds to the authenticator.  In
         [IEEE-802.1X], this entity is known as the supplicant.

   server  The entity that terminates the EAP authentication method with
         the peer.  In the case where no backend authentication server
         is used, the EAP server is part of the authenticator.  In the
         case where the authenticator operates in pass-through mode, the
         EAP server is located on the backend authentication server.

3.  EAP-NOOB protocol

   This section defines the EAP-NOOB protocol.  The protocol is a
   generalized version of the original idea presented by Sethi et al.
   [Sethi14].





Aura & Sethi             Expires January 3, 2019                [Page 4]


Internet-Draft                  EAP-NOOB                       July 2018


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.

   The overall protocol starts with the Initial Exchange, in which 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 Elliptic Curve
   Diffie-Hellman (ECDH) 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, ECDH rekeying,
   and updates of cryptographic algorithms can be achieved with the
   Reconnect Exchange.
























Aura & Sethi             Expires January 3, 2019                [Page 5]


Internet-Draft                  EAP-NOOB                       July 2018


                                       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 |
        |                 |
        '-----------------'


         Figure 1: EAP-NOOB server-peer association state machine

   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 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 either endpoint may
   cause the protocol to fall back to the Initial Exchange.  After the
   Completion Exchange has resulted in EAP-Success, the association



Aura & Sethi             Expires January 3, 2019                [Page 6]


Internet-Draft                  EAP-NOOB                       July 2018


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

   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 resets also 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.net"
   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 and, secondly, it allows routing of the
   EAP-NOOB sessions to a specific authentication server in the 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.  In particular, EAP-NOOB supports also peers with no input



Aura & Sethi             Expires January 3, 2019                [Page 7]


Internet-Draft                  EAP-NOOB                       July 2018


   capability in the user interface.  Since these output-only devices
   cannot be told to perform the protocol at the right moment, they 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.
   For example, consider a printer (peer) that outputs the OOB message
   on paper, which is then scanned for the server.  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 and Completion
   Exchanges in different EAP conversations.

3.2.  Protocol messages and sequences

   This section defines the EAP-NOOB exchanges, which correspond to EAP
   conversations.  The protocol messages in each exchange and the data
   members in each message are listed in the diagrams below.

   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, containing
   the network access identifier (NAI), which conveys both the peer
   identity and the current peer state as defined in Section 3.3.1.

   After receiving the NAI, the server chooses the EAP-NOOB exchange,
   i.e. the ensuing message sequence, based on the combination of the
   peer and server states.  The peer recognizes the exchange based on
   the message type field (Type) of the EAP-NOOB request received from
   the server.  The available exchanges are defined in the following
   subsections.  Each exchange comprises one or more EAP requests-
   response pairs and ends in either EAP-Failure, indicating that
   authentication is not (yet) successful, or in EAP-Success.

3.2.1.  Initial Exchange

   Upon receiving the EAP-Response/Identity from the peer, if either the
   peer or the 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.

   The Initial Exchange comprises two EAP-NOOB request-response pairs,
   one for version, algorithm and parameter negotiation and the other
   for the ECDH key exchange.  The first EAP-NOOB request (Type=1) from
   the server contains a newly allocated PeerId for the peer and an
   optional Realm.  The server allocates a new PeerId in the Initial
   Exchange regardless of any old PeerId in the username part of the



Aura & Sethi             Expires January 3, 2019                [Page 8]


Internet-Draft                  EAP-NOOB                       July 2018


   received NAI.  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=1) with the selected
   protocol version (Verp), the received PeerId, the selected
   cryptosuite (Cryptosuitep), an indicator of the OOB channel
   directions selected by the peer (Dirp), and a PeerInfo object.  In
   the second EAP-NOOB request and response (Type=2), the server and
   peer exchange the public components of their ECDH keys and nonces
   (PKs,Ns,PKp,Np).  The ECDH keys MUST be based on the negotiated
   cryptosuite.  The Initial Exchange ends with EAP-Failure from the
   server because the authentication cannot yet be completed.


        EAP Peer                                        EAP Server
          |                                                  |
          |<----------- EAP-Request/Identity -|              |
          |                                                  |
          |                                                  |
          |------------ EAP-Response/Identity -------------->|
          |      (NAI=noob|PeerId+sX@eap-noob.net)           |
          |                                                  |
          |                                                  |
          |<----------- EAP-Request/EAP-NOOB ----------------|
          |      (Type=1,Vers,PeerId,[Realm],                |
          |       Cryptosuites,Dirs,ServerInfo)              |
          |                                                  |
          |                                                  |
          |------------ EAP-Response/EAP-NOOB -------------->|
          |      (Type=1,Verp,PeerId,Cryptosuitep,           |
          |        Dirp,PeerInfo)                            |
          |                                                  |
          |                                                  |
          |<----------- EAP-Request/EAP-NOOB ----------------|
          |      (Type=2,PeerId,PKs,Ns,[SleepTime])          |
          |                                                  |
          |                                                  |
          |------------ EAP-Response/EAP-NOOB -------------->|
          |      (Type=2,PeerId,PKp,Np)                      |
          |                                                  |
          |                                                  |
          |<----------- EAP-Failure -------------------------|
          |                                                  |


                        Figure 2: Initial Exchange




Aura & Sethi             Expires January 3, 2019                [Page 9]


Internet-Draft                  EAP-NOOB                       July 2018


   At the conclusion of the Initial Exchange, both the server and the
   peer move to the Waiting for OOB (1) state.

3.2.2.  OOB Step

   The OOB Step, labeled as OOB Output and OOB Input in Figure 1, takes
   place after the Initial Exchange.  Depending on the direction
   negotiated, the peer or the server outputs the OOB message shown in
   Figure 3 or Figure 4.  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.


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


                Figure 3: OOB Step, from peer to EAP server


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


                Figure 4: OOB Step, from EAP server to peer

   The receiver of the OOB message 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 OOB message.  For usability
   reasons, the 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.

   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



Aura & Sethi             Expires January 3, 2019               [Page 10]


Internet-Draft                  EAP-NOOB                       July 2018


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

   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 OOB message expiry
   or similar error detected in the Completion Exchange causes it to
   return to the Waiting for OOB (1) state.  It is RECOMMENED that the
   OOB receiver notifies the user about redundant OOB messages, but it
   MAY also discard them silently.

   The sender will typically generate a new Noob, and therefore a new
   OOB message, at constant intervals (NoobInterval).  The RECOMMENDED
   interval is NoobInterval = NoobTimeout / 2, so that the two latest
   values are always accepted.  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 one of them.

   The details of the OOB channel implementation including the message
   encoding are defined by the application.  Appendix E gives an example
   of how the OOB message can be encoded as a URL that may be embedded
   in a QR code and NFC tag.

3.2.3.  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.  Once the server receives the EAP-
   Response/Identity, if one of the server and peer 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 SHOULD continue with the Completion Exchange.

   The Completion Exchange comprises one or two EAP-NOOB request-
   response pairs.  If the peer is in the Waiting for OOB (1) state, the



Aura & Sethi             Expires January 3, 2019               [Page 11]


Internet-Draft                  EAP-NOOB                       July 2018


   OOB message has been sent in the peer-to-server direction.  In that
   case, only one request-response pair (Type=4) takes place.  In the
   request, the server sends the NoobId value, 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 that case, two request-
   response pairs (Type=8 and Type=4) are needed.  With the first
   request, the server discovers 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 and sometimes only request-response pair (Type=4) 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.1) and the Completion Exchange ends
   in EAP-Failure.

   After successful Completion Exchange, both the server and the peer
   move to the Registered (4) state.  They also derive the output key
   material and store the persistent association state as defined in
   Section 3.4 and Section 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 1006, see Section 3.6.1) and the
   Completion Exchange ends in EAP-Failure.  The recipient of the error
   message 1006 moves back to the Waiting for OOB (1) state.  This state
   transition is shown as OOB Reject in Figure 1 (even though it really
   is a specific type of failed Completion Exchange).  The sender of the
   error message, on the other hand, 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 by observing that both the
   server and peer are in the OOB Received state (2).  In that case, as




Aura & Sethi             Expires January 3, 2019               [Page 12]


Internet-Draft                  EAP-NOOB                       July 2018


   a tiebreaker, the server MUST behave as if only the server-to-peer
   message was delivered.


        EAP Peer                                        EAP Server
          |                                                  |
          |<----------- EAP-Request/Identity -|              |
          |                                                  |
          |                                                  |
          |------------ EAP-Response/Identity -------------->|
          |      (NAI=PeerId+sX@eap-noob.net)                |
          |                                                  |
          |                                                  |
          |<----------- [ EAP-Request/EAP-NOOB ] ------------|
          |      (Type=8,PeerId)                             |
          |                                                  |
          |                                                  |
          |------------ [ EAP-Response/EAP-NOOB ] ---------->|
          |      (Type=8,PeerId,NoobId)                      |
          |                                                  |
          |                                                  |
          |<----------- EAP-Request/EAP-NOOB ----------------|
          |      (Type=4,PeerId,NoobId,MACs)                 |
          |                                                  |
          |                                                  |
          |------------ EAP-Response/EAP-NOOB -------------->|
          |      (Type=4,PeerId,MACp)                        |
          |                                                  |
          |                                                  |
          |<----------- EAP-Success -------------------------|
          |                                                  |


                       Figure 5: Completion Exchange

3.2.4.  Waiting Exchange

   As explained in Section 3.2.3, the peer SHOULD probe the server for
   completion of the OOB Step.  If both the server and peer states are
   Waiting for OOB (1), the server will continue with the Waiting
   Exchange (message Type=3).  The main purpose of this exchange is to
   indicate to the peer that the server has not yet received a peer-to-
   server OOB message.

   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 Waiting
   Exchange a minimum time to wait before probing the server again.  A
   peer that has not received an OOB message MUST wait at least the



Aura & Sethi             Expires January 3, 2019               [Page 13]


Internet-Draft                  EAP-NOOB                       July 2018


   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
   SHOULD wait for an application-specified minimum time.

   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.2).  The peer SHOULD discard such
   expired Noob values even if the probing failed, e.g. because of
   failure to connect to the EAP server or incorrect MAC.  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 (3600) to prevent the peer from
   probing the server frequently.


        EAP Peer                                        EAP Server
          |                                                  |
          |<----------- EAP-Request/Identity -|              |
          |                                                  |
          |                                                  |
          |------------ EAP-Response/Identity -------------->|
          |      (NAI=PeerId+s1@eap-noob.net)                |
          |                                                  |
          |                                                  |
          |<----------- EAP-Request/EAP-NOOB ----------------|
          |      (Type=3,PeerId,[SleepTime])                 |
          |                                                  |
          |                                                  |
          |------------ EAP-Response/EAP-NOOB -------------->|
          |      (Type=3,PeerId)                             |
          |                                                  |
          |                                                  |
          |<----------- EAP-Failure -------------------------|
          |                                                  |


                        Figure 6: Waiting Exchange





Aura & Sethi             Expires January 3, 2019               [Page 14]


Internet-Draft                  EAP-NOOB                       July 2018


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

   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 [RFC7542]; however, it MUST NOT exceed
   60 bytes in length and MUST NOT contain the character '+'.  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 beforehand.
   One way to generate the identifiers is to choose a random 16-byte
   identifier and to base64url encode it without padding into a
   22-character string.  Another way to generate the identifiers is to
   choose a random 22-character alphanumeric string.  It should be noted
   that longer the peer identifiers result in longer OOB messages.

   When the peer is in one of the states 1..2, the peer 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.  When the peer
   is in the Unregistered (0) state, it MUST use the default value
   "noob" as its PeerId.

   The server MAY also assign a realm (Realm) to the peer by in Initial
   Exchange or Reconnect Exchange.  The realm value MUST follow the
   syntax of the utf8-realm specified in [RFC7542].  When the peer is in
   one of the states 1..2, the peer MUST use the Realm that the server
   assigned to it the latest Initial Exchange, if one was assigned.
   When the peer is in one of the persistent states 3..4, it MUST use
   the Realm from its persistent EAP-NOOB association, if one is stored
   in the association.  When the peer is in the Unregistered (0) state,
   or when the peer is in one of the other states 1..4 and the server
   has not assigned it a realm, the peer SHOULD use the default realm
   "eap-noob.net".  However, the user or application MAY provide a
   different default realm to the peer.

   To compose its NAI [RFC7542], the peer uses the PeerId in the user
   part and the Realm as the realm part.  When no server-assigned PeerId
   or Realm is available, the default value is used instead.  In the
   Unregistered (0) state, the peer must create the NAI as the
   concatenation of the PeerId, the symbol "@", and the Realm.  In the
   other states 1..4, the peer MUST create the NAI as the concatenation
   of the PeerId, the string "+s", a single digit indicating the state
   of the peer, and the Realm.




Aura & Sethi             Expires January 3, 2019               [Page 15]


Internet-Draft                  EAP-NOOB                       July 2018


   Note that a new peer typically sends the NAI "noob@eap-noob.net" in
   its first EAP-Response/Identity message, and this default NAI is
   always acceptable when the peer is in the Unregistered (0) state.
   The purpose of the state indicator "+sX" is to inform the server
   about the peer state without the cost of an additional round trip.
   The server uses this information together with the server state to
   decide on the type of the exchange and, thus, the type of the next
   EAP-Request.  The lack of a state indicator means that that peer is
   in state 0.

   The purpose of the server-assigned realm is to enable more flexible
   routing of the EAP sessions over the AAA infrastructure, including
   roaming scenarios (see Appendix D).  The possibility to configure a
   different default realm further enables registration of new devices
   while roaming.  It also enables manufacturers to set up their own AAA
   servers for bootstrapping of new peer devices.  Moreover, some
   Authenticators or AAA servers use the assigned Realm to determine
   peer-specific connection parameters, such as isolating the peer to a
   specific VLAN.

   The peer's PeerId and Realm 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 the server or until a new Realm is assigned in the Reconnect
   Exchange.  Resetting the server means deleting the association for
   the peer from the server database.

3.3.2.  Message data fields

   Table 1 defines the data fields in the protocol messages.  The in-
   band messages are formatted as JSON objects [RFC8259] 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.     |
   |                  | Currently, the only defined values are "[1]"   |
   |                  | and "1", respectively.                         |
   |                  |                                                |
   | PeerId           | Peer identifier as defined in Section 3.3.1.   |
   |                  |                                                |
   | Realm            | Peer identifier as defined in Section 3.3.1.   |
   |                  |                                                |



Aura & Sethi             Expires January 3, 2019               [Page 16]


Internet-Draft                  EAP-NOOB                       July 2018


   | Peer State "+sX" | Peer state indicator as defined in Section     |
   |                  | 3.3.1.                                         |
   |                  |                                                |
   | Type             | EAP-NOOB message type. The type is an integer  |
   |                  | in the range 0..8. EAP-NOOB requests and the   |
   |                  | corresponding responses share the same type    |
   |                  | value.                                         |
   |                  |                                                |
   | PKs, PKp         | The public components of the ECDH keys of the  |
   |                  | server and peer. PKs and PKp are sent in the   |
   |                  | JSON Web Key (JWK) format [RFC7517]. Detailed  |
   |                  | format of the JWK object is defined by the     |
   |                  | cryptosuite.                                   |
   |                  |                                                |
   | Cryptosuites,    | The identifiers of cryptosuites supported by   |
   | Cryptosuitep     | 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  |
   |                  | an 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. The registration of cryptosuites is   |
   |                  | specified in Section 4.1.                      |
   |                  |                                                |
   | Dirs, Dirp       | The OOB channel directions supported by the    |
   |                  | server and ones selected by the peer. The      |
   |                  | possible values are 1=peer-to-server, 2        |
   |                  | =server-to-peer, 3=both directions. Endpoints  |
   |                  | that are general-purpose computers or online   |
   |                  | services SHOULD support both directions. IoT   |
   |                  | devices with a limited user interface will     |
   |                  | mostly support only one direction. If the      |
   |                  | negotiated value is 3, the user may be         |
   |                  | presented with two OOB messages, one for each  |
   |                  | direction, even though the user needs to       |
   |                  | deliver only one of them. Since this can be    |
   |                  | confusing to the user, it is RECOMMENDED that  |
   |                  | the peer selects Dirp value 1 or 2. The EAP-   |
   |                  | NOOB protocol itself is designed to cope also  |
   |                  | with selected 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.                             |
   |                  |                                                |
   | Dir              | The actual direction of the OOB message (1     |



Aura & Sethi             Expires January 3, 2019               [Page 17]


Internet-Draft                  EAP-NOOB                       July 2018


   |                  | =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 or a Uniform Resource Locator (URL)       |
   |                  | [RFC4266] or some other information that helps |
   |                  | the user to 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 to distinguish     |
   |                  | between devices and to deliver the OOB message |
   |                  | to the correct peer through the out-of-band    |
   |                  | channel.                                       |
   |                  |                                                |
   | SleepTime        | The number of seconds for which peer MUST NOT  |
   |                  | start a new execution of the EAP-NOOB method   |
   |                  | with the authenticator, unless the peer        |
   |                  | receives the OOB message or the peer is reset  |
   |                  | by the user. 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   |



Aura & Sethi             Expires January 3, 2019               [Page 18]


Internet-Draft                  EAP-NOOB                       July 2018


   |                  | 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.                                    |
   |                  |                                                |
   | MACs, MACp       | Message authentication codes 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.     |
   |                  |                                                |
   | PKs2, PKp2       | The public components of the ECDH keys of the  |
   |                  | server and peer for the Reconnect Exchange.    |
   |                  | These MUST be present if a new cryptosuite was |
   |                  | negotiated. Otherwise, either endpoint MAY     |
   |                  | omit the field. PKs2 and PKp2 are sent in the  |
   |                  | JSON Web Key (JWK) format [RFC7517]. Detailed  |
   |                  | format of the JWK object is defined by the     |
   |                  | cryptosuite.                                   |
   |                  |                                                |
   | MACs2, MACp2     | Message authentication codes 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.    |
   |                  |                                                |
   +------------------+------------------------------------------------+

                       Table 1: Message data fields

   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
   hash function specified in the negotiated cryptosuite and truncated
   to the 16 leftmost bytes of the output.  The message authentication



Aura & Sethi             Expires January 3, 2019               [Page 19]


Internet-Draft                  EAP-NOOB                       July 2018


   codes (MACs, MACp, MACs2, MACp2) are computed with the HMAC function
   [RFC2104] based on the same cryptographic hash function 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 (16) 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 re-encoded, and whitespace MUST NOT
   be added anywhere in the JSON structure.  Implementers should check
   that their JSON library copies the elements as UTF-8 strings and does
   not modify then in any way.

   The inputs for computing the fingerprint and message authentication
   codes are the following:

      Hoob = H(Dir,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,Cryptos
      uitep,Dirp,[Realm],PeerInfo,PKs,Ns,PKp,Np,Noob).

      NoobId = H("NoobId",Noob).

      MACs = HMAC(Kms; 2,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,C
      ryptosuitep,Dirp,[Realm],PeerInfo,PKs,Ns,PKp,Np,Noob).

      MACp = HMAC(Kmp; 1,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,C
      ryptosuitep,Dirp,[Realm],PeerInfo,PKs,Ns,PKp,Np,Noob).

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

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

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

   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 in needed 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 for the
   HMACs are defined in Section 3.5.



Aura & Sethi             Expires January 3, 2019               [Page 20]


Internet-Draft                  EAP-NOOB                       July 2018


   The nonces (Ns, Np, Ns2, Np2, Noob), hash value (NoobId) and message
   authentication codes (MACs, MACp, MACs2, MACp2) in the in-band
   messages and when used as inputs to the hash and message
   authentication code MUST be base64url encoded [RFC4648].  The values
   Noob and Hoob in the OOB channel MAY also 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 (22-character string for a 16-byte nonce and
   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.

3.4.  Fast reconnect and rekeying

   EAP-NOOB implements Fast Reconnect ([RFC3748], section 7.2.1) that
   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 MSK and 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 non-persistent state data.  The failure would typically be
   detected by the peer or authenticator when session keys no longer are
   accepted by the other endpoint.  Change 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 to Reconnecting state.
   These state transitions are labeled Mobility/Timeout/Failure in
   Figure 1.  The EAP-NOOB method will then perform the Reconnect
   Exchange next time when EAP is triggered.

3.4.1.  Persistent EAP-NOOB association

   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 state (4) or Reconnecting state (3), as
   shown in Figure 1.



Aura & Sethi             Expires January 3, 2019               [Page 21]


Internet-Draft                  EAP-NOOB                       July 2018


   +--------------+---------------------------------+------------------+
   | Data field   | Value                           | Type             |
   +--------------+---------------------------------+------------------+
   | PeerId       | Peer identifier allocated by    | UTF-8 string     |
   |              | server                          | (typically 22    |
   |              |                                 | bytes)           |
   |              |                                 |                  |
   | Verp         | Negotiated protocol version     | integer          |
   |              |                                 |                  |
   | Cryptosuitep | Negotiated cryptosuite          | integer          |
   |              |                                 |                  |
   | Realm        | Optional realm assigned by      | UTF-8 string     |
   |              | server (default value is "eap-  |                  |
   |              | noob.net")                      |                  |
   |              |                                 |                  |
   | Kz           | Persistent key material         | 32 bytes         |
   +--------------+---------------------------------+------------------+

                 Table 2: Persistent EAP-NOOB association

3.4.2.  Reconnect Exchange

   The server chooses the Reconnect Exchange when peer is in the
   Reconnecting (3) state and the server itself is in the Registered (4)
   or Reconnecting (3) state.  The peer MUST NOT initiate EAP-NOOB when
   the peer is in Registered state.

   The Reconnect Exchange comprises three EAP-NOOB request-response
   pairs, one for algorithm and parameter negotiation, another for the
   nonce and ECDH key exchange, and the last one for exchanging message
   authentication codes.  In the first request and response (Type=5) 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 previously used with the same peer.
   The messages MAY also contain PeerInfo and ServerInfo objects.  In
   the second request and response (Type=6), the server and peer
   exchange public components of ECDH keys (PKs2, PKp2) and nonces (Ns2,
   Np2).  The server ECDH key MUST be fresh, i.e. not previously used
   with the same peer, and the peer ECDH key SHOULD be fresh, i.e. not
   previously used.

   In the third and final request and response (Type=7), 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.  If the peer finds that it has received the



Aura & Sethi             Expires January 3, 2019               [Page 22]


Internet-Draft                  EAP-NOOB                       July 2018


   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.1) and the
   Completion Exchange ends in EAP-Failure.

   If the negotiated cryptosuite is the same as previously, the server
   MAY refuse to perform a new ECDH exchange by omitting PKs2, and the
   peer MAY refuse by omitting PKp2.  If the server omits PKs2, the peer
   SHOULD also omit PKp2.  When one or both public keys are not present,
   the new EAP output values are derived from the fresh nonces and the
   previously established shared key Kz, as defined in Section 3.5.  The
   security property lost by refusing the ECDH exchange is forward
   secrecy.

   The server and peer MAY send updated Realm, ServerInfo and PeerInfo
   objects in the Reconnect Exchange.  If there is no update to the
   values, they SHOULD omit this information from the messages.

   Both sides MUST compare the received message authentication code with
   a locally computed value.  If the EAP server finds that it has
   received the correct value of MACp2, the Reconnect Exchange ends in
   EAP-Success; otherwise, in EAP-Failure.

   After successful Reconnect Exchange, both the server and the peer
   move to the Registered (4) state.  If the Realm was updated or if a
   new cryptosuite and Kz were negotiated, they also update the
   persistent EAP-NOOB association with the changed values.























Aura & Sethi             Expires January 3, 2019               [Page 23]


Internet-Draft                  EAP-NOOB                       July 2018


        EAP Peer                                        EAP Server
          |                                                  |
          |<----------- EAP-Request/Identity -|              |
          |                                                  |
          |                                                  |
          |------------ EAP-Response/Identity -------------->|
          |      (NAI=PeerId+s3@eap-noob.net)                |
          |                                                  |
          |                                                  |
          |<----------- EAP-Request/EAP-NOOB ----------------|
          |      (Type=5,Vers,PeerId,Cryptosuites,           |
          |       [Realm],[ServerInfo])                      |
          |                                                  |
          |                                                  |
          |------------ EAP-Response/EAP-NOOB -------------->|
          |      (Type=5,Verp,PeerId,Cryptosuitep,[PeerInfo])|
          |                                                  |
          |                                                  |
          |<----------- EAP-Request/EAP-NOOB ----------------|
          |      (Type=6,PeerId,[PKs2,]Ns2)                  |
          |                                                  |
          |                                                  |
          |------------ EAP-Response/EAP-NOOB -------------->|
          |      (Type=6,PeerId,[PKp2,]Np2)                  |
          |                                                  |
          |                                                  |
          |<----------- EAP-Request/EAP-NOOB ----------------|
          |      (Type=7,PeerId,MACs2)                       |
          |                                                  |
          |                                                  |
          |------------ EAP-Response/EAP-NOOB -------------->|
          |      (Type=7,PeerId,MACp2)                       |
          |                                                  |
          |                                                  |
          |<----------- EAP-Success -------------------------|
          |                                                  |


                       Figure 7: Reconnect Exchange

3.4.3.  User reset

   As shown in the association state machine in Figure 1, the only
   specified way for the association to return from the Registered state
   (4) to the Unregistered state (0) 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



Aura & Sethi             Expires January 3, 2019               [Page 24]


Internet-Draft                  EAP-NOOB                       July 2018


   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 administrator 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 SHOULD support situations where the "new" peer is actually
   a previously registered peer that has been reset by a user or has
   otherwise lost the persistent EAP-NOOB association data and needs to
   be merged with the old peer data in the server.

3.5.  Key derivation

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

   Table 3 defines the inputs to KDF.  In the Completion Exchange, the
   input Z comes from the preceding Initial exchange, while the
   Reconnect Exchange uses the Z just created.  KDF takes some
   additional inputs (OtherInfo), for which we use the concatenation
   format defined in section 5.8.1.2.1 of the NIST specification
   [NIST-DH].  OtherInfo consists of the AlgorithmId, PartyUInfo,
   PartyVInfo, and SuppPrivInfo fields.  The first three fields are
   fixed-length bit strings, and SuppPrivInfo is a variable-length



Aura & Sethi             Expires January 3, 2019               [Page 25]


Internet-Draft                  EAP-NOOB                       July 2018


   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's and peer's nonces.  In the Completion Exchange, the
   inputs also include the secret nonce Noob from the OOB message, while
   in the Reconnect Exchange, it is replaced by the shared secret Kz
   from the persistent EAP-NOOB association.

   A special case of the rekeying occurs if no ECDH public keys were
   exchanged in the Reconnect Exchange (or if only one endpoint sent its
   public key).  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 ECDH exchange, but
   also without forward secrecy.

   +-----------------+--------------+----------------------+-----------+
   | Exchange        | KDF input    | Value                | Length    |
   |                 | field        |                      | (bytes)   |
   +-----------------+--------------+----------------------+-----------+
   | Completion      | Z            | ECDH shared secret   | variable  |
   |                 |              | from PKs and PKp     |           |
   |                 | AlgorithmId  | "EAP-NOOB"           | 8         |
   |                 | PartyUInfo   | Np                   | 32        |
   |                 | PartyVInfo   | Ns                   | 32        |
   |                 | SuppPubInfo  | (not allowed)        |           |
   |                 | SuppPrivInfo | Noob                 | 16        |
   |                 |              |                      |           |
   | Reconnect,      | Z            | ECDH shared secret   | variable  |
   | rekeying with   |              | from PKs2 and PKp2   |           |
   | ECDH            | AlgorithmId  | "EAP-NOOB"           | 8         |
   |                 | PartyUInfo   | Np2                  | 32        |
   |                 | PartyVInfo   | Ns2                  | 32        |
   |                 | SuppPubInfo  | (not allowed)        |           |
   |                 | SuppPrivInfo | Kz                   | 32        |
   |                 |              |                      |           |
   | Reconnect,      | Z            | Kz                   | 32        |
   | rekeying        | AlgorithmId  | "EAP-NOOB"           | 8         |
   | without ECDH    | PartyUInfo   | Np2                  | 32        |
   |                 | PartyVInfo   | Ns2                  | 32        |
   |                 | SuppPubInfo  | (not allowed)        |           |
   |                 | SuppPrivInfo | (null)               | 0         |
   +-----------------+--------------+----------------------+-----------+

                       Table 3: Key derivation input

   Table 4 defines how the output bytes of KDF are used.  In addition to
   the EAP output values MSK and EMSK, the server and peer derive
   another shared secret key AMSK, which MAY be used for application-
   layer security.  Further output bytes are used internally by EAP-NOOB



Aura & Sethi             Expires January 3, 2019               [Page 26]


Internet-Draft                  EAP-NOOB                       July 2018


   for the message authentication keys (Kms,Kmp,Kms2,Kmp2).  The
   Completion Exchange also produces the shared secret Kz, which the
   server and peer store in the persistent EAP-NOOB association.  The
   Reconnect Exchange updates Kz only when a new cryptosuite is
   negotiated.  In that case, the server and peer update both the
   cryptosuite and Kz in the persistent EAP-NOOB association.  (Note the
   differences in the leftmost column between Table 4 and Table 3.)

    +-----------------+------------------+----------+----------------+
    | Exchange        | KDF output bytes | Used as  | Length (bytes) |
    +-----------------+------------------+----------+----------------+
    | 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             |
    |                 |                  |          |                |
    | Reconnect,      | 0..63            | MSK      | 64             |
    | no change in    | 64..127          | EMSK     | 64             |
    | cryptosuite     | 128..191         | AMSK     | 64             |
    |                 | 192..223         | MethodId | 32             |
    |                 | 224..255         | Kms2     | 32             |
    |                 | 256..287         | Kmp2     | 32             |
    |                 |                  |          |                |
    | Reconnect,      | 0..63            | MSK      | 64             |
    | new cryptosuite | 64..127          | EMSK     | 64             |
    | negotiated      | 128..191         | AMSK     | 64             |
    |                 | 192..223         | MethodId | 32             |
    |                 | 224..255         | Kms2     | 32             |
    |                 | 256..287         | Kmp2     | 32             |
    |                 | 288..319         | Kz       | 32             |
    |                 |                  |          |                |
    +-----------------+------------------+----------+----------------+

                      Table 4: Key derivation output

   Finally, every EAP method must export a Server-Id, Peer-Id and
   Session-Id [RFC5247].  In EAP-NOOB, the exported Peer-Id is the
   PeerId which 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 Type-Code xxx (TBA) with
   the MethodId, which is obtained from the KDF output as shown in
   Table 4.





Aura & Sethi             Expires January 3, 2019               [Page 27]


Internet-Draft                  EAP-NOOB                       July 2018


3.6.  Error handling

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


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


             Figure 8: Error notification from server to peer


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


             Figure 9: Error notification from peer to server

   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 and
   Completion Exchanges, each side MUST remain in its old state as if
   the failed exchange did not take place, with the exception that the
   recipient of error code 1006 processes it as specified in



Aura & Sethi             Expires January 3, 2019               [Page 28]


Internet-Draft                  EAP-NOOB                       July 2018


   Section 3.2.3.  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.

3.6.1.  Invalid messages

   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; 1005 if the PeerId has an unexpected value; 1006
   if the NoobId is not recognized; and 1007 if the ECDH key is invalid.

3.6.2.  Unwanted peer

   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 which 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.  However, in order to avoid
   persistent denial of service, the peer is not required to stop
   entirely from reconnecting to the server.

3.6.3.  State mismatch

   In the states indicated by "-" in Figure 10 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.

3.6.4.  Negotiation failure

   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.




Aura & Sethi             Expires January 3, 2019               [Page 29]


Internet-Draft                  EAP-NOOB                       July 2018


   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.  In
   particular, user action is needed for resetting the association from
   a persistent state to the Unregistered (0) state.

3.6.5.  Cryptographic verification failure

   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 state (1) as if no OOB message was
   received.  The receiver SHOULD indicate the failure to accept the OOB
   message to the user.

   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 destination.  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 and, 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, 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 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 and, 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 MUST be a way for the user to reset the EAP server and peer to
   the Unregistered state (0), so that the OOB Step can be repeated.








Aura & Sethi             Expires January 3, 2019               [Page 30]


Internet-Draft                  EAP-NOOB                       July 2018


3.6.6.  Application-specific failure

   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 5003, 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 invalid server URL.

4.  IANA Considerations

   This section provides guidance to the Internet Assigned Numbers
   Authority (IANA) regarding registration of values related to the EAP-
   NOOB protocol, in accordance with [RFC8126].

   The EAP Method Type number for EAP-NOOB needs to be assigned.

   This memo also requires IANA to create new registries as defined in
   the following subsections.

4.1.  Cryptosuites

   Cryptosuites are identified by an integer.  Each cryptosuite MUST
   specify an ECDH curve for the key exchange, encoding of the ECDH
   public key as a JWK object, and a cryptographic hash function for the
   fingerprint and MAC computation and key derivation.  The hash value
   output by the cryptographic hash function MUST be at least 32 bytes
   in length.  The following suites are defined by EAP-NOOB:

   +-------------+-----------------------------------------------------+
   | Cryptosuite | Algorithms                                          |
   +-------------+-----------------------------------------------------+
   | 1           | ECDH curve Curve25519 [RFC7748], public-key format  |
   |             | [RFC7518] Section 6.2.1, hash function SHA-256      |
   |             | [RFC6234]                                           |
   +-------------+-----------------------------------------------------+

                      Table 5: EAP-NOOB cryptosuites

   An example of Cryptosuite 1 public-key encoded as a JWK object is
   given below (line breaks are for readability only).

   "jwk":{"kty":"EC","crv":"Curve25519","x":"3p7bfXt9wbTTW2HC7OQ1Nz-
   DQ8hbeGdNrfx-FG-IK08"}






Aura & Sethi             Expires January 3, 2019               [Page 31]


Internet-Draft                  EAP-NOOB                       July 2018


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

4.2.  Error codes

   The error codes defined by EAP-NOOB are listed in Table 6.

          +------------+----------------------------------------+
          | Error code | Purpose                                |
          +------------+----------------------------------------+
          | 1001       | Invalid NAI                            |
          | 1002       | Invalid message structure              |
          | 1003       | Invalid data                           |
          | 1004       | Unexpected message type                |
          | 1005       | Unexpected peer identifier             |
          | 1006       | Unrecognized OOB message identifier    |
          | 1007       | Invalid ECDH key                       |
          | 2001       | Unwanted peer                          |
          | 2002       | State mismatch, user action required   |
          | 3001       | No mutually supported protocol version |
          | 3002       | No mutually supported cryptosuite      |
          | 3003       | No mutually supported OOB direction    |
          | 4001       | MAC verification failure               |
          | 5001       | Application-specific error             |
          | 5002       | Invalid server info                    |
          | 5003       | Invalid server URL                     |
          | 5004       | Invalid peer info                      |
          | 6001-6999  | Private and experimental use           |
          +------------+----------------------------------------+

                       Table 6: EAP-NOOB error codes

   Assignment of new error codes MUST be done through IANA with
   "Specification Required" and "IESG Approval" as defined in [RFC8126],
   with the exception of the range 6001-6999, which is reserved for
   "Private Use" and "Experimental Use".

4.3.  Domain name reservation considerations

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

   o  Users: Non-admin users are not expected to encounter this name or
      recognize it as special.  AAA administrators may need to recognize
      the name.




Aura & Sethi             Expires January 3, 2019               [Page 32]


Internet-Draft                  EAP-NOOB                       July 2018


   o  Application Software: Application software is not expected to
      recognize this domain name as special.

   o  Name Resolution APIs and Libraries: Name resolution APIs and
      libraries are not expected to recognize this domain name as
      special.

   o  Caching DNS Servers: Caching servers are not expected to recognize
      this domain name as special.

   o  Authoritative DNS Servers: Authoritative DNS servers MUST respond
      to queries for eap-noob.net with NXDOMAIN.

   o  DNS Server Operators: Except for the authoritative DNS server,
      there are no special requirements for the operators.

   o  DNS Registries/Registrars: There are no special requirements for
      DNS registrars.

5.  Implementation Status

   This section records the status of known implementations of the
   protocol defined by this specification at the time of posting of this
   Internet-Draft, and is based on a proposal described in [RFC7942].
   The description of implementations in this section is intended to
   assist the IETF in its decision processes in progressing drafts to
   RFCs.  Please note that the listing of any individual implementation
   here does not imply endorsement by the IETF.  Furthermore, no effort
   has been spent to verify the information presented here that was
   supplied by IETF contributors.  This is not intended as, and must not
   be construed to be, a catalog of available implementations or their
   features.  Readers are advised to note that other implementations may
   exist.

5.1.  Implementation with wpa_supplicant and hostapd

   o  Responsible Organization: Aalto University

   o  Location: <https://github.com/tuomaura/eap-noob>

   o  Coverage: This implementation includes all of the features
      described in the current specification.  The implementation
      supports two dimensional QR codes and NFC as example out-of-band
      (OOB) channels

   o  Level of Maturity: Alpha

   o  Version compatibility: Version 03 of the draft implemented



Aura & Sethi             Expires January 3, 2019               [Page 33]


Internet-Draft                  EAP-NOOB                       July 2018


   o  Licensing: BSD

   o  Contact Information: Tuomas Aura, tuomas.aura@aalto.fi

5.2.  Protocol modeling

   The current EAP-NOOB specification has been modeled with the mCRL2
   formal specification language [mcrl2].  The model
   <https://github.com/tuomaura/eap-noob/protocolmodel/mrcl2/> was used
   mainly for simulating the protocol behavior and for verifying basic
   safety and liveness properties as part of the specification process.
   For example, the model was used to verify the correctness of the
   tiebreaking mechanism when two OOB messages are received
   simultaneously, one in each direction.  The mCRL2 model is not
   intended for verifying security of the authenticated key-exchange; a
   different modeling method is needed for that.  It was, however, used
   to verify that a man-in-the-middle attacker cannot cause persistent
   failure by spoofing a finite number of messages.

6.  Security considerations

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

6.1.  Authentication principle

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

   The additional security provided by the cryptographic fingerprint
   Hoob is somewhat intricate to understand.  The endpoint that receives
   the OOB message uses Hoob to verify the integrity of the ECDH
   exchange.  Thus, the OOB receiver can detect impersonation and man-



Aura & Sethi             Expires January 3, 2019               [Page 34]


Internet-Draft                  EAP-NOOB                       July 2018


   in-the-middle attacks on the in-band channel.  The other endpoint,
   however, is not equally protected because the OOB message and
   fingerprint are sent only in one direction.  Some protection to the
   OOB sender is afforded by the fact that the user may notice the
   failure of the association at the OOB receiver and therefore reset
   the OOB sender.  Other device-pairing protocols have solved similar
   situations by requiring the user to confirm to the OOB sender that
   the association was accepted by the OOB receiver, e.g. by pressing an
   "accept" button on the sender side.  Applications MAY implement EAP-
   NOOB in this way.  Nevertheless, since EAP-NOOB was designed to work
   with strictly one-directional OOB communication and the fingerprint
   is only the second authentication feature, the EAP-NOOB specification
   does not mandate such explicit confirmation to the OOB sender.

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

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

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

   The users delivering the OOB messages will often authenticate
   themselves to the EAP server, e.g. by logging into a secure web page.



Aura & Sethi             Expires January 3, 2019               [Page 35]


Internet-Draft                  EAP-NOOB                       July 2018


   In this case, the server can reliably associate the peer device with
   the user account.  Applications that make use of EAP-NOOB can use
   this information for configuring the initial owner of the freshly-
   registered device.

6.2.  Identifying correct endpoints

   One remaining threat against EAP-NOOB is that the attacker first
   impersonates the peer on the in-band channel in the Initial Exchange
   and, during the OOB step, tricks the user to deliver the OOB message
   to or from the wrong peer device.  The server will now be associated
   with that wrong peer.  Similarly, the attacker can try to trick the
   user to deliver the OOB message to the wrong server, so that the peer
   device becomes associated with the wrong server.  This reliance on
   user in identifying the correct endpoints is an inherent property of
   user-assisted out-of-band authentication.

   One mechanism that can mitigate user mistakes is certification of
   peer devices.  The certificate can convey to the server authentic
   identifiers and attributes of the peer device.  If used together with
   EAP-NOOB, vendor certificates could prevent accidental association
   with a rogue peer device or registration of false PeerInfo in the
   server.  Compared to a fully certificate-based authentication,
   however, EAP-NOOB can be used without trusted third parties and does
   not require the user to know any identifier of the peer device;
   physical access to the device is sufficient.

   The user could accidentally deliver the OOB message to a wrong peer
   device in addition to the correct one.  Such accidents in EAP-NOOB
   will not enable the wrong device to compute the master key of the
   correct device or to eavesdrop the communication protected by that
   key.  This is because the wrong device would need to have performed a
   man-in-the middle attack on the in-band Initial Exchange before the
   accident occurred.  In comparison, simpler solutions where the master
   key is transferred to the device via the OOB channel are vulnerable
   to opportunistic attacks if the user mistakenly delivers the master
   key to more than one device.

6.3.  Trusted path issues

   Another remaining threat is spoofed user input or output on the peer
   device.  When the user is delivering the OOB message to or from a
   peer device, a trusted path between the user and the peer device is
   needed.  That is, the user must communicate directly with an
   authentic operating system and EAP-NOOB implementation in the peer
   device and not with a spoofed user interface.  Otherwise, a
   Registered device that is under the control of the attacker could
   emulate the behavior of an Unregistered device.  The secure path can



Aura & Sethi             Expires January 3, 2019               [Page 36]


Internet-Draft                  EAP-NOOB                       July 2018


   be implemented, for example, by indicating the peer device's status
   (Unregistered or Registered/Reconnecting) when the devices is powered
   up or by requiring the user to press a reset button to trigger the
   Initial Exchange.

6.4.  Peer identifiers and attributes

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

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

   After completion of EAP-NOOB, the server may store the PeerInfo data,
   and the user may use it to identify the peer and its properties, such
   as the make and model or serial number.  A compromised peer could lie
   in the PeerInfo that it sends to the server.  If the server stores
   any information about the peer, it is important that this information
   is approved by the user during or after the OOB Step.  Without
   verification by the user or authentication with vendor certificates
   on the application level, the PeerInfo is not authenticated
   information and should not be relied on.

   One possible use for the PeerInfo field is EAP channel binding
   ([RFC3748] Section 7.15).  That is, the PeerInfo may include data
   items that bind the EAP-NOOB association and exported keys to
   properties of the authenticator or the access link, such as the SSID
   and BSSID of the wireless network (see Appendix C).






Aura & Sethi             Expires January 3, 2019               [Page 37]


Internet-Draft                  EAP-NOOB                       July 2018


6.5.  Identify protection

   The PeerInfo field contains identifiers and other information about
   the peer device (see Appendix C), and the peer sends this information
   in plaintext to the EAP server before the server authentication in
   EAP-NOOB has been completed.  While the information refers to the
   peer device and not directly to the user, it may be better for user
   privacy to avoid sending unnecessary information.  In the Reconnect
   Exchange, the optional PeerInfo SHOULD be omitted unless some
   critical data has changed.

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

6.6.  Downgrading threats

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

   As an additional precaution, the EAP server and peer SHOULD check for
   downgrading attacks in the Reconnect Exchange.  As long as the server
   or peer saves any information about the other endpoint, it MUST also
   remember the previously negotiated cryptosuite and MUST NOT accept
   renegotiation of any cryptosuite that is known to be weaker than the
   previous one, such as a deprecated cryptosuite.

   Integrity of the direction negotiation cannot be verified in the same
   way as the integrity of the cryptosuite negotiation.  That is, if the
   OOB channel used in an application is critically insecure in one
   direction, a man-in-the-middle attacker could modify the negotiation
   messages and thereby cause that direction to be used.  Applications
   that support OOB messages in both directions SHOULD therefore ensure
   that the OOB channel has sufficiently strong security in both



Aura & Sethi             Expires January 3, 2019               [Page 38]


Internet-Draft                  EAP-NOOB                       July 2018


   directions.  While this is a theoretical vulnerability, it could
   arise in practice if EAP-NOOB is deployed in unexpected applications.
   However, most devices acting as the peer are likely to support only
   one direction of exchange, in which case interfering with the
   direction negotiation can only prevent the completion of the
   protocol.

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

6.7.  Denial-of-service threats

   To be written.

6.8.  EAP security claims

   EAP security claims are defined in section 7.2.1 of [RFC3748].  The
   security claims for EAP-NOOB are listed in Table 7.
























Aura & Sethi             Expires January 3, 2019               [Page 39]


Internet-Draft                  EAP-NOOB                       July 2018


   +----------------+--------------------------------------------------+
   | Security       | EAP-NOOB claim                                   |
   | property       |                                                  |
   +----------------+--------------------------------------------------+
   | Authentication | ECDH key exchange with out-of-band               |
   | mechanism      | authentication                                   |
   |                |                                                  |
   | Protected      | yes                                              |
   | cryptosuite    |                                                  |
   | negotiation    |                                                  |
   |                |                                                  |
   | Mutual         | yes                                              |
   | authentication |                                                  |
   |                |                                                  |
   | Integrity      | yes                                              |
   | protection     |                                                  |
   |                |                                                  |
   | Replay         | yes                                              |
   | protection     |                                                  |
   |                |                                                  |
   | Key derivation | yes                                              |
   |                |                                                  |
   | Key strength   | The specified cryptosuites provide key strength  |
   |                | of at least 128 bits.                            |
   |                |                                                  |
   | Dictionary     | yes                                              |
   | attack         |                                                  |
   | protection     |                                                  |
   |                |                                                  |
   | Fast reconnect | yes                                              |
   |                |                                                  |
   | Cryptographic  | not applicable                                   |
   | binding        |                                                  |
   |                |                                                  |
   | Session        | yes                                              |
   | independence   |                                                  |
   |                |                                                  |
   | Fragmentation  | no                                               |
   |                |                                                  |
   | Channel        | yes (The ServerInfo and PeerInfo can be used to  |
   | binding        | convey integrity-protected channel properties    |
   |                | such as network SSID or peer MAC address.)       |
   +----------------+--------------------------------------------------+

                       Table 7: EAP security claims






Aura & Sethi             Expires January 3, 2019               [Page 40]


Internet-Draft                  EAP-NOOB                       July 2018


7.  References

7.1.  Normative references

   [NIST-DH]  Barker, E., Chen, L., Roginsky, A., and M. Smid,
              "Recommendation for Pair-Wise Key Establishment Schemes
              Using Discrete Logarithm Cryptography", NIST Special
              Publication 800-56A Revision 2 , May 2013,
              <http://nvlpubs.nist.gov/nistpubs/SpecialPublications/
              NIST.SP.800-56Ar2.pdf>.

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              DOI 10.17487/RFC2104, February 1997,
              <https://www.rfc-editor.org/info/rfc2104>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, Ed., "Extensible Authentication Protocol
              (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
              <https://www.rfc-editor.org/info/rfc3748>.

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
              <https://www.rfc-editor.org/info/rfc4648>.

   [RFC5247]  Aboba, B., Simon, D., and P. Eronen, "Extensible
              Authentication Protocol (EAP) Key Management Framework",
              RFC 5247, DOI 10.17487/RFC5247, August 2008,
              <https://www.rfc-editor.org/info/rfc5247>.

   [RFC6234]  Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
              (SHA and SHA-based HMAC and HKDF)", RFC 6234,
              DOI 10.17487/RFC6234, May 2011,
              <https://www.rfc-editor.org/info/rfc6234>.

   [RFC6761]  Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
              RFC 6761, DOI 10.17487/RFC6761, February 2013,
              <https://www.rfc-editor.org/info/rfc6761>.

   [RFC7517]  Jones, M., "JSON Web Key (JWK)", RFC 7517,
              DOI 10.17487/RFC7517, May 2015,
              <https://www.rfc-editor.org/info/rfc7517>.




Aura & Sethi             Expires January 3, 2019               [Page 41]


Internet-Draft                  EAP-NOOB                       July 2018


   [RFC7518]  Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
              DOI 10.17487/RFC7518, May 2015,
              <https://www.rfc-editor.org/info/rfc7518>.

   [RFC7542]  DeKok, A., "The Network Access Identifier", RFC 7542,
              DOI 10.17487/RFC7542, May 2015,
              <https://www.rfc-editor.org/info/rfc7542>.

   [RFC7748]  Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
              for Security", RFC 7748, DOI 10.17487/RFC7748, January
              2016, <https://www.rfc-editor.org/info/rfc7748>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

   [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", STD 90, RFC 8259,
              DOI 10.17487/RFC8259, December 2017,
              <https://www.rfc-editor.org/info/rfc8259>.

7.2.  Informative references

   [BluetoothPairing]
              Bluetooth, SIG, "Simple pairing whitepaper", Technical
              report , 2007.

   [EUI-48]   Institute of Electrical and Electronics Engineers,
              "802-2014 IEEE Standard for Local and Metropolitan Area
              Networks: Overview and Architecture.", IEEE Standard
              802-2014. , June 2014.

   [IEEE-802.1X]
              Institute of Electrical and Electronics Engineers, "Local
              and Metropolitan Area Networks: Port-Based Network Access
              Control", IEEE Standard 802.1X-2004. , December 2004.

   [mcrl2]    Groote, J. and M. Mousavi, "Modeling and analysis of
              communicating systems", The MIT press , 2014,
              <https://mitpress.mit.edu/books/
              modeling-and-analysis-communicating-systems>.

   [RFC2904]  Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L.,
              Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and
              D. Spence, "AAA Authorization Framework", RFC 2904,
              DOI 10.17487/RFC2904, August 2000,
              <https://www.rfc-editor.org/info/rfc2904>.



Aura & Sethi             Expires January 3, 2019               [Page 42]


Internet-Draft                  EAP-NOOB                       July 2018


   [RFC4266]  Hoffman, P., "The gopher URI Scheme", RFC 4266,
              DOI 10.17487/RFC4266, November 2005,
              <https://www.rfc-editor.org/info/rfc4266>.

   [RFC5216]  Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
              Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216,
              March 2008, <https://www.rfc-editor.org/info/rfc5216>.

   [RFC7942]  Sheffer, Y. and A. Farrel, "Improving Awareness of Running
              Code: The Implementation Status Section", BCP 205,
              RFC 7942, DOI 10.17487/RFC7942, July 2016,
              <https://www.rfc-editor.org/info/rfc7942>.

   [Sethi14]  Sethi, M., Oat, E., Di Francesco, M., and T. Aura, "Secure
              Bootstrapping of Cloud-Managed Ubiquitous Displays",
              Proceedings of ACM International Joint Conference on
              Pervasive and Ubiquitous Computing (UbiComp 2014), pp.
              739-750, Seattle, USA , September 2014,
              <http://dx.doi.org/10.1145/2632048.2632049>.
































Aura & Sethi             Expires January 3, 2019               [Page 43]


Internet-Draft                  EAP-NOOB                       July 2018


Appendix A.  Exchanges and events per state

   Figure 10 shows how the EAP server chooses the exchange type
   depending on the server and peer states.  In the state combinations
   marked with hyphen "-", there is no possible exchange and user action
   is required to make progress.  Note that peer state 4 is omitted from
   the table because the peer never connects to the server when the peer
   is in that state.  The table also indicates the handling of errors in
   each exchange.  A notable detail is that the recipient of error code
   1006 moves to state 1.


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


              Figure 10: How server chooses the exchange type

   Figure 11 lists the local events that can take place in the server or
   peer.  Both the server and peer output and accept OOB messages in



Aura & Sethi             Expires January 3, 2019               [Page 44]


Internet-Draft                  EAP-NOOB                       July 2018


   association state 1, leading the receiver to state 2.  Communication
   errors and timeouts in states 0..2 lead back to state 0, while
   similar errors in states 3..4 lead to state 3.  Application request
   for rekeying (e.g. to refresh session keys or to upgrade algorithms)
   also takes the association from state 3..4 to state 3.  User can
   always reset the association state to 0.  Recovering association
   data, e.g. from a backup, leads to state 3.


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


                Figure 11: Local events on server and peer

Appendix B.  Application-specific parameters

   Table 8 lists OOB channel parameters that need to be specified in
   each application that makes use of EAP-NOOB.  The list is not
   exhaustive and is included for the convenience of implementors only.




















Aura & Sethi             Expires January 3, 2019               [Page 45]


Internet-Draft                  EAP-NOOB                       July 2018


   +--------------------+----------------------------------------------+
   | Parameter          | Description                                  |
   +--------------------+----------------------------------------------+
   | OobDirs            | Allowed directions of the OOB channel        |
   |                    |                                              |
   | OobMessageEncoding | How the OOB message data fields are encoded  |
   |                    | for the OOB channel                          |
   |                    |                                              |
   | SleepTimeDefault   | Default minimum time in seconds that the     |
   |                    | peer should sleep before the next Waiting    |
   |                    | Exchange                                     |
   |                    |                                              |
   | OobRetries         | Number of received OOB messages with invalid |
   |                    | Hoob after which the receiver moves to       |
   |                    | Unregistered (0) state                       |
   |                    |                                              |
   | NoobTimeout        | How many seconds the sender of the OOB       |
   |                    | message remembers the sent Noob value. The   |
   |                    | RECOMMENDED value is 3600 seconds.           |
   |                    |                                              |
   | ServerInfoMembers  | Required members in ServerInfo               |
   |                    |                                              |
   | PeerInfoMembers    | Required members in PeerInfo                 |
   +--------------------+----------------------------------------------+

                   Table 8: OOB channel characteristics

Appendix C.  ServerInfo and PeerInfo contents

   The ServerInfo and PeerInfo fields in the Initial Exchange and
   Reconnect Exchange enable the server and peer, respectively, send
   information about themselves to the other endpoint.  They contain
   JSON objects whose structure may be specified separately for each
   application and each type of OOB channel.  ServerInfo and PeerInfo
   MAY contain auxiliary data needed for the OOB channel messaging and
   for EAP channel binding.  Table 9 lists some suggested data fields
   for ServerInfo.














Aura & Sethi             Expires January 3, 2019               [Page 46]


Internet-Draft                  EAP-NOOB                       July 2018


   +----------------+--------------------------------------------------+
   | Data field     | Description                                      |
   +----------------+--------------------------------------------------+
   | ServerName     | String that may be used to aid human             |
   |                | identification of the server.                    |
   |                |                                                  |
   | ServerURL      | Prefix string when the OOB message is formatted  |
   |                | as URL, as suggested in Appendix E.              |
   |                |                                                  |
   | SSIDList       | List of wireless network identifier (SSID)       |
   |                | strings used for roaming support, as suggested   |
   |                | in Appendix D. The SSIDs are UTF-8 encoded.      |
   |                |                                                  |
   | Base64SSIDList | List of wireless network identifier (SSID)       |
   |                | strings used for roaming support, as suggested   |
   |                | in Appendix D. The SSIDs are base64url encoded.  |
   |                | Peer SHOULD send at most one of the fields       |
   |                | SSIDList and Base64SSIDList in PeerInfo, and the |
   |                | server SHOULD ignore SSIDList if Base64SSIDList  |
   |                | is included.                                     |
   +----------------+--------------------------------------------------+

                 Table 9: Suggested ServerInfo data fields

   PeerInfo typically contains auxiliary information for identifying and
   managing peers on the application level at the server end.  Table 10
   lists some suggested data fields for PeerInfo.
























Aura & Sethi             Expires January 3, 2019               [Page 47]


Internet-Draft                  EAP-NOOB                       July 2018


   +--------------+----------------------------------------------------+
   | Data field   | Description                                        |
   +--------------+----------------------------------------------------+
   | PeerName     | String that may be used to aid human               |
   |              | identification of the peer.                        |
   |              |                                                    |
   | Manufacturer | Manufacturer or brand string.                      |
   |              |                                                    |
   | Model        | Manufacturer-specified model string.               |
   |              |                                                    |
   | SerialNumber | Manufacturer-assigned serial number.               |
   |              |                                                    |
   | MACAddress   | Peer link-layer identifier (EUI-48) in the         |
   |              | 12-digit base-16 form [EUI-48]. The string MAY     |
   |              | include additional colon ':' or dash '-'           |
   |              | characters that MUST be ignored by the server.     |
   |              |                                                    |
   | SSID         | Wireless network SSID for channel binding. The     |
   |              | SSID is a UTF-8 string.                            |
   |              |                                                    |
   | Base64SSID   | Wireless network SSID for channel binding. The     |
   |              | SSID is base64url encoded. Peer SHOULD send at     |
   |              | most one of the fields SSID and Base64SSID in      |
   |              | PeerInfo, and the server SHOULD ignore SSID if     |
   |              | Base64SSID is included.                            |
   |              |                                                    |
   | BSSID        | Wireless network BSSID (EUI-48) in the 12-digit    |
   |              | base-16 form [EUI-48]. The string MAY include      |
   |              | additional colon ':' or dash '-' characters that   |
   |              | MUST be ignored by the server.                     |
   |              |                                                    |
   +--------------+----------------------------------------------------+

                 Table 10: Suggested PeerInfo data fields

Appendix D.  EAP-NOOB roaming

   AAA architectures [RFC2904] allow for roaming of network-connected
   appliances that are authenticated over EAP.  While the peer is
   roaming in a visited network, authentication still takes place
   between the peer and an authentication server at its home network.
   EAP-NOOB supports such roaming by assigning a Realm to the peer.
   After the Realm has been assigned, the peer's NAI enables the visited
   network to route the EAP session to the peer's home AAA server.

   A peer device that is new or has gone through a hard reset should be
   connected first to the home network and establish an EAP-NOOB
   association with its home AAA server before it is able to roam.



Aura & Sethi             Expires January 3, 2019               [Page 48]


Internet-Draft                  EAP-NOOB                       July 2018


   After that, it can perform the Reconnect Exchange from the visited
   network.

   Alternatively, the device may provide some method for the user to
   configure the Realm of the home network.  In that case, the EAP-NOOB
   association can be created while roaming.  The device will use the
   user-assigned Realm in the Initial Exchange, which enables the EAP
   messages to be routed correctly to the home AAA server.

   While roaming, the device needs to identify the networks where the
   EAP-NOOB association can be used to gain network access.  For 802.11
   access networks, the server MAY send a list of SSIDs in the
   ServerInfo JSON object in a member called SSIDList or Base64SSIDList.
   This member contains a JSON array where each element is an SSID that
   is base64url encoded without padding.  If present, the peer MAY use
   this list as a hint to determine the networks where the EAP-NOOB
   association can be used for access authorization, in addition to the
   access network where the Initial Exchange took place.

Appendix E.  OOB message as URL

   While EAP-NOOB does not mandate any particular OOB communication
   channel, typical OOB channels include graphical displays and emulated
   NFC tags.  In the peer-to-server direction, it may be convenient to
   encode the OOB message as a URL, which is then encoded as a QR code
   for displays and printers or as an NDEF record for NFC tags.  A user
   can then simply scan the QR code or NFC tag and open the URL, which
   causes the OOB message to be delivered to the authentication server.
   The URL MUST specify the https protocol i.e. secure connection to the
   server, so that the man-in-the-middle attacker cannot read or modify
   the OOB message.

   The ServerInfo in this case includes a JSON member called ServerUrl
   of the following format with maximum length of 60 characters:

   https://<host>[:<port>]/[<path>]

   To this, the peer appends the OOB message fields (PeerId, Noob, Hoob)
   as a query string.  PeerId is provided to the peer by the server and
   might be a 22-character string.  The peer base64url encodes, without
   padding, the 16-byte values Noob and Hoob into 22-character strings.
   The query parameters MAY be in any order.  The resulting URL is of
   the following format:

   https://<host>[:<port>]/[<path>]?P=<PeerId>&N=<Noob>&H=<Hoob>

   The following is an example of a well-formed URL encoding the OOB
   message (without line breaks):



Aura & Sethi             Expires January 3, 2019               [Page 49]


Internet-Draft                  EAP-NOOB                       July 2018


   https://example.com/Noob?P=ZrD7qkczNoHGbGcN2bN0&N=rMinS0-F4EfCU8D9ljx
   X_A&H=QvnMp4UGxuQVFaXPW_14UW

Appendix F.  Example messages

   The message examples in this section are generated with Curve25519
   ECDH test vectors specified in section 6.1 of [RFC7748]
   (server=Alice, peer=Bob).  The direction of the OOB channel
   negotiated is 1 (peer-to-server).  The JSON messages are as follows
   (line breaks are for readability only).

   ====== Initial Exchange ======

   Identity response:
      noob@eap-noob.net

   EAP request (type 1):
      {"Type":1,"Vers":[1],"PeerId":"07KRU6OgqX0HIeRFldnbSW","Realm":"no
      ob.example.com","Cryptosuites":[1],"Dirs":3,"ServerInfo":{"Name":"
      Example","Url":"https://noob.example.com/sendOOB"}}

   EAP response (type 1):
      {"Type":1,"Verp":1,"PeerId":"07KRU6OgqX0HIeRFldnbSW","Cryptosuitep
      ":1,"Dirp":1,"PeerInfo":{"Make":"Acme","Type":"None","Serial":"DU-
      9999","SSID":"Noob1","BSSID":"6c:19:8f:83:c2:80"}}

   EAP request (type 2):
      {"Type":2,"PeerId":"07KRU6OgqX0HIeRFldnbSW","PKs":{"kty":"EC","crv
      ":"Curve25519","x":"hSDwCYkwp1R0i33ctD73Wg2_Og0mOBr066SpjqqbTmo"},
      "Ns":"PYO7NVd9Af3BxEri1MI6hL8Ck49YxwCjSRPqlC1SPbw","SleepTime":60}

   EAP response (type 2):
      {"Type":2,"PeerId":"07KRU6OgqX0HIeRFldnbSW","PKp":{"kty":"EC","crv
      ":"Curve25519","x":"3p7bfXt9wbTTW2HC7OQ1Nz-DQ8hbeGdNrfx-FG-
      IK08"},"Np":"HIvB6g0n2btpxEcU7YXnWB-451ED6L6veQQd6ugiPFU"}

   ====== Waiting Exchange ======

   Identity response:
      07KRU6OgqX0HIeRFldnbSW+s1@noob.example.com

   EAP request (type 3):
      {"Type":3,"PeerId":"07KRU6OgqX0HIeRFldnbSW","SleepTime":60}

   EAP response (type 3):
      {"Type":3,"PeerId":"07KRU6OgqX0HIeRFldnbSW"}

   ====== OOB Step ======



Aura & Sethi             Expires January 3, 2019               [Page 50]


Internet-Draft                  EAP-NOOB                       July 2018


   Identity response:
      P=07KRU6OgqX0HIeRFldnbSW&N=x3JlolaPciK4Wa6XlMJxtQ&H=faqWz68trUrBTK
      AnioZMQA

   ====== Completion Exchange ======

   Identity response:
      07KRU6OgqX0HIeRFldnbSW+s2@noob.example.com

   EAP request (type 8):
      {"Type":8,"PeerId":"07KRU6OgqX0HIeRFldnbSW"}

   EAP response (type 8):
      {"Type":8,"PeerId":"07KRU6OgqX0HIeRFldnbSW","NoobId":"U0OHwYGCS4nE
      kzk2TPIE6g"}

   EAP request (type 4):
      {"Type":4,"PeerId":"07KRU6OgqX0HIeRFldnbSW","NoobId":"U0OHwYGCS4nE
      kzk2TPIE6g","MACs":"Y5NfKQkZTbRW3sEFhWy0Bv0ic2wsMnaA6xGqtUmQqmc"}

   EAP response (type 4):
      {"Type":4,"PeerId":"07KRU6OgqX0HIeRFldnbSW","MACp":"ddY225rN3lYzo7
      qZNPStbVO1HRdNnTx0Rit6_8xEh7A"}

   ====== Reconnect Exchange ======

   Identity response:
      07KRU6OgqX0HIeRFldnbSW+s3@noob.example.com

   EAP request (type 5):
      {"Type":5,"Vers":[1],"PeerId":"07KRU6OgqX0HIeRFldnbSW","Cryptosuit
      es":[1],"Realm":"noob.example.com","ServerInfo":{"Name":"Example",
      "Url":"https://noob.example.com/sendOOB"}}

   EAP response (type 5):
      {"Type":5,"Verp":1,"PeerId":"07KRU6OgqX0HIeRFldnbSW","Cryptosuitep
      ":1,"PeerInfo":{"Make":"Acme","Type":"None","Serial":"DU-
      9999","SSID":"Noob1","BSSID":"6c:19:8f:83:c2:80"}}

   EAP request (type 6):
      {"Type":6,"PeerId":"07KRU6OgqX0HIeRFldnbSW","PKs2":{"kty":"EC","cr
      v":"Curve25519","x":"hSDwCYkwp1R0i33ctD73Wg2_Og0mOBr066SpjqqbTmo"}
      ,"Ns2":"RDLahHBlIgnmL_F_xcynrHurLPkCsrp3G3B_S82WUF4"}

   EAP response (type 6):
      {"Type":6,"PeerId":"07KRU6OgqX0HIeRFldnbSW","PKp2":{"kty":"EC","cr
      v":"Curve25519","x":"3p7bfXt9wbTTW2HC7OQ1Nz-DQ8hbeGdNrfx-FG-
      IK08"},"Np2":"jN0_V4P0JoTqwI9VHHQKd9ozUh7tQdc9ABd-j6oTy_4"}



Aura & Sethi             Expires January 3, 2019               [Page 51]


Internet-Draft                  EAP-NOOB                       July 2018


   EAP request (type 7):
      {"Type":7,"PeerId":"07KRU6OgqX0HIeRFldnbSW","MACs2":"_pXDF4-
      7uBKXKqVKKB6U-GP9EDnGCNOMdkyfEQp_iwA"}

   EAP response (type 7):
      {"Type":7,"PeerId":"07KRU6OgqX0HIeRFldnbSW","MACp2":"qSUH4zA0VzMqU
      2O1U-JJTqwGRXGB8i3bggasYL6o1uU"}

Appendix G.  TODO list

   o  Write security considerations on persistent denial-of-service
      conditions and avoiding them.

   o  If last message that commits algorithm upgrade is lost, user reset
      is needed to recover.  Consider ways of mitigating this potential
      DoS issue.

   o  NoobId is currently a hash of the nonce Noob.  The fingerprint
      Hoob indirectly binds the Noob and thus also NoobId to all the
      other significant protocol parameters.  A more direct binding
      could make it easier to model and verify the security properties
      of the cryptographic protocol.  Consider the advantages and
      disadvantages of computing NoobId as a hash of Hoob, instead of
      Noob.

Appendix H.  Version history

   o  Version 01:

      *  Fixed Reconnection Exchange.

      *  URL examples.

      *  Message examples.

      *  Improved state transition (event) tables.

   o  Version 02:

      *  Reworked the rekeying and key derivation.

      *  Increased internal key lengths and in-band nonce and MAC
         lengths to 32 bytes.

      *  Less data in the persistent EAP-NOOB association.

      *  Updated reference [NIST-DH] to Revision 2 (2013).




Aura & Sethi             Expires January 3, 2019               [Page 52]


Internet-Draft                  EAP-NOOB                       July 2018


      *  Shorter suggested PeerId format.

      *  Optimized the example of encoding OOB message as URL.

      *  NoobId in Completion Exchange to differentiate between multiple
         valid Noob values.

      *  List of application-specific parameters in appendix.

      *  Clarified the equivalence of Unregistered state and no state.

      *  Peer SHOULD probe the server regardless of the OOB channel
         direction.

      *  Added new error messages.

      *  Realm is part of the persistent association and can be updated.

      *  Clarified error handling.

      *  Updated message examples.

      *  Explained roaming in appendix.

      *  More accurate definition of timeout for the Noob nonce.

      *  Additions to security considerations.

   o  Version 03:

      *  Clarified reasons for going to Reconnecting state.

      *  Included Verp in persistent state.

      *  Added appendix on suggested ServerInfo and PeerInfo fields.

      *  Exporting PeerId and SessionId.

      *  Explicitly specified next state after OOB Step.

      *  Clarified the processing of an expired OOB message and
         unrecognized NoobId.

      *  Enabled protocol version upgrade in Reconnect Exchange.

      *  Explained handling of redundant received OOB messages.

      *  Clarified where raw and base64url encoded values are used.



Aura & Sethi             Expires January 3, 2019               [Page 53]


Internet-Draft                  EAP-NOOB                       July 2018


      *  Cryptosuite must specify the detailed format of the JWK object.

      *  Base64url encoding in JSON strings is done without padding.

      *  Simplified explanation of PeerId, Realm and NAI.

      *  Added error codes for private and experimental use.

      *  Updated the security considerations.

Appendix I.  Acknowledgments

   Aleksi Peltonen modeled the protocol specification with the mCRL2
   formal specification language.  Shiva Prasad TP and Raghavendra MS
   implemented parts of the protocol with wpa_supplicant and hostapd.
   Their inputs helped us in improving the specification.

   The authors would also like to thank Rhys Smith and Josh Howlett for
   providing valuable feedback as well as new use cases and requirements
   for the protocol.  Thanks to Darshak Thakore, Stefan Winter and
   Hannes Tschofenig for interesting discussions and arguments in this
   problem space.

Authors' Addresses

   Tuomas Aura
   Aalto University
   Aalto  00076
   Finland

   EMail: tuomas.aura@aalto.fi


   Mohit Sethi
   Ericsson
   Jorvas  02420
   Finland

   EMail: mohit@piuha.net












Aura & Sethi             Expires January 3, 2019               [Page 54]


Html markup produced by rfcmarkup 1.128, available from https://tools.ietf.org/tools/rfcmarkup/