----- Original Message ----- From: "Chris Lonvick" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> 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 protected] https://www1.ietf.org/mailman/listinfo/syslog
