-----BEGIN PGP SIGNED MESSAGE-----
At 11:20 AM 12/7/00 -0800, Chris Calabrese wrote:
>This looks great.
Thanks.
>Some questions/comments...
>
>o Is it actually true that you'd need all the messages of
>the block plus the signature message to verify the
>authenticity of any one message (as stated in 1.0.c and
>2.1.b)? It seems you should really only need the message
>you want to verify and the signature message (as implied in
>2.1.d), not all the other messages in the block.
All you need to verify a given message is that message and
the signature block. That's the whole point of having the
signature block contain hashes of all the messages it's
signing--so that all the information is there to make the
signature valid. It's possible in principle to get the
signature block, but none of the messages; you could still
verify that the signature block was valid and signed.
>This is important because it allows messages in the same
>block to go to different places as long as the signature
>messages go to all those places (or some central signature
>block repository, I guess).
I guess this is true. My goal had been to make sure that
the collector ends up with a log file he can verify with
only the information available in that file. But it's
possible in principle to design a syslog-sign like system
where either:
a. Each signature block is propogated to all collectors.
or
b. Signature blocks go to some central repository, where
from which they're retrieved when it's time to review the
logs.
It seems to me that (a) might be useful in some
environments, though it seems kind of wasteful. I can't
think of a situation where (b) would make much sense; why
make the sysadmin go to two different machines in order to
read a single log?
>o Shouldn't the signature block cookie (2.1.1.a) be a
>reference both the syslog and signature part of its
>job? How about ``@#logSIG''? Similarly @#logCER for
>the certificate cookie (2.2.2.a). Admitadly a nit.
This is fine. It doesn't matter what the cookie is, so long
as it's not a common first eight characters of log messages.
>o Seems you might want to specify more than one
>pre-defined HMAC function (2.1.2.1). Maybe MD5 and
>{DSA/320,RSA/1024,RSA/2048} too. Also, you need to
>specify at least one combination that must be
>supported by all implementations. Otherwise you'll
>never fix the interoperability problems.
I was thinking of specifying something like
Version 1 == SHA1 + DSA
since that's all written up in easily-referenced documents,
and since this is an environment where DSA's short
signatures really come in handy.
>o In 2.1.2.2 (Redundancy), you'll need to change the
>wording in the first paragraph to make it more obvious
>that the whole redundancy issue is an implimentation
>issue. Also, what about just sending each signature
>message multiple times as well as or instead of having
>overlapping signature blocks?
Well, the redundancy isn't exactly an implementation issue.
The reviewer has to put up with whatever level of redundancy
is selected by the device, and a good device implementation
has to support configurable levels of redundancy. The whole
point is to make this useful in a wide range of
environments.
>o In 2.2.d (Key blob types), do you think PGP, SSH1
>and SSH2 types should be added? In theory they can be
>covered by conversion to type 'F', but they're awfully
>popular.
I'm not sure what the best thing to do here is. It seems
like the signing keys for each syslog device ought to be
unique signing keys not used for anything else. And that
the simplest, lowest-overhead implementation is for the
sysadmin to keep track of the public keys for each device,
and just use the certificate blocks sending key fingerprints
to check for something that shouldn't ever happen. (If one
of your devices changes keys without your knowledge, it's
probably something you'd like to know about.)
>o What does the stuff look like to specify the
>session ID in a log message?
I assumed the superincreasing session ID requirement here,
though there's no inherent reason we have to stick with
that. Honestly, after writing the syslog-auth document,
with a zillion different optional and variable-length
fields, I just wanted to start out with the design being
very simple. But we can add support for pseudorandom
session IDs, and I think that would be a reasonable
addition.
Also, note that there's nothing inherent in this spec that
requires digital signatures. We could use hmac-sha1 just as
easily, though naturally, the key management problems get
bigger when we're using symmetric keys.
>-Chris
- --John Kelsey, [EMAIL PROTECTED]
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.1 Int. for non-commercial use
<http://www.pgpinternational.com>
Comment: foo
iQCVAwUBOjBoYCZv+/Ry/LrBAQE6IQP/dwXQE2WBAyRE/tJHg1YnEpzM8dXHSDzI
PUhv64KI2E6XYVhTYeryJ2qXgOUGUj8dphnAD0WUw6Hh46IlIfGbFN4VO1tCkZrx
iOXrYisXguaxLZ7mLt0PHbgxi3GO1TBoviAB7QHJKDj0jrj3IDYMyzW2GBDWFgpH
uOgJGtLoscA=
=CmYJ
-----END PGP SIGNATURE-----
