Re: [Standards] XEP-0388

[Dave Cridland]

I can do on the list too - merge it, publish it, but add yourselves as
authors too.

On Fri, 13 Jan 2023 at 13:55, Thilo Molitor  wrote:

> > Dave approved the PR last week here:
> > https://github.com/xsf/xeps/pull/1214#pullrequestreview-1236512706
> Great, I've not hallucinated! At least partly (I thought he did so on
> list).
>
> -tmolitor
>
>
>
> ___
> 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: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0388

[Thilo Molitor]

> Dave approved the PR last week here:
> https://github.com/xsf/xeps/pull/1214#pullrequestreview-1236512706
Great, I've not hallucinated! At least partly (I thought he did so on list).

-tmolitor



___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0388

[Matthew Wild]

On Thu, 12 Jan 2023 at 17:14, Thilo Molitor  wrote:
> To bring this to the list, too:
> I thought Dave did approve the PR #1214 here on list, but could not find his
> mail. Maybe I just hallucinated the approval?

Dave approved the PR last week here:
https://github.com/xsf/xeps/pull/1214#pullrequestreview-1236512706

Regards,
Matthew
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] XEP-0388

[Thilo Molitor]

To bring this to the list, too:
I thought Dave did approve the PR #1214 here on list, but could not find his 
mail. Maybe I just hallucinated the approval?

So @dwd: could you either please approve the PR or tell us (here on list) what 
to change?
It would be super cool to move forward with SASL2 and leave this stuck state 
where the missing approval of the SASL2 update is blocking several other XEP 
updates and new XEPs.

-tmolitor



___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0388 SASL2: #2 Inline features

[Andrzej Wójcik]

As someone who also implemented SASL2, Bind2, FAST & SM as a SASL2 features,
I do think that wrapping subsequent stream features in  makes a lot of 
sense.
It is not only convenient for developers (as they need to pass just  
element as
Daniel mentioned), but it also makes it easier to understand which features are 
available
after SASL2 and Bind2. It is the same as in the classic XMPP stream 
establishment process
when subsequent stream openings a different set of features is advertised 
(separate in 
a separate stream features element). With  element we have the same 
separation
which will not be achieved if we would just inline those features directly in 
the stream features
(even if we would make a way to distinguish features available after SASL2 from 
other stream
features).

Moreover, from my understanding of RFC 6120 (I know it may not be written 
anywhere),
I would always assume that each feature advertised in the stream features sent 
by the
server may always be used just after receiving this stream features set and I 
do not need to
do any other establishment before being able to use any of those new features. 
That is
something which would change if we would inline features from  
directly into 
stream features.

Regards,
Andrzej Wójcik

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0388 SASL2: #2 Inline features

[Daniel Gultsch]

While  wrapper vs flat stream features is mostly just a
matter of syntactical preference as someone who has implemented SASL2,
Bind 2, FAST and SM as a SASL2 feature¹ I just want to say that the
inline wrapper elements make a lot of sense implementation wise. I’m
just passing the entire, de-serialized  element to my SASL 2
code or my Bind 2 code respectively.


I often hear "Let’s gather some implementation experience before
deciding how to proceed with XEP". I’m aware of several people who
have implemented parts or all of the SASL2/Bind2/SM stack and seem to
be quite happy with the  wrappers.


¹: https://github.com/xsf/xeps/pull/1215
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0388 SASL2: #2 Inline features

[Matthew Wild]

On Sat, 19 Nov 2022 at 19:09, Dave Cridland  wrote:
> On Sat, 19 Nov 2022 at 18:50, Matthew Wild  wrote:
>> > But supposing that the SASL2 extension part needs changing - in that case, 
>> > we need to bump the namespace of that - but we don't want to break 
>> > compatibility with the old-style stream feature. So now we have to 
>> > advertise a different stream feature if you're inlineing it, and then if 
>> > the main one changes but the ... you get the drift, I hope.

We've never bumped the SASL namespace that RFC 6120 defines. I think
it is unlikely we will ever want to bump SASL2's namespace once it is
widely deployed either. The extensibility SASL2 brings only makes it
even less likely that we'll ever want to do so.

If regularly bumping SASL2 *is* something we want to do, then we would
probably also want to split out things like the mechanism list, since
that is likely to be common across the different versions. We could
define a separate namespace for  (and ?!) that
stays stable even if we change the SASL2 namespace/syntax/semantics.
But this all seems very hypothetical and not realistic.

>> I don't really understand this concern. A XEP can specify anything to
>> be contained in . If the inlining portion of a XEP (only)
>> needs to change, then of course it will need to advertise that
>> somehow.  doesn't change that either way.
>>
>
> It means the features advertised in the  block are not simple 
> restatements of the same features outside; they are themselves distinct 
> features with a distinct lifecycle, only now we're advertising stream 
> features in multiple places.
>
> In effect, you're reinventing the stream feature mechanism inside another 
> stream feature.

Yes and no.  does not quite have the same semantics as
.

>> > Incidentally, if SASL2+BIND2+etc take over the world, then you'll be 
>> > repeating all these stream features and/or having all stream features 
>> > nesting eternally inside each other.

I'm not sure what you mean by "nesting eternally inside each other".

We need to advertise that a server supports inlining stream
management, and not just traditional stream management negotiation. I
think we're all agreed that this needs signalling of some kind. You
seem to prefer every extension defining an arbitrary new feature (e.g.
XEP-0198 could define ) and
the current proposal is that we group these features (which pertain
only to SASL 2 and/or Bind 2), and that also frees us from having to
invent new elements for all the existing extensions.

> I find advertising some stream features only inside other stream features an 
> additional complexity that's not warranted.

These are not just more "stream features", but specifically a
description of the things that are supported for inlining. Having this
presented in one place is more convenient than having the elements
mixed up with other (actual) stream features.

Regards,
Matthew
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0388 SASL2: #2 Inline features

[Matthew Wild]

On Sat, 19 Nov 2022 at 20:00, Florian Schmaus  wrote:
> Authenticated but unbound connections seem to something worth
> sacrificing if it makes SASL 2 + Bind 2 significantly less complex
> (which I believe it does). Or am I missing an important use case for
> those kind of connections?

I personally can't come up with any use-case for such connections. In
the past it was possible to bind zero, one or many resources on a
stream. Thankfully we've settled on one these days, and I don't see a
purpose for zero or many.

Nevertheless, even with Bind 2 integrating with SASL 2, I don't see
that merging the documents will make anything "significantly less
complex". It could quite easily be argued that the opposite is true.
SASL is about authenticating the stream, and resource binding is more
focused on session establishment. We also trend towards smaller specs
these days (nobody wants another XEP-0045 or XEP-0060 if we can help
it).

Regards,
Matthew
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0388 SASL2: #1 client-identifier

[Matthew Wild]

On Sat, 19 Nov 2022 at 19:02, Dave Cridland  wrote:
> On Sat, 19 Nov 2022 at 18:34, Matthew Wild  wrote:
>>
>> On Sat, 19 Nov 2022 at 15:14, Dave Cridland  wrote:
>> >
>> > I commented about this on the PR, but that seems to have been dismissed, 
>> > so again, for the list:
>> >
>> > * I'm not convinced this is required to be a mandatory feature of SASL2, 
>> > despite its obvious utility, but I'm not going to argue very strongly that 
>> > it shouldn't be.
>> > * I *am* convinced that an id attribute has to be mandatory (and SHOULD be 
>> > a UUIDv4).
>> > * I am also convinced that the human-readable software information 
>> > shouldn't be mandatory.
>>
>> I agree that neither of these should be mandatory, and that's why they
>> aren't. If there are reasons for clients not to include them, they
>> don't have to. Not including them may have consequences - e.g. the
>> FAST spec depends on the client id being present so wouldn't be
>> usable, and if the software info isn't included then the user will be
>> less informed about what is connecting to their account. For such
>> reasons, it is recommended that they are included. But mandatory, no.
>>
>
> Clients SHOULD also include a user-agent/> element, informing the 
> server about the connecting client. The 'id'
> attribute is RECOMMENDED, and if present it contains a unique stable 
> identifier for the client installation. This allows
> the server to provide functionality such as deriving stable resource 
> identifiers (see ). The child elements software/> and 
> device/> contain text descriptions of the client software and the device 
> it is installed on. These allow the server to keep the user informed
> about what devices are connected to their account. Servers MUST NOT expose 
> this information to other entities (such functionality is available in 
>  if required).
>
> So...
>
> The  isn't mandatory, no, and I stand corrected on my first 
> point. I'm not convinced this should be a part of SASL2, as such - but to be 
> clear, I'm not convinced it shouldn't be either.
>
> But if included, then the id isn't mandatory, which was my second point - I 
> think the id needs to be a MUST for this to have value, whether or not the 
> software info is supplied.
>
> The child elements aren't explicitly mandatory or optional in this paragraph, 
> but are included in every example. I'd assumed they were mandatory based on 
> this and the phrasing "The child elements ... contain" - no "if present" as 
> with the id attribute. Certainly it's very unclear if they're recommended, 
> optional, or mandatory. Is there some other text I'm missing? It's not in the 
> schema, as far as I can find, either.

