At Huawei, we plan to develop a prototype of syslog/TLS. David Harrington [EMAIL PROTECTED]
> -----Original Message----- > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > Sent: Friday, March 10, 2006 1:59 AM > To: [email protected] > Cc: [EMAIL PROTECTED] > Subject: FW: [Syslog] WG Review: Recharter of Security Issues > in Network EventLogging (syslog) > > IESG: > > we (Adiscon) will implement the upcoming new drafts in our softwares > WinSyslog, EventReporter, Monitorware Agent and rsyslog (already has a > proof-of-concept implementation of -protocol and -transport-tls). > > Best regards, > Rainer Gerhards > Adiscon > > > -----Original Message----- > > From: IESG Secretary [mailto:[EMAIL PROTECTED] > > Sent: Friday, March 10, 2006 12:58 AM > > 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 > _______________________________________________ Syslog mailing list [email protected] https://www1.ietf.org/mailman/listinfo/syslog
