Hi Éric, Thanks for the review. Answers below.
--Mohit On 4/20/21 4:29 PM, Éric Vyncke via Datatracker wrote: > Éric Vyncke has entered the following ballot position for > draft-ietf-emu-eap-noob-04: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer tohttps://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/ > > > > ---------------------------------------------------------------------- > 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. The working group had extensive discussion on the issue of CBOR vs JSON encoding. See, for example, slide 8 from IETF 108 (https://datatracker.ietf.org/meeting/108/materials/slides-108-emu-eap-noob-00 <https://datatracker.ietf.org/meeting/108/materials/slides-108-emu-eap-noob-00>). At the end, there was consensus for using JSON (with the possibility of adding CBOR later). There were many reasons for this decision by the working group. First, there were several implementations and early deployments of EAP-NOOB already using JSON. Second, there is support for JSON encoding/decoding in wpa_supplicant. wpa_supplicant is the most popular EAP peer implementation. It does not have support for CBOR encoding/decoding. Third, devices using EAP are either class 1 or 2, as defined in RFC7228. So while the benefits of CBOR would have been nice, they can live with JSON. > -- Section 2 -- > Please apply the current BCP 14 template and not the old RFC 2119 one. We have updated the text. > -- 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 ? We have added a new sub-section on "Denial of Service" in the security considerations section: https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-noob-05#section-7.8 > -- 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 ? That's a good question. You are right that in the default case, it will always be eap-noob.arpa. However, EAP-NOOB allows the server to assign a new NAI: "the server MAY assign a new NAI to the peer in the Initial Exchange or Reconnect Exchange, in the NewNAI field of request types 2 and 7, to override any previous NAI value.". So it can be different if the server assigns something other than eap-noob.arpa. > -- 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 ? We have tried to make the text readable by collecting error handling into one section (3.6), rather than constantly interrupting the flow of the text by mentioning possible error conditions. We hope that the list in section 3.6 gives the implementers a more complete picture of error handling than if some, but not all, errors were explained in the sections where they may occur. > -- Section 3.2.3 -- > Suggest to give a hint to the reader for "Hoob": is this Hash of OoB ? Same > comment for "Noob". We expect those familiar with cryptographic protocol notations to interpret the H in Hoob as the common symbol for hash and oob as its subscript. In Latex, this would be $H_{\text{oob}}$. Similarly, Noob consists of the commonly-used symbol N for a nonce and the oob subscript: $N_{\text{oob}}$. While we understand your question, explaining such origins of the notation in the draft would be confusing. Instead, we have tried to make the definition "the secret nonce Noob, and the cryptographic fingerprint Hoob" in section 3.2.3 understandable to every reader. > == 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'. Unless these stylistic issues are a complete show-stopper, we would like to avoid such global changes to the document at this stage. > _______________________________________________ > Emu mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
