Hello, On Tue, Sep 06, 2022 at 09:57:02PM -0700, Joseph Salowey wrote:
I think we need to have some review of the EAP-FAST and TEAP sections before publication. If we can't get the review then maybe we should remove those sections. Is someone willing to step up and review these sections of the draft, preferably who has implementation experience?
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. Section 2.2 - TEAP ------------------I do not think changing the language for the definition of the MAC used for the Compound MAC was necessary.
Looking at the reasoning behind the decision[1], I think RFC7170 section 5.3 is pretty clear already that "MAC is the MAC function negotiated in TLS 1.2 [RFC5246]" which I interpreted this as 'use cipher spec from Section 7' which covers the *handshake*.
When I was implementing TEAP I peeked at hostapd's guts and found a sizable lookup table which for OpenSSL users maps 1:1 to:
SSL_CIPHER_get_handshake_digest(SSL_get_current_cipher(const SSL *ssl))During my TLS 1.2 interop testing with Win11[2] everything looked happy and SHA386 was being used automagically.
A slight confession, I did originally use the MAC for encrypted records but when I started getting "no digest" it did nudge me to use the handshake digest; looks like Jorge Vergara picked up on this too, but not sure if anyone flagged both Windows and hostapd do this.
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?"
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()"?
Having a deep guru level of knowledge of RFC8446 should never be a prerequisite to implementing TEAP...or any standard.
Maybe I am the only one here who gets depressed when instructed to look at a TLS RFC to gain wisdom?
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.
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.
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.
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.
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. 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?
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".
Section 5 - Implementation Status ---------------------------------Again, only if it helps someone come off the fence, I can sprinkle these proposed changes for TEAP and EAP-FAST into hostapd[3] and FreeRADIUS?
Radiator also implements EAP-FAST so maybe we can get them onboard here too for that.
This though is under the shadow that you are up against a clock to get this published, I cannot guarantee when I could get his work done.
I do agree with Alan though. Something has to point the direction thatTEAP/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.
This document needs to be published with a TEAP and EAP-FAST statement. Thanks Alex [1] https://mailarchive.ietf.org/arch/msg/emu/PH7ua-4TgxR0pBuxxuZu-UAzMHk/ [2] https://gitlab.com/wireshark/wireshark/-/merge_requests/7945 for a TEAP Win11 .pcapng that is decodable with a development 4.x release of Wireshark [3] still waiting on some hostapd lovin' for my patch https://lists.infradead.org/pipermail/hostap/2022-July/040640.html [4] https://github.com/emu-wg/teap-errata/ _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
