[802SEC] FW: [New-work] WG Review: Recharter of Security Issues in Network Event Logging (syslog)

["Congdon, Paul T (ProCurve)" <paul.congdon@HP.COM>]

IEEE 802 WG Chairs,

The following new work announcement from the IETF may be of interest to
your working group members.

Paul 

-----Original Message-----
From: IESG Secretary [mailto:iesg-secretary@ietf.org] 
Sent: Thursday, March 09, 2006 3:53 PM
To: new-work@ietf.org
Subject: [New-work] WG Review: Recharter of Security Issues in Network
Event Logging (syslog) 

A modified charter has been submitted for the Security Issues in Network
Event Logging (syslog)working group in the Security Area of the IETF.  
The IESG has not made any determination as yet. The modified charter is
provided below for informational purposes only. Please send your
comments to the IESG mailing list (iesg@ietf.org) by March 15th.

The IESG solicits feedback from those considering implementing or
deploying syslog on the following charter. In particular, the concern
has been raised that insufficient vendors will implement a new syslog
protocol and insufficient operators will deploy it. The IESG requests
those who support this effort to explicitly indicate their support.
If significant community support is not indicated, this work will not be
chartered.

+++

Security Issues in Network Event Logging (syslog)
====================================

Current Status: Active Working Group

Chair(s):
Chris Lonvick <clonvick@cisco.com>

Security Area Director(s):
Russ Housley <housley@vigilsec.com>
Sam Hartman <hartmans-ietf@mit.edu>

Security Area Advisor:
Sam Hartman <hartmans-ietf@mit.edu>

Mailing Lists:

General Discussion: syslog@ietf.org
To Subscribe: syslog-request@ietf.org
In Body: in body: (un)subscribe
Archive: ftp://ftp.ietf.org/ietf-mail-archive/syslog/

Description of Working Group:

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






_______________________________________________
New-work mailing list
New-work@ietf.org
https://www1.ietf.org/mailman/listinfo/new-work

----------
This email is sent from the 802 Executive Committee email reflector.  This list is maintained by Listserv.