(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
