Re: [Emu] Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

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
>