Originally, I was going to complain that this mechanism doesn't allow for end-to-end message-level confidentiality. However, the more I think about it the less I believe that's a realistic goal anyway (there are too many interdependencies given that the log system has to look at the data to figure out where to forward/store it). Meanwhile, the Syslog-Reliable stuff adds some very useful information (timestamps, reveived-by headers, etc.) that also needs integrity protoection. So... If this is really end-to-end integrity (rather than just the end-machine signing the stuff before it goes on disk, which isn't as interesting IMO) and it's going to operate by large blocks of messages, then the Syslog-Reliable stuff would have to work by the same blocks instead of individual messages. Not impossible, but not necessarily easy either since a block may get split up at some point to go to different log servers or different files on the same server. And without end-to-end confidentiality, the ability for messages to go to different files on the same server becomes more important as you're going to be relying more on file-level protections. So... I still think this needs to be done message-by-message. John Kelsey wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > At 10:44 AM 11/9/00 -0500, Chris Calabrese wrote: > ... > >I strongly believe that a framework for cradle-to-grave > >message signing and confidentiality. I also believe that it > >is easier to add this to what's already in Syslog-Reliable > >than to what's in Syslog-Auth from what I know about both. > > Just for what it's worth, adding confidentiality to > syslog-auth is really simple. There's nothing about > encryption that requires reliable delivery or two-way > communications. It's just adding another field in the > authentication block, and a couple bits in the version > block. > > Key management gets a little easier for two-way > communications, but not as much easier as you might think. > (If you want every machine to have a certificate, you have > to predistibute those certificates, or you have to do > something ugly and insecure on the first interaction between > each machine and the CA. But key management is a different > can of worms.) > > Anyway, for message signing, you want to do this for storage > security, right? (There's no reason to worry about using > digital signatures for security on the wire.) I really > think this ought to be thought of separately from the > over-the-wire security--the receiver certainly shouldn't > have to check a signature whenever it receives each message; > instead, that should be done offline when the stored log is > read and verified. (This also allows us to choose a digital > signature scheme like DSA, where signing is relatively cheap > and verifying is more expensive.) > > Anyway, there are a couple of simple ways to handle this, > where we include signatures as normal syslog messages of > less than 1024 bytes: > > a. If we're going over syslog-reliable, decide how often > it's reasonable to sign messages. Like, it may be that > messages are so common that you only want to do a digital > signature once per hundred messages, for performance > reasons. So just generate one additional message after each > hundred messages sent, containing a digital signature of the > range of messages. (That is, we digitally sign something > like ``Batched signature of messages 100-199 in reboot > sequence 0x544802e481911038'', hash(messages 100-199).) > If we trust the reliable delivery mechanism, this message is > sure to arrive and be stored on the receiver's machine. > Our whole system then ends up being secure against > compromise of either the sender or the receiver. (That is, > if you compromise the sender or receiver right now, you > still can't alter any of the old messages that have been > batch-signed. You have to compromise both machines to alter > already-received log entries. > > b. If we're going over syslog-auth over UDP, things get a > bit more complicated, because we may have to deal with both > missing signature blocks and missing messages. We can do > the signatures, we just have to add redundancy, and there > will always be some low probability that we won't be able to > find a signature on all the messages. Worse, however, with > unreliable delivery, if I compromise the receiver, I can > discard messages I don't want read, and there's no way > signatures from the sender can catch this. The only thing > that can catch this is something done on the receiver at the > time messages arrival, like the audit-log scheme Bruce and I > published a couple years ago, or having the receiver logging > its status to another machine over the network, so that it > can periodically send along a log entry like: > > Received from sender X reboot session ID 0000000000012831 > messages 101-197,199-268,271-300, > hash=e4d7f1b4ed2e42d15898f4b27b019da4. > > to some other machine. > > If this message has to go over an unreliable channel, we can > again add redundancy, e.g., every few hundred received > messages, send out a new message which contains the hash of > the most recent several hundred messages, plus also the > previous three such hashes sent out. And in any event, we'd > send it out using syslog-auth, to prevent any games being > played with altering these hashes to try to discredit logs > stored on a given log server. > > >So, the question remains whether Syslog-Auth is really > >needed as a seperate entity if this stuff is added to > >Syslog-Reliable. My feeling is that it is not needed, but > >I'm open to the opinion of others. > > My impression is that we want to be able to provide > authentication, replay detection, and detection of missing > messages even in environments where we're stuck with (in the > worst case) unreliable one-way message delivery. This > allows a more-or-less drop-in replacement for syslog. > Providing the authentication and detection of gaps in the > messages should also really be useful for the UDP > environment, since it means that someone can detect the fact > that (for example) there's a sequence of 50 missing log > messages from a certain machine, which could indicate an > intentional blocking of interesting log entries. > > ... > - --John Kelsey, [EMAIL PROTECTED] > > -----BEGIN PGP SIGNATURE----- > Version: PGPfreeware 6.5.1 Int. for non-commercial use > <http://www.pgpinternational.com> > Comment: foo > > iQCVAwUBOgvIGiZv+/Ry/LrBAQEGUwP+Ob3eULYr64gEI3k4ou02QsKDd1RCsqO2 > 0q6N85gyI+1VfHf3xSUgWkDQe6w520YiMhWSRc73fU8a0Hmq7k2nz+LOJyoaOnvj > Juou01WchIe/ByLk5/BoZw4m0Y83XQ1nzf5Zdy/9J1QRhsTwYMPGYdV8L9sXsqZv > odOh949mGIQ= > =yWEz > -----END PGP SIGNATURE-----
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
