Re: [Standards] XEP-0388: SASL2 enhancements
Hi all, the SASL2 update consists of various parts. Mixing them doesn't help our discussion and I guess most people will loose track sooner or later. I will therefore start a new thread for every part, to discuss them separately. I also want to stress what MattJ already said: > New Bind 2 (and SASL2) is already implemented by at least Prosody, > Conversations and Monal. We learnt a lot from our collaboration > and testing, and have tweaked and improved various things along > the way as we discovered what did and didn't work well during > implementation. Overall, I'm pretty happy with what we have working. -tmolitor Am Donnerstag, 20. Oktober 2022, 13:49:50 CEST schrieb Marvin W: > Hi Thilo, > > On Wed, 2022-10-19 at 21:41 +0200, Thilo Molitor wrote: > > I want us to move away from that "PLAIN is sometimes needed, let's > > support > > it in all relevant clients without further interaction by the user > > and ignore > > any security implications this might have" stance that seems be > > common, to > > something like "only support PLAIN in clients after configured to do > > so, to not > > allow for trivial MITM attacks". > > That's essentially a "default secure" rather a "default insecure" > > approach. > > You make it sound as if PLAIN over TLS was anywhere near insecure. It's > not. It's what is protecting your emails, your online banking, your tax > declaration, ... (at least on first connection, some of these can store > a token for further use instead of the plain password). > > The main advantage of SCRAM is that clients don't need to store the > plain password, but can store the SaltedPassword instead. This is still > a valid credential, but it is restricted to the server (as each server > would have it's own salt), so if users reuse passwords (which they > shouldn't, but do anyways), it's not as much of an issue, if the XMPP > client is attacked, as only the XMPP account would be affected. > > Under certain extreme conditions it might be sensible to put some kind > of additional security to TLS, for example Signal is known to use > certificate pinning with their own CA. And for these special cases it's > worth having something like SCRAM with channel binding specified (and > both defaulting to it and pinning to it is somewhat sensible). > > But that doesn't mean we should frame PLAIN over TLS as insecure. It's > not. It also doesn't allow for trivial MITM attacks: If a public CA was > to issue certificates it shouldn't issue, it will get banned > immediately (and thanks to certificate transparency we will learn about > this close to immediately). And if a private CA was installed onto a > system, the attacker could have installed malware at the same time, > that would be able to fish the user's password and thereby break > SCRAM's channel binding. > > Given that there are always usecases where SCRAM cannot be used (RFC > already mentioned PAM and LDAP, but there are even further, basically > everything where credentials are not handled by the XMPP server itself) > > > I've split out the SCRAM upgrade task definition into a new ProtoXEP: > > https:// > > github.com/tmolitor-stud-tu/xeps/tree/scram-upgrades > > Rendered version: > > https://dyn.eightysoft.de/final/xep-scram-upgrade.html > > Just wanted to mention that this specification isn't really a "SCRAM > upgrade", but rather a "change salted password" specification (which > might be an interesting idea to have, but that's another story), > because the server has no way to verify that the salted password is the > same as the previous one when upgrading from SCRAM-SHA-1 to SCRAM-SHA- > 256. > > I also question the proposed upgrade mechanism in general. The server > can only suggest mechanisms independent of the user's account name. If > the server previously only stored SCRAM-SHA-1 secrets and some users > upgraded but others didn't, the list can't be used meaningfully. What > we'd need here is a new error code for the server to tell the client > after the message that the user can't use SCRAM-SHA-256 > yet, but will be able to do so after some upgrade operation being > performed (which probably entails sending the password in plain). > A client that is trying to do SCRAM-SHA-256 when the server doesn't > have matching credentials yet must have the plain password at hand > already (as it can't have the SaltedPassword yet due to lack of salt), > so it is already prepared to provide it. If channel binding is desired > for security reasons, one could also do a SCRAM-SHA-1-PLUS before > sending the password to the server in plain. > > Marvin > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe:
Re: [Standards] XEP-0388: SASL2 enhancements
Hi Marvin, > > I've split out the SCRAM upgrade task definition into a new ProtoXEP: > > https:// > > github.com/tmolitor-stud-tu/xeps/tree/scram-upgrades > > Rendered version: > > https://dyn.eightysoft.de/final/xep-scram-upgrade.html > > Just wanted to mention that this specification isn't really a "SCRAM > upgrade", but rather a "change salted password" specification (which > might be an interesting idea to have, but that's another story), > because the server has no way to verify that the salted password is the > same as the previous one when upgrading from SCRAM-SHA-1 to SCRAM-SHA- > 256. Well, if a client used different passwords to generate she SCRAM-SHA-256 hash than was used for the SCRAM-SHA-1, mere chaos would evolve. But you are right: we should add wording to XEP-0388 that the password used for the new hash MUST be the same as used to log in the client in the first place. > I also question the proposed upgrade mechanism in general. The server > can only suggest mechanisms independent of the user's account name. If > the server previously only stored SCRAM-SHA-1 secrets and some users > upgraded but others didn't, the list can't be used meaningfully. What > we'd need here is a new error code for the server to tell the client > after the message that the user can't use SCRAM-SHA-256 > yet, but will be able to do so after some upgrade operation being > performed (which probably entails sending the password in plain). > A client that is trying to do SCRAM-SHA-256 when the server doesn't > have matching credentials yet must have the plain password at hand > already (as it can't have the SaltedPassword yet due to lack of salt), > so it is already prepared to provide it. If channel binding is desired > for security reasons, one could also do a SCRAM-SHA-1-PLUS before > sending the password to the server in plain. You misunderstood the upgrade tasks: the server knows perfectly well which SASL mechanisms a specific account can be upgraded to and which mechanisms can already be used right away (the "from"-attribute of the stream header tells it which account the client wants to upgrade). Of course the server has to store all hashes independently (e.g. two database fields, one for SCRAM-SHA-1 and one for SCRAM-SHA-256). This wasn't outlined in the XEP because I figured details on the storage implementations of servers were out of scope for this XEP. But I could well add some wording that all hashes should be stored on the server, not only one of them. -tmolitor ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0388: SASL2 enhancements
Hi Thilo, On Wed, 2022-10-19 at 21:41 +0200, Thilo Molitor wrote: > I want us to move away from that "PLAIN is sometimes needed, let's > support > it in all relevant clients without further interaction by the user > and ignore > any security implications this might have" stance that seems be > common, to > something like "only support PLAIN in clients after configured to do > so, to not > allow for trivial MITM attacks". > That's essentially a "default secure" rather a "default insecure" > approach. You make it sound as if PLAIN over TLS was anywhere near insecure. It's not. It's what is protecting your emails, your online banking, your tax declaration, ... (at least on first connection, some of these can store a token for further use instead of the plain password). The main advantage of SCRAM is that clients don't need to store the plain password, but can store the SaltedPassword instead. This is still a valid credential, but it is restricted to the server (as each server would have it's own salt), so if users reuse passwords (which they shouldn't, but do anyways), it's not as much of an issue, if the XMPP client is attacked, as only the XMPP account would be affected. Under certain extreme conditions it might be sensible to put some kind of additional security to TLS, for example Signal is known to use certificate pinning with their own CA. And for these special cases it's worth having something like SCRAM with channel binding specified (and both defaulting to it and pinning to it is somewhat sensible). But that doesn't mean we should frame PLAIN over TLS as insecure. It's not. It also doesn't allow for trivial MITM attacks: If a public CA was to issue certificates it shouldn't issue, it will get banned immediately (and thanks to certificate transparency we will learn about this close to immediately). And if a private CA was installed onto a system, the attacker could have installed malware at the same time, that would be able to fish the user's password and thereby break SCRAM's channel binding. Given that there are always usecases where SCRAM cannot be used (RFC already mentioned PAM and LDAP, but there are even further, basically everything where credentials are not handled by the XMPP server itself) > I've split out the SCRAM upgrade task definition into a new ProtoXEP: > https:// > github.com/tmolitor-stud-tu/xeps/tree/scram-upgrades > Rendered version: > https://dyn.eightysoft.de/final/xep-scram-upgrade.html Just wanted to mention that this specification isn't really a "SCRAM upgrade", but rather a "change salted password" specification (which might be an interesting idea to have, but that's another story), because the server has no way to verify that the salted password is the same as the previous one when upgrading from SCRAM-SHA-1 to SCRAM-SHA- 256. I also question the proposed upgrade mechanism in general. The server can only suggest mechanisms independent of the user's account name. If the server previously only stored SCRAM-SHA-1 secrets and some users upgraded but others didn't, the list can't be used meaningfully. What we'd need here is a new error code for the server to tell the client after the message that the user can't use SCRAM-SHA-256 yet, but will be able to do so after some upgrade operation being performed (which probably entails sending the password in plain). A client that is trying to do SCRAM-SHA-256 when the server doesn't have matching credentials yet must have the plain password at hand already (as it can't have the SaltedPassword yet due to lack of salt), so it is already prepared to provide it. If channel binding is desired for security reasons, one could also do a SCRAM-SHA-1-PLUS before sending the password to the server in plain. Marvin ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0388: SASL2 enhancements
Hi Matthew, > There are deployments that require PLAIN. That is unlikely to change > (ever). However this doesn't stop clients from being smart, e.g. by > pinning support for SCRAM and refusing to downgrade. I don't know if > any clients actually do this. Yes, those deployments do exist. But I want us to move away from that "PLAIN is sometimes needed, let's support it in all relevant clients without further interaction by the user and ignore any security implications this might have" stance that seems be common, to something like "only support PLAIN in clients after configured to do so, to not allow for trivial MITM attacks". That's essentially a "default secure" rather a "default insecure" approach. While pinning is a valid approach it has some downsides, too. It does not cover the first connection and depends on ordering of mechanisms. If you upgrade the pinning to stronger mechanisms as soon as the server advertises them, you'll break authentication for your client if the server operator just briefly activated these stronger mechanisms and deactivates them again. If you don't upgrade your pinning, your client will remain on a sort of security baseline that eventually will be outdated over the years and virtually be as good as no pinning at all. Because all of these I consider pinning to be some solution of last resort if you can't come up with something better rather than a go-to solution one should always use. > There is a separate issue which was brought up by Dave in his review, > which is the inclusion of the upgrade tasks in this XEP. As far as I > am aware, nobody is opposing the upgrade tasks themselves (I certainly > think they are desperately needed). The problem is that they are not > part of the SASL2 framework itself. Just like we don't plan to define > every possible post-authentication task in this XEP, these tasks are > mechanism-specific and they don't need to be in XEP-0388. Copy/paste > them into a new document, and I think everyone will be happy. I've split out the SCRAM upgrade task definition into a new ProtoXEP: https:// github.com/tmolitor-stud-tu/xeps/tree/scram-upgrades Rendered version: https://dyn.eightysoft.de/final/xep-scram-upgrade.html -tmolitor ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0388: SASL2 enhancements
On Wed, 19 Oct 2022 at 14:23, Thilo Molitor wrote: > > Hi Daniel, > > Daniel Gultsch wrote: > > Inline + User-Agent good. Very skeptical on forbidding PLAIN and the > dependency on channel binding. > It's not forbidding PLAIN, but highlights what is already described in RFC > 6120 section 13.8.3, but seems to have been forgotten: PLAIN should not be > used if it's not absolutely needed. > Why is that so? Because any channel-binding falls apart if the client supports > PLAIN. Thus it's always possible to downgrade the client to use PLAIN. > Today almost every client still supports PLAIN and will happily negotiate it > without any warning to the user and without being hidden behind a "Activate > legacy authentication" knob that has to be enabled by the user first. There are deployments that require PLAIN. That is unlikely to change (ever). However this doesn't stop clients from being smart, e.g. by pinning support for SCRAM and refusing to downgrade. I don't know if any clients actually do this. > > I don’t yet have on opinion on the tasks issue. > Well, if we don't have a way to upgrade the SCRAM hashes stored on the server, > we won't be able to gradually phase out SCRAM-SHA-1 to use the more secure > SCRAM-SHA-256. I think there are two "tasks issue"s being confused here. The "tasks issue" that I was referring to (and I assume Daniel too) was specifically about the task syntax (base64 vs arbitrary XML payloads). I don't have a strong opinion on this right now, mainly because I haven't properly tried to use either format yet. While working on rough draft flows for MFA, I did find base64 and the next/continue framework very limiting, but I understand why the spec was written as it is, so I think any changes do deserve attention. There is a separate issue which was brought up by Dave in his review, which is the inclusion of the upgrade tasks in this XEP. As far as I am aware, nobody is opposing the upgrade tasks themselves (I certainly think they are desperately needed). The problem is that they are not part of the SASL2 framework itself. Just like we don't plan to define every possible post-authentication task in this XEP, these tasks are mechanism-specific and they don't need to be in XEP-0388. Copy/paste them into a new document, and I think everyone will be happy. Regards, Matthew ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0388: SASL2 enhancements
I've pushed a new commit partly addressing some of Dave's concerns: https:// github.com/xsf/xeps/pull/1214/commits/2a0a894f8ea606d9bbf894f85c3c306c8166cb54 Up to date rendering: https://dyn.eightysoft.de/final/xep-0388.html Up to date diff: https://dyn.eightysoft.de/final/xep-0388-diff.html -tmolitor ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0388: SASL2 enhancements
Hi Daniel, Daniel Gultsch wrote: > Inline + User-Agent good. Very skeptical on forbidding PLAIN and the dependency on channel binding. It's not forbidding PLAIN, but highlights what is already described in RFC 6120 section 13.8.3, but seems to have been forgotten: PLAIN should not be used if it's not absolutely needed. Why is that so? Because any channel-binding falls apart if the client supports PLAIN. Thus it's always possible to downgrade the client to use PLAIN. A client supporting PLAIN will never have to implement SCRAM nor channel- binding. Implementing these just does not make any sense if an attacker able to break into the TLS layer can always downgrade authentication to use PLAIN, circumventing any SCRAM or channel-binding. If, on the other hand, we assume TLS to always be secure, than we won't have to implement SCRAM and channel-binding either. There is no need in implementing SCRAM or channel-binding to secure something we deem to be always secure by definition. Today almost every client still supports PLAIN and will happily negotiate it without any warning to the user and without being hidden behind a "Activate legacy authentication" knob that has to be enabled by the user first. Now to the dependency on channel-binding: that was not meant to be a hard dependency, but if a client or server supports channel-binding it MUST use XEP-0440 to negotiate which binding to use. And it SHOULD only use upgrade tasks if channel-binding is in use to make sure an attacker won't be able to intercept the SCRAM hash (or any other authentication data) that could later be used to impersonate the client/user. If I accidentally made the channel-binding a hard dependency, I'm happy to fix that. Just point me to the part of the XEP I should change. > I don’t yet have on opinion on the tasks issue. Well, if we don't have a way to upgrade the SCRAM hashes stored on the server, we won't be able to gradually phase out SCRAM-SHA-1 to use the more secure SCRAM-SHA-256. You'll either have to store the password on the server in plaintext or only offer SCRAM-SHA-1. There are good reasons to not store passwords in plaintext on the server, but use salted hashes: https://prosody.im/doc/plain_or_hashed Prosody even defaults to hashed now. That means you won't be able to upgrade to SCRAM-SHA-256 if these upgrade tasks weren't included in SASL2. (You could of course force the complete userbase of a server into resetting their passwords to switch from SHA-1 to SHA-256, but that's obviously very bad UX.) This upgrade problem has been mentioned in 2019 here on list already: https:// mail.jabber.org/pipermail/standards/2019-January/035720.html I've written a blog post that more or less describes all of the rationale behind my changes to this XEP over here: https://monal-im.org/post/4-sasl/ -tmolitor ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0388: SASL2 enhancements
On Tue, Oct 18, 2022 at 10:11 PM Matthew Wild wrote: > > …do we really need ? Yes. The ability to announce that a certain feature a) exists b) supports SASL2 inline must be announced. For example regular SM might not even be announced prior to authentication. The only question is if we create a new top level stream feature called (we briefly had that in one of our drafts IIRC) or if we bunch up all line features in a wrapper element called If we ever do a SM2 your just include everything opportunistically approach falls apart. I mean feature announcements are an integral part to XMPP. I'm not sure why SASL2 inlining would be the place to get rid of it. > New Bind 2 is already implemented by at least Prosody, Conversations > and Monal. We learnt a lot from our collaboration and testing, and > have tweaked and improved various things along the way as we > discovered what did and didn't work well during implementation. > Overall, I'm pretty happy with what we have working. I agree. SASL2 + Bind 2 + inline SM + token auth is a great combination. cheers Daniel ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0388: SASL2 enhancements
Hi,
without trying to rehash what Matthew said I just wanted to give my +1
to everything he said.
Inline + User-Agent good. Very skeptical on forbidding PLAIN and the
dependency on channel binding.
I don’t yet have on opinion on the tasks issue.
cheers
Daniel
On Tue, Oct 18, 2022 at 4:02 PM Matthew Wild wrote:
>
> Hi folks,
>
> For context, there is an update to XEP-0388 (SASL2) pending:
>
> PR: https://github.com/xsf/xeps/pull/1214
> HTML: https://dyn.eightysoft.de/final/xep-0388.html
> HTML (diff): https://matthewwild.co.uk/uploads/xep-0388-diff.html
>
> As per policy, we're bringing any substantial discussion to the
> mailing list. Nevertheless, you'll find an initial review by Dave
> (original author of the XEP) at the above link.
>
> We have quite a few prototype implementations of (many of) the new
> changes already in Prosody, Conversations, Monal, Gajim and Siskin.
>
> The main changes that I'm interested in are the following:
>
> 1) Advertisement of supported "inline" features
>
> One of the initial premises of SASL2 was that you would be able to
> negotiate various other things at the same time as authenticating. For
> example, this quote from the original XEP:
>
> "In order to provide support for other desired stream states beyond
> authentication, additional child elements are used. For example, a
> hypothetical XEP-0198 session resumption element might be included,
> and/or Resource Binding requests."
>
> To make it easier to talk about, I generally refer to this feature as
> "inlining" (which is different to pipelining, another similar method
> to reduce round-trips).
>
> While implementing, I quickly realised that the server supporting
> SASL2 and also supporting XEP-0198 is not enough information to
> determine that the server supports negotiating XEP-0198 inline within
> SASL2. For this reason we added the element within the SASL2
> stream feature element. This lists the features that are
> supported for SASL2 inlining. An example of this can be found here:
> https://dyn.eightysoft.de/final/xep-0388.html#example-2
>
> It's important to stress that, despite calling out XEP-0198 and Bind 2
> in the changelog and text, this is intended for example purposes only.
> There is no intention to increase the scope of XEP-0388 to cover which
> specific protocols can be negotiated (in fact this is the whole reason
> for introducing as an extension point).
>
> Therefore, the exact rules for handling inlining of features are to be
> specified elsewhere. For example, there is a proposed update to
> XEP-0198 for exactly this: https://github.com/xsf/xeps/pull/1215
>
> I have also submitted an update proposal for XEP-0386 Bind 2, which
> uses to advertise support (it will need to be revised if
> is not accepted).
>
> 2)
>
> One thing that has always frustrated me with our current
> authentication flow is that things like per-device credentials were
> impossible to do (securely). It's possible for e.g. PLAIN that a
> server could iterate through a list of acceptable passwords. But this
> doesn't work for more advanced mechanisms such as SCRAM. The same
> issue applies to token authentication, if we want to support fancier
> mechanisms such as Florian's HT-* proposal.
>
> We solved this by adding a stable client identifier. Its value and
> lifetime are client-chosen, but it allows the server to scope
> credentials to a specific client. This allows per-device credentials,
> more advanced authentication flows, and finally opens up the door to
> being able to view and manage what clients currently have access to
> your account (something that is invisible when all you have is a
> single password shared across all your clients).
>
> It also provides a foundation for many other advanced features, such
> as the server being able to associate things like push registrations
> to specific clients, and therefore stop pushing data to client
> developer push services if you no longer use their client (although we
> already attempt such cleanup, it's pretty hacky and unreliable right
> now).
>
> As well as the client identifier, the element optionally allows the
> client to include software and platform name. This can be used for
> diagnostic purposes ("what is this client that always fails to
> connect?") as well as allowing the server to provide more information
> to users about what is accessing their account.
>
> Now, there are some other changes in this update. My reading of Dave's
> review is that features related to specific mechanisms (such as the
> SCRAM upgrade) are out of scope for this document. I think I agree
> with that assessment. Likewise, channel binding is already covered by
> XEP-0440 and individual mechanisms. It would be good to keep this XEP
> as a mechanism-agnostic framework.
>
> Finally, I'm on the fence about one thing: switching the task syntax
> from base64 data to XML (and separately, dropping the
> / framework). I'll start a separate thread about this,
> as it probably
Re: [Standards] XEP-0388: SASL2 enhancements
Hi Florian, On Tue, 18 Oct 2022 at 18:55, Florian Schmaus wrote: > On 18/10/2022 16.01, Matthew Wild wrote: > > 1) Advertisement of supported "inline" features > > […] > > While implementing, I quickly realised that the server supporting > > SASL2 and also supporting XEP-0198 is not enough information to > > determine that the server supports negotiating XEP-0198 inline within > > SASL2. For this reason we added the element within the SASL2 > > stream feature element. This lists the features that are > > supported for SASL2 inlining. An example of this can be found here: > > https://dyn.eightysoft.de/final/xep-0388.html#example-2 > > …do we really need ? > > Couldn't clients create a sasl2 nonza, opportunistically > adding all extensions the client suspects, derived from the stream > features, that server supports via bind2? Then we only need to require > that the server (briefly) acknowledges each supported feature in the > response, which is potentially already the case for the majority of > features. I don't immediately see a reason why this really couldn't work, but it seems a bit awkward to me. Firstly, some extensions (such as bind2) can get a bit verbose, and I guess it's potentially a bunch of duplicated traffic on every connection. Also, it assumes that everything has a response from the server. New Bind 2 has a similar model, and there CSI does not have a response (just like when it's not inlined). > Features that the server does not support via sasl2, and hence where not > acknowledged, could be enabled "traditionally" by the client. This is > something clients may want to support anyway, in case the server does > not announce the feature , but otherwise supports it. Or am I > mistaken here? I don't see why a server would support inlining a feature but not announce it correctly. > In any case, I feel that , and related mechanisms, is more > bind2 territory than sasl2. If stays in sasl2, then wouldn't > we potentially end-up with in bind2 too? New Bind 2 does indeed have its own too :) The split is between things that are enabled before resource binding, and those that are enabled after resource binding. You can see an example here: https://matthewwild.co.uk/uploads/xeps-tmp/xep-0386.html#example-1 > Luckily we appear to have already some implementations of the proposed > protocol (changes). Could the maintainers of such implementations maybe > provide some real world exchanges of the (currently) most sophisticated > sasl2 XMPP-session establishments currently being performed. I am > thinking of MAM, carbons, SM resumption, and more. I would like to get a > better understanding how sasl2 can be used with existing widely-deployed > protocols and with bind2. Or is bind2 outside the scope (for now?)? New Bind 2 is already implemented by at least Prosody, Conversations and Monal. We learnt a lot from our collaboration and testing, and have tweaked and improved various things along the way as we discovered what did and didn't work well during implementation. Overall, I'm pretty happy with what we have working. I think we have the opportunity right now to determine a new login flow that will see us through the next 20 years of XMPP. Over the past couple of decades we've bolted various things on (XEP-0198, carbons, etc.) that are almost universally implemented. This has led to the stream setup process getting quite difficult to explain to newcomers, increased complexity in clients and gradually worse performance on poor networks due to the required round-trips. We all knew about the problem - SASL2 and Bind 2 have been waiting in the wings for a while now, and combined together they allow the client to describe its desired stream state to the server, and the server to respond with the final state. Ideally these updates provide the XEPs with enough polish to make implementations practical and useful. Once SASL2/Bind2/XEP-0198 updates have settled, I plan to write up an informational XEP, mostly of examples, demonstrating possible connection flows. Meanwhile, as requested, here is an example flow from a real client (with some replacement of identifiers, etc.): https://matthewwild.co.uk/uploads/sasl2-example.xml In this flow, the client is using token auth, but SCRAM would be pretty much the same with the addition of a and in the middle. As well as resource binding, it also shows the client requesting to resume a XEP-0198 session, but the server responds that the session has expired. Because of this, the server proceeds to process the resource bind request, which includes a request to enable XEP-0198, and a new session is successfully established. Hopefully this helps put some of this stuff into context. Regards, Matthew ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0388: SASL2 enhancements
Thanks Matt (and others) for pursuing this, IMHO very worthwhile goal. I think I like what I've seen so far, but… On 18/10/2022 16.01, Matthew Wild wrote: 1) Advertisement of supported "inline" features […] While implementing, I quickly realised that the server supporting SASL2 and also supporting XEP-0198 is not enough information to determine that the server supports negotiating XEP-0198 inline within SASL2. For this reason we added the element within the SASL2 stream feature element. This lists the features that are supported for SASL2 inlining. An example of this can be found here: https://dyn.eightysoft.de/final/xep-0388.html#example-2 …do we really need ? Couldn't clients create a sasl2 nonza, opportunistically adding all extensions the client suspects, derived from the stream features, that server supports via bind2? Then we only need to require that the server (briefly) acknowledges each supported feature in the response, which is potentially already the case for the majority of features. Features that the server does not support via sasl2, and hence where not acknowledged, could be enabled "traditionally" by the client. This is something clients may want to support anyway, in case the server does not announce the feature , but otherwise supports it. Or am I mistaken here? In any case, I feel that , and related mechanisms, is more bind2 territory than sasl2. If stays in sasl2, then wouldn't we potentially end-up with in bind2 too? Luckily we appear to have already some implementations of the proposed protocol (changes). Could the maintainers of such implementations maybe provide some real world exchanges of the (currently) most sophisticated sasl2 XMPP-session establishments currently being performed. I am thinking of MAM, carbons, SM resumption, and more. I would like to get a better understanding how sasl2 can be used with existing widely-deployed protocols and with bind2. Or is bind2 outside the scope (for now?)? - Flow OpenPGP_signature Description: OpenPGP digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XEP-0388: SASL2 enhancements
Hi folks,
For context, there is an update to XEP-0388 (SASL2) pending:
PR: https://github.com/xsf/xeps/pull/1214
HTML: https://dyn.eightysoft.de/final/xep-0388.html
HTML (diff): https://matthewwild.co.uk/uploads/xep-0388-diff.html
As per policy, we're bringing any substantial discussion to the
mailing list. Nevertheless, you'll find an initial review by Dave
(original author of the XEP) at the above link.
We have quite a few prototype implementations of (many of) the new
changes already in Prosody, Conversations, Monal, Gajim and Siskin.
The main changes that I'm interested in are the following:
1) Advertisement of supported "inline" features
One of the initial premises of SASL2 was that you would be able to
negotiate various other things at the same time as authenticating. For
example, this quote from the original XEP:
"In order to provide support for other desired stream states beyond
authentication, additional child elements are used. For example, a
hypothetical XEP-0198 session resumption element might be included,
and/or Resource Binding requests."
To make it easier to talk about, I generally refer to this feature as
"inlining" (which is different to pipelining, another similar method
to reduce round-trips).
While implementing, I quickly realised that the server supporting
SASL2 and also supporting XEP-0198 is not enough information to
determine that the server supports negotiating XEP-0198 inline within
SASL2. For this reason we added the element within the SASL2
stream feature element. This lists the features that are
supported for SASL2 inlining. An example of this can be found here:
https://dyn.eightysoft.de/final/xep-0388.html#example-2
It's important to stress that, despite calling out XEP-0198 and Bind 2
in the changelog and text, this is intended for example purposes only.
There is no intention to increase the scope of XEP-0388 to cover which
specific protocols can be negotiated (in fact this is the whole reason
for introducing as an extension point).
Therefore, the exact rules for handling inlining of features are to be
specified elsewhere. For example, there is a proposed update to
XEP-0198 for exactly this: https://github.com/xsf/xeps/pull/1215
I have also submitted an update proposal for XEP-0386 Bind 2, which
uses to advertise support (it will need to be revised if
is not accepted).
2)
One thing that has always frustrated me with our current
authentication flow is that things like per-device credentials were
impossible to do (securely). It's possible for e.g. PLAIN that a
server could iterate through a list of acceptable passwords. But this
doesn't work for more advanced mechanisms such as SCRAM. The same
issue applies to token authentication, if we want to support fancier
mechanisms such as Florian's HT-* proposal.
We solved this by adding a stable client identifier. Its value and
lifetime are client-chosen, but it allows the server to scope
credentials to a specific client. This allows per-device credentials,
more advanced authentication flows, and finally opens up the door to
being able to view and manage what clients currently have access to
your account (something that is invisible when all you have is a
single password shared across all your clients).
It also provides a foundation for many other advanced features, such
as the server being able to associate things like push registrations
to specific clients, and therefore stop pushing data to client
developer push services if you no longer use their client (although we
already attempt such cleanup, it's pretty hacky and unreliable right
now).
As well as the client identifier, the element optionally allows the
client to include software and platform name. This can be used for
diagnostic purposes ("what is this client that always fails to
connect?") as well as allowing the server to provide more information
to users about what is accessing their account.
Now, there are some other changes in this update. My reading of Dave's
review is that features related to specific mechanisms (such as the
SCRAM upgrade) are out of scope for this document. I think I agree
with that assessment. Likewise, channel binding is already covered by
XEP-0440 and individual mechanisms. It would be good to keep this XEP
as a mechanism-agnostic framework.
Finally, I'm on the fence about one thing: switching the task syntax
from base64 data to XML (and separately, dropping the
/ framework). I'll start a separate thread about this,
as it probably needs more discussion and this email is long enough
already.
Regards,
Matthew
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
