Chris I notice that the body of the proposal takes a neutral stance towards which secure transport but then specifies TLS in the milestones. I suggest that you keep the milestones neutral as well, not because I expect any different but because I think it more acceptable to those that will review it.
Tom Petch ----- Original Message ----- From: "Chris Lonvick" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, February 07, 2006 3:09 PM Subject: [Syslog] Coming to consensus on syslog threats > Hi, > > In reviewing the messages around the threats to the syslog protocol, it > appears that the priority of threats is as follows: > > Primary: > Modification > Disclosure > Masquerading > > Secondary: > Message stream modification > > Not highly considered: > DoS > Traffic Analysis > > > Disclosure has been controversial in the discussions. It has been noted > that syslog messages are freeform text and the possibility of sending > sensitive information will always exist. This is all the more true if > high levels of debugging are enabled. > > Also from the list, it appears that the use of TLS is supported and will > address these threats. I will ask for volunteers to write > syslog-protocol-tls and get it through the process. > > It looks like syslog-protocol and syslog-transport-udp are very close to > being finished. I'd like to wrap those up and fully concentrate on > syslog-transport-tls, syslog-sign, and syslog-device-mib. > syslog-transport-tls will have to go through the process at the same time > as syslog-protocol and syslog-transport-udp. I'll ask Rainer and Anton to > please be patient while we complete this final document. > > > With that, I'll propose the following Charter revision and Milestones. > > ---vvv--- > > 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 > > > ---^^^--- > > Thanks, > Chris > > _______________________________________________ > Syslog mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list [email protected] https://www1.ietf.org/mailman/listinfo/syslog
