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

Syslog-Sign

Goals:
* 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.

Definitions:
   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:
   Cookie
   Version {protocol, hash, signature}
   Session ID
   Signature Group
   Global Block Counter
   First Message Number (in signature group)
   Count
   Message Hashes
   Signature

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.

Redundancy
* 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:
   version
   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.

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

Minuses:
* 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.

Syslog-Auth:

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:
Syslog-Reliable

Syslog-Reliable

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

Syslog: RAW, COOKED
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