Nimble out-of-band authentication for EAP (EAP-NOOB)
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)
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], , [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)
I haven't finished my review of this, but while that's pending, I do want to say I support Francesca's DISCUSS.