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