Subject: [Syslog] Threat model requirements discussion

From: Chris Lonvick <[email-masked]>
Date: Wed, 25 Jan 2006 12:24:57 -0800 (PST)

Hi Folks,

We need to back up a moment and formalize our thoughts on the threats that we 
are going to address to "secure" syslog messages.  We need to have this 
discussion to ensure that any mechanism we decide to provide will address the 
threats.  The summary of our discussion will likely be included in 
syslog-transport-(secure) to show our objective and how the mechanism 
meets it.

>From the prior discussions, it looks like the primary threats to current syslog 
messages are:

- message observation
- message tampering, injection, replay
- message loss

If these are the threats (please respond to the list if you don't agree), 
then we can deploy the following mechanisms to thwart them:
   - message encryption at the transport layer will prevent observation
   - transport layer encryption with a sufficient message authentication
     check (mac) mechanism will allow a receiver to detect attemps of
     tampering, injection and replay
   - transport layer encryption will provide seqenced delivery of messages
     in transit

Is this sufficient for our needs?

Does the possibility of message loss due to network unavailability need to be 
addressed at this time?  This will be addressed in syslog-sign, but do we need 
an additional mechanism (such as the required use of the eventID SD-ID) to 
ensure that messages generated but not delivered are detected by the receiver?

If we can agree that these are the threats, and mechanisms that will thwart 
them, then we can finalize our discussion on a transport layer service and add 
that to our charter.

Please respond to the list with your thoughts.  We need responses to this to 
make sure that we're on the right track with this discussion.  Please keep Sam 
cc'd on this thread.

Thanks,
Chris

_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog

---

From: "Tom Petch" <[email-masked]>
Date: Thu, 26 Jan 2006 18:10:35 +0100

----- Original Message -----
From: "Chris Lonvick" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, January 25, 2006 9:24 PM
Subject: [Syslog] Threat model requirements discussion

> Is this sufficient for our needs?

I disagree.  I think this list of threats is excessive.

As I have said before, I regard integrity and message origin authentication as
the needs, with modification and spoofing as the threats.  I do not see
observation as a problem and although others have said it is, noone has given an
example of a syslog message that is so significant that it must be kept secret.
Doubtless someone will produce some but I doubt I will ever be convinced that it
is as important as the first two threats I mention.

The logical conclusion of your approach is that what we need is encryption,
encryption and encryption, and oh, we could throw in a little MAC here and
there.  I think this makes it too complex, too costly with the result that the
security that is needed, and could be provided more simply, will not happen.

Tom Petch

<snip>

---

From: Balazs Scheidler <[email-masked]>
Date: Thu, 26 Jan 2006 21:08:28 +0100

> is as important as the first two threats I mention.

Application Layer firewall logs may contain sensitive information such
as passwords, especially when running at a high log level.

Lots of people are using syslog-ng with stunnel for similar reasons now.

So maybe we should consider both schemes: authenticating the origin of
each message _AND_ standardizing encrypted transport. I vote for
encrypted transport but there might be enough support for the first one
as well.

-- 
Bazsi

---

From: Chris Lonvick <[email-masked]>
Date: Sun, 29 Jan 2006 18:11:14 -0800 (PST)

Hi Bazsi,

Would you look at the section of RFC3411 that David Harrington forwarded 
and put those sections in a priority order as you see they would apply to 
syslog?

Thanks,
Chris

---

From: Chris Lonvick <[email-masked]>
Date: Sun, 29 Jan 2006 18:33:17 -0800 (PST)

Hi Tom,

I see your points.  It appears that the section of RFC3411 that David 
Harrington sent around agrees with your analysis for SNMP.  However, as 
Baszi says, devices are using encryption for syslog for what is considered 
to be sensitive information when high levels of debugging are enabled. 
How would you address that?

Thanks,
Chris

---

From: "Tom Petch" <[email-masked]>
Date: Tue, 31 Jan 2006 11:28:47 +0100

----- Original Message -----
From: "Chris Lonvick" <[email-masked]>
To: "Tom Petch" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Monday, January 30, 2006 3:33 AM
Subject: Re: [Syslog] Threat model requirements discussion

Chris

I would not exclude encryption as a defence against message observation but
would give it a lower priority, my experience suggests a much lower priority,
than message origin authentication and integrity.  My concern is that we end up
with a solution whose complexity or cost makes it unsuitable for users whose
needs would be satisfied by a simpler one, namely authentication and integrity
without encryption - in technical terms, I see adding a keyed hash as more
attractive than deploying SSH or TLS etc

Any solution has some of the same issues - key distribution and maintenance -
but what I am mindful of is that this is an event/notification system (and
one-way at that) which reverses client and server roles compared to much of the
rest of systems management.  SNMPv3 solved this problem but in a way that users
found unacceptable to implement; isms and netconf have yet to solve it, we have
not yet begun to think about it.

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.

Tom Petch

<snip>

---

From: Balazs Scheidler <[email-masked]>
Date: Tue, 31 Jan 2006 14:34:43 +0100

> usually turns out they have not yet learnt about the concept of differing

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.

But I guess this is a yes/no argument so we have to come up with a
decision. I would propose an agenda like:

1) syslog-protocol
2) syslog-protocol over TLS
3) message integrity/authenticity checking in syslog-protocol

Or maybe even start work on 2) and 3) in parallel.

-- 
Bazsi

---

From: Sam Hartman <[email-masked]>
Date: Tue, 31 Jan 2006 12:51:08 -0500

>>>>> "Tom" == Tom Petch <[email-masked]> writes:

    Tom> The logical conclusion of your approach is that what we need
    Tom> is encryption, encryption and encryption, and oh, we could
    Tom> throw in a little MAC here and there.  I think this makes it
    Tom> too complex, too costly with the result that the security
    Tom> that is needed, and could be provided more simply, will not
    Tom> happen.

I will say that encryption and macs are very easy to do and I think
you'd need to show a strong argument that they will not perform well
before performance concerns can be taken seriously.

The question  I really need answers to is:

* Does the WG believe that Authentication of the origin of the message is a requirement for the mandatory to implement approach?

* Does the WG believe that integrity protection independent of transport is a requirement for the mandatory to implement?

I want these questions answered independent of particular choices
about implementation complexity.  

Ultimately this comes down to Chris judging the consensus of the WG
based on the discussion here.

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Tue, 31 Jan 2006 13:05:45 -0500

Tom, I'd like to ask you to give your requirements independent of any
particular implementation biases.

I'm trying to determine if the requirements match what the WG is able
to implement.  It doesn't help me do that when people keep mixing the
two issues.

I do completely understand that if we get impossible to implement
requirements for our security solution then we'll have to go back and
revisit something.

---

From: "Tom Petch" <[email-masked]>
Date: Tue, 31 Jan 2006 18:34:37 +0100

----- 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

> 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

---

From: "Tom Petch" <[email-masked]>
Date: Tue, 31 Jan 2006 19:46:15 +0100

> * Does the WG believe that Authentication of the origin of the message is a
requirement for the mandatory to implement approach?

Yes, this is top of my list

>
> * Does the WG believe that integrity protection independent of transport is a
requirement for the mandatory to implement?

No; integrity per se yes (comes second on my list), but integrity independent of
transport, no (just nice to have)

Tom Petch