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 <garcia...@uniovi.es> 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. >
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
