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

From: John Mattsson <[email-masked]>
Date: Mon, 28 Jan 2019 14:58:33 +0000

Hi Alan,

Great news that you have done interoperability testing of EAP-TLS 1.3 and that you have not found any major issues.

I think it is very good to inform implementors about the use of the length values to ensure combability. I have added your suggested text to the GitHub.

https://github.com/emu-wg/draft-ietf-emu-eap-tls13

Cheers,
John

---

From: Alan DeKok <[email-masked]>
Date: Mon, 28 Jan 2019 10:36:25 -0500

> I think it is very good to inform implementors about the use of the length values to ensure combability. I have added your suggested text to the GitHub.

  Thanks.

  Another note is Section 2.3, which says:

   All other parameters such as MSK and EMSK are derived as specified in
   EAP-TLS [RFC5216], Section 2.3.  

  While I understand what is intended, that reference can be confusing.  To recap, the calculations referenced are:

   Key_Material = TLS-PRF-128(master_secret, "client EAP encryption",
                     client.random || server.random)
   MSK          = Key_Material(0,63)
   EMSK         = Key_Material(64,127)

  Where TLS-PRF-128 depends on the master secret, client random and server random.  This seems to contradict the previous paragraph in this draft, which says:

   By using the TLS exporter, EAP-TLS can use any TLS 1.3 implementation
   without having to extract the Master Secret, ClientHello.random, and
   ServerHello.random in a non-standard way.

  The issue here is not the derivation of MSK and ESK from Key_Material, but the implication that the Key_Material for MSK and EMSK is *different* than the Key_Material define in this draft.

  I suggest removing the sentence in this draft that references RFC 5216, and replacing it with text that says:

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

  It's not any more text, and it removes a potential confusion.

  Alan DeKok.