-----BEGIN PGP SIGNED MESSAGE-----
[ To: syslog list ## Date: 11/08/00 ##
Subject: Storage vs. Transmission security and Forwarding]
I had a couple questions/comments on the syslog-auth stuff,
which I'm working on writing up and fitting into Alex's
previous draft.
1. Storage Security
To what extent is the syslog-auth stuff supposed to
provide security for messages when they're stored on the
receiving machine? I keep seeing comments that imply to me
that people are expecting this stuff to provide storage
security, but it can't do that.
This is related to issues of how to handle the
authentication messages when forwarding. I want to explain
how I'm thinking of this stuff, and I'd appreciate it if you
guys can tell me if I'm missing something.
All the cryptography we've been doing involves a secret key
that's shared between two parties, whom I'll call the Sender
and Receiver. There are a couple of implications of that:
a. Only someone with that shared key can generate a valid
log message.
b. *Anyone* with that shared key can generate a valid log
message; there's no way to tell whether a given message was
generated by the Sender or the Receiver.
This is what makes it impossible for the cryptography we're
doing here to provide security for stored syslog messages on
the Receiver's disk. If the Receiver hasn't been
compromised and is rejecting messages whose MACs and
sequence numbers don't check out, then the messages on its
disk are valid, and there's no reason to store the
cryptographic information. If the Receiver *has* been
compromised, then we can't trust what's stored on its disk.
However, we also can't trust the MACs on those messages to
mean anything, since the Receiver has the same key as the
Sender.
What all this means is that the cryptography we're doing can
provide security on the wire, but we're going to have to add
some things if we also want to provide storage security.
So, I guess my first question is: are we expecting to use
the cryptography in syslog-auth to provide storage security?
Because I can design (have designed) stuff to do this, but
it's not what we're using to authenticate the syslog
messages on the wire.
My feeling is that these are separate problems, and that
we assume the integrity of the Receiver implicitly in
trusting its stored messages.
2. Forwarding
Sometimes, there's an intermediate machine that's collecting
syslog messages from one or more devices, and then
forwarding them to one or more servers. It's important to
work out how the cryptography in this system works.
There are a few possibilities:
a. Each hop (Sender->Relay, Relay->Receiver) is handled
independently, with only an additional field added to
indicate that this message came from the Sender by way of
the Relay, rather than directly from the Relay.
b. The secure part is ``tunneled'' through from the Sender
to the Receiver; the Relay has no way to resist replays or
anything like that, it just forwards messages that claim to
come from the Sender. The Sender discards any
unauthenticated or replayed messages as needed. This may
require an additional field to make it easy for the Receiver
to figure out which Sender this came from. However, that
information need not be MACed, since an incorrect
identification of the source of the message simply means
that the Receiver will use the wrong key to check the MAC,
and so will reject the message. (An attacker can *always*
make us reject the message, by flipping even a single bit of
the message in transit.)
c. We could allow flexibility between these. That is, we
might just specify that the Sender authenticates the message
to whichever machine along the path of relays it has the key
for, and relays that don't share the authentication
information must just forward the message along unchanged.
d. We might even decide to allow multiple MACs, one for
each recipient with which we share a key along the route.
This would also be useful if we decided we wanted storage
security from this scheme--we could include one MAC in the
message for which only the sysadmin has the key.
Compromising the Receiver would no longer allow an attacker
to alter the stored messages, though he could still delete a
few inconvenient messages in a way that looked like the
messages had just been lost in transit.
It looks to me like it is very important to allow at least
(a) and (b). We should support the tunneled case, because
it's a really natural way of doing things. We should
support the case of securing each hop separately, because
sometimes, there just won't be a shared key available
between the Sender and Receiver.
Question: Is it possible for the Sender not to even know the
eventual Receiver of the message? It seems like this is
allowed to happen, which pretty-much requires that we
support the hop-by-hop way of authenticating messages.
Otherwise, whenever the sysadmin reconfigures the relay
machines, he has to also do a bunch of new key distribution.
(In fact, supporting the hop-by-hop way of securing the
messages seems like it might make key management a lot
simpler in many situations.)
I think a lot of these schemes will be easier to implement
if each message authenticated under a key has an identifier
attached. This will make it easy for the Receiver to find
any unaltered messages that it can verify.
If the Sender and Receiver are sharing a secret key K, then
it's easy enough to use the one-way hash of that key as an
identifier for this key. Let's call this
K_{S,R} is the shared authentication key between Sender and
Receiver, 128 bits long.
ID_{S,R} is the identifier of that key,
ID_{S,R} = low64bits( md5(md5(K_{S,R})) )
Anyway, I'm inclined to include this ID unless someone has a
strong reason why it's a bad idea. It adds 64 bits (11
characters in base-64-encoding, or 16 characters in
ASCII hex representation) to the message.
The larger question is what you guys think of the forwarding
options. Should we be supporting all of these options? Am
I making some dumb assumptions that I'm not seeing?
- --John Kelsey, [EMAIL PROTECTED]
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.1 Int. for non-commercial use
<http://www.pgpinternational.com>
Comment: foo
iQCVAwUBOgoeESZv+/Ry/LrBAQEGhgQAmqb4/dRyPwdVYLsCuE3tCWfBrIS+fy/U
jd9Tz7XzFNEihKtm5FUFk35AJv3hmFnQdE4GT/t1SCI5WaP576usE88FwSamxKVv
95nv0dZ1ty3lK3pmhqyBaBxCVbybGm7ivubJbekahVH+kZmEJIen5HGuL9fJcSz8
gNiYNcT3iew=
=pLtL
-----END PGP SIGNATURE-----
