---------- Forwarded message ----------
Date: Tue, 17 Apr 2001 14:59:02 -0400
From: John Kelsey <[EMAIL PROTECTED]>
To: syslog-sec-digest <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Subject: Re: syslog-sec-digest V1 #96
-----BEGIN PGP SIGNED MESSAGE-----
>Date: Tue, 10 Apr 2001 22:52:47 +1000 (EST)
>From: Darren Reed <[EMAIL PROTECTED]>
>Subject: Re: An almost-final version of syslog-sign ID, with questions
>In some email I received from John Kelsey, sie wrote:
[...]
>> b. Is there a problem having my PRI values always have a leading zero?
>> (e.g., PRI 46 is included as "046".
>Yes, if "PRI" is a combination of "proirity" AND "facility".
>
>Or you should make it explicitly clear what you mean by "PRI".
That's right. "PRI" is the integer that appears between the
angle-brackets at the beginning of any syslog message.
The signature and certificate blocks have to have PRI
values, since they're required by syslog-syslog, and since
relays would otherwise add their own values, invalidating
the signatures.
>> Using digital signatures instead of MACs to authenticate
>[...]
>I think you mean "instead of unsigned MACs". Digital signatures
>*ARE* MACs but more.
I have occasionally seen ``Digital signature'' used to mean
a MAC (a symmetric cryptographic checksum), but I don't
think I've ever seen the reverse. Anyway, the standard way
the terms are used is that MACs are symmetric checksums
(like 3DES-CBC-MAC or HMAC-SHA1), while digital signatures
are asymmetric; that is, you can know enough to check the
signatures, without knowing enough to make your own
signatures for new messages. (And then there are hash
functions, like MD5 and SHA1, which don't have any key
material, but can be used to build digital signatures and
MACs both.)
Maybe I should add a terminology subsection somewhere, in
case this isn't clear?
>[...]
>> sysadmin who uses the system; he must configure any relays
>[...]
>systems administrator, not "sysadmin".
Got it, thanks.
>> Syslog-sign provides four options for handling signature
>> groups, linking them with PRI values. In all cases, no more
>> than 192 signature groups (0-191) are permitted. In this
>> list, SIG is the signature group, and PRI is the PRI value
>> of the signature and certificate blocks in that signature
>> group.
>It should be possible for there to be at least one group for
>each combination of facility and priority. That should have
>the above worded "no less than 192". You might wish to define
>0-191 as being per-PRI and 192+ as being "user defined". I
>don't see any necessary reason to put a ceiling on this, aside
>for convenience and then it should be something like MAXINT.
>The problem you have here is that the local storage of messages
>does not necessarily reflect anything to do with them being sent.
>For other numbers, you should define numbers which are used and
>make others invalid and not worry about ranges.
>What you need to add, and can't(?), is something to the syslog
>messages that identify them with "channels" or destinations and
>generate signature blocks every n messgaes for each "channel".
Right. I can't add anything to specific syslog messages to
identify them as belonging to a specific signature group.
However, the messages are currently being routed wherever
they belong by relays. What we need to do is:
a. To the extent possible, make sure messages with the same
ultimate destination are in the same signature group.
b. Provide some features for making it as easy as possible
for relays to forward signature and certificate blocks to
the same destination as the messages in their signature
group.
c. Provide some features for making it possible to get as
much benefit as possible from syslog-sign even when those
relays are routing messages in ways that the device can't
possible guess about.
Now, my understanding from syslog-syslog is that relays are
only supposed to route messages based on what I'm calling
PRI values. (That is, on that integer between 000 and 191
between the angle brackets at the beginning of the message.)
If so, then the easy way to handle this is to keep messages
with the same PRI value in the same signature group.
Alternatively, when all messages are going to end up in the
same place before they're reviewed, we can just have one
signature group that includes all messages. The other
options are intended for supporting weird special cases.
Does this make sense?
>Darren
--John Kelsey
k.e.l.s.e.y.(dot).j.(at).i.x.(dot).n.e.t.c.o.m.(dot).c.o.m
PGP: 5D91 6F57 2646 83F9 6D7F 9C87 886D 88AF
``So long ago, when we were taught, that for whatever
kind of problem you've got, you just put the right formula
in, a solution for every fool....''
--Indigo Girls, ``Least Complicated''
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.1 Int.
iQCVAwUBOtySMSZv+/Ry/LrBAQGfvwP7Bp2YpgFLuw7O6KjiB43rKbtlYUEaNhEr
4cimkvPhlsZcxYXeRtjxDV9+miHeZ/K2sR3McxFDu+o7vBlIQNTqk/CwJ3yRz9zh
9Jha5RbGbQJ5OKSrz05mzdxeejcnSN7hfB0BOORP3ynzag3ToecFup8gwNoNM1jI
G+idUCSW1WE=
=gtU+
-----END PGP SIGNATURE-----