That makes sense, thanks. I'll provide updated wording which clarifies
things. Taking each piece of information separately, the intent was
that each of them SHOULD be included by the client. However any or all
could be omitted with reason.

I don't know how I feel about making the inclusion of 'id' a MUST. If
a client can't or won't provide a stable identifier for whatever
reason, I'd sooner have such a client omit it entirely than, for
example, provide a changing id on every connection.

I'm in favour of saying that the identifier SHOULD/MUST be a UUIDv4.
That would alleviate some concerns I had about clients putting
inappropriate identifiers there, such as those that can be used to
identify the user/device in other contexts.

Regards,
Matthew
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0388 SASL2: #2 Inline features

[Florian Schmaus]

On 19/11/2022 19.27, Matthew Wild wrote:

On Sat, 19 Nov 2022 at 17:52, Florian Schmaus  wrote:

I was aware of what Daniel and you wrote. But that does not give an
answer why there *need* to be two places. What would break if there was
only one?


It wouldn't be logical if it was only advertised in one place (which
one place would you choose?).


Similar, the client's response to the server's features is currently



dXNlcm5hbWUAYWJjMTIzYWJjMTIzYWJjMTIzYWJjMTIz

  Conversations


  Conversations
  
  






Why not shove everything into a single place here (e.g. under )?


Because you might do SASL2 without binding, for example (not a common
case I'm sure, but it's possible already today with traditional
SASL/bind). Also note that In this example  is optional, since
the client says it would prefer to resume an existing session if
possible.


Authenticated but unbound connections seem to something worth 
sacrificing if it makes SASL 2 + Bind 2 significantly less complex 
(which I believe it does). Or am I missing an important use case for 
those kind of connections?


- Flow


OpenPGP_signature
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0388 SASL2: #2 Inline features

[Thilo Molitor]

Am Samstag, 19. November 2022, 20:08:17 CET schrieb Dave Cridland:
> > Incidentally, if SASL2+BIND2+etc take over the world, then you'll be
> > repeating all these stream features and/or having all stream features
> > nesting eternally inside each other.
> > 
> > I don't see how  adds any need for repetition. If 
> > didn't exist, everything still has to indicate in some way whether it
> > can be inlined or not. Sure, we can have  and
> >  features perhaps, but I find  is a much
> > cleaner and more logically obvious solution to this issue.
> 
> I find advertising some stream features only inside other stream features
> an additional complexity that's not warranted.

I'd argue that this makes things even clearer rather than more complicated, 
because it clearly states that these stream features could be inlined into 
SASL2 by logically moving them into the SASL2 hierarchy.

Suppose, for example, we'd have something like SASL3, also supporting 
inlining.
That would list 3 stream features all beneath each other.
Their naming would have to be such that it would be clear if they belonged to 
SASL2, SASL3 or the old non-inlining way of SASL1.

Moving them logically into the SASL2 (or SASL3) elements releases you from the 
burden to invent new names for the same thing over and over again.

-tmolitor



___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0388 SASL2: #2 Inline features

[Dave Cridland]

On Sat, 19 Nov 2022 at 18:50, Matthew Wild  wrote:

> On Sat, 19 Nov 2022 at 18:31, Dave Cridland  wrote:
> > On Sat, 19 Nov 2022 at 16:33, Daniel Gultsch  wrote:
> >>
> >> The  stream feature wrapper is just a neat wrapper for all
> >> stream features that can be inlined into SASL to announce themselves.
> >> Yes ISR works without inline but that's not the point.
> >>
> >
> > Well, that wasn't in fact the point I was making there - I meant the
>  element within the TLEs.
> >
> > But you're right, neither adds any actionable information whatsoever, so
> isn't useful and therefore should not be added.
> >
> >>
> >> Imagine we want to make compression inline-able. Simply by looking at
> >> the  stream feature a client doesn’t know if compression
> >> can be inlined into SASL. So if we want to make compression inlinable
> >> the new XEP (or an amendment to the existing XEP) would have to either
> >> announce a new stream feature called  (This is
> >> kind of - but not really - what ISR is doing) or place itself in the
> >>  wrapper like this: 
> >>
> >
> > OK, so compression, let's take that as a worked example.
> >
> > A client absolutely knows that XEP-0138 isn't a XEP-0388 extension,
> because it isn't.
> >
> > You cannot simply advertise it in an  block and expect it to
> work, either. When would compression kick in? There's no specification that
> tells you. It might be obvious to you - it might even be obvious to me -
> but it's not specified, and my obvious may not match yours. So you need to
> define what that means, and it's a change in wire protocol, so implicitly
> that means that something new has to be advertised.
>
> I agree, you cannot just advertise anything in an  block and
> expect it to work. Nobody thinks that. Every protocol that supports
> inlining has specified exactly what that means. E.g. XEP-0198 has been
> updated with an additional section to cover this.
>
> Now I'll add that your suggestion also doesn't work: you can't just
> spec something and then expect it to work. Just because we update
> XEP-0198 with a section that describes how it can be inlined, that
> doesn't mean every server supporting SASL2 automatically understands
> XEP-0198 inlining. And as you pointed out, things may change over
> time. In other words, we *need* advertisement and discovery for this
> feature.
>
>
Yes, of course.

So we agree that a SASL2 variant of an existing extension has to have a
stream feature.


> >> It's just a syntax modification that some people find more pleasent;
> >> not a new addition to the XEP to achieve something that wasn’t
> >> possible before.
> >
> > Oh, but it carries all manner of implications.
> >
> > Supposing that we change the wire protocol of XEP-0198 to support
> directly using it as a SASL2 extension. So that means advertising the same
> stream feature under , by this design. So far, so good.
> >
> > But supposing that the SASL2 extension part needs changing - in that
> case, we need to bump the namespace of that - but we don't want to break
> compatibility with the old-style stream feature. So now we have to
> advertise a different stream feature if you're inlineing it, and then if
> the main one changes but the ... you get the drift, I hope.
>
> I don't really understand this concern. A XEP can specify anything to
> be contained in . If the inlining portion of a XEP (only)
> needs to change, then of course it will need to advertise that
> somehow.  doesn't change that either way.
>
>
It means the features advertised in the  block are not simple
restatements of the same features outside; they are themselves distinct
features with a distinct lifecycle, only now we're advertising stream
features in multiple places.

In effect, you're reinventing the stream feature mechanism inside another
stream feature.

> Incidentally, if SASL2+BIND2+etc take over the world, then you'll be
> repeating all these stream features and/or having all stream features
> nesting eternally inside each other.
>
> I don't see how  adds any need for repetition. If 
> didn't exist, everything still has to indicate in some way whether it
> can be inlined or not. Sure, we can have  and
>  features perhaps, but I find  is a much
> cleaner and more logically obvious solution to this issue.
>

I find advertising some stream features only inside other stream features
an additional complexity that's not warranted.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0388 SASL2: #1 client-identifier

[Dave Cridland]

