Hi Jorge, Thanks for joining the conversation.
On Wed, Oct 30, 2019 at 6:11 PM Jorge Vergara <jovergar= 40microsoft....@dmarc.ietf.org> wrote: > 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. > > [Joe] I know that Alan has been asking for help with this draft especially with TEAP and EAP-FAST. I hope that you and others can work with him to get the draft in a shape that we can progress through the working group. I agree that this is an important thing to do. The EAP-TLS 1.3 draft is fairly far along and I do not think we have consensus to add TEAP into the document at this point, but I think we can make faster progress on the TLS types document if we have people interested in working on it. > 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 >
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
