Hi Bazsi, I agree with you, thanks for the great clarification. I think this is also an excellent explanation why syslog-sign is necessary - and that a secure transport and -sign have some different applications.
When it comes to priorities, I am still in favour of mandating a TLS transport. The good in that is that you can actually guarantee authenticy, even in a relay chain, as long as you (can) trust all relays. In a typical corporate environment, I think this can be ensured. -sign, on the other hand, does not solve the "message observation" issue, which to the best of my knowledge is the driving force behind most of todays syslog/ssl implementations. The security considerations section for -transport-tls should list the hop-by-hop restriction and provide information on mitigating it. Rainer > -----Original Message----- > From: Balazs Scheidler [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 11, 2006 1:04 PM > To: Rainer Gerhards > Cc: [EMAIL PROTECTED] > Subject: RE: [Syslog] Re: Threat model and charter > > On Wed, 2006-01-11 at 10:37 +0100, Rainer Gerhards wrote: > > Chris, > > > > However, it *is* possible to authenticate the peers via X.509 > > certificates. Any TLS implementation can do client and server > > certificate verification as part of the session setup > process. To the > > best of my knowledge, some folks use this feature with > stunnel. So the > > server accepts messages only from clients which are > authenticated via > > their certificate (their certificate-based names are > configured at the > > server side). > > I basically agree with you, one minor addition that this X.509 > certificate based authentication is a hop-by-hop authentication and > provided the operator trusts all devices on the message path and > requires authentication on each hop, then message authenticity can be > ensured. There's no per-message signature, thus it is not > proovable that > a message was generated by a given device after it has been > received and > stored. > > A parallel example: It is in a sense similar to client > authentication in > HTTPS: if you upload a file using HTTPS where client certificate was > required and validated, then the file on the server can be > trusted to a > certain extent (as much as the HTTPS server can be trusted), however > there's no means to prove that the file has not been tampered > with after > it has been received. There was no signature _stored_ along > the file and > no such signature exists in the HTTPS protocol itself, to do this the > HTTPS client would need to generate a signature before > transmission and > upload the signature along with the file itself. > > Back to syslog: TLS and X.509 certificate authentication is hop-by-hop > and authenticates the infrastructure and network transmission (like > HTTPS itself), syslog-sign is a per-message authentication similar to > the client-side-sign-and-upload-along-with-file example in HTTPS as > described above. > > -- > Bazsi > > > _______________________________________________ Syslog mailing list [email protected] https://www1.ietf.org/mailman/listinfo/syslog
