identity checking redux (was: Re: Call for discussion topics for Apps Area meeting in Hiroshima)

[Peter Saint-Andre <stpeter at stpeter.im>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/28/09 10:12 AM, Dave CROCKER wrote:
> 
> 
> Peter Saint-Andre wrote:
>> I'd like to discuss draft-saintandre-tls-server-id-check so that we can
>> get closer to consensus about what exactly we want to cover in that I-D
>> and whether we need additional I-Ds for related topics.
> 
> 
> If I read the draft correctly:
> 
>    "If a client wishes to connect to a server securely, it needs to check
>    the identity of the server so that it can determine if the server is
>    what it claims to be"
> 
> seems to be the salient statement about the problem to be solved.
> 
> Can you elaborate a bit? I'm only looking for a somewhat more extensive
> spec of your topic goal, rather than trying resolving it, here.

We seem to have discussed several possibilities:

1. Define how an application client checks its expectations ("reference
identity" = domain name or IP address) against what the application
server presents in a CA-issued certificate. We have a great deal of
experience with this model in HTTP, IMAP, LDAP, XMPP, and so on. It
seems valuable to abstract from those instances to form a more general
conception of how an application client should check the identity of an
application server.

2. Other application protocols (SSH, Netconf, SysLog, etc.) use keys
instead of X.509 certs. Here the application client needs to bootstrap
some notion of trust (which might be "leap of faith" in the presented
key) and then in the future simply verify that the same association
continues to hold (i.e., there is no concept of a "reference identity"
here). It appears that some folks would like to specify this in the same
document, whereas others want to specify it separately.

3. Other application protocols (DTLS, XMPP, etc.) enable one client to
communicate with another client in a way that enables end-to-end
security. Here the credentials might be keys or certs, but I think more
typically keys, in which case the fingerprint verification model might
apply (except that the identity being checked is not an application
server but a peer client).

There are, no doubt, questionable assumptions lurking in the summary
I've provided, which is why I think it makes sense to discuss this in
Hiroshima.

Peter

- --
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrog4kACgkQNL8k5A2w/vwu4wCg4z903KLFIIWKOcF+0EGFAzV/
Ue8AoLUUv/wmZsQ//WjaV7+urao8To5v
=o1dz
-----END PGP SIGNATURE-----