>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, thanks for pointing that out. Cisco also implements option number 1 from above. I referenced to EAP-FAST implementation by mistake, sorry. So, not to harm at least two implementations, all we can do for errata 5127, 5128 - is just to change the wording to be more clear, removing ambiguity. On Thu, Oct 22, 2020 at 7:58 PM Jorge Vergara <jover...@microsoft.com> wrote: > >[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> > 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" | 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 > > > > [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> 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%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
