Re: [Syslog] Some revised text for syslog TLS

Rainer Gerhards wrote:

> I know that you asked about the usefulness of IP based
> authentication before. I am now at a point where I have actually
> finished my implementation and I am "polishing" it. On my agenda is
> now a as good as possible *automatic* authentication.
> 
> For the client to authorize the server, it is quite easy.  There
> usually is something like
> 
> *.* @@192.0.2.1
> 
> In this case, I can take the destination ("192.0.2.1") and verify it
> against the server's certificate. Provided we use a common root CA,
> this setup is fully automatic. So supporting IPs is quite useful in
> this 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.

I agree that in some situations, we don't want to depend on
DNS. However, this is somewhat orthogonal to what the certificate
contains.

AFAIK certificates containing IP addresses are quite rare; host names
are much common.  To support such situation -- while still avoiding
dependency on DNS -- it would be useful if you could configure the IP
address (used for opening the connection) and server name (compared
against the certificate, but not looked up from DNS) separately.

I don't know what that would look like in your configuration file
syntax, but maybe something like

*.* @@192.0.2.1[syslogsrv2.example.com]

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

It doesn't seem very useful to me... I guess you could have a local
"wildcard" or "netmask" saying that only clients from 192.0.2.* are
allowed to connect; if your certificates contain IP addresses,
presumably you'd use the address in the certificate (and not the
transport) for that check. (But as I said, certificates containing
IP addresses are not common.)

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

This doesn't seem very useful to me, and AFAIK no such thing
is done in other protocols using TLS/certificates.

Best regards,
Pasi
_______________________________________________
Syslog mailing list
Syslog@ietf.org
https://www.ietf.org/mailman/listinfo/syslog