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
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu