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 _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
