Nimble Out-of-Band Authentication for EAP (EAP-NOOB)
draft-ietf-emu-eap-noob-06

[Ballot comment]
Thanks for the many updates to address my Discuss and Comment points.

Just a few final thoughts from reading the diff from -04 to -05:

Section 5.6

It's interesting to see the eap-noob.arpa registration lose discussion about
who should care and why (i.e., the list from RFC 6761).  I guess I see how
it's not specifically required by 6761 itself, but it seemed useful to think
about.

Section 7.2

The first and second paragraphs both start with the same sentence, which makes
me suspect that there are some editing remnants left.

Section 7.7

Many thanks for adding this treatment of channel binding.  The actual
properties provided are weaker than I'd like, but attempting to diverge from
RFC 6677 in this document seems unlikely to actually be useful, so I'll have
to accept what is possible.

[Ballot comment]
Thank you for the work on this document, and for addressing my DISCUSS and COMMENTs. I leave the leftover comment for the record.

Francesca


>> 7. -----
>>
>>    and truncated to the 16 leftmost bytes of the output.  The message
>>
>> FP: please mention that network byte order is used (either here or in the
>> terminology).

>The byte order is relevant when encoding/decoding things like integers
>etc. While cryptographic hash functions may use integers or 32- or
>64-bit words internally, their output is a byte string, and the order of
>the bytes in that output is defined by each individual hash function
>specification (e.g. RFC 6234). We don’t think we should say anything
>that could lead to a programmer mistakenly reordering the bytes in the
>hash output.

FP: But the fact that you talk about "leftmost" bytes means that you are already implying ordering. Talking about leftmost without talking about ordering seems imprecise. Maybe you want to talk about the 16 most significant bytes instead.

[Ballot comment]
All comments below are about potential very minor issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools, so there will likely be some false positives. There is no need
to let me know what you did with these suggestions.

Section 8.2, paragraph 2, nit:
>    [BluetoothPairing]
>              Bluetooth, SIG, "Simple pairing whitepaper", Technical
>              report , 2007.

Add URL?

Section 1, paragraph 6, nit:
-    Many proprietary OOB configuration methods exist for specific IoT
+    Many proprietary out-of-band (OOB) configuration methods exist for specific IoT
+                    +++++++++++++  +

Section 1, paragraph 6, nit:
-    use of a user-assisted out-of-band (OOB) channel.  The device
-                          -------------  -
+    use of a user-assisted OOB channel.  The device

Section 3.1, paragraph 10, nit:
-    Success.  The reason is that, while EAP allows delays between the
-                                -
+    Success.  The reason is that while EAP allows delays between the

Section 6.4, paragraph 2, nit:
-    process.  For example, we verified the correctness of the tiebreaking
+    process.  For example, we verified the correctness of the tie-breaking
+                                                                +

Section 3.3.2, paragraph 3, nit:
> ication | | | channel but it is included in the computation |
>              ^^^^^^^^^^^
Use a comma before 'but' if it connects two independent clauses (unless they
are closely connected and short).

Section 3.3.2, paragraph 3, nit:
>  to the OOB | | | channel and it is encoded as a JSON object of |
>                  ^^^^^^^^^^^
Use a comma before 'and' if it connects two independent clauses (unless they
are closely connected and short).

Section 3.3.2, paragraph 3, nit:
> r | | | to the OOB channel and it is encoded as a JSON | |
>                    ^^^^^^^^^^^
Use a comma before 'and' if it connects two independent clauses (unless they
are closely connected and short).

Section 3.4.2, paragraph 11, nit:
> ause the server does not store previous keys and it never rolls back a cryptosuite up
>                                        ^^^^^^^^
Use a comma before 'and' if it connects two independent clauses (unless they
are closely connected and short).

Section 3.5, paragraph 2, nit:
> on. The auxiliary function H is a hash function and it is taken from the negotiated cryp
>                                        ^^^^^^^^^^^^
Use a comma before 'and' if it connects two independent clauses (unless they
are closely connected and short).

Section 3.5, paragraph 8, nit:
>  keys are exchanged. Input Z is the fresh shared secret from the ECDHE exchange with
>                                    ^^^^^^^^^^^^
Make sure that the adjective 'fresh' is correct. Possibly, it should be an
adverb (typically ~ly) that modifies 'shared'. Possibly, it should be the first
word in a compound adjective (hyphenated adjective). Possibly, it is correct.

Section 3.5, paragraph 11, nit:
> ed for application- layer security. Further output bytes are used internally by EAP
>                                    ^^^^^^^
Did you forget a comma after a conjunctive/linking adverb?

Section 3.6.5, paragraph 3, nit:
>  device may not have the capability for many different error indications to the user and it MA
>                                        ^^^^^^^^^^^^^^^^^
Consider using "many".

Section 3.6.5, paragraph 3, nit:
> y different error indications to the user and it MAY use the same indication as in
>                                      ^^^^^^^^
Use a comma before 'and' if it connects two independent clauses (unless they
are closely connected and short).

Section 4, paragraph 4, nit:
> ing. The | | | SSID is a ASCII string.
>                        ^
Use "an" instead of 'a' if the following word starts with a vowel sound, e.g.
'an article', 'an hour'.

