Re: [Emu] Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
Hi Alan, I'll try to stick to the stuff that hasn't already progressed more in the downthread discussions. On Wed, Dec 16, 2020 at 07:23:45PM -0500, Alan DeKok wrote: > On Dec 16, 2020, at 5:36 PM, Benjamin Kaduk via Datatracker > wrote: > > To start with the easy one: currently the way in which the structure of > > the Commitment Message is described makes reference to many fields of > > TLS Record Layer structures in order to specify what is fundamentally a > > message on the TLS Application Data stream. This is a layering > > violation; I don't see any reason to say more than what was suggested in > > https://mailarchive.ietf.org/arch/msg/emu/ECgvnq-C_VVXT5bpvOowte8LBjw/ : > > I will wave a magic wand of "implementation issues". :( You can only get away with that if you are clear about what properties you actually need, though. I think we've been making good progress at drilling down into that, so far, so let's keep it up. > There appears to be few ways to *explicitly* signal that negotiation has > completed. i.e. ways which are both implemented in SSL libraries, and > available to EAP-TLS implementations. > > We implemented multiple ways in FreeRADIUS (0 octet of application data and > other methods). I'll have to double-check the list archive. But my > recollection is that the "0x00" of application data was the least ugly > alternative. > > > Next, the whole reason for the existence of a Commitment Message seems > > under-justified -- the only mention I could find in the document is that > > it serves "to decrease the uncertainty for the EAP-TLS peer". What harm > > would be caused by a lack of certainty in this area? Why does waiting > > for an EAP-Success or EAP-Failure not provide a similar level of > > certainty? > > The EAP-Success and EAP-Failure messages are *not* protected. i.e. they > are 4-bytes of data which can be spoofed rather trivially. > > In contrast, the 0 byte is an application-layer signal that EAP-TLS has > succeeded. > > > The commitment message as specified seems to itself be a layering > > violation. The TLS protocol itself consists of a few sub-protocols, > > e.g., the handshake protocol, record protocol, and alert protocol. The > > operation of the handshake protocol is supposed to be completely > > independent of the application-data record protocol (except to the > > extent that the handshake protocol supplies the keys used for > > cryptographic protection of application data records). In particular, > > there should not be any interaction between the handshake state machine > > and the application data. If there is to be a commitment made about the > > operation of the TLS handshake protocol, that more properly belongs in > > the handshake layer itself, or perhaps the alert layer if it relates to > > the overall operation of the TLS connection. It seems inappropriate and > > unsustainable to expect that an application-data message would affect > > the operation of the handshake layer. > > IMHO, it doesn't affect the TLS-layer handshakes. It's a signal specific > to EAP-TLS, which is an application using TLS. EAP-TLS is an application using TLS, yes. That means it can't peek into TLS's abstraction barriers -- the example Martin gave where the TLS stack returns a bunch of records that say "application_data" on the outside is a case in point. > > The use of application data for the commitment message also may have > > unfortunate interactions with other TLS-using EAP methods, which is very > > briefly mentioned as a possibility but not explored at all: > > I have a draft on precisely this issue. We have implemented TLS 1.3 for > TTLS and PEAP (hostap && FreeRADIUS). Where they send application data, > there is no need for a commitment message. The EAP method sends it's own > application data. Those messages seem to play the role that Martin has identified, as confirming that the handshake has successfully completed, but that is distinct from what the commitment message is currently described in the draft as doing (indicating no more handshake messages; the NewSessionTicket interaction is most prominent but not unique). > Where the methods don't send application data (i.e. session resumption), > they have the same problem as EAP-TLS, and require a similar solution. > > In general, a number of your comments here conflate EAP-TLS with other > TLS-based EAP methods. This document specifies a standard for EAP-TLS. It > doesn't apply to other methods. There are similar issues for other methods, > but those methods require method-specific solutions. Well, this document does say "many other EAP methods ... depend on TLS and EAP-TLS", as well as allowing for the negotiated ciphersuite to be used to secure application data "as done in other TLS-based EAP methods". That alone would be enough to justify me thinking about the interaction with other methods, not to mention the general obligation of the IESG to be r
Re: [Emu] Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
On Fri, Jan 01, 2021 at 05:03:45PM +, 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 : target="RFC7525">BCP 195? 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
Re: [Emu] Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
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 : BCP 195? > 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 revo
Re: [Emu] Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
On Dec 16, 2020, at 5:36 PM, Benjamin Kaduk via Datatracker wrote: > To start with the easy one: currently the way in which the structure of > the Commitment Message is described makes reference to many fields of > TLS Record Layer structures in order to specify what is fundamentally a > message on the TLS Application Data stream. This is a layering > violation; I don't see any reason to say more than what was suggested in > https://mailarchive.ietf.org/arch/msg/emu/ECgvnq-C_VVXT5bpvOowte8LBjw/ : I will wave a magic wand of "implementation issues". :( There appears to be few ways to *explicitly* signal that negotiation has completed. i.e. ways which are both implemented in SSL libraries, and available to EAP-TLS implementations. We implemented multiple ways in FreeRADIUS (0 octet of application data and other methods). I'll have to double-check the list archive. But my recollection is that the "0x00" of application data was the least ugly alternative. > Next, the whole reason for the existence of a Commitment Message seems > under-justified -- the only mention I could find in the document is that > it serves "to decrease the uncertainty for the EAP-TLS peer". What harm > would be caused by a lack of certainty in this area? Why does waiting > for an EAP-Success or EAP-Failure not provide a similar level of > certainty? The EAP-Success and EAP-Failure messages are *not* protected. i.e. they are 4-bytes of data which can be spoofed rather trivially. In contrast, the 0 byte is an application-layer signal that EAP-TLS has succeeded. > The commitment message as specified seems to itself be a layering > violation. The TLS protocol itself consists of a few sub-protocols, > e.g., the handshake protocol, record protocol, and alert protocol. The > operation of the handshake protocol is supposed to be completely > independent of the application-data record protocol (except to the > extent that the handshake protocol supplies the keys used for > cryptographic protection of application data records). In particular, > there should not be any interaction between the handshake state machine > and the application data. If there is to be a commitment made about the > operation of the TLS handshake protocol, that more properly belongs in > the handshake layer itself, or perhaps the alert layer if it relates to > the overall operation of the TLS connection. It seems inappropriate and > unsustainable to expect that an application-data message would affect > the operation of the handshake layer. IMHO, it doesn't affect the TLS-layer handshakes. It's a signal specific to EAP-TLS, which is an application using TLS. > The use of application data for the commitment message also may have > unfortunate interactions with other TLS-using EAP methods, which is very > briefly mentioned as a possibility but not explored at all: I have a draft on precisely this issue. We have implemented TLS 1.3 for TTLS and PEAP (hostap && FreeRADIUS). Where they send application data, there is no need for a commitment message. The EAP method sends it's own application data. Where the methods don't send application data (i.e. session resumption), they have the same problem as EAP-TLS, and require a similar solution. In general, a number of your comments here conflate EAP-TLS with other TLS-based EAP methods. This document specifies a standard for EAP-TLS. It doesn't apply to other methods. There are similar issues for other methods, but those methods require method-specific solutions. > Section 2.3 > > The use of a constant 0x0D (the "Type-Code") as the TLS-Exporter context > is rather unusual; per RFC 8446 this value is intended to be a > "per-association context value provided by the application using the > exporter" per RFC 5705 -- this value is not a per-association value but > rather a global one. The existing TLS-based EAP methods have consistently used exporters which are global. I'm not even sure what would be used for per-association value. This is EAP, there is generally no underlying transport method (or data) which is consistently available to the EAP layer. i.e. Can you suggest a per-association value which would *work* for EAP? Across RADIUS, Diameter, PANA, ... > 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? The EAP-Type field is 0x0D for EAP-TLS. This value is hard-coded for EAP-TLS. For other EAP types, the use of the field is clarified here; https://tools.ietf.org/html/draft-dekok-emu-tls-eap-types-00 i.e. this document specifies EAP-TLS, and does *not* affect other TLS-based EAP methods. Those are defined elsewhere. > That > seems like it would prevent the modification from successfully causing a > different TLS-based EAP method to be used, by using a different > ke
[Emu] Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-emu-eap-tls13-13: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/ -- DISCUSS: -- I'm going to defer this document's evaluation because I think there are several interrelated subtle issues that merit closer consideration than has been given so far. I will also invite the TLS WG to provide input on these issues, since they relate to rather fundamental issues of the operation of the TLS sub-protocols. Most of them concern the Commitment Message, in terms of what goals it aims to achieve, how it is specified, and what mechanism is used to effectuate it. To start with the easy one: currently the way in which the structure of the Commitment Message is described makes reference to many fields of TLS Record Layer structures in order to specify what is fundamentally a message on the TLS Application Data stream. This is a layering violation; I don't see any reason to say more than what was suggested in https://mailarchive.ietf.org/arch/msg/emu/ECgvnq-C_VVXT5bpvOowte8LBjw/ : "the commit[ment] message is a single byte of [value] 0 in the application data stream". All the bits about cryptographic protection and expansion of the plaintext in prepararation for record protection are just adding noise, and the interface between the TLS stack and the application is supposed to be a data-stream abstraction, not a record abstraction. Next, the whole reason for the existence of a Commitment Message seems under-justified -- the only mention I could find in the document is that it serves "to decrease the uncertainty for the EAP-TLS peer". What harm would be caused by a lack of certainty in this area? Why does waiting for an EAP-Success or EAP-Failure not provide a similar level of certainty? The document also suggests in several places that the Commitment Message can or should be sent at 0.5-RTT data in the same flight as the server Finished. The intent, as determined from the mailing list archive, seems to be to save a round-trip compared to a typical full message flow where the server does not send application data until after the client's Finished (and any application data alongside it) is received. In particular, this came out during discussion of how a TLS "close_notify" alert would be unsuitable for the role of the Commitment Message, since sending the "close_notify" in 0.5-RTT would prevent sending an alert if the client authentication failed, and the diagnostic value of such alerts is significant. This is where the issues start to become interrelated -- the Commitment Message as a new application-data construct is for the objective of reducing the number of round trips. However, TLS session resumption is also designed to reduce the number of round-trips (including by no longer needing to send potentially large TLS Certificate messages that get fragmented at the EAP layer, with the cost of a round trip per fragment), and there is a nasty interaction between the two mechanisms. Specifically, TLS 1.3 session resumption requires the use of a NewSessionTicket message, which is associated with a resumption secret; the resumption secret, in turn, is not available in the key schedule until the client Finished (and client authentication messages, if any) is available. While it is possible in many Web scenarios for NewSessionTicket to be issued in the 0.5-RTT flight, this is because the server can precompute what the valid client Finished would be and use that in the key schedule to precompute the resumption secret. If the client is to be authenticated, as is the case for the vast majority of EAP exchanges, then such precomputation is impossible, and the session ticket cannot be issued until the extra round trip is completed. The document contains no discussion of the inherent tradeoff between sending the commitment message in 0.5-RTT and using resumption, and this tradeoff seems to call into question the merits of choosing this mechanism to implement the commitment message, since... The commitment message as specified seems to itself be a layering violation. The TLS protocol itself consists of a few sub-protocols, e.g., the handshake protocol, record protocol, and alert protocol. The operation of the handshake protocol is supposed to be completely independent of the application-data record protocol (except to the extent that the handshake protocol supplies the keys used for cryptographic protection of appl
