2.6.11 Security Issues in Network Event Logging (syslog)

NOTE: This charter is a snapshot of the 49th IETF Meeting in San Diego, California. It may now be out-of-date. Last Modified: 23-Oct-00


Chris Lonvick <clonvick@cisco.com>

Security Area Director(s):

Jeffrey Schiller <jis@mit.edu>
Marcus Leech <mleech@nortelnetworks.com>

Security Area Advisor:

Jeffrey Schiller <jis@mit.edu>

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:

May 00


Post as an Internet Draft the observed behavior of the Syslog protocol for consideration as an Informational Document.

Jun 00


Submit Syslog protocol document to IESG for consideration as an INFORMATIONAL RFC.

Jul 00


Post as an Internet Draft the specification for an authenticated Syslog for consideration as a Standards Track RFC.

Aug 00


Submit Syslog Authentication Protocol to IESG for consideration as a PROPOSED STANDARD.

Sep 00


Post an Internet Draft describing enhancements to the Syslog authentication protocol to add verification of delivery and other security services.

Oct 00


Submit Syslog Authentication Protocol Enhancement to IESG for consideration as a PROPOSED STANDARD.

Dec 00


Revise drafts as necessary to advance these Internet-Drafts to Standards Track RFCs.


No Request For Comments

Current Meeting Report

syslog Working Group Minutes 49th IETF
David A. McGrew mcgrew@cisco.com

Chris Lonvick:

No changes to agenda
Comparison of features of syslog-auth, syslog-sign and syslog-reliable

Extremely brief review of syslog-syslog-02: no questions

John Kelsey:
Syslog-Sign and Syslog-Auth


* support transmission and storage security
* support offline review of logs (online review is more computationally expensive)

Security goals:
* origin authentication
* message integrity
* message sequencing, replay protection
* gap detection
* explicit security properties

What's not possible:
* ensuring that all messages arrive, or arrive in order
* ensure host security

Three kinds of messages:
* normal messages
* signature blocks
* certificate blocks

Signature blocks sign block of (30 or so) messages.
Each message is linked back to its block, and put into order.

Q: what is offline and online?
A: Offline is after messages have been received.

Missing, garbled/altered messages appear as "invalid" markers in log, but can be retained for future reference. Duplicate messages are handled properly.

Device: machine generating logs
Relay: machine that forwards log messages
Collector: machine that forwards log messages
Reviewer: offline reviewer of logs

Device may send different messages to many collectors

Signature group: messages ALWAYS sent to same collector

One signature group per collector is simplest implementation, other ways are possible.

Syslog has no notion of a session, but Syslog-Sign needs a session definition. Unique session ID is used, 48 bits non-decreasing.
Message Index Number (implicit, can be reconstructed)
Message types: raw, signature blocks, certificate blocks
Sending device has tunable redundancy parameter

Signature Block:
Version {protocol, hash, signature}
Session ID
Signature Group
Global Block Counter
First Message Number (in signature group)
Message Hashes

Q: global counter?
A: Global over all signature blocks generated by this device.

Q: If a message is lost, can signature be verified?
A: Yes.

Q: Where is name of sender in hash?
A: It's not, maybe it should be to protect against cases where signing keys are identical.

Signature blocks, fields:
* base64 encoding of binary data, so that it is ASCII.
* Count (number of messages whose hashes appear)
* Message Hashes (sequence of hash values)
* Signature (on all previous elements in block)

Non-RSA signatures have smaller signature sizes. Variable length
fields, based on versions of hash and sig.

* signature blocks can be resent multiple times
* hashes can be included in multiple signature blocks

Q: Why not send sig blocks over TCP?
A: That's in scope of syslog-reliable, not syslog-sign.

Q: Why not use syslog timestamps for sequencing?
A: Those timestamps are not required in syslog.

Q: Why not add NACKs?
A: Outside scope; I don't want to reinvent TCP.

Certificate Blocks:

Goal: support sending a certificate chain over (limited size) syslog messages.

