Re: [Syslog] Some revised text for syslog TLS

Rainer Gerhards schrieb:
> scenario. Please note that operators tend to use IP addresses over
> hostnames because of reliability reasons and early startup capability of
> the syslogd (before DNS resolutions is available). So this is of
> practical relevance.

As noted later this will require the IP adresses to be included in the 
x509 certificates. The usual verification against the Common Name 
requires DNS.

> In case of the server authenticating the client, there is no such
> obvious choice. I could use the remote client's IP address (provided by
> the transport stack) and verify that it matches the IP address inside
> the certificate. However, is this really useful?

I think it is necessary since it is a mutual authentication: the client 
verifies the server, and the server verifies the client.
Each Authentication has two steps: 1. verify the trust path to the cert 
(either by CA signature, having the cert itself configured as a trust 
anchor, or having its fingerprint) and 2. check if the cert matches the 
requesting host (by IP or DNS, by Common Name or subjectAltName).

> IMO, this is more or
> less a check if the remote cert is signed by a common CA. Something that
> may be useful, but does not depend on the client's IP be known.

> Do you or somebody else on this list (Tom?) have a clue why it may be
> useful to carry out such a check?

Maybe the second step should be configurable (like the first one) since 
it is comes down to policy, but the question is: Do you accept a 
connection from client A if it shows a certificate from client B?

You might want to if you use only one cert for all clients, but if every 
client has its own cert then you might not, because this situation 
indicates a serious misconfiguration or intrusion.

> Back on the topic of easy but still secure configuration, I could
> envision taken the reverse DNS name of the transport sender and checking
> that against the identity presented in the certificate. Anyone any
> thoughts/comments on this?

Ack. I am going to do the same.

> Again, all of this assumes a common root CA and certificates signed by
> it (not necessarily full PKI, but an "in-house CA").

Either that or a collection af all involved certificates.
It should not make a difference if a common CA is the trust anchor or if 
every cert itself is.

-- 
Martin
_______________________________________________
Syslog mailing list
Syslog@ietf.org
https://www.ietf.org/mailman/listinfo/syslog