[Emu] EAP-TLS 1.3 - few more comments

[Oleg Pekar <[e-mail]>]

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

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

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?

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

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.

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

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.

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

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?

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

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

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

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"?

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

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).

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

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.


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

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.

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

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.

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

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

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

Regards,
Oleg