[Syslog] Syslog-sign: Multiple signers on host?

[<Pasi.Eronen at nokia.com>]

In some places, the draft seems to assume the "traditional Unix model"
where a host has a single "syslog daemon", which receives messages
from applications via IPC, and sends them to relays/collectors using
the syslog protocol (and signs them).  This of course isn't the case
in all systems; e.g. if I configure Apache Tomcat on Windows to send
messages to a remote syslog collector, it does so directly (not going
via any central syslog daemon).

If there are multiple syslog signers on the same host, the assumption
(in Section 3) that "the signature and certificate data do not need to
include an additional parameter to identify the machine that orginates
the message" is no longer 100% accurate. While HOSTNAME identifies the
host, to figure out which Certificate Block messages belong together,
and which Payload Block applies to which Signature Block, it seems
additional information could be needed in some situations? (unless 
you try all combinations by brute force)

There might be many different ways to solve this problem; one
semi-obvious one would be to include the hash of the Payload Block in
all CertifiFrom syslog-bounces at ietf.org  Thu Jul 24 03:37:17 2008
Return-Path: <syslog-bounces at ietf.org>
X-Original-To: syslog-archive at megatron.ietf.org
Delivered-To: ietfarch-syslog-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 4A3523A67A4;
	Thu, 24 Jul 2008 03:37:17 -0700 (PDT)
X-Original-To: syslog at core3.amsl.com
Delivered-To: syslog at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id C18053A659B
	for <syslog at core3.amsl.com>; Thu, 24 Jul 2008 03:37:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.652
X-Spam-Level: 
X-Spam-Status: No, score=-6.652 tagged_above=-999 required=5
	tests=[AWL=-0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id efcPPvTtOUJy for <syslog at core3.amsl.com>;
	Thu, 24 Jul 2008 03:37:16 -0700 (PDT)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233])
	by core3.amsl.com (Postfix) with ESMTP id B57543A67A4
	for <syslog at ietf.org>; Thu, 24 Jul 2008 03:37:15 -0700 (PDT)
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211])
	by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id
	m6OAbusC010533 for <syslog at ietf.org>; Thu, 24 Jul 2008 13:37:57 +0300
Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by
	esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); 
	Thu, 24 Jul 2008 13:37:56 +0300
Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by
	vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); 
	Thu, 24 Jul 2008 13:37:54 +0300
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 24 Jul 2008 13:36:41 +0300
Message-ID: <1696498986EFEC4D9153717DA325CB72013502F1 at vaebe104.NOE.Nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Syslog-sign: Multiple signers on host?
Thread-Index: AcjteSjB1DYplmmeSVeeV9bcr/aVjQ==
From: <Pasi.Eronen at nokia.com>
To: <syslog at ietf.org>
X-OriginalArrivalTime: 24 Jul 2008 10:37:54.0542 (UTC)
	FILETIME=[548D20E0:01C8ED79]
X-Nokia-AV: Clean
Subject: [Syslog] Syslog-sign: Multiple signers on host?
X-BeenThere: syslog at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request at ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog at ietf.org>
List-Help: <mailto:syslog-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: syslog-bounces at ietf.org
Errors-To: syslog-bounces at ietf.org

In some places, the draft seems to assume the "traditional Unix model"
where a host has a single "syslog daemon", which receives messages
from applications via IPC, and sends them to relays/collectors using
the syslog protocol (and signs them).  This of course isn't the case
in all systems; e.g. if I configure Apache Tomcat on Windows to send
messages to a remote syslog collector, it does so directly (not going
via any central syslog daemon).

If there are multiple syslog signers on the same host, the assumption
(in Section 3) that "the signature and certificate data do not need to
include an additional parameter to identify the machine that orginates
the message" is no longer 100% accurate. While HOSTNAME identifies the
host, to figure out which Certificate Block messages belong together,
and which Payload Block applies to which Signature Block, it seems
additional information could be needed in some situations? (unless 
you try all combinations by brute force)

There might be many different ways to solve this problem; one
semi-obvious one would be to include the hash of the Payload Block in
all Certificate Blocate Block and Signature Block messages.  Or perhaps it
should be some kind of session identifier, similar to reboot session
ID, except not monotonically increasing? (This could be e.g. hash of
payload block, process ID of the process doing the signing, the local
time the process was started, and similar things likely to result in
unique string.) Or maybe something else? Are the APP-NAME/PROCID
of any use here?

Section 4.2.2 (about the reboot session ID) also assumes a central
syslog process that's tightly coupled with host reboots -- it should
be described in terms that make sense in other models, too.

Best regards,
Pasi
_______________________________________________
Syslog mailing list
Syslog at ietf.org
https://www.ietf.org/mailman/listinfo/syslog


ck and Signature Block messages.  Or perhaps it
should be some kind of session identifier, similar to reboot session
ID, except not monotonically increasing? (This could be e.g. hash of
payload block, process ID of the process doing the signing, the local
time the process was started, and similar things likely to result in
unique string.) Or maybe something else? Are the APP-NAME/PROCID
of any use here?

Section 4.2.2 (about the reboot session ID) also assumes a central
syslog process that's tightly coupled with host reboots -- it should
be described in terms that make sense in other models, too.

Best regards,
Pasi
_______________________________________________
Syslog mailing list
Syslog at ietf.org
https://www.ietf.org/mailman/listinfo/syslog