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

rgerhards@private

Anton,

actually, the question you raise is the same one that the IESG raised ;)
They are looking if somebody is really interested. So far, I know that
Huawai and we (Adiscon) are definitely interested. Based on mailing list
participation I strongly think that Cisco has some vital interest and it
also looks like Balabit (syslog-ng) and Kiwi (popular Windows syslog
implementation) is interested. Other than that, I do not know anything.

I hope this clarifies.

Rainer 

> -----Original Message-----
> From: anton.chuvakin@private 
> [mailto:anton.chuvakin@private] On Behalf Of Anton Chuvakin
> Sent: Friday, March 10, 2006 9:17 PM
> To: Rainer Gerhards
> Cc: loganalysis@private
> Subject: Re: [logs] FW: [Syslog] WG Review: Recharter of 
> Security Issues in Network Event Logging (syslog)
> 
> Whenever I see stuff like this I always think: how's the adoption
> doing? Is anybody important implementing it in the real world? Or is
> it just another IDMEF, which, BTW, just died [WG got disbanded]...
> 
> On 3/10/06, Rainer Gerhards <rgerhards@private> wrote:
> > Hi all,
> >
> > I am forwarding a syslog-related message from the IETF to 
> this group. I
> > am doing so because I assume there is some interest in the 
> evolution of
> > syslog. Please note that you can comment to the IESG (IETF) 
> if you have
> > an opinion on the topic. For details, please see below.
> >
> > Best regards,
> > Rainer
> >
> > > -----Original Message-----
> > > From: IESG Secretary [mailto:iesg-secretary@private]
> > > Sent: Friday, March 10, 2006 12:58 AM
> > > To: IETF Announcement list
> > > Cc: syslog@private
> > > 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 (iesg@private) 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 <clonvick@private>
> > >
> > > Security Area Director(s):
> > > Russ Housley <housley@private>
> > > Sam Hartman <hartmans-ietf@private>
> > >
> > > Security Area Advisor:
> > > Sam Hartman <hartmans-ietf@private>
> > >
> > > Mailing Lists:
> > >
> > > General Discussion: syslog@private
> > > To Subscribe: syslog-request@private
> > > 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
> > > Syslog@private
> > > https://www1.ietf.org/mailman/listinfo/syslog
> > >
> > _______________________________________________
> > LogAnalysis mailing list
> > LogAnalysis@private
> > http://lists.shmoo.com/mailman/listinfo/loganalysis
> >
> 
> 
> --
> Anton Chuvakin, Ph.D., GCIA, GCIH, GCFA
>      http://www.chuvakin.org
> http://www.securitywarrior.com
> 
_______________________________________________
LogAnalysis mailing list
LogAnalysis@private
http://lists.shmoo.com/mailman/listinfo/loganalysis