Re: [Syslog] Some revised text for syslog TLS

Going back to the first question...

Tom Petch

----- Original Message -----
From: "Rainer Gerhards" <rgerhards@hq.adiscon.com>
To: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>; <syslog@ietf.org>
Sent: Monday, May 26, 2008 9:18 AM
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?

You have lost me here.  Suppose I am a server and I want to check that syslog
only comes from someone I trust so I will configure an identifier in the server
and want security credentials to authenticate an assertion of that identity.
The IP address is the identity, and the certificate the security credential.

Or the host name is the identity and the certificate the security credential.

Or the MAC address is the identity and the certificate the security credential.

I do not see a difference (except that some identities are commoner than others
as Pasi points out).

Tom Petch
>
> 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