Section 5.3, paragraph 5, nit:
> tion Required" as defined in [RFC8126], with the exception of the range 6001-6999. This range is res
>                                        ^^^^^^^^^^^^^^^^^^^^^^^^
Consider using "except" or "except for"

Section 6.1, paragraph 3, nit:
>  Coverage: This implementation includes all of the features described in the current
>                                        ^^^^^^^^^^
Consider using "all the".

Section 6.1, paragraph 4, nit:
> ion. The implementation supports two dimensional QR codes and NFC as example out-of-band
>                                  ^^^^^^^^^^^^^^^
This word is normally spelled with a hyphen.

Section 6.2, paragraph 3, nit:
>  Coverage: This implementation includes all of the features described in the current
>                                        ^^^^^^^^^^
Consider using "all the".

Section 7.2, paragraph 4, nit:
> ber, of the peer device. Compared to a fully certificate- based authentication, however, EAP-
>                                        ^^^^^^^^^^^^^^^^^
You used an adverb ('fully') instead of an adjective, or a noun ('certificate')
instead of another adjective.

Section 7.5, paragraph 2, nit:
> e omitted unless some critical data has changed and it cannot be updated on the applicat
>                                        ^^^^^^^^^^^
Use a comma before 'and' if it connects two independent clauses (unless they
are closely connected and short).

"Appendix D.", paragraph 3, nit:
>  RECOMMENDED length of 60 characters or less: https://[:]/[]
>                                        ^^^^
Did you mean "fewer"? The noun characters is countable.

"Appendix F.", paragraph 9, nit:
>  lengths to 32 bytes. * Less data in the persistent EAP-NOOB associa
>                        ^^^^
Did you mean "fewer"? The noun data is countable.

These reference issues exist in the document:
* No reference entries found for:
    [PeerId], [NewNAI], [SleepTime], [ErrorInfo],
    [PKp2], [PKs2], [PeerInfo], [1], [ServerInfo]

These URLs in the document did not return content:
* https://[:]/[<path
* https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pdf

[Ballot comment]
Thanks for the effort on this.

Due to lack of time I had to do a quick review and I didn't find any transport related issues.

However, I do think more guidance need to be added for creating IANA registries and only referring to RFC8126 is not enough.

[Ballot discuss]
The example JWK for cryptosuite 1 in §5.1 is not well-formed.  RFC 8037
key-exchange uses a crv of "X25519" and a kty of "OKP".
(See COMMENT for more quibbles with §5.1.)
I think Appendix E is also using the wrong "kty" for X25519 (but is
properly using "X25519" as the "crv").

