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
