18 Mar
2024
18 Mar
'24
2:59 a.m.
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(a)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!
18 Mar
18 Mar
8:19 a.m.
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
11:24 a.m.
On Mon, 18 Mar 2024 at 14:19, Stephen Paul Weber <singpolyma(a)singpolyma.net>
wrote:
That's not the purview of a SASL profile. If a SASL mechanism supports
multiple credentials, that's entirely encapsulated within that mechanism.
There's XEP-0400, actually, which defines two tasks.
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
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
11:32 a.m.
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.
11:58 a.m.
On Mon, 18 Mar 2024, 17:32 Stephen Paul Weber, <singpolyma(a)singpolyma.net>
wrote:
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.
_______________________________________________
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. Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
4:10 p.m.
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)
11:22 a.m.
On Mon, 18 Mar 2024 at 09:00, Daniel Gultsch <daniel(a)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(a)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(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
7:25 p.m.
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. :)
22 Mar
22 Mar
2:45 a.m.
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(a)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
4:27 a.m.
On Fri, Mar 22, 2024 at 9:46 AM Florian Schmaus <flo(a)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
59
days inactive
63
days old
9 comments
6 participants
participants (6)
-
Daniel Gultsch -
Dave Cridland -
Florian Schmaus -
Linus Jahn -
Stephen Paul Weber -
Thilo Molitor