I'd also like to discuss our treatment of channel binding, as the
current mention seems dangerously incomplete.  I don't remember if there
is generic discussion of channel binding in the core EAP RFCs (if so, a
specific reference would help), but otherwise if we're going to mention
that protocol elements can be used for channel binding we should give
some indication of how to actually do so in a secure manner (e.g., what
protocol element needs to be verified against external channel
information and what to do if they don't match).

[Ballot comment]
Thanks for putting together this pretty comprehensive treatment of a
topic that is simple to understand but has a lot of important details.
(I do have some comments about a few of those details, just to check
that we do have them right.)  I especially appreciate the strong feature
set that's been assembled.

In Section 3.5 we discuss a key derivation scheme and say to use the
one-step KDF from NIST SP 800-56Ar3 §5.8.2.1.  In particular, this is
not the two-step (extract-then-expand) KDF of the following section
(§5.8.2.2).  Since the (EC)DH shared secret Z is not uniformly random,
my understanding was that generally the two-step KDF was needed, since
the one-step KDF assumes that the input key is uniformly selected.  I am
not balloting Discuss for this point because I assume it was considered
in the formal verification, but I would very much appreciate some
additional insight into this selection.

Section 3.1

  The overall protocol starts with the Initial Exchange, which
  comprises four EAP request-response pairs.  In the Initial Exchange,
  the server allocates an identifier to the peer, and the server and

Is this a DoS risk for state exhaustion on the server?

  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 the
  ephemeral states 0..2 without explicit user approval.  [...]

This also looks like a DoS risk, if a malicious device/user completes
the OOB step then only deletes the association on the device (without
telling the server), then re-registers, deletes again, etc.  The server
is required to maintain state without bound.

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

No way other than the registered cryptographic key that's used to
authenticate the Reconnect Exchange, that is?

  A special feature of the EAP-NOOB method is that the server is not
  assumed to have any a-priori knowledge of the peer.  Therefore, the
  peer initially uses the generic identity string "noob@eap-noob.arpa"
  as its network access identifier (NAI).  [...]

This looks like codepoint squatting, since we haven't received an early
allocation of this entry in .arpa.

section 3.2.1

  After receiving the EAP-Response/Identity message, the server sends
  the first EAP-NOOB request (Type=1) to the peer, which responds with
  the peer identifier (PeerId) and state (PeerState) in the range 0..3.
  However, the peer SHOULD omit the PeerId from the response (Type=1)
  when PeerState=0.  [...]

Why only SHOULD and not MUST?

Section 3.2.3

Can we give any guidance for how to set OobRetries?

Section 3.2.4

                          In the request, the server sends the NoobId
  value, which the peer uses to identify the exact OOB message received
  by the server.  [...]

This is the first time we mention the NoobId value, so some more
explanation or forward-reference seems in order.

  value.  The recipient of an unrecognized NoobId indicates this with
  an error message (error code 2003, see Section 3.6.1), and the
  Completion Exchange ends in EAP-Failure.  [...]

I assume that the formal modeling has considered whether the specific
"bad NoobId" error code leads to an attack.

Section 3.2.5

SleepTime is sent in an unauthenticated EAP message, thus presents a DoS
vector due to forged very large values.  In Section 3.3.2 we seem to
place an upper limit of 3600 seconds, which could mitigate this DoS
risk.  I suggest mentioning the upper limit here.

Section 3.3.1

                                The peer sets the PeerId value in
  response type 1 as follows.  When the peer is in the Unregistered (0)
  state, it SHOULD omit the PeerId from response type 1.  [...]

[if we change this SHOULD above, we have to change it here as well.  And
arguably only put the normative requirement in one location.]

Section 3.3.2

Can we list the message Type in the table or otherwise indicate that the
message type is passed as a regular member of the JSON object that is
the message payload?  I had to consult the examples to figure this out
otherwise...

  | Dirs, Dirp      | The OOB channel directions supported by the    |
  |                  | server and the directions selected by the      |
  |                  | peer. The possible values are 1=peer-to-      |
  |                  | server, 2=server-to-peer, 3=both directions.  |

If a server supports both directions does it have to advertise [1,2,3]
(the examples suggest "no")?
What happens if it only advertises [3]?

  | Ns, Np          | 32-byte nonces for the Initial Exchange.      |
  [...]
  | Ns2, Np2        | 32-byte Nonces for the Reconnect Exchange.    |

I see there is a note later about the nonce formatting, but I think it
would be helpful to mention the base64url encoding and JSON string
representation for transport.

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

It seems like there are some potential privacy considerations to sending
this information to an unauthenticated server.  Section 7.5 covers some
of this, but we might benefit from specifically using the phrase
"privacy considerations" and perhaps expounding slightly more.

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

Did the formal verification include modeling of scenarios where the
initial NAI varied and NewNAI was not sent?

Also, was consideration given to using a "raw" transcript hash that
takes the literal messages exchanged, as opposed to subsetting certain
fields?  This version seems to leave, e.g., SleepTime unprotected even
by post-facto authentication.

  The nonces (Ns, Np, Ns2, Np2, Noob) and the hash value (NoobId) MUST
  be base64url encoded [RFC4648] when they are used as input to the
  cryptographic functions H or HMAC.  [...]

This part is somewhat surprising to me; I would have only expected the
base64url encoding to be used for in-band messages and not for
cryptographic inputs, espcially if we are mixing use of en- and de-coded
forms (the raw binary is used for the KDF procedure).

Section 3.4.2

  1.  The peer first compares the received MACs2 value with one it
      computed using the Kz stored in the persistent EAP-NOOB

I briefly attempted to think through some scenarios where a Kz is
compromised (either from the peer or the server), as always checking the
persistent Kz makes it easy for an attacker that knows Kz and has some
on-path presence to get an exchange accepted when the peer recommences
EAP.  But it seems that an attacker in that position would generally be
able to impersonate the server regardless of what procedure we specify,
since Kz is the main thing that authenticates the reconnect exchange
anyway.  So I don't think that we need to consider (e.g.) attempting to
confirm a new key prior to Kz, if one is present.

  Exchange ends in EAP-Success.  When KeyingMode is 3, the server also
  updates Cryptosuitep and Kz in the persistent EAP-NOOB association.
  On the other hand, if the server finds that the values do not match,
  it sends an error message (error code 4001), and the Reconnect
  Exchange ends in EAP-Failure.

It's surprising to me that Kz is only updated for keying mode 3 -- I
would have expected it to always update.  IIUC doing so would provide a
weak form of forward secrecy even for the non-ECDHE case, and my
intuition is that it would extend the safe usable lifetime for the key
material.

Section 3.4.3

  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

If we're going to mention the possibility of storing the server's
persistent session state on backup storage we need to talk about the
security considerations for protecting that backup storage.

Section 3.6.5

  of peer connections with SleepTime after the above error.  Also,
  there SHOULD be a way for the user to reset the peer to the
  Unregistered state (0), so that the OOB Step can be repeated as the
  last resort.

Why is this only a SHOULD?

Section 4

  for EAP channel binding.  This section describes the initial data
  fields for ServerInfo and PeerInfo registered by this specification.
  Further specifications may request new application-specific
  ServerInfo and PeerInfo data fields from IANA (see Section 5.4 and
  Section 5.5).

I might say something about how all of these are optional to use.

  | Type          | Type-tag string that can be used by the peer as  |
  |                | a hint for how to interpret the ServerInfo      |
  |                | contents.                                        |
  [...]
  | Type        | Type-tag string that can be used by the server as  |
  |              | a hint for how to interpret the PeerInfo contents. |

A little unfortunate to have "Type" as a JSON object member in both
these and the toplevel message payloads but with different semantics,
but I guess it is understandable.

Section 4

  | MACAddress  | Peer link-layer identifier (EUI-48) in the        |
  |              | 12-digit base-16 form [EUI-48]. The string MAY be  |
  |              | in upper or lower case and MAY include additional  |
  |              | colon ':' or dash '-' characters that MUST be      |
  |              | ignored by the server.                            |

We traditionally include privacy considerations when we convey MAC
address information in protocol fields.

Section 5.1

  | 1          | ECDHE curve Curve25519 [RFC7748], public-key format |
  |            | [RFC7517], hash function SHA-256 [RFC6234]          |
  | 2          | ECDHE curve NIST P-256 [FIPS186-4], public-key      |
  |            | format [RFC7517], hash function SHA-256 [RFC6234]  |

I think we might need to give a slightly more detailed
explanataion/reference for the public-key formats here.

In particular, RFC 7517 is not really a good reference for Curve25519 in
JWK; RFC 8037 is what defines X25519 for JOSE.  (Curve25519 itself is
not yet registered, though there is some work underway in or adjacent to
draft-ietf-lwig-curve-representations to define ECSDA and NIST cofactor
ECDH on Curve25519.)

Section 6.3

  o  Coverage: This implementation is the most up-to-date.  The
      [...]
  o  Version compatibility: Version 02 of the working group adopted
      draft is implemented

It's hard to square "most up-to-date" with only implementing version 02
(the other implementations claim 08 and 06)...though since this is
getting removed anyway it's rather moot.

Section 7.1

  or API.  In this case, the server can reliably associate the peer
  device with the user account.  Applications that make use of EAP-NOOB

I'd suggest dropping "reliably" here; there are some attack scenarios
that can arise when a registration is deliberately (or perhaps even as a
confused deputy?) made under the "wrong" account.

Section 7.2

  It is, however, not possible to exploit accidental delivery of the
  OOB message to the wrong device when the user makes an unexpected
  mistake.  This is because the wrong peer device would not have
  prepared for the attack by performing the Initial Exchange with the
  server.  [...]

I'm not entirely sure that I understand what's being said here.  IIUC an
attacker could well try to perform an initial exchange in parallel with
the legitimate device, keyed on by perhaps some environmental factors,
observing the user at another device, etc.  But the attack would only
succeed if it was actively claiming the PeerId of the legitimate device,
and the legitimate device would have some failed exchange(s) that might
be able to detect the attack.  Just saying "would not have prepared"
doesn't really help me understand how much (or how little) risk there
is.

  After the device registration, an attacker could clone the device
  identity by copying the keys from the persistent EAP-NOOB association
  into another device.  The attacker can be an outsider who gains
  access to the keys or the device owner who wants to have two devices
  matching the same registration.  The cloning threats can be mitigated
  by creating the cryptographic keys and storing the persistent EAP-
  NOOB association on the peer device in a secure hardware component
  such as a trusted execution environment (TEE).  Furthermore, remote
  attestation on the application level could provide assurance to the
  server that the device has not been cloned.

Please mention that doing a KeyingMode-3 reconnect would drop any cloned
devices from being able to associate as that identity.

Section 7.4

  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.

Should we say anything to prevent the server from re-using a PeerId
(which would be a natural thing to do if this SHOULD NOT is ignored)?

Section 7.6

  As an additional precaution, the EAP server and peer MUST check for
  downgrading attacks in the Reconnect Exchange as follows.  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.  Determining
  the relative strength of the cryptosuites is out of scope and may be
  managed by implementations or by local policies at the peer and
  server.

There is no fundamental guarantee that the peer and server will use the
same ordering for relative strength of ciphersuites.  This could in
theory lead to a situation where any attempt to change ciphersuite is
rejected by the other party, and the participants are stuck on a single
ciphersuite.  However, it's not really clear that there would be
significant practical consequences if that actually happened.

Section 7.9

Looking through the security claims, it seems pretty clear that the
mutual nonces give replay protection for the Initial and Reconnect
exchanges, but I didn't immediately see what provided replay protection
for the Completion exchange.  I suspect it's just the local state on
both parties that would not produce a state transition on the basis of a
replayed exchange, but please confirm.  (It might be worth a brief
discussion in the document about how replay protection is attained,
though I could pretty easily be convinced that it's not worth it.)

Section 8.2

Since we use it to specify by reference the content of a protocol field,
[EUI-48] may well be classified as normative.

I also don't think that RFC 4266 is the right reference for URLs in
general.

Appendix A

What do the asterisks in the middle column in Figure 12 indicate?

Appendix B

  Alternatively, the device may provide some method for the user to
  configure the NAI of the home network.  This is the user or

Please reiterate here that there can be privacy considerations with
doing the initial+completion exchange while roaming.

  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 SSID strings in the
  ServerInfo field called either SSIDList or Base64SSIDList.  The list

[This ServerInfo usage is prior to the roaming event, right?]

Appendix D

  server.  The URL MUST specify the https protocol, so that there is a
  secure connection to the server and the on-path attacker cannot read
  or modify the OOB message.

I recognize that the intent is to ban unencrypted http (and support this
goal), but as written this might prevent the use of other, equally
secure, URL schemes.

  The ServerInfo in this case includes a field called ServerUrl of the
  following format with RECOMMENDED length of 60 characters or less:

  https://[:]/[]

  To this, the peer appends the OOB message fields (PeerId, Noob, Hoob)
  as a query string.  [...]

To be honest, this feels like a great time to use POST rather than GET
with query string

(side note) If I understand correctly, this would not have been
compatible with the previous version of BCP 190, but a recent-ish update
makes it okay.

Appendix E

These examples all have the "Type" field first in the JSON object, but
generally the semantics of a JSON object are not dependent on the order
in which fields appear.  Please consider mentioning in the main text
something about field order and/or showing the examples in a variety of
orders.

It would also be helpful to show some examples for the key derivation
steps (IIUC we should the MAC plaintext inputs and the output but not
the MAC keys).

  These message examples show the case where the peer upgrades to
  Cryptosuite 2 during the Reconnect Exchange.  The messages are
  generated with NIST P-256 ECDHE test vectors specified in section 8.1
  of [RFC5903] (server=responder, peer=initiator).

Are we in a position to show the old/new Kz/etc.?

NITS

Section 1

  o  input or output interface that may be capable of only one-
      directional communication.

Does this refer to the non-network interface?  Presumably the interface
doing EAP can both send and receive...

  The solution presented here is intended for devices that have either
  an input or output interface, such as a camera, microphone, display

Likewise, is this an "'out-of-band' input or output interface"?

  This document describes a method for registration, authentication and
  key derivation for network-connected ubiquitous computing devices,

If devices are truly "ubiquitous", a manual OOB step will not scale and
fully automated mechanisms like BRSKI will be needed.  Perhaps a
different word than "ubiquitous" could be used?

  registration codes.  One reason for requiring dynamic OOB messages is
  that the receipt of the OOB message authorizes the server to take
  ownership of the device.  This is more secure than a static printed
  code, which could be leaked and later misused.

I think we should not use the pronoun "this", since it could be misread
as referring to the act of having the OOB message authorize the server
to take over the device (vs the intended "using dynamic OOB messages").

Section 3.2.2

  versions and cryptosuites.  The peer sends a response (Type=2) with
  the selected protocol version (Verp), the received PeerId, the
  selected cryptosuite (Cryptosuitep), an indicator of the OOB channel
  directions selected by the peer (Dirp), and a PeerInfo object.  In

"directions" plural are selected?  Perhaps "direction(s)"?

Section 3.2.3

  The OOB receiver MUST compare the received value of the fingerprint
  Hoob (see Section 3.3.2) with a value that it computes locally for

Maybe s/computes/computed/?  It seems like it would be more natural to
digest things and only save the (PeerId, Noob, Hoob) state rather than
the entire transcript and key-share, which implies that the value is
computed before the OOB message arrives.

  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

(pedantic nit) tracking the number of invalid messages inherently
requires "changing its state".

Section 3.2.4

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

Both sides support, or the peer selects to use?

Section 3.3.1

  server sent a NewNAI in the latest Initial Exchange, the peer MUST
  use this serve-assigned NAI.  When the peer moves to the Registered

s/serve-/server-/

Section 7.1

  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

I suggest using a different term than "master secret", perhaps just
"shared secret".

  Forward secrecy during fast reconnect in EAP-NOOB is optional.  The
  Reconnect Exchange in EAP-NOOB provides forward secrecy only if both
  the server and peer send their fresh ECDHE keys.  This allows both
  the server and the peer to limit the frequency of the costly
  computation that is required for forward secrecy.  [...]

We should say something about the case where the peer reuses its ECDH
share but the server generates a fresh one.  (Also, as mentioned
previously, the hash-forward scheme can provide some forward secrecy
without an ECDH exchange.)

Section 7.4

  User reset or failure in the OOB Step can cause the peer to perform
  many Initial Exchanges with the server, to allocate many PeerId
  values, and to store the ephemeral protocol state for them.  The peer
  will typically only remember the latest one.  EAP-NOOB leaves it to

I think we want to s/to store/the server to store/

Appendix D

  server.  The URL MUST specify the https protocol, so that there is a
  secure connection to the server and the on-path attacker cannot read
  or modify the OOB message.

s/protocol/scheme/

[Ballot comment]
Thank you for the work put into this document. I really like the ideas behind this OOB authentication.

Please find below some non-blocking COMMENT points (**but replies would be appreciated esp around CBOR**), and some nits.

Special thanks to Dave Thaler for his early IoT directorate review (and the CBOR discussion with Carsten):
https://datatracker.ietf.org/doc/review-ietf-emu-eap-noob-01-iotdir-early-thaler-2020-06-12/
https://mailarchive.ietf.org/arch/msg/iot-directorate/PNi6nxtR7_1T2rxu7O49HRx5Kdg/

I hope that this helps to improve the document,

Regards,

-éric

PS: when the ballot for this document was created, I failed to spot the DNS & IoT aspects of it, hence, the absence of INT and IoT directorates telechat reviews.

== COMMENTS ==

Like Carsten, I am really puzzled by the lack of consideration of CBOR to replace JSON especially for a protocol aimed at constrained devices. Was this discussed at the WG level ? I was unable to read any discussion on the mail list except about the IoT directorate thread.

This non-obvious choice of encoding ***should really be discussed*** in the document.

-- Section 2 --
Please apply the current BCP 14 template and not the old RFC 2119 one.

-- Section 3.1 --
"timeout needs to be several minutes rather than seconds" can this lead to a DoS against the server, which potentially needs to keep states for minutes ?

-- Section 3.2.1 --
I am not a EAP expert, so bear with my possibly naive question, "based on the realm part of the NAI", isn't it always "eap-noob.arpa" in this case ?

-- Section 3.2.2 --
What happens if the peer does not support any of the server's ciphersuite? Esp in the world of IoT where peers are old and cannot always be updated.Should there be a forward pointer to section 3.6.4 ?

-- Section 3.2.3 --
Suggest to give a hint to the reader for "Hoob": is this Hash of OoB ? Same comment for "Noob".

== NITS ==

Global nit: I prefer the use of 'octet' rather than 'byte'.

-- Section 1 --
Please avoid the use of 'we' as in 'We thus do not support'.

[Ballot discuss]
Thank you for the work on this document. I have a couple of blocking comments related to the IANA section, which should be easy to fix, plus some minor non blocking comments below.

Francesca


1. -----

Section 5.

FP: IANA is requested to create a sub registry to the EAP registry, but there is no actual "Nimble out-of-band authentication for EAP Parameters" registry defined, nor values registered in it. Either this is a new page or (I would suggest) the subregistries are just created directly under the EAP page.

2. -----

Section 5.1 and following

FP: This document defines several new registry with policy Specification required, which will need designated experts.
https://tools.ietf.org/html/rfc8126#section-5.3 states that:

  When a designated expert is used, the documentation should give clear
  guidance to the designated expert, laying out criteria for performing
  an evaluation and reasons for rejecting a request.  In the case where

I believe designated expert guidance should be added to this document.

[Ballot comment]
3. -----

  document are to be interpreted as described in [RFC2119].

FP: Please update as indicated by RFC 8174.

4. -----

  it supports, an indicator of the OOB channel directions it supports
  (Dirs), and a ServerInfo object.  The peer chooses one of the

FP: Please add a reference to where the ServerInfo object is defined, as this is its first occurrence.

5. -----

          |      (Type=3,PeerId,PKs,Ns,[SleepTime])          |

FP: SleepTime appear in the figure without having been introduced in the previous paragraph, as the other parameters. I would suggest adding a sentence about it, including a fw reference to where it is explained in detail (3.2.5).

6. -----

  use this serve-assigned NAI.  When the peer moves to the Registered

FP: nit - s/serve/server

7. -----

  and truncated to the 16 leftmost bytes of the output.  The message

FP: please mention that network byte order is used (either here or in the terminology).

8. -----

  reasons.  New EAP output values MSK and EMSK may be needed because of

FP: MSK and EMSK appear here for the first time, please expand.

9. -----

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

      ...

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

FP: I would suggest to add a sentence explicitly stating that H and HMAC are the hash function and HMAC specified in this paragraph:

  The fingerprint Hoob and the identifier NoobId are computed with the
  cryptographic hash function specified in the negotiated cryptosuite
  and truncated to the 16 leftmost bytes of the output.  The message
  authentication codes (MACs, MACp, MACs2, MACp2) are computed with the
  HMAC function [RFC2104] based on the same cryptographic hash function
  and truncated to the 32 leftmost bytes of the output.

10. -----

  |                  | integer. The registration of cryptosuites is  |
  |                  | specified in Section 5.1. Example values are  |
  |                  | "[1]" and "1", respectively.                  |

FP: not only registration, but also MTI and examples.

11. -----

  for EAP Parameters" registry.  Cryptosuites are identified by an
  integer.  EAP-NOOB request and response pairs are identified by an

FP: "Cryptosuite ... integer." I don't understand the point of having this sentence in this section, is this copy paste? (sections 5.2, 5.3)

12. -----

          | 1007      | Invalid ECDHE key                      |

FP: Out of curiosity, any special reason why this is not 1005?

13. -----

Appendix E.

FP: are the examples generated with any of the implementations mentioned? It would be good to state that in the first paragraph of the appendix. Also I am curious if the JSON examples were validated.

[Ballot comment]
[ section 2 ]

* Do you want to use the 8174 language instead of the 2119 version?

[ section 5.6 ]

* For eap-noob.arpa (or noob.eap.arpa or whatever), even though
  Application Software, Name Resolution APIs and Libraries, and
  Caching DNS Servers are "not expected to recognize this domain
  name as special", there is no harm if they do recognize it and
  short circuit any resolution attempts, yes?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-emu-eap-noob-04. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are eight actions which we must complete.

First, in the Method Types registry on the Extensible Authentication Protocol (EAP) Registry page located at:

https://www.iana.org/assignments/eap-numbers/

a new registration is to be made as follows:

Value: [ TBD-at-Registration ]
Description: EAP-NOOB
Reference: [ RFC-to-be ]

IANA understands that the authors have requested value 56 for this registration.

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request.  This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, a new registry is to be created called the Nimble out-of-band authentication for EAP Parameters registry. The new registry will be created on the Extensible Authentication Protocol (EAP) Registry page located at:

https://www.iana.org/assignments/eap-numbers/

IANA Question --> Can the authors confirm if the following registries are to be listed under the "Nimble out-of-band authentication for EAP Parameters" heading? If so, the Nimble out-of-band authentication for EAP Parameters registry has to be located under its own URL. We can\u2019t create a heading in the middle of a web page if it isn\u2019t for an actual registry. We can create a registry with that name at https://www.iana.org/assignments/eap-numbers/, but if it doesn't have any registrations, we can't create any sub-registries under it.

Third, a new registry is to be created called the EAP-NOOB Cryptosuites registry. The registry is managed via Specification Required as defined in RFC 8126.

There are initial values in the new registry as follows:

+-------------+-----------------------------------------------------+
| Cryptosuite | Algorithms |
+-------------+-----------------------------------------------------+
| 1 | ECDHE curve Curve25519 [RFC7748], public-key format |
| | [RFC7517], hash function SHA-256 [RFC6234] |
| 2 | ECDHE curve NIST P-256 [FIPS186-4], public-key |
| | format [RFC7517], hash function SHA-256 [RFC6234] |
+-------------+-----------------------------------------------------+

Fourth, a new registry is to be created called the EAP-NOOB Message Types registry. The registry is managed via Specification Required as defined in RFC 8126.

There are initial values in the new registry as follows:

+----------+------------+-------------------------------------------+---------------+
| Message | Used in | Purpose | Reference |
| Type | Exchange | | |
+----------+------------+-------------------------------------------+---------------+
| 1 | All | PeerId and PeerState discovery | [ RFC-to-be ] |
| | exchanges | | |
| | | | |
| 2 | Initial | Version, cryptosuite and parameter | [ RFC-to-be ] |
| | | negotiation | |
| | | | |
| 3 | Initial | Exchange of ECDHE keys and nonces | [ RFC-to-be ] |
| | | | |
| 4 | Waiting | Indication to peer that the server has | [ RFC-to-be ] |
| | | not yet received an OOB message | |
| | | | |
| 5 | Completion | NoobId discovery | [ RFC-to-be ] |
| | | | |
| 6 | Completion | Authentication and key confirmation with | [ RFC-to-be ] |
| | | HMAC | |
| | | | |
| 7 | Reconnect | Version, cryptosuite, and parameter | [ RFC-to-be ] |
| | | negotiation | |
| | | | |
| 8 | Reconnect | Exchange of ECDHE keys and nonces | [ RFC-to-be ] |
| | | | |
| 9 | Reconnect | Authentication and key confirmation with | [ RFC-to-be ] |
| | | HMAC | |
| | | | |
| 0 | Error | Error notification | [ RFC-to-be ] |
| | | | |
+----------+------------+-------------------------------------------+---------------+

Fifth, a new registry is to be created called the EAP-NOOB Error codes registry. The registry is managed via Specification Required as defined in [RFC8126], with the exception of the range 6001-6999. This range is reserved for "Private Use" and "Experimental Use."

There are initial values in the new registry as follows:

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

Sixth, a new registry is to be created called the EAP-NOOB ServerInfo data fields registry. The registry is managed via Specification Required as defined in RFC 8126.

There are initial values in the new registry as follows:

+----------------+--------------------------+
| Data field | Reference |
+----------------+--------------------------+
| Type | [ RFC-to-be; Section 4 ] |
| ServerName | [ RFC-to-be; Section 4 ] |
| ServerURL | [ RFC-to-be; Section 4 ] |
| SSIDList | [ RFC-to-be; Section 4 ] |
| Base64SSIDList | [ RFC-to-be; Section 4 ] |
+----------------+--------------------------+

Seventh, a new registry is to be created called the EAP-NOOB PeerInfo data fields registry. The registry is managed via Specification Required as defined in RFC 8126.

There are initial values in the new registry as follows:

+--------------+--------------------------+
| Data field | Reference |
+--------------+--------------------------+
| Type | [ RFC-to-be; Section 4 ] |
| PeerName | [ RFC-to-be; Section 4 ] |
| Manufacturer | [ RFC-to-be; Section 4 ] |
| Model | [ RFC-to-be; Section 4 ] |
| SerialNumber | [ RFC-to-be; Section 4 ] |
| MACAddress | [ RFC-to-be; Section 4 ] |
| SSID | [ RFC-to-be; Section 4 ] |
| Base64SSID | [ RFC-to-be; Section 4 ] |
| BSSID | [ RFC-to-be; Section 4 ] |
+--------------+--------------------------+

Eighth, in the Special-Use Domain Names registry located at:

https://www.iana.org/assignments/special-use-domain-names/

a new registration will be made as follows:

Name: eap-noob.arpa
Reference: [ RFC-to-be ]

IANA Question --> Do the authors only want the name in the special use registry or should it also be delegated in the .arpa zone? IANA notes that RFC3172 contains the guidelines for registration in that zone.

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Please note that specific values cannot be reserved. However, early allocation is available for some types of registrations. For more information, please see RFC 7120.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-04-13):

From: The IESG
To: IETF-Announce
CC: draft-ietf-emu-eap-noob@ietf.org, emu-chairs@ietf.org, emu@ietf.org, joe@salowey.net, rdd@cert.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Nimble out-of-band authentication for EAP (EAP-NOOB)) to Proposed Standard


