Subject: Re: [Emu] Francesca Palombini's Discuss on draft-ietf-emu-eap-noob-04: (with DISCUSS and COMMENT)

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

Hi Francesca,

We have submitted a new version ( 
https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-noob-05 ) which 
hopefully addresses your comments. Here is the diff for your 
convenience: 
https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-noob-05.txt

See our answers below.

--Mohit

On 4/20/21 1:37 AM, Francesca Palombini via Datatracker wrote:
> Francesca Palombini has entered the following ballot position for
> draft-ietf-emu-eap-noob-04: Discuss
>
> 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/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Thank you for the work on this document. I have a couple of blocking comments
> related to the IANA section, which should be easy to fix, plus some minor non
> blocking comments below.
>
> Francesca
>
> 1. -----
>
> Section 5.
>
> FP: IANA is requested to create a sub registry to the EAP registry, but there
> is no actual "Nimble out-of-band authentication for EAP Parameters" registry
> defined, nor values registered in it. Either this is a new page or (I would
> suggest) the subregistries are just created directly under the EAP page.
This question was also asked by Sabrina during the IANA review.  A 
separate URL (or page) for EAP-NOOB is what we intended. There is 
precedence for such an approach: EAP-FAST. There is a separate URL for 
EAP-FAST parameters: 
https://www.iana.org/assignments/eap-fast-parameters/eap-fast-parameters.xhtml 
but all the sub registries are still listed on the main EAP registry 
with links (such as 
https://www.iana.org/assignments/eap-numbers/eap-numbers.xhtml#eap-numbers-5). 
So we are hoping for the same, i.e.: i) a separate URL for the EAP-NOOB 
registry titled "Nimble out-of-band authentication for EAP Parameters", 
ii) the separate URL should contain sub registries listed in section 5.1 
to 5.5 of the draft, iii) the sub registries are listed in the EAP 
Registry 
(https://www.iana.org/assignments/eap-numbers/eap-numbers.xhtml) only as 
links pointing to the URL to the separate EAP-NOOB registry.
> 2. -----
>
> Section 5.1 and following
>
> FP: This document defines several new registry with policy Specification
> required, which will need designated experts.
> https://tools.ietf.org/html/rfc8126#section-5.3  states that:
>
>     When a designated expert is used, the documentation should give clear
>     guidance to the designated expert, laying out criteria for performing
>     an evaluation and reasons for rejecting a request.  In the case where
>
> I believe designated expert guidance should be added to this document.
We have added section "Guidance for Designated Experts": 
https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-noob-05#section-5.7. 
We hope this is sufficient.
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> 3. -----
>
>     document are to be interpreted as described in [RFC2119].
>
> FP: Please update as indicated by RFC 8174.
Done.
> 4. -----
>
>     it supports, an indicator of the OOB channel directions it supports
>     (Dirs), and a ServerInfo object.  The peer chooses one of the
>
> FP: Please add a reference to where the ServerInfo object is defined, as this
> is its first occurrence.
>
> 5. -----
>
>            |      (Type=3,PeerId,PKs,Ns,[SleepTime])          |
>
> FP: SleepTime appear in the figure without having been introduced in the
> previous paragraph, as the other parameters. I would suggest adding a sentence
> about it, including a fw reference to where it is explained in detail (3.2.5).
As authors we have tried to strike a careful balance between explaining 
new terms when they are first occur vs. avoiding repetition and 
interruptions to the readability of the text. Therefore, some terms like 
ServerInfo, PeerInfo, SleepTime etc. are not defined immediately. We 
hope this is an acceptable compromise.
> 6. -----
>
>     use this serve-assigned NAI.  When the peer moves to the Registered
>
> FP: nit - s/serve/server
Fixed.
> 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.
> 8. -----
>
>     reasons.  New EAP output values MSK and EMSK may be needed because of
>
> FP: MSK and EMSK appear here for the first time, please expand.
Done.
> 9. -----
>
>        Hoob = H(Dir,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,Cryptos
>        uitep,Dirp,[NewNAI],PeerInfo,0,PKs,Ns,PKp,Np,Noob).
>
>        ...
>
>        MACs = HMAC(Kms; 2,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,C
>        ryptosuitep,Dirp,[NewNAI],PeerInfo,0,PKs,Ns,PKp,Np,Noob).
>
> FP: I would suggest to add a sentence explicitly stating that H and HMAC are
> the hash function and HMAC specified in this paragraph:
>
>     The fingerprint Hoob and the identifier NoobId are computed with the
>     cryptographic hash function specified in the negotiated cryptosuite
>     and truncated to the 16 leftmost bytes of the output.  The message
>     authentication codes (MACs, MACp, MACs2, MACp2) are computed with the
>     HMAC function [RFC2104] based on the same cryptographic hash function
>     and truncated to the 32 leftmost bytes of the output.

We have clarified the definitions of the functions H and HMAC as follows:

>  The fingerprint Hoob and the identifier NoobId are computed with the
>    cryptographic hash function H, which is specified in the negotiated
>    cryptosuite and truncated to the 16 leftmost bytes of the output.
>    The message authentication codes (MACs, MACp, MACs2, MACp2) are
>    computed with the function HMAC, which is the HMAC message
>    authentication code [RFC2104] based on the cryptographic hash
>    function H and truncated to the 32 leftmost bytes of the output.

> 10. -----
>
>     |                  | integer. The registration of cryptosuites is   |
>     |                  | specified in Section 5.1. Example values are   |
>     |                  | "[1]" and "1", respectively.                   |
>
> FP: not only registration, but also MTI and examples.
Added that the section also list the MTI cryptosuites.
> 11. -----
>
>     for EAP Parameters" registry.  Cryptosuites are identified by an
>     integer.  EAP-NOOB request and response pairs are identified by an
>
> FP: "Cryptosuite ... integer." I don't understand the point of having this
> sentence in this section, is this copy paste? (sections 5.2, 5.3)
Yes, I suspect a copy paste leftover. Thanks for catching this. We have 
removed this stray sentence.
> 12. -----
>
>            | 1007       | Invalid ECDHE key                      |
>
> FP: Out of curiosity, any special reason why this is not 1005?
Some error types were moved to a different category. We have changed 
this to 1005 now.
> 13. -----
>
> Appendix E.
>
> FP: are the examples generated with any of the implementations mentioned? It
> would be good to state that in the first paragraph of the appendix. Also I am
> curious if the JSON examples were validated.
The messages were generated with a python script 
(https://github.com/tuomaura/eap-noob/tree/master/test-vectors) and 
verified against the C implementation. The JSON examples are validated 
for basic syntactic correctness.
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu

---

From: Francesca Palombini <[email-masked]>
Date: Fri, 30 Jul 2021 19:49:35 +0000

Hi Mohit! 

Thanks for your answer and for addressing my DISCUSS, I will go ahead and remove the block now. All the rest of the comments also look good, however I am not convinced by 7: see my answer below. However this is minor and non-blocking, so I will let you and Roman decide if and how to implement a change.

Thanks,
Francesca

...

>that could lead to a programmer mistakenly reordering the bytes in the 

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.