[Telepathy] Spec discussion sasl auth channels

[Eitan Isaacson]

On Wed, 2010-04-28 at 12:48 +0100, Sjoerd Simons wrote:
> === One channel type to rule them all ===
> 
> (this bit is ghost-written by wjt :))
> 
> Combining the channel types forces you to have a single UI for dealing
> with all aspects of any given channel. In the XTLS case, this is
> probably okay. In the SASL case: does the handler for some custom SASL
> mechanism also have to be able to check SSL certificates, or will those
> two actually be two separate channels (even though they could be combined)?

A SASL auth channel follows a SSL channel when connecting, they are not
the same channel. They are the same channel type however.

In the current version, the different authentication channels have
different interfaces depending on their use, as seen in the table on the
wiki page[1]. This could be sufficient for distinguishing which handlers
should deal with what.

> 
> It's desirable to have a single channel for a single authentication
> operation... But:
> 
> Connect time:
>        SSL
>    and Captcha
>    and SASL
> 
> You probably don't know up-front that there'll be a captcha.
> 
> XTLS:
>         SSL
>    (and shared secret if needed)
> 
> In the latter case, the second head on the channel would have to pop up
> only once you realise that you don't trust the other party's certificate.
> 

I wrote flow diagrams to show how these different cases would pan
out[2]. Not sure if you saw them.

> So how do we choose handlers for these channels? Combining everything
> onto one channel type seems to make it harder to share out the chores.

Like I mentioned above, if this isn't enough we could either make
distinct channel types, or have an immutable property that would signify
what kind of authentication the channel is for.

> 
> Bundling the successive channels together smells like it's solving a
> dispatcher limitation (hinting that the second channel should go to the
> same handler as the first one, if possible) which we could better solve
> in the dispatcher.
> 
> Related point: do we actually want to have >1 handler for auth channels
> in general? Sjoerd reckons we do: Empathy should have a "hey, i need a
> password" thing; Empathy's accounts UI might also have one
> 
> === The SASL negotiation itself ===
> 
> This just focusses on
> org.freedesktop.Telepathy.Channel.Type.Authentication.DRAFT [0] and its usage
> wrt. using it for plain old SASL.
> 
> First for those less familiar with SASL some basics from a high-level
> perspective first, basics SASL authentication from a Client to a Server goes
> like this:
> 
> Server: I support SASL mechanisms A, B and C
> Client: Cool, let's go for B + optionally some ``initial data''
> Server: Ok, here is my Challenge
> Client: So here is my Response..
> < the challenge-response steps are repeated as often as is needed for the
>   mechansism>
> Server: Awesome, you've successfully authenticated + optionally some
>         ``final data''
> 
> Whether there is a initial and final data is defined by the choosen SASL
> mechanism. How often the Challenge, Reponse ping-pong is repeated is also
> defined by mechanism. For example in the PLAIN sasl mechanism, the initial data
> contains your password, there is no challenge and response sequence and the
> server sends success without any final data.
> 
> When there is final data it's basically always the server proving that it
> shares a secret with the client. Which means that not in essence the server
> also authenticated to the client :)
> 
> To complicate things on the wire protocol a bit more, not all protocols allow
> one to sent the initial data together with the selection of the authentication
> mechanism or send the final data together with the success. In both cases this
> is solved by one party sending an empty string instead of sasl data (empty
> challenge in case of initial data, empty response in case of final data). Not a
> big issue, but something to keep in mind.
> 
> 
> Looking at the suggested interfaces, the way to select a mechanism isn't
> coupled to the challenge/response mechanism. So essentially we have a protocol
> where we can't send initial data with mechanism selection. Which means the CM
> needs to start the process by sending an empty challenge and the handler
> probably needs to send an empty response if it has no initial data or that
> MechanismNegotiated should implicitely be seen as such an empty challenge and
> the handler starts with sending the reponse.. I think i prefer the latter.
> 
> In case of the latter, having a Pending_Initial_Response state would probably
> be good (even though in practise the same handler will always choose the
> mechanism).
> 
> The same is true for final data. So we need to document that the Handler is
> meant to sent an empty response there. Also to support mechanisms in which the
> server needs to proof its identity property we need a way for the handler to
> accept the fact that the server declared the authentication as successful.
> Which probably entails adding an extra state and a method for the Handler to
> indicate its agreement.
> 

