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 Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