On Sat, 19 Nov 2022 at 18:34, Matthew Wild  wrote:

> On Sat, 19 Nov 2022 at 15:14, Dave Cridland  wrote:
> >
> > I commented about this on the PR, but that seems to have been dismissed,
> so again, for the list:
> >
> > * I'm not convinced this is required to be a mandatory feature of SASL2,
> despite its obvious utility, but I'm not going to argue very strongly that
> it shouldn't be.
> > * I *am* convinced that an id attribute has to be mandatory (and SHOULD
> be a UUIDv4).
> > * I am also convinced that the human-readable software information
> shouldn't be mandatory.
>
> I agree that neither of these should be mandatory, and that's why they
> aren't. If there are reasons for clients not to include them, they
> don't have to. Not including them may have consequences - e.g. the
> FAST spec depends on the client id being present so wouldn't be
> usable, and if the software info isn't included then the user will be
> less informed about what is connecting to their account. For such
> reasons, it is recommended that they are included. But mandatory, no.
>
>
Clients SHOULD also include a user-agent/> element, informing the
server about the connecting client. The 'id'
attribute is RECOMMENDED, and if present it contains a unique stable
identifier for the client installation. This allows
the server to provide functionality such as deriving stable resource
identifiers (see ). The child elements software/> and device/>
contain text descriptions of the client software and the device it is
installed on. These allow the server to keep the user informed
about what devices are connected to their account. Servers MUST NOT expose
this information to other entities (such functionality is available in
 if required).

So...

The  isn't mandatory, no, and I stand corrected on my first
point. I'm not convinced this should be a part of SASL2, as such - but to
be clear, I'm not convinced it shouldn't be either.

But if included, then the id isn't mandatory, which was my second point - I
think the id needs to be a MUST for this to have value, whether or not the
software info is supplied.

The child elements aren't explicitly mandatory or optional in this
paragraph, but are included in every example. I'd assumed they were
mandatory based on this and the phrasing "The child elements ... contain" -
no "if present" as with the id attribute. Certainly it's very unclear if
they're recommended, optional, or mandatory. Is there some other text I'm
missing? It's not in the schema, as far as I can find, either.


> Regards,
> Matthew
> ___
> 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: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0388 SASL2: #2 Inline features

[Matthew Wild]

On Sat, 19 Nov 2022 at 18:31, Dave Cridland  wrote:
> On Sat, 19 Nov 2022 at 16:33, Daniel Gultsch  wrote:
>>
>> The  stream feature wrapper is just a neat wrapper for all
>> stream features that can be inlined into SASL to announce themselves.
>> Yes ISR works without inline but that's not the point.
>>
>
> Well, that wasn't in fact the point I was making there - I meant the 
>  element within the TLEs.
>
> But you're right, neither adds any actionable information whatsoever, so 
> isn't useful and therefore should not be added.
>
>>
>> Imagine we want to make compression inline-able. Simply by looking at
>> the  stream feature a client doesn’t know if compression
>> can be inlined into SASL. So if we want to make compression inlinable
>> the new XEP (or an amendment to the existing XEP) would have to either
>> announce a new stream feature called  (This is
>> kind of - but not really - what ISR is doing) or place itself in the
>>  wrapper like this: 
>>
>
> OK, so compression, let's take that as a worked example.
>
> A client absolutely knows that XEP-0138 isn't a XEP-0388 extension, because 
> it isn't.
>
> You cannot simply advertise it in an  block and expect it to work, 
> either. When would compression kick in? There's no specification that tells 
> you. It might be obvious to you - it might even be obvious to me - but it's 
> not specified, and my obvious may not match yours. So you need to define what 
> that means, and it's a change in wire protocol, so implicitly that means that 
> something new has to be advertised.

I agree, you cannot just advertise anything in an  block and
expect it to work. Nobody thinks that. Every protocol that supports
inlining has specified exactly what that means. E.g. XEP-0198 has been
updated with an additional section to cover this.

Now I'll add that your suggestion also doesn't work: you can't just
spec something and then expect it to work. Just because we update
XEP-0198 with a section that describes how it can be inlined, that
doesn't mean every server supporting SASL2 automatically understands
XEP-0198 inlining. And as you pointed out, things may change over
time. In other words, we *need* advertisement and discovery for this
feature.

>> It's just a syntax modification that some people find more pleasent;
>> not a new addition to the XEP to achieve something that wasn’t
>> possible before.
>
> Oh, but it carries all manner of implications.
>
> Supposing that we change the wire protocol of XEP-0198 to support directly 
> using it as a SASL2 extension. So that means advertising the same stream 
> feature under , by this design. So far, so good.
>
> But supposing that the SASL2 extension part needs changing - in that case, we 
> need to bump the namespace of that - but we don't want to break compatibility 
> with the old-style stream feature. So now we have to advertise a different 
> stream feature if you're inlineing it, and then if the main one changes but 
> the ... you get the drift, I hope.

I don't really understand this concern. A XEP can specify anything to
be contained in . If the inlining portion of a XEP (only)
needs to change, then of course it will need to advertise that
somehow.  doesn't change that either way.

> So repeating the same stream feature inside a SASL2 stream feature as 
>  isn't actually what you want.
>
> You do, genuinely, just want a new stream feature.

There's no rule that you have to repeat the same stream feature inside
.

> Incidentally, if SASL2+BIND2+etc take over the world, then you'll be 
> repeating all these stream features and/or having all stream features nesting 
> eternally inside each other.

I don't see how  adds any need for repetition. If 
didn't exist, everything still has to indicate in some way whether it
can be inlined or not. Sure, we can have  and
 features perhaps, but I find  is a much
cleaner and more logically obvious solution to this issue.

Regards,
Matthew
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0388 SASL2: #2 Inline features

[Daniel Gultsch]

On Sat, Nov 19, 2022 at 7:31 PM Dave Cridland  wrote:

> But supposing that the SASL2 extension part needs changing - in that case, we 
> need to bump the namespace of that - but we don't want to break compatibility 
> with the old-style stream feature. So now we have to advertise a different 
> stream feature if you're inlineing it, and then if the main one changes but 
> the ... you get the drift, I hope.

That's a fair point.

For what it's worth I’m not overly attached to the inside wrapper - I
just (wrongly?) assumed we weren’t all on the same page on what it
does.

cheers
Daniel
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0388 SASL2: #1 client-identifier

[Matthew Wild]

On Sat, 19 Nov 2022 at 15:14, Dave Cridland  wrote:
>
> I commented about this on the PR, but that seems to have been dismissed, so 
> again, for the list:
>
> * I'm not convinced this is required to be a mandatory feature of SASL2, 
> despite its obvious utility, but I'm not going to argue very strongly that it 
> shouldn't be.
> * I *am* convinced that an id attribute has to be mandatory (and SHOULD be a 
> UUIDv4).
> * I am also convinced that the human-readable software information shouldn't 
> be mandatory.

I agree that neither of these should be mandatory, and that's why they
aren't. If there are reasons for clients not to include them, they
don't have to. Not including them may have consequences - e.g. the
FAST spec depends on the client id being present so wouldn't be
usable, and if the software info isn't included then the user will be
less informed about what is connecting to their account. For such
reasons, it is recommended that they are included. But mandatory, no.

Regards,
Matthew
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0388 SASL2: #2 Inline features

[Daniel Gultsch]

On Sat, Nov 19, 2022 at 6:52 PM Florian Schmaus  wrote:

> Why not shove everything into a single place here (e.g. under )?
>
> xmlns="urn:xmpp:sasl:2">
>
> dXNlcm5hbWUAYWJjMTIzYWJjMTIzYWJjMTIzYWJjMTIz
>
>  Conversations
>
>
>  Conversations
>  
>  
>  
>  
>  
>  
>
> 

Because I find it very desirable to be able to do  and
 respectively without bind 2.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0388 SASL2: #2 Inline features

[Dave Cridland]

On Sat, 19 Nov 2022 at 16:33, Daniel Gultsch  wrote:

