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

["tom.petch" <cfinss at dial.pipex.com>]

----- Original Message ----- 
From: "Peter Saint-Andre" <stpeter at stpeter.im>
Sent: Wednesday, October 28, 2009 6:46 PM

> 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

Peter

The comments I have made relate solely to use of X.509 certificates
with NETCONF, syslog, isms etc, nothing to do with public keys ie 
the validation of X.509 certificate against reference identity with these
protocols.

I would widen the reference identity beyond DNS and IP, to eg
URL and MAC.

The other wrinkle is the use of a fingerprint in order to avoid the need
to use CA/CRL/OCSP etc but again, this is for a pukka X.509 certificate
which would then be subject to checking against a reference identity
as above.

Tom Petch

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