Thanks Joe, one comment regarding item #16 is inline below. On Sun, May 16, 2021 at 9:52 PM Joseph Salowey <j...@salowey.net> wrote:
> Hi Oleg, > > thanks for the review, comments below: > > On Sun, May 16, 2021 at 1:55 AM Oleg Pekar <oleg.pekar.2...@gmail.com> > 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 >> >
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
