Re: [Telepathy] Spec meeting notes on SASL authentication and SSL cert verification
Hi, -Original Message- From: telepathy-boun...@lists.freedesktop.org [mailto:telepathy- boun...@lists.freedesktop.org] On Behalf Of ext Eitan Isaacson Sent: Thursday, March 11, 2010 12:04 AM To: Will Thompson Cc: telepathy@lists.freedesktop.org Subject: Re: [Telepathy] Spec meeting notes on SASL authentication and SSL cert verification 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. Thanks. I like that the proposed way is friendly to cases when the dispatcher needs to pop up a separate authentication UI, which can even ignore differences between channel and connection auth. Also, this isolated UI process could have elevated privileges and be better secured. Few minor comments: - A challenge channel should present some human-readable string, to possibly inform what is being authenticated. The string SHOULD be formed locally by the connection manager, so as to avoid presenting remotely supplied information as trusted. - Maybe there should be a list of request tokens from the original channel request(s), available through the ChannelAuthentication interface, to refer to requested channels that will be created after the authentication is successful. Best regards, Misha ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Spec meeting notes on SASL authentication and SSL cert verification
On Thu, 11 Mar 2010 at 13:01:34 +0100, mikhail.zabal...@nokia.com wrote: Few minor comments: - A challenge channel should present some human-readable string, to possibly inform what is being authenticated. The string SHOULD be formed locally by the connection manager, so as to avoid presenting remotely supplied information as trusted. If connection managers continue to not be localized, then the auth UI would have to form this string itself by understanding the meaning of the channel (e.g. putting together TargetHandleType=CONTACT, targetid=s...@example.com, and ideally also the local address book to say secure communication with Simon McVittie s...@example.com). I'd suggest that it should ignore (close) channels it doesn't understand well enough to present such a thing? The usual rationale for connection managers (and MC) not being localized: * UI environments have much more infrastructure and policy for translations than we do (e.g. the Empathy translations come from GNOME's localization teams, and Maemo translations are done internally by Nokia according to the UI specification), but CMs and MC need to be UI-independent * Consistent translations are (AIUI) consistent within a UI environment - GNOME in Klingon, Maemo in Klingon and KDE in Klingon don't necessarily have the same translation guidelines (e.g. the word to use to translate application). Regards, S signature.asc Description: Digital signature ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Spec meeting notes on SASL authentication and SSL cert verification
Hi, -Original Message- From: telepathy-boun...@lists.freedesktop.org [mailto:telepathy- boun...@lists.freedesktop.org] On Behalf Of ext Simon McVittie Sent: Thursday, March 11, 2010 2:40 PM To: telepathy@lists.freedesktop.org Subject: Re: [Telepathy] Spec meeting notes on SASL authentication and SSL cert verification On Thu, 11 Mar 2010 at 13:01:34 +0100, mikhail.zabal...@nokia.com wrote: Few minor comments: - A challenge channel should present some human-readable string, to possibly inform what is being authenticated. The string SHOULD be formed locally by the connection manager, so as to avoid presenting remotely supplied information as trusted. If connection managers continue to not be localized, then the auth UI would have to form this string itself by understanding the meaning of the channel (e.g. putting together TargetHandleType=CONTACT, targetid=s...@example.com, and ideally also the local address book to say secure communication with Simon McVittie s...@example.com). I'd suggest that it should ignore (close) channels it doesn't understand well enough to present such a thing? Yes, I agree that an informational string should not really be treated as an UI-ready message. And if we always have a way to identify the peer or the destination through basic Channel properties, and connect the challenge to requests that caused it, fine. Misha ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Spec meeting notes on SASL authentication and SSL cert verification
Thanks for the feedback! On Thu, 2010-03-11 at 13:01 +0100, mikhail.zabal...@nokia.com wrote: Thanks. I like that the proposed way is friendly to cases when the dispatcher needs to pop up a separate authentication UI, which can even ignore differences between channel and connection auth. Also, this isolated UI process could have elevated privileges and be better secured. Few minor comments: - A challenge channel should present some human-readable string, to possibly inform what is being authenticated. The string SHOULD be formed locally by the connection manager, so as to avoid presenting remotely supplied information as trusted. Some thing like John is requesting authentication? The problem with that is localization. CMs don't localize strings, I believe the UI does that exclusively. So the channel would probably need to present machine readable information for the UI to make human readable. Aren't there enough hints in the channel to pick up? - If the channel is anonymous it is authentication for the Connection object (ie. the server). - If it has a target handle, and a target handle type, it should be enough information to work with: Chatroom Car-Talk is password protected, please enter password, John is requesting authentication, John's certificate is self-signed, etc. - With the change you suggest below, even more could be figured out about the authentication's context. - Maybe there should be a list of request tokens from the original channel request(s), available through the ChannelAuthentication interface, to refer to requested channels that will be created after the authentication is successful. Good idea. There should probably be two properties, one for requests tokens and one for already existing channels. Cheers, Eitan. signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Spec meeting notes on SASL authentication and SSL cert verification
Evenin', On 10/03/10 22:04, Eitan Isaacson wrote: 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]. This looks nice! The example flows made it pretty easy to get my head around; maybe they could be included in the preamble in some form or another later on? Something similar to the chatroom password example could be used to make clients that just want to provide a password when you log in, rather than storing it on disk, easier, with a TP_PASSWORD mechanism where you just Respond(secretpassword). Which would save simple clients having to know how to do SASL PLAIN. Maybe those clients don't actually exist, but it's nice to know it's possible. Maybe the authentication rejection reasons should be namespaced strings, D-Bus error style? This would prevent the need for the Other member, and would allow people with particularly weird auth requirements to use this more easily. But perhaps this is YAGNI territory. It's a little weird that the Challenge signal is also used for here is a response from the other party, and the Respond() method is used to issue challenges to the other party. But this is just a naming thing; it makes sense from a technical perspective. -- Will ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Spec meeting notes on SASL authentication and SSL cert verification
On Thu, 2010-03-11 at 23:10 +, Will Thompson wrote: This looks nice! The example flows made it pretty easy to get my head around; maybe they could be included in the preamble in some form or another later on? Sure, we could drop that in the wiki perhaps, or where you thinking in the spec itself? Maybe when the developer's guide covers authentication it could use those. Something similar to the chatroom password example could be used to make clients that just want to provide a password when you log in, rather than storing it on disk, easier, with a TP_PASSWORD mechanism where you just Respond(secretpassword). Which would save simple clients having to know how to do SASL PLAIN. Maybe those clients don't actually exist, but it's nice to know it's possible. Not sure what you mean by this. When SASLing with the server it will always be a SASL_ mechanism. But for chatroom joins and the like, where the security level is relatively low, the chat UI could handle the TP_PASSWORD mechanism or whatever. Maybe the authentication rejection reasons should be namespaced strings, D-Bus error style? This would prevent the need for the Other member, and would allow people with particularly weird auth requirements to use this more easily. But perhaps this is YAGNI territory. Hm, not a bad idea. I don't mind either way. Although revising the enums or the namespaced strings seem to be the same kind of headache. It's a little weird that the Challenge signal is also used for here is a response from the other party, and the Respond() method is used to issue challenges to the other party. But this is just a naming thing; it makes sense from a technical perspective. Yeah, challenge/response is used liberally in the SASL RFC. It doesn't matter who is authenticating against who, the challenge is the remote response, and the response is the remote challenge. I took the same liberty in this spec. signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Spec meeting notes on SASL authentication and SSL cert verification
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 +, 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 amfoo and ownbar.” 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
Re: [Telepathy] Spec meeting notes on SASL authentication and SSL cert verification
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 amfoo and ownbar.” 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 ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Spec meeting notes on SASL authentication and SSL cert verification
Ar 20/01/2010 am 17:59, ysgrifennodd Will Thompson: SaslAuthentication: • Is SaslMechanism an ASCII string Yes. IANA maintains a list of them: http://www.iana.org/assignments/sasl-mechanisms • It should probably be plural, so that the UI can pick the mechanism it wants to use. • So the usage goes: ∘ ChooseMethod( mechanism, crap ) where crap is some initial data which you include with your choice of mechanism (which according to Sjoerd is supported by SASL). ∘ n times: ‣ get Challenge() ‣ call Respond() ∘ get Success() or Failure() • One we have a ChooseMethod() method then we don't need the Challenge property for state recovery. Ok. • Could Abort() just be Close()? Or do we need a reason in Abort() for XMPP? “I'm aborting because the server sent an incorrect challenge.” etc. cf. Call This was to preserve correspondance with the SASL RFC, but I'm not sure how useful it is, and actually it doesn't really cover the full SASL abort semantics: http://tools.ietf.org/html/rfc4422#section-3.5 • Do they need to be Destroyable, if they respawn? No: Close() is like Destroy() in this diagram. The CM should only ever pop up a new challenge channel if the previous one failed rather than just being closed. This diagram? • Identity/rôle: is it inside the sasl mech's string of misc? Use case please? String of misc? Again, this is part of the SASL model. It has two concepts of identity: the authentication identity (who you are) and the authorization identity (who you act as). I might /authenticate/ that /I am/ the owner of a particular X.509 ceritificate so that I am /authorized/ to /act as/ xmpp:dafydd.harr...@collabora.co.uk. 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. • Separable: OTR's “phone your contact, agree on a codeword, both type it into your client, clients exchange hashes” verification method is a counter-example. Ok, so how does everything work when you need to authenticate both ways? While some SASL mechanisms may allow clients to identify the server, SASL is inherently asymmetric and geared towards authentication of the client to the server. • How does the CM know when we don't trust the peer? Sjoerd says: part of the challenge can be the server saying it knows a hash of your password, so that you know the server is not MITMed. This doesn't really answer the question. What if the mechanism you're using doesn't allow you to trust the peer? Putting the policy in the CM feels wrong. If you get a certificate from the server and verify it, or if you have some means from the forward-SASL to identify the server (or at least know that it knows your password, which isn't exactly the same thing), then everything's good. But if those things don't happen during connection, what do you do? Should you be able to initiate reverse-SASL, assuming the protocol allows it? Does the authentication handler just disconnect the connection? Or does the client get to do it? If the authentication handler does it, how does the client know that that's why the connection was terminated? Do we add a new connection termination reason? ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Spec meeting notes on SASL authentication and SSL cert verification
On Thu, Jan 21, 2010 at 10:16:27AM -0800, Eitan Isaacson wrote: Also, how certain is the client of the remote server's hostname? It seems like there is no definitive way of knowing, there is only a well-known RequestConnection 'server' parameter, maybe I missed it? In the XMPP case, a CM might do some additional DNS voodoo, like SRV and reverse lookup, a protocol-agnostic client won't be able to reliably do this. Yes, the CM needs to tell the UI what server name the UI should be verifying (e.g. via the Server property on the channel). In some protocols we might need to give the UI a list of hostnames any of which would be acceptable, I suppose? I doubt this ever needs to be plural the CM should be able to know what it is verifying. With new-style TLS protocols the client always tells the server in some way who its expecting to connect to and in the old-style SSL stuff you always verify the canonical name of the server. In case the server has multiple names this should be dealt with by using wildcards/multiple names in the certificate not multiple potential identities from the client side. Also as a side-point, the name you need to verify should never ever come from DNS lookups as that makes you trivially vulnarable to MITM attacks. Sjoerd -- Entropy isn't what it used to be. ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Spec meeting notes on SASL authentication and SSL cert verification
On Wed, 20 Jan 2010 at 11:39:44 -0800, Eitan Isaacson wrote: On Wed, 2010-01-20 at 17:59 +, Will Thompson wrote: Sjoerd and Simon think we want different channel types for verifying servers' certs and for verifying contacts', with a common interface, rather like how (modern) tubes are [...] I think I like this idea, but just to see I understand: Channel.Type.CertificateVerification will have one property, Resource. The only paths that utilize this channel type are Connections. No, something like: Channel.Type.ServerVerification readable property Server: s TargetHandleType = NONE requires interface Channel.Interface.CertificateVerification Channel.Type.ContactVerification TargetHandleType = CONTACT requires interface Channel.Interface.CertificateVerification Channel.Interface.CertificateVerification is where the rest of the API will reside Yes. SendCertificate seems unexpected. What does the cert represent? What does RequestedIdentity *mean*? Need examples. The RequestedIdentity is the identity the remote peer needs to verify, for example: Simon is exchanging certificates with Joe. Joe has two certificates, one for his gmail address, and one for his work address. Since Simon is chatting with Joe through Joe's work account, he needs to verify Joe's work identity, thus RequestedIdentity, on Joe's end with show 'joe.plum...@work.com'. So his client knows to send the work cert. Did I get this all wrong? Is that scenario unrealistic? Is Simon the local Telepathy user or the remote XMPP user in this diagram? It seems you're using the same channel to authenticate Simon's identity to Joe, and to authenticate Joe's identity to Simon. If that's the case, then it's important that the spec text (and examples) make it completely clear who's being asked to trust what. So we actually just want the channel to have an array of PEM fingerprints, an Accept() method, and Reject( reason goes here? ) method, and not have separate objects for each certificate. I had no idea this scenario could exist. You could identify with multiple certificates simultaneously? No reason you couldn't... Anyway, if this is really the case, I think a good way to deal with it is in a linear fashion, while keeping SSLCertVerification singular. For example: 1. Receive CACert signed cert from peer, channel state is AcceptCertificate. 2. Reject certificate with 'untrusted' reason. 3. StateChanged is fired. 4. Receive Collabora CA signed cert. 5. Reject/Accept 6. goto 3 Do we really want to force prompting the user n times as a matter of API? It seems to me that the actual question being asked is I have these two forms of identity, are they sufficient for you to believe that I'm me?. If this is the case, then you might as well present all available certificates in parallel. (There is another possible trust level: perhaps Mikhail doesn't trust either CAcert or Collabora individually, but is willing to believe that if both CAcert and Collabora say I'm me, then they're right :-) But apropo certificate lists, I chose to send a single PEM encoded certificate, while it seems that many TLS APIs provide a list of certificates that represents the signature chain. I chose not to include those for the reasons below. What are those reasons? If the CM has the signature chain, it might as well tell the client; at worst, the client ignores it. In particular, if the certification model is more complex than the CA model of blindly trust a set of designated CAs to sign anything, don't trust anyone else at all (think XMPP end-to-end encryption here, rather than authenticating servers), you might well need the whole certificate chain. About cert properties: We should probably add fingerprint as a property, as for other properties, it may get tricky since we are not relying on a specific type of certificate, so it may be an openpgp x509, or whatever which have different fields(?). Although there might be a few common ones, didn't actually look at this. Why can't the UI just receive all the source information the CM has, and make its decision based on that? (For instance, if the UI wants to show the user a fingerprint, it can compute it from the cert.) We want to avoid clients relying on the CMs doing preliminary verification on certs, so maybe Certificate_Status should go away. (Sjœrd may already have said this in an email.) A CM should present certs without comment, and the client should say yes, no or meh; only in the meh (legacy) case should the CM make its own judgements. This makes the most straightforward use-case a bit more complex - present the user with a dialog when verification fails, and let them decide to ignore the failure. I'm not convinced that Here is a popup you do not understand because it's full of scary words like SSL, certificate and fingerprint. Do you want to keep talking to someone who looks superficially like your friend Joe? is
Re: [Telepathy] Spec meeting notes on SASL authentication and SSL cert verification
On Thu, 2010-01-21 at 11:40 +, Simon McVittie wrote: On Wed, 20 Jan 2010 at 11:39:44 -0800, Eitan Isaacson wrote: On Wed, 2010-01-20 at 17:59 +, Will Thompson wrote: Sjoerd and Simon think we want different channel types for verifying servers' certs and for verifying contacts', with a common interface, rather like how (modern) tubes are [...] I think I like this idea, but just to see I understand: Channel.Type.CertificateVerification will have one property, Resource. The only paths that utilize this channel type are Connections. No, something like: Channel.Type.ServerVerification readable property Server: s TargetHandleType = NONE requires interface Channel.Interface.CertificateVerification Channel.Type.ContactVerification TargetHandleType = CONTACT requires interface Channel.Interface.CertificateVerification Much clearer, thanks. Is Simon the local Telepathy user or the remote XMPP user in this diagram? It seems you're using the same channel to authenticate Simon's identity to Joe, and to authenticate Joe's identity to Simon. If that's the case, then it's important that the spec text (and examples) make it completely clear who's being asked to trust what. So the gap here is just documentation? I could improve on that. So we actually just want the channel to have an array of PEM fingerprints, an Accept() method, and Reject( reason goes here? ) method, and not have separate objects for each certificate. I had no idea this scenario could exist. You could identify with multiple certificates simultaneously? No reason you couldn't... I couldn't find this in any spec[1][2][3], that is why I asked. Anyway, if this is really the case, I think a good way to deal with it is in a linear fashion, while keeping SSLCertVerification singular. For example: 1. Receive CACert signed cert from peer, channel state is AcceptCertificate. 2. Reject certificate with 'untrusted' reason. 3. StateChanged is fired. 4. Receive Collabora CA signed cert. 5. Reject/Accept 6. goto 3 Do we really want to force prompting the user n times as a matter of API? It seems to me that the actual question being asked is I have these two forms of identity, are they sufficient for you to believe that I'm me?. If this is the case, then you might as well present all available certificates in parallel. (There is another possible trust level: perhaps Mikhail doesn't trust either CAcert or Collabora individually, but is willing to believe that if both CAcert and Collabora say I'm me, then they're right :-) But apropo certificate lists, I chose to send a single PEM encoded certificate, while it seems that many TLS APIs provide a list of certificates that represents the signature chain. I chose not to include those for the reasons below. What are those reasons? If the CM has the signature chain, it might as well tell the client; at worst, the client ignores it. In particular, if the certification model is more complex than the CA model of blindly trust a set of designated CAs to sign anything, don't trust anyone else at all (think XMPP end-to-end encryption here, rather than authenticating servers), you might well need the whole certificate chain. Yeah, I'll add that. About cert properties: We should probably add fingerprint as a property, as for other properties, it may get tricky since we are not relying on a specific type of certificate, so it may be an openpgp x509, or whatever which have different fields(?). Although there might be a few common ones, didn't actually look at this. Why can't the UI just receive all the source information the CM has, and make its decision based on that? (For instance, if the UI wants to show the user a fingerprint, it can compute it from the cert.) That is currently what's expected. The client receives a raw PEM it could parse any way it wishes. We want to avoid clients relying on the CMs doing preliminary verification on certs, so maybe Certificate_Status should go away. (Sjœrd may already have said this in an email.) A CM should present certs without comment, and the client should say yes, no or meh; only in the meh (legacy) case should the CM make its own judgements. This makes the most straightforward use-case a bit more complex - present the user with a dialog when verification fails, and let them decide to ignore the failure. I'm not convinced that Here is a popup you do not understand because it's full of scary words like SSL, certificate and fingerprint. Do you want to keep talking to someone who looks superficially like your friend Joe? is good UI to be treating as a baseline in any case - everyone will just click yes and carry on with their unencrypted lives :-) It is a wonderful way of life :) I misunderstood the basic aim of this API. I thought we were mostly making it easy for clients to deal with
