Re: [Emu] EAP-TLS key derivation resolution

[Alan DeKok]

On Mar 1, 2021, at 5:26 AM, Mohit Sethi M  wrote:
> 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

  That's good.
> 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.

  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.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] EAP-TLS key derivation resolution

[Mohit Sethi M]

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 
 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 t