Hi Everyone,
Things got slow just after the IETF meeting and so did I...
David McGrew took the minutes of our WG meeting on the 13th
and I've appended them below. Please review them and if there
are no objections, I'll post them to the Secretariat along
with the presentations. Thanks again, David.
I had a chance to talk with Eric Allman about syslog-syslog
after the WG meeting. He pointed out some errors to the
current draft to me. They're mostly in the way that a device
will format them if they are relayed. It also applies to the
way that they will be stored if they are not received in the
same format but I'm only documenting what is observed on the
wire. I'll have an update to that ID soon after the new year.
I've sent in John Kelsey's IDs on syslog-auth and syslog-sign.
However, it appears that the ID editors are being slower than
I. ;-) I know they have a backlog and are probably taking
a few days for this time of year so I won't try to predict
when they'll show up. I'll get them posted to the WG web
page rsn.
My thanks to John Kelsey, Darren New and Marshall Rose for
their presentations at the WG meeting, and to everyone who
attended and gave their attention.
Thanks,
Chris
(I'm using a "reply-to:" of [EMAIL PROTECTED] so if
you want to send a separate reply to me, please use
[EMAIL PROTECTED] .)
============================================================
syslog Working Group Minutes
49th IETF
David A. McGrew [EMAIL PROTECTED]
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.
------------------------------------------------------------
End
