Re: [Standards] Channel binding and token authentication
On Tue, 27 Sept 2022 at 13:22, Dave Cridland wrote: > All of which I broadly agree with to various degrees, however that's not the > attack here - the attack is that a passive observer can replay TLS 1.3 Early > Data, and if a client developer (fairly sensibly) chooses to send a SASL > exchange there, that might get to the point of an authenticated connection. > It's one the attacker cannot control, mind - confidentiality has still been > assured - but if a client developer were to use TLS Early Data to send both > the SASL exchange *and* a message or something, then that might be a problem. The pending updates to SASL2 forbid Early Data. The pending token auth spec allows it if negotiated, but also adds a per-token counter to protect against replays. This works independently of SASL mechanism or channel binding. Channel binding (e.g. with tls-server-end-point) is not adequate protection against this replay attack, and was not intended as such protection, to my knowledge. > In other protocols also using SASL, though, it might be a worse problem - in > principle some uses of Submission (ie, SMTP for sending mails) might be > susceptible here, and there could be some other issues even on broadly > readonly protocols like IMAP. Yes. Correctly specified and implemented, we don't have these problems (with or without channel binding). > In any case, given the focus for HT-* is 0-RTT startup, it makes a lot of > sense to try to ensure it has some protection for replay - saying "Well, if > you want to save on round-trips, you can use HT-*-NONE, but then you'll need > to disable TLS Early Data and spend an additional RTT there" doesn't seem > like an ideal situation. > > Meanwhile in the HTTP world, verified TLS and a session cookie is *very* > susceptible to replay attacks based on TLS 1.3 Early Data, and it's often > blocked as a result (for example, Cloudflare reject it for anything except > "plain" GET requests, and Go doesn't even implement it, and ... ). Given it > weakens forward secrecy for the Early Data, too, there's not just replay > issues to consider anyway. > > Anyway, something to worry over when looking at HT-*-NONE - and to be > explicit, my knowledge here is getting very sketchy, so I don't even know if > HT-* with (say) TLS Exporter channel bindings is any better. If the primary practical value of channel binding is only to work around a problem in something that nobody currently implements - a problem which also has simpler and more correct workarounds available - I rest my case :) Regards, Matthew ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Channel binding and token authentication
On Tue, 27 Sept 2022 at 12:59, Matthew Wild wrote: > On Tue, 27 Sept 2022 at 12:31, Dave Cridland wrote: > > On Tue, 27 Sept 2022 at 11:51, Matthew Wild wrote: > >> On Tue, 27 Sept 2022 at 11:36, Dave Cridland wrote: > >> > - I seem to remember that HT-* derives a lot of its replay protection > from the channel binding, so we may want to have *something* there. > >> > >> What is the attack scenario here? Someone compromised TLS? > >> > > > > Any case where an attacker obtains the SASL exchange itself, or can > replay it by some other means (I think TLS Early Data has some weaknesses > here). > I'm not convinced this is very exploitable in any useful way, but I > think it might be enough to do something in some cases. > > If an attacker is able to do this, they have either compromised your > client, your server or TLS. In all three cases, I think SASL is the > least of your worries. > > I understand that in some protocols it is more common to send your > credentials to multiple different third parties, and ensuring that > authentication is bound to the entity you think you are authenticating > to fixes a large security hole. > > Here in XMPP this is rarely the case - users generally don't send > credentials for service A to service B. And in this particular > instance, we're talking about short-lived tokens that are already > unique to the service you are connecting and authenticating to. There > is nobody else to replay to that would accept the token. > > Looking beyond our own ecosystem, verified TLS and a session cookie > are considered adequate protection for practically all online services > today, from webmail to internet banking. They are susceptible to these > same "replay attacks". Despite this reality, I've had many discussions > with multiple XMPP community members in recent weeks, practically > claiming the absolute necessity of channel binding. I just don't see > it. I get that it's cool, and if you can do it, why not? But I don't > think it is preventing any practical attacks at all. > > All of which I broadly agree with to various degrees, however that's not the attack here - the attack is that a passive observer can replay TLS 1.3 Early Data, and if a client developer (fairly sensibly) chooses to send a SASL exchange there, that might get to the point of an authenticated connection. It's one the attacker cannot control, mind - confidentiality has still been assured - but if a client developer were to use TLS Early Data to send both the SASL exchange *and* a message or something, then that might be a problem. In other protocols also using SASL, though, it might be a worse problem - in principle some uses of Submission (ie, SMTP for sending mails) might be susceptible here, and there could be some other issues even on broadly readonly protocols like IMAP. In any case, given the focus for HT-* is 0-RTT startup, it makes a lot of sense to try to ensure it has some protection for replay - saying "Well, if you want to save on round-trips, you can use HT-*-NONE, but then you'll need to disable TLS Early Data and spend an additional RTT there" doesn't seem like an ideal situation. Meanwhile in the HTTP world, verified TLS and a session cookie is *very* susceptible to replay attacks based on TLS 1.3 Early Data, and it's often blocked as a result (for example, Cloudflare reject it for anything except "plain" GET requests, and Go doesn't even implement it, and ... ). Given it weakens forward secrecy for the Early Data, too, there's not just replay issues to consider anyway. Anyway, something to worry over when looking at HT-*-NONE - and to be explicit, my knowledge here is getting very sketchy, so I don't even know if HT-* with (say) TLS Exporter channel bindings is any better. > > But note that there's at least three different problems here: > > > > - Do we need to specify an HT-*-NONE (or at least, something similar)? > The answer to this is "probably, yes". > > Agreed. Previous discussions have included talk of stuffing tokens > into PLAIN (which of course I've seen in multiple real-world > deployments over the years). I'd rather not sanction that approach in > a new spec, but it's pretty much the leading alternative. > > > - Can we minimize the need to use this, and encourage developers down a > better path? I think we're in agreement that there's some good advice we > can usefully give in some cases, but sadly not all. > > If we specify it, yes, we can provide guidance on it. As you noted, > such guidance may already be warranted for tls-server-end-point > already. > > > - Does a simplistic HT-*-NONE have some issues we'll want to address > carefully - possibly to the point that we actually need something different > in this case? Again, "probably, yes". > > I'm open to suggestions about what might be done differently, that > still fits into a single round-trip. > Right. I'm not saying "Don't!", I'm saying it might not be as simple to do as "Just don't do channel binding". > > > It
Re: [Standards] Channel binding and token authentication
On Tue, 27 Sept 2022 at 12:31, Dave Cridland wrote: > On Tue, 27 Sept 2022 at 11:51, Matthew Wild wrote: >> On Tue, 27 Sept 2022 at 11:36, Dave Cridland wrote: >> > - I seem to remember that HT-* derives a lot of its replay protection from >> > the channel binding, so we may want to have *something* there. >> >> What is the attack scenario here? Someone compromised TLS? >> > > Any case where an attacker obtains the SASL exchange itself, or can replay it > by some other means (I think TLS Early Data has some weaknesses here). I'm not convinced this is very exploitable in any useful way, but I think it might be enough to do something in some cases. If an attacker is able to do this, they have either compromised your client, your server or TLS. In all three cases, I think SASL is the least of your worries. I understand that in some protocols it is more common to send your credentials to multiple different third parties, and ensuring that authentication is bound to the entity you think you are authenticating to fixes a large security hole. Here in XMPP this is rarely the case - users generally don't send credentials for service A to service B. And in this particular instance, we're talking about short-lived tokens that are already unique to the service you are connecting and authenticating to. There is nobody else to replay to that would accept the token. Looking beyond our own ecosystem, verified TLS and a session cookie are considered adequate protection for practically all online services today, from webmail to internet banking. They are susceptible to these same "replay attacks". Despite this reality, I've had many discussions with multiple XMPP community members in recent weeks, practically claiming the absolute necessity of channel binding. I just don't see it. I get that it's cool, and if you can do it, why not? But I don't think it is preventing any practical attacks at all. > But note that there's at least three different problems here: > > - Do we need to specify an HT-*-NONE (or at least, something similar)? The > answer to this is "probably, yes". Agreed. Previous discussions have included talk of stuffing tokens into PLAIN (which of course I've seen in multiple real-world deployments over the years). I'd rather not sanction that approach in a new spec, but it's pretty much the leading alternative. > - Can we minimize the need to use this, and encourage developers down a > better path? I think we're in agreement that there's some good advice we can > usefully give in some cases, but sadly not all. If we specify it, yes, we can provide guidance on it. As you noted, such guidance may already be warranted for tls-server-end-point already. > - Does a simplistic HT-*-NONE have some issues we'll want to address > carefully - possibly to the point that we actually need something different > in this case? Again, "probably, yes". I'm open to suggestions about what might be done differently, that still fits into a single round-trip. > It might be that HT-* in general has much higher security than HT-*-NONE, and > it might be that we just have to live with that. (...suppressing more questions about how much value channel binding really brings to us...) This is why I would of course specify that channel binding must be used if supported, and that tokens must be pinned to the mechanism they were initially created for. Regards, Matthew ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Channel binding and token authentication
On Tue, 27 Sept 2022 at 11:51, Matthew Wild wrote: > On Tue, 27 Sept 2022 at 11:36, Dave Cridland wrote: > > On Tue, 27 Sept 2022 at 09:59, Matthew Wild wrote: > >> > >> On Tue, 27 Sep 2022, 09:46 Dave Cridland, wrote: > > I'd not considered web clients - can they not obtain the server > certificate at all, even these days? > > I'm not aware of any method to do so (which is certainly a shame). > > Indeed... Never occurred to me there wouldn't be, especially these days with Crypto.subtle and things. > > - I'd assumed that all clients could use tls-server-end-point fairly > easily. If that's not the case for web clients, that's clearly a problem. > > - As a client, it's impossible to tell whether a server is validating > the channel binding data or simply blindly accepting it anyway. > > - Ideally, even with TLS termination before the XMPP server, the XMPP > server can discover or be configured with its TLS certificate so it can > verify that. > > Sure, in Prosody we default to the configured certificate but allow > manually providing a hash to allow for setups where TLS is handled > externally. > > > - I seem to remember that HT-* derives a lot of its replay protection > from the channel binding, so we may want to have *something* there. > > What is the attack scenario here? Someone compromised TLS? > > Any case where an attacker obtains the SASL exchange itself, or can replay it by some other means (I think TLS Early Data has some weaknesses here). I'm not convinced this is very exploitable in any useful way, but I think it might be enough to do something in some cases. I'm not sure that tls-server-end-point doesn't have the same weaknesses with HT-*, mind. (IoW, I think it might have the same problems as no channel binding at all, because it's a fixed string). > >> Unless I'm misunderstanding your proposal. > > > > Well, my proposal is to think about it a bit before we commit, so maybe > you're unwittingly accepting it anyway? > > I propose to consider that you might be right. But note that there's at least three different problems here: - Do we need to specify an HT-*-NONE (or at least, something similar)? The answer to this is "probably, yes". - Can we minimize the need to use this, and encourage developers down a better path? I think we're in agreement that there's some good advice we can usefully give in some cases, but sadly not all. - Does a simplistic HT-*-NONE have some issues we'll want to address carefully - possibly to the point that we actually need something different in this case? Again, "probably, yes". It might be that HT-* in general has much higher security than HT-*-NONE, and it might be that we just have to live with that. Dave. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Channel binding and token authentication
On Tue, 27 Sept 2022 at 11:36, Dave Cridland wrote: > On Tue, 27 Sept 2022 at 09:59, Matthew Wild wrote: >> >> On Tue, 27 Sep 2022, 09:46 Dave Cridland, wrote: > I'd not considered web clients - can they not obtain the server certificate > at all, even these days? I'm not aware of any method to do so (which is certainly a shame). > - I'd assumed that all clients could use tls-server-end-point fairly easily. > If that's not the case for web clients, that's clearly a problem. > - As a client, it's impossible to tell whether a server is validating the > channel binding data or simply blindly accepting it anyway. > - Ideally, even with TLS termination before the XMPP server, the XMPP server > can discover or be configured with its TLS certificate so it can verify that. Sure, in Prosody we default to the configured certificate but allow manually providing a hash to allow for setups where TLS is handled externally. > - I seem to remember that HT-* derives a lot of its replay protection from > the channel binding, so we may want to have *something* there. What is the attack scenario here? Someone compromised TLS? >> Unless I'm misunderstanding your proposal. > > Well, my proposal is to think about it a bit before we commit, so maybe > you're unwittingly accepting it anyway? I propose to consider that you might be right. Regards, Matthew ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Channel binding and token authentication
On Tue, 27 Sept 2022 at 09:59, Matthew Wild wrote: > On Tue, 27 Sep 2022, 09:46 Dave Cridland, wrote: > >> Before committing to this, some observations: >> >> - HT-*-NONE is needed for cases where there's no TLS at all. These are >> rare, but there's legitimate cases where this is a sensible choice. >> - Channel bindings can be used in cases where TLS is terminated in >> advance by either: >> - Using TLS Endpoint channel bindings, which merely mean the XMPP >> server needs to know the certificate which is to be used, or >> - Just going through the motions and blindly accepting the client's >> channel binding choice, perhaps most sensibly by again using >> tls-server-end-point >> >> So I'm not *against* a HT-*-NONE, but I wonder if we should promote the >> second bullet-point above the first? >> > > What would you propose exactly? That web clients just send some junk data > and servers just accept it? > > I'd not considered web clients - can they not obtain the server certificate at all, even these days? > I think any mode that blindly accepts in this way is worse than explicitly > not using channel binding. With the planned token authentication protocols, > a token is bound to a specific mechanism. That means if it is obtained with > support for channel binding, it can only be used for authentication with > that channel binding. If the server isn't always verifying the channel > binding data, this undermines the security of this mechanism. > > Yes, but: - I'd assumed that all clients could use tls-server-end-point fairly easily. If that's not the case for web clients, that's clearly a problem. - As a client, it's impossible to tell whether a server is validating the channel binding data or simply blindly accepting it anyway. - Ideally, even with TLS termination before the XMPP server, the XMPP server can discover or be configured with its TLS certificate so it can verify that. - I seem to remember that HT-* derives a lot of its replay protection from the channel binding, so we may want to have *something* there. > Unless I'm misunderstanding your proposal. > Well, my proposal is to think about it a bit before we commit, so maybe you're unwittingly accepting it anyway? Dave. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Channel binding and token authentication
On Tue, 27 Sep 2022, 09:46 Dave Cridland, wrote: > Before committing to this, some observations: > > - HT-*-NONE is needed for cases where there's no TLS at all. These are > rare, but there's legitimate cases where this is a sensible choice. > - Channel bindings can be used in cases where TLS is terminated in advance > by either: > - Using TLS Endpoint channel bindings, which merely mean the XMPP server > needs to know the certificate which is to be used, or > - Just going through the motions and blindly accepting the client's > channel binding choice, perhaps most sensibly by again using > tls-server-end-point > > So I'm not *against* a HT-*-NONE, but I wonder if we should promote the > second bullet-point above the first? > What would you propose exactly? That web clients just send some junk data and servers just accept it? I think any mode that blindly accepts in this way is worse than explicitly not using channel binding. With the planned token authentication protocols, a token is bound to a specific mechanism. That means if it is obtained with support for channel binding, it can only be used for authentication with that channel binding. If the server isn't always verifying the channel binding data, this undermines the security of this mechanism. Unless I'm misunderstanding your proposal. Regards, Matthew ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Channel binding and token authentication
On Tue, 27 Sept 2022 at 08:39, Daniel Gultsch wrote: > But I agree that it should be optional; I already said this in the ISR > thread: There are plenty of scenarios where channel binding is not an > option. > Before committing to this, some observations: - HT-*-NONE is needed for cases where there's no TLS at all. These are rare, but there's legitimate cases where this is a sensible choice. - Channel bindings can be used in cases where TLS is terminated in advance by either: - Using TLS Endpoint channel bindings, which merely mean the XMPP server needs to know the certificate which is to be used, or - Just going through the motions and blindly accepting the client's channel binding choice, perhaps most sensibly by again using tls-server-end-point So I'm not *against* a HT-*-NONE, but I wonder if we should promote the second bullet-point above the first? Dave. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Channel binding and token authentication
On Mon, Sep 26, 2022 at 7:28 PM Matthew Wild wrote: > > The current specs say that channel binding is a mandatory requirement. > However this excludes web clients from using the mechanisms, even > though they would be one of the key client groups to benefit from > being able to exchange passwords for tokens. Meanwhile, I believe that > the security gained by channel binding in XMPP is minimal, at best. > > Does anyone have objections to proceeding with the definition of one > or more HT-*-NONE mechanisms for token authentication? > > FWIW I think channel binding has some interesting security properties - especially once we have device specif tokens that can be stored relatively securely one a device. But I agree that it should be optional; I already said this in the ISR thread: There are plenty of scenarios where channel binding is not an option. cheers Daniel ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Channel binding and token authentication
Sep 26, 2022 7:42:48 AM Kevin Smith : > -- Original Message -- > From: "Matthew Wild" > To: "XMPP Standards" > Sent: 26/09/2022 18:24:37 > Subject: [Standards] Channel binding and token authentication > >> Does anyone have objections to proceeding with the definition of one >> or more HT-*-NONE mechanisms for token authentication? > > Seems entirely sensible to me. I agree. (Selfishly, as the author of a proxy that would break channel binding) ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Channel binding and token authentication
-- Original Message -- From: "Matthew Wild" To: "XMPP Standards" Sent: 26/09/2022 18:24:37 Subject: [Standards] Channel binding and token authentication Does anyone have objections to proceeding with the definition of one or more HT-*-NONE mechanisms for token authentication? Seems entirely sensible to me. /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Channel binding and token authentication
Hi folks, I'm continuing work on authentication[1]. While fleshing out a plan for token authentication in SASL2, I provided feedback to Florian a few days ago that we need a new SASL HT- mechanism without channel binding ( https://datatracker.ietf.org/doc/html/draft-schmaus-kitten-sasl-ht-07 ). He suggested I bring up the topic on the list, so here I am. The current specs say that channel binding is a mandatory requirement. However this excludes web clients from using the mechanisms, even though they would be one of the key client groups to benefit from being able to exchange passwords for tokens. Meanwhile, I believe that the security gained by channel binding in XMPP is minimal, at best. Does anyone have objections to proceeding with the definition of one or more HT-*-NONE mechanisms for token authentication? Regards, Matthew [1]: https://docs.modernxmpp.org/projects/auth/ ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
