[Standards-JIG] Inclusion of both, to and from attributes to the stream root element
stpeter at jabber.org
Thu Sep 28 22:02:38 UTC 2006
Matthias Wimmer wrote:
> Hi Peter, hi list,
> you already added to http://www.xmpp.org/xmppbis.html, that it might be
> worth considering, that an initiating entity should add both, a to and a
> from attrbiute to the initial stream headers.
> When I proposed this two years ago I only gave a reason why this is
> worth for s2s links.
BTW, this is already in my working copy for rfc3920bis.
> I want to add now, that it would also be worth that a client is adding a
> from attribute to the initial stream headers:
> When a server is generating the list of supported authentication schemes
> (SASL mechanisms and/or legacy authentication), the set of possible
> schemes may depend on the user, that tries to authenticate.
> The server currently has no way to offer different users different
> authentication schmes (SASL mechanisms).
> - If we have a legacy authentication database, that just stores hashes
> of user passwords (not suitable for doing DIGEST-MD5); and for newer
> users, we store DIGEST-MD5 compatible hashes. The users using old
> accounts should not get offered DIGEST-MD5 but only PLAIN; while newer
> accounts should get offered DIGEST-MD5 and should prefere that over
> - We have some users only having a password, but nothing else. We have
> other users just having certificates, but nothing else (e.g. because
> they registered for an account by submitting a certification request
> for a free JabberID - which would be a nice way to enroll XMPP
> and the third group of users just have a SecurID token,
> but neither a certificate nor a password.
> For each group of users, the server has to present an other SASL
> mechanism. How can the server decide which one to present, if it does
> not get a from attribute?
My only concern is that the 'from' address in the stream header is
simply asserted, so I could be shown the wrong set of SASL mechanisms if
I assert that I'm mawis at jabber.org instead of stpeter at jabber.org or
whatever. However, if I try to auth using a mechanism that I'm not
really allowed to use, I'll find out eventually anyway because the
server will return an <invalid-mechanism/> error to me. So I don't think
this opens any security holes.
Jabber Software Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards