Hi Ben, Thanks for the usual detailed feedback. I haven't yet addressed all the comments in your COMMENT section. Below, I copy the comments which have now been addressed in github: https://github.com/emu-wg/draft-ietf-emu-eap-tls13/commit/901a28578c65b8b483eecf6394cfc218b3d02f2b
> Using BCP195 as the slug is probably preferred, since any RFCs > associated with the BCP are going to be relevant and topical Done! I think. Not sure if this is the right way to do it : <xref target="RFC7525">BCP 195</xref>? > Section 5.9 > > Pervasive monitoring refers to widespread surveillance of users. In > the context EAP-TLS, pervasive monitoring attacks can target EAP-TLS > > nit: "context of" Fixed. Also reported by Erik Kline! > static RSA based cipher suites without privacy. This implies that an > EAP-TLS peer SHOULD NOT continue the handshake if a TLS 1.2 EAP-TLS > server responds to an empty certificate message with a TLS alert > message. > > Just to check my understanding, this "response" would be an EAP-TLS > response containing a new ClientHello (that would proceed to do a > handshake including the client certificate in the unprotected initial > handshake)? That is, it would be a response at the EAP layer but not at > the TLS layer. In EAP, servers send EAP-Request and peer send EAP-Response. I changed the text somewhat. It now reads "Therefore, it is RECOMMENDED for EAP-TLS peers to not use EAP-TLS with TLS 1.2 and static RSA based cipher suites without privacy. This implies that an EAP-TLS peer SHOULD NOT continue the handshake if a TLS 1.2 EAP-TLS server sends an EAP-TLS/Request with a TLS alert message in response to an empty certificate message from the peer." Other suggestions to improve are welcome. > and only using the pseudo-random usernames a single time. Note that > the privacy-friendly usernames also MUST NOT include substrings that > can be used to relate the identity to a specific user. Similarly, > privacy-friendly username SHOULD NOT be formed by a fixed mapping > that stays the same across multiple different authentications. > > I think that violating the SHOULD NOT would intrinsically violate the > preceding MUST NOT ... so should they both be MUST NOTs Changed to MUST NOT. > Section 5.8 > > Tracking of users by eavesdropping on identity responses or > certificates is a well-known problem in many EAP methods. When EAP- > TLS is used with TLS 1.3, all certificates are encrypted, and the > username part of the identity response is always confidentiality > protected (e.g. using anonymous NAIs). [...] > > As written this applies to server certificates as well as TLS client > certificates. For which the statement is technically true, but with the > caveat that it is typically easy to persuade the server to (re-)send > those same certificates encrypted to a key known to the attacker, so the > protection provided by the encryption is limited. (The server has been > fairly strongly authenticated by the time the EAP peer makes the > decision to send its certificate, so there the reverse situation is > different.) Added a sentence to note this: "When EAP-TLS is used with TLS 1.3, all certificates are encrypted, and the username part of the identity response is always confidentiality protected (e.g., using anonymous NAIs). Note that even though all certificates are encrypted, the server's identity is only protected against passive attackers while client's identity is protected against both passive and active attackers. As with other EAP methods, even when privacy-friendly identifiers or EAP tunneling is used, the domain name (i.e., the realm) in the NAI is still typically visible." > Section 4.2.11, 8.1, and 8.2 of [RFC8446] provides security > considerations for resumption. > > I'm curious why specifically § 8.1 and 8.2 were selected, given that §8 > as a whole is about "0-RTT and Anti-Replay", which is a more specific > topic than just resumption. Updated to section 2.2 and 4.2.11 of RFC 8446. > Where a good decision is unclear, EAP-TLS servers SHOULD reject the > resumption. > > I suggest "reject the assumption and continue with a full handshake". Makes sense. Done! > If any authorization, accounting, or policy decisions were made with > information that have changed between the initial full handshake and > resumption, and if change may lead to a different decision, such > decisions MUST be reevaluated. It is RECOMMENDED that authorization, > accounting, and policy decisions are reevaluated based on the > information given in the resumption. [...] > > I'm not sure I understand how these two sentences fit together. Is it > trying to say that "if there could be a different decision, you > definitly have to re-check, and we recommend just always re-checking > since that's timpler"? Yes. > Section 5.7 > > and the authorizations of the other party may have been reduced. If > the cached revocation is not sufficiently current, the EAP-TLS peer > or EAP-TLS server MAY force a full TLS handshake. > > nit: s/cached revocation/cached revocation data/ > > in the certificate chain has been revoked or has expired. In all > such cases, resumption results in a full TLS handshake instead. > > nit: s/resumption results/an attempt at resumption results/ (or similar) Fixed. > Section 5.5 > > It seems like there may be some scope for improvements on the RFC 5216 > behavior here. For example, what if we used the EAP Type field as the > TLS Exporter 'context' argument, instead of the literal 0x0D? That > seems like it would prevent the modification from successfully causing a > different TLS-based EAP method to be used, by using a different > key-derivation formula, exactly as postulated by RFC 5126. 0x0D is the EAP type for EAP-TLS: https://www.iana.org/assignments/eap-numbers/eap-numbers.xhtml#eap-numbers-4 > To enable revocation checking in situations where EAP-TLS peers do > not implement or use OCSP stapling, and where network connectivity is > not available prior to authentication completion, EAP--TLS peer > implementations MUST also support checking for certificate revocation > after authentication completes and network connectivity is available, > and they SHOULD utilize this capability by default. > > If it's RECOMMENDED to use OCSP stapling, what does it mean that they > "SHOULD utilize this capability by default" (as well)? > > (Also, nit: only one '-' in EAP-TLS.) Fixed the nit. This text was based on RFC 5216 which says " MUST also support checking for certificate revocation after authentication completes and network connectivity is available, and they SHOULD utilize this capability by default.". I have now tried to reformulate as "To enable revocation checking in situations where EAP-TLS peers do not implement or use OCSP stapling, and where network connectivity is not available prior to authentication completion, EAP-TLS peer implementations MUST also support checking for certificate revocation after authentication completes and network connectivity is available, and peers SHOULD utilize this in the absence of other revocation checking mechanisms.". Other suggestions are welcome. > TLS, see Section 4.4.2.1 of [RFC8446]. In TLS 1.3 the OCSP > information is carried in the CertificateEntry containing the > associated certificate instead of a separate CertificateStatus > message as in [RFC4366]. This enables sending OCSP information for > > RFC 4366 seems like a stale (obsolete) reference, and RFC 6066 should be > preferred. (RFC 4366 would then become an unused reference, I believe.) Thanks. Fixed. > [3] Key strength: TLS 1.3 forbids all algorithms with known > weaknesses including 3DES, CBC mode, RC4, SHA-1, and MD5. TLS 1.3 > > Where does RFC 8446 forbid 3DES? CBC is forbidden by the requirement to > be AEAD, and RC4 and MD5 are explicitly forbidden, but the situation for > SHA-1 is more subtle. Please reword this sentence to be accurate. Updated to: "TLS 1.3 forbids algorithms such as RC4 and MD5 which have known weaknesses." > Section 5.1 > > [2] Confidentiality: The TLS 1.3 handshake offers much better > confidentiality than earlier versions of TLS by mandating cipher > suites with confidentiality and encrypting certificates and some of > the extensions, see [RFC8446]. When using EAP-TLS with TLS 1.3, the > > I note that there exist codepoints for TLS 1.3 ciphersuites that do not > provide confidentiality protection. Please point to the part of RFC > 8446 that mandates this behavior. The text now says "The TLS 1.3 handshake offers much better confidentiality than earlier versions of TLS. The mandatory to implement cipher suites of [RFC8446] ensure confidentiality. TLS 1.3 also encrypts certificates and some of the extensions. When using EAP-TLS with TLS 1.3, the use of privacy is mandatory and does not cause any additional round-trips." > username in cleartext in the Identity Response. Following [RFC7542], > it is RECOMMENDED to omit the username (i.e. the NAI is @realm), but > other constructions such as a fixed username (e.g. anonymous@realm) > or an encrypted username (e.g. YmVuZGVy@realm) are allowed. Note > > (I note that YmVuZGVy is just base64("bender"); does that really count > as "encrypted"?) Updated to xCZINCPTK5+7y81CrSYbPg+RKPE3OTrYLn4AQc4AC2U=@realm. > Section 2.1.6 > > the handshake. One use case is if the EAP-TLS server does not > support the groups in the "key_share" extension, but supports one of > > I'd consider adding a parenthetical "(or there is no "key_share" > extension)". Done. --Mohit _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
