On Fri, 2002-11-08 at 16:05, Christopher Lonvick wrote: > On 5 Nov 2002, Frank O'Dwyer wrote: > > I have been reviewing syslog-sign-07 and notice that it states the > > following "Syslog messages are sent over unreliable transport, which > > means that they can be lost in transit..." > > > > How does this square with use of the BEEP version of syslog? Is the > > intention to use signing only with the UDP transport? SYSLOG-REL is in > > the references of sign-07 but I couldn't find an actual reference in the > > text. > > Both syslog-reliable (now RFC-3195) and syslog-sign were initiated > independently with the thought that they could be complimentary. It may > be useful to indicate in the syslog-sign work that syslog-sign transported > over syslog-reliable provides cumulative benefits. Isn't syslog-reliable pretty much a pre-requisite, though? I mean, why check for deleted messages when you're using a transport (UDP) that is going to delete messages itself anyway. It is already known that UDP messages are lost under high load, and a router is more or less free to drop them and remain compliant. So given that you detect a missing message over UDP, it's hard for an implementation to know what to do with that information.
I would have thought that syslog-sign's benefits would be mainly on the storage side (detecting tampering), and just the general benefits of not having to establish and manage shared secrets, plus protection against rogue relays. But without reliable delivery, detection of tampering doesn't seem to be worth a lot. Am I missing something? > > One other point is that when using reliable syslog with authentication > > and encryption, this addresses many of the security requirements of > > syslog-sign (origin authentication, detection of missing messages, etc), > > at least within a particular session. The crypto overhead would probably > > be less, too. However there still could be an application for using both > > together, > > I think it's actually an implementation detail. In traditional syslog, > the work provisioning the devices and collectors is pretty minimal. The > thought was that this could be duplicated with syslog-reliable if we chose > BEEP which may call SASL w/ SSL/TLS. Authentication may be anonymous and > certificates may only need be presented by the server (or not at all). > This provides confidentiality and message integrity without distributing > and maintaining keys/certificates/passwords/etc. On the other hand, you > are free to provision and require tougher mechanisms if your policy > requires. In this ease-of-provisioning model, a rogue device may send > syslog messages to a relay or collector impersonating another device. True. I had in mind a model where every device would authenticate itself. In that case only a rogue relay could impersonate (which syslog-sign would detect). That is, relays or collectors could (and really should) drop messages where the authenticated peer was a device, but its hostname did not match the hostname in the message. I would also expect that real implementations would support 'legacy syslog' (i.e. completely vanilla syslog) for as long as there are devices out there sending messages that way. However I would expect them to treat these messages differently, e.g. flag them as unauthenticated and more or less "FYI". By the way, are there working implementations of either spec to test against for interop purposes? Especially, what can be assumed in the way of SASL and TLS support for interop? Cheers, Frank.
