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

[Eitan Isaacson]

On Wed, 2010-01-20 at 17:59 +0000, Will Thompson wrote:
> Eitan's CertificateVerification interface
> =========================================
> 
> <http://people.freedesktop.org/~sjoerd/telepathy-spec-cert_verification/spec/org.freedesktop.Telepathy.Channel.Type.CertificateVerification.DRAFT.html>
> 
> 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. This clarifies what the "Resource"
> is: it would become a property that is the connection (along with the
> name of the server!) for servers. For channels, the CertVerification
> object doesn't know which channels it's for; rather, the channels have
> an interface saying they're awaiting verification, pointing to the
> request. We discussed this in the telepathy@ thread “API sketches for
> encrypted channels, and OTR” — beginning with Message-ID:
> <4AD3A017.3020108 at collabora.co.uk> — in particular, Cosimo's replies
> based on conversations with Sjoerd.

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.

Channel.Interface.CertificateVerification is where the rest of the API
will reside, if the verification is for a connection it uses the
dedicate channel type above. If it is for a peer channel, this is an
interface on top of the target peer channel.

> 
> 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.plumber at work.com'. So his client knows to send the work cert.

Did I get this all wrong? Is that scenario unrealistic?

> 
> State looks like FT, which is good.
> 
> GetCertificate() probably wants to be plural — Sjoerd should check this
> — and to include the certs' properties. It could be a property —
> Certificates: a{oa{sv}} — so that clients don't have to GetAll() on each
> object.
> 
> But on closer inspection: Simon points out that you're accepting
> the identity, so even if you have >1 cert then you only want to
> accept/reject once. 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.
> 
> Example:
> • Simon presents his contacts with two certs identifying him, one from
>    Collabora and one from CACert
> • Will trusts Collabora but not CACert; Steve trusts CACert but not
>    Collabora; Tollef trusts both; Bill Gates trusts neither.
> • Simon doesn't care why Will, Steve or Tollef trust him; and if Bill
>    doesn't, then he didn't trust any of the certs.
> • So we don't need Accept() or Reject() to say anything the specific
>    certs?
> 

I had no idea this scenario could exist. You could identify with
multiple certificates simultaneously?

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

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.

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.

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

In the current draft, the client just needs to read the
CertificateStatus property, and present a human readable notification to
the user with accept/reject buttons.

If the property goes away, the client will be forced to utilize a TLS
library to do it's own verification magic.

Of course, a client could choose to do verification with it's own CA
pool and CRL, and ignore the CM-set CertificateStatus property.

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.

> Scary situation: verification UI crashes, MC calls Close(), CM decides.
> Would we ever be in a situation where the UI would reject a certificate
> but the CM would accept the cert?
> Solution: If we know that there is a client on the system which supports
> this channel type, but the channel gets closed rather than accepted or
> rejected, then the CM should be really strict on the fallback path
> (rather than being lenient, as is Gabble's current default).
> 

Maybe client-side verification could be requested during
RequestConnection? That way, we could interpret close() as reject. This
is really only relevant to connection verification, since if a peer
channel is closed, it negates the need for verification.


Cheers,
  Eitan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/telepathy/attachments/20100120/029cce39/attachment.pgp