Forwarded this conversation from the TLS list.  The question is about
changing the key derivation.

Joe

---------- Forwarded message ---------
From: Joseph Salowey <j...@salowey.net>
Date: Tue, Jan 5, 2021 at 10:24 PM
Subject: Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on
draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
To: Alan DeKok <al...@deployingradius.com>
Cc: Mohit Sethi M <mohit.m.se...@ericsson.com>, EMU WG <emu@ietf.org>,
Benjamin Kaduk <ka...@mit.edu>, t...@ietf.org <t...@ietf.org>




On Tue, Jan 5, 2021 at 8:31 AM Alan DeKok <al...@deployingradius.com> wrote:

> On Jan 5, 2021, at 11:13 AM, Mohit Sethi M <mohit.m.se...@ericsson.com>
> wrote:
> >
> > Hi Alan,
> >
> > Cleaning up the email. The current draft says the exporter should be
> called once as:
> >
> >>    Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material",
> >>                                Type-Code, 128)
> >>
> > and then split the 128 into MSK (64) and EMSK (64). As said, from
> initial glance, it seems the exporter is called twice (once in
> eap_tls_get_emsk and once in eap_tls_getKey). Both the calls are with
> exactly the same context, context length, and labels. In getKey, the EMSK
> parts are cleared with
> >> os_memset(eapKeyData + EAP_TLS_KEY_LEN, 0, EAP_EMSK_LEN);
> > while in get_emsk, they are read with
> >
> >
> >>              os_memcpy(emsk, eapKeyData + EAP_TLS_KEY_LEN,
> >>
> >>
> >> EAP_EMSK_LEN);
> > Maybe we can live with this. But if exporter is called twice, we should
> use different labels as suggested by Martin?
>
>   Yes.
>
>   Perhaps as Joe suggested: EXPORTER_EAP_TLS_MSK and
> EXPORTER_EAP_TLS_EMSK, which seem simple enough.
>
> [Joe] I created a pull request (
https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/17)  with the
proposed labels.  Is this change going to cause significant problems for
implementation?


  Alan DeKok.
>
> _______________________________________________
> TLS mailing list
> t...@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Reply via email to