Re: [Ace] Secdir last call review of draft-ietf-ace-wg-coap-eap-09

[Dan Garcia Carrillo <[e-mail]>]

Great, thank you.

Best regards.


El 25/1/24 a las 14:26, Deb Cooley escribió:
> My 5.1 comment:  I skimmed RFC 4017 and it seems sufficient.  I also 
> looked to see if EAP methods include it as a reference (and many of 
> them do).  It is my opinion that w/ the addition of a reference and 
> some clarifying text will allow you to claim that the MSK is a 'strong 
> cryptographic key', and therefore ok to use the HKDF KDF Expand directly.
>
> I apologize for not catching this in the early review!
>
> Deb
>
> On Thu, Jan 25, 2024 at 5:46 AM Dan Garcia Carrillo 
> <[e-mail]> wrote:
>
>     Dear Deb,
>
>     Thank you for the update on the review.
>
>     Please let us comment inline.
>
>     El 23/1/24 a las 13:07, Deb Cooley via Datatracker escribió:
>>     Reviewer: Deb Cooley
>>     Review result: Has Nits
>>
>>     I have reviewed this document as part of the security directorate's
>>     ongoing effort to review all IETF documents being processed by the
>>     IESG.  These comments were written primarily for the benefit of the
>>     security area directors.  Document editors and WG chairs should treat
>>     these comments just like any other last call comments.
>>
>>     Document: draft-ietf-ace-wg-coap-eap-09
>>     Reviewer: Deb Cooley
>>     Review Date: 2024-01-23
>>
>>     The summary of the review is 'Has Nits'.
>>
>>     0.  All of my early review comments have been addressed.  TY
>     Great, thank you.
>>     1.  Section 5.1, last paragraph:  The MSK can be assumed to be 'fresh key
>>     material', but do all EAP methods yield 'strong cryptographic key' by Section
>>     3.3 of RFC 5869?  If some EAP methods do not yield strong keys, then either the
>>     KDF Extract should be used, or those methods should not be allowed.  (I did not
>>     look this up, so telling me that you all checked is a fine answer)
>
>     This is a very good point.
>
>     In this sense, we limit the applicability of EAP methods to the
>     ones compliant with the mandatory requirements of RFC4017. We will
>     add  this clarification to the text.
>
>     Regarding the use of Extract, as it says in RFC5869, if we
>     understand that the MSK is cryptographically strong by the
>     requirements of RFC4017, we can directly use expand.
>
>       
>
>     RFC5869
>
>     In some applications, the input key material IKM may already be
>
>     present as a cryptographically strong key (for example, the premaster
>
>     secret in TLS RSA cipher suites would be a pseudorandom string,
>
>     except for the first two octets).In this case, one can skip the
>
>     extract part and use IKM directly to key HMAC in the expand step.
>
>
>     That said, we do not see any inconvenient, far from it, that in
>     addition to the requisites of RFC4017 for EAP methods to be used,
>     to use extract as well for the case of CoAP-EAP to create a
>     specific key.
>
>     Do you think this is an adequate approximation, o could we leave
>     it as it currently is with these clarifications?
>
>     Using extract would change the design a bit, and we would have to
>     define the new process, selecting the salt (e.g., a transcript
>     hash of the exchange up to that point to generate a PRK). We
>     understand that this would delay the process further and maybe we
>     will be doing something unnecessary.
>
>     What do you think?
>
>
>>     2.  Section 5.2:  It would be useful to have an actual example of the info part
>>     of the KDF. How is CS constructed - spaces, commas? Are there spaces between CS
>>     and the string?
>>
>     We will add an example of this.
>
>     Thank you.
>
>     Best regards.
>