2.7.16 Security Issues in Network Event Logging (syslog)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.
In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       Additional SYSLOG Page

Last Modified: 2005-10-10

Chair(s):

Chris Lonvick <clonvick@cisco.com>

Security Area Director(s):

Russ Housley <housley@vigilsec.com>
Sam Hartman <hartmans-ietf@mit.edu>

Security Area Advisor:

Sam Hartman <hartmans-ietf@mit.edu>

Mailing Lists:

General Discussion: syslog@ietf.org
To Subscribe: syslog-request@ietf.org
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 but undocumented security problems. For instance, the
messages are unauthenticated and there is no mechanism to provide
verified delivery and message integrity.

The goal of this working group is to document and address the security
and integrity problems of the existing Syslog mechanism. In order to
accomplish this task we will document the existing protocol. The
working
group will also explore and develop a standard to address the security
problems.

Beyond documenting the Syslog protocol and its problems, the working
group will work on ways to secure the Syslog protocol. At a minimum
this group will address providing authenticity, integrity and
confidentiality of Syslog messages as they traverse the network. The
belief being that we can provide mechanisms that can be utilized in
existing programs with few modifications to the protocol while
providing significant security enhancements.

Goals and Milestones:

Done  Post as an Internet Draft the observed behavior of the Syslog protocol for consideration as an Informational Document.
Done  Submit Syslog protocol document to IESG for consideration as an INFORMATIONAL RFC.
Done  Post as an Internet Draft the specification for an authenticated Syslog for consideration as a Standards Track RFC.
Done  Post an Internet Draft describing enhancements to the Syslog authentication protocol to add verification of delivery and other security services.
Done  Submit Syslog Authentication Protocol Enhancement to IESG for consideration as a PROPOSED STANDARD.
Oct 2004  Submit Syslog Internationalization to IESG for consideration as a PROPOSED STANDARD.
Mar 2005  Submit Syslog Protocol to IESG for consideration as a PROPOSEDSTANDARD
Mar 2005  Submit Syslog Transport Mapping to IESG for consideration as a PROPOSED STANDARD.
Jun 2005  Submit Syslog Device MIB to IESG for consideration as a PROPOSED STANDARD
Jul 2005  Submit Syslog Authentication Protocol to IESG for consideration as a PROPOSED STANDARD.
Apr 2006  Revise drafts as necessary to advance these Internet-Drafts to Standards Track RFCs.

Internet-Drafts:

  • draft-ietf-syslog-sign-16.txt
  • draft-ietf-syslog-protocol-15.txt
  • draft-ietf-syslog-transport-udp-06.txt

    Request For Comments:

    RFCStatusTitle
    RFC3164 I The BSD Syslog Protocol
    RFC3195 PS Reliable Delivery for Syslog

    Current Meeting Report

     
    Syslog meeting notes
-------------------

Chris went over various outstanding issues/updates
 - use of unicode (see presented slide)
 - SD-IDs (see presented slide)
 - Will it be implemented? -- Angle brackets w/PRI inside or new header...
     * Sharon Chisholm - concerned about doing a complete re-do of syslog which
       may change in the near future. Too many changes may be dangerous
       since it may go on for a while.
     * Proposal is to update the draft to put back angle brackets around PRI - no one objected
     * Put updated timestamp
     * Steve Chang - he feels that keeping the angle brackets will help speed up 
       implementations. It also helps as a delimiter for multiple syslog packets/messages
     * Sam - these changes are significant and they should not be made now. The document
       should be withdrawn from last call, updated, and re-submitted if the changes need
       to be made - agreed
     * Richard G. - looking at multiple dimensions (better use of field, security, 
       will it be implemented). Seems the WG is defining a new protocol. Want to be able
       to separate the issues. Want to use syslog in a management framework for another
       standard outside the IETF but needed security. 
     * Proposal - separate various issues into multiple docs. 
       Question to mailing list: should a new doc be generated to include angle bracket,
       new time stamp, and SD-ID
     * Darrin - should have a syslog receiver compliance doc (accept old format - 3164 and
       over time accept new one). Capture evolution of protocol/implementations. The protocol
       doc does not appear to be good enough for capturing this. 
     * Steve - Truncate indicator seems to be necessary. Chris - perhaps move it from the
       header to the SD-ID
     * Sam - WG is behind on many milestones. Various concerns about decisions the WG is
       making at this late stage. CHris - the WG will establish new milestones


 Alex Clemm - update on signed syslog (syslog-sign)
       Brief re-cap of what the current draft specifies
       
       sylsog/BEEP - anyone implemented it? Cisco 
       SSH and TLS - should do this in conjunction w/other WGs (NETCONF, ISMS)
       Split decision on use of SSH & TLS - take it to the mailing list

    Slides

    syslog-protocol review