Victor Duchovni wrote:
On Wed, Mar 07, 2007 at 03:34:31AM +0100, Vladislav Marinov wrote:
This is why I want to extract information about who is the hostname/IP
participating in the TLS handshake and compare it to the Common Name
field in the certificate.
This makes no sense, the client could be behind a NAT firewall, ... its
network address should be irrelevant, perform access control on the client
identity found in the cert, and ignore the IP address.
Client certs have IP addresses in them ? (I'm reading the thread to
learn more about DTLS but I really dont think the mechanics of the
process is any different for TLS and DTLS)
It sounds like someone is confusing the client validation of the server,
with the server validation of the client.
Stream based TLS can present a client certificate and its best to
authenticate based on the Serial ID of the certificate against a locally
held database. This works well for the case where the CA is managed by
the TLS server end. This way you automatically have CRL support because
you can switch single certificates on and off based on the Serial ID.
The Common Name is then used as an unique (per user) identifier to group
cert reissue and overlap of operational time window in which a specific
Serial ID is valid for. The Common Name can be any arbitrary identifier
scheme you choose (hostname, username, IP address, random garbage or
even a mixture of the these things) whatever makes sense to the server
to manage authentication, cert reissue and cert management.
Its not usual to record the IP address in the client certificate (for a
start it would give the attacker extra information as to why his
certificate wouldn't work and what he needs to do to fool the server).
If you need to lock down the client IP address this would be best
supported by a configuration check attached to the certificate Serial ID
(or Common Name) in the database of the server end. This makes it a
hidden requirement to the attacker who merely obtained the client cert.
One of the points of having a certificate is to forfill electronically a
security requirement "to authenticate with something you have". I use
the term have as in to have possession of. This is obviously not as
good as something physical which can't be cloned or copied but none the
less can address indisputable proof of possession.
So far I have discussed client certificate authentication performed by
the server, now to talk about client authentication of the server:
The scheme upon which web browsers employ is to validate the forward and
reverse hostname and IP address all match as an additional security
check. This scheme is usually not necessary in a privately managed CA
where the CA and server infrastructure are the same entity. In the case
of the web browser validation scheme they are separate entities and its
the client who is validating the identity of the server, where as the
server does not care who the client is (because he just wants hit Credit
Card details for his money).
For a privately managed CA the best way for the client to perform
repudiation checks for the server it to simply validate the client
certificate it is using against the server certificate given out. This
deals with stopping clients from sending sensitive information to a
server that accepted their certificate but it's actually a fake server
run by an attacker trying to gain information from clients. This is a
separate check that needs to be performed upon each connection by the
client, the "openssl verify" command embodies the mechanics of this check.
All in all there is no obvious reason to put an IP address or hostname
inside a client certificate when using a client certificate as part of
your authentication scheme. A username or user number would make far
more sense to me.
Darryl
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
