On Tue, 2006-01-31 at 18:34 +0100, Tom Petch wrote: > ----- 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?
As I said the communication model is the same as current syslog to make the implementation possible with no real program changes. Thus the connection is established from the sender to the receiver, right before messages are sent. The connection might be kept opened for a period of time with a sane timeout value. > > - 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)? A separate port number would probably be necessary. > > - with multiple flows, are they multiplexed over a single connection? yes, just like they are now. > > - 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?) the one initiating the connection is client, the other presumably the server :) authentication has already been discussed, authentication should be warmly recommended (maybe even required). how the credentials are stored and distributed are an implementation issue, the credentials are X.509 certificates, they could be stored in secure storage or as files in PEM format. > > - what is the user to which these security credentials relate, particularly > for > authentication, how is the user identified? no user is identified, the credentials identify the "hop", thus the infrastructure element. > > - is authorisation to use secure syslog required? do you mean authentication here? authorization is again an imlpementation issue, it could be implemented as a list of trusted DNs, a single trusted CA which is required to sign all keys. Again authentication would be performed for _devices_ and not individual messages, e.g. it is not possible to verify the authenticity of separate messages, but it is an independent goal. > > - is another system needed to keep security credentials up to date, eg RADIUS? no, RADIUS is password based, TLS is RSA keypair based. Keys need to be distributed to all end-nodes. (to be more precise a certificate, the matching private key, the CA certificate(s) and a revocation list (or access to an online revocation service) But again, it is again an implementation issue how keys are distributed. > > 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). and not only the keys need to be distributed but the software running in _each_ device. we have customers who still use AIX 4.3 and Solaris 7, not to mention the necessity for firmware upgrades in various embedded devices. I think we already achieved something if we focus securing the syslog infrastructure (relay and center) first and then go on to other issues like message based authentication. Keyed hash also have a list of questions what you asked about TLS above: * how to get the shared key to the box? * what about replay detection? you need a sequence number, then what about losing messages? * if you want reliable transport then the same questions with connection establishment come up, if you stick with UDP, then what happens with lost messages, and how does this affect your sequence numbering? > > syslog is precisely like SNMP traps No, it isn't, but it probably depends on how you use it. syslog contains debugging information generated by applications which might not exactly know what they are dumping: it might contain sensitive information like passwords, mail bodies and instant messages. If you enable debugging on a router, it does not send that information as SNMP traps but it does send it in syslog. > 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. _It is_ being used. Just google around searching for "syslog-ng stunnel" I've just tried and found 133000 hits. You can even read step-by-step articles how to set this up on sun.com: http://www.sun.com/bigadmin/features/articles/syslog_ng.html (Stunnel + syslog-ng is a hack, I know that myself.) -- Bazsi _______________________________________________ Syslog mailing list [email protected] https://www1.ietf.org/mailman/listinfo/syslog
