Hello folks. Recently I was tasked with continuing the work that Dafydd started on SASL. The good news is that this allows a more unified approach with the SSL and other authentication schemes we have been working on, specifically XTLS. The bad news is that I scratched a lot of the previous work Cosimo and I did in favor of a more symmetric and and clean interface (imho, anyway). I think most discussion items that I observed have been included in this spec, let me know if not.
You could see an outline on the wiki page[1], browse the HTML spec[2], or checkout my branch[3]. I don't think the other iterations were a waste of time, on the server TLS front I have been maintaining a gabble implementation in lockstep to the rewrites and I am still sane. I feel like the actual code changes required for this are not too big (can't speak for XTLS though). First a note about English: Verification and authentication are interchangeable. I know this seems obvious, but I just feel like pointing it out. In my mind at least - verification is remote authentication, meaning we are verifying the remote peer is who she says she is. So in the new spec I scratched all mentions of verification, and I have stuck with authentication exclusively while distinguishing between remote and local authentication. In the old spec we had some weak points and some omissions that are critical to SASL: - Variable number of response/challange round trips. - Support for local authentication. the verification interface provided remote authentication, but the only local authentication we have is incomplete and hidden in the IdentityExchange interface. - Simple mechanism negotiation, not necessary, but the current NegotiateVerification iface is very complex for SASL needs. The new spec has a few benefits, imho: - One channel. Take E2E for example, we used to have 3 consecutive channels. Negotiation, verification and certificate exchange. In this design there is only one (for better or worse). - Incremental complexity: Take a look at the chatroom example[4] or the server TLS[5] example. They only require one interface. More complex exchanges like E2E[6] use more interfaces. - The Challange/Respond pattern let's us be more flexible about different authentication stages, this is how I added certificate exchange in to the SRP_BOOTSTRAP method. - The Challange/Respond pattern also makes the mechinism opaque and thus it is separate from the telepathy API. I think it was a mistake, for example, to have a certificate-specific API in telepathy. - We unify the mechanism negotiation for all protocols and schemes under a common API. 1 http://telepathy.freedesktop.org/wiki/Authentication#UnifiedInterface 2 http://people.freedesktop.org/~eitani/telepathy-spec-authentication/spec 3 http://git.collabora.co.uk/?p=user/eitan/telepathy-spec.git;a=log;h=refs/heads/authentication 4 http://git.collabora.co.uk/?p=user/eitan/authentication-whiteboard.git;a=blob;f=client_chatroom.txt;hb=inline-negotiation 5 http://git.collabora.co.uk/?p=user/eitan/authentication-whiteboard.git;a=blob;f=client_server.txt;hb=inline-negotiation 6 http://git.collabora.co.uk/?p=user/eitan/authentication-whiteboard.git;a=blob;f=client_client.txt;hb=inline-negotiation On Mon, 2010-02-01 at 18:49 +0000, Will Thompson wrote: > 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. :)
signature.asc
Description: This is a digitally signed message part
_______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
