[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 #22 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-10-19 04:42:07 PDT ---
(In reply to comment #21)
> 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)

Thanks, I'll have a look at that RFC.

> Your
> choice for either adding a boolean or split of a StartMechanismWithData (i
> think i prefer two methods instead of a silly boolean)

I agree with your preference.

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

Ah, good; a "road map" at the top would probably have made that clear. I'll
have a go at writing one.

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

Does your markup here mean that either the part [...|| or the part ||...]
happens?

This assumes that it's obvious from the definition of any mechanism that the
last Challenge is not actually a challenge, but instead an additional-data blob
(i.e. there's no time at which either a challenge or additional data would be
equally valid). I haven't checked whether that's true.

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

Yeah, I meant to ask about that. Mikhail suggests using D-H or something, like
the fd.o secrets service does, either immediately or a bit later.

Is it true that the only distinction between X-TELEPATHY-PASSWORD and PLAIN is
that the mechanism name implicitly tells the client who it's authenticating to
- if it's X-TELEPATHY-PASSWORD then it's the CM, else it's the server?

It occurs to me that another way to do this would be to say in the
AuthenticationInfo who we're authenticating with - it could be as simple as
{"talking-to-cm": True} - and use an unmodified SASL mechanism, presumably
PLAIN at first and some sort of D-H badgers later, to hand over credentials to
it. This is how I'd assumed the "smart CM, dumb protocol" case would work.

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