[Bug 14003] Chan.T.ServerAuthentication, Chan.I. SASLAuthentication — authenticate with server interactively

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=14003

--- Comment #36 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-11-22 07:55:11 PST ---
AuthorizationIdentity isn't really sufficient; we also need DefaultUsername,
for use with SASL mechanisms that deal with a "simple username" as defined in
RFC 4422 §2. RFC 3920 §6.3 suggests that we should also be providing the UI
with a service name, which is "xmpp" for XMPP.

In XMPP, servers typically[1] expect "smcv at example.com" to authenticate with
username "smcv"; this was a SHOULD in RFC 3920. Wocky doesn't appear to support
anything else, in fact.

3920bis weakens that SHOULD to "in the absence of local information provided by
the server, an XMPP client SHOULD assume that the authentication identity for
such a SASL mechanism is the combination of a user name and password, where the
simple user name is the localpart of the user's JID".

-------- Simple case: being yourself

When you're authenticating as "yourself", XMPP mandates that you "MUST NOT
provide an authorization identity unless the authorization identity is
different from the default authorization identity derived from the
authentication identity, as described in [SASL]".

So if I connect with:

    RequestConnection({ account: "smcv at example.com" })

and use PLAIN with password "password", I should authenticate like so:

    "\0smcv\0password"

However, I think the authorization identity I'm trying to assert is still
"smcv at example.com". So the channel would look like this:

    { "...DefaultUsername": "smcv",
      "...AuthorizationIdentity": "smcv at example.com }

One problem here is that I can't see how a generic SASL client can be expected
to know what authorization identity the server is going to derive from its
authentication identity (this is particularly tricky for non-username/password
things, like SASL EXTERNAL referring to a certificate). So we might violate
that "MUST" directive sometimes, without knowing about it...

The semantics I propose for DefaultUsername are: if using a "simple username"
SASL mechanism, clients SHOULD default to using the DefaultUsername; also, if
the client uses the DefaultUsername, it SHOULD assume that the authorization
identity AuthorizationIdentity will be derived from it by the server.

-------- Complex case: being someone else

If I'm using my sysadmin powers to log in as the "announcements" role address,
I expect that I'd want to connect with:

    RequestConnection({ account: "announcements at example.com" })

The SASL channel would look like this:

    { "...DefaultUsername": "announcements",
      "...AuthorizationIdentity": "announcements at example.com }

but a sufficiently elaborate UI could give me the opportunity to override the
username from "announcements" to "smcv".

My simple username is still smcv, my password is still password, but this time
I'm trying to authorize myself to act as announcements at example.com, so the UI
would have to perform SASL PLAIN with this string:

    "announcements at example.com\0smcv\0password"

In this case, it really does need to know the AuthorizationIdentity.

[1] http://trac.tools.ietf.org/wg/xmpp/trac/ticket/49

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.