Alex Brown wrote:
>
>
>> Chris Calabrese <[EMAIL PROTECTED]> on
>> 10/25/99 11:42:14 AM
>> Sent by: Chris Calabrese
>> <[EMAIL PROTECTED]>
>>
>> To: [EMAIL PROTECTED]
>> Subject: a specific protocol proposal
>>
>> ...
>
> 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).
> 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.
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."
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.
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:
<RCVD HOST=loghost DATE=whatever SRC.NAME=intermediate>
<RCVD HOST=intermediate DATE=whatever
SRC.NAME=orig_sender>
<...>
</RCVD>
</RCVD>
--
Chris Calabrese
Internet Infrastructure and Security
Merck-Medco Managed Care, L.L.C.
[EMAIL PROTECTED]
.
