Hello - I am the primary maintainer of Microsoft's EAP implementation. I am sorry for joining late to this conversation, but hope our input is welcome.
On the topic of draft-dekok-emu-tls-eap-types: I agree that it is necessary to standardize other TLS based EAP methods at the same time as EAP-TLS. The alternatives if this doesn't happen were discussed here previously at https://mailarchive.ietf.org/arch/msg/emu/J9Afcza1gOBQ_jww8E0yxSKPYeo - namely, either implementations will forge ahead with non-standard updates anyways, or they will be forced to wait to update EAP-TLS until the other methods are updated. We are taking the second approach - we do not plan to update our EAP-TLS implementation until it is clear what the updates to other EAP methods will look like. We do not want to see non-standard vendor implementations to become difficult to implement de-facto standards. We would also like to see TEAP covered in this update. A brief review on the material contained in the draft-dekok-emu-tls-eap-types: I believe the 0x00 "Commitment message" not to send anymore TLS handshake data should be mentioned in this document, since it was established during https://mailarchive.ietf.org/arch/msg/emu/0MeocWZQLCv1pST5_2jW_ABlpMo that even tunnel based methods will need this. 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. I understand there may be a TEAP errata related to this and I may not be fully up to date on the errata discussion, so perhaps this is already taken into consideration. Jorge Vergara -----Original Message----- From: Emu <emu-boun...@ietf.org> On Behalf Of Alan DeKok Sent: Wednesday, October 30, 2019 4:12 AM To: Eliot Lear <l...@cisco.com> Cc: draft-ietf-emu-eap-tl...@ietf.org; John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org>; Michael Richardson <m...@sandelman.ca>; EMU WG <emu@ietf.org> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13 On Oct 30, 2019, at 5:02 AM, Eliot Lear <l...@cisco.com> wrote: > A fair argument, if it can be made, and I am not convinced it has been fully > expressed, is the idea that there is no context by which one can separate > fast restart and initial authentication. This is Alan’s concern. I’m not > saying it’s without merit, but what I cannot yet see is whether it is an > implementation or a protocol matter. I believe it's a protocol matter. In TLS 1.3, PSK handshakes are the same as resumption handshakes. It's not clear to me how this issue was addressed when using TLS 1.3 with HTTPS. But I do believe it's an issue there, too. As an additional note, I believe it's also important that draft-dekok-emu-tls-eap-types be published at the same time as the EAP-TLS document. The only unknown there is FAST and TEAP. I'm happy to remove them from the document. But at this point it's not even a WG document. There's not even consensus that the document necessary, which surprises me rather a lot. Because password-based EAP methods are *much* more wide-spread than EAP-TLS. If the IETF publishes EAP-TLS without simultaneously rev'ing TTLS and PEAP, it will not only look bad, it will *be* bad. And the industry press will (rightfully) lambast the standards process. 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%7C68e3a65a1c3441c857cb08d75d2a038b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637080308161040037&sdata=zrPr0rRh1bkV8rrF23SaAJYz6aFfuO3lTX9e6U1fOXw%3D&reserved=0 _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
