Anton SSH is now a set of RFC, RFC425?
Tom Petch ----- Original Message ----- From: "Anton Okmianski (aokmians)" <[EMAIL PROTECTED]> To: "Chris Lonvick (clonvick)" <[EMAIL PROTECTED]>; "Balazs Scheidler" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, January 11, 2006 8:50 PM Subject: RE: [Syslog] Re: Threat model and charter Hi! I am not sure how re-emerging "TLS vs. SSH" discussion pertains to the Threat Model for charter. They provide identical security except TLS requires PKI, while SSH can do PKI or shared-secrets. TLS is well established. SSH as a transport is not an RFC yet, as far as I understand, but been around in similar incarnation. So, the relevant issues for the charter in this discussions are: (a) Do we have to provide PKI support for auth? (b) Do we have to provide an auth option that does not require PKI? These requirements would likely drive choice between TLS and SSH. Another relevant issues: (c) Do we have to provide a light-weight non-encrypted security option which MUST work with any transport? Syslog-sign is such. It covers all of security except for encryption (message integrity). You get authentication of original message producer by virtue of shared secret. You get message integrity. If you include timestamp in integrity check, it can also provide replay protection. (d) Do we have to address message observation threat? If not. Then we don't need neither TLS/SSH - syslog-sign would do. This does not prevent new transport to be used. Some can be used by just underlying tunnels anyway. Thanks, Anton. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Chris > Lonvick (clonvick) > Sent: Wednesday, January 11, 2006 9:19 AM > To: Balazs Scheidler > Cc: [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 > _______________________________________________ Syslog mailing list [email protected] https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list [email protected] https://www1.ietf.org/mailman/listinfo/syslog
