[Emu] Implementation report for EAP-TLS 1.3: OK, with nits

[Alan DeKok <[e-mail]>]

  We've been doing interoperability testing of EAP-TLS 1.3, and have some comments.  The testing was made more difficult by issues in different software.  We've been using OpenSSL, FreeRADIUS, and wpa_supplicant.  In short, it mostly works, or it should work by the end of next week.  But you will likely have to use the most recent source from revision control.  Older versions of the software either don't support TLS 1.3, or have implementation issues which break interoperability.

  One major issue which isn't highlighted in the -03 draft is derived from RFC 5216 Section 2.3:

   MSK          = Key_Material(0,63)
   EMSK         = Key_Material(64,127)

   If an implementation does not use EMSK, then the temptation would be to ask for 63 octets, not 128.  This worked for TLS 1.2 and earlier.  It does not work in TLS 1.3.

  In TLS 1.3, the output text explicitly depends on the amount of data requested.  RFC 8446 Section 7.1 says:

       HKDF-Expand-Label(Secret, Label, Context, Length) =
            HKDF-Expand(Secret, HkdfLabel, Length)

  Which means that implementations cannot truncate the output by asking for less data.

  We've seen this in practice where a number of EAP types worked, but some didn't.  On working through the issues, the client software didn't use EMSK, and therefore only asked for 64 octets.  We're filing a bug with the implementors, but it's important enough that it should also be noted here.

  The -03 draft is correct, in that it has the lengths given as inputs to the KDF in Section 2.3:

   Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material", "", 128)
   IV           = TLS-Exporter("EXPORTER_EAP_TLS_IV", "", 64)
   Method-Id    = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id", "", 64)
   Session-Id   = 0x0D || Method-Id

  However, I think it's worth adding a note here for implementors.  Something like:

--
  We note that the key derivation MUST use the length values given above.  Where in TLS 1.2 and earlier it was possible to truncate the output by requesting less data from the TLS-Exporter function, this practice is not possible with TLS 1.3.  If an implementation intends to use only part of the output of the TLS-Exporter function, then it MUST ask for the full output, and then only use part of that output.  Failure to do so will result in incorrect values being calculated for the above keying material.
--

  Alan DeKok.