----- Original Message ----- From: "Balazs Scheidler" <[EMAIL PROTECTED]> To: "Tom Petch" <[EMAIL PROTECTED]> Cc: "Chris Lonvick" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, January 31, 2006 2:34 PM Subject: Re: [Syslog] Threat model requirements discussion
> On Tue, 2006-01-31 at 11:28 +0100, Tom Petch wrote: > > > So I want to see a simpler solution - eg keyed hash - first and a more complex > > one which includes encryption as phase two (2007?). > > > > And yes, my views are coloured by SNMP which I have worked with for many years, > > where, as I have said before, users tell me they must have encryption but it > > usually turns out they have not yet learnt about the concept of differing > > threats. > > My points: > * syslog is way different than SNMP traps, it really does contain > sensitive information (not just link up/down). > * adding TLS is very simple from the implementation point of view: > adding a new transport layer to the software stack does not really > change the software (can be done without changing the software at all > via a wrapper like stunnel), message signatures is a big change in _all_ > senders > * adding TLS is very simple from the protocol specification point of > view: define a way to wrap messages to an "envelope" (e.g. NL > termination, or byte counter) and wrap messages into TLS > * adding message signatures is difficult both implementation and > specification wise, syslog-sign is far from being simple > > I'd say that the specification and implementation something like > syslog-sign is at least 3-5 times as big work as doing the same with a > drop-in package like TLS. > Note that I did not say syslog-sign, just keyed hash, so it is misleading to estimate the implementation effort when we are debating requirements (even if a possible design which may or may not match the requirements already exists). The kind of issues that need solving with SSH and/or TLS - reliable transport needed, eg TCP; when is the connection established, when is it taken down? - what port is used? if SSH/TLS, how is syslog traffic differentiated? if not, will IANA grant yet another port (or ports as allowed by syslog MIB)? - with multiple flows, are they multiplexed over a single connection? - which end is SSH/TLS client, which server? client and server in security protocols have significant impact on what security credentials are stored where, what customisation is needed before the system can be used (do you allow an unattended hub to perform a leap of faith?) - what is the user to which these security credentials relate, particularly for authentication, how is the user identified? - is authorisation to use secure syslog required? - is another system needed to keep security credentials up to date, eg RADIUS? and so on and so forth. Keyed hash? many of these issues disappear (and it could be end-to-end security were that a requirement, none of those concerns about relays). syslog is precisely like SNMP traps when you look at the wish that some users express for encyption, namely both are a one way flow over a datagram transport with some application client out there somewhere:-) And as I said, these issues have been mulled over by isms and netconf and, a year or so on, there are no obvious solutions. TLS may allow you to use off the shelf modules to achieve a quick code package but, and SNMPv3 is the case study here, the code package is not enough, the system must be sufficiently easy to implement if we are going to see it used. Tom Petch _______________________________________________ Syslog mailing list [email protected] https://www1.ietf.org/mailman/listinfo/syslog
