Signed Syslog Messages
Extracted elements (28)
Signature Groups were introduced because in deployments where different messages (differentiated by PRI/Facility) are sent to different collectors, each collector must receive only the Signature Blocks covering its own messages. Grouping syslog messages by Signature Group ensures that Signature Blocks follow their corresponding messages to each collector.
The Payload Block is never sent directly but always fragmented into Certificate Block messages because certificates can legitimately exceed 2048 octets, which is the maximum syslog message length. Each Certificate Block carries a fragment of the Payload Block along with its own signature for authenticity.
Multiple signers MAY coexist on a single host, each with its own keys and Signature Groups. Each signer must use a unique combination of APP-NAME and PROCID. The triple (HOSTNAME, APP-NAME, PROCID) uniquely identifies originators of syslog-sign messages across the network, provided signers use unique HOSTNAMEs.
A collector MUST ignore duplicates of Signature Blocks and Certificate Blocks already received and authenticated. Collectors MUST also be able to cope with overlapping Signature Blocks.
All implementations MUST support Key Blob Type 'C' (PKIX certificate per RFC 5280) to ensure at least one common Key Blob Type between sender and receiver for immediate validation.
All implementations MUST support SHA1 as the hash algorithm; SHA256 SHOULD also be supported. These are identified by the hash algorithm octet in the Version field.
Collectors MUST support X.509 certificate fingerprints for end-entity certificate matching, and MUST support configuring a list of HOSTNAMEs (as FQDNs or IP addresses) for each peer. Signer implementations MUST provide a means to generate a key pair and self-signed certificate.
Each unique signer MUST have a unique APP-NAME and PROCID combination on each host. A Signature Block message MUST use the same HOSTNAME, APP-NAME, and PROC-ID as the corresponding Certificate Block messages containing the Payload Block.
For TLS transport, the sender MUST send a fresh Certificate Block when a session is established, to keep sender and receiver synchronized with the most current Certificate Block.
Implementations of syslog-sign MUST also implement RFC 5424. Because syslog-sign uses STRUCTURED-DATA elements defined in RFC 5424, that protocol is a prerequisite.
Syslog messages MUST NOT be changed in transit; any alteration or truncation renders signing invalid. Signer and collector implementations MUST support messages up to and including 2048 octets to minimize truncation.
Syslog-sign messages (Signature Block messages and Certificate Block messages) MUST NOT themselves be signed by a Signature Block. Collectors know to process these differently from normal messages.
The Reboot Session ID MUST strictly monotonically increase after each reboot to allow collectors to distinguish messages across reboots. If the signer cannot guarantee monotonic increase, RSID MUST be set to 0.
UDP is NOT RECOMMENDED for use with signed syslog because its recommended payload size of 480 octets is too restrictive for Signature Block messages. TLS transport (RFC 5425) is the preferred transport.
The digital Signature (SIGN) in both Signature Blocks and Certificate Blocks is calculated over the entire formatted message before the SIGN parameter is added. For OpenPGP DSA, the signature contains DSA values r and s as concatenated multiprecision integers, base64 encoded.
The Hash Block (HB) contains base64-encoded hashes of entire syslog messages, ordered left to right, space-separated, all within a single SD-PARAM. Each hash covers the complete syslog message starting from '<' of the PRI; hash size MUST NOT be shorter than 160 bits.
The Payload Block contains key management information conveyed via Certificate Block fragments. It consists of a full local timestamp, a one-octet Key Blob Type ('C'=PKIX cert, 'P'=OpenPGP cert, 'K'=raw public key, 'N'=pre-distributed, 'U'=installation-specific), and the base64-encoded key blob. There is exactly one Payload Block per reboot session.
The Signature Group (SG) and Signature Priority (SPRI) fields together define how syslog messages are grouped for signing. SG=0 means one group for all messages; SG=1 means each PRI value is its own group; SG=2 means groups cover PRI ranges; SG=3 means groups assigned by an out-of-band scheme.
IANA created the 'Syslog syslog-sign Key Blob Type' registry for the one-octet Key Blob Type field, with initial values: 'C' (PKIX certificate), 'P' (OpenPGP certificate), 'K' (raw public key), 'N' (pre-distributed), 'U' (installation-specific).
IANA created the 'Syslog syslog-sign SG Field' registry for Signature Group field values (0-3), defining the four Signature Group assignment schemes.
IANA created the 'Syslog syslog-sign Version' registry for the VER field, initially populated with protocol version '01', hash algorithms SHA1 ('1') and SHA256 ('2'), and signature scheme OpenPGP DSA ('1').
IANA registered two new SD-IDs for syslog Structured Data: 'ssign' for Signature Block messages and 'ssign-cert' for Certificate Block messages. These are registered in the Syslog Structured Data ID Values registry.
Message authenticity is not established until the Signature Block is verified. With Signature Block checking, an attacker can only forge messages if they compromise the signer's private key. Collectors should not assume message authenticity before validation.
The online log verification process is susceptible to flooding (DoS) attacks. An attacker can flood the collector with unsigned messages, causing legitimate messages to roll off the 'Waiting for Signature' queue before their Signature Blocks arrive. Implementers must dimension queues sufficiently large.
Unless TLS is used as a transport, all event messages, Certificate Blocks, and Signature Blocks are sent in plaintext, allowing both network administrators and attackers to observe the contents. TLS transport (RFC 5425) is recommended to protect confidentiality.
The Certificate Block is encoded as an SD ELEMENT with SD-ID 'ssign-cert', containing fields in fixed order: VER (4 octets), RSID (1-10 octets), SG (1 octet), SPRI (1-3 octets), TPBL (1-8 octets), INDEX (1-8 octets), FLEN (1-4 octets), FRAG (variable, base64), SIGN (variable, base64).
The Signature Block is encoded as an SD ELEMENT with SD-ID 'ssign', containing fields in fixed order: VER (4 octets), RSID (1-10 octets), SG (1 octet), SPRI (1-3 octets), GBC (1-10 octets), FMN (1-10 octets), CNT (1-2 octets), HB (variable, base64), SIGN (variable, base64). All binary values are base64 encoded per RFC 4648.
The Version field (VER) is 4 octets: the first 2 octets encode the protocol version ('01' for this specification), the 3rd octet encodes the hash algorithm ('1'=SHA1, '2'=SHA256), and the 4th octet encodes the signature scheme ('1'=OpenPGP DSA). Full values are '0111' (SHA1) or '0121' (SHA256).