Hi,
I was thinking that if we have to do authentication then we could try to
get consensus on a simple authentication mechanism - a shared secret.
Essentially, each sender would have to be configured with a shared secret
before it could use TLS. The receivers and relays would also have that
information. When a sender prepares a message, it would hash the shared
secret with the formed message. That hash could be placed in an SD
element ( [tlsAuthChk="12345678..."] ). The recipient could extract the
value, and then re-run the hash. If the received hash is the same as the
calculated hash then both the sender and the receiver must be using the
same shared secret. The caveat to this is in choosing the right hash
algorithm. This mechanism and shared secret authentication has been well
defined in many prior RFCs. A lot of those RFCs used MD5 which is now
going out of favor. Check out RFC 1305 (NTP - appendix D) and RFC 2385
(authentication for BGP).
This suggestion tries to keep the ease-of-use of syslog. Using
credentials stored in an X.505 certificate (of the recipient) would
provide a higher degree of authentication - shared secrets can be much
more easily compromised (found, guessed, brute-forced, etc.) than the
validated credentials contained in a certificate.
If we can get consensus that an in-packet authentication mechanism like
this is sufficient to meet our threat model, then we can decide if the
shared secret is sufficient (the REQUIRED mechanism), and/or if we want to
RECOMMEND a similar X.509 mechanism. That would require having each
syslog sender to have an X.509 certificate, and have those signed and
available. That just seems to me to be getting a bit far away from the
ease-of-use that makes syslog so easy to deploy.
Thoughts?
Thanks,
Chris
On Wed, 11 Jan 2006, Balazs Scheidler wrote:
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
_______________________________________________
Syslog mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/syslog
