>
> > I am generally in agreement with this XML-based encoding
> > approach but I think there are some known problems not
> > solved. I would like to see some specific discussion of
> > the client-loghost authentication, at connect time.
>
>I'd rather leave that out of the specification at this
>level. It can be dealt with at lower levels in the protocol
>stack by things like private networks (possible over
>RS-232), tunneling in SSL/TLS, tunneling in SSH, and
>tunneling in IPv6 SEC packets. Those implementations should
>be mentioned, and the reference implementation should
>support the SSL/TLS and IPv6/sec options, and possibly the
>raw RS-232 option (the private-network link option should
>require no special implementation support if it's running
>over IP).
OK - but the split between levels should be clarified. I would hope to avoid
ambiguity of whether a specification applies to data model, log message, or log file
format -- cf. ULM.
> > However, this looks like a workable approach for a draft
> > replacement specification. Could you write up a more
> > complete description of the protocol, so the following
> > security features become clear? (Does not have to be in
> > RFC form at this time.)
>
>I'd be happy to.
I would like to see the XML transport encoding proposal discussed among the
"Replacements" on the BOF agenda if we can get a bit more detail. The "unalog"
reference you noted (www.unalog.com) is really not very helpful - there's not much
more than a general concept of XML encoding of event data there. Would you consider
sketching XML for the data elements identified in ULM?
>BTW, before I get into that, I've come up with a few
>questions I think are worth addressing and would appreciate
>feedback.
>
> 1. Do we want to adhere to "strict" XML to guarantee that
> any XML-aware app could potentially process the logs?
> I'm not terribly familiar with XML specifics, so I
> don't know what the implications are here. Just from
> what I know of HTML, I'm guessing what I've proposed is
> fairly compliant, but there may be some things that
> aren't "strict XML."
Neither am I. Probably should just learn enough about XML to suggest a reasonable
direction and leave the rest to implementation.
> 2. Should the protocol allow cascaded messages so you can
> express concepts like "I got this IPsec packet and when
> I decrypted it it contained another IP packet which
> contained..."? This is a powerful concept, but it's
> also kind of complex to deal with both for the app
> generating the logs and for the app/person processing
> the logs.
Probably should be an option, although I think this is beyond the level of detail
needed now, unless a security need comes up that specifically requires it. Certainly
more complex than is desired for an embedded client.
>Also, I was thinking that an extra tag would be nice to
>allow intermediate and/or final log hosts to stick on their
>own timestamps, etc. Something like this:
>
>
>
>
> <...>
>
>
>
This is clearly the kind of flexibility you get with XML. I think a required tag
like this would fall out of the data model, which should probably identify "mandatory"
and "optional" elements along with extension mechanisms.
BTW, these XML-like tags show up as HTML tags in the Netscape Communicator mail tool
I'm using, and are closed icons. Can they be quoted? If not I think it would be
helpful to substitute "{}" for "<>" so the text can be read easily.
>Chris Calabrese
>Internet Infrastructure and Security
>Merck-Medco Managed Care, L.L.C.
>[EMAIL PROTECTED]
--
Alex Brown v 4 323 2283
Consulting engineer - MSD software development
Marlborough MA USA
