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

[Mohit Sethi M]

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

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

[Éric Vyncke via Datatracker]

É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 to https://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.

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



___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu