To second others... We would like to see this work be completed and plan on being active participants in the WG to help it accomplish this goal. I would like to see my company implement this, but can't comment on any specific product road maps.
Syslog has been a very popular protocol. It is long overdue to graduate it into a real standard from the current loosely defined informational RFC. This charter will accomplish this, as well as provide a robust standard security mechanism for syslog. Thanks, Anton. > -----Original Message----- > From: IESG Secretary [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 09, 2006 6:58 PM > To: IETF Announcement list > Cc: [EMAIL PROTECTED] > Subject: [Syslog] 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 > ([email protected]) 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 <[EMAIL PROTECTED]> > > Security Area Director(s): > Russ Housley <[EMAIL PROTECTED]> > Sam Hartman <[EMAIL PROTECTED]> > > Security Area Advisor: > Sam Hartman <[EMAIL PROTECTED]> > > Mailing Lists: > > General Discussion: [EMAIL PROTECTED] > To Subscribe: [EMAIL PROTECTED] > 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 > > > > > > > > _______________________________________________ > Syslog mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/syslog >
_______________________________________________ Syslog mailing list [email protected] https://www1.ietf.org/mailman/listinfo/syslog
