Alex Brown wrote:
> Status report on syslog BOF outcome
>
> [...]
> > - Should this group get into the secure storage of records or keep to
> > the secure delivery of them
Secure storage is definitely an issue because of the desire for provably correct
logging data in court. However, it is not as much of an issue as secure delivery.
So, I'd say the right thing to do is at least make sure that it's possible to secure
things securely, but not necessarily to go out of our way to enshrine how to do it
in a standard or make sure it works in a reference implementation.
> > - Are strong authentication and tamper proofing needed?
TLS, IPsec, and some mechanisms that would provide save record storage would also
provide authentication and tamper proofing on the wire. Additionally, lack of
authentication is probably the single biggest security complaint against current
syslog. Therefore, it seems a no-brainer that you want these features, at least as
options.
> > - Logs must be kept confidential as is required in certain countries.
Again, taken care of quite easily by TLS, IPsec, and/or record-storage mechanisms on
the wire. Whether logs are actually confidential or not depends more on how many
people have access to the secure log repository, though...
> > Stored records need to be stored in clear-text
> > so they may be read and manipulted.
I definitely disagree here. Stored records need to be accessible in clear text so
they may be read and manipulated, and how to access the clear text version must be
obvious. That doesn't mean you have to store in clear text.
For example, if logs are accessed something like this:
log-query source_machine=fubar.mydomain.com start_time=yesterday |
processing-script
Why should anyone care if the files are stored in an SQL database on top of an
encrypting filesystem?
Be careful about over specifying the implementation details.
> > - The message format must be excluded from the efforts of the WG.
> > - The WG must focus on the protocols only
> > - Message formats are not in scope of this WG (if formed)..
What exactly does this mean? If it means that the implementation is free to store
records any way it likes on the disk, then I agree. I disagree if it means the WG
produces a document that merely says something like:
"Logs are sent as an uninterpreted ascii stream over port TCP port XXX, with
IPsec as an option for authentication and confidentiality."
Without structure in the messages, we're still stuck with the current mess where
programs can't parse logs without all kinds of special log-specific knowledge.
> > The IETF is strongly biased toward "running code." I would encourage
> > all to actually put together implementations. Given the subject matter
> > a "drop in" replacement for syslog would be the form of "running code"
> > for this group.
>
> I take this to mean that any replacement should observe the syslog(3)
> API at each UNIX client. Semantics of the parameter lists can be
> extended (e.g. more facilities can be added) but there should be general
> backwards compatibility to allow existing client applications to use the
> replacement with only relinking. It does not seem necessary to retain
> the syslogd.conf(4) specification.
> It seems that the XML encoding of the ULM data model, which we've
> discussed on this list prior to the BOF and which is described in a
> rough draft at
> ftp://ftp.3com-ne.com/pub/syslog/drafts/calabrese/xml-log.txt
> does not fit well with a requirement that the syslog(3) client API be
> retained.
I think everyone agrees that we need to support the existing syslog() API for
backward compatibility. The question is whether we might also have an extended API
to get extra capabilities, etc.
If this is the case, then the XML encoding is still perfectly valid, since it has no
problem encoding the stuff that the current syslog() API can generate.
> However, it's probably still worth developing this approach
> for discussion; to be considered there must be a prototype
> implementation. Is anyone interested in trying implementation of a DTD,
> client, and server? I'm ready to help within my resources but this
> would not be a funded 3Com project.
As the main proponent of the XML encoding, I guess I'd look pretty silly if I said I
wasn't interested in being involved in the implementation. The first step, however,
is to refine and flesh out the spec document, so we know what we're supposed to be
building.
--
Chris Calabrese
Internet Infrastructure and Security
Merck-Medco Managed Care, L.L.C.
[EMAIL PROTECTED]
.