Ok, I know we don't fully agree on this, but I'll try to make my point.
Bare with me :)

initial-response and data-on-success support depends on 3 things:
method, mechanism and protocol. For example, SASL+PLAIN+XMPP will
support initial-response, but if any of the above elements are swapped,
it is not guaranteed. For the tp API consumer, I don't think it makes
sense to take into account the method, mechanism, and protocol at use.
It is for the CM to determine if initial-response is supported by the
remote peer, take advantage of it, and be bomb-proof if proven wrong.

The whole initial-response/data-on-success deal takes up 3/4 of the SASL
RFC, which is fine when you are designing a wire protocol, but frankly
is pretty uninteresting on a semantic level.

This is how things are super-simplified on the UI end:
1. You choose a mechanism.
2. (challenge+response)*n
3. success or failure

A challenge always precedes a response, and a response always succeeds a
challenge. Does this mean the CM should ignore protocol/mechanism
availability of initial-response/data-on-success? Of course not.

For example, in the case of SASL+PLAIN+XMPP, we get an empty challenge
that the CM synthesizes after we picked a mechanism, before sending
<auth />. Once the CM gets a Respond() it sends the <auth /> with the
mechanism and the initial-response.

In the case of data-on-success in SASL+DIGEST-MD5+XMPP, the CM sends the
data-on-success to the UI as a challenge, and does not let the
authentication conclude until it receives an empty response (basically
ack).

In short, ir/dos is for the CM to take advantage of, not for the UI to
be confused with. And decoupling the mechanism selection is a good
thing.

IMHO :)

> Looking at the various properties i'm unsure why the Challenges property has
> the history of all challenges we got instead of just the latest one?
> 

Seemed like a good idea at the time :P for example in DIGEST-MD5 you
would want to see the original challenge to verify the server's second
challenge, but obviously the handler should store this, and this could
be nicked.

> It seems we're missing a property which tells us what our username  is, which
> one need to be able to implement various SASL mechanisms.

Originally I thought AuthorizationIdentity could be reused for this, if
it is not explicitly set. On second thought, maybe and a{sv} would be in
order?

user:foo
realm:example.com
session-id:2432423
etc..

> 
> The fact that this interface tries to generalize several mechanisms is
> something that seems to just add complexity? Is there a good rationale of why
> doing so makes things for implementors on both sides ?
> 

Hope I answered that above. I think the decoupling into multiple
interfaces makes the process just as complex as the auth method actually
is, for example TLS is extremely simple, SASL is not bad, and XTLS is as
complex as it already was :)
I think the examples I provided[2] demonstrate that.

> Also the Mechanism property seems declare our own list of known mechanisms. In
> sasl this is already defined by various RFCs. It would be better to have
> the type of mechanisms (SASL, TLS, SNAKES) and the type-specific mechanism
> used seperately. Where for SASL that would just be the SASL names as defined by
> the exisiting standards.
> 
> 
> If anyone actually managed to read the whole mail up till this point without
> falling asleep: go out and buy yourselve a cookie or a big cup of coffee as a
> reward :)

done :)

> 
> Sjoerd
> 
> 0:
> http://people.freedesktop.org/~eitani/telepathy-spec-authentication/spec/org.freedesktop.Telepathy.Channel.Type.Authentication.DRAFT.html

1: http://telepathy.freedesktop.org/wiki/Authentication
2:
http://git.collabora.co.uk/?p=user/eitan/authentication-whiteboard.git;a=tree


-------------- 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/20100505/7d59a3c6/attachment.pgp>