FWD: WG Review: Recharter of Security Issues in Network Event Logging (syslog)

["Fergie" <fergdawg () netzero net>]

Blogger is having problems, and I'm bored. :-)

No --really, Chris Lonvick is an old friend and colleague of
mine -- we used to work together in the same group at Cisco.
Great guy, trying to make a difference. (He also lives here
in Austin, TX.)

Having said that, Chris is the chair of the 're-birth' of a working
group in the IETF tasked to take a look at how to make syslog
better, more robust, more secure, etc.

If you're interested in these types of things, and wouldn't
mind providing some comments/input on a mailing list, consider
taking a look a the (re)charter of the IETF working group [below]
and perhaps if you are interested enough, provide some input.

FYI,

- ferg

p.s. Sorry abou any formatting issues -- it is forward 'as is'. :-)


-- IESG Secretary <iesg-secretary () ietf org> wrote:

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







_______________________________________________
IETF-Announce mailing list
IETF-Announce () ietf org
https://www1.ietf.org/mailman/listinfo/ietf-announce


--
"Fergie", a.k.a. Paul Ferguson
 Engineering Architecture for the Internet
 fergdawg () netzero net or fergdawg () sbcglobal net
 ferg's tech blog: http://fergdawg.blogspot.com/


_______________________________________________
Fun and Misc security discussion for OT posts.
https://linuxbox.org/cgi-bin/mailman/listinfo/funsec
Note: funsec is a public and open mailing list.