[Bug 14003] Connection: interface to ask for credentials (SASL auth channels)

[bugzilla-daemon at freedesktop.org]

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

--- Comment #21 from Sjoerd Simons <sjoerd at luon.net> 2010-10-19 03:59:25 PDT ---
(In reply to comment #20)
> ServerAuthentication
> ====================
> 
> ServerAuthentication could do with a high-level explanation of how it happens:
> 
> - When is it dispatched? I infer that it's while the Connection is CONNECTING,
> but that should be stated up-front.

Go for it

> - What properties can it be expected to have? Most of the text from
> ServerTLSConnection is probably applicable.

? 

> - Can you have more than one ServerAuthentication in series? The SASL RFC says
> you can't have more than one SASL negotiation, if I'm reading it correctly, but
> you could conceivably have a round of SASL followed by a round of captcha, or
> vice versa. If you can, would it mean "at least one must succeed" or "all must
> succeed"?
>
> - Can you have more than one ServerAuthentication in parallel? If you can,
> would it mean "at least one must succeed" or "all must succeed"?

You can have multiple ServerAuthentication in series, you must defeat them all
to get the prize. I haven't seen a use-case in practise for multiple alternate
paths, for now the CM chooses your path to the maze and it's up to you to
defeat the challenges.

> Are the username and realm in Auth_Details the same as SASL RFC 4422's
> "authorization identity strings" or are they intended as something to put in
> the UI presented to the user or what?
>
> Please note the distinction between authentication and authorization
> identities. A non-empty, non-omitted authorization identity means I want to
> authenticate with one identity (authentication identity), then act as a
> different identity. For instance, that could mean "authenticate as root, using
> your root powers to impersonate eeejay without knowing his password", or
> conversely, it could mean "the sysadmins can authenticate with their own
> identities, and are authorized to impersonate announcements at example.com when
> they do so". We don't necessarily need to support that, but we should get the
> terminology right so we can support it later if desired.

The property is called AuthenticationInformation for a reason. The CM gives you
the default/likely authentication identities, the UI can choose a different
authorization identity if it so chooses. I probably wouldn't put those in a
default UI though (maybe only when you toggle and advanced drop-down) as it's
rarely used in practise.

for a specification of realm we might want to refer to the definition in 
rfc2831 (specifically the CM computes a default realm to be used)

> SASL
> ====
> 
> Abort_Reason is too vague a name - types are a flat namespace. It should be
> SASL_Abort_Reason.
++

> StartMechanism can't distinguish between no initial data, and initial data of
> zero length. (Not as stupid as it sounds: RFC 4422 §4(3)(a) requires these to
> be distinct.)

I've not seen an mechanism yet where you can meaningfully start with an empty
initial data (e.g. zero length). But i agree that potentially supporting that
could be useful, not having a maybe type in D-Bus strikes again though... Your
choice for either adding a boolean or split of a StartMechanismWithData (i
think i prefer two methods instead of a silly boolean)

> We don't have a way to emit an 'ay' of additional data with a successful
> outcome (i.e. carried on a successful StateChanged), which is a SHOULD in RFC
> 4422 §4(3)(c). Again, "no additional data" is a value distinct from the
> zero-length string.

We do. The additional data is expected to be emitted as a last challenge to
which the client responds with Accept (the CurrentChallenge property has some
info about it, but it needs to be spelled out more)

> Is AvailableMechanisms immutable? (My guess: yes.)
> 
> Is Secure immutable? (My guess: yes.)

Seems i annoted that in my initial mails but it didn't make it into the spec:

http://www.mail-archive.com/telepathy@lists.freedesktop.org/msg04137.html
http://www.mail-archive.com/telepathy@lists.freedesktop.org/msg04138.html

> What is CurrentChallenge when there is no current challenge? (This is not as
> stupid as it sounds: the empty octet-string is a valid challenge.)

Like you say a bit later, CurrentChallenge is superflous, so i don't think
that's an issue

> We should document that only the Handler may call StartMechanism.
Yup, we should, go go go :)

