LAST CALL: XEP-0388 (Extensible SASL Profile)
This message constitutes notice of a Last Call for comments on XEP-0388. Title: Extensible SASL Profile Abstract: This document describes a replacement for the SASL profile documented in RFC 6120 which allows for greater extensibility. URL: https://xmpp.org/extensions/xep-0388.html This Last Call begins today and shall end at the close of business on 2024-04-01. Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? 2. Does the specification solve the problem stated in the introduction and requirements? 3. Do you plan to implement this specification in your code? If not, why not? 4. Do you have any security concerns related to this specification? 5. Is the specification accurate and clearly written? Your feedback is appreciated!
1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?
Yes, we currently have no way to use multiple SASL or otherwise to acheive a similar result.
2. Does the specification solve the problem stated in the introduction and requirements?
Yes. However it does lack any way to support indicating to the server which credential will be used, other than perhaps by implication from the SASL mechanism.
3. Do you plan to implement this specification in your code? If not, why not?
Yes, I have implemented this for xmpp.js -- except for "tasks" which I have not implemented and I think there are no official profiles of, making that a somewhat more risky area of the spec.
4. Do you have any security concerns related to this specification?
No, only usability concerns outlined above
5. Is the specification accurate and clearly written?
Yes
On Mon, 18 Mar 2024 at 14:19, Stephen Paul Weber <singpolyma@singpolyma.net> wrote:
1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?
Yes, we currently have no way to use multiple SASL or otherwise to acheive a similar result.
2. Does the specification solve the problem stated in the introduction and requirements?
Yes. However it does lack any way to support indicating to the server which credential will be used, other than perhaps by implication from the SASL mechanism.
That's not the purview of a SASL profile. If a SASL mechanism supports multiple credentials, that's entirely encapsulated within that mechanism.
3. Do you plan to implement this specification in your code? If not, why not?
Yes, I have implemented this for xmpp.js -- except for "tasks" which I have not implemented and I think there are no official profiles of, making that a somewhat more risky area of the spec.
There's XEP-0400, actually, which defines two tasks.
4. Do you have any security concerns related to this specification?
No, only usability concerns outlined above
5. Is the specification accurate and clearly written?
Yes _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
However it does lack any way to support indicating to the server which credential will be used, other than perhaps by implication from the SASL mechanism.
That's not the purview of a SASL profile. If a SASL mechanism supports multiple credentials, that's entirely encapsulated within that mechanism.
Except that it is not. For example all of the SCRAM-SASL-* profiles can easily support authentication with any of the passwords on an account, but they need to know in advance which one is being used. So SASL mechanism is insufficient for selecting credential by itself. The same goes for the HT-* token mechanisms.
On Mon, 18 Mar 2024, 17:32 Stephen Paul Weber, <singpolyma@singpolyma.net> wrote:
However it does lack any way to support indicating to the server which credential will be used, other than perhaps by implication from the SASL mechanism.
That's not the purview of a SASL profile. If a SASL mechanism supports multiple credentials, that's entirely encapsulated within that mechanism.
Except that it is not. For example all of the SCRAM-SASL-* profiles can easily support authentication with any of the passwords on an account, but they need to know in advance which one is being used. So SASL mechanism is insufficient for selecting credential by itself.
The same goes for the HT-* token mechanisms.
Yes, I mean, the SASL profile itself doesn't do anything there. If you want to indicate a particular credential, you could use the authentication identifier to select which, and the authorization identifier might remain the same. Or a mechanism might support multiple credentials. But the SASL profile isn't involved here. _______________________________________________
Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
Yes, I have implemented this for xmpp.js -- except for "tasks" which I have not implemented and I think there are no official profiles of, making that a somewhat more risky area of the spec.
There is a task defined in XEP-0480 (for upgrading server-stored SCRAM hashes, for example from SHA-1 to SHA-256)
On Mon, 18 Mar 2024 at 09:00, Daniel Gultsch <daniel@gultsch.de> wrote:
This message constitutes notice of a Last Call for comments on XEP-0388.
Title: Extensible SASL Profile Abstract: This document describes a replacement for the SASL profile documented in RFC 6120 which allows for greater extensibility.
URL: https://xmpp.org/extensions/xep-0388.html
This Last Call begins today and shall end at the close of business on 2024-04-01.
Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list:
1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?
Well, I think so, yes.
2. Does the specification solve the problem stated in the introduction and requirements?
Again, I believe so.
3. Do you plan to implement this specification in your code? If not, why not?
I implemented this some time ago in order to get TOTP working in Openfire - I never merged the code into the main branch, but it is available.
4. Do you have any security concerns related to this specification?
Not that aren't already specified.
5. Is the specification accurate and clearly written?
I can't really judge this; but after implementing it I did do a sweep over it in order to tidy it up. I have noticed that Example 8 no longer has the additional data Base64 encoded, which is wrong, so this needs fixing prior to advancing it. It also spoils the joke.
Your feedback is appreciated! _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
This message constitutes notice of a Last Call for comments on XEP-0388.
Title: Extensible SASL Profile Abstract: This document describes a replacement for the SASL profile documented in RFC 6120 which allows for greater extensibility.
URL: https://xmpp.org/extensions/xep-0388.html
This Last Call begins today and shall end at the close of business on 2024-04-01.
I implemeted it in QXmpp and I think it solves important issues. The only thing I noticed when implementing it is that the XML schema misses the elements <user-agent/>, <failure/> and <task-data/>. That should probably be fixed. :)
On 18/03/2024 09.59, Daniel Gultsch wrote:
This message constitutes notice of a Last Call for comments on XEP-0388.
Title: Extensible SASL Profile Abstract: This document describes a replacement for the SASL profile documented in RFC 6120 which allows for greater extensibility.
URL: https://xmpp.org/extensions/xep-0388.html
This Last Call begins today and shall end at the close of business on 2024-04-01.
Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list:
1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?
Yes.
2. Does the specification solve the problem stated in the introduction and requirements?
Yes.
3. Do you plan to implement this specification in your code? If not, why not?
No immediate plans, due the lack of resources on my end. However, it is consensus that SASL2 and Bind2 are the frontier of current XMPP stream/session establishment and hence are, or at least will become, highly relevant. And the fundamental design of both is solid and incorporates our experience with the current design.
4. Do you have any security concerns related to this specification?
None at the moment.
5. Is the specification accurate and clearly written?
Just some random remarks: - § 2.2 specifies that Base 64 encoding is used but does not reference the specification for Base 64. Also, there are multiple flavors of Base64, we may want to clarify which one is used. - § 2.4 mandates that "Servers MUST disconnect Clients immediately if any other traffic is received". Should we allow Servers to send a stream:error with some helpful information about the cause for the disconnect prior disconnecting? - It would be nice if the mentioned RFCs in the documented where actual linked references. - § 7. says 'None' whereas this XEP introduces a new namespace 'urn:xmpp:sasl:2' which should be registered in the registrars namespace registry (Yes I know that the XSF registrar is not in a good shape, but still). Thanks for working on SASL2. - Florian
On Fri, Mar 22, 2024 at 9:46 AM Florian Schmaus <flo@geekplace.eu> wrote:
- § 7. says 'None' whereas this XEP introduces a new namespace 'urn:xmpp:sasl:2' which should be registered in the registrars namespace registry (Yes I know that the XSF registrar is not in a good shape, but still).
Thanks. I've added that to my PR: https://github.com/xsf/xeps/pull/1333
participants (6)
-
Daniel Gultsch -
Dave Cridland -
Florian Schmaus -
Linus Jahn -
Stephen Paul Weber -
Thilo Molitor