> The  stream feature wrapper is just a neat wrapper for all
> stream features that can be inlined into SASL to announce themselves.
> Yes ISR works without inline but that's not the point.
>
>
Well, that wasn't in fact the point I was making there - I meant the
 element within the TLEs.

But you're right, neither adds any actionable information whatsoever, so
isn't useful and therefore should not be added.


> Imagine we want to make compression inline-able. Simply by looking at
> the  stream feature a client doesn’t know if compression
> can be inlined into SASL. So if we want to make compression inlinable
> the new XEP (or an amendment to the existing XEP) would have to either
> announce a new stream feature called  (This is
> kind of - but not really - what ISR is doing) or place itself in the
>  wrapper like this: 
>
>
OK, so compression, let's take that as a worked example.

A client absolutely knows that XEP-0138 isn't a XEP-0388 extension, because
it isn't.

You cannot simply advertise it in an  block and expect it to work,
either. When would compression kick in? There's no specification that tells
you. It might be obvious to you - it might even be obvious to me - but it's
not specified, and my obvious may not match yours. So you need to define
what that means, and it's a change in wire protocol, so implicitly that
means that something new has to be advertised.

So, as you note, either way something new has to be advertised, so the
 there is just additional cruft.

But once negotiated, there's no need to put it in an  element in
the messages anyway - what value does that add? The entire syntax of SASL2
was explicitly designed to handle extension, that was literally a stated
goal.


> It's just a syntax modification that some people find more pleasent;
> not a new addition to the XEP to achieve something that wasn’t
> possible before.


Oh, but it carries all manner of implications.

Supposing that we change the wire protocol of XEP-0198 to support directly
using it as a SASL2 extension. So that means advertising the same stream
feature under , by this design. So far, so good.

But supposing that the SASL2 extension part needs changing - in that case,
we need to bump the namespace of that - but we don't want to break
compatibility with the old-style stream feature. So now we have to
advertise a different stream feature if you're inlineing it, and then if
the main one changes but the ... you get the drift, I hope.

So repeating the same stream feature inside a SASL2 stream feature as
 isn't actually what you want.

You do, genuinely, just want a new stream feature.

Incidentally, if SASL2+BIND2+etc take over the world, then you'll be
repeating all these stream features and/or having all stream features
nesting eternally inside each other.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0388 SASL2: #2 Inline features

[Matthew Wild]

On Sat, 19 Nov 2022 at 17:52, Florian Schmaus  wrote:
> I was aware of what Daniel and you wrote. But that does not give an
> answer why there *need* to be two places. What would break if there was
> only one?

It wouldn't be logical if it was only advertised in one place (which
one place would you choose?).

> Similar, the client's response to the server's features is currently
>
>  xmlns="urn:xmpp:sasl:2">
>
> dXNlcm5hbWUAYWJjMTIzYWJjMTIzYWJjMTIzYWJjMTIz
>
>  Conversations
>
>
>  Conversations
>  
>  
>
>
>
> 
>
>
> Why not shove everything into a single place here (e.g. under )?

Because you might do SASL2 without binding, for example (not a common
case I'm sure, but it's possible already today with traditional
SASL/bind). Also note that In this example  is optional, since
the client says it would prefer to resume an existing session if
possible.

The things outside of  are things that you negotiate separately
to (before) resource binding.

> Slightly related: I am getting a strong vibe that Bind 2 and SASL 2
> should be one document, as they appear to be tightly coupled.

We made the decision to make Bind 2 dependent on SASL 2 (that is, it
can't be used with SASL1 or outside of a SASL2 exchange), as it
significantly simplified some things. However there is no reverse
dependency: SASL 2, like traditional SASL, does not bind a resource. I
don't see a need to merge the two documents. There would be just as
strong arguments for merging XEP-0198, as that is also tightly linked
to the stream initialization process.

Regards,
Matthew
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0388 SASL2: #2 Inline features

[Florian Schmaus]

On 19/11/2022 18.39, Thilo Molitor wrote:

Am Samstag, 19. November 2022, 18:15:17 CET schrieb Daniel Gultsch:

On Sat, Nov 19, 2022 at 5:55 PM Florian Schmaus  wrote:

Why not simply





  SCRAM-SHA-1-PLUS

  PLAIN
  SCRAM-SHA-1
  


  
  





  SCRAM-SHA-1-PLUS

  PLAIN
  SCRAM-SHA-1





  





http://jabber.org/features/iq-register"/>




Because this would imply that carbons and CSI can be inlined into
SASL. That's not the same as the other example where they can be
inlined into bind2

(Which also answers your question on why SM is there twice)


Or, to explain it in more detail: with traditional xmpp you'd have two places
in the xmpp stream to do something: 1. after auth and 2. after bind.
Because inlining squeezes it all together, these two points in the xmpp stream
no longer exist. The two  elements therefore correspond exactly to
this two traditional points in the xmpp stream.

XEP-0198 can be enabled after bind and can be used to resume a stream without
bind directly after authentication. It can also be used to do only one of
these two.
That's the reason why it's mentioned in both inline blocks.
The occurrence in the SASL2  element means "resume" and the
occurrence in the bind2  means "enable".


I was aware of what Daniel and you wrote. But that does not give an 
answer why there *need* to be two places. What would break if there was 
only one?


Similar, the client's response to the server's features is currently

xmlns="urn:xmpp:sasl:2">


dXNlcm5hbWUAYWJjMTIzYWJjMTIzYWJjMTIzYWJjMTIz
  
Conversations
  
  
Conversations


  
  
  



Why not shove everything into a single place here (e.g. under )?



dXNlcm5hbWUAYWJjMTIzYWJjMTIzYWJjMTIzYWJjMTIz
  
Conversations
  
  
Conversations






  



Slightly related: I am getting a strong vibe that Bind 2 and SASL 2 
should be one document, as they appear to be tightly coupled.


- Flow


OpenPGP_signature
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0388 SASL2: #2 Inline features

[Thilo Molitor]

Am Samstag, 19. November 2022, 18:15:17 CET schrieb Daniel Gultsch:
> On Sat, Nov 19, 2022 at 5:55 PM Florian Schmaus  wrote:
> > Why not simply
> > 
> > 
> > 
> >
> >
> >  SCRAM-SHA-1-PLUS
> >  PLAIN
> >  SCRAM-SHA-1
> >  
> >
> >
> >  
> >  
> >
> >
> >
> >
> >  SCRAM-SHA-1-PLUS
> >  PLAIN
> >  SCRAM-SHA-1
> >
> >
> >
> >
> >  
> >
> >
> >
> >
> >http://jabber.org/features/iq-register"/>
> > 
> > 
> 
> Because this would imply that carbons and CSI can be inlined into
> SASL. That's not the same as the other example where they can be
> inlined into bind2
> 
> (Which also answers your question on why SM is there twice)

Or, to explain it in more detail: with traditional xmpp you'd have two places 
in the xmpp stream to do something: 1. after auth and 2. after bind.
Because inlining squeezes it all together, these two points in the xmpp stream 
no longer exist. The two  elements therefore correspond exactly to 
this two traditional points in the xmpp stream.

XEP-0198 can be enabled after bind and can be used to resume a stream without 
bind directly after authentication. It can also be used to do only one of 
these two.
That's the reason why it's mentioned in both inline blocks.
The occurrence in the SASL2  element means "resume" and the 
occurrence in the bind2  means "enable".

-tmolitor



___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0388 SASL2: #2 Inline features

[Daniel Gultsch]

On Sat, Nov 19, 2022 at 5:55 PM Florian Schmaus  wrote:

> Why not simply
>
> 
>
>  SCRAM-SHA-1-PLUS
>  PLAIN
>  SCRAM-SHA-1
>  
>
>
>  
>
>
>  SCRAM-SHA-1-PLUS
>  PLAIN
>  SCRAM-SHA-1
>
>
>  
>
>
>
>http://jabber.org/features/iq-register"/>
> 

Because this would imply that carbons and CSI can be inlined into
SASL. That's not the same as the other example where they can be
inlined into bind2

(Which also answers your question on why SM is there twice)
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0388 SASL2: #2 Inline features

[Florian Schmaus]

On 19/11/2022 16.16, Dave Cridland wrote:



On Sat, 22 Oct 2022 at 22:29, Thilo Molitor > wrote:


Again, MattJ already explained this well:
https://mail.jabber.org/pipermail/
standards/2022-October/038998.html


SASL2 allows for inlining additional elements into the
authentication flow.
That, like pipelining, reduces round-trip-times.
To let clients distinguish, which features can be inlined into the
SASL2
authentication flow and which features are supported by the server
but can not
be inlined, a new "namespace" for inlinable features is needed.


When I designed SASL2, I designed it such that arbitrary elements could 
be introduced anywhere in the flow by having them within SASL2 top-level 
elements. I certainly didn't intend to imply that this meant that 
clients could inject top-level-elements from other extensions that 
happened to be supported without negotiation. I'm not sure where that 
came from.


As MattJ says:
 > 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).

