Subject: Re: [Emu] EAP-TLS key derivation resolution

From: Mohit Sethi M <[email-masked]>
Date: Mon, 1 Mar 2021 10:26:19 +0000

FYI: the latest update of wolfSSL (February 16, 2021) now claims to implement RFC 5705: Keying Material Exporters for TLS. See: https://github.com/wolfSSL/wolfssl/blob/ef916df1b1f9f9678fe7787e3b864a4b015fe569/README.md#wolfssl-release-470-february-16-2021

The TLS 1.3 exporter here: https://github.com/wolfSSL/wolfssl/blob/94a23c1d4891b750110c6b806181628bffe782cf/src/tls13.c#L763 allows context, but the exporter function defined separately for EAP-TLS does not allow context: https://github.com/wolfSSL/wolfssl/blob/f0ce6ada0fcf99a15b85ddac951e46376df96e4d/src/tls.c#L632. Anyhow, my initial concern that some popular TLS libraries don't support context may not be valid as implementations are updated. I'll check wolfssl more soon.

The reason for moving the Type-Code to the label was also based on Ben and Martin's comments. Ben's IESG review for example notes:

Section 2.3

The use of a constant 0x0D (the "Type-Code") as the TLS-Exporter context
is rather unusual; per RFC 8446 this value is intended to be a
"per-association context value provided by the application using the
exporter" per RFC 5705 -- this value is not a per-association value but
rather a global one.

--Mohit

On 2/28/21 12:58 PM, Alan DeKok wrote:

On Feb 27, 2021, at 7:10 PM, Joseph Salowey <[email-masked]><mailto:[email-masked]> 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-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/emu

---

From: Alan DeKok <[email-masked]>
Date: Mon, 1 Mar 2021 08:08:26 -0500

> FYI: the latest update of wolfSSL (February 16, 2021) now claims to implement RFC 5705: Keying Material Exporters for TLS. See: https://github.com/wolfSSL/wolfssl/blob/ef916df1b1f9f9678fe7787e3b864…

  That's good.
>> exporter" per RFC 5705 -- this value is not a per-association value but

  The issue is what can we use for "per-association context value".

  EAP runs over PPP, Ethernet, RADIUS, PANA, IKEv2, ...

  There is literally no per-association context value which can be used.  So our choices here are:

1) leave context empty, and have per-type key labels

2) use type-code as the context, and use a constant label across EAP types

  There appears to be consensus among implementors that (2) is preferred.

  Alan DeKok.