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 

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 mailing list

Reply via email to