> Do we really need CurrentChallenge at all? Couldn't we just say that the
> Handler can't call StartMechanism until it has connected to the NewChallenge
> signal, and it makes no sense for anyone else to call that method?

Correct. If you care a lot about challenge with no data vs. zero lengt then you
might want to add a boolean to that signal, but again i've yet to see a
mechanism that actually makes a difference in this case.

> It's not immediately obvious what the state transitions are; I'll try to dig
> that out from Gabble.

Gabble doesn't have the complete set, in particular it can't restart a sasl
try.

> There are no tp:possible-errors anywhere, which seems like an oversight.

go go go :)

> I would assume that:
> 
> - Respond() is only valid to be called while In_Progress; similarly,
> NewChallenge makes no sense unless In_Progress

Yup, the successfull sequences look like:

StartMechanisms,  => In_Progress, (Challenge, Respond)*,  [=> ServerSucceeded,
Accept, => Succeeded || Challenge, Accept, => ClientSucceeded, => Succeeded]

> - Abort() can be called at any time, except when Server_Failed or Client_Failed
> when it would have no effect (or can it be called in Server_Failed to convert
> it into Client_Failed? answers on a postcard)

Yeah, no effect in the Failed cases, wouldn't make much sense (the server
failed, well screw you, client failed as well, neh neh neh).

Doesn't really make sense to call abort in Succeeded or Client_Succeeded (You
alreadh told the channel everything is fine from your perspective). So Abort
can be usefully called in Not_Started (e.g. we don't support any of the sasl
mechanisms), In_Progress (server fucked up or user pressed cancel) and
Server_Succeeded (the server might claim we're done, but we don't agree)

> - Close() can be called at any time, and has the same effect as calling Abort()
> with errors ignored, and then Close()

Same effect as Abort indeed, accept when Abort doesn't make sense :)

> Can StartMechanism be called in In_Progress, Server_Succeeded, Client_Accepted
> and Succeeded states, to restart authentication gratuitously?

No, SASL_Status correctly documents when you can call StartMechanism. If you
want to restart gratuitously you should first Abort and then StartMechanism. (I
don't think StartMechanism implicitly calling Abort makes much sense and in
general i don't expect restarting to happen unless the server failed us)

> Why does Abort() take an Abort_Reason, but SASL_State has a DBus_Error_Name?
> Shouldn't they both have the same (perhaps both)?

good point, potentially both indeed.

> We should perhaps write to IANA and register X-GOOGLE-TOKEN as a SASL
> mechanism, since Google have failed to do so (if I read the RFC correctly,
> there's no particular provision for "X-" SASL mechanisms, but anyone can
> register a SASL mechanism, and no particular approval is required).

Unless you want to register all custom SASL mechanisms that doesn't make much
sense. Even if the RFC doesn't have a provision for it, the X- stuff seems to
be the normal practise. It's not up to us to fix the world :)

> Do we need a way for the authenticator to get the server's GSSAPI host-based
> service name (RFC 4422 §4(1))? I expect that that'd be a constant string + "@"
> + the hostname, for basically every protocol we support.

Could be added to the AuthenticationInformation dict i guess?


The one thing i'd like to add to the spec is a mandatory to implement
X-TELEPATHY-PASSWORD mechanism, which is a simple mechanism with initial-data
'\0user\0password' (basically SASL PLAIN (RFC 4616). When this mechanism is
used it's expected that the CM handles the actual authentication (basically as
if there was a password in the account information). Reasoning here is that it
would allow us to never store a password in the account information and always
use an authentication handler (without that handler needed to implement
specific sasl mechanisms). (This way Empathy wouldn't need to implement any
sasl mechanisms, just get the password from the keyring). Ofcourse if the CM
doesn't recognize any of the SASL mechanisms, it doesn't have to expose it to
the client (but that seems strange)

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