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.
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).
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)
> [AR] R R Could this be a "best case"? The message would be
> generated in the Authenticated format and transported
> through either the RAW or COOKED profiles to the
> collector. It will be stored with the Authenticated
> attributes.
Let's see....
RELIABILITY - Yup, got that.
INTEGRITY - Got that, but only if the authentication stuff is on a per-message
basis and any new information added by the relayers wraps the entirety
of the original message (otherwise it would break the authentication scheme).
Something like this:
<log:rcvd signer=loghost.a.b TIME=2000-10-25T110512 MAC=4j4k32j4>
<log:rcvd signer=relay1.a.b TIME=2000-10-25T110511 MAC=4j34kj23>
<log:entry sender=www.a.b facility=daemon
priority=info proc=httpd:34234 ... MAC=34j23k4jk32>
Something happened.
</log:entry>
</log:rcvd>
<log:rcvd>
This does imply that some parsing needs to be done in order to
show authenticity. On the other hand, this lets the authenticity data
run cradle to grave, which has lots of advantages (discussed
more further down).
CONFIDENTIALITY - Oops, nothing going on there.
You can get on-the-wire confidentiality through SSL/TLS or IPsec.
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.
The only way to do that is to encrypt the sensitive data and leave it
encrypted. Something like this:
<log:rcvd signer=loghost.a.b TIME=2000-10-25T110512 MAC=4j4k32j4>
<log:rcvd signer=relay1.a.b TIME=2000-10-25T110511 MAC=4j34kj23>
<log:entry sender=www.a.b facility=daemon
priority=info proc=httpd:34234 ... MAC=34j23k4jk32>
<crypt sender=httpd.www.a.b MAC=43j4k32j>
<key [EMAIL PROTECTED]
value=344jkjk23j4/>
<key [EMAIL PROTECTED] value=3243jkj4j3k24j/>
<key recipient=log-monitor.a.b value=43j4j32k4/>
45JK43J5KL3J45K34J5KLJ435KLJ345LKJ345LK
</crypt>
</log:entry>
</log:rcvd>
<log:rcvd>
No, I'm not just being paranoid. What if I have a e-commerce
application that deals with prescription drugs and logs who
bought what for audit purposes (I actually do have such
an application). Under HIPPA, this information can only
be revealed to people actually involved in providing
this service, which may not include the people with access
to my logging data (might be run by a different group
or even outsourced, and there are those pesky maintenance
folks from the hardware vendor that keep insisting on
swapping out our dead disk drives).
With this scheme, I can send my logs anywhere I want to
without worrying that unauthorized individuals can access
this very sensitive data.
> 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!
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).
> 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.
> 3. It has been proposed that the credential used to authenticate the
> messages in the Authenticated proposal is a "shared secret". It also
> looks like the provisioning of that will be manual. This appears to
> be acceptable for how we're going about this and what we expect it to
> do. However, if we utilize the Authenticated format for messages
> generated by the Reliable devices, then I don't think that manual
> provisioning of the shared secret is desirable. Should a separate
> exchange be used between the Collector//Relay, Relay//Relay and
> Relay//Device to pass up/down the shared secret? If we're going to
> go to that length, should we expand the credential to include a
> Certificate? The Device could even generate a self-signed certificate
> and pass that along upwards to the Collector. The private key could
> be used to authenticate the message and that could be validated with
> the public key contained in the certificate. If needed, the Relays
> along the path could validate the authenticity of the message using
> the public key if they cache it. The Collector could do the same
> but would probably need to store it for the case that the certificate
> may not be available in the future. (Of course, having the self-signed
> certificate on the same device as the signed messages would present
> a potential vulnerability as an attacker could modify the certificate
> and the messages. ..however, I would classify that as an operational
> challenge and not something that we need to address. ;-)
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.
begin:vcard
n:Calabrese;Chris
tel;work:201-703-7218
x-mozilla-html:TRUE
org:Merck-Medco Managed Care, L.L.C.;Internet Infrastructure and Security
adr:;;1900 Pollitt Drive;Fair Lawn;NJ;07410;USA
version:2.1
email;internet:[EMAIL PROTECTED]
title:Internet Security Administrator
fn:Chris Calabrese
end:vcard