The Bind2 update already in our pipeline as well as the XEP-0198
update use
that  element as specified in our SASL2 update.

In fact, Bind2 has it's own  element, too.


ISR, for example - XEP-0397 - doesn't need the  element at all 
to handle XEP-0198.


You can argue it's too tied into HT-* or whatever, but the framework for 
adding extensions into SASL2 exists already and I'm honestly confused as 
to why a further  is needed here.


See the previous discussion on  at

https://mail.jabber.org/pipermail/standards/2022-October/038999.html

I am still not convinced that we need , but I urge the authors 
to at least consider


1. If we need it twice
2. To simply re-use the existing  element for that. 
There is no reason to introduce a new element.


For example, a SALS 2 + Bind 2 + FAST auth currently produces this [1]

  
SCRAM-SHA-1-PLUS
PLAIN
SCRAM-SHA-1

  

  
  
  

  
  
  

  
  
SCRAM-SHA-1-PLUS
PLAIN
SCRAM-SHA-1
  
  

  
  
  
  http://jabber.org/features/iq-register"/>


This is madness, err Sparta.

First, the  sometimes contains  var's, and sometimes 
not. And Stream Management (sm) is there twice.


Why not simply


  
SCRAM-SHA-1-PLUS
PLAIN
SCRAM-SHA-1

  
  

  
  
SCRAM-SHA-1-PLUS
PLAIN
SCRAM-SHA-1
  
  

  
  
  
  http://jabber.org/features/iq-register"/>


(Yes, I notice that there is no stream feature for carbons, but that 
shouldn't be a show stopper)


- Flow

1: https://matthewwild.co.uk/uploads/sasl2-example.xml
   from 
https://mail.jabber.org/pipermail/standards/2022-October/039000.html


OpenPGP_signature
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0388 SASL2: #1 client-identifier

[Daniel Gultsch]

On Sat, Nov 19, 2022 at 4:15 PM Dave Cridland  wrote:

> * I *am* convinced that an id attribute has to be mandatory (and SHOULD be a 
> UUIDv4).

I agree. That also gives it an automatic size limit

> * I am also convinced that the human-readable software information shouldn't 
> be mandatory.

I'm not sure it is. But if it is I agree that it shouldn’t
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0388 SASL2: #2 Inline features

[Daniel Gultsch]

The  stream feature wrapper is just a neat wrapper for all
stream features that can be inlined into SASL to announce themselves.
Yes ISR works without inline but that's not the point.

Imagine we want to make compression inline-able. Simply by looking at
the  stream feature a client doesn’t know if compression
can be inlined into SASL. So if we want to make compression inlinable
the new XEP (or an amendment to the existing XEP) would have to either
announce a new stream feature called  (This is
kind of - but not really - what ISR is doing) or place itself in the
 wrapper like this: 

It's just a syntax modification that some people find more pleasent;
not a new addition to the XEP to achieve something that wasn’t
possible before.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0388 SASL2: #2 Inline features

[Dave Cridland]

On Sat, 22 Oct 2022 at 22:29, Thilo Molitor  wrote:

> Again, MattJ already explained this well:
> https://mail.jabber.org/pipermail/
> standards/2022-October/038998.html
> 
>
> SASL2 allows for inlining additional elements into the authentication flow.
> That, like pipelining, reduces round-trip-times.
> To let clients distinguish, which features can be inlined into the SASL2
> authentication flow and which features are supported by the server but can
> not
> be inlined, a new "namespace" for inlinable features is needed.
>
>
When I designed SASL2, I designed it such that arbitrary elements could be
introduced anywhere in the flow by having them within SASL2 top-level
elements. I certainly didn't intend to imply that this meant that clients
could inject top-level-elements from other extensions that happened to be
supported without negotiation. I'm not sure where that came from.


> As MattJ says:
> > 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).
>
> The Bind2 update already in our pipeline as well as the XEP-0198 update
> use
> that  element as specified in our SASL2 update.
>
> In fact, Bind2 has it's own  element, too.
>

ISR, for example - XEP-0397 - doesn't need the  element at all to
handle XEP-0198.

You can argue it's too tied into HT-* or whatever, but the framework for
adding extensions into SASL2 exists already and I'm honestly confused as to
why a further  is needed here.


> > 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
>
> -tmolitor
>
>
> ___
> 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: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0388 SASL2: #1 client-identifier

[Dave Cridland]

I commented about this on the PR, but that seems to have been dismissed, so
again, for the list:

* I'm not convinced this is required to be a mandatory feature of SASL2,
despite its obvious utility, but I'm not going to argue very strongly that
it shouldn't be.
* I *am* convinced that an id attribute has to be mandatory (and SHOULD be
a UUIDv4).
* I am also convinced that the human-readable software information
shouldn't be mandatory.

On Sat, 22 Oct 2022 at 22:29, Thilo Molitor  wrote:

> I'm trying to rephrase and sum up here, what MattJ already said: https://
> mail.jabber.org/pipermail/standards/2022-October/038998.html
>
> Stable client-identifier:
> This allows per-device tokens or even passwords.
> It allows to present users with a list of devices that currently have
> access
> to their account.
>
> Software and Device:
> The software and device information allows users to better identify their
> clients than just using the opaque client-identifier: "Conversations on
> Kiva's
> iPhone" is far more descriptive than "0ba15cd[...]".
>
> @MattJ: Add it, if I'm missing something here
>
> -tmolitor
>
>
>
> ___
> 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: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0388 SASL2: #3 protocol agility - SASL mechanisms

[Thilo Molitor]

Hi Kim,

> I don't believe randomizing mechanisms helps. An attacker can simply
> connect multiple times and check if things vary or stay the same.
> 
> And given that attackers have unlimited IP addressees via proxies or
> compromised machines, I don't think rate limiting helps much either.
Hmm yes, you are right.
 
> On the other hand, I'm not sure anyone cares enough to really do this
> kind of thing, there are probably much easier ways to check if an
> account exists.
And yes, that's right, too. Querying for OMEMO keys/devices comes to my mind.
An attacker could even try to establish an OMEMO session without actually 
sending any user-visible message to see if a device is online and maybe even 
fingerprint the client by observing when the prekeys are refilled.

> I would likely just pick one "common" set of mechanisms to offer for
> unknown accounts, or seed the randomization with something relatively
> stable.
Sounds sensible. I'll update the Security Considerations to include this 
approach in a few days.

-tmolitor




___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0388 SASL2: #3 protocol agility - SASL mechanisms

[Kim Alvefur]

On Sat, Oct 22, 2022 at 11:28:26PM +0200, Thilo Molitor wrote:

That does not come without a cost, though: attackers could use this
information to determine which accounts are present on the server and maybe
even fingerprint which software might be used.
Because of this, we suggest multiple counter-measures in the Security
Considerations of SASL2: https://dyn.eightysoft.de/final/xep-0388.html#security
Namely randomizing the provided mechanisms for not-existing accounts and rate-
limiting.


I don't believe randomizing mechanisms helps. An attacker can simply
connect multiple times and check if things vary or stay the same.

And given that attackers have unlimited IP addressees via proxies or
compromised machines, I don't think rate limiting helps much either.

On the other hand, I'm not sure anyone cares enough to really do this
kind of thing, there are probably much easier ways to check if an
account exists.

