2.6.12 Security Issues in Network Event Logging (syslog)

In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       http://www.employees.org/~lonvick/index.shtml -- Additional SYSLOG Page
NOTE: This charter is a snapshot of the 59th IETF Meeting in Seoul, Korea. It may now be out-of-date.

Last Modified: 2004-01-22

Chris Lonvick <clonvick@cisco.com>
Security Area Director(s):
Russell Housley <housley@vigilsec.com>
Steven Bellovin <smb@research.att.com>
Security Area Advisor:
Steven Bellovin <smb@research.att.com>
Mailing Lists:
General Discussion: syslog-sec@employees.org
To Subscribe: majordomo@employees.org
In Body: subscribe syslog-sec your_email_address
Archive: http://www.mail-archive.com/syslog-sec@employees.org/
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.
Jun 03  Submit Syslog Authentication Protocol to IESG for consideration as a PROPOSED STANDARD.
Jun 03  Submit Syslog Device MIB to IESG for consideration as a PROPOSED STANDARD
Sep 03  Revise drafts as necessary to advance these Internet-Drafts to Standards Track RFCs.
  • - draft-ietf-syslog-sign-13.txt
  • - draft-ietf-syslog-device-mib-05.txt
  • - draft-ietf-syslog-international-00.txt
  • - draft-ietf-syslog-protocol-03.txt
  • Request For Comments:
    RFC3164 I The BSD Syslog Protocol
    RFC3195 PS Reliable Delivery for Syslog

    Current Meeting Report

    Security Issues in Network Event Logging WG (syslog WG; Sec Area)
    Chair: Chris Lonvick <clonvick@cisco.com>
    Scribe: Richard Graveman, RFG Security
    The maillist is at syslog-sec@employees.org.
    Additional information is available at
    Issue tracking is in use.
    I.    Review of Scope and Charter (Chris)                        10 min.
    There were no changes to the agenda. The agenda and on-line 
    information were reviewed. The work is to secure the transport of logs. 
    Content is out of scope. They produced RFCs 3164 and 3195. Protocol, UDP 
    transport, sign, device MIB, and Internationalization drafts are in 
    II.   Update of "syslog Protocol" ID (Chris - Rainer unavailable) 30 min.
    The three layers are application, protocol, and transport. 3164 is the two 
    lower layers. 3195 touches the application. Sign and International are 
    mostly the two higher layers. A new concept for aligning documents within 
    these layers was proposed, which leads to six documents instead of four. UDP 
    and 3195; protocol, and then international and sign, etc. at the 
    application layer.
    Protocol describes devices, relays, collectors, protocol layers, simplex 
    communications, common header, structured data, classical free-form 
    messages, and security considerations.
    There is no two-way communications, except for RFC 3195 which is over TCP. 
    End-to-end (duplex) would be an entirely different protocol.
    Transport layer mapping: UDP being written; others, including TCP, later. 
    The protocol ID is not completely backward compatible. 
    Non-compliant messages will be treated as messages without a header. WG 
    consensus that a solid base is more important than backwards 
    compatibility. The new HEADER has more fields, including a version 
    number. TIMESTAMP is better defined. John Kelsey introduced 
    structured data elements. Used for extended functionality. Assigned by 
    IANA. Extensible. The ID s defined are msgpart, time, and origin, with more 
    to come. Time zones were debated. IP addresses are preferable to 
    Multi-part messaging: 1280 is the maximum message size. A message 
    segmentation scheme exists. Downstream message splitting is proposed.
    Semantics questions were on facility (issue 5) and TAG (issue 16).
    Issue 13 states that syslog-protocol currently dictates many details. 
    There is a tradeoff between ambiguity and security. The notes could be 
    moved to an Informational RFC. There was no objection to this.
    Relay operations may be described in the -protocol document or 
    described briefly with the rest deferred. It will be left for now.
    Message size was discussed: current maximum is 1280. Removing this 
    restriction was proposed. It could become a transport issue.
    Comments and feedback are solicited.
    III.  Introduction of "syslog Transport" ID (Chris - Anton 
    unavailable) 15 min.
    This is a standards track ID to replace 3164. It defines UDP over port 514 as 
    MUST. One datagram per syslog message. One datagram per msg part for 
    multi-part. UDP checksums RECOMMENDED. IP fragmentation SHOULD be 
    avoided. Recommends 548 bytes maximum message size to avoid 
    fragmentation. (S. Bellovin drew a comparison with the DNS message size 
    limit of 512.
    Reliability is a separate section: lost, corrupted, congestion control, 
    un-sequenced delivery, and increased risk of loss with IP 
    fragmentation. Many sec considerations: authenticity, 
    authentication, forgery, eavesdropping, replay, unreliability, no 
    prioritization, DoS, and covert channels.
    There was no objection to this approach, which simplifies the 
    syslog-protocol document.
    IV.   Update of "syslog-sign" ID (Chris - Jon unavailable)      15 min.
    Slightly on hold while the protocol issues are resolved. Parts can be 
    removed based on the above protocol and transport. IANA 
    considerations need to be done.
    The current document is transport independent. It can be used with 
    classic syslog or home-grown applications. No objection to this.
    V.    Update of "syslog-device-mib" ID (Glenn Mansfield Keeni)  30 min.
    This started with modest ambitions and became more complicated. After more 
    reflection, the current -05 draft emerged. The name "device" is 
    Purpose is to monitor syslog operation: message stats, received, 
    processed, relayed. Security considerations need to address READONLY 
    threats and other threats.
    The following issues are resolved:
    Issue 1: Written, and feedback is requested.
    Issue 2: Make the MIB generic (now BSD centric)
    Issue 3: Do not overlap with HR-MIB. provide mapping to 
    hrSWRunTable. Remove syslogParamsProcessStatus (or make it readOnly), add 
    syslogProcReference. The syslogProcReference OBJECT-TYPE was shown.
    Issue 4: Add SNMP notification. The MIB will not address syslog over SNMP.
    Issue 5: Add "no DNS lookup"
    Issue 6: Use the MIB to control and configure syslog. The suggestion was to 
    do this with ScriptMIB. The syslog.conf semantics are not part of this, but a 
    script can be transferred to a host, which can deal with 
    syslog.conf. Much complexity
    The next draft is scheduled for April: DESCRIPTION clauses, REFERENCE 
    clauses, editorial items.
    VI.   Wrap-up and review of decisions made (Chris)              10 min.
    There were no additional items. There was no objection to the plan to 
    proceed as described in the discussion items.
    Meeting adjourned at 16:34.


    Layered Syslog Architecture