Subject: RE: [Syslog] Threat model requirements discussion

From: "Anton Okmianski \(aokmians\)" <[email-masked]>
Date: Thu, 26 Jan 2006 13:39:42 -0500

I second Tom's opinion.

I think we should not preclude the use of transport that supports encryption, but I don't think it is as high a priority as integrity and authentication of origin. Certainly, there should be an option of not incurring encryption overhead when all you need is integrity and authentication. 

Anton.  

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Tom Petch
> Sent: Thursday, January 26, 2006 12:11 PM
> To: Chris Lonvick (clonvick); [email-masked]
> Cc: [email-masked]
> Subject: Re: [Syslog] Threat model requirements discussion
> 
> ----- 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
> 
> 
> > 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?
> >
> 
> 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>
> 
> 
> _______________________________________________
> Syslog mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/syslog
> 

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

---

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

FWIW: I agree with Baszi in all points.

Rainer

> [mailto:[email-masked]] On Behalf Of Balazs Scheidler
> Sent: Tuesday, January 31, 2006 2:35 PM
> To: Tom Petch
> Cc: [email-masked]; [email-masked]
> 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.
> 
> 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: "Anton Okmianski \(aokmians\)" <[email-masked]>
Date: Tue, 31 Jan 2006 13:31:46 -0500

My personal opinion below. Not speaking for WG, of course. 

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

Yes.  

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

I would guess this is where opinions may differ. 

I think - yes, it is a requirement. Both integrity support in general and its independence from transport. The latter extends protection beyond transport (to storage for example) and allows to defer validation till message is actually used if this is desired.     

Thanks,
Anton.