Subject: FW: [Syslog] WG Review: Recharter of Security Issues in Network Event Logging (syslog)

From: "Rainer Gerhards" <[email-masked]>
Date: Fri, 10 Mar 2006 07:58:44 +0100

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-masked]] 
> Sent: Friday, March 10, 2006 12:58 AM
> To: IETF Announcement list
> Cc: [email-masked]
> 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-masked]) 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-masked]>
> 
> Security Area Director(s):
> Russ Housley <[email-masked]>
> Sam Hartman <[email-masked]>
> 
> Security Area Advisor:
> Sam Hartman <[email-masked]>
> 
> Mailing Lists:
> 
> General Discussion: [email-masked]
> To Subscribe: [email-masked]
> 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-masked]
> https://www1.ietf.org/mailman/listinfo/syslog
> 

_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog

---

From: "David B Harrington" <[email-masked]>
Date: Fri, 10 Mar 2006 02:57:56 -0500

At Huawei, we plan to develop a prototype of syslog/TLS. 

David Harrington
[email-masked]

> From: Rainer Gerhards [mailto:[email-masked]] 
> Sent: Friday, March 10, 2006 1:59 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: FW: [Syslog] WG Review: Recharter of Security Issues 
> in Network EventLogging (syslog) 
> 
> IESG:
>