Re: Identity Checking in Application Protocols

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

---- Original Message -----
From: "Peter Saint-Andre" <stpeter at stpeter.im>
To: "Kurt Zeilenga" <Kurt.Zeilenga at Isode.com>
Cc: "tom.petch" <cfinss at dial.pipex.com>; "Alexey Melnikov"
<alexey.melnikov at isode.com>; <apps-discuss at ietf.org>
Sent: Thursday, October 29, 2009 4:39 PM
Subject: Re: Identity Checking in Application Protocols


> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 10/29/09 8:51 AM, Kurt Zeilenga wrote:
> >
> > On Oct 28, 2009, at 10:20 AM, tom.petch wrote:
> >
> >> ----- Original Message -----
> >> From: "Peter Saint-Andre" <stpeter at stpeter.im>
> >> Sent: Tuesday, October 27, 2009 10:28 PM
> >>
> >>> On 10/27/09 4:28 AM, Alexey Melnikov wrote:
> >>>> Hi Peter,
> >>>>
> >>>> Peter Saint-Andre wrote:
> >>>>> I had hoped to update draft-saintandre-tls-server-id-check before the
> >>>>> submission cutoff today, but it's not going to happen because there's
> >>>>> quite a bit of feedback to sift through (ideally I would have followed
> >>>>> the list discussions more closely the first time around).  However, I
> >>>>> shall work to update it in the next few days, at which time I will
> >>>>> also
> >>>>> rename it to remove the strings "tls" and "server" since the scope of
> >>>>> the spec has widened to include non-TLS interactions as well as client
> >>>>> identity checking. My apologies for the delay.
> >>>>>
> >>>> Without my AD hat: I don't think the document should cover client
> >>>> identity checking. I found Kurt's arguments to be convincing.
> >>>
> >>> I think that the distinction between application roles and security
> >>> roles causes some confusion here. This I-D talks about security roles,
> >>> not application roles. Thus, for example, when two XMPP servers wish to
> >>> establish a TLS-encrypted connection, from the security point of view
> >>> the server that initiates the connection is a TLS client whereas the
> >>> server that receives the connection is a TLS server (despite the fact
> >>> that from an application point of view both of them are XMPP servers).
> >>>
> >>> My understanding of Kurt's argument is that we can't say much that's
> >>> helpful about how a TLS server checks the identity of a TLS client
> >>> because the problem is application-specific and the TLS server doesn't
> >>> really have a "reference identity" (an idea of what identity the client
> >>> will assert). At some level, the TLS server knows that it expects the
> >>> TLS client to assert a kind of identity (domain name, email address,
> >>> XMPP address, etc.) but not necessarily a particular instance of that
> >>> kind ("example.com", "foo at example.com", or whatever).
> >>>
> >>> I need to think about this further. I'm sure that re-reading Kurt's
> >>> messages will help...
> >>
> >> My take is that the only difference is one of number.
> >>
> >> A client is 'configured' with a single reference identity, eg by the user
> >> keying it into a window, which is then used in a comparison with what
> >> is returned in an X.509 certificate.
> >>
> >> A server may support more than one client and so may be configured
> >> with more than one reference identity and use any or all of them in a
> >> comparison with what is received in an X.509 certificate eg with SIP,
> >> Netconf, syslog,
> >> ....
> >>
> >> Of course, a server may not care to check, may not be configured with
> >> anything, in which case the procedures in this I-D are irrelevant
> >
> > My objection is not against an "application server" acting as a TLS
> > client verifying the identity of the TLS server it connects to.
> > My objection is against this I-D discussing in detail how an
> > "application server" acting as a TLS server might verify the identity of
> > the TLS client connecting to it.
> >
> > The difference between the two (generally speaking) is that in the
> > former, the verifying entity (the TLS client) has an assumption of trust
> > in the reference identity as it provided by the user (via some dialog or
> > configuration or whatever) as opposed to be programmatically determined
> > by the verifying entity (such as simply using the TLS client's IP
> > address as the reference identity, or using some IP address to reference
> > identity mapping, etc.).   The security considerations for these two
> > scenarios is quite different, and I simply rather avoid discussing the
> > latter in this document.
>
> Agreed, I would rather keep this I-D focused on the application client's
> task of verifying the identity of an application server. But nothing is
> stopping us from writing another I-D that focuses on other problems.

Peter

I don't think we can say anything about <application> client or server.

We are dealing with TLS or a similar protocol presenting an X.509
certificate for authentication, and the client for the security protocol
may be the server for the application or not as the case may be
so while I do not want us to restrict ourselves to TLS, I also think it
wrong to refer to application.

If you do need to differentiate the two ends of the connection (I dont':-)
then I suggest transport client and transport server, although even that
is not quite right as the TCP client could be the TLS server, ie they are
eight choices in prospect.

Tom Petch

> > I note that are other use scenarios, such as when the reference identity
> > is provided to the client via a referral mechanism.  That is, an
> > application clients to server A, A provides a referral to B, client
> > connects to B and now wants to verify B's identity.   I think this
> > scenario likely should be discussed to some degree in the I-D as it is a
> > relatively common application client scenario.
>
> Yes, I think it would be good to discuss that scenario, although I
> confess that I don't have a clear handle on what text would be appropriate.
>
> Peter
>
> - --
> Peter Saint-Andre
> https://stpeter.im/
>
>