Subject: Re: [Emu] EAP-TLS 1.3 - few more comments

From: John Mattsson <[email-masked]>
Date: Tue, 8 Jun 2021 13:10:08 +0000

Hi,

I implemented the suggestions below in the following PR. Some of the editorial changes was merged directly to master.
https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/78

I have also implemented all the thing in issue #58 (Alans review) in a PR
https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues/58
https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/71

The PRs that Joe has approved has been merged into the master branch.

I will go through the mailing list soon and see if there are more comments on the draft.

John

From: Emu <[email-masked]> on behalf of Oleg Pekar <[email-masked]>
Date: Monday, 17 May 2021 at 16:25
To: Joseph Salowey <[email-masked]>
Cc: EMU WG <[email-masked]>
Subject: Re: [Emu] EAP-TLS 1.3 - few more comments
Thanks Joe, one comment regarding item #16 is inline below.

On Sun, May 16, 2021 at 9:52 PM Joseph Salowey <[email-masked]<mailto:[email-masked]>> wrote:
Hi Oleg,

thanks for the review, comments below:

On Sun, May 16, 2021 at 1:55 AM Oleg Pekar <[email-masked]<mailto:[email-masked]>> wrote:
Hi, few more comments on the draft #15 https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/15/:

1)

2.1.1.  Authentication

The full handshake in EAP-TLS with TLS 1.3 always
   provide forward secrecy by exchange of ephemeral "key_share"
   extensions in the ClientHello and ServerHello (e.g. containing
   ephemeral ECDHE public keys).

—- comment:
should say “provides”

—————————————————————

2)

2.1.1.  Authentication

After the EAP-TLS server has received an
   empty EAP-Response to the EAP-Request containing the TLS application
   data 0x00, the EAP-TLS server sends EAP-Success.

-- comment:
the phrase “empty EAP-Response” may be confusing. EAP-TLS RFC [RFC 5216] calls such messages as "EAP-Response packet of EAP-Type=EAP-TLS and no data" (Section 2.1.3. Termination, 2.1.5.  Fragmentation). Suggest continue using the old RFC terminology since Figure 1 preserves the same messages names.

—————————————————————

3)

2.1.1.  Authentication

Figure 1: EAP-TLS mutual authentication

-- comment:
"TLS Application Data 0x00)" lacks opening round bracket

—————————————————————

4)

2.1.2.  Ticket Establishment

Figure 2: EAP-TLS ticket establishment

-- comment:
"TLS Application Data 0x00)" lacks opening round bracket

—————————————————————

5)

2.1.3.  Resumption

Figure 3: EAP-TLS resumption

-- comment:
"TLS Application Data 0x00)" lacks opening round bracket

—————————————————————

[Joe] Authors, please address the above nits.

6)

2.1.3.  Resumption

Providing a
   "key_share" and using the "psk_dhe_ke" pre-shared key exchange mode
   is also important in order to limit the impact of a key compromise.
   When using "psk_dhe_ke", TLS 1.3 provides forward secrecy meaning
   that key leakage does not compromise any earlier connections.  It is
   RECOMMMENDED to use "psk_dhe_ke" for resumption.

-- comment:
The recommendation may be interpreted ambiguously. Is it recommended to TLS server to reject EAP-TLS session resumption from EAP-TLS peer and fallback to full handshake when there's no "psk_dhe_ke" extension?

[Joe] SHOULD and RECOMMENDED are a bit ambiguous.  Perhaps this can be replaced by something better:

"psk_dh_ke" MUST be used for resumption unless the deployment has a local requirement to allow configuration of other mechanisms."

—————————————————————

7)

2.1.4.  Termination

In TLS 1.3 [RFC8446], error alerts are not mandatory to send after a
   fatal error condition.  Failure to send TLS Error alerts means that
   the peer or server would have no way of determining what went wrong.
   EAP-TLS 1.3 strengthen this requirement.  Whenever an implementation
   encounters a fatal error condition, it MUST send an appropriate TLS
   Error alert.

-- comment:
It there a way to enforce sending TLS Error alert? Since the conversation is probably failed anyway after the case that requires sending TLS Error alert - there is no real feasible enforcement to be specified. I remember a lot of suffering due to EAP-TLS peers just broke connection with no indication of what was wrong, so admins cannot really reveal the cure for the failed authentication.

[Joe] This section does say that TLS error alerts MUST be sent.  Are you looking for something else?

—————————————————————

8)

2.1.4.  Termination

Figure 6 shows an example message flow where the EAP-TLS server
   authenticates to the EAP-TLS peer successfully, but the EAP-TLS peer
   fails to authenticate to the EAP-TLS server and sends a TLS Error
   alert.

