On Oct 7, 2009, at 4:09 PM, tom.petch wrote:
---- Original Message -----
From: "Kurt Zeilenga" <Kurt.Zeilenga at Isode.com>
Sent: Wednesday, October 07, 2009 9:14 AM
On Oct 6, 2009, at 12:09 PM, tom.petch wrote:
This I-D is very hot on the fact that it is about Server Identity,
yet
technically, I see no reason why the logic does not also apply
equally
to client identity.
In networking, with the networking box as server, and the client
being the one that wants to change the configuration, then client
identity is the one that matters, not server.
I would like to add an initial paragraph to the effect that
although
the memo is written in terms of Server Identity, there is no
technical reason why the processes described cannot be applied
to verifying the Client Identity.
I'm not sure this makes sense. The connection model assumed in
this
document is that the user (directly or via configuration) specifies
the name of the server which than the client connects to, and this
document then specifies how to match the user specified name (or a
secure derivation of that name) to the subject of the certificate
the
server provides.
The technical reason why this cannot be applied to verifying the
client identity is that server's operator has not specified any
name
to match up the subject in the client's certificate. Also, the
client certificate is likely to that associated with a human, not a
service. So the rules would differ significantly.
I part company with you here.
In the field of Operations and Management, then the (network)
box is the server and is configured with the identifiers of those
who may access it eg to update the configuration, so yes, the
reference identity is pre-configured in the server. This may be
an IP address, a host name, an e-mail address etc etc.
The latest I-D includes a quote from the syslog RFC but omits
the earlier statement in that RFC
" Both syslog transport sender (TLS client) and syslog transport
receiver (TLS server) MUST implement certificate-based
authentication. "
so without rules for the server to follow, this I-D would be of
no use to syslog (and similar operational applications).
I disagree. A syslog document can provide the text necessary to
describe how the process detailed in this I-D is applied to syslog.
It has to do this anyways.
The only think this text makes explicit is that the process defined
by
this I-D could be used for client identity verification. I don't see
any reason why this actually needs to be said. I worry that saying
it
might lead to implementations using this process for client identity
verification without fully considering the implications. I rather
leave it to protocol specifications which make use of the
verification
process for client identity verification to discuss the implications,
especially the security implications associated with one determines
which reference identity to use as input to a client identity
verification process.
I would (still) suggest adding to Section 1
"This memo is written in terms of a client authenticating the
identity
of a server. Where the server is configured with reference
identities
for clients, and the client certificate contains an identity of the
types
described in section 3.2, then this process MAY be used by a
server to authenticate the identity of a client."
How does the server determine which of the reference identities it
has
been configured with ought to be the one used to verify the
certificate the client provided?
Why is a "configuration" approach needed? Maybe the application
protocol wants to just use the client IP address as the reference
identity, or use a DNS-based reverse lookup of the client IP address,
or some other approach.
I think for the verification process defined by this I-D to be used
for client identity verification, there must be additional text
describing the process for determining which reference identity to
use
as input to client identity verification process. There will be
security considerations specific to the process of determining the
reference identity input which ought to be discussed.
