Security Issues in Network Event Logging (syslog) ------------------------------------------------- Charter Last Modified: 2007-02-20 Current Status: Active Working Group Chair(s): Chris Lonvick David Harrington Security Area Director(s): Tim Polk Sam Hartman Security Area Advisor: Sam Hartman Mailing Lists: General Discussion:syslog@ietf.org To Subscribe: syslog-request@ietf.org In Body: in body: (un)subscribe Archive: http://www1.ietf.org/mail-archive/web/syslog/current/index.html 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. Goals and Milestones: Done Post as an Internet Draft the observed behavior of the Syslog protocol for consideration as an Informational Document. Done Submit Syslog protocol document to IESG for consideration as an INFORMATIONAL RFC. Done Post as an Internet Draft the specification for an authenticated Syslog for consideration as a Standards Track RFC. Done Post an Internet Draft describing enhancements to the Syslog authentication protocol to add verification of delivery and other security services. Done Submit Syslog Authentication Protocol Enhancement to 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 Done Submit Syslog UDP Transport Mapping to the IESG for consideration as a PROPOSED STANDARD Done Submit Syslog Protocol to the IESG for consideration as a PROPOSED STANDARD Done Submit Syslog TLS Transport Mapping to the IESG for consideration as a PROPOSED STANDARD Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jan 2001 Oct 2007 Signed syslog Messages Nov 2001 Feb 2008 Syslog Management Information Base Dec 2003 Sep 2007 The syslog Protocol Mar 2004 Sep 2007 Transmission of syslog messages over UDP Mar 2006 Nov 2007 TLS Transport Mapping for Syslog May 2007 Feb 2008 Textual Conventions for Syslog Management Nov 2007 Nov 2007 Reliable Delivery for syslog Request For Comments: RFC Stat Published Title ------- -- ----------- ------------------------------------ RFC3164 I Aug 2001 The BSD Syslog Protocol RFC3195 PS Nov 2001 Reliable Delivery for Syslog