[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