[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 #23 from Sjoerd Simons <sjoerd at luon.net> 2010-10-19 05:11:18 PDT ---
(In reply to comment #22)
> (In reply to comment #21)
> > 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?

Yes. The difference is in whether it's a mechanism with or without additional
data (figuring out which one is which is left as an exercise to the reader)

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

Yes, we're implementing a sasl protocol which has no additional data field in
the success message here (See paragraph 3 of RFC 4422).  Every mechanism has to
be able to handle this.

We picked this way as you can trivially transform from a protocol doing
success-with-additional-data to the challenge-with-additional-data,empty
response,succes sequence without any knowledge of the underlying sasl
mechanism, while the reverse is impossible.

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

We can add that part later, with the same semantics, just a different way of
transferring the information, afaik gnome-keyring doesn't even always use the
DH part.

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

You never authenticate to the CM, but that's me nitpicking. All
non-X-TELEPATHY-* mechanisms are a direct conversation with the server, while
the X-TELEPATHY-* ones is just giving credentials to the CM indeed.

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

I don't think masking PLAIN is a good idea. Leave it to the UI to choose, yes i
want to do PLAIN with the server or let the CM handle it for me.

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