Naming with non-PKI TLS authentication

| TrackBacks (1) |
Traditional TLS authentication was pretty much completely tied to old-style PKI. When you wanted to stand up your server, you went to one of the well-known CAs (typically VeriSign) and got a certificate that contained the name of your server, e.g. www.educatedguesswork.org. The standard reference here is RFC 2818 and of course RFC 3280.

Lately, though, I've been starting to see a lot more interest in more flexible (or at least non-PKI-based) models. The two big ones are:

  • Exchanging fingerprints in some out of band channel. See, for example, draft-ietf-mmusic-comedia-tls.
  • Using SSH-style "leap of faith" authentication where you just trust the first certificate you see from a given server and then check to see if it changes.

When you're using these models, you still use a certificate (that's what everyone who uses TLS is set up to use) it's just not signed by one of the universally accepted CAs. It might be accepted by an unknown CA or perhaps self-signed. However, despite the fact that a certificate is used, the underlying authentication model is totally different. In a PKI-based system, the certificate is an attestation about the binding between this name and a key. In these systems, it's just a convenient carrier for the public key and the authentication comes from somewhere else.

This raises the obvious question of what identity (either Distinguished Name or subjectAltName) should appear in the certificate. It's tempting to just stick with the RFC 2818 rules. This lets you do consistent name checking without regard to how the certificate got validated. But as a protocol designer or an implementor it's important to realize here that the name doesn't have any real security implication. It's just a placeholder and you can't trust it. The downside of following the 2818 rules is that they're a bit complicated and since the name is meaningless, if the server operator happens to get it wrong you're going to get a bunch of false security warnings, which is irritating at best and a source of interoperability failure at worst.

Consider, for instance, what happens if you have a self-signed certificate for "server.educatedguesswork.org". You then make a CNAME record (an alias) for "www.educatedguesswork.org" that points to "server.educatedguesswork.org". If someone tries to connect to "www.educatedguesswork.org" they'll get a name mismatch error of some kind, even if they are checking the fingerprint. That's obviously bad. Sure, you could make a new self-signed cert, but that's a pain, especially if the person controlling the DNS is the same as the person controlling the server's cert.

It's obviously not critically important which way you do things, but my intuition here is that having a consistent code path between the PKI and non-PKI cases is actually a bug here because it obscures the nature of the interaction. So, when I design or review protocols, I've been encouraging people to omit the checking in this case.

1 TrackBacks

Listed below are links to blogs that reference this entry: Naming with non-PKI TLS authentication.

TrackBack URL for this entry: http://www.educatedguesswork.org/cgi-bin/mt/mt-tb.cgi/521

poker casino481 from poker casino481 on February 11, 2006 6:41 PM

poker casino poker 654 Read More