On Thu, Jan 7, 2021 at 2:42 PM Martin Thomson <m...@lowentropy.net> wrote:
> Hi Joe,
>
> Thanks for doing this, I think that this is a distinct improvement (and I
> will take your word for the difficulties involved with further splits).
>
> One point that I made poorly perhaps, and was dismissed, might be worth
> restating:
>
> MSK = TLS-Exporter("EXPORTER_EAP_TLS_MSK", Type-Code, 64)
>
>
[Joe] I think you propose something like this instead (eliminating context):
MSK = TLS-Exporter("EXPORTER_EAP_TLS_MSK-" + ASCII-Type-Code, 64)
Where + is concatenation and ASCII-Type-Code is "13"
the IANA section would explicitly list: EXPORTER_EAP_TLS_MSK-13
> The inclusion of a type code as context is, I believe, a misuse of the
> field. As this is a fixed value, the value is being used for domain
> separation. However, that is the function of the exporter label input.
> The label exists to establish that this is EAP-TLS and the key is (in this
> case) MSK. If you need different derivations for different type codes, I
> strongly suggest that this be included in the label.
>
> The Context input exists to pull in variables from the context that
> endpoints might need to agree on. It is not for domain separation. For
> example, if you thought it necessary to authenticate the Identity values
> that client and server exchange, you might add those to this field. (As an
> aside, you might want to consider that as their value could be used to
> determine what parameters to feed into the TLS handshake.)
>
> If, however, you have an adjacent usage of EAP that wants its own MSK,
> then that is domain separation. The right thing to do would be to create
> new labels for that usage.
>
> This might be a fine point in light of the fact that these all just get
> fed into HKDF, but I think that it is important to respect the purpose for
> which these inputs were designed.
>
>
[Joe] I see your point that we should eliminate the context and include the
type code in the label as it will always be the same for EAP-TLS (which
also goes to the point that has been made by several people that this value
may be redundant since we would expect another EAP type to use a different
label). In the past, people have used TLS in all sorts of innovative and
unique ways in different EAP methods all loosely based on EAP-TLS. I don't
see this usage as too far outside the intended use of the context field
(the value should match on both sides) and I think including the type value
in the context value would help avoid some potential implementation
problems if the key derivation is reused for another method.
Cheers,
> Martin
>
> On Wed, Jan 6, 2021, at 17:24, Joseph Salowey wrote:
> >
> >
> > 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
> > > TLS@ietf.org
> > > https://www.ietf.org/mailman/listinfo/tls
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> >
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
