[Telepathy] Spec discussion sasl auth channels

[Sjoerd Simons]

On Wed, May 05, 2010 at 03:58:08PM -0700, Eitan Isaacson wrote:
> 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.

The issue i have with this is that it's hard to explain to people (and hard to
code). For example if i have a handler for C->S TLS i need to check if it has
the RemoteAuthentication Interface but none of the others, which seems the
wrong way round. And also it's potentially not futureproof if we add interfaces
for different (or maybe the same) use-case.

Your suggestion later in this thread to have an immutable AuthenticationType
property sounds like going the right direction. I think if we have a
channel-type to basically indicate the use-case and a AuthenticationType doing
a specialisation then we win.

So for example channels with:

  { Channel.Type: ServerAuthentication,
    ServerAuthentication.AuthenticationType: SASL }

or for Captcha support

  { Channel.Type: ServerAuthentication,
    ServerAuthentication.AuthenticationType: CAPTCHA }

And for EULA support:
  { Channel.Type: ServerAuthentication,
    ServerAuthentication.AuthenticationType: EULA }

I'm currently not entirely sure if SSL certificates checking should go into
this interface, but we could have an AuthenticationType for that.

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

I indeed didn't. When reviewing a spec i always assume that the spec is
self-contained :).. Your general flow seems to be the same as the one i was
thinking of so that's awesome :)

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

Well if the UI is going to implement a SASL mechanism it needs to know every
well how IR/DOS works in our case. My main point was, how do these things work
with your Interface as there was no documentation at all about it.

Also a CM implenting this interface needs to know very well how these bits
work when translating it to its wire-protocol :) So while the way you choose to
do it might not be very interesting, documenting it properly is (but yes i do
find your solution for ir/dos a bit complex and unelegant :p)

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

Maybe, i'm not sure, the properties you need do change very much in various
situations (e.g. DIGEST-MD5 needs realm, SCRAM-SHA1 doesn't need it, jabbers
old-style digests needs a session-id, but nothing else ever uses that).

An a{sv} with some well-known keys sounds very sensible, then the CM could just
stuff everything it knows which you potentially need in it..

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

I'm unconvinced with this argument. Yes i agree that we can translate
everything into a generic challenge-response structure. But i think if we
follow that route we end up with a reasonably simple interface, with a lot of
text of how one would use it in a lot of different circumstances and some
aspects of it only being used for one of them. Currently you'd use one
interface to do TLS (both server-side and client-side), SASL, CAPTCH, EULA/TLS,
misc and other.

It seems easier to have a somewhat less generic interfaces geared towards
use-case/method. Both from a documentation standpoint and a Implementation
standpoint. I'll send a mail later on how i'd polish up the C/R interface to do
SASL slightly nicer

> > 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
-- 
God is the tangential point between zero and infinity.
		-- Alfred Jarry