Chris Calabrese wrote:
> I strongly believe that a framework for cradle-to-grave
> message signing and confidentiality. I also believe that it is
> easier to add this to what's already in Syslog-Reliable than
> to what's in Syslog-Auth from what I know about both.
Well, syslog-reliable is about reliable delivery of messages from one device
to the next. Right now, it defines three rather orthoganol sets of
functionality.
The first is on-the-wire reliability (via TCP), authentication (via SASL,
and SASL/DIGEST-MD5 in particular), and privacy (via TLS). If public key
authentication is preferred, one could bring in a different SASL-based
authentication with little problem, at the risk of being incompatible with
DIGEST-MD5 if you don't implement both. Nothing prevents a device from
signing its messages with any SASL mechanism desired, as long as everyone
along the way implements it.
The second is the message formatting, of which there are two choices. The
RAW format essentially transports over TCP (or any other reliable
connection-oriented protocol) pretty much exactly what you'd get over UDP.
Any signatures or specified formatting get carried along, as long as they
would have been in the payload of the UDP packet already.
The COOKED format not only provides the raw payload, but also allows for an
XML wrapper that provides unambiguous formatting for current message fields.
For example, the timestamp is spelled out in UTC, the proccess name and ID
are broken out, and so on. The COOKED format can be used by new
implementations of applications, particularly ones doing XML-like processing
already (say, for web server logs perhaps). It can also be used if one wants
to gateway a RAW message to a COOKED message and you're willing to write
special code to understand the RAW messages. For example, if you have
Microsoft program that sends syslog messages in a particular format, from
which you can reliably extract the time, process name, etc, you can direct
it to a "relay" that will pick up the UDP messages, parse out the time,
convert it from local timezone to UTC, add on the full domain name of the
sender (rather than the netbios name, say), and do other processing like
that. It can wrap the original message as the CDATA in the COOKED format,
add the parsed headers as XML attributes to the message, and pass it on to a
collector.
All of which is orthoganol to whether the messages were encrypted or MACed
on the wire.
There's also a third set of functionalities concerned with provisioning and
such... How do devices find collectors, etc.
> So, the question remains whether Syslog-Auth is really needed
> as a seperate entity if this stuff is added to Syslog-Reliable.
> My feeling is that it is not needed, but I'm open to the opinion
> of others.
I think syslog-auth is not incompatible with syslog-reliable.
> As for formatting, I fully understand that the formatting stuff
> needs to be published seperately (though it's probably no
> use publishing it until syslog-reliable is done as it provides
> part of the framework that the formatting stuff will plug into).
syslog-reliable is dealing with the stuff that's currently in messages, and
in one case giving a place to break out some of that information,
potentially duplicating it if it was in the original text already, in order
to make it easier for collectors to understand it.
> To summarise....
>
> 1. I believe the right thing to do is to add message
> confidentiality and integrity capabilities to Syslog-Reliable.
> Hop-by-hop 'received by' stuff is also a possibility.
What do you mean by this? The hop-by-hop stuff is already there. If you're
sending directly from the device to the collector, it's already there (in
terms of just leaving the authentication in the message when you store it).
And nothing prevents a future on-the-disk confidentiality from being
included in the message.
> 2. Once this is done, then it will be reasonable to publish
> something discussing formatting of things not covered by
> syslog-reliable.
Hopefully, such formatting won't be incompatible with syslog-reliable. I'd
be very surprised if it could be incompatible with the RAW mode, certainly.
--
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