I would likely just pick one "common" set of mechanisms to offer for
unknown accounts, or seed the randomization with something relatively
stable.

--
Regards,
Kim "Zash" Alvefur
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] XEP-0388 SASL2 / ProtoXEP: #8 downgrade detection

[Thilo Molitor]

This series of mails concluded that channel-binding together with SCRAM (or 
OPAQUE) provides for the highest additional security beyond TLS.

But channel-binding can only be used, if a MITM isn't able to deactivate it 
before it can detect the MITM.
The security considerations of XEP-0440 ( https://xmpp.org/extensions/
xep-0440.html#security ) show a scenario where a MITM is able to change the 
server-announced list of supported channel-binding types to only include a 
dummy type the client certainly does not support or to contain no channel-
bindings at all.

A client in this situation has two possible actions at hand:
1. Signal in it's SCRAM handshake, that it does support channel-binding, but 
not the one the server advertised (use "y" for the channel-binding flag as 
described in RFC 5802).
The server will fail authentication if it supports channel-binding.
That's bad UX if the problem only arose because no mutual channel-binding type 
could be found rather than because a MITM occurred.

2. Signal in its SCRAM handshake that it does not support channel-binding at 
all (use "n" for the channel-binding flag as described in RFC 5802).
That won't fail the authentication but leaves a possible MITM undetected.

XEP 0440 tries to mitigate this by suggesting to use pinning for the channel-
binding types. But that introduces other problems: A server operator deciding 
to offload TLS termination to an extra box would not be able to offer "tls-
exporter" on his server anymore (only the weaker "tls-server-end-point").
Pinning will not allow this downgrade in security and fail the connection/
authentication.

I've written my ProtoXEP ("SASL SCRAM Downgrade Protection") to overcome 
exactly this problem.
(Side note: Naming it "SASL SCRAM Downgrade Detection" would have been a 
better choice.)
As long as PLAIN is not supported by the client (and not the only mechanism 
announced by the server), this protocol can be used to detect downgrades on 
the channel-binding types, even if channel-binding is not used, and fail the 
authentication if a downgrade was detected.

Some clients can not support channel-binding (for example web-clients).
To allow some level of downgrade detection even for those type of clients, 
I've added the list of announced SASL mechanisms as perceived by the client 
alongside the list of channel-binding types as perceived by the client.
A downgrade from SCRAM-SHA-256 to, say, SCRAM-SHA-1 could be detected even 
without channel-binding in place and may some day be valuable, if SCRAM-SHA-1 
get broken.

Yes, that downgrade detection of SASL mechanisms is of limited use in case of 
SCRAM, because the downgrade can only be detected after the client-final-
message was sent, which already contains the client proof based upon the 
password. But that's a limitation of SCRAM itself, my downgrade detection 
could be defined for OPAQUE as well and OPAQUE does not have this weakness that 
SCRAM has. But the downgrade detection of SCRAM mechanisms could still be used 
to inform the user that a password change could be helpful.
(For the record: that same limitation holds for channel-binding using SCRAM as 
well: the mismatch in channel-binding data will only be detected by the server 
after the client-final-message was sent.)

To make it clear: The main goal of my ProtoXEP is to protect the list of 
channel-binding types, not the list of SASL mechanisms. But while I was at it, 
I thought it was trivial to add at least some level of protection for the SASL 
mechanisms as well.

An implementation of this ProtoXEP for Prosody and Monal already exists and 
works well.

-tmolitor




___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] XEP-0388 SASL2: #7 SASL PLAIN

[Thilo Molitor]

Using the PLAIN mechanism will send the password in cleartext, only protected 
by TLS itself, the server will always see your cleartext password and channel-
binding isn't supported by PLAIN, too.
That's fine, if you deem TLS to be always secure and your server to never be 
evil or compromised.

Yes, really, that's fine. But you'll loose another layer of security. Having 
multiple layers of security is always beneficial.

RFC 6120 discourages the use of PLAIN in section 13.8.3.
We merely added a pointer to this RFC into SASL2 to stress that more.
That doesn't mean one couldn't still use PLAIN.
It may well be that the deployment (LDAP etc.) makes it impossible to use 
something else than PLAIN.
Let me stress that again: SASL2 does still allow that, even when pointing to 
RFC 6120 (which would already be normative on that subject, even without the 
additional pointer in SASL2).


Why  did we add the pointer nonetheless?
Because supporting PLAIN, *even if the deployment doesn't warrant it*, weakens 
security.
As soon as the client does support PLAIN, a MITM able to break into the TLS 
channel could downgrade the used SASL mechanism to plain by manipulating the 
server advertised mechanism list to only include PLAIN.
Channel-binding would be a technique to detect such a MITM, but channel-
binding is only possible with SCRAM (or OPAQUE), not when using PLAIN.

In my opinion removing support for PLAIN in clients would be the best thing to 
do. But I see, that some deployments require the use of PLAIN.
In a private discussion with Holger, we came up with a solution, that could 
help solving that deadlock using a compromise:
Use a security profile in a well-known path on a webserver serving the same 
domain as the xmpp server, similar to the well-known path used for POSH (RFC 
7711). This profile would tell the client, if the domain in question needs 
PLAIN turned on or off. The default in case such a profile is absent would be 
"on". (This could even eventually switched to "off" if all major clients 
support such a profile. But that's for another discussion in several years.)
This security profile could even contain other security relevant settings our 
community comes up with. Maybe, just speculating, this profile could be also 
part of POSH.

There is one other mitigation possible: SASL mechanism pinning.
But 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 permanently break authentication for your client if 
the server operator just briefly activated these stronger mechanisms and 
deactivates them again (for various reasons).
If, on the other hand, you don't upgrade your pinning as outlined above, 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.

Pinning is the best solution we currently have at hand.
In my opinion the proposed security profile above would be an even better 
solution worth writing a ProtoXEP for. And those solutions could be even 
combined.

As for now, nothing in the SASL2 XEP does forbid to use PLAIN.
All I wanted was to add awareness of the security implications of PLAIN 
(especially without pinning) and I think I've reached that goal.

-tmolitor



___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] XEP-0388 SASL2: #6 TLS

[Thilo Molitor]

One topic not directly connected to SASL2, but to channel-binding and SCRAM in 
general, is the security of TLS.
When discussing about whether PLAIN is a good choice or whether channel-
binding has any benefit or even if SCRAM is needed, the underlying problem ist, 
that everyone has another view upon how secure TLS is.
And that view influences the discussion about these topics.

Let me sum up some of the properties SCRAM and channel-binding offer, before 
diving into the TLS stuff itself.

Channel-binding:
Channel-binding allows client and server to agree upon using the same TLS 
channel without a MITM between them.
While the relatively weak "tls-server-end-point" channel-binding only makes 
sure the same certificate as used by the server is seen by the client, other 
channel-binding types like "tls-exporter" are really strong, coupling every 
newly established TLS channel to a unique random-looking value.

SCRAM:
Salted Challenge Response Authentication Mechanism allows mutual 
authentication for server and client (to be exact: SCRAM allows each party to 
proof that they know the password or a hash thereof).
That allows for servers not storing the plaintext password, but a salted hash 
of it.
It allows for clients doing the same, but that prevents them to use any other 
authentication method than exactly the SCRAM flavor the password was originally 
stored in. Most clients therefore use the (often hardware backed) keystore of 
their operating system to store the password securely.
Yes Marvin, I consider the storage of password hashes on the user's devices of 
no practical relevance here. But the storage of those hashes on the server is.
SCRAM uses nonces to make the SCRAM exchange replay-save. Even if an attacker 
records the whole SCRAM exchange he won't be able to use this data to 
authenticate himself (as long as the hashes SCRAM is based upon have not been 
broken).

TLS:
Yes, TLS 1.2 and 1.3 itself is secure (as of today), but the PKI is not.
There are numerous shortcomings and I recommend reading Bruce Schneier's 
article over here: https://www.schneier.com/academic/archives/2000/01/
ten_risks_of_pki_wha.html
Some of the issues mentioned therein are still valid today.

