Subject: [Syslog] Coming to consensus on syslog threats

From: Chris Lonvick <[email-masked]>
Date: Tue, 7 Feb 2006 06:09:32 -0800 (PST)

Hi,

In reviewing the messages around the threats to the syslog protocol, it 
appears that the priority of threats is as follows:

Primary:
    Modification
    Disclosure
    Masquerading

Secondary:
    Message stream modification

Not highly considered:
    DoS
    Traffic Analysis

Disclosure has been controversial in the discussions.  It has been noted 
that syslog messages are freeform text and the possibility of sending 
sensitive information will always exist.  This is all the more true if 
high levels of debugging are enabled.

Also from the list, it appears that the use of TLS is supported and will 
address these threats.  I will ask for volunteers to write 
syslog-protocol-tls and get it through the process.

It looks like syslog-protocol and syslog-transport-udp are very close to 
being finished.  I'd like to wrap those up and fully concentrate on 
syslog-transport-tls, syslog-sign, and syslog-device-mib. 
syslog-transport-tls will have to go through the process at the same time 
as syslog-protocol and syslog-transport-udp.  I'll ask Rainer and Anton to 
please be patient while we complete this final document.

With that, I'll propose the following Charter revision and Milestones.

---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 modification, 
disclosure, and masquerading.  A secondary threat is message stream 
modification.  Threats that will not be addressed by this WG are DoS and 
traffic analysis.  The primary 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 secondary threat of message stream modification can be 
addressed by a mechanism that will verify the end-to-end integrity and 
sequence of 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:

Nov 2006   Submit Syslog Protocol to the IESG for consideration as a
              PROPOSED STANDARD.
Nov 2006   Submit Syslog UDP Transport Mapping to the IESG for
              consideration as a PROPOSED STANDARD.
Nov 2006   Submit Syslog TLS Transport Mapping to the IESG for
              consideration as a PROPOSED STANDARD.
Nov 2006   Submit Syslog Device MIB to IESG for consideration as a
              PROPOSED STANDARD.
Nov 2006   Submit a document that defines a message signing and
              ordering mechanism to the IESG for consideration as a
              PROPOSED STANDARD

---^^^---

Thanks,
Chris

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

---

From: Miao Fuyou <[email-masked]>
Date: Wed, 08 Feb 2006 17:20:40 +0800

I and Yuzhi would like to edit a draft on syslog tls transport. We will get
the draft  posted ASAP.

Miao
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Chris Lonvick
Sent: Tuesday, February 07, 2006 10:10 PM
To: [email-masked]
Subject: [Syslog] Coming to consensus on syslog threats

Hi,

Primary:
    Modification
    Disclosure
    Masquerading

Secondary:

Not highly considered:
    DoS
    Traffic Analysis

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

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.

- 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 describes a standardized mechanism to
sign syslog messages to provide integrity checking and source
authentication.

Milestones:

---^^^---

Thanks,
Chris

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

---

From: "Tom Petch" <[email-masked]>
Date: Thu, 9 Feb 2006 13:21:32 +0100

Chris

I notice that the body of the proposal takes a neutral stance towards which
secure transport but then specifies TLS in the milestones.  I suggest that you
keep the milestones neutral as well, not because I expect any different but
because I think it more acceptable to those that will review it.

Tom Petch

---

From: Balazs Scheidler <[email-masked]>
Date: Thu, 09 Feb 2006 18:44:20 +0100

> appears that the priority of threats is as follows:

Cool. :)

-- 
Bazsi

---

From: Chris Lonvick <[email-masked]>
Date: Sat, 11 Feb 2006 13:13:32 -0800 (PST)

Hi Miao and Yuzhi,

As Tom Petch pointed out we do need to establish that a TLS transport will 
address the threats we have described.  Would you briefly outline how you 
propose to utilize TLS to address Modification, Disclosure, Masquerading? 
(Others can jump in here with more comments and concerns so the document 
can get a good start.)  Once we establish that I believe we can accept 
your offer to write the document.

Many thanks,
Chris

---

