Hi Chris,
At 01:57 PM 10/25/00 -0400, Chris Calabrese wrote:
>Chris Lonvick wrote:
>
>> Reliable: As described in syslog-reliable-01, there will be two
>> formats for the messages being transmitted. First, the RAW
>> profile will allow the transmission of any string. Second,
>> the COOKED profile will still allow the transmission of any
>> string but will also contain other elements.
>
>I'm a little confused here.
When I say "string", I mean the original syslog message is treated
as a string. It can't be modified.
>Back several months ago, I proposed something like the COOKED mode
>and was told that this sort of thing was beyond the scope of the Syslog
>WG and that the IDWG would be driving this effort.
>
>Now, the IDWG has published something, but the Syslog WG isn't
>using it. Instead, a third option has been proposed. A third option that,
>IMO, looks an awful lot like my original proposal (I'm just talking about
>the data formats here, not the reliability bits).
Your proposal had to do with defining the contents and format of the
syslog messages. The COOKED format will retain the original syslog
message as a string (in the format described in syslog-syslog-0x) and
then append the additional elements. The RAW format will only use the
original syslog message. This is the same as is being proposed in the
Authenticated format. Changing the format, or defining a format is
outside the scope of this working group.
>Is this in the charter or not? And if so, isn't the work that's already been
>done in this area being recognized (my proposal, UML, and the IDWG
>stuff)? (sorry if I come off a bit testy here, but I am)
The IDWG has defined their own format which meets their requirements.
The ULM work and your proposal look viable for defining the contents
and format of event messages. I've heard from very many people that
they would like to see that work started again. However, it is outside
of the scope of this WG. Please get together and propose a BoF. If
not that, then get together and submit an internet draft.
I don't think that we're doing anything here with the proposals on the
table that will preclude the use of a future standardized format. It is
my hope that when a standard format is accepted, it will be able to
utilize the work that comes out of this Working Group.
>CONFIDENTIALITY - Oops, nothing going on there.
>
>You can get on-the-wire confidentiality through SSL/TLS or IPsec.
Confidentiality and transmission integrity is fundamental to BEEP. See:
http://www.ietf.org/internet-drafts/draft-ietf-beep-framework-05.txt
>However, that still leaves the possibility of rogue/trojan relays or even
>collectors. Ideally we want to be able to send the logs anywhere and
>still make sure only authorized people/processes can see them.
TLS can use bidirectional authentication through the use of authoritatively
signed certificates. If that's too much of a problem to set up, it can
fall-back to single sided authentication or null authentication. That's
just the way that it's working in most browsers today.
>The only way to do that is to encrypt the sensitive data and leave it
>encrypted. Something like this:
>--some deleted--
Are you proposing that the device generating the message have the
capability of encrypting all messages?
>> This brings up some architectural questions that I'd like to pursue.
>>
>> 1. Should some wording go into the Authenticated and Reliable IDs that
>> explicitly states what is to be done with messages received? Perhaps
>> the Authenticated relay must wrap the Traditional message into an
>> Authenticated format using its own credential (T-[TA]-A)? Perhaps the
>> Reliable relay must do the same (T-[TAR]-R)?
>
>Be careful that you're not mandating that Relays sign data
>injected into the stream by attackers!
I think that there is the same concern with all syslog messages today.
Having them wrapped/signed by the first relay doesn't mean that any
confidence should be put into their origin. It would only mean that
the first relay received them.
>Ideally the implementation would allow you to tune what IP's
>you're willing to sign stuff for and maybe put in support for the
>lightweight authentication stuff the router guys are working on
>(i.e., sign stuff that came in authenticated in the other format).
umm.. I didn't catch that.
>> 2. If we do that, should the COOKED profile contain elements in the DTD
>> for the parameters supported in the Authenticated format? ..or should
>> it be left as a clear string.
>
>I don't see the relationship to [1], but anyway... Yes, the COOKED
>profile should contain stuff allowing originating processes to sign
>and/or encrypt their log messages. The most obvious way would
>by simply using the existing standards for XML signatures.
>
>> Keep in mind that [AR] receiver should
>> validate the packet before accepting it.
>> Once it is received by the
>> relay, it should have passed the authentication test. Would there be
>> any value in breaking out those values for additional purposes only
>> for subsequent transmission.
>
>Well, if you break this out then the messages can be authenticated
>independently of the transmission system. That means they can be
>used as hard evidence as long as you can show chain-of-custody
>on the signing key, rather than on the messages themselves.
>
>It also means the messages can pass through intermediate gateways
>that don't have the signing key or don't have the horsepower to check
>authenticity. In fact, it's conceivable that none of the components
>may check authenticity until the logs are retrieved from the message-store
>for reporting (i.e., [AR] gateways don't have to check authenticity).
>
>This allows you to see the forged messages (or just messages
>signed with out of date keys or some such) and alleviates the relays and
>even the collector from the need to parse and perform cryptographic
>operations on the messages in real time. It also lets you see the
>unauthenticated messages rather than just rejecting them. Of course,
>there's a downside here in that it makes it easier to perform a DoS
>against the message store and network (if there's a bottleneck
>along the path), but the tuning of this stuff should be up to the
>implementors and not be part of the protocol design.
Good points.
>Public key is definitely the way to go here. For one thing, it is impossible
>to show true authenticity using shared secrets (they're shared by definition
>which means you don't know who for sure who did the signing). It also
>makes key distribution much harder (need O(n^2) keys rather than O(n)).
>
>The comment about keeping the keys on the collector directly speaks to why
>this is so important. With shared secret, the people/processes viewing the
>logs need to know the secret, and therefore could themselves forge messages.
>With public key, only the public portion is needed by these people/processes
>and messages can only be forged if the private portion (presumably only
>kept on the signing machine) is compromised.
>
>Yes, you still need to keep the public half of the signing key around for later
>authentication, that's an area that's already has plenty of good
>solutions. For example, you can always keep the keys on several
>floppies in several safe-depoist boxes.
>
>If you're also encrypting using the public keys of the intended recipients,
>you an use multiple keys to ensure that one of them will still be around
>when you need to decrypt. Just like PGP with multiple recipients and also
>demonstrated in the crypto example I gave above.
Thanks,
Chris