- I have seen schools and companies demanding to install their CA into phones 
and computers to access the internet over wifi. These MITM boxes create new 
certificates on the fly while filtering internet access and frequently exhibit 
security holes.
- Certificate Transparency doesn't work automatically: you'll have to monitor 
your domain yourself, to detect misissuance. That's something operators of 
small home-deployments most probably won't do.
- Certificate Revocation Lists are frequently not checked at all (we don't even 
do OCSP stapling in our open source xmpp servers, mobile platforms even seem 
to not support OCSP stapling at all), stolen private keys can be used for the 
rest of the lifetime of a certificate (that could be up to a full year!)
- People often click away certificate trust warnings
- CAs still misissue certificates, despite certificate transparency
- Bugs like Heartbleed allow stealing of private keys
- Russia and other states are trying to lead people to install their CA: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1758773
- many more

Yes, the web platform solely relies upon TLS, but that does not mean that it's 
the holy grail of internet security. Even older TLS versions like TLS 1.0 or 
SSL 3 are deemed insecure today.
If we can improve the security beyond simply using TLS, we should.
More so if this does not have any negative side effects (like disabling PLAIN 
in every client would have on these deployments only supporting PLAIN).

To me, supporting SCRAM (the whole family, not just SCRAM-SHA-1) and channel-
binding is a valuable goal to strive for as a second layer of defence even 
when using TLS. 
Defense in depth is something that's important. It borrows people some time 
after one layer of defence is broken, but before all software (server and 
clients) could be upgraded.
And yes, this defence in depth has to be established some time *before* 
another layer of our security gets broken, not afterwards.

Journalists, activists and other people at risk of being MITMed benefit from 
this additional defense, too.

-tmolitor



___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] XEP-0388 SASL2: #5 protocol agility - channel-binding types

[Thilo Molitor]

As with SASL mechanisms, today various different channel-binding types with 
varying strength can be used.
SCRAM and the upcoming OPAQUE mechanism can use channel-binding to make sure 
the TLS channel is MITM-free (the "-PLUS" variants of SCRAM and OPAQUE).

You'll need channel-binding to make sure an attacker that is able to break 
into the TLS channel can not downgrade the used SASL mechanism to something 
weak enough for him to break.

All of this is nice, but the current XMPP protocol flow - as implemented in 
servers/clients today - lacks a way to negotiate which channel-binding should 
be used by the client or server.
If both do support multiple but only partially overlapping mechanisms, the 
client has to guess which one is also supported by the server.
That can lead to authentication failures if the client uses a binding, the 
server does not know.
XMPP lacks a way to indicate that the failed authentication was due to wrong 
channel-binding type used nor should we add such an indication for various 
security reasons. Sequentially probing all channel-binding methods a client 
supports would significantly extend the time needed to log in, too, which could 
exhaust the limited background time available on mobile platforms as well as 
degrade UX.

Luckily all of this was already solved by Florian Schmaus in XEP-0440: SASL 
Channel-Binding Type Capability.
We therefore made XEP-0440 mandatory to implement, if channel-binding is 
implemented by the server/client at all.
Without implementing channel-binding, XEP-0440 is not needed, of course.

-tmolitor



___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] XEP-0388 SASL2: #4 SASL2 tasks

[Thilo Molitor]

Previously the SASL2 XEP used a base64 encoded challenge-response flow for it's 
tasks.
That allows challenges and responses to be of arbitrary payload, but makes it 
difficult to encode information when defining SASL2 tasks for XMPP in future 
XEPs.
One example we came across ourselves are the SCRAM upgrade tasks.
For these upgrades the server needs to send the client the used salt as well 
as the iteration count to use.
Encoding this into a base64 string would involve to either develop some 
arbitrary text-encoding (like "s=xxx,i=4096") or base64-encode XML.
Both is not perfect and could be even more problematic for other SASL2 tasks.

We therefore decided to use XML for SASL2 tasks.
To make the protocol flow easier, I've pushed an update to the PR adding a 
wrapper-element to the SASL2 protocol flow for tasks: https://github.com/xsf/
xeps/pull/1214/commits/251800fabb9ac4fd095f9b04a04f062022c94dbe
This  element can contain any element defined in a future 
specification of the task in question.

For SCRAM upgrades, the task is defined in this split-out ProtoXEP over here: 
https://github.com/tmolitor-stud-tu/xeps/commits/scram-upgrades 
(rendered version: https://dyn.eightysoft.de/final/xep-scram-upgrade.html )

For other tasks the SASL2 gives a fictional example using base64, too: https://
dyn.eightysoft.de/final/xep-0388.html#example-14

SASL2 tasks originally defined for another protocol (say SMTP) could now still 
use base64 while other tasks only defined for XMPP could use the richer and 
more readable XML variant.

-tmolitor



___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] XEP-0388 SASL2: #3 protocol agility - SASL mechanisms

[Thilo Molitor]

This consists of various sub-parts.
All of these assume, that the server does not store passwords in plaintext, 
but in hashed form of some sort (e.g. SCRAM, OPAQUE etc.).
There are various reasons to not let servers store passwords in plaintext, if 
possible. Prosody, for example, stores it's password hashed by default: 
https://prosody.im/doc/plain_or_hashed

The missing protocol agility was already mentioned on this very list, but no 
one presented a solution back then: https://mail.jabber.org/pipermail/
standards/2019-January/035720.html
Let me stress that the upgrade mechanism defined in SASL2 can not only be used 
to upgrade between different mechanisms of the SCRAM family, but can be used to 
upgrade from SCRAM to OPAQUE (or something entirely new), too.

1. Mechanism Announcements
SASL1 and the original SASL2 proposal provide no way of introducing new SASL 
mechanisms for server operators.
If, for example, a server operator wants to introduce SCRAM-SHA-256 while 
previously only supporting SCRAM-SHA-1 (and therefore only having SCRAM-SHA-1 
hashes stored on the server), he simply can't do that without causing damage:
Globally announcing SCRAM-SHA-256 will make clients happily use it, even 
though the server still does not have the corresponding hashes and salts in 
its storage --> authentication will fail.

SASL2 therefore contains a way to announce only authentication methods that 
can be used for a specific user account, not what is globally enabled.
It does so by using the from-attribute of the stream-header already present in 
RFC 6120. That way we did not need to introduce another round-trip.
Round-trip reduction is one of the goals of SASL2 and especially important for 
mobile devices.

That does not come without a cost, though: attackers could use this 
information to determine which accounts are present on the server and maybe 
even fingerprint which software might be used.
Because of this, we suggest multiple counter-measures in the Security 
Considerations of SASL2: https://dyn.eightysoft.de/final/xep-0388.html#security
Namely randomizing the provided mechanisms for not-existing accounts and rate-
limiting.
Overall I think these security implications are not that big (especially with 
the suggested countermeasures in place): other parts of XMPP already allow for 
some sort of fingerprinting (querying OMEMO keys and other open PEP-nodes 
etc.).

2. Mechanism Upgrades
Point 1 would be pretty limited if there was no way of upgrading the SASL 
mechanisms a server can offer for a specific account.
An account registered when only SCRAM-SHA-1 was supported would otherwise 
virtually stay on SCRAM-SHA-1 forever (more precisely: until the user resets 
the password of this account).

To overcome this limitation, we used the already existing SASL2 tasks to 
introduce a way for clients to upgrade the server to new SASL mechanisms.
The server lists all mechanisms it could support, if it had the needed data  
in it's storage and the client picks one of these it supports, too, to send 
the server this needed data. The details depend on the used mechanism (SCRAM, 
OPAQUE etc.) and are defined in a new ProtoXEP for SCRAM (that's the split-out 
I announced lately: https://github.com/xsf/xeps/pull/1214/commits/
251800fabb9ac4fd095f9b04a04f062022c94dbe ).

This will make sure the server never sees the cleartext password, if we 
additionally update XEP-0389: Extensible In-Band Registration to send only 
hashes, too.
This way even an evil or compromised server won't be able to extract your 
password and potentially use it for credential stuffing.
Reducing the attack surface is always good and using hashes for mechanism 
upgrades rather than cleartext passwords provides for exactly this.

