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