From: Chris Lonvick <[email-masked]>
Date: Sat, 11 Feb 2006 13:11:55 -0800 (PST)

Hi Tom,

You are correct.

I'll change that to:

Nov 2006   Submit a secure syslog transport mapping document to the
               IESG for consideration as a PROPOSED STANDARD.

Thanks,
Chris

---

From: Miao Fuyou <[email-masked]>
Date: Fri, 17 Feb 2006 11:05:14 +0800

Hi Chris,

---------------------OUTLINE----------------------------------

1, Problem statement
In reviewing the messages around the threats to the syslog protocol, it
appears that the priority of threats is as follows:
Primary:
    Modification
    Disclosure
    Masquerading
Secondary:
    Message stream modification
Not highly considered:
    DoS
    Traffic Analysis
Disclosure has been controversial in the discussions.  It has been noted
that syslog messages are freeform text and the possibility of sending
sensitive information will always exist.  This is all the more true if  high
levels of debugging are enabled. 
Note: This section will summary the security threats to SYSLOG discussed on
mailing list.

2, Introduction to TLS
2.1 How TLS works
TLS establishes a private end-to-end connection, optionally including strong
mutual authentication, using a variety of cryptosystems. Initially, a
handshake phase uses three subprotocols to set up a record layer,
authenticate endpoints, set parameters, as well as report errors. Then,
there is an ongoing layered record protocol that handles encryption,
compression, and reassembly for the remainder of the connection. Application
data protocol, such as SYSLOG, works as a client of record protocol.

2.2 Security Property
TLS security properties: Integrity verification (by Hash MAC with MD5 and
SHA1), Data origin authentication (by Certificate/signature along with hash
MAC), Confidentiality/Privacy (by encryption/decryption with DES, AES, RC2
etc), Anti-replay (by sequence number with integrity verification).

3, TLS to mitigate SYSLOG security threats
Integrity verification to counter modification
Data origin authentication to counter masquerading
Confidentiality/Privacy to counter disclosure
Anti-replay to counter message stream modification
	
4, Framework
4.1 Roles
SYSLOG sender works as TLS client and receiver as TLS server.
Note: It is possible to reverse the role, i.e. sender is TLS server. But it
looks odd and there is no obvious benefit observed right now.
Syslog relay can be either TLS client or server.

4.2 Protocol Port
A port number should be allocated.

5, Protocol Elements
5.1 Initiation
The Sender should initiate a connection to the Receiver on the appropriate
port and then send the TLS ClientHello to begin the TLS handshake. When the
TLS handshake has finished the Sender may then initiate the first SYSLOG
message. 
Note: We need to define how syslog interpret the authentication certificates
exchanged by handshake protocol.
Note: We need to discuss what authentication we need: client authenticated
to server, server authenticated to client, or both (mutual authentication)

5.2 Sending data
All SYSLOG message MUST be sent as TLS "application data".
We need to discuss:
5.2.1, Multiple SYSLOG messages in one TLS message or one SYSLOG message in
one TLS message? How to parse TLS message into several SYSLOG messages in
the multiplexing mode? 

5.2.2, Does SYSLOG message truncation will affect the transport? 

5.3 Closure
Sender MUST send a closure alert before closing the connection. Sender which
are unprepared to receive any more data MAY choose not to wait for the
Receiver 's closure alert and simply close the connection, thus generating
an incomplete close on the Receiver side. Receiver MUST attempt to initiate
an exchange of closure alerts with the Sender before closing the connection.
Receiver MAY close the connection after sending the closure alert, thus
generating an incomplete close on the Sender side.

5.4 Relay
5.4.1 It seems expensive to a SYSLOG Relay to become TLS client or server.
Is it possible to relay SYSLOG message without TLS processing? 
5.4.2 There are hostname or IP in SYSLOG message header. A implementation
should not check the hostname/IP against TLS certificate because of relay.

