>Microsoft has already said that they won't rev their EAP-TLS implementation >until they can also rev PEAP.
PEAP/TTLS/TEAP - we (Microsoft) believe all should be addressed at the same time and will postpone TLS 1.3 support until such a time as we are able to make the updates together. >* should the document drop references to TEAP? > Given Jouni Malinen's comments on implementing TEAP, it may be worth simply > noting that we're waiting for a TEAP update document I've reviewed the current errata, and acknowledge their validity, but am not sure that any of them would impact this document. The most relevant errata to this document seems to be https://www.rfc-editor.org/errata/eid5770. As noted in the errata, the calculation of keys becomes confusing when methods export both MSK and EMSK because it is not clearly specified which value IMCK[j] should take on during the calculation of S-IMCK[j]. The addition of clarifying information is welcome, but I don't believe this ambiguity currently prevents a compliant implementation - for example, an implementation could avoid this ambiguity by choosing to use either the MSK/EMSK exclusively, and communicating that to the server via the Compound MAC TLV. The server can then make a policy decision on whether it is accepting of this decision by the client and follow suit, or reject the client. The specifics of resolving this particular errata is a digression from my main point - I believe a clarification can be added to the main TEAP document at a future time without impacting the contents of this document. Ambiguity about which IMCK to use in S-IMCK calculation should not impact the definition of the cryptographic calculations. On the document contents themselves, I have this review: The key derivation proposed for TEAP/FAST uses the definition from FAST, which is not identical to the TEAP derivation. Namely, FAST used MSK[j] in the derivation, but TEAP uses IMSK[j], which may be equivalent in some cases, but may not in others where the inner method exports an EMSK. Specifically, I believe this line of section 2.2 should change from IMCK[j] = TLS-Exporter("EXPORTER: Inner Methods Compound Keys", S-IMCK[j-1] | MSK[j], 60) To IMCK[j] = TLS-Exporter("EXPORTER: Inner Methods Compound Keys", S-IMCK[j-1] | IMSK[j], 60) For TEAP. Jorge -----Original Message----- From: Emu <emu-boun...@ietf.org> On Behalf Of Alan DeKok Sent: Friday, April 3, 2020 1:48 PM To: EMU WG <emu@ietf.org> Subject: [Emu] draft-dekok-emu-tls-eap-types discussion https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-dekok-emu-tls-eap-types-01&data=02%7C01%7Cjovergar%40microsoft.com%7C2c42095edc4e4cd61ce408d7d8106200%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637215437188744711&sdata=ndLp%2FSzsDlX%2FKYx0UR0uf77rHgCjGej4kdZPpywuD9Q%3D&reserved=0 I haven't seen much discussion on the document. There are still some open questions: * should it be published simultaneously with draft-ietf-emu-eap-tls13? If so, we need some consensus on this document, and quick. If not, when do we publish this draft? Microsoft has already said that they won't rev their EAP-TLS implementation until they can also rev PEAP. * Should the document simply drop references to FAST? It looks like the effort has moved to TEAP. Perhaps we should note that FAST cannot be used with TLS 1.3, and that TEAP should be used instead * should the document drop references to TEAP? Given Jouni Malinen's comments on implementing TEAP, it may be worth simply noting that we're waiting for a TEAP update document * Without FAST / TEAP, the document is about 4 pages of text. Is there anything controversial, missing, etc? * What are the barriers to adoption and publication? Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femu&data=02%7C01%7Cjovergar%40microsoft.com%7C2c42095edc4e4cd61ce408d7d8106200%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637215437188744711&sdata=lkoHzd0fgN4z1oalqV2jW9pewUGSnlRLeKpiFew4Yw8%3D&reserved=0 _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
