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 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/ ---------------------------------------------------------------------- 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. 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. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 3. ----- document are to be interpreted as described in [RFC2119]. FP: Please update as indicated by RFC 8174. 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). 6. ----- use this serve-assigned NAI. When the peer moves to the Registered FP: nit - s/serve/server 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). 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. 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. 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. 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) 12. ----- | 1007 | Invalid ECDHE key | FP: Out of curiosity, any special reason why this is not 1005? 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. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
