>[Joe] This is the one we have not discussed yet. This derivation is also >ambiguous. THis section does not reference 5295. It's not clear if the >original intent was to include the length in the hash or not. I think there >are a few interpretations: > >1. TLS-PRF(S-IMCK[j], "Session Key Generating Function") iterated to generate >64 bytes = P_hash(S-IMCK[j], "Session Key Generating Function”) >2. TLS-PRF(S-IMCK[j], "Session Key Generating Function", 64) iterated to >generate 64 bytes = P_hash(S-IMCK[j], "Session Key Generating Function” | 0x00 >| 0x40) >3. (Follow 5295 parameters) TLS-PRF(S-IMCK[j], "Session Key Generating >Function", "\0" | 64) = P_hash(S-IMCK[j], "Session Key Generating Function” | >0x00 | 0x00 | 0x40) > >I think 1 or 2 is what was probably originally intended, however it seems that >3 is what has been implemented. Do we have agreement on this is what current >implementations do?
No, Microsoft implements number 1 of Joe’s presented options. That is - P_<hash>(S-IMCK[j], "Session Key Generating Function"). This follows the same pattern as the errata we are discussion. I am very surprised to hear that Cisco’s implementation may be different. Oleg, could you please double check? I have just double checked our implementation. Since our implementations interop, I assume we must have the same implementation. Jorge Vergara From: Joseph Salowey <j...@salowey.net> Sent: Thursday, October 22, 2020 9:53 AM To: Oleg Pekar <oleg.pekar.2...@gmail.com> 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 On Thu, Oct 22, 2020 at 9:29 AM Oleg Pekar <oleg.pekar.2...@gmail.com<mailto:oleg.pekar.2...@gmail.com>> wrote: I agree that changing the KDF is harmful to existing implementations. However, if I understood correctly, Joe's suggestion for IMCK[j] also breaks the existing implementation. I still see that we can define a unified KDF by changing the API in the RFC but with the same harm to the existing implementation in IMCK[j] as in both proposals: TEAP-PRF (secret, key label, optional data, length) = TLS-PRF(secret, key label | 0x00 | optional data, length) Joe, thanks for pointing out that RFC 5295 doesn't specify that a 0x00 is used to represent no optional data, that was just my mistake. IMSK: Current Microsoft and Cisco implementation: P_hash(EMSK, "teapbind...@ietf.org<mailto:teapbind...@ietf.org>" | 0x00 | 0x00 | 0x40) Joe's proposal: P_hash(EMSK, "teapbind...@ietf.org<mailto:teapbind...@ietf.org>" | 0x00 | 0x00 | 0x40), the same, just the API correction Unified KDF proposal: TEAP-PRF(EMSK, "teapbind...@ietf.org<mailto:teapbind...@ietf.org>", <no optional data>, 64) = P_hash(EMSK, "teapbind...@ietf.org<mailto:teapbind...@ietf.org>" | 0x00 | 0x00 | 0x40) --- no implementation change IMCK[j]: Current Microsoft and Cisco implementation: P_hash(S-IMCK[j-1], "Inner Methods Compound Keys” | IMSK[j]) Joe's proposal: P_hash(S-IMCK[j-1], "Inner Methods Compound Keys" | IMSK[j] | 0x00 | 0x3C) Unified KDF proposal: TEAP-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j], 60) = P_hash(S-IMCK[j-1], "Inner Methods Compound Keys" | IMSK[j] | 0x00 | 0x3C) --- implementation change [Joe] That was my initial proposal, but based on Jorge's comment it is modified to: IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j]) to generate a length of 60 bytes IMCK[j] = P_hash(S-IMCK[j-1], "Inner Methods Compound Keys” | IMSK[j]) MSK: Current Microsoft and Cisco implementation: P_hash(S-IMCK[j], "Session Key Generating Function” | 0x00 | 0x00 | 0x40) Unified KDF proposal: TEAP-PRF(S-IMCK[j], "Session Key Generating Function”, <no optional data>, 64) = P_hash(S-IMCK[j], "Session Key Generating Function” | 0x00 | 0x00 | 0x40) --- no implementation change [Joe] This is the one we have not discussed yet. This derivation is also ambiguous. THis section does not reference 5295. It's not clear if the original intent was to include the length in the hash or not. I think there are a few interpretations: 1. TLS-PRF(S-IMCK[j], "Session Key Generating Function") iterated to generate 64 bytes = P_hash(S-IMCK[j], "Session Key Generating Function”) 2. TLS-PRF(S-IMCK[j], "Session Key Generating Function", 64) iterated to generate 64 bytes = P_hash(S-IMCK[j], "Session Key Generating Function” | 0x00 | 0x40) 3. (Follow 5295 parameters) TLS-PRF(S-IMCK[j], "Session Key Generating Function", "\0" | 64) = P_hash(S-IMCK[j], "Session Key Generating Function” | 0x00 | 0x00 | 0x40) I think 1 or 2 is what was probably originally intended, however it seems that 3 is what has been implemented. Do we have agreement on this is what current implementations do? Jorge, please correct me if I misinterpret the Microsoft implementation. On Thu, Oct 22, 2020 at 6:55 PM Joseph Salowey <j...@salowey.net<mailto:j...@salowey.net>> wrote: On Thu, Oct 22, 2020 at 6:59 AM Oleg Pekar <oleg.pekar.2...@gmail.com<mailto:oleg.pekar.2...@gmail.com>> wrote: 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. [Joe] I don't think this was the original intent of the document. The IMSK derivation referenced 5295 while the others just reference the TLS PRF. I think to unify them would require a document update and I'm not sure what we would gain especially if we have implementations that do this. 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. [Joe] I don't think that 5295 specifies that a 0x00 is used to represent no optional data. Did you see this in the spec? It may be ambiguous, but I think the intent is that optional data is just omitted if it is not provided. 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? [Joe] the null after the key label is to provide a delimiter between the key label and optional data. Since the optional data can be arbitrary content the null prevents two different lablels with specially crafted optional data from deriving the same key. 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%7C1607f5f05ab64c11228108d876ab0304%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637389824150792537%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2FY77gd5%2BZnRPHT%2Bkq2KkTJPlkK2hIu%2FfFejHlj9e7CQ%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
