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 , , or 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 : * carries actual message * has xml:lang, severity, facility, ISO timestamp, processName, processID (if known), deviceFQDN (for relays), #PCDATA - original message COOKED : 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 really needed? Some data could be one-time for a channel, put into the 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