Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Eric Rescorla <[e-mail]>]

On Mon, Jan 4, 2021 at 6:08 AM Alan DeKok <[e-mail]> wrote:

> On Jan 3, 2021, at 10:44 PM, Martin Thomson <[e-mail]> wrote:
> > # Key Schedule
> >
> > The other thing I observe is the way that this slices up the exporter
> output.  This was something that old versions of TLS did, but TLS 1.3 did
> away with.  Though RFC 5216 did this, EAP-TLS for TLS 1.3 doesn't need to.
> This could - and should - do the same.  All it means is having more
> exporter labels.
>
>   That's easy enough to change at this state.  The question is what are
> those labels?
>

They're just strings, so as long as they don't conflict, it's largely up to
the EAP WG.

-Ekr

  The alternative is to dither around for another year or two, all the
> while relying on legacy TLS versions for 802.1X / WiFi authentication.
> i.e. packets which are trivially monitored by anyone with a WiFi card.
>
> > I appreciate that this uses exporters now rather than abusing the
> internal PRF.  That's good.  The next step is to dispense with the
> intermediate values (Key_Material, MSK, EMSK, IV) and all the slicing that
> occurs and use the TLS exporter for each of the six values that the
> protocol requires.  I also note that the 0x0D value is used multiple times,
> unnecessarily, both as a context strong to the exporter and as a prefix to
> the session ID.
>
>   If EAP-TLS was the only TLS-based EAP method, I would agree with you.
> But it's not.  Historically, each TLS-based EAP method uses it's own key
> derivations, using method-specific strings.  This practice made
> implementations more difficult and error-prone.
>
>   The use of 0x0D is to allow standard key derivations across TLS-based
> EAP methods.  The other methods replaced the 0x0D byte with their own EAP
> type value.  This practice greatly simplifies implementations.
>
>   See https://tools.ietf.org/html/draft-dekok-emu-tls-eap-types-00 for
> more information.
>
>   Alan DeKok.
>
> _______________________________________________
> Emu mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/emu
>