Re: [Syslog] Some revised text for syslog TLS

[Rainer Gerhards <[e-mail]>]

Hi Pasi,

inline...

On Mon, 2008-05-26 at 15:28 +0300, [e-mail] wrote:
> 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.  

Please keep in mind that my message was related to the question if there
is a use case for using IPs inside a certificate. As I said above, there
is.

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

rsyslog of course supports this. The actual syntax is:

$ActionSendStreamDriverAuthMode x509/name # soon to be default
$ActionSendStreamDriverPermittedPeer syslogsrv2.example.com
*.* @@192.0.2.1

The $ActionSendStreamDriverPermittedPeer directive can be specified
multiple times, for example when talking to an active/passive cluster
with different identities (or whatever else may come up).

To prevent relying on tcp, one could also add syslogsrv2.example.com
to /etc/hosts, which would also lead to

*.* @@syslogsrv2.example.com

In any case, the goal is to have automatic authentication, and this
works well with a common trusted CA. An "in-house" CA may also issue
certificates with IP addresses.

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

Even if the certificate has an IP - does that really gain me something?
I think using the certificate's IP doesn't provide me any additional
security in this case.

I think this authentication is not useful and the server really can not
automatically be configured to detect permitted remote clients - except
for wildcard names.

(as a side-note, rsyslog allows a mode where it just checks the validity
of the remote certificate - so a common CA can be used to automatically
authorize a broad range of machines).

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

Plus, it would again introduce the DNS dependency. So that's probably a
bad idea.

But after this conversation: is there really any use case for IP
addresses in the certificate? I begin to get the feeling that we should
probably remove the text about them - there are ample work-arounds to
achieve the same, mostly better, effect.

Rainer

_______________________________________________
Syslog mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/syslog