> On Feb 27, 2021, at 7:10 PM, Joseph Salowey <[email protected]> wrote:
>
> The current draft test specifies the following for key derivation:
> Type-Code = 0x0D
> MSK = TLS-Exporter("EXPORTER_EAP_TLS_MSK_"+Type-Code,
> "",64)
> EMSK = TLS-Exporter("EXPORTER_EAP_TLS_EMSK_"+Type-Code,
> "",64)
> Method-Id = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id_"+Type-Code,
> "",64)
> Session-Id = Type-Code || Method-Id
>
> A zero-length context (indicated by "") is used in the TLS exporter
> interface. The EAP-TLS Type-Code of '0D' (in hexadecimal) is
> appended to the label strings. Other TLS based EAP methods can use
> exporters in a similar fashion by replacing the EAP-TLS Type-Code
> with their own Type-Code (encoded as a hexadecimal string).
Unless I'm greatly mistaken, the WG already has a draft which updates other
TLS-based EAP types. Text about other EAP types does not belong in a document
which updates EAP-TLS.
If this document should not give advice about TLS internals, then it should
not give advice about other TLS methods.
The text referring to other EAP types should be removed.
> The main alternative proposals are to 1) include identity information in the
> context and 2) include the type code in the context instead of the label.
> 1) has not received support from the working group
> 2) is a viable alternative, but it really isn't in the spirit of the context.
>
RFC 8446 Section 7.5 is entirely silent on the subject of what context is
for. It refers instead to RFC 5705, which has this to say in Section 4:
3. Binding to Application Contexts
In addition to using an exporter to obtain keying material, an
application using the keying material has to securely establish the
upper-layer context where the keying material will be used. The
details of this context depend on the application, but it could
include things such as algorithms and parameters that will be used
with the keys, identifier(s) for the endpoint(s) who will use the
keys, identifier(s) for the session(s) where the keys will be used,
and the lifetime(s) for the context and/or keys.
The EAP type code is well within the definition of "algorithms and parameters
that will be used with the keys". RFC 5705 continues to describe the context
as:
o Information about the upper-layer context can be included in the
optional data after the exporter label (see Section 4).
And Section 4 says:
The context value allows the application using the exporter to mix
its own data with the TLS PRF for the exporter output. One example
of where this might be useful is an authentication setting where the
client credentials are valid for more than one identity; the context
value could then be used to mix the expected identity into the keying
material, thus preventing substitution attacks.
Using an identity in the context might be useful, except that it is very
difficult to define which identity is used. Certificates have multiple fields
which could be used, not all fields are required, and many fields can have
multiple values.
From a practical point of view, it is nearly impossible to include identity
information in the context in an inter-operable manner.
It doesn't seem to make sense to leave the context blank, and instead
shoe-horn more data into the label field. We have the context, nothing else
can go there, using the EAP type-code follows RFC 5705, so why not use it?
> The proposed resolution is to use the type-code in the label as defined above
> and in draft-14. Please comment on this thread if you disagree.
Mixing the type-code in the label is more complex to implement than simply
using it in the context. As such, I prefer to use it in the context.
Such use falls well within the examples given in RFC 5705.
Alan DeKok.
_______________________________________________
Emu mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/emu
