Subject: Re: [Syslog] Threat model requirements discussion

From: Balazs Scheidler <[email-masked]>
Date: Wed, 01 Feb 2006 13:24:36 +0100

On Tue, 2006-01-31 at 18:34 +0100, Tom Petch wrote:
> ----- Original Message -----
> From: "Balazs Scheidler" <[email-masked]>
> To: "Tom Petch" <[email-masked]>
> Cc: "Chris Lonvick" <[email-masked]>; <[email-masked]>;
> <[email-masked]>
> 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-masked]
https://www1.ietf.org/mailman/listinfo/syslog

---

From: "Rainer Gerhards" <[email-masked]>
Date: Wed, 1 Feb 2006 13:46:05 +0100

> (Stunnel + syslog-ng is a hack, I know that myself.)

If you google for just syslog + stunnel 

http://www.google.com/search?q=syslog+stunnel&hl=en&lr=&safe=off&start=0
&sa=N

you'll find 212,000 results - and many of them seem to be quite related
to what we discuss. tls protected syslog is something that is widely
used.

Rainer