[Telepathy] Spec meeting notes on SASL authentication and SSL cert verification

Eitan Isaacson eitan.isaacson at collabora.co.uk
Thu Mar 11 22:43:53 PST 2010


On Thu, 2010-03-11 at 23:10 +0000, Will Thompson wrote: 
> This looks nice! The example flows made it pretty easy to get my head 
> around; maybe they could be included in the preamble in some form or 
> another later on?
> 

Sure, we could drop that in the wiki perhaps, or where you thinking in
the spec itself? Maybe when the developer's guide covers authentication
it could use those.

> Something similar to the chatroom password example could be used to make 
> clients that just want to provide a password when you log in, rather 
> than storing it on disk, easier, with a TP_PASSWORD mechanism where you 
> just Respond("secretpassword"). Which would save simple clients having 
> to know how to do SASL PLAIN. Maybe those clients don't actually exist, 
> but it's nice to know it's possible.

Not sure what you mean by this. When SASLing with the server it will
always be a SASL_ mechanism. But for chatroom joins and the like, where
the security level is relatively low, the chat UI could handle the
TP_PASSWORD mechanism or whatever.

> 
> Maybe the authentication rejection reasons should be namespaced strings, 
> D-Bus error style? This would prevent the need for the Other member, and 
> would allow people with particularly weird auth requirements to use this 
> more easily. But perhaps this is YAGNI territory.
> 

Hm, not a bad idea. I don't mind either way. Although revising the enums
or the namespaced strings seem to be the same kind of headache.

> It's a little weird that the Challenge signal is also used for "here is 
> a response from the other party", and the Respond() method is used to 
> issue challenges to the other party. But this is just a naming thing; it 
> makes sense from a technical perspective.
> 

Yeah, challenge/response is used liberally in the SASL RFC. It doesn't
matter who is authenticating against who, the challenge is the remote
response, and the response is the remote challenge. I took the same
liberty in this spec.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/telepathy/attachments/20100311/09b7d540/attachment.pgp>


More information about the telepathy mailing list