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

On Mon, Jan 4, 2021 at 6:08 AM Alan DeKok <aland@deployingradius.com> wrote:

> On Jan 3, 2021, at 10:44 PM, Martin Thomson <mt@lowentropy.net> 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?

  And, we're getting very close to needing an implementation soon.  RFC
> 8446 is over two years old.  Web services have started serious migration to
> TLS 1.3.  But we still don't even have a standard for EAP.  I suggest that
> this is an issue.
>
>   At this point, we have inter-operability of TLS 1.3 for EAP-TLS, with
> the major EAP peer / server implementations.  This code is alpha, and not
> in any major release.  But we need to decide fairly soon what we're doing,
> as testing and releases take time.
>
>   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.
>

[Joe] It may be worth having separate exporter tags for EMSK and MSK.
(EXPORTER_EAP_TLS_MSK
and EXPORTER_EAP_TLS_EMSK).   I believe current applications define the use
EAP key material based on the MSK or EMSK.   The mechanism for splitting
the MSK into Enc-RECV-Key and Enc-SNED-Key I believe is only used in
specific legacy cases (WEP, MPPE?) and may still be the radius attributes
used in some deployments, so I don't think we should alter that
derivation.   I'm not sure where the IV is used, but I don't think
splitting it up more will be helpful.

>
>   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
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>