-----BEGIN PGP SIGNED MESSAGE-----
At 09:30 PM 11/20/00 -0600, you wrote:
>>Okay, so I've spent some time thinking about this (along
>>with writing a much bigger document than I intended to
>>describe syslog-auth as I see it, hopefully to be sent out
>>real soon now)
>
>(Before I started, I could'a sworn that a totally complete ID
>on syslog would not have been more than 5 pages... ;-)
I am coming to know the feeling. Just thinking through
forwarding and storage security issues raises all kinds of
interesting questions, like how to handle storage security
on old-style receivers, and how to keep messages that are
forwarded for a huge number of hops from growing to some
unreasonable size.
...
>Are you proposing to have a hash included within each message
>as well as a signing block? That makes sense, but it wasn't
>entirely clear from what you wrote here.
No. The whole point of this is to leave the messages
unaltered, so that old-style receivers can store or forward
them without any problems. That means we want to put the
signatures in additional syslog messages (and that those
messages have to go where the others do).
You can think of each message as effectively carrying a hash
with it, since the receiver can always compute the hash on
a message that's arrived. I visualize this whole scheme as
mainly being useful for offline analysis of the stored log
data.
There are only four possibilities for a given message seen
by the receiver:
a. We get a signature block into which the message fits.
This tells us that the message hasn't been changed since it
was sent, and where the message fits into the sequence of
messages sent by the sender. The information in the rest of
the signature block lets us determine whether this is a
replay, and whether we're missing any signature blocks.
b. We get the signature block into which a given message
would fit, but we don't get the message. In this case, we
will be able to tell that we've missed some message with a
given hash, and where it should have been in the sequence of
sent messages.
c. We get a message, but it has been altered in transit in
some way, or it is an attempt to insert a message into the
sequence of received messages by some kind of an attacker.
The hash doesn't fit into any of the nearby signature
blocks, and so we discard the message as fake or
accidentally altered.
d. We get a message, but the signature block(s) into which
the message fit was/were lost. In this case, we can't
really say anything about whether these messages are valid.
We can add redundancy in the signature blocks in various
clever ways, but we will never be able to avoid this as a
possibility. (Even over reliable delivery mechanisms, an
attacker who can intercept and alter IP messages can always
cause connections to fail.) The more redundancy we put into
the signature blocks, the less plausible it will be that
random dropped packets just happened to take out all the
signature blocks involved.
...
>>It's simple enough to add redundancy to this. For example,
>>we can send a signature block every 17 messages, and have
>>each syslog block carry the hashes of the previous 17 and
>>next 17 messages. But it's also easy enough to see that as
>>long as we don't have reliable message delivery, we will
>>have some chance of not being able to verify some messages.
>
>And then you also have the case of multiple signature
>blocks being lost. Either proposal ("past-34" or
>"past-17+next17") sounds like it will well cover what we
>have in the charter.
I think the only issue is plausibility of missing signature
blocks. If every message were signed by ten independent
signature blocks, thousands of messages apart, then a set of
missing signature blocks that left some messages unsigned
would be nearly certain evidence of an attack. At some
point, this becomes very similar to using a reliable
delivery mechanism, in terms of the options available to an
attacker.
...
>>The big question to me is how we can encode this signature
>>block so that it will always be forwarded to the same place
>>as the messages associated with it are forwarded. Is there
>>any way to reliably do this?
>
>I think that would be an implementation issue. The import thing
>in the ID is the description of the signature block and its
>usage. It should be noted in the ID that it will only be useful
>if it is received by the devices receiving the syslog messages.
>I'd suggest keeping it within the syslog format; perhaps using
><46> = syslogd facility + informational severity.
This makes sense. I see this as fundamentally a separate
thing from syslog-auth, though. Different key management,
different main objectives, different kinds of cryptographic
mechanisms. It may be necessary to include a certificate in
the signature blocks, for example. It becomes much less of
a security problem to let each machine have only one secret
key value. But the signature verifications (including
reordering recently-arrived messages as needed ) will be
computationally expensive to do online.
...
>Both encryption and compression make the message unreadable
>to packet sniffers. I don't think that we want to change
>that behaviour.
Do you mean we want to make sure messages can be read by
packet sniffers (for debugging, I guess), or that we don't
want messages to be readable by packet sniffers?
(Compression by itself won't add any real security against
packet sniffers.)
>Thanks,
>Chris
- --John Kelsey, [EMAIL PROTECTED]
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.1 Int. for non-commercial use
<http://www.pgpinternational.com>
Comment: foo
iQCVAwUBOhocxiZv+/Ry/LrBAQErAwP+JTZEDiCRudm9Bb9XTjtCmjEzpO1McEb9
JxL0M2IRObEzgTs5k09QVWR9uJTP/Z5KIIGzdkpOMyKYor5s/DzN+PTnVQozDSPF
wd663RD+mJ0z9dAalpsiemkz9k4Nji/Xo8k8GCrTbhEDR6bsOUlIAvf3vCVYx8f0
wsNSHvI8bK8=
=w3wN
-----END PGP SIGNATURE-----
