Re: [Syslog] Some revised text for syslog TLS

["Anton Okmyanskiy (aokmians)" <[e-mail]>]

The bottom line is that when you use a certificate to authenticate the
client, the trusted identity of the client that gets recorded in the
messages must be derived from certificate, not from other source like IP
address or whatever device or DNS says device might be. 

This can be handled by specifying appropriate tags (structured data ID)
for certificate fields and recommending that those are added to the
message (or updated) by the receiver if certificate-based authenticate
is used. 

This would prevent the case of some client using legitimate (but stolen)
certificate, and then indicating identity of another device in the
message itself. If such behavior were allowed, then when certificate is
stolen (but not yet put on certificate revocation list), this would
extend the security threat to a wider scope of issues because we are
allowing one device to masquerade as any other device.  

Note, that we need structured data field IDs not only for certificate
Common Name (CN), but also for fields such as fingerprint.  When one
certificate is revoked and a new one issues, I believe the new one can
have the same common name.  In that case, if the receiver wants to
identify which exact certificate the client used, you need to see the
fingerprint or other similar certificate fields. We had a use-case with
customer where such information was needed with TLS (albeit not in
syslog context). 

Regards,
Anton.



> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Moehrke, John 
> (GE Healthcare)
> Sent: Monday, May 26, 2008 3:16 PM
> To: Rainer Gerhards; Joseph Salowey (jsalowey); [e-mail]
> Subject: 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: [e-mail] [mailto:[e-mail]] On
> Behalf
> > Of Rainer Gerhards
> > Sent: Monday, May 26, 2008 2:19 AM
> > To: Joseph Salowey (jsalowey); [e-mail]
> > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/syslog
> _______________________________________________
> Syslog mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/syslog
> 
_______________________________________________
Syslog mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/syslog