Re: [Emu] WG last call for draft-ietf-emu-tls-eap-types ?

[Joseph Salowey <[e-mail]>]

I also notice that the document header says it updates RFC 5247 instead of
RFC 4851.



On Tue, Sep 20, 2022 at 12:50 PM Alan DeKok <[e-mail]>
wrote:

> On Sep 10, 2022, at 3:59 AM, Alexander Clouter <[e-mail]>
> wrote:
> > I have both implemented EAP-FAST and TEAP, and also slogged through the
> interoperability testing of the TLS 1.3 changes proposed here for EAP-TTLS
> and PEAP.
> >
> > This probably qualifies me to chip in here.
>
>   Thanks.
>
> > Section 2.2 - TEAP
> > ------------------
> > I do not think changing the language for the definition of the MAC used
> for the Compound MAC was necessary.
>
>   I don't see if changing the definition that much,  There's just a
> reference to the previous section, which was changed.  That definition was
> just changed to use TLS-Exporter() instead of TLS-PRF().
>
>   Are there any other changes which need highlighting (or fixing) ?
>
> > If any wording changes need to be made, maybe to be more explicit in
> stating "the MAC from the handshake" or "cipher_suite from RFC8446 section
> 4.1.3"? I find the existing "section 7.1 of RFC 8446" wording unusable to
> someone trying to answer "what am I actually meant to do here?"
>
>   Do you have explicit text to suggest?
>
> > Maybe I am just dumb so someone can help join the dots for me, but as an
> implementer it is unclear to me how anyone could get from "look at RFC8446
> section 7.1" to "use SSL_CIPHER_get_handshake_digest()"?
>
>   Perhaps updating it to say:
>
> For TLS 1.3, the message authentication code (MAC) is computed with
> the HMAC algorithm negotiated for HKDF in the key schedule, as per
> section 7.1 of RFC 8446.  That is, the MAC used is the MAC derived
> from the TLS handshake.
>
>
> > Having a deep guru level of knowledge of RFC8446 should never be a
> prerequisite to implementing TEAP...or any standard.
>
>   Agreed.
>
> > Maybe I am the only one here who gets depressed when instructed to look
> at a TLS RFC to gain wisdom?
>
>   I'l take the fifth here.
>
> > Section 2.2.1 - Client Certificates [TEAP]
> > ------------------------------------------
> > I think we should remove the unnecessary additional SSL handshake, as
> three full handshakes is getting excessive and life is too short for
> multi-second WAN authentications.
>
>   I agree that the layered TLS sessions are less than optimal.
>
> > On a practical note for this type of chained authentication we are
> already at the ~25 mark of the default limit of 50 EAP round trips that
> some EAP implementations (eg. hostapd and FreeRADIUS) set as the threshold
> of "things are now getting silly" and abort the conversion. This may thwart
> chaining future EAP methods.
>
>   Agreed.
>
> > Picking though our options, whilst Identity-Type TLV is needed to
> provide the EAP server on what is being authenticated, this TLV is also
> permitted as an outer-TLV in RFC7170 section 4.3.1.
> >
> > RFC7170 being an RFC that relishes in contradiction, section 4.2.3
> states this TLV MUST be passed alongside either an EAP-Payload or
> Basic-Password-Auth-{Req,Resp} which themselves are only permitted as
> inner-TLVs.
> >
> > Fortunately section 4.3.1 also states outer-TLVs MUST be marked optional
> which I see as the way to break out of this situation.
> >
> > I would propose allowing an Identity-Type outer-TLV during Phase 1 to
> provide the necessary hinting to support machine/user authentication.
>
>   That seems fine.  I'll update the section to say:
>
> However, an implementation may send Identity-Type as an outer-TLV, in
> which case a client certificate can be sent in Phase 1, and that
> client certificate MUST be associated with the referenced
> Identity-Type.
>
>
> > Only if it would help some people on the fence land a decision, I am
> willing to do some interoperability testing to verify that sending
> outer-TLVs in this manner does not cause any unintended consequences? If
> you are that person, let me know.
>
>   I don't see a problem with it.
>
> > Section 2.3 - EAP-FAST
> > ----------------------
> > I think you should be explicit that an implementer should now only look
> to session tickets for their PAC provisioning needs.
> >
> > Maybe something more like:
> >
> >  EAP-FAST previously used a PAC, which is functionally equivalent to
> >  session tickets provided by TLS 1.3 that contain a pre-shared key (PSK)
> >  along with other data. As such, the use of a PAC is deprecated for
> >  EAP-FAST in TLS 1.3. PAC provisioning [RFC5422] is also no longer part
> >  of EAP-FAST when TLS 1.3 is used.
>
>   Updated, thanks.  I'll add similar text for TEAP.
>
> > Section 2.4 - EAP-TTLS
> > ----------------------
> > I know that it is trying to communicate context is empty but it still
> looks like a typo, maybe instead:
> >
> >  EAP-TTLS_challenge = TLS-Exporter("ttls challenge", {}, n)
> >
> > Then highlight 'context={}' means 'empty'/'zero length' as per RFC8446
> Section 7.5?
>
>   The other EAP RFCs just use an empty context, and not {}.  So I'm OK
> with leaving that alone.
>
> > Section 2.[45].1 - Client Certificates [EAP-TTLS/PEAP]
> > ------------------------------------------
> > I would like to see the "just use EAP-TLS" and "abort when no inner
> methods" replicated in the sections covering TEAP and EAP-FAST too.
> >
> > Alternatively broken out into its own section which I think it deserves
> to highlight "this is pointless folks, we have EAP-TLS for this".
>
>   I'll add text to TEAP and FAST.  That seem simplest.
>
> > I do agree with Alan though. Something has to point the direction that
> > TEAP/EAP-FAST needs to go in for TLS 1.3 and any inaccuracies can be
> resolved through Errata.
> >
> > The inaccuracies in the RFC7170 and the stalled errata efforts[4] for
> TEAP has not prevented hostapd, Windows 11 and FreeRADIUS interoperating.
>
>   That's good news.
>
> > This document needs to be published with a TEAP and EAP-FAST statement.
>
>   Thanks.
>
>   I've updated the document, and will issue a new I-D shortly.
>
>   Alan DeKok.
>
> _______________________________________________
> Emu mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/emu
>