The IESG has received a request from the EAP Method Update WG (emu) to
consider the following document: - 'Nimble out-of-band authentication for EAP
(EAP-NOOB)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-04-13. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The 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.  The EAP method is intended for bootstrapping all
  kinds of Internet-of-Things (IoT) devices that have no pre-configured
  authentication credentials.  The method makes use of a user-assisted
  one-directional OOB message between the peer device and
  authentication server to authenticate the in-band key exchange.  The
  device must have an input or output interface, such as a display,
  microphone, speaker or blinking light, which can send or receive
  dynamically generated messages of tens of bytes in length.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/



No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time.

This version is dated 20 January 2020.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard. The type of RFC is indicated in the title page. Proposed standard is the correct choice since this document defines a new EAP authentication protocol with several implementations.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document specifies a new EAP method called Nimble out-of-band authentication for EAP (EAP-NOOB). The method makes use of a user-assisted one-directional OOB message between the peer device and authentication server to authenticate the in-band key exchange.  The peer device must have an input or output interface, such as a display, microphone, speakers or blinking light, which can send or receive dynamically generated messages of tens of bytes in length.

Working Group Summary:

The document had sufficient review and discussion.  There is reasonable consensus for moving the document forward.

Document Quality:

The document has received detailed feedback from Dave Thaler as part of an early IoT directorate review. The document was also reviewed by experts such as Alan DeKok, Hannes Tshofenig, and Daniel Migault.

