Re: [Syslog] Some revised text for syslog TLS

[<[e-mail]>]

Anton,

If you want to work on specifying such structured data fields,
that's fine (I agree that they could useful in many situations);
but it's way too late to add anything this big to the 
syslog-transport-tls draft. So this would be a separate document.

Best regards,
Pasi

> -----Original Message-----
> From: Anton Okmyanskiy (aokmians)
> Sent: 27 May, 2008 02:24
> To: Moehrke, John (GE Healthcare); Rainer Gerhards; Joseph 
> Salowey (jsalowey); [e-mail]
> Subject: Re: [Syslog] Some revised text for syslog TLS
> 
> 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
> 
_______________________________________________
Syslog mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/syslog