-- comment:
"the EAP-TLS peer fails to authenticate to the EAP-TLS server and sends a TLS Error" - there's an impression from this text that EAP-TLS peers sends a TLS error. However it is EAP-TLS server that does it. Should be clarified. Example of suggestion:

Figure 6 shows an example message flow where the EAP-TLS server
   authenticates to the EAP-TLS peer successfully, but the EAP-TLS peer
   fails to authenticate to the EAP-TLS server and the server sends a TLS Error
   alert.

[Joe] Authors please reword this text to be less ambiguous.

—————————————————————

9)

2.1.5.  No Peer Authentication

-- comment:
Can "TLS CertificateRequest" message still be sent by EAP-TLS server? Should EAP-TLS peer silently discard it or reject the connection in case it is sent but EAP-TLS peer doesn't own a credentials to authenticate?

[Joe] I think this is covered by TLS behavior.  I don't think we need to describe it further here.  The peer includes the certificate or not according to its policy and the server applies it policy accordingly.

—————————————————————

10)

2.1.5.  No Peer Authentication

Figure 7: EAP-TLS without peer authentication

-- comment:
"TLS Application Data 0x00)" lacks opening round bracket

—————————————————————

11)

2.1.6.  Hello Retry Request

Figure 8: EAP-TLS with Hello Retry Request

-- comment:
"TLS Application Data 0x00)" lacks opening round bracket

[Joe] authors please address these nits.

—————————————————————

12)

2.2.  Identity Verification

EAP peer implementations SHOULD
   allow users to configuring a unique trust root (CA certificate) and a
   server name to authenticate the server certificate and match the
   subjectAlternativeName (SAN) extension in the server certificate with
   the configured server name.

-- comment:
What is the configured server name? Do the supplicants that play EAP-TLS peer role usually have such configuration?

—————————————————————

13)

2.2.  Identity Verification

If
   server name matching is not used, then peers may end up trusting
   servers for EAP authentication that are not intended to be EAP
   servers for the network.

--comment:
What is meant by "EAP server for the network"?

[Joe] Please see the separate thread on this section 2.2. I'd rather have the discussion there.

—————————————————————

14)

2.4.  Parameter Negotiation and Compliance Requirements

While EAP-TLS does not protect any application data except for the
   Commitment Message, the negotiated cipher suites and algorithms MAY
   be used to secure data as done in other TLS-based EAP methods.

-- comment:
The term "Commitment Message" has never been introduced before in the document so it is confusing to see it in the middle section. However this term was used in the previous versions of the draft (last time in version #13).

[Joe] Authors please address this nit.

—————————————————————

15)

5.6.  Authorization

This information can include, but
   is not limited to, information about the authenticator, information
   about the EAP-TLS peer, or information about the protocol layers
   above or below EAP ( port numbers, WiFi
   SSID, etc.).

-- comment:
Suggest adding "...port numbers, SSID and the data previously collected for the EAP-TLS peer". This way we can mention including the data collected via MDM, Posture Validation and other Network Access Control management services into making authorization decision.

[Joe] This list is not meant to be exhaustive.

—————————————————————

16)

5.7.  Resumption

 As suggested in [RFC8446], EAP-TLS peers MUST NOT store resumption
   PSKs or tickets (and associated cached data) for longer than 7 days,
   regardless of the PSK or ticket lifetime.

-- comment:
This sentence repeats exactly the sentence in "2.1.2. Ticket Establishment", just without mentioning the number of seconds in 7 days, suggest removing it.

Reference to the previous occurrence in "2.1.2. Ticket Establishment":
Note that TLS 1.3
   [RFC8446] limits the ticket lifetime to a maximum of 604800 seconds
   (7 days) and EAP-TLS servers MUST respect this upper limit when
   issuing tickets.

[Joe] THese two sections are actually slightly different.  One is from the server point of view and the other is from the client point of view.  Perhaps both of these should be left to the TLS spec.

[Oleg] Got it. Then maybe it is worth specifying 604800 seconds in the section "5.7.  Resumption" also so it will be clear that the requirement in this section is the same strict as in "2.1.2. Ticket Establishment".

—————————————————————

17)

5.4.  Certificate Revocation

It is RECOMMENDED that EAP-TLS peers
   and EAP-TLS servers use OCSP stapling for verifying the status of the
   EAP-TLS server's certificate chain.

-- comment:
Suggest mentioning OCSP Stapling RFC 6961 here.

[Joe]  TLS 1.3 deprecates RFC 6961

—————————————————————

18)

6.1.  Normative References

-- comment:
Suggest adding OCSP Stapling RFC to the list of references:

[RFC6961] The Transport Layer Security (TLS) Multiple Certificate Status Request Extension

[Joe]  TLS 1.3 deprecates RFC 6961

—————————————————————
Regards,
Oleg