At least three public implementations of the protocol are available:
1. wpa_supplicant - https://github.com/tuomaura/eap-noob
2. contiki - https://github.com/eduingles/coap-eap-noob
3. hostap - https://github.com/Vogeltak/hostap

The protocol has security proofs:
1. Proverif: https://github.com/tuomaura/eap-noob/tree/master/protocolmodel/proverif
2. mcrl2: https://github.com/tuomaura/eap-noob/tree/master/protocolmodel/mcrl2

Personnel:
Document Shepherd - Joe Salowey
Responsible AD - Roman Danyliw

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd has reviewed the document and believes it is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No disclosures

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Reasonable consensus within the WG as a whole

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

No nits

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

NA

(13) Have all references within this document been identified as either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

Yes. Most normative references in the document are to published NIST, FIPS, and standards track RFCs. There are normative references to 3 informational RFCs (2104, 6234, and 7748) but all three are allowed as noted in the Downref registry: https://trac.ietf.org/trac/iesg/wiki/DownrefRegistry

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

IANA section is complete

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

Only the EAP-NOOB Message Type registry requires Expert Review for allocation of new values. The Message Type is a simple integer that identifies the EAP-NOOB request and response pairs. New integer values for new request/response pairs can be assigned by experts as and when necessary.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

NA

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

