Chris, I think a shared secret is not actually much less management overhead then certificates. You need to distribute the shared secret anyway, much the same as you distribute the certificates.
>From the implementor's standpoint, I assume most implementors will use openssl or a similar library. These libraries all support certificate processing. In fact, it should be done as part of the session setup process. So, in short, the implementor will already have almost everything implemented that is necessary. The only thing missing are some configuration file entries (or whereever the config is kept) that allow the operator to specify which sending systems to accept (something necessary for shared secrets, too). I tend to assume that shared secrets are a bigger effort to implement than certificate based authentication. >From the security perspective, there is the hop-by-hop problem Bazsi mentioned. With TLS, you can only secure/authenticate from hop to hop, leaving a gap. With TLS, you also do not get anything that you can persist to the log file (at least not easily). The hash you propose offers this. However, isn't that hash not just a signature? If so (and I think so), we are back at syslog-protocol. I do not fully agree with Baszi that it does not offer additional benefits. Relays do not necessarily need to rewrite the signature, so it can provide a genuine "stamp" of the orginal sender. It even can be persisted to a log file and such. I think we should address this need in the context of syslog-sign, which already put a lot of effort into it. In my point of view, the ideal solution is transmitting signed messages via certificate-authenticated TLS. I haven't look at -sign lately, but I think the signature could be based on the same cert that is used for TLS authentication. A receiver could even be configured to check that the signature matches the sender (obviously not an option when relaying, but in other cases it might be useful). So we could use the same technology for multiple purposes - plus the technology is close to what is already being deploed (signing shouldn't be too hard for an implementor if openssl is already used for TLS...). Rainer > -----Original Message----- > From: Chris Lonvick [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 11, 2006 3:19 PM > To: Balazs Scheidler > Cc: Rainer Gerhards; [EMAIL PROTECTED] > Subject: RE: [Syslog] Re: Threat model and charter > > 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
