Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

Hi Jorge,

Thanks for joining the conversation.

On Wed, Oct 30, 2019 at 6:11 PM Jorge Vergara <jovergar=
40microsoft.com@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-bounces@ietf.org> On Behalf Of Alan DeKok
> Sent: Wednesday, October 30, 2019 4:12 AM
> To: Eliot Lear <lear@cisco.com>
> Cc: draft-ietf-emu-eap-tls13@ietf.org; John Mattsson <john.mattsson=
> 40ericsson.com@dmarc.ietf.org>; Michael Richardson <mcr@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 <lear@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&amp;data=02%7C01%7Cjovergar%40microsoft.com%7C68e3a65a1c3441c857cb08d75d2a038b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637080308161040037&amp;sdata=zrPr0rRh1bkV8rrF23SaAJYz6aFfuO3lTX9e6U1fOXw%3D&amp;reserved=0
> _______________________________________________
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>