NA

As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time.

This version is dated 20 January 2020.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard. The type of RFC is indicated in the title page. Proposed standard is the correct choice since this document defines a new EAP authentication protocol with several implementations.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document specifies a new EAP method called Nimble out-of-band authentication for EAP (EAP-NOOB). The method makes use of a user-assisted one-directional OOB message between the peer device and authentication server to authenticate the in-band key exchange.  The peer device must have an input or output interface, such as a display, microphone, speakers or blinking light, which can send or receive dynamically generated messages of tens of bytes in length.

Working Group Summary:

The document had sufficient review and discussion.  There is reasonable consensus for moving the document forward.

Document Quality:

The document has received detailed feedback from Dave Thaler as part of an early IoT directorate review. The document was also reviewed by experts such as Alan DeKok, Hannes Tshofenig, and Daniel Migault.

At least three public implementations of the protocol are available:
1. wpa_supplicant - https://github.com/tuomaura/eap-noob
2. contiki - https://github.com/eduingles/coap-eap-noob
3. hostap - https://github.com/Vogeltak/hostap

The protocol has security proofs:
1. Proverif: https://github.com/tuomaura/eap-noob/tree/master/protocolmodel/proverif
2. mcrl2: https://github.com/tuomaura/eap-noob/tree/master/protocolmodel/mcrl2

Personnel:
Document Shepherd - Joe Salowey
Responsible AD - Roman Danyliw

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd has reviewed the document and believes it is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No disclosures

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Reasonable consensus within the WG as a whole

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

No nits

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

NA

(13) Have all references within this document been identified as either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

Yes. Most normative references in the document are to published NIST, FIPS, and standards track RFCs. There are normative references to 3 informational RFCs (2104, 6234, and 7748) but all three are allowed as noted in the Downref registry: https://trac.ietf.org/trac/iesg/wiki/DownrefRegistry

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

IANA section is complete

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

Only the EAP-NOOB Message Type registry requires Expert Review for allocation of new values. The Message Type is a simple integer that identifies the EAP-NOOB request and response pairs. New integer values for new request/response pairs can be assigned by experts as and when necessary.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

NA

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

NA