Subject: [xmpp] SASL errors in 3920bis-03

From: Tobias Markmann <[email-masked]>
Date: Mon, 16 Nov 2009 20:26:40 +0100

Hi,

According to 3920bis-03 there are this two errors defined: mechanism-invalid
[1] and mechanism-too-weak [2]. I think mechanism-invalid would be
sufficient.

SASL usually works the way that first the server advertises what it supports
and then the client gets to choose. A client selecting a mechanism which
hasn't advertised is quite broken in my opinion. Since it's broken why have
two errors for this. I mean the client can't really do something useful with
the info mechanism-too-weak. Selecting and unsupported mechanism is quite a
bug and I think it would be cleaner to not split our errors in areas that
are about buggy clients. Or have I missed the clients that bring up a text
box where the user can enter the mechanism to use manually? ;)

Cheers,
Tobias

[1] http://tools.ietf.org/html/draft-ietf-xmpp-3920bis-03#section-7.4.7
[2] http://tools.ietf.org/html/draft-ietf-xmpp-3920bis-03#section-7.4.9

-- 
Tobias Markmann
http://ayena.de

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 17 Nov 2009 16:52:24 +0900

> Hi,
Hi Tobias,
> According to 3920bis-03 there are this two errors defined: 
> mechanism-invalid [1] and mechanism-too-weak [2]. I think 
> mechanism-invalid would be sufficient.
>
> SASL usually works the way that first the server advertises what it 
> supports and then the client gets to choose. A client selecting a 
> mechanism which hasn't advertised is quite broken in my opinion.
I agree.
But there might be another use case for the error code - selection of a 
mechanism which is considered too weak for a particular user. In such 
case the server would advertise the mechanism to everybody, but return 
the error for some users.
> Since it's broken why have two errors for this. I mean the client 
> can't really do something useful with the info mechanism-too-weak. 
> Selecting and unsupported mechanism is quite a bug and I think it 
> would be cleaner to not split our errors in areas that are about buggy 
> clients. Or have I missed the clients that bring up a text box where 
> the user can enter the mechanism to use manually? ;)
>
> Cheers,
> Tobias
>

---

From: Tobias Markmann <[email-masked]>
Date: Tue, 17 Nov 2009 09:11:15 +0100

On Tue, Nov 17, 2009 at 8:52 AM, Alexey Melnikov <[email-masked]>
 wrote:

> mechanism which is considered too weak for a particular user. In such case
> the server would advertise the mechanism to everybody, but return the error
> for some users.

So you're are suggesting to use the mechanism-too-weak error for per-user
authentication profiles since you initially can only have them on per-domain
basis. But then again how should the client know what to chose for the
current user? Try each advertised mechanism and after 20 round trips finally
find one that doesn't respond with an mechanism-too-error?

Which client does provide manual SASL mechanism choice so the user could
select a more secure mechanism?

-- 
Tobias Markmann
http://ayena.de

---

From: Philipp Hancke <[email-masked]>
Date: Tue, 17 Nov 2009 10:28:35 +0100 (CET)

Hi Alexey,

> mechanism which is considered too weak for a particular user. In
> such case the server would advertise the mechanism to everybody, but
> return the error for some users.

If stream:from is set, the servers knows the users jid before offering the 
list of mechanisms and should not offer any weak mechanisms.

Might solve Tobias problem at least.

cheers

philipp

---

From: Tobias Markmann <[email-masked]>
Date: Tue, 17 Nov 2009 10:35:29 +0100

> list of mechanisms and should not offer any weak mechanisms.

Exactly this was my thinking. Dumb client, why are you selecting a mechanism
that hasn't been advertised. ;)
Sure if during usage of PLAIN or DIGEST-MD5 the server receives the username
and decides this mechanism is too weak one could reply with a
mechanism-too-weak error but the process with having to know stream:from is
way cleaner.

Cheers,
Tobias

-- 
Tobias Markmann
http://ayena.de

---

From: Dave Cridland <[email-masked]>
Date: Tue, 17 Nov 2009 10:26:54 +0000

