Dear Francesca,
Thank you for the review and comments.
Please see answers inline:
El 21/11/24 a las 15:17, Francesca Palombini via Datatracker escribió:
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 tohttps://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!D9dNQwwGXtA!Q1Cb6e-7SKoB_ipmJ7kYvWJ2-kflp1p6epu11oLPfGAxbL_JoToR7m9SZAO0AriMTMtfyFXnsIlgvY-6$
for more information about how to handle DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-ace-wg-coap-eap/__;!!D9dNQwwGXtA!Q1Cb6e-7SKoB_ipmJ7kYvWJ2-kflp1p6epu11oLPfGAxbL_JoToR7m9SZAO0AriMTMtfyFXnsEkxAc6X$
----------------------------------------------------------------------
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.
Authors > Thank you, we changed that.
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.
Authors > Thank you, we clarified the text as suggested.
Section 6.2: You should explicitly mention that ID Context is not provided for
the OSCORE Security Context derivation.
Authors > We added the note to the beginning of the section.
----------------------------------------------------------------------
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?
Authors > There was a discussion about this in the ACE WG.
https://mailarchive.ietf.org/arch/msg/emu/nb8zGGDJ3d4fUaCW8QMkf6rkhVs/
<https://mailarchive.ietf.org/arch/msg/emu/nb8zGGDJ3d4fUaCW8QMkf6rkhVs/>
https://mailarchive.ietf.org/arch/msg/core/AK8Wxy64tXofocdRHm5HNew8dpE/
<https://mailarchive.ietf.org/arch/msg/core/AK8Wxy64tXofocdRHm5HNew8dpE/>
The summary would be that, we leverage what is called the alternate
indication of success, to trigger the same event as the reception of the
EAP success would. This alternate indication of success is the reception
of the OSCORE message that can be generated by the EAP server.
We indicated that in the draft. Following your comments, we realized
that the text can be improved as follows:
“The reception of the OSCORE-protected POST message is considered by the
EAP peer as an alternate indication of success ([RFC3748
<https://www.rfc-editor.org/info/rfc3748>]). The EAP peer state machine
in the EAP peer interprets the alternate indication of success
(similarly to the arrival of an EAP Success) and returns the MSK, which
is used to create the OSCORE security context in the EAP peer to process
the protected POST message received from the EAP authenticator”
Hopefully, this clarifies the question.
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".
Authors > Thank you, we clarified the text following the suggestions.
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?)
Authors > We clarified the text as suggested.
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.
Authors > We added this at the beginning of the section.
Thank you again for the review. Best regards.
--
Dan García Carrillo
---------------------
Departamento de Informática, Área de Telemática, Universidad de Oviedo
2.7.8 - Escuela Politécnica de Ingeniería, 33204, Campus de Viesques, Gijón
Tel.: +34 985182654 (Ext. 2654) | email:garcia...@uniovi.es
_______________________________________________
Ace mailing list -- ace@ietf.org
To unsubscribe send an email to ace-le...@ietf.org
