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

[Deb Cooley <[e-mail]>]

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.
>