Subject: [Emu] EAP-TLS key derivation resolution

From: Joseph Salowey <[email-masked]>
Date: Sat, 27 Feb 2021 16:10:26 -0800

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).

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.

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.

Cheers,

Joe

---

From: Alan DeKok <[email-masked]>
Date: Sun, 28 Feb 2021 05:58:31 -0500

> On Feb 27, 2021, at 7:10 PM, Joseph Salowey <[email-masked]> wrote:
> 

  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.

  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.