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 <al...@deployingradius.com>
wrote:
> On Sep 10, 2022, at 3:59 AM, Alexander Clouter <alex+i...@coremem.com>
> 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
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