-tmolitor



___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] XEP-0388 SASL2: #2 Inline features

[Thilo Molitor]

Again, MattJ already explained this well: https://mail.jabber.org/pipermail/
standards/2022-October/038998.html

SASL2 allows for inlining additional elements into the authentication flow.
That, like pipelining, reduces round-trip-times.
To let clients distinguish, which features can be inlined into the SASL2 
authentication flow and which features are supported by the server but can not 
be inlined, a new "namespace" for inlinable features is needed.

As MattJ says:
> 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).

The Bind2 update already in our pipeline as well as the XEP-0198 update use 
that  element as specified in our SASL2 update.

In fact, Bind2 has it's own  element, 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

-tmolitor


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] XEP-0388 SASL2: #1 client-identifier

[Thilo Molitor]

I'm trying to rephrase and sum up here, what MattJ already said: https://
mail.jabber.org/pipermail/standards/2022-October/038998.html

Stable client-identifier:
This allows per-device tokens or even passwords.
It allows to present users with a list of devices that currently have access 
to their account.

Software and Device:
The software and device information allows users to better identify their 
clients than just using the opaque client-identifier: "Conversations on Kiva's 
iPhone" is far more descriptive than "0ba15cd[...]".

@MattJ: Add it, if I'm missing something here

-tmolitor



___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0388: SASL2 enhancements

[Thilo Molitor]

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

[Thilo Molitor]

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

[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
___

Re: [Standards] XEP-0388: SASL2 enhancements

[Thilo Molitor]

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

[Matthew Wild]

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

[Thilo Molitor]

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

[Thilo Molitor]

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

[Daniel Gultsch]

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

[Daniel Gultsch]

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

[Matthew Wild]

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

[Florian Schmaus]

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

[Matthew Wild]

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
___

Re: [Standards] XEP-0388: Extensible SASL Profile - implementations?

[Dave Cridland]

Hi Matthew,

I did an implementation for Openfire some years ago, including TOTP and
other bits, and updated the XEP based on what I discovered.

In practical terms, I think it should work well in its current state.

The code I wrote is open source, but was never in a state to merge to the
upstream, I'm afraid.

Dave.

On Thu, 16 Jun 2022 at 15:48, Matthew Wild  wrote:

> Hi folks,
>
> Is anyone aware of client or server, public or private,
> implementations of XEP-0388?
>
> I'm planning to begin an implementation for Prosody in the near future.
>
> Regards,
> Matthew
> ___
> 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: standards-unsubscr...@xmpp.org
___

[Standards] XEP-0388: Extensible SASL Profile - implementations?

[Matthew Wild]

Hi folks,

Is anyone aware of client or server, public or private,
implementations of XEP-0388?

I'm planning to begin an implementation for Prosody in the near future.

Regards,
Matthew
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0388 (SASL2): Format of tasks, internationalisation of messages, Security Considerations

[Peter Saint-Andre]

On 1/31/19 8:58 AM, Jonas Schäfer wrote:
> So since during the summit, it was desired to have a breaking change to SASL2 
> (that’s rare, isn’t it?), I have two suggestions for things which could use 
> fixing and which could trigger a namespace bump and one thing which should be 
> mentioned independently:
> 
> 
> 1. xml:lang on : The error messages could use xml:lang support, like 
> stanza and RFC 6120 sasl errors do (with multiple  elements in 
> different languages).
> 
> 2. Is there a particular reason why the  thing uses plain strings as 
> its values instead of a mechanism like , where namespaced 
> elements with possible child elements / text are used?
> 
> 3. We should mention in the security considerations that clients should be 
> careful which requests they include in the initial  especially 
> when no transport security is in use; if the SASL method allows mutual 
> authentication (e.g. SCRAM), a client might find that they’re not actually 
> connected to the server and have just sent possibly private data to them.

That all seems reasonable.

Peter



signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0388 (SASL2): Format of tasks, internationalisation of messages, Security Considerations

[Florian Schmaus]

On 31.01.19 16:58, Jonas Schäfer wrote:
> 3. We should mention in the security considerations that clients should be 
> careful which requests they include in the initial  especially 
> when no transport security is in use; if the SASL method allows mutual 
> authentication (e.g. SCRAM), a client might find that they’re not actually 
> connected to the server and have just sent possibly private data to them.

It possibly can't hurt to also specify that a server, who detected a
(potential) MitM by the means provided by the SASL layer, should also
drop the SM state. But I feel like this should go into xep198's security
considerations.

- Florian



signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] XEP-0388 (SASL2): Format of tasks, internationalisation of messages, Security Considerations

[Jonas Schäfer]

So since during the summit, it was desired to have a breaking change to SASL2 
(that’s rare, isn’t it?), I have two suggestions for things which could use 
fixing and which could trigger a namespace bump and one thing which should be 
mentioned independently:


1. xml:lang on : The error messages could use xml:lang support, like 
stanza and RFC 6120 sasl errors do (with multiple  elements in 
different languages).

2. Is there a particular reason why the  thing uses plain strings as 
its values instead of a mechanism like , where namespaced 
elements with possible child elements / text are used?

3. We should mention in the security considerations that clients should be 
careful which requests they include in the initial  especially 
when no transport security is in use; if the SASL method allows mutual 
authentication (e.g. SCRAM), a client might find that they’re not actually 
connected to the server and have just sent possibly private data to them.

Although somebody (I think it was Dave) noted:

> This probably is the difference between an attacker stabbing you multiple 
> times with a knife, and stabbing you multiple times with a slightly rusty 
> knife.

kind regards,
Jonas

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0388 (SASL2) Update

[Dave Cridland]

On 15 August 2017 at 17:08, Sam Whited  wrote:
> On Tue, Aug 15, 2017, at 10:12, Dave Cridland wrote:
>> *  now talks about "tasks" rather than special SASL
>> mechanisms. Tasks have essentially the same interface as SASL mechs,
>> but do different things - trying to shoehorn them into the same thing
>> wasn't mentally working for me, and for some reason everything got
>> simpler after I stopped pretending.
>
> These do seem like the same thing to me (although I don't have a strong
> opinion on this either way); what are the differences as you see them?

You can't use the post authentication tasks as normal SASL mechanisms,
and normal SASL mechanisms don't work as tasks either.

For example, a normal SASL mechanism decides what authorization
identifier to use; a task can't change that, and uses that as input.

So using a stock SASL framework, like Java's or Cyrus, to drive these
just breaks everywhere.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0388 (SASL2) Update

[Sam Whited]

On Tue, Aug 15, 2017, at 10:12, Dave Cridland wrote:
> *  now talks about "tasks" rather than special SASL
> mechanisms. Tasks have essentially the same interface as SASL mechs,
> but do different things - trying to shoehorn them into the same thing
> wasn't mentally working for me, and for some reason everything got
> simpler after I stopped pretending.

These do seem like the same thing to me (although I don't have a strong
opinion on this either way); what are the differences as you see them?

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] XEP-0388 (SASL2) Update

[Dave Cridland]

GitHub PR: https://github.com/xsf/xeps/pull/493

Folks,

I've had a bit of a crack at implementing SASL2 in Openfire, with a
view to getting "Password change at next login" and (in the future)
TOTP support in place around SASL2. I've also implemented it in
stanza.io.

In the course of this, I found various things about the design which
either didn't work, or else caused rather more effort than I really
wanted.

The main changes I've made are:

* I did away with the "=" encoding for empty strings. It was daft, as
Alexey suggested, and wasn't required.
*  is now followed immediately by .
Otherwise it's very hard to decide what to do next. There's no stream
restart, so this is still keeping the RTTs down.
*  now talks about "tasks" rather than special SASL
mechanisms. Tasks have essentially the same interface as SASL mechs,
but do different things - trying to shoehorn them into the same thing
wasn't mentally working for me, and for some reason everything got
simpler after I stopped pretending.

These changes made it fairly straightforward to implement.

Comments welcome...

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___