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

anton@private

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