Subject: [Emu] Review of draft-ietf-emu-tls-eap-types-02

From: John Mattsson <[email-masked]>
Date: Sat, 19 Jun 2021 14:05:35 +0000

Hi Alan,

I reviewed draft-ietf-emu-tls-eap-types-02. Some minor comments:

- “The Type-Code is defined to be 1 octet for values smaller than 255.”

I think this should be “smaller than 254” as 0xFE = 254

- “Some implementations use the TLS "Finished" state as a signal that application data is now available.

As there is no formal “Finished” state, maybe better to write out that this happens after receiving and sending Finished messages (in any order). TLS 1.3 formally defines this state and calls it CONNECTED.

- The following five derivations were removed from draft-ietf-emu-eap-tls13. I assume draft-ietf-emu-tls-eap-types should do the same

IV           = TLS-Exporter("EXPORTER_EAP_TLS_IV", Type-Code, 64)

Enc-RECV-Key = MSK(0, 31)

      Enc-SEND-Key = MSK(32, 63)

      RECV-IV      = IV(0, 31)

      SEND-IV      = IV(32, 63)

- OLD “EAP servers peers MUST NOT”

  NEW “EAP peers MUST NOT”

- The document use “Type ID”, “Type code” and “Type-Code”. Likely one is enough. I also notice that RFC 3748 use Code for a different purpose, does not use ID, and talks about “EAP Type Values”, “Method Type Values”. Would it be a good idea to change both draft-ietf-emu-eap-tls13 and draft-ietf-emu-tls-eap-types to use the term “type value”?

- List formatting

  “* EXPORTER: session key seed * EXPORTER: Inner Methods Compound Keys

   * EXPORTER: Session Key Generating Function * EXPORTER: Extended

   Session Key Generating Function * [email-masked]”

- The draft mentions “commitment message” several times, but you are probably aware of that.

Cheers,
John

---

From: Alan DeKok <[email-masked]>
Date: Mon, 21 Jun 2021 07:55:30 -0400

> I reviewed draft-ietf-emu-tls-eap-types-02. Some minor comments:

  I'll revise this document based on the final scope of eap-tls13.  I had essentially dropped this document for a while, as there was little point in updating it to match eap-tls13, when that document wasn't finalized.  Now that there's consensus and code for eap-tls13, I'll pick up this document again.

  We have interoperability between hostap / wpa_supplicant and FreeRADIUS.  We have preliminary results for Microsoft, but TTLS and PEAP won't be enabled in the initial builds.
 
> I think this should be “smaller than 254” as 0xFE = 254

  Yes.

> As there is no formal “Finished” state, maybe better to write out that this happens after receiving and sending Finished messages (in any order). TLS 1.3 formally defines this state and calls it CO…

  Yeah, the OpenSSL API uses SSL_is_init_finished(), but that doesn't well to a particular TLS state.  I'll change this to:

Unlike previous TLS versions, TLS 1.3 can continue negotiation after
the initial TLS handshake has been completed, which TLS 1.3 calls
"CONNECTED".  Some implementations use that as a signal that TLS
negotiation has completed, and that an "inner tunnel" session can now
be negotiated.  This assumption is no longer correct for TLS 1.3.
 
>       Enc-SEND-Key = MSK(32, 63)

  Yes.  I'll remove those.
> - OLD “EAP servers peers MUST NOT”

  Fixed.
 
> - The document use “Type ID”, “Type code” and “Type-Code”. Likely one is enough. I also notice that RFC 3748 use Code for a different purpose, does not use ID, and talks about “EAP Type Values”, “M…

  I think so, yes.  RFC 3748 uses "Code" to refer to the EAP packet header (Success, Failure, etc.), and "Type" for the method type.  IANA uses "Method Types".  RFC 5216 also uses Type.

  I'll change this to "Type" in diagrams and other references, and make it clear in the document when we refer to the "type value".

>    Session Key Generating Function * [email-masked]”

  Fixed, thanks.

> - The draft mentions “commitment message” several times, but you are probably aware of that.

  Yes.  Now that eap-tls13 no longer uses that, I'll update this draft to be in agreement with it.

  Alan DeKok.