[Standards-JIG] Inclusion of both, to and from attributes to the stream root element

[Peter Saint-Andre]

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).

Interesting.

> Examples:
> - 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
>   PLAIN.
> - 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
>   certificates), 

Agreed. :-)

> 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?

True.

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.

Peter

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20060928/cb3dbb13/smime.bin