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)
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.
Cheers,
Martin
On Wed, Jan 6, 2021, at 17:24, Joseph Salowey wrote:
>
>
> On Tue, Jan 5, 2021 at 8:31 AM Alan DeKok <[email protected]> wrote:
> > On Jan 5, 2021, at 11:13 AM, Mohit Sethi M <[email protected]>
> > 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
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/tls
> _______________________________________________
> TLS mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/tls
>
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
