On Jun 19, 2021, at 10:05 AM, John Mattsson
<[email protected]> wrote:
>
> 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.
> - “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
Yes.
> - “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.
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.
> - 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)
Yes. I'll remove those.
>
> - OLD “EAP servers peers MUST NOT”
> NEW “EAP 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”, “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”?
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".
> - List formatting
> “* EXPORTER: session key seed * EXPORTER: Inner Methods Compound Keys
> * EXPORTER: Session Key Generating Function * EXPORTER: Extended
> Session Key Generating Function * [email protected]”
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.
_______________________________________________
Emu mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/emu
