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" | 0x00 | 0x00 | 0x40) Joe's proposal: P_hash(EMSK, "teapbind...@ietf.org" | 0x00 | 0x00 | 0x40), the same, just the API correction Unified KDF proposal: TEAP-PRF(EMSK, "teapbind...@ietf.org", <no optional data>, 64) = P_hash(EMSK, "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 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 Jorge, please correct me if I misinterpret the Microsoft implementation. On Thu, Oct 22, 2020 at 6:55 PM Joseph Salowey <j...@salowey.net> wrote: > > > On Thu, Oct 22, 2020 at 6:59 AM Oleg Pekar <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", 64) = >> TLS-PRF(EMSK, "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> wrote: >> >>> (I accidentally dropped this list from the conversation) >>> >>> On Wed, Oct 21, 2020 at 4:48 PM Jorge Vergara <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> >>>> *Sent:* Wednesday, October 21, 2020 4:36 PM >>>> *To:* Jorge Vergara <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> >>>> 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> >>>> *Sent:* Wednesday, October 21, 2020 2:34 PM >>>> *To:* EMU WG <emu@ietf.org>; Jouni Malinen <j...@w1.fi>; Jorge Vergara < >>>> jover...@microsoft.com>; Oleg Pekar (olpekar) <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%7C38c27add2cb64a06310108d8761a22d3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637389201909062787%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=XudZt9FPh4jOBFQj01SQysnhX4p7G%2BflW2Pn2yIaJRM%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
