Re: [Syslog] Some revised text for syslog TLS

I have said this before, but people continue to go down this path... 

The TLS authentication has already proven that the 'other' side holds
the private key... this is cryptographically secure authentication... 

Adding a check of the IP address or DNS address adds very very little
value, and is not cryptographically secure (unless using Secure DNS). 

Therefore there is little value to adding IP or hostname checking, and
lots of ways it will break (NAT, DHCP, etc).

John

> -----Original Message-----
> From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On
Behalf
> Of Rainer Gerhards
> Sent: Monday, May 26, 2008 2:19 AM
> To: Joseph Salowey (jsalowey); syslog@ietf.org
> Subject: Re: [Syslog] Some revised text for syslog TLS
> 
> Joe,
> 
> I like this new text.
> 
> I am snipping everything below except the one thing that drives a
> question:
> 
> > 	o IP-address-based authorization where the IP address configured
> > for the authorized peer is compared against the subject fields in
the
> > certificate.  Implementations MUST support matching the IP address
> > against a SubjectAltName field of type iPAddress and MAY support
> > checking the configured IP address against the Common Name portion
of
> > the Subject Distinguished Name.  Matching for certificate
credentials
> > is
> > performed using the matching rules specified by [3].  If more than
one
> > IP Address identity is present in the certificate a match in any one
> of
> > the set is considered acceptable.
> 
> 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.
> 
> 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?
> 
> 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?
> 
> Again, all of this assumes a common root CA and certificates signed by
> it (not necessarily full PKI, but an "in-house CA").
> 
> Thanks,
> Rainer
> _______________________________________________
> Syslog mailing list
> Syslog@ietf.org
> https://www.ietf.org/mailman/listinfo/syslog
_______________________________________________
Syslog mailing list
Syslog@ietf.org
https://www.ietf.org/mailman/listinfo/syslog