Francesca Palombini has entered the following ballot position for draft-ietf-ace-wg-coap-eap-11: 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/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ace-wg-coap-eap/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you for the work on this document. I have a few comments that I'd like to see addressed before the document moves forward. I don't think any of these are particularly controversial, but they really should be fixed before publication, which is why I mark them as DISCUSS. Section 3.5.1: > EAP authentication MAY fail in different situations (e.g., wrong credentials). Incorrect use of BCP 14 "MAY", I think you mean to use "may" in this case. Section 6.2: > CS is the concatenation of the content of the cipher suite negotiation, that is, the list of cipher suites sent by the EAP authenticator (Step 1) to the selected option by the EAP peer (Step 2). "The list of cipher suites" and "the selected option" is not precise enough on what CS is: you need to specify that CS is the concatenation of two CBOR arrays (with CBOR ints or text strings as elements), as defined in section 5. One could interpret it as being the concatenation of a CBOR array with a CBOR int or tstr. Same comment for the Master Salt, which should be made consistent with the text for Master Secret, and instead now says: > CS is the concatenation of the content of the cipher suite negotiation, in the request and response. If any of the messages did not contain the CBOR array, the null string is used. Section 6.2: You should explicitly mention that ID Context is not provided for the OSCORE Security Context derivation. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Murray's and Orie's DISCUSSes. Section 3.2: > In this step, the EAP peer MAY create an OSCORE security context (see Section 6.2). The required Master Session Key (MSK) will be available once the EAP authentication is successful in step 7. But MSK is necessary to derive the OSCORE security context - that means the EAP peer cannot create it in this step, right? What did I miss? Section 5: > cipher suite: It contains an array including the list of the proposed or selected COSE algorithms for OSCORE. This is a nit (and my personal interpretation of verbs in CBOR terminology) - I would remove "it contains". cipher suite "is" an array. "containing" is used for arrays or maps, which would make this an array of arrays. Same for the other parameters, I would just replace "contains" with "is". Section 6.1: > This list is included in the payload after the EAP message through a CBOR as explained previously. Missing text (CBOR ...? object? array?). I would also recommend to remove "previously" and replace with the precise reference (Section 5?) Section 6.2: I would suggest adding a pointer to Section 3.2.1 of RFC 8613 somewhere in this section to mention that once Master Secret and Master Salt are derived you can use them to derive the rest of the OSCORE Security Context. _______________________________________________ Ace mailing list -- ace@ietf.org To unsubscribe send an email to ace-le...@ietf.org
