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

[Will Thompson]

On 25/01/10 23:46, Dafydd Harries wrote:
> Ar 25/01/2010 am 22:15, ysgrifennodd Will Thompson:
>> Relatedly: perhaps this is a good reason to have an explicit Abort(): it
>> means the CM knows that the UI explicitly said "no, don't bother" rather
>> than crashing.
>
> Doesn't Destroy() already accomplish that?

So, the UI should call Destroy() to explicitly give up?

>> Also relatedly, and has just occurred to me: if you mess up the
>> challenge, do we really want a new channel to pop up and be
>> dispatched? That would mean a UI that wants to keep a prompt window on
>> the screen until the connection succeeds or fails is a bit harder than
>> it would be if there's at most one auth channel per connection attempt;
>> however, allowing repeated auth attempt on the same channel might
>> complicate the interface.
>
> I'm not sure I understand this prompt interface. Surely any prompt must at
> least be disabled while the response round trips.

That's true. I'm not sure I understand my point now either.

>>> So far, we haven't needed the authentication identity part. But I think we
>>> should include it in case mechanisms/protocols we haven't encountered yet
>>> require it. I'm not sure how we should include it, however.
>>
>> Would it be something that you could include along with the choice of
>> mechanism? “I want to use Kerberos; I am<foo>  and own<bar>.”
>
> Actually, I think this is always transmitted in a mechanism-specific way in
> responses to challenges. E.g. in Kerberos it's passed in the first response.
>
> As far as I can tell, with the KERBEROS_V4 mechanism, the authorization
> identity was always implicit (i.e. the server had to derive it from the
> authentication identity) because it's never sent as part of the SASL exchange.
>
> I'm really confused about Kerberos 5 and SASL. The reference for the
> KERBEROS_V5 mechanism is a person, not a document.

Ugh.

 > The RFC for the GSSAPI
> mechanism is called “The Kerberos V5 ("GSSAPI") Simple Authentication and
> Security Layer (SASL) Mechanism”, but talks entirely not in terms of protocol
> but in terms of GSSAPI functions I'm not familiar with.
>
> In short, I don't know how the authn vs. authz distinction works in practice.
> Trying to divine it from the standards has been an excercise in frustration.

But based on what you have divined from other protocols, it sounds like 
assuming it's transmitted in-band with the challenges and responses is safe.

> So, in review:
>
> We definitely need:
>
>   1. client → server SASL
>   2. server → client X.509
>   3. client → service authentication for SIP that we assume can be shoehorned
>      into SASL (hmm, how do we indicate the identity of authenticator in this
>      case?)
>   4. OTR
>
> We might need:
>
>   5. client → server X.509
>   6. server → client SASL
>   7. client → client SASL
>
> Out of these, my proposal currently covers #1 and most of #3, and Eitan's
> proposal covers #2.

And we just had some discussion in Cambridge about XTLS and SSL 
verification — which Sjoerd is writing up — and reckon we can adapt 
Eitan's proposal to cover #4 too.

> My biggest questions boil down to:
>
>   * Should we be worrying about unifying all of these, or just
>     accept that there might be multiple similar interfaces and some inelegance
>     and push ahead?

I personally think that we'll either end up with a handful of similar 
interfaces, or one really ugly and hard-to-understand interface; so if I 
were you I'd push ahead.

>   * How much should I be worrying about #5/#6/#7? Should I just concentrate on
>     what we know we need or worry about future expansion?

Under the same handful-of-similar-interfaces umbrella, I'd say the 
former. :)
-- 
Will