My concern with this proposal of defining a new KDF is that it is a clear breaking change to any implementation that may exist.
In my opinion such a change would be fine if we want to bump some version numbers - maybe the TEAP version number has to be bumped, or maybe this can be achieved solely with the TLV version fields some of the TLVs contain. I haven’t thought about this aspect of too much. But redefining the KDF entirely with no version changes would be disruptive to multiple products. This leads to a follow-up concern is - if an entirely new KDF were to be defined, I believe it should avoid using the TLS 1.2 PRF since it is already obsoleted in TLS 1.3. Jorge Vergara From: Oleg Pekar <oleg.pekar.2...@gmail.com> Sent: Thursday, October 22, 2020 6:59 AM To: Joseph Salowey <j...@salowey.net> Cc: EMU WG <emu@ietf.org>; Jorge Vergara <jover...@microsoft.com>; Jouni Malinen <j...@w1.fi> Subject: Re: Proposed resolution for TEAP errata for 5128 Hi all, Speaking about both errata 5127 and 5128, I think we need to align all key derivation calls in TEAP RFC with the same rule/format to make the RFC easier to understand. This can be achieved by introducing a unified single PRF function that will be called from all the relevant RFC locations. For me it sounds better than if we align just part of KDF calls with RFC 5295 (where the output length is included into seed). Also: in some KDF calls we do have optional data and in some no. This could be also unified. So I would suggest introducing: TEAP-PRF (secret, key label, optional data, length) = TLS-PRF(secret, key label | 0x00 | optional data, length) where a single byte 0x00 is used for no optional data, length is a 2-octet unsigned integer in network byte order. Then: IMSK = First 32 octets of TEAP-PRF(EMSK, "teapbind...@ietf.org<mailto:teapbind...@ietf.org>", 64) = TLS-PRF(EMSK, "teapbind...@ietf.org<mailto:teapbind...@ietf.org>" | 0x00 | 0x00 | 0x00 | 0x40) IMCK[j] = TEAP-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j], 60) = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys" | 0x00 | IMSK[j] | 0x00 | 0x3C) MSK = TEAP-PRF(S-IMCK[j], "Session Key Generating Function”, 64) = TLS-PRF(S-IMCK[j], "Session Key Generating Function" | 0x00 | 0x00 | 0x00 | 0x40) EMSK = TEAP-PRF(S-IMCK[j], ”Extended Session Key Generating Function”, 64) = TLS-PRF(S-IMCK[j], "Extended Session Key Generating Function" | 0x00 | 0x00 | 0x00 | 0x40) This may change the existing implementation but will make it more clear - need to create and call just one KDF function. We can remove 0x00 that comes after the key label - while it is required by RFC 5295. But there the key label is also ASCII printable string. Joe, do you remember what was the motivation to put 0x00 after the key label parameter? Oleg On Thu, Oct 22, 2020 at 2:54 AM Joseph Salowey <j...@salowey.net<mailto:j...@salowey.net>> wrote: (I accidentally dropped this list from the conversation) On Wed, Oct 21, 2020 at 4:48 PM Jorge Vergara <jover...@microsoft.com<mailto:jover...@microsoft.com>> wrote: >[Joe] Yes this is a concern and I think your interpretation of the current >document is also valid. There may be more than one implementation. So what >you implemented was: > >IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j]) = >P_<hash>(S-IMCK[j-1], "Inner Methods Compound Keys" | IMSK[j]) Yes, this is what I implemented. As you mentioned, there are multiple possible interpretations of this since the TEAP usage is incorrect. However, my implementation does interop with at least 2 large vendor implementations. If the implementations were using different calculations here, the Wi-Fi/Ethernet connections that depend on the MSK would fail. But since connections work, I can assume we are all using the same implementation and arriving at the same MSK. Cisco is one of the implementations that I have tested against which is why I was hoping Oleg may offer more context as to what he has seen. [Joe] I can hope Jouni can chime in on this as well. I think the original intent was to not include the length as is your suggestion. >[Joe] Does the revision in 5167 match you implementation ( I don't think >Jouni's comment changes the underly calculation, just its representation)? I have not implemented this portion of the RFC as I found it too unclear to work with. Thus I can’t comment on what implementations may be doing. However, I agree with the current revision in 5167 as the most natural interpretation. If others have implemented this portion of the RFC then certainly their comments would be welcome. By the way, we’ve dropped the EMU group on our replies here – not sure if intentional or not. Jorge Vergara From: Joseph Salowey <j...@salowey.net<mailto:j...@salowey.net>> Sent: Wednesday, October 21, 2020 4:36 PM To: Jorge Vergara <jover...@microsoft.com<mailto:jover...@microsoft.com>> Subject: Re: Proposed resolution for TEAP errata for 5128 On Wed, Oct 21, 2020 at 3:20 PM Jorge Vergara <jover...@microsoft.com<mailto:jover...@microsoft.com>> wrote: In theory I agree this is a possible resolution. However, this doesn’t match any of the current TEAP implementations that I am aware of. Perhaps Oleg can weigh in as well in terms of what he’s seen. I believe all current implementations treat 60 as the desired output length without treating as a seed. In terms of P_<hash>, this means implementations are performing the calculation without a seed. RFC 5246 defines the TLS 1.2 PRF as: PRF(secret, label, seed) = P_<hash>(secret, label + seed) So the calculation implementations are currently performing with an empty seed ends up as: P_<hash>(secret, label) Note that in RFC 5295, the length *is* explicitly mentioned as being concatenated with the label USRK = KDF(EMSK, key label | "\0" | optional data | length) RFC 5295 is mentioned earlier in the TEAP RFC, in the section covered by errata 5127. *However* it is not mentioned in this portion of the RFC. Since this calculation is not on an EMSK, I do not believe RFC 2395 applies and this is likely why implementations went with the seedless P_<hash>(secret, label) calculation instead. Is there concern about updating the RFC in a way that breaks existing implementations? [Joe] Yes this is a concern and I think your interpretation of the current document is also valid. There may be more than one implementation. So what you implemented was: IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j]) = P_<hash>(S-IMCK[j-1], "Inner Methods Compound Keys" | IMSK[j]) taken out to 60 bytes. The problem is that the TEAP spec references a TLS-PRF in a way that it does not define. I think the errata points out the definition that should be used: PRF(secret, label, seed) = P_<hash>(secret, label + seed) That does not include length so the 60 in the original definition is ambiguous. The new text would then be something like: IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j]) to generate a length of 60 bytes Does the revision in 5167 match you implementation ( I don't think Jouni's comment changes the underly calculation, just its representation)? Jorge Vergara From: Joseph Salowey <j...@salowey.net<mailto:j...@salowey.net>> Sent: Wednesday, October 21, 2020 2:34 PM To: EMU WG <emu@ietf.org<mailto:emu@ietf.org>>; Jouni Malinen <j...@w1.fi<mailto:j...@w1.fi>>; Jorge Vergara <jover...@microsoft.com<mailto:jover...@microsoft.com>>; Oleg Pekar (olpekar) <olpe...@cisco.com<mailto:olpe...@cisco.com>> Subject: Proposed resolution for TEAP errata for 5128 Errata 5128: https://www.rfc-editor.org/errata/eid5128<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid5128&data=04%7C01%7Cjovergar%40microsoft.com%7C0c37db33d7a74c4fdfd108d87692b46f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637389719762481075%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tm01%2FqLAGaQ9HxeyBeeU0yGPXVOPdWjIRDtPwW%2FRjGI%3D&reserved=0> Proposed State: Verified Revision: Section 5.2. says IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j], 60) It should say: IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j] | 60) Note: According to RFC5246 The Transport Layer Security (TLS) Protocol Version 1.2 5. HMAC and the Pseudorandom Function "TLS's PRF is created by applying P_hash to the secret as: PRF(secret, label, seed) = P_<hash>(secret, label + seed)" In terms of P_<hash> this would look like the following with the length represented as a 2 byte value in network byte order: IMCK[j] = P_<hash>(S-IMCK[j-1], "Inner Methods Compound Keys" | IMSK[j] | 0x00 | 0x3C)
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
