Nimble out-of-band authentication for EAP (EAP-NOOB)
draft-ietf-emu-eap-noob-06

Note: This ballot was opened for revision 04 and is now closed.

Roman Danyliw Yes

Alvaro Retana No Objection

Benjamin Kaduk (was Discuss) No Objection

Comment (2021-08-17 for -05)
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.

Erik Kline No Objection

Comment (2021-04-18 for -04)
[ 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?

Francesca Palombini (was Discuss) No Objection

Comment (2021-07-30 for -05)
No email
send info
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.

Lars Eggert No Objection

Comment (2021-04-22 for -04)
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://<host>[:<port>]/[<path>] 
>                                         ^^^^
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://<host>[:<port>]/[<path
 * https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pdf

Martin Vigoureux No Objection

Robert Wilton No Objection

Zaheduzzaman Sarker No Objection

Comment (2021-04-22 for -04)
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.

Éric Vyncke No Objection

Comment (2021-04-20 for -04)
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'.

Murray Kucherawy No Record

Comment (2021-04-22 for -04)
No email
send info
I haven't finished my review of this, but while that's pending, I do want to say I support Francesca's DISCUSS.