Charter

Security Issues in Network
Event Logging (Syslog)

Last Modified: 2006-03-21

Chair(s):

Chris Lonvick <clonvick@cisco.com>

Security Area Director(s):

Tim Polk <tim.polk@nist.gov>
Pasi Eronen <pasi.eronen@nokia.com>

Security Area Advisor:

Pasi Eronen <pasi.eronen@nokia.com>

Mailing Lists:


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 at the start. Additional testing has shown that as long as the 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 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.



IETF 64

We met at the 64th IETF in Vancouver, BC, Canada.

Our notes are here. It has pointers to presentations and minutes.


IETF 59

We met at the 59th IETF in Seoul, South Korea.

Our notes are here. It has pointers to presentations and minutes.


IETF 56

We met at the 56th IETF.

Our submitted information is here. Glenn Mansfield Keeni presented the Syslog MIB work. Marshall Rose took the minutes. Locally, my presentation is here and Glenn's is here.


IETF 55

We met at the 55th IETF. Our notes are here.


IETF 49

We met at the 49th IETF. The WG minutes are here. The presentations are also locally here:


Liaison Letters

The syslog WG has received a Liaison Letter from the Optical Internetworking Forum. The cover letter requests review and comments from this Working Group.

The syslog WG has received another Liaison Letter from the Optical Internetworking Forum.

Current Work

This is the last piece of our charter. This document has passed WG Last Call and has been submitted to the IESG with recommendations to publish it as a standards-track RFC. We have some feedback from our Advisor and it has not gone before the IESG for full review. Please watch the mailing list for discussion of this ID.

        Title           : Signed syslog Messages
        Author(s)       : J. Kelsey, et al.
        Filename        : draft-ietf-syslog-sign-25.txt
        Pages           : 44
        Date            : 2009-03-30

This document describes a mechanism to add origin authentication,
message integrity, replay resistance, message sequencing, and
detection of missing messages to the transmitted syslog messages.
This specification is intended to be used in conjunction with the
work defined in [RFC5424], "The syslog Protocol".

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-25.txt


Completed Work

RFC 5424

        RFC 5424

        Title:      The Syslog Protocol 
        Author:     R. Gerhards
        Status:     Standards Track
        Date:       March 2009
        Mailbox:    rgerhards@adiscon.com
        Pages:      38
        Characters: 85162
        Obsoletes:  RFC3164

        I-D Tag:    draft-ietf-syslog-protocol-23.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5424.txt

This document describes the syslog protocol, which is used to convey
event notification messages.  This protocol utilizes a layered
architecture, which allows the use of any number of transport
protocols for transmission of syslog messages.  It also provides a
message format that allows vendor-specific extensions to be provided
in a structured way.

This document has been written with the original design goals for
traditional syslog in mind.  The need for a new layered specification
has arisen because standardization efforts for reliable and secure
syslog extensions suffer from the lack of a Standards-Track and
transport-independent RFC.  Without this document, each other
standard needs to define its own syslog packet format and transport
mechanism, which over time will introduce subtle compatibility
issues.  This document tries to provide a foundation that syslog
extensions can build on.  This layered architecture approach also
provides a solid basis that allows code to be written once for each
syslog feature rather than once for each transport.  [STANDARDS TRACK]


RFC 5425

        RFC 5425

        Title:      Transport Layer Security (TLS) Transport 
                    Mapping for Syslog 
        Author:     F. Miao, Ed.,
                    Y. Ma, Ed.,
                    J. Salowey, Ed.
        Status:     Standards Track
        Date:       March 2009
        Mailbox:    miaofy@huawei.com, 
                    myz@huawei.com, 
                    jsalowey@cisco.com
        Pages:      13
        Characters: 28159
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-syslog-transport-tls-14.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5425.txt

This document describes the use of Transport Layer Security (TLS) to
provide a secure connection for the transport of syslog messages.
This document describes the security threats to syslog and how TLS
can be used to counter such threats.  [STANDARDS TRACK]


RFC 5426

        RFC 5426

        Title:      Transmission of Syslog Messages over 
                    UDP 
        Author:     A. Okmianski
        Status:     Standards Track
        Date:       March 2009
        Mailbox:    aokmians@cisco.com
        Pages:      9
        Characters: 19354
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-syslog-transport-udp-12.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5426.txt

This document describes the transport for syslog messages over UDP/
IPv4 or UDP/IPv6.  The syslog protocol layered architecture provides
for support of any number of transport mappings.  However, for
interoperability purposes, syslog protocol implementers are required
to support this transport mapping.  [STANDARDS TRACK]


RFC 5427

        RFC 5427

        Title:      Textual Conventions for Syslog Management 
        Author:     G. Keeni
        Status:     Standards Track
        Date:       March 2009
        Mailbox:    glenn@cysols.com
        Pages:      8
        Characters: 17829
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-syslog-tc-mib-08.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5427.txt

This MIB module defines textual conventions to represent
Facility and Severity information commonly used in syslog messages.
The intent is that these textual conventions will be imported and
used in MIB modules that would otherwise define their own
representations.  [STANDARDS TRACK]


RFC 3195


      RFC 3195

        Title:	    Reliable Delivery for syslog
        Author(s):  D. New, M. Rose
        Status:     Standards Track
	Date:       November 2001
        Mailbox:    dnew@san.rr.com, mrose@dbc.mtview.ca.us
        Pages:      30
        Characters: 60960
        Updates/Obsoletes/SeeAlso:  None

        I-D Tag:    draft-ietf-syslog-reliable-12.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3195.txt


The BSD Syslog Protocol describes a number of service options related
to propagating event messages.  This memo describes two mappings of
the syslog protocol to TCP connections, both useful for reliable
delivery of event messages.  The first provides a trivial mapping
maximizing backward compatibility.  The second provides a more
complete mapping.  Both provide a degree of robustness and security
in message delivery that is unavailable to the usual UDP-based syslog
protocol, by providing encryption and authentication over a
connection-oriented protocol.

This document will be revised after we finalize syslog-protocol


RFC 3164 - Obsoleted by RFC 5424


        RFC 3164

        Title:	    The BSD syslog Protocol
        Author(s):  C. Lonvick
        Status:     Informational
	Date:       August 2001
        Mailbox:    clonvick@cisco.com
        Pages:      29
        Characters: 72951
        Updates/Obsoletes/SeeAlso:  None

        I-D Tag:    draft-ietf-syslog-syslog-12.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3164.txt

This document describes the observed behavior of the syslog
protocol.  This protocol has been used for the transmission of
event notification messages across networks for many years.  While
this protocol was originally developed on the University of
California Berkeley Software Distribution (BSD) TCP/IP system
implementations, its value to operations and management has led
it to be ported to many other operating systems as well as being
embedded into many other networked devices.

This document is a product of the Security Issues in Network Event
Logging Working Group of the IETF.

This memo provides information for the Internet community.  It does
not specify an Internet standard of any kind.  Distribution of this
memo is unlimited.





Owned by Chris Lonvick (clonvick@cisco.com)
Last modified on 2009-Apr-20