-----BEGIN PGP SIGNED MESSAGE-----
>Date: Sat, 18 Nov 2000 00:52:40 -0500
>From: Alex Brown <[EMAIL PROTECTED]>
>Subject: Re: what level for end-to-end signing?
Chris Calabrese wrote:
>> So... The idea sound like it's moving in the direction
>> of adding signatures to COOKED mode in Syslog-Reliable
>> and possibly adding confidentiality to Syslog-Auth.
...
>Sounds like it should be available (and perhaps
>user-selectable optional and to-order, e.g. neither raw or
>cooked, but rare or medium well-done as you prefer) in both
>versions. True signature authentication in the Syslog-Auth
>UDP version would be great if the UDP PDU size limit is not
>exceeded. A common signature wrapper for both Syslog-Auth
>and Syslog-Reliable/COOKED would make it easier to provide a
>single loghost server supporting both new modes as well as
>an old-fashioned mode.
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), and it looks to me like the only way to do
end-to-end message signatures that work for all lengths of
messages is to include signature blocks every N messages. I
visualize this as something like this:
For a given signing session, we generate a reboot session ID
in much the same way we do for syslog-auth. Each signing
block is of the form
a. Version (2 characters)
b. Session ID (8 or 16 characters)
c. Signature Block ID (8 characters)
b. Count (6 characters)
c. Array of Hashes (N hashes, 27 characters each)
d. Signature (54 characters)
The signature block can hold up to 34 signatures. The
straightforward way to use this is to just send it out after
every 34th syslog message, regardless of any other
authentication provided. By including the hashes of the
previously sent 34 messages, a receiver with some extra
computing resources (or a program doing offline analysis of
the logs) can compute the hash of each message received, and
match each one with a hash value in a signature block.
Unreliable delivery means that some messages won't make it
in (which is why we need to include all the hashes of the
messages in the signature block; that way the receiver
doesn't have to have all of the original messages to verify
the signature). More inconveniently, it means that we may
occasionally lose a signature block. When that happens, we
lose the ability to verify signatures on any of these
messages.
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.
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?
...
>What about combining compression and encryption to squeeze a
>full payload with signature etc into the UDP PDU?
Hmmm. I guess I don't see what this buys us. There are two
situations:
a. We're sending between a syslog-auth sender and a
syslog-auth receiver. In this case, we'll never have to
truncate anything, since we've just defined our message
length to be long enough to hold everything we're going to
want to send along.
b. We're sending from a syslog-auth sender to an old-style
receiver. In this case, we can't use compression or
encryption without making the message incomprehensible to
the receiver, and we can't do much compression without
using illegal characters in ths messages. (We also can't
guarantee that all legal message texts will compress well
enough that a base 64 encoded version of the compressor
output will be smaller than the original message text.)
What am I missing?
>Alex Brown <[EMAIL PROTECTED]>
- --John Kelsey, [EMAIL PROTECTED]
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.1 Int. for non-commercial use
<http://www.pgpinternational.com>
Comment: foo
iQCVAwUBOhluBSZv+/Ry/LrBAQGdjQQAm1pKMFmj1jVKzyPDKFgT1m8cAQz4v6en
hMcMXvP6/lUOrY3dONgTRfbvteMM0Y4ORa1Zl3zbezQyV/aAlinuC3tUy9zUs+fm
Yek3pgNKgHkbXnxH0O5OktC2oy9bhYBLniKJ6yYBeVXqGhiRPhhNZhjbwaUr1r3L
0C6GdK3pvxk=
=fE61
-----END PGP SIGNATURE-----
