[Telepathy] Spec discussion sasl auth channels

[Sjoerd Simons]

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

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.

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.

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.

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?

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.

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 ?

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


Sjoerd

0:
http://people.freedesktop.org/~eitani/telepathy-spec-authentication/spec/org.freedesktop.Telepathy.Channel.Type.Authentication.DRAFT.html
-- 
Dying is one of the few things that can be done as easily lying down.
		-- Woody Allen