-----BEGIN PGP SIGNED MESSAGE-----
At 12:32 PM 12/8/00 -0800, Chris Calabrese wrote:
>> 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?
>You're assuming there's only one person looking at
>the logs. In our environment we may have very
>sensitive data in some of our logs. Therefore we
>keep the logs for different applications seperated
>as well as seperating the applications logs from the
>real "system" logs. Not necessarily on different
>machines, but at least in different files with
>different permissions.
Okay. But why not just assign a different signature group
for each of these files, so that the signature blocks for a
given sequence of messages always go into the file with
those messages? Alternatively, it would be totally
legitimate to split out those messages at the collector into
their individual files, along with:
a. Copying the signature blocks to all files.
b. Making some distinction in the stored files between
messages that were sent to different files, and messages
that were never received.
This is likely to be useful in many environments, since (for
example) it's legitimate to verify the signatures on
interesting messages only, if that what you want to do.
(Caveat: if you do this, an attacker who can alter messages
on the wire can change all interesting messages to
uninteresting ones before they arrive at your machine.)
...
>I wasn't so much thinking of reusing your PGP key
>or SSH key as reusing the tools that generate them.
>I guess a simple PERL script that converts from
>one of these formats to the native syslog-sign
>format would work equally well, though.
This seems reasonable. If this is intended to be a usable
standard, then:
a. It has to be reasonably easy to implement with available
tools.
b. It has to specify enough details of things like key
formats that it's reasonably easy to build interoperable
versions, e.g., software for different devices written by
different people, which is all understood by software for
reviewing these logs offline, or processing them online,
written by someone else.
For this reason, I cringe a bit at the thought of saying
``put your public keys into whatever format you find
convenient, and let the recipient sort all that stuff out.''
Is there a single really good format for encoding all public
keys, which has widely available software support? I
especially want to make sure that using DSA is as easy as
possible in this environment, since DSA's short signatures
are so nice here.
...
>> I assumed the superincreasing session ID requirement
>> here,
>
>OK, so you're assuming this is on top of syslog-auth.
>I have no problem with that, but just wanted to be
>sure.
No. I reused some fields and concepts, but none of this
requires syslog-auth.
>BTW, I just finished reading the syslog-auth tome,
>and I'm very puzzled about one thing... Why have
>both syslog-sign and the Storage-MAC block in
>syslog-auth? Seems like the latter is pretty weak
>compared to the former.
Right. It's because
a. The two mechanisms are separate, and there's no reason
to expect anyone to use them together.
b. I wrote syslog-auth up first, and learned a lot about
what I didn't want to do. Thus syslog-sign has almost no
complicated options or assumptions.
- --John Kelsey, [EMAIL PROTECTED]
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.1 Int. for non-commercial use
<http://www.pgpinternational.com>
Comment: foo
iQCVAwUBOjMQByZv+/Ry/LrBAQG37AP+PkbLlpcTQAT3kUfuZC7fCYWQFmpfaVoI
9yMv4/GhYM2sRgHS2soufn4bBixQeMw8eUnzgOm+9VlKayjD30uVquM1jpT3GBpU
xAXuFg1Xfl7ctEI3r4ycojagjXz0Km74VeGh9Vmtw0E6bxyld9EemhTDE3yjUv8Z
xP6U70xXV0A=
=h2QP
-----END PGP SIGNATURE-----
