Subject: [Syslog] Syslog-sign: Signature groups, originators, etc.

From: <[email-masked]>
Date: Thu, 5 Feb 2009 08:45:10 +0100

I've gone through the following emails, trying to figure out what the
outcome was for multiple signers per host, and signing the same
messages with multiple algorithms (for e.g. algorithm transition).

http://www.ietf.org/mail-archive/web/syslog/current/msg02023.html
http://www.ietf.org/mail-archive/web/syslog/current/msg02025.html
http://www.ietf.org/mail-archive/web/syslog/current/msg02030.html
http://www.ietf.org/mail-archive/web/syslog/current/msg02036.html
http://www.ietf.org/mail-archive/web/syslog/current/msg02040.html
http://www.ietf.org/mail-archive/web/syslog/current/msg02041.html
http://www.ietf.org/mail-archive/web/syslog/current/msg02042.html
http://www.ietf.org/mail-archive/web/syslog/current/msg02043.html
http://www.ietf.org/mail-archive/web/syslog/current/msg02047.html
http://www.ietf.org/mail-archive/web/syslog/current/msg02048.html
http://www.ietf.org/mail-archive/web/syslog/current/msg02051.html
http://www.ietf.org/mail-archive/web/syslog/current/msg02052.html
http://www.ietf.org/mail-archive/web/syslog/current/msg02136.html

I think one conclusion from these emails is that the concept of
Signature Group probably needs some clarification. Currently,
Section 1 says that

   Appropriate syslog-sign messages must be kept with their proper
   syslog messages.  To address this, syslog-sign uses a Signature
   Group.  A Signature Group identifies a group of messages that are
   all kept together for signing purposes by the originator.  A
   Signature Block always belongs to exactly one Signature Group and
   always signs messages belonging only to that Signature Group.

This leaves several questions open. For example, it seems one cannot
easily identify the originator of a normal syslog message?

The text added in -24 to Sections 4.1 and 5.3.1 implies that you can
use HOSTNAME+APPNAME+PROCID to identify the originator of Signature
Blocks and Certificate Blocks.

But presumably this does not apply to normal syslog messages -- in a
"single syslog daemon" model, I guess APPNAME for normal syslog
messages would identify the application that generated the message
(not the syslog daemon), and PROCID would be related to the
application (e.g. Unix PID, or even SMTP transaction ID as suggested
in the syslog-protocol document).

Another question is whether a single originator can sign the same set
messages using different algorithms (different VER) -- and if it can,
are these separate Signature Groups or the same one? (I think saying
they're the same signature group would be simpler -- otherwise, the
same message might have different message number when signed with
different algorithms.)

Yet another question is whether Certificate Blocks with same
HOSTNAME,APP-NAME,PROCID,VER,RSID (but different SG/SPRI) have to
contain the same key blob. Below I'm assuming they MUST do so (since
it seems to simplify the description).

However, it's probably more important to look this from the collector
point-of-view. That is, given a wide variety of originator behavor,
how does the collector process the stuff it gets?

Currently, Section 7.1 says "we presume that the stored log files have
already been separated by originator, Reboot Session ID, and Signature
Group.  This can be done easily with a script file."  With multiple
originators per HOSTNAME, it's probably not that easy any more (or at
least, it's not so obvious that we could omit the description from the
spec).

Perhaps the collector behavior described in Section 7 should instead
assume that the log file can contain messages from multiple
originators (on the same HOSTNAME), and also multiple RSIDs and
Signature Groups. Here's a sketch of what this could look like
(may not have all the details correct yet):

Input: log file, separated by HOSTNAME (not originator, RSID, or
anything else)

a. Split contents to three files as before.

b. Go through the Certificate Block file, ignoring messages with
   unsupported VER, and separate them by (APP-NAME, PROCID, VER, RSID).

   For each separated group, sort the Certificate Blocks by INDEX
   value, and check if we can recontruct the Payload Block. If so,
   reconstruct it, verify it, and store the public key indexed by
   (APP-NAME, PROCID, VER, RSID).

c. Go through the Signature Block file, ignoring messages with
   unsupported VER, and separate them by (APP-NAME, PROCID,
   RSID, SG, SPRI). (but not VER)

   For each separated group, sort the Signature Blocks by FMN.

   [..]

   3.  For each remaining hashed message in the Signature Block:
       a.  Look up the hash value in the keyed message file.
       b.  If the message is found, write (message number, message text)
           to the authenticated log file. The authenticated log file
           SHOULD also include information identifying the
           originator (e.g. APP-NAME and PROCID, or some information from
           the Payload Block) and RSID and GBC to allow comparing
           message numbers within that originator.

Does this adequately handle all the cases? Do we need better definitions
of Originator, Reboot Session, and Signature Group as suggested
by Martin in msg02052.html?

Best regards,
Pasi