Subject: Re: [Emu] Éric Vyncke's No Objection on draft-ietf-emu-eap-noob-04: (with COMMENT)

From: Mohit Sethi M <[email-masked]>
Date: Fri, 16 Jul 2021 09:35:24 +0000

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-masked]
> https://www.ietf.org/mailman/listinfo/emu