Hello Frank, On 5 Nov 2002, Frank O'Dwyer wrote:
> Hi, > > 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. > > 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. In adding syslog-sign, an administrator should be able to get a device to generate a key and push that along in the syslog-sign certificate block. If a rogue device tries to impersonate that, then the administrator would only have to find the public key being held on the 'real' device to decide if a certificate block and the key were truely associated with that device. > and in particular for having collectors and/or relays use > syslog-sign "on behalf of" a peer connected via syslog-rel. Are proxy > signatures of this type envisaged, and if so are they within the scope > of syslog-sign? I hadn't thought of a relay/proxy being able to sign traditional messages from another device. I don't think that's a particularly good idea as the original syslog messages may be so easily spoofed. I am, however, very open to a discussion on this. Thoughts from others? Thanks, Chris
