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


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

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


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 protected] https://www1.ietf.org/mailman/listinfo/syslog


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

Reply via email to