Great, thank you.
Best regards.
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 <garciadan@xxxxxxxxx> 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ó:
Great, thank you.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
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.
RFC5869In some applications, the input key material IKM may already bepresent as a cryptographically strong key (for example, the premastersecret in TLS RSA cipher suites would be a pseudorandom string,except for the first two octets). In this case, one can skip theextract 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.
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
