Last Modified: 2004-01-22
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.
| 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. |
| RFC | Status | Title |
|---|---|---|
| RFC3164 | I | The BSD Syslog Protocol |
| RFC3195 | PS | Reliable Delivery for Syslog |
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 http://www.employees.org/~lonvick/Seoul_agenda/agenda.html. 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 progress. II. Update of "syslog Protocol" ID (Chris - Rainer unavailable) 30 min. draft-ietf-syslog-protocol-03.txt 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 hostnames. 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. See http://www.syslog.cc/ietf/protocol.html. III. Introduction of "syslog Transport" ID (Chris - Anton unavailable) 15 min. draft-ietf-syslog-transport-udp-00.html http://www.employees.org/~lonvick/transp ort/draft-ietf-syslog-transport-udp-00.txt 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. draft-ietf-syslog-sign-13 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. draft-ietf-syslog-device-mib-05 This started with modest ambitions and became more complicated. After more reflection, the current -05 draft emerged. The name "device" is historical. 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. |