Subject: [Syslog] Threat model and charter

From: Chris Lonvick <[email-masked]>
Date: Tue, 10 Jan 2006 08:47:54 -0800 (PST)

Hi All,

I'd like to address this topic in three parts:
1) The threat model and what threats we feel are important to address
2) How we should address those threats
3) Wording our charter

== 1 ==

I'd like to review the on-the-wire threats documented in RFC 3164 and see 
what we want to address.

>From RFC 3164 Section 6:

6.2  Message Authenticity (incl. Forgery)
6.3  Sequenced Delivery (incl. Replaying)
6.4  Reliable Delivery
6.5  Message Integrity
6.6  Message Observation
6.7  Message Prioritization and Differentiation

Including a per-message signing mechanisms would address message 
authenticity (6.2).  However, that would require key maintenance and would 
require a lot of touching of the end-points.  That seems to be 
counter-productive to current implementations of syslog.  I've found that 
many are willing to put up with unauthenticated messages rather than to 
have to step up their maintenance of those systems.
[ TLS is not required to authenticate the client.  SSH can (SHOULD) 
[ require that the user authenticate to the server.  Utilizing SSH could 
[ provide a mechanism to address 6.2, but again that seems to be higher 
[ maintenance than what most people would like to do for syslog.

Sequenced delivery (6.3) will be addressed by the eventID SD element in 
syslog-protocol.
[ syslog-sign will additionally address this by including the engineID.
[ Additionally, a REQUIRED secure transport would ensure proper 
[ sequencing but would not alone provide stored-message sequence 
[ verification.

Reliable delivery (6.4), message integrity (6.5), and message observation 
(6.6) may be addressed through the use of a REQUIRED secure transport.
[ Both SSH and TLS will provide this as long as they use sufficiently
[ appropriate ciphers.

Message prioritization and differentiation are not entirely protocol 
issues and they are addressed in RFC 3195.
[ I suggest that we drop this as a threat that we will address.

If we agree that message authenticity is not going to be in the 
critical path of the current effort in the WG, then we can conclude that 
our threats can be addressed by a REQUIRED secure transport.

   Sequenced Delivery
   Reliable Delivery
   Message Integrity
   Message Observation

== 2 ==

The discussion of a secure transport has come up before.  Most of the list 
requested that TLS be considered if we do go down that path.  The 
reasoning was that TLS is already in wide use to transport syslog messages 
and implementors would really like to continue using that.

SSH as a transport is acceptable but seems to require a higher level of 
operations support than TLS.  There are also no currently known 
implementaitons of syslog/SSH.

I'd suggest that we REQUIRE the use of TLS to address the identified 
threats.  If future implementors feel that it will be beneficial to merge 
isms, netconf and syslog, then the work that they are currently doing to 
bind their protocols to SSH will pave the way and a future effort can 
document that.

With that being said, however, it appears that Sam will allow some 
discussion of a secure transport if we can address the threats in our 
charter.  If so, then we can abstract the secure transport for the time.

I will still continue to say that syslog-sign provides mechanisms that 
will be beneficial to the community.  It will provide device 
authentication, stored-message integrity, stored-message integrity, 
and stored-message sequence verification.  These cannot be as well 
addressed with per-message signing.  Since this will require high-touch 
maintenance I will suggest that it be taken out of the critical path of 
our charter.  (We'll leave it for the end and see how many people 
contribute to it and indicate that they will implement it.)

== 3 ==

Proposed charter revision below:

--vvv--

Syslog is a de-facto standard for logging system events.  However, the
protocol component of this event logging system has not been formally
documented.  While the protocol has been very useful and scalable, it has
some known security problems which were documented in the INFORMATIONAL 
RFC 3164.

The goal of this working group is to address the security and integrity
problems, and to standardize the syslog protocol, transport, and a select
set of mechanisms in a manner that considers the ease of migration between
and the co-existence of existing versions and the standard.

Reviews have shown that there are very few similarities between the
message formats generated by heterogeneous systems.  In fact, the only
consistent commonality between messages is that all of them contain the
<PRI> at the start.  Additional testing has shown that as long as the
<PRI> is present in a syslog message, all tested receivers will accept any
generated message as a valid syslog message.  In designing a standard
syslog message format, this Working Group will retain the <PRI> at the
start of the message and will introduce protocol versioning.  Along these
same lines, many different charsets have been used in syslog messages
observed in the wild but no indication of the charset has been given in
any message.  The Working Group also feels that multiple charsets will not
be beneficial to the community; much code would be needed to distinguish
and interpret different charsets.  For compatibility with existing
implementations, the Working Group will allow that messages may still be
sent that do not indicate the charset used.  However, the Working Group
will recommend that messages contain a way to identify the charset used
for the message, and will also recommend a single default charset.

syslog has traditionally been transported over UDP and this WG has already
defined RFC 3195 for the reliable transport for the syslog messages.  The
WG will separate the UDP transport from the protocol so that others may
define additional transports in the future.

The threats that this WG will primarily address are sequenced delivery 
(including replay attacks), reliable delivery, message integrity, and 
message observation.  These attacks may be thwarted by a secure transport. 
However, it must be remembered that a great deal of the success of syslog 
has been attributed to its ease of implementation and relatively low 
maintenance level.  The Working Group will consider those factors, as well 
as current implementations, when deciding upon a secure transport.

The threat that this group will not primarily address is that of message 
authentication.  The Working Group expects that requiring key maintenence 
for syslog senders would hamper the acceptance of a new protocol. 
However, there does still remain an interest in providing message 
authentication and a mechanism to verify the integrity and sequence of 
stored messages.  The Working Group feels that these aspects may be 
addressed by a dissociated signature upon sent messages.

- A document will be produced that describes a standardized syslog
protocol.  A mechanism will also be defined in this document
that will provide a means to convey structured data.

- A document will be produced that describes a standardized UDP
transport for syslog.

- A document will be produced that requires a secure transport for the 
delivery of syslog messages.

- A document will be produced to describe the MIB for syslog entities.

- A document will be produced that describes a standardized mechanism
to sign syslog messages to provide integrity checking and source
authentication.

Milestones:

Mar 2006   Submit Syslog Protocol to IESG for consideration as a PROPOSED
             STANDARD.
Mar 2006   Submit Syslog UDP Transport Mapping to IESG for consideration
             as a PROPOSED STANDARD.
Jul 2006   Submit Syslog Device MIB to IESG for consideration as a
             PROPOSED STANDARD.
Nov 2006   Submit a document that requires a reliable transport for syslog
             to the IESG as a PROPOSED STANDARD.
Nov 2006   Submit Syslog Authentication Protocol to IESG for consideration
             as a PROPOSED STANDARD.

---^^^---

== x ==

I've given the secure transport document a deadline of November of this 
year.  It should be a simple document to write if we can quickly agree to 
the use of a transport.  However, we will need to find a document author.

Comments and thoughts would be appreciated.

Thanks,
Chris

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

---

From: Sam Hartman <[email-masked]>
Date: Tue, 10 Jan 2006 13:00:47 -0500

Hi.

Can you explain what actions on a part of an attacker are prevented in
terms of attacks on message integrity without authenticating the
source of the message?

In general, the security community is very suspicious of mechanisms
that provide integrity without authentication.  If you are going to
propose such a mechanism then you need to explain why it is
appropriate in your environment.

In effect, in terms of integrity, it sounds like you say that it is
important for a sender to know that the message has been transported
to the receiver unmodified.  However since the receiver does not know
who is sending it the message, the receiver cannot know anything about
the integrity of the message.

It may be a bit more complicated than that.  If the message contains
confidential information that an attacker could not have generated
then the receiver may actually know that the message is unmodified
without knowing who generated it.

However it seems like your proposal does not protect against a number
of attacks.  In particular, an attacker can generate messages
appearing to come from any source and containing content of the
attacker's choosing.  This combined with the ability to suppress
messages sounds like enough to get around any message integrity you
might have.

Also, I'd reword the charter bullet regarding the secure transport.
You want a bullet claiming that you will write a document describing a
secure transport.  Actually requiring the secure transport be
implemented happens in the protocol document.  As a result, you cannot
submit syslog-protocol to the IESG until this transport document is
written.  It might be possible for the protocol document not to
discuss mandatory transports at all and for there to be a later
applicability statement for syslog requiring protocol, the secure
transport and UDP.  RFC 2026 does allow that structure but I don't
know of any WG who has actually done things that way.

--Sam

---

From: Chris Lonvick <[email-masked]>
Date: Tue, 10 Jan 2006 10:32:54 -0800 (PST)

Hi Working Group,

I'll pass this along to those people who have already implemented 
syslog/TLS(SSL).  Please be specific about why you did this.

Thanks,
Chris