6 Security Consideration
6.1 Coexist of TLS and SYSLOG-SIGN
TLS and SYSLOG-SIGN address quite different security requirements. Data
origin authentication of TLS checks whether the data is received from the
SENDER (device or relay), but the SYSLOG-SIGN check whether the data
originates from a specific DEVICE.
The syslog-sign certificate and tls client certificate are not exchangeable
because a sender may be a relay. Another reason is sender may have several
certificates for different purpose.
6.2 Mutual Authentication? 

-----Original Message-----
From: Chris Lonvick [mailto:[email-masked]] 
Sent: Sunday, February 12, 2006 5:14 AM
To: Miao Fuyou
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Syslog] Coming to consensus on syslog threats

Hi Miao and Yuzhi,

Many thanks,
Chris

On Wed, 8 Feb 2006, Miao Fuyou wrote:

>
> I and Yuzhi would like to edit a draft on syslog tls transport. We 
> will get the draft  posted ASAP.
>
> Miao
> [email-masked]
>
> In reviewing the messages around the threats to the syslog protocol, 
> it appears that the priority of threats is as follows:
>
> Primary:
>    Modification
>    Disclosure
>    Masquerading
>
> Secondary:
> Disclosure has been controversial in the discussions.  It has been 
> noted that syslog messages are freeform text and the possibility of 
> sending sensitive information will always exist.  This is all the more 
> true if high levels of debugging are enabled.
>
> Also from the list, it appears that the use of TLS is supported and 
> will address these threats.  I will ask for volunteers to write 
> It looks like syslog-protocol and syslog-transport-udp are very close 
> to being finished.  I'd like to wrap those up and fully concentrate on 
> syslog-transport-tls will have to go through the process at the same 
> time as syslog-protocol and syslog-transport-udp.  I'll ask Rainer and 
> Anton to please be patient while we complete this final document.
>
>
> 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.
>
> 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.
>
> modification.  Threats that will not be addressed by this WG are DoS 
> and traffic analysis.  The primary attacks may be thwarted by a secure 
> 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 secondary threat of message stream 
> modification can be addressed by a mechanism that will verify the 
> end-to-end integrity and sequence of messages.  The Working Group 
> feels that these aspects may be addressed by a dissociated signature 
> upon sent messages.
>
>
>
> protocol. A mechanism will also be defined in this document that will 
> provide a means to convey structured data.
>

---

From: Chris Lonvick <[email-masked]>
Date: Mon, 20 Feb 2006 05:56:00 -0800 (PST)

Hi All,

I am willing to accept this as a WG document.  There are some items that 
Miao has noted below.  Let's get some discussion going now so Miao and 
Yuzhi can deliver a clean -00 ID.

We're not going to have this ID available for the Dallas IETF meeting.  As 
such, I'm not planning on calling a meeting there.  Please let me know if 
you think otherwise.

Some comments in-line.

> Note: This section will summary the security threats to SYSLOG discussed on

This needs to include the definitions of "sender", "reviever", etc. as 
they are defined in Section 3 of syslog-protocol-16.  The TLS devices of 
"client" and "server" should be defined in the next section, or in Section 
4, or perhaps in the "Conventions Used in this Document" section.  I 
suspect that the syslog message "sender" will always be the TLC "client". 
Anyone disagree with that?

> Syslog relay can be either TLS client or server.

A relay will be both TLS client and server.

> to server, server authenticated to client, or both (mutual authentication)

This needs to be discussed by the Working Group.  All:  Please comment.

> one TLS message? How to parse TLS message into several SYSLOG messages in

I'll open a separate thread about this.

> Is it possible to relay SYSLOG message without TLS processing?

No; the relay will need to view the <PRI> or other information in the 
message to decide if it needs to be relayed, and if so to where.

> should not check the hostname/IP against TLS certificate because of relay.

This falls under the threat of message stream modification.  A brief note 
about this in the Security Considerations section should take care of 
this.  It will be fully addressed in syslog-sign.

> originates from a specific DEVICE.

Do not reference syslog-sign in this document.  We do not want to create 
any additional dependencies.  This document, syslog-protocol and 
syslog-transport-udp will go to the IESG together.  syslog-sign can come 
after these.

> 6.2 Mutual Authentication?

Let's see what the WG has to say about this.

Thanks,
Chris