On Fri, Jan 01, 2021 at 05:03:45PM +0000, Mohit Sethi M wrote: > 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>?
The RFC Editor will help out on this one. > > 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. Even that seems to help a lot. > > 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. Ah, that makes more sense than my initial "as well" reaction. Thanks! > > 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. Much more random :) Thanks, the rest of this all sounds good. -Ben > > 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