> mechanism-too-weak error but the process with having to know  

It could also be that the client has used DIGEST-MD5, but failed to  
negotiate a suitable security layer, or something. There's enough  
sub-option negotiation in deployed mechanisms that I can't see your  
reasoning for arguing against this so hard.

After all, nobody's forcing you to do this.

One minor point, though - the stream:stream's from attribute (not, of  
course, stream:from) isn't typically set by clients. I don't think  
RFC 3920 (and bis) suggest that it should be, either.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 17 Nov 2009 12:41:17 -0700

> the error for some users.

That was the intent for mechanism-too-weak. For example, if you want to
authenticate as an administrative user then you might not be allowed to
use a weaker mechanism (even if the server offered it to you because it
didn't know who you were at that point).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Tobias Markmann <[email-masked]>
Date: Tue, 17 Nov 2009 22:43:51 +0100

> didn't know who you were at that point).

I completely understand the use case. It just seems kind of stupid to select
a mechanism which isn't advertised. Sure you can't do otherwise the way SASL
has been designed since you don't know the username before advertising the
supported mechanisms.

Tobias

-- 
Tobias Markmann
http://ayena.de

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 17 Nov 2009 14:46:43 -0700

On 11/17/09 2:43 PM, Tobias Markmann wrote:
> On Tue, Nov 17, 2009 at 8:41 PM, Peter Saint-Andre <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> I completely understand the use case. It just seems kind of stupid to
> select a mechanism which isn't advertised. Sure you can't do otherwise
> the way SASL has been designed since you don't know the username before
> advertising the supported mechanisms.

No, you choose a mechanism (say, PLAIN) but the server doesn't allow you
to authenticate as a higher class of user with that mechanism.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Tobias Markmann <[email-masked]>
Date: Tue, 17 Nov 2009 22:53:36 +0100

> to authenticate as a higher class of user with that mechanism.

Yeah. However protocol wise the cleaner way would be for the server to know
the username before, look up the authentication profile for that user and
send the supported mechanisms and thereby reducing the number of round
trips.

Tobias

-- 
Tobias Markmann
http://ayena.de

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 17 Nov 2009 14:56:39 -0700

On 11/17/09 2:53 PM, Tobias Markmann wrote:
> On Tue, Nov 17, 2009 at 10:46 PM, Peter Saint-Andre <[email-masked]
> Yeah. However protocol wise the cleaner way would be for the server to
> know the username before, look up the authentication profile for that
> user and send the supported mechanisms and thereby reducing the number
> of round trips.

Sure. But reality is not always so clean. :) I doubt that anyone has
ever seen this error on the wire, but it's defined just in case...

/psa

---

From: Tobias Markmann <[email-masked]>
Date: Tue, 17 Nov 2009 23:01:50 +0100

> ever seen this error on the wire, but it's defined just in case...

Well, you can always reckon on some strange Prosody dev that made it respond
mechanism-too-weak if client choose ANONYMOUS but the server isn't set to
support it.

Tobias

-- 
Tobias Markmann
http://ayena.de

---

From: Matthew Wild <[email-masked]>
Date: Tue, 17 Nov 2009 22:53:26 +0000

> mechanism-too-weak if client choose ANONYMOUS but the server isn't set to

This strange Prosody dev (not the one that added the error) fails to
understand the problem with this response, it being more specific than
"invalid-mechanism". You're making a mountain out of a molehill, over
an error that will never appear to a "correct" client. Hence I don't
particularly care whether it gets changed in Prosody - patches welcome
:)

Matthew

---

From: Tobias Markmann <[email-masked]>
Date: Tue, 17 Nov 2009 23:58:04 +0100

> particularly care whether it gets changed in Prosody - patches welcome

I was just wondering about the error, that's all. It just felt wrong. Though
due to SASL's restrictions we seem to /need/ that error. I'm thinking more
of it like making a molehill out of an earth crumb. ;)

At least the questions I had have been answered in this thread. Thanks.

-- 
Tobias Markmann
http://ayena.de