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

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

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.