At session startup, build full payload block, split into M cert blocks, send as syslog messages.

Payload block contains:
session id
ip addr of sending device
key blob type
key blob

Q: What about DHCP addresses?
Q: What about syslog messages generated before IP assigned?
A: perhaps other fields should be added.

Q: Cert blocks should be sent redundantly.
A: Yes.

Redundancy: whole payload block sent to each signature group at session startup.

Offline review
* make one raw log file
* first pass: make hash table of log messages
* second pass: verify signature blocks for each hash value
* end up with authenticated sequence of log messages

Online review
* Keep `replay window' of last K*N messages in a binary tree or hash table.

* uses syslog for transport
* new software on device
* software for online review of device
* meets all security goals
* plays well with syslog-reliable

* online analysis is more complicated than offline analysis
* may require changes to how messages are routed to collectors

Q: Intellectual property status?
A: No known patents.


More complicated key management. Forwarding Block - keeps track of secure path that message has followed, contains message status flags, and is authenticated. Sticky flags: must follow a message through path of relays.

Minuses: too complicated, requires changing *all* devices in network.

Future of syslog-auth: perhaps should move some ideas into syslog-sign.

Q: What happens if a collector has the wrong key?
A: There is a key id in the syslog-auth, which is a partial hash of the key.

Q: What are security advantages of building security into syslog, rather than use ipsec?
A: More security services provided.

Q: Why not allow other signing techniques for unreliable flows (e.g., those developed and presented in SMUG) to be used in future versions of syslog-sign.
A: Sure.

Darren New with support from Marshall Rose:


Uses BEEP framework

BEEP provides reliability, authentication, privacy
(BEEP ID in last call)

syslog Forms
Traditional UDP (device, relay, collector)

syslog Secure Transmission
Message auth ensured (you know who message came from)
Replay prevented
Integrity assured

BEEP capabilities
point to point sessions
one or more underlying sessions (TCP or SCTP)
One user identity (via SASL)
One privacy policy (via TLS)
One or more channels (one for control, many for application)
Creating a channel associates a profile
Profile defines a syntax and semantics

Syslog Reliable Profiles

Two integrity profiles: TLS, SASL/DIGEST-MD5

Selections are orthogonal

TLS is SSLv3 plus provisioning
DIGEST-MD5 hashes nonce and password, can add hash to messages

RAW profile
MSG from collector
ANS, ANS, ANS, ... NULL from device
each ANS carries one syslog message

BEEP can run multiple channels (e.g., high priority, low priority)

COOKED profile
Basic XML formatting/wrapper
MSG from device
MSG is <iam>, <entry>, or <received>

<iam> fqdn, ip, type, #pcdata (commentary)
semantics: compare FQDN to SASL user

Can support sticky flags.

Q: Multihomed hosts - which fqdn, which IP?
Q: If we insist IP addr interface MUST be used, this might break some implementations. Make this a SHOULD?
A: Will discuss on mailing list.

BEEP can run on multiple transport layers.

COOKED <entry> :
* carries actual message
* has xml:lang, severity, facility, ISO timestamp, processName, processID (if known), deviceFQDN (for relays), #PCDATA - original message

COOKED <received> :

Discussion Points

Q: Would it be reasonable to make TLS a MUST and SASL a should?
A: Perhaps the matrix of options should be simplified; always TLS can be discussed on the email list.

Q: Why digest-md5?
A: Due to other guidance from SASL folks, alternatives can be visited.
Comment: this was discussed in LDAP WG, we decided on digest-md5.

Q: How does replay protection work?
A: (Paraphrasing) It's a challenge/response protocol, using password as a shared secret.

COOKED <received> really needed? Some data could be one-time for a channel, put into the <iam> message.

Comment: this would be a good thing, but we should avoid an explosion in the number of channels.

Comment: multiple paths to log are possible.
A: But those would be on different channels.

Comment: some folks want to store info on the complete trail.

Meeting Closed


Syslog-Sign and Syslog-Auth
Syslog - Reliable