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

[Alan DeKok <